
2/72

LR14UMTS ACCESS NETWORK FEATURE PLANNING GUIDE 30/JUN/2014

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Alcatel-Lucent Confidential & Proprietary

UMT/SYS/INF/041185 V01.07/EN Standard, External Page 2 of 72

Copyright 2014 by Alcatel-Lucent Technologies. All Rights Reserved.

About Alcatel-Lucent

Alcatel-Lucent (Euronext Paris and NYSE: ALU) provides solutions that enable serviceproviders, enterprises and governments worldwide, to deliver voice, data and videocommunication services to end-users. As a leader in fixed, mobile and converged broadbandnetworking, IP technologies, applications, and services, Alcatel-Lucent offers the end-to-endsolutions that enable compelling communications services for people at home, at work and onthe move. For more information, visit Alcatel-Lucent on the Internet: http://www.alcatel-lucent.com

Notice

At the time of publication, this document reflects the latest information on Alcatel-Lucents

offer. However, as we are continually enhancing our products and solutions, we recommendthat on a bi-monthly basis you obtain the latest version of this document from your Alcatel-Lucent representative.

Trademarks

The following trademarks are used throughout this document:

Alcatel-Lucent, Alcatel, Lucent Technologies and their respective logos are trademarks andservice marks of Alcatel-Lucent, Alcatel and Lucent Technologies.

Sun, Sun Microsystems, the Sun Logo, Java and all Java-based trademarks and logos aretrademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and othercountries.

Microsoft, Microsoft Internet Explorer logo, Microsoft Office Compatible logo, NetMeeting,

Outlook, PowerPoint, Visio, Visual Basic, Windows, Windows logo, Windows NT, and/or otherMicrosoft products referenced are either registered trademarks or trademarks of MicrosoftCorporation in the U.S. and/or other countries


3/72





PUBLICATION HISTORY

JUNE 30TH2014 - ISSUE 01.07 / EN, Standard, External

Modification of features description:

125616 W-CDMA/LTE dual-technology support by D4U

Removal of features:

165529 RRH2x60-1900A (RRH2x60-1900 with 4 antenna connections) with 9926digital

170506 Support of DC-HSDPA with Multiple RRH per cell

JUNE 11TH2014 - ISSUE 01.06 / EN, Draft, Internal

Internal version for review

MARCH 31

ST

2014 - ISSUE 01.05 / EN, Standard, ExternalUpdated version to include features:

176914 Support of band 12 MFBI capable UE in WCDMA

177111 Digital DAS using Tyco CDIU with WCDMA 9396 digital Phase 2

Modification of features description:

112527 Defense against PA failure in parallel x2PAM configurations

168556 Traffic filtering in cell overload - new Market support (939x Node B) andenhancement

Removal of features:

100894 UMTS to LTE PS HO

MARCH 17TH2014 - ISSUE 01.04 / EN, Draft, Internal


OCTOBER 15TH2013 - ISSUE 01.03 / EN, Preliminary, External

Preliminary version for external distribution.

SEPTEMBER 9TH2013 - ISSUE 01.02 / EN, Draft, Internal


JULY 19TH2013 - ISSUE 01.01 / EN, Draft, Internal

Document creation


4/72





CONTENTS

1 INTRODUCTION ................................................................................................ 6

1.1 OBJECT ....................................................................................................... 61.2 SCOPE OF THIS DOCUMENT .................................................................................... 6

1.3 FEATURES LISTS .............................................................................................. 71.4 AUDIENCE..................................................................................................... 8

2 RELATED DOCUMENTS ........................................................................................ 9

2.1 APPLICABLE DOCUMENTS ...................................................................................... 92.2 REFERENCE DOCUMENTS...................................................................................... 9

3 LR14.2W MAIN DRIVERS .................................................................................... 10

4 LR14.2W OPTIONAL SW PACKAGES ...................................................................... 11

5 LR14.2W FEATURES ......................................................................................... 12

5.1 BASELINE ................................................................................................. 12168853 LR14.2W 3GPP Baseline .......................................................................... 12

5.2 PERFORMANCESANDCAPACITY ...................................................................... 13

108103 Enhanced CELL_FACH for DL&UL ............................................................... 13 121209 Enhanced UE DRX in CELL_FACH ................................................................ 15122612 E-DCH performance enhancement .............................................................. 16163882 F-DPCH Enhancements ........................................................................... 20165360 Smart E-DCH resource usage - new Market support (939x Node B) ........................ 21172598 DC-HSDPA functional enhancement ............................................................ 21

5.3 SERVICESANDRADIORESOURCESMANAGEMENT .................................................. 23131683 Selective Paging Discard ......................................................................... 23164968 Support of GLONASS assistance data over IuPC (SAS Centric mode) ....................... 25168556 Traffic filtering in cell overload - new Market support (939x Node B) and enhancement27

5.4 MOBILITY ................................................................................................. 27132010 RRC Connection Re-establishment over Iur support .......................................... 27 170715 Fast return to LTE improvement ................................................................ 28176914 Support of band 12 MFBI capable UE in WCDMA .............................................. 30

5.5 TRANSPORTANDTRANSMISSIONCAPABILITIES .................................................... 32126921 DSCP Marking Enhancements .................................................................... 325.6 OPERATIONALEFFECTIVENESS ....................................................................... 38

121555 LR14.2W RNC Counters Evolution ............................................................... 385.7 NODEBEVOLUTIONS ................................................................................... 42

112527 Defense against PA failure in parallel x2PAM configurations ............................... 42 123826 AISG for TRDU60-21B ............................................................................. 44125616 W-CDMA/LTE dual-technology support by D4U ............................................... 45127580 CPICH power level reporting correction for oneBTS DAS .................................... 47132085 3G support of TRDU2x60 900MHz without dependency to 2G ............................... 49162306 Support of VAM on TRDU60-21B ................................................................. 51163122 RRH2x60-21A operation with 45MHz Instantaneous Bandwidth ............................. 52166352 3G AISG support on TRDU2x60 900MHz ........................................................ 54166354 LR Outdoor Battery cabinet ..................................................................... 55

168705 Noise floor self-learning algorithm for oneBTS ............................................... 57 169488 AISG2.0 on 9396-based RRHs Phase 1A ......................................................... 59170665 TRDU2x80 2100MHz ............................................................................... 61174085 AISG management enhancements .............................................................. 62174283 AISG for MC-RRH 3G-only ........................................................................ 63177111 Digital DAS using Tyco CDIU with WCDMA 9396 digital Phase 2 ............................. 65

5.8 RNCEVOLUTIONS ....................................................................................... 66134390 9771 Wireless Cloud Element (WCE) RNC .................................................... 66

6 ABBREVIATIONS AND DEFINITIONS ....................................................................... 69

6.1 ABBREVIATIONS ............................................................................................. 69

FIGURES

1: A C AD C ( A DC) ................................. 17


5/72





2: A ACD C AD C ( A 122612) ................................. 17 3: DC400 CAAC ............................................................. ......................................... 18 4: A AAC DAA C .......................................................... .................................... 25 5 : 700 BAD A ..................................................................................................................... 31 6 : A AC A 3 A 13 A ......... 35

7 : A AC A A B 3 A A 126921A ...................................................................... ............................................................... ... 36

8 : CDA/ DAC D4 ............................................................................................. 46 9 : D CAB A CAB ...................................................................... 56 10 : D280 B1 ..................................................................................................................................... 61


6/72





1 INTRODUCTION

1.1 Object

This document provides a high-level description of the features introduced in

release LR14 of Alcatel-Lucent UMTS Radio Access Network (UTRAN). In the rest of

the document the release will be referred as LR14.2W (W like W-CDMA).

The features described in this document represent the content of the release at the

time the document is published. There might be changes to the final release content

to accommodate latest 3GPP standardization results or changes in the market.

The OAM part of the release is covered in the Wireless Management System for

UTRAN Feature Planning Guide LR14.2 [R1].

1.2 Scope of this document

This document lists and describes customer-viewable UTRAN features that are new

in LR14.2W.

Both optional and base features are included. Section 4 provides the list of optional

software packages.

In this document, features are grouped using the following organizing principles:

Features are grouped by category:

BASELINE

PERFORMANCES AND CAPACITY

SERVICES AND RADIO RESOURCES MANAGEMENT

MOBILITY

TRANSPORT AND TRANSMISSION CAPABILITIES

OPERATIONAL EFFECTIVENESS

NODE B EVOLUTIONS

RNC EVOLUTIONS

Within category, features are presented in numerical order by Feature ID

(FID), except when features are grouped together under the same

description.

The table below is included in the hardware dependency section of each feature

description to clearly indicate with which products and with which hardware

requirements a feature is supported.

The 939x Node B product family [R11] is only deployed in the North American W-

CDMA market. Other Node B means any Node B not part of the 939x portfolio.

RNC 9370 Other Node B 939x Node B


7/72





Support S, NS S, NS S, NS

HW requirements None, N/A,required modules

None, N/A,required modules

None, N/A,required modules

"S" on the line "Support" means the feature is supported with the correspondingproduct, while "NS" means it is not

"None" on the line "HW requirements" means the feature is supported with no

specific hardware requirements, otherwise the required modules are explicitly

listed

Important notes

The last software release to support RNC 9370 PSFP modules is UA07.1.3. As such,

None in the RNC 9370 HW requirements column means the feature is supported on

DCPS and eDCPS only.

The last software release to support iCEM and iCCM modules is LR13.3W. As such,None in the Other Node B HW requirements column means the feature is

supported on x-Modules and e-Modules only.

1.3 Features Lists

The following table provides the list of features described in this FPG, grouped by

Node B family applicability. It also provides an indication on whether the feature is

base or optional.

ID Feature Title Base orOptional

OtherNode B

939xNode B

121555 LR14.2W RNC Counters Evolution Base S S

122612 E-DCH performance enhancement Optional S S

131683 Selective Paging Discard Optional S S

164968 Support of GLONASS assistance data overIuPC (SAS Centric mode)

Optional S S

165360 Smart E-DCH resource usage - newMarket support (939x Node B)

Optional S S

168556 Traffic filtering in cell overload - newMarket support (939x Node B)

Optional S S

168853 LR14.2W 3GPP Baseline Base S S

170715 Fast return to LTE improvement Optional S S

108103 Enhanced CELL_FACH for DL&UL Optional S NS

121209 Enhanced UE DRX in CELL_FACH Optional S NS

123826 AISG for TRDU60-21B Base S NS

125616 W-CDMA/LTE dual-technology support byD4U

Optional S NS

132085 3G Support of TRDU2x60 900MHz withoutdependency to 2G

Base S NS

134390 9771 Wireless Cloud Element (WCE) - Optional S NS


8/72





RNC Hardware

162306 Support of VAM on TRDU60-21B Base S NS

163122 RRH2x60-21A operation with 45MHzInstantaneous Bandwidth

Optional S NS

163882 F-DPCH Enhancements Optional S NS

166352 3G AISG support on TRDU2x60 900MHz Base S NS

166354 LR Outdoor Battery Cabinet Optional Configuration

S NS

170665 TRDU2x80 2100MHz Optional Hardware

S NS

172598 DC-HSDPA functional enhancement Optional S NS

174085 AISG management enhancements Base S NS

174283 AISG for MC-RRH 3G-only Base S NS

112527 Defense against PA failure in parallelx2PAM configurations

Optional NS S

126921 DSCP Marking Enhancements Optional NS S

127580 CPICH power level reporting correctionfor oneBTS DAS

Optional NS S

132010 RRC Connection Re-establishment overIur support

Optional NS S

168705 Noise floor self-learning algorithm foroneBTS

Optional NS S

169488 AISG2.0 on 9396-based RRHs Phase 1A Optional NS S176914 Support of band 12 MFBI capable UE in

WCDMAOptional NS S

177111 Digital DAS using Tyco CDIU with WCDMA9396 digital Phase 2

Optional HW NS S

1.4 Audience

The primary audience for this document is Alcatel-Lucent customers. This document

is also intended for Alcatel-Lucent functional and operational teams.


9/72





2 RELATED DOCUMENTS

2.1 Applicable documents

None

2.2 Reference documents

[R1] UMT/OAM/INF/040976 Wireless Management System for UTRAN Feature

Planning Guide LR14.2

[R2] UMT/SYS/INF/7906 UMTS4.1 Access Network Feature Planning Guide

[R3] UMT/SYS/INF/12239 UMTS4.2 Access Network Feature Planning Guide

[R4] UMT/SYS/INF/16608 UA05.0 Access Network Feature Planning Guide


[R6] UMT/SYS/INF/022664 UA06 Access Network Feature Planning Guide

[R7] UMT/SYS/INF/025020 UA07 Access Network Feature Planning Guide


[R9] UMT/SYS/INF/037991 LR13W Access Network Feature Planning Guide

[R10] 9YZ-03990-0005-FMZZA Alcatel-Lucent LTE Radio Access Network Release

LA5.0.0 FDD Feature Planning Guide

[R11] UMT/BTS/INF/024180 Alcatel-Lucent 939X W-CDMA Node B Family Product

Description


10/72





3 LR14.2W MAIN DRIVERS

CAPACITY & COVERAGE

Cell capacity

E-DCH cell capacity increase with E-DCH 400kbps

RF Capacity

Increased RF transmit power over disaggregated spectrum with TRDU2x802100MHz

Increased instantaneous bandwidth (45MHz) on RRH2x60-21A for operation overdisaggregated spectrum

UMTS 900MHz for rural coverage/better indoor penetration

Consolidation of U900 coverage configurations with 3G only mode on TRDU2x60900MHz

Controller Capacity

Wireless Cloud Element (WCE) RNC introduction - RNC application running on ITplatform providing increased and scalable RNC capacityas well as readiness forfuture deployment in cloud architecture

USER EXPERIENCE

Improved reactivity & user peak throughput

User perceived reactivity similar to LTE and additional UE battery saving with

Enhanced CELL_FACH ULand enhanced UE DRX

LTE SUPPORT

Digital Evolution

3G/LTE dual-technology BBU

Complement 3G/LTE mobility features set

Fast return to LTE improvement


11/72





4 LR14.2W OPTIONAL SW PACKAGES

A number of LR14.2W features compose the optional SW packages as detailed in the belowtable.

ID Feature Title SI Code Saleable Offer

122612 E-DCH performance enhancement 3JR 35055 AF HSUPA LR14Mobility &PerformanceFeatures

131683 Selective paging discard 3JR 35040 AE RNC Pagingoverloadmanagement

164968 Support of GLONASS assistance data over IuPC

(SAS centric mode)

3JR 35010 AD Advanced Location

Services170715 Fast return to LTE improvement 3JR 35033 AE Mobility to LTE


108103 Enhanced CELL_FACH for DL&UL 3JR 35053 AF EnhancedCELL_FACH forSmartphones

121209 Enhanced UE DRX in CELL_FACH

125616 W-CDMA/LTE dual-technology support by D4U 3BK 33994 AA WCDMA/LTE dual-technology supportby D4U

163122 RRH2x60-21A operation with 45MHzinstantaneous bandwidth

3BK 33993 AA RRH RTU 45MHziBW unlock

163882 F-DPCH enhancements 3JR 35029 AE Smartphoneexperience

172598 DC-HSDPA functional enhancement 3JR 35009 AD End user MobilityImprovement

112527 Defense against PA failure in parallel x2PAMconfigurations

3BK 33992 AA Defense against PAfailure in parallelx2PAMconfigurations

126921 DSCP marking enhancements 3JR 35052 AF Quality of Servicedifferentiation

127580 CPICH power level reporting correction forOneBTS DAS

3BK 33991 AB CPICH power levelreportingcorrection for

oneBTS DAS132010 RRC connection re-establishment over Iur

support3JR 35006 AD Mobility & Traffic

Balancing

168705 Noise floor self-learning algorithm for OneBTS 3BK 33991 AA Noise floor self-learning algorithmfor OneBTS

169488 AISG2.0 on 9396 based RRHs Phase 1A 3BK 33991 AC RRH AISG2.0 ondigital 9396


12/72





5 LR14.2W FEATURES

5.1 BASELINE

168853 LR14.2W 3GPP Baseline

FEATURE DESCRIPTION

Alcatel-Lucent LR14.2.W software releases is built upon the following 3GPP baseline:

3GPP release: Rel-11

3GPP specification version: March 2013

This baseline applies to all supported UTRAN external interfaces.

FEATURE BENEFITS

Making use of a recent 3GPP baseline & implementing all the essential changes (CRs)

approved by 3GPP beyond this baseline ensures that Alcatel-Lucent UMTS solution reaches a

high quality level both regarding the behaviour of Alcatel-Lucent UTRAN products for handling

UMTS features (RNC, BTS) & regarding multi-vendor interoperability.

IMPACTED SYSTEMS

Node B, RNC

DEPENDENCIES

Hardware


Support S S S

HW requirements None None None

Software feature

No dependency. On the contrary, this feature is an input to all the LR14.2Wfeatures based on 3GPP specifications.

External nodes or devices (Core Network, UE or others)

No dependency but this feature is an input to the multi-vendor interoperabilityprograms setup by Alcatel-Lucent.

Standards

By definition, this feature depends on 3GPP specifications, especially on 3GPPspecifications for external interfaces.

RESTRICTION/LIMITATION

None

ENGINEERING IMPACTS

None


13/72





OPERATIONAL REQUIREMENTS

Counters

None

Configuration Management and Parameters

None

Fault Management and Alarms

None

FEATURE TYPE

Base

5.2 PERFORMANCES AND CAPACITY

108103 Enhanced CELL_FACH for DL&ULFEATURE DESCRIPTION

Todays Smartphone applications mostly generate relatively small data bursts. Servicing these

data sessions in CELL_DCH is costly. 3GPP Rel-8 has introduced the Enhanced CELL_FACH

state, hybrid between HSPA CELL_DCH and legacy CELL_FACH, designed to best manage such

traffic.

The idea of Enhanced CELL_FACH in 3GPP is that small transfers can be better served on

CELL_FACH state by accessing HSPA code and power resource without need for a transition to

CELL_DCH. UE downloading larger file sizes in CELL_DCH can also benefit from the feature

thanks to faster RRC state transition.

FEATURE BENEFITS

Improved call setup time

Improved resource utilization

Interference reduction

Improved UE battery life

Reduced signaling load

IMPACTED SYSTEMS

Node B, RNC, OAM

DEPENDENCIES

Hardware


Support S S NS

HW requirements None eCEM(-U) N/A

Software feature


14/72





89563 Improved L2 for uplink [R9]

168710 - Enhanced CELL_FACH for DL (3GPP Rel-7) [R9]


Rel-7 or Rel-8 UE supporting eRACH (Common E-DCH), eFACH (Common HS-DSCH)

Standards

3GPP Rel-8


Only Common E-DCH 10ms TTI is supported.

ENGINEERING IMPACTS

Additional Common Control Channels need to be allocated for eFACH: E-AGCH, E-

RGCH/E-HICH, F-DPCH.

Common E-DCH resources are taken from existing CELL_DCH dedicated E-DCHresource.


Counters

Several new counters are introduced to monitor capacity, throughput and E-DCH

resource usage.


1. For online feature activation,

a.

RNC does not support activating E-FACH for UL alone if the cell isalready configured with E-FACH for DL only. The cell has to be locked

and unlocked.

b. RNC will support activating E-FACH for DL and UL in one shot.

2. For online feature de-activation,

a. RNC does not support de-activating E-FACH for UL alone if the cell is

already configured with E-FACH for DL and UL. The cell has to be locked

and unlocked.

b. RNC will support de-activating E-FACH for DL and UL in one shot.

3. Thanks to the above policy, RNC does not manage cell re-selection between Rel-

7 E-FACH cell and Rel-8 E-FACH cell.

The feature has an activation flag at the RNC and cell level. Several new parameters

are introduced to configure the feature (>70). However, only a few of them are

expected to be configured / updated by the operator such as timers or traffic

volume thresholds that control the transitions between RRC states.


New alarm in case Enhanced CELL_FACH cannot be configured in a given cell.

FEATURE TYPE


15/72





Optional

121209 Enhanced UE DRX in CELL_FACH

FEATURE DESCRIPTION

The feature Enhanced UE DRX in CELL_FACH state for FDD supports:

Discontinuous HSDPA (HS-SCCH / HS-DSCH) reception in CELL_FACH state to further

save UE battery life,

Free of FACH measurement occasions thanks to the fact a UE can do measurements in

DRX cycles.

FEATURE BENEFITS

To improve battery consumption in case of infrequent small packet data services for

Smartphone users staying in CELL_FACH state, without a need of state transition.

To reduced signaling load by allowing keeping UE longer in CELL_FACH state (less frequent

state transitions between CELL_FACH and Idle or PCH).

IMPACTED SYSTEMS

Node B, RNC, OAM

DEPENDENCIES

Hardware


Support S S NS

HW requirements None eCEM(-U) None

Software feature

89563 Improved L2 for uplink [R9]

108103 Enhanced CELL_FACH DL & UL (3GPP Rel-8)

168710 Enhanced CELL_FACH DL (3GPP Rel-7) [R9]


Rel-8 UE supporting eRACH (Common E-DCH), eFACH (Common HS-DSCH), eDRX

Standards

3GPP Rel-8


None

ENGINEERING IMPACTS

None


Counters


16/72





One new counter is added to count the number of MAC PDUs which are dropped by

NodeB due to either discardTimerexpiry or timerT1expiry for those eDRX-capable

UEs.


The feature has an activation flag at the RNC level.

eDRX pattern is fully configurable. Furthermore, it is possible to keep UE longer in

eFACH with eDRX by increasing eFACH specific T2 timer.


Since Common HS-DSCH and Enhanced DRX capabilities are linked, existing eFACH

alarms can be reused therefore no specific alarm needed.

FEATURE TYPE

Optional

122612 E-DCH performance enhancement

FEATURE DESCRIPTION

This feature is made of two main items:

Improvement in cell load management - Currently, the RNC does not have a good view

of the real load of a cell, because E-DCH is handled as best effort functionality: any

E-DCH user is accepted, up to the point that the cell is so loaded that the NodeB is no

longer in a position to guarantee a single E-DCH PDU per user. At that stage, the

NodeB starts rejecting the setup of new calls. This comes without warning for the

RNC, as the load measurements reported to it do not take into account the E-DCH

load. As E-DCH is offered as best effort, it can be considered normal not to report it.

Yet, it is not fully a best effort service, because the UTRAN is not allowed to drop

such a call, and if no PDU can be sent by a UE, the corresponding call is likely to

rapidly drop, as the signaling between UE and UTRAN can no longer be exchanged. To

improve this, the NodeB reports a virtual load to the RNC: for E-DCH, this corresponds

to what the UEs would generate as load if they were sending the minimum traffic.

The RNC derives a meaningful cell load color instead of totally ignoring the E-DCH

load: this is called the enhanced UL cell load color. The RNC takes the enhanced UL

cell load color into account in its decisions with regard to resource allocation.

The pictures below present (for oneBTS, but the same applies for iBTS):

o UL cell load color before the feature (with sudden change from normaloperation region and overload operation region: in this mode, the RNC cannot

adapt the admission and configuration of new calls according to the real load.

It only has 2 behaviors: normal operation and overload).

o Enhanced UL cell load color, where E-DCH virtual load is seen by the RNC,

which can then have a much smoother adaptation of the acceptance and

configuration of calls in the normal operation region, and thus avoid, or at

least delay the occurrence of overload operation.


17/72

LR14UMTS ACCESS NETW

Passing on or copying of this document, u

UMT/SYS/INF/041185 V01.07/

Figure 1: Operation wit

Figure 2: Operation wit

Note: The load line sh

Introduction of

E-DCH targets v

offering these

primarily DL-ori

improvement (if

sometimes turn

costly than R99 i

RK FEATURE PLANNING GUIDE

se and communication of its contents not permitted without Alcatel


EN Standard, External

h UL cell load color (prior to feature introduc

h enhanced UL cell load color (with feature 1

uld always be less than 1 by definition, even in

-DCH400 - This corresponds to a new approach

ery high UL bit rates, however, load situation

maximum rates. Furthermore, many applic

nted throughput and/or their burstiness, prov

any), when served with a high UL bit rate. Cl

out to be a waste of resources. Tests have sho

n terms of UL Load at equivalent throughput fo

30/JUN/2014

Lucent written authorization

Page 17 of 72

ion)

2612)

overload situations.

for E-DCH. Classical

almost never permits

ations, due to their

ide only marginal QoE

ssical E-DCH can then

n that E-DCH is more

r low bit rates (e.g. 32


18/72





kbps). Instead E-DCH400 aims at providing bit rates within a range from low bit rates

to rates just above those allowed by R99. It uses the main advantages of E-DCH such

as HARQ, allowing a fast and efficient retransmission mechanism. Its entirely

compatible with the standards, only using adapted E-TFCI values, Power Offset values

and SIR targets. Internal tests have shown that E-DCH 400 is more efficient than R99even at low rates. E-DCH 400 introduction thus brings significant improvement in load

handling in the user plane domain. It also avoids increasing control plane load, by

suppressing the need of reconfiguring the call from E-DCH to R99 in case of radio

congestion, as it was envisaged in previous releases, which would create signaling

load between RNC and NodeB. Classical E-DCH must remain accessible to users that

do need higher UL throughputs and can benefit from it according to load. E_DCH 400

or classical E_DCH can be selected according to enhanced UL cell load color, in

addition to call priority. Real time traffic measurements can also be used to switch

between E_DCH 400 and classical E_DCH.

Note that for classical E-DCH, the NodeB has implemented a defense mechanism

against Absolute Grant (AG) misdetection by UEs: if the UE wrongly decodes an AG

that lets it send more data than expected, the NodeB quickly sends an update of the

AG to bring the rate down to normal. This defense mechanism is compatible with E-

DCH 400.

The following figures present capacity test results obtained in lab, where all UEs

perform UDP traffic. They clearly show the gain of EDCH 400k over classical EDCH on

Cell Throughput (+60% for 20 UEs) and non-EDCH load (-40% for 20 UEs).

Figure 3: E-DCH400 capacity test results

FEATURE BENEFITS

The feature improves the cell UL capacity and improves UL quality of service (by better

choice of users that can access high UL rate)

IMPACTED SYSTEMS

Node B, RNC, OAM

DEPENDENCIES

Cell Throughput

0

200

400

600

800

1000

1200

1400

1600

1800

2000

5 UEs 10 UEs 15 UEs 20 UEs

CellThroughput(kbps)

eDCH 400k 10ms

Classical eDCH 10ms

Non EDCH load

0

10

20

30

40

50

60

5 UEs 10 UEs 15 UEs 20 UEs

NonEDCHload(%

eDCH 400k 10ms

Classical eDCH 10ms


19/72





Hardware


Support S S S


Software feature

25080 - QoS differentiation based on TC, ARP and THP [R4]: if the operatorwants that calls can benefit from classical E-DCH, feature 25080 must beactivated.


None

Standards

3GPP Rel-6


None

ENGINEERING IMPACTS

Operator may want to tune parameters according to priority requirements and

traffic profile.


Counters

Distribution of UL cell load (10% granularity), derived from Enhanced UL cell color

measurements


Activation flag for enhanced UL cell load color

Activation flag for E-DCH400

Radio parameters defining E-DCH400 (in particular E-TFCI table, PO table, SIR

target)

Parameter controlling the use of multi-RAB with E-DCH400

Parameters controlling the use of E-DCH 400 with regard to volume measurements

(activation flag, thresholds, timers)

Parameters controlling the use of E-DCH400 with regard to UL cell load

Parameters controlling the use of E-DCH 400 with regard to call QoS attributes (cell

color, number of E-DCH active users)


None

FEATURE TYPE

Optional


20/72





163882 F-DPCH Enhancements

FEATURE DESCRIPTION

In UA08.1, in case F-DPCH is activated at the RNC level through flag isSrbOverHspaEnabled

(under RadioAccessService) but deactivated at cell level, through flags isSrbOverHspaEnabled

(under FDDCell), it is not possible for Rel-7 and Rel-8 F-DPCH capable devices to benefit from

SRB over EDCH configuration. It is therefore impossible to effectively provide cell based F-

DPCH licensing.

This feature is to remove this restriction in order to allow F-DPCH cell level licensing.

FEATURE BENEFITS

Enabler for F-DPCH per cell licensing. Benefit from SRB over EDCH capabilities regardless of F-

DPCH activation level for Rel-7 & Rel-8 devices.

IMPACTED SYSTEMS

RNC, OAM

DEPENDENCIES

Hardware


Support S S NS

HW requirements None None N/A

Software feature

29810 Enhanced Fractional DPCH [R8]


3GPP Rel-7 or Rel-8 devices supporting enhanced F-DPCH

Standards

None


None

ENGINEERING IMPACTS

None


Counters

None


No new parameter. However, the RNC will not override the setting of the parameter

isSrbOnEdchAllowedWhenTrbOnEdch (under RadioAccessService) when the F-DPCH

feature is disabled at a cell level.



21/72





None

FEATURE TYPE

Optional

165360 Smart E-DCH resource usage - new Market support (939x Node B)

FEATURE DESCRIPTION

The support of Improved initial grant allocation mechanism based on TEBS and Improved

radio conditions on TTI selection, part of Smart E-DCH resource usage feature, is extended

to the North American market where 939x product family is deployed.

Please refer to 165360 Smart E-DCH resource usage in LR13W Access Network Feature

Planning Guide [R9] for a comprehensive description of the feature.

172598 DC-HSDPA functional enhancement

FEATURE DESCRIPTIONThis feature covers 3 enhancements:

1) Always-on Upsize improvement: a DC-capable UE is preferably sent to a DC-capable cell

by iMCRA at RRC connection setup time, but before this feature, a DC-capable UE in URA_PCH

state was not redirected from the cell it chooses (based on load criteria) to a DC-capable cell

at AO upsize time. It could thus temporarily lose DC-capability. This drawback may prevent

deployment of URA_PCH. This feature removes this drawback by introducing the capability for

the RNC to redirect (in iMCTA) a DC-capable UE to a DC-capable cell at AO upsize time in case

of traffic resuming (from URA_PCH, CELL_PCH or CELL_FACH).

2) Increase of number of HSDPA-DC users from 15 to 30: currently, the number of Dual-

Carrier users (plus MIMO users) per modem is limited to 15, which may become too low for

some operators, as the number of DC-capable UEs widely increases. The operator may choose

to limit the allowed number to a lower value than 30, in order to preserve the overall HSDPA

capacity of the modem in terms of number of total users, since each MIMO or DC user takes

twice more resources than a "normal" user. This capacity increase is applicable to eCEM and

eCEM-u and is subject to licensing.

3) Aggregate modem DL capacity increase from 60 to 80 Mbit/s: this figure represents the

maximum total DL Layer 1 throughput that the modem can handle for one or several users

(more precisely, the capacity is increased to 79.2 Mbit/s). Note that no feature in the LR14

roadmap allows a single user to reach 80 Mbit/s (this will occur when e.g. feature 4C-HSDPA

is introduced), so this capacity increase can be useful e.g. in situations with one eCEM-u

handling 2 sectors with DC users. 80 Mbit/s aggregate capacity, as 60 Mbit/s before this

feature, is only achievable with the Ethernet backplane.

Note that this aggregate capacity can also be useful in situations without DC, each time an

eCEM-u handles at least 4 cells.

FEATURE BENEFITS

This feature improves DC performance and capacity. The AO upsize aspect reduces the time

during which the UE is not configured for using DC, which potentially unblocks deployment of

URA_PCH. This feature thus indirectly contributes to the URA_PCH benefits.


22/72





IMPACTED SYSTEMS

Node B, RNC, OAM

DEPENDENCIES

Hardware


Support S S NS

HW requirements None Capacity increase to80 Mbit/s: eCEMu

Max number of DC-users: eCEM/eCEMu

AO upsize: x and e-CEM(u)

N/A

Software feature

26673 - URA_PCH [R4]

26675 - CELL_PCH [R4]

108388 - Enhanced URA_PCH paging [R7]

Dual-Cell HSDPA features (81204 [R7], 104832 [R8], 118154 [R8])

89858 iMCTA Enhanced with HSPA Load Blind HHO Direct HHO on AO Upsize[R8]


CN and UEs supporting DC-HSDPA.

Standards3GPP Rel-7


iMCRA provides more flexibility than iMCTA in configuring preferences. In this

version of AO upsize improvement, it is possible to configure a systematic

preference of DC-capability over cell load, or a systematic preference of load over

DC-capability. Some intermediate choices may be possible with iMCRA without

being introduced in iMCTA yet.

ENGINEERING IMPACTS

NoneOPERATIONAL REQUIREMENTS

Counters

Number of Attempted UE State Transitions to CELL_DCH from URA_PCH, CELL_PCH

and CELL_FACH where the UE is eligible for HSDPA Multi-cell.

Number of Successful UE State Transitions where the UE is eligible for HSDPA Multi-

cell.

Number of Attempted iMCTA redirection during AO upsizing for traffic Resume, with

screening for DCH, SC and DC.


23/72





Number of Successful iMCTA redirection during AO upsizing for traffic Resume, with


Number of Attempted iMCTA redirection during AO upsizing for CAC Failure, with


Number of Successful iMCTA redirection during AO upsizing for CAC Failure, with



One activation flag per item.


None

FEATURE TYPE

Optional

5.3 SERVICES AND RADIO RESOURCES MANAGEMENT

131683 Selective Paging Discard

FEATURE DESCRIPTION

This feature introduces the ability to selectively discard lower priority (compared to other

services) paging request messages towards cells in severe cell overload conditions.

The feature applies to per Core Network domain and paging cause, where as paging messages

are discarded (via configurable % values), when the trigger-criteria exceeds a configurable

threshold.

The trigger-criteria are intended to include one or more of the following 3 criteria:

Cell color

RRC arrival rate

CAC failure %

Once a configured trigger criterion has been met, a specific (also configurable) paging-

discard-profile will be activated. The paging-discard-profile will provide the ability to specify

degree of paging discards on a per-domain basis as well as on a per-paging-cause basis

As an example: Conf1: trigger-criteria-1 activates discard-profile-A

Conf2: trigger-criteria-1 activates discard-profile-A and trigger-criteria-2 activates

discard-profile-B

There may be one or more supported trigger-criteria and paging-discard-profile sets.

Paging messages would no longer be discarded, when all of the configured trigger-criteria fall

below their associated configurable thresholds.

It is recommended to have both Selective Paging Discard and Access Class Barring (ACB)

functionality (provided by feature 98448 [R9]) operating together as ACB alone does not


24/72





provide the same level of paging channel protection without the functionality provided by this

feature.

FEATURE BENEFITS

During localized heavy congestion events causing excessive cell overload, this feature reduces

core network originating signaling flow resulting in less traffic demand on the overloaded

cells.

This provides an increased chance of users accessing the Mobile Network, improving CS and

SMS paging success rates.

IMPACTED SYSTEMS

RNC, OAM

DEPENDENCIESHardware


Support S S S


Software feature

127550/168556 Traffic Filtering in cell overload [R9]

98448 - Access Class Barring (ACB) at Cell Granularity [R9]

External nodes or devices (Core Network, UE or others)None

Standards

None


None

ENGINEERING IMPACTS

None


Counters

Counters are introduced to track the number of paging messages discarded per

paging cause by the RNC in each domain.


The functions provided by this feature can be configured by the operator through

the management system. Parameters are available to activate the selective paging

discard feature at the cell level and configure paging profiles to discard:

A percentage of Paging based on domain (CS, PS, ALL)


25/72





A percent of Paging by paging cause (Terminating Conversational,

Streaming, Interactive, Background, High & Low Priority Signaling, unknown)


Alarm used to monitor when Selective Paging Discard is triggered.FEATURE TYPE

Optional

164968 Support of GLONASS assistance data over IuPC (SAS Centricmode)

FEATURE DESCRIPTION

Alcatel-Lucent RNC supports two Location services modes or operations: RNC-centric mode

(with iSMLC solution) and SAS-centric mode with the 3GPP standard IuPC interface introduced

in LR13.1W with feature 120416 IuPC interface enhancements [R9].

In case of SAS-centric mode where the RNC is connected to an external standalone SMLC (SAS)

over the standard IuPC interface (see figure below), three location methods were supported

in the previous release: A-GPS, ECID/RTT and Basic Cell-ID.

This feature introduces the support of an additional location method based on the Russian

satellite system (GLONASS: Global Navigational Satellite System). The main impact of this

feature is for the RNC to support the GLONASS assistance data coming from the SAS and to

forward them to the UE.

Figure 4: GLONASS assistance data over IuPC

FEATURE BENEFITS

Location-based services are key features that allow operators to offer innovative services,

generate revenues, and mainly to comply with regulatory requirements.

Implementing support of GLONASS enhances the A-GPS location performance for E911 service.

With this feature, assistance data for A-GPS capable devices will now also include information

for GLONASS satellites.


26/72





GLONASS support provides an additional positioning method on top of the existing ones.

Supporting two satellite systems (GPS and GLONASS) increases the probability for a user to

see a larger number of satellites and hence increases the probability to be localized by a

satellite-based method instead of falling back to other methods like ECID/BCID. And since the

satellite-based location method is the most accurate, GLONASS (together with A-PGS)increases the overall location accuracy.

IMPACTED SYSTEMS

RNC, OAM

DEPENDENCIES

Hardware


Support S S S


Software feature

120416 IuPC Interface Enhancements [R9]


Standalone SMLC (SAS)

UE shall support GLONASS

Standards

Compliancy with 3GPP Rel-11 TS 25.453 (PCAP) and 3GPP TS 25.331 (RRC)


UE-Assisted A-GANSS method is not supported

ENGINEERING IMPACTS

None


Counters

Emergency and Non-Emergency SAS Centric GANSS counters added as part of 120416

[R9] are extended to GLONASS.


New GLONASS based data transfer parameters, as well as horizontal and vertical

accuracy attributes for SAS Centric Mode when SAS does not provide accuracy

information in the Position Activation Request.


None

FEATURE TYPE

Optional


27/72





168556 Traffic filtering in cell overload - new Market support (939x NodeB) and enhancement

FEATURE DESCRIPTION

The support of Improved definitions of Basic Call Type & Group Call type and Call Upsize

filtering from URA_PCH, part of Traffic filtering in cell overload feature, is extended to

the North American market where 939x product family is deployed.

Please refer to 168556 Traffic filtering in cell overload in LR13W Access Network Feature

Planning Guide [R9] for a comprehensive description of the feature.

This feature also introduces a solution for the UE that do not obey the Wait Time in the RRC

Cell Update Confirm message what can cause endless loop of Cell Update / Cell Update

confirm.

5.4 MOBILITY

132010 RRC Connection Re-establishment over Iur support

FEATURE DESCRIPTION

Feature 132010 extends the current RRC Connection Re-establishment (RRE) capabilities

(33821 [R6] and 34290 [R6]) to support scenarios involving Iur (i.e. RRE over Iur).

As for the current RRE feature, re-establishment over Iur is only supported in case of Radio

Link Failure and RLC unrecoverable error detection. The table below summarizes all the RRE

over Iur supported scenarios.

UE in CELL_DCH RNC/Node B detected UE detected

Old PRL on New PRL on RLCunrecoverable

error

Radio LinkFailure

RLCunrecoverable

error

Radio LinkFailure

SRNC DRNC X X X X

DRNC DRNC X X X X

DRNC SRNC X X - -

FEATURE BENEFITS

Reduce CS call drop rate in case of failures (RL failure or RLC unrecoverable Error) during Iurmobility.

IMPACTED SYSTEMS

RNC, OAM

DEPENDENCIES

Hardware


Support S NS S


28/72





HW requirements None N/A None

Software feature

33821 - RRC Connection Re-Establishment [R6]

34290 - RRC Connection Re-Establishment for CS [R6]External nodes or devices (Core Network, UE or others)

None

Standards

None


None

ENGINEERING IMPACTS

None


Counters

6 new counters are introduced to count Cell Updates over Iur, attempts and

successful RRE and RRC releases with cause DSCR.


The feature has an activation flag at the RNC level and for each neighboring RNC so

each Iur link can be configured with/without the feature.


None

FEATURE TYPE

Optional

170715 Fast return to LTE improvement

FEATURE DESCRIPTION

In case of redirection from LTE to W-CDMA due to CS Fallback (CSFB), a Rel-9 UE onward can

indicate in the RRC Connection Request message that the request is due to CSFB through the

CSFB Indication IE.

As the RNC is then able to detect that the UE was sent to W-CDMA layer due to a CSFB, the UE

can be sent back to LTE via release/redirection as soon as the CS speech call ends.

Fast return to LTE behavior, as introduced in previous release by feature 134661 Redirection

to LTE at CS speech call completion [R8], is kept for iso-functionality purpose and can also be

used for Rel-8 UE not supporting the CSFB Indication IE. Indeed, with this new feature, three

modes of CSFB detection are introduced and are configurable by the operator:

Mode #1 the CSFB indication IE is not taken into account and CSFB detection is as

per 134661 [R8].

Mode #2 for Rel-8 UE and below, CSFB detection from 134661 [R8] is used, but for

Rel-9 UE onward the detection is based on the CSFB indication IE.


29/72





Mode #3 CSFB detection is based only on the CSFB indication IE, the detection

method from 134661 is not used at all, which means that if the CSFB indication IE is

not included in the RRC Connection Request, the UE is not sent back to LTE at CS

speech call completion.

Besides this feature introduces:

new counters for

o redirection based CSFB attempt/success/cancel

o number of CS calls drop after redirection based CSFB

new screening for

o CSFB detection in RRC Connection

FEATURE BENEFITS

Avoid sending back to LTE Rel-9 UEs onward which have been re-directed due to LTE

offloading as well as improved Fast Return to LTE performance monitoring.

IMPACTED SYSTEMS

RNC, OAM

DEPENDENCIES

Hardware


Support S S S


Software feature

134661 Redirection to LTE at CS speech call completion [R8]: refer toConfiguration Management and Parameters section below.


UE shall support CSFB Indication IE.

Standards

June12 3GPP (Rel-9 CR 5026 in 25.331) has introduced the capability for a UEto indicate that the connection request is due to CSFB.


None

ENGINEERING IMPACTS

None


Counters

Total number of CS fallback detected in the RRC connection


30/72





Attempted RAB Establishment of CS call (conversational/speech) after CSFB

detection in RRC Connection or in relocation request (with cause: "CS Fallback

triggered")

Successful RAB Establishment of CS call (conversational/speech) after CSFB


triggered")

Cancelled Establishment of the first CS call (conversational/speech) after CSFB


triggered")

Dropped UTRAN Initiated first CS Voice RAB (conversational/speech) Connections

after CSFB detection in RRC Connection or in relocation request (with cause: "CS

Fallback triggered")

Dropped first CS Voice RAB (conversational/speech) due to UE Initiated Signalling

Connection Release after CSFB detection in RRC Connection or in relocation request(with cause: "CS Fallback triggered").

Dropped first CS Voice RAB (conversational/speech) abnormally released due to MSC

initiated failure after CSFB detection in RRC Connection or in relocation request

(with cause: "CS Fallback triggered")


csfbDetectionMethoddefines the way CSFB from LTE is detected in the RNC during

the RRC connection request, it can be set to 3 values as follows:

csfbDeduction - CSFB detection deduced from the fact that the UE is

coming from LTE (solution introduced by feature 134661 [R8]).

csfbDeductionAndIndication- CSFB detection according to UE release, i.e.

for UE below Rel-9, deduced from the fact that the UE is coming from LTE

(solution introduced by feature 134661 [R8]),for rel-9 UE onward, based on

CSFB Indication IE.

csfbIndication- CSFB detection according to CSFB Indication IE.


None

FEATURE TYPE

Optional


FEATURE DESCRIPTION

The US 700 MHz band plan defines overlapping FDD Band 12 and FDD Band 17 in the lower 700

MHz band, as shown in the figure below.


31/72





Figure 5 : US 700 MHz band plan

Multi-Frequency Band Indicator (MFBI) feature, which was standardized in 3GPP Rel-8 for LTE

and in Rel-10 for WCDMA, permits LTE networks to operate simultaneously as both a Band 12

and Band 17 network and to support devices in both bands.

LTE System Information blocks have been modified to allow a network to signal up to 8

additional frequency band indicators in a cell. As a result, UEs of different but overlapping

bands are allowed to camp and operate on the same cell. For instance, Band 12 MFBI capable

UE can access network only supporting Band 17, since eNode B will broadcast Band 17 and

Band 12 frequency band indicator.

Feature 176914 in WCDMA allows inter-RAT mobility to LTE band 17 for band 12 MFBI capable

UE without support of 3GPP defined MFBI in UTRAN. It consists in adding by configuration

Band 12 Frequency Channel Number (eARFCN) to SIB19 (cell re-selection) as well as to the

RRC Connection Release message (RRC re-direction) in addition to Band 17.

FEATURE BENEFITS

Ensure Band 12 MFBI UE also capable of operating in Band 17 can do cell reselection to LTE or

can be redirected to LTE.

IMPACTED SYSTEMS

RNC

DEPENDENCIES

Hardware


Support S NS S


Software feature

UMTS to LTE cell re-selection (81436 [R7]/108661 [R8])

UMTS to LTE re-direction:

At Speech call completion (134661 [R8]/170715)

On Always-On downsize (89858 [R8])

At RRC connection request (89857 [R8])


Band 12 UE shall be MFBI capable

Standards

None


32/72






None

ENGINEERING IMPACTS

NoneOPERATIONAL REQUIREMENTS

Counters

None


Band 12 eARFCN has to be configured in addition to Band 17.


None

FEATURE TYPE

Optional

5.5 TRANSPORT AND TRANSMISSION CAPABILITIES

126921 DSCP Marking Enhancements

FEATURE DESCRIPTION

This feature increases the range of DSCP values supported in the RNC and Node-B (OneBTS).

For the OneBTS, the feature also introduces the possibility to assign different DSCP values and

configurable traffic shaping parameters for different types of OAM traffic flows (CM&FM data,Traces, PM data).

On the RNC, DSCP values are configured per interface, or mapped per IP flow using the

TransportMap and the expected PHB received from the CN. The interfaces on the RNC are:

Itf-r (oam interface to OMC-R)

o DCSP DE is used for OAM traffic - not configurable.

o There are no changes with this feature.

Iub Cplane/Uplane

o The DSCP values for IuB CP traffic flows is done in object Nodeb MO with theparameter sctpParameters/sctpDscp

o The DSCP values for IuB UP traffic flows is done in component RncIn

TransportMap TransportServiceEntry with the parameter Rncin TM TSE

diffServCodePoint(dscp)

o The DSCP values allowed for these parameters are:

default, ef, cs7, cs6, cs5, cs4, cs3, cs2, cs1, af11, af12, af13, af21,

af22, af23, af31, af32, af33,af41, af42,af43

o This feature will test cs4 in conjunction with OneBTS Node-B (support of DSCP

= cs4 is new on the OneBTS)


33/72





Iu-CS Cplane/Uplane

o The DSCP values for Iu-CS CP traffic flows is done in component Ss7 Sctp

SrcEp with parameter Ss7 Sctp SrcEp diffServCodePoint(dscp)

o The DSCP values for Iu-CS UP traffic flows is done in component RncInTransportMap TransportServiceEntry with the parameter Rncin TM TSE





o There are no changes with this feature. Usage of cs4 for Iu-CS control plane is

explicitly tested with this feature.

Iur Cplane/Uplane

o The DSCP values for IuCS Iur CP traffic flows is done in component Ss7 Sctp


o The DSCP values for IuB Iur UP traffic flows is done in component RncIn

TransportMap TransportServiceEntry with the parameter Rncin TM TSE





o There are no changes with this feature. Usage of cs4 for Iur control plane is


Iu-PS Cplane/Uplane

o The DSCP values for IuCS IuPS CP traffic flows is done in component Ss7 Sctp


o The DSCP values for IuPS UP traffic flows is done in object

PsCoreNetworkAccess MO with the parameter dscpPerTrafficClass/dscp




o There are no changes with this feature. Usage of cs4 for Iu-PS control plane is


Iu-PC

o The DSCP values for IuCS Iu-PC CP traffic flows is done in component Ss7 Sctp



34/72








o There are no changes with this feature. Usage of cs4 for Iu-PC plane isexplicitly tested with this feature.

Iu-BC and Others

o For Iu-BC, FACH for MBMS streaming uses AF41 and FACH for MBMS background

uses AF23.

In previous releases, on the NodeB (OneBTS) the implementation is the following:

On Iub UP (uplink), the DSCP is set by the NodeB, which uses the DSCP value indicatedby the RNC in the NBAP message

For the other flows (Iub CP and OAM), the DSCP is configured and selected from a set

of 17 values (dE, aF11, aF12, aF13, aF21, aF22, aF23, aF31, aF32, aF33, cs4, aF41,

aF42, aF43, eF, cS6, cS7). The list of flows is the following:

o attachTraffic

o nbapTraffic

o ptpHighPriorityTraffic

o ptpLowPriorityTraffic

o ntpTraffic

o oamTraffic

The mapping of the DSCP to emission queues is done on the Ethernet Backhaul Port

object, with the dscpToEp parameter, which defines the mapping table from DSCP

QoS class (first 3 bits of the 6 bits DSCP) to Emission Priority (EP). The Range allowed

for the priority queues is eP0, eP1, eP2, eP3, eP4, eP5, eP6, eP7

The mapping of the DSCP to L2 pbit is done on the Ethernet Backhaul Port object,

with the dscpToPBit parameter, which defines the mapping table from DSCP QoS class

(first 3 bits of the 6 bits DSCP) to p-bit (level 2 QoS). The 8 pbit values are

supported: bestEffort(0), background(1), spare(2), excellentEffort(3),

controlledLoad(4), video(5), voice(6), networkControl(7)

The OneBTS Performs Uplink Scheduling and Traffic shaping according to the following

principles:

o Done per VLAN with 8 Ip Traffic Shaping queues (defined with CIR, PIR, )

o Ulbandwidth parameter (on Ethernet Backhaul Port) defines the UL bandwidth

available on Iub

The OAM and PTP bandwidth are hardcoded for some Vlans configurations


35/72





The scheduler implements a strict priority order is respected between the 8 Emission

Priority queues up to the CIR allocated to each one.

Between CIR and PIR, all Emission Priority queues are also emptied according to their

respective priority but in a second step (only when the 8 queues have been emptied

according to their CIR)

OAM and PTP CIR/PIR are hardcoded for some Vlans configurations

Figure 6 : Example of uplink traffic shaping with 3 VLANs with the LR13W implementation

With this feature the following Enhancements are implemented on the Node-B

Node-B (OneBTS) will also support the usage of CS4 (DSCP=32) in the Iub/Itf-b

interface

The current oamTraffic category is split in 3 new categories each allowed to have a

configurable DSCP setting. The new OAM traffic categories are:

o oamCmFmTraffic for Configuration Management and Fault Management

Traffic

o oamTraceTraffic - for Traces

o oamFileTransferAndMonitoringToolsTraffic For Performance Management

and other file transfers

The Node-B UL traffic shaping function / scheduler allows user configurable

parameters (CIR/PIR/bandwidth) for OAM and PTP traffic (currently hardcoded)


36/72





Figure 7 : Example of uplink traffic shaping in a OneBTS with 3 VLANs with the feature126921 Implementation

FEATURE BENEFITS

This feature allows the customer a finer granularity in the differentiation of the traffic flows.

This enables more control of the QoS behavior of the transport network during congestion

situations.

This feature helps to increase user QoS experienced by the end user as, during congestion

periods, it gives more flexibility for the transport to provide different QoS treatment to be

given for traffic flows with different priority levels.

IMPACTED SYSTEMS

Node B, RNC

DEPENDENCIES

Hardware


Support S NS S


Software feature

None

A1 A A3 A2

3 3

0

C7

C

0%

0%

1

C 6

C

15%

1 00%

2

C

15 %

100 %

3

A4

C

2 0%

5 0%

4

A3

C

2 0%

5 0%

5

A2

C

2 0%

2 0%

6

A1

C

5%

5 %

7

D

C

5%

5%

0

C 7

C

60%

100%

1

C 6

C

40%

60%

2

C

10 %

100 %

3

41

C

5 0%

1 00%

3

A : D C=D => 7

: DC=A31 => 4

: DC=C7 => 0

: DC=C6 => 1

* A +

C

B A (128 /)

B (8 /)

B

(8 /)

BA

.A

B99

.99

C

C

C

6

1 1

C

40 %

100 %

*

A

(128 /)


37/72






For Iur, Iu-CS, Iu-PS, Iu-PC, Iur the DSCP values to be configured must besupported on the peer nodes.

Standards

None


Feature applicable to Full IP Node-Bs

ENGINEERING IMPACTS

New DSCP and Node-B Traffic Shaping settings to be defined


Counters

No new counters are needed for this feature, as existing counters will continue to

work the same way.


The ranges are extended for the following Node-B parameters:

QosDscpValues/attachTraffic,

QosDscpValues/nbapTraffic,

QosDscpValues/ntpTraffic,

QosDscpValues/ptpHighPriorityTraffic

QosDscpValues/ptpLowPriorityTraffic.

The parameter QosDscpValues/oamTraffic is removed and replaced by:

oamCmFmTraffic,

oamTraceTraffic,

oamFileTransferAndMonitoringToolsTraffic.

The following object is removed: IpTrafficShapingQueue

The following objects are created, with the same properties as

IpTrafficShapingQueue:

IpTrafficShapingQueueVI1



They are defined with the following parameters:

cbs

cir

congestionEnd

congestionStart


38/72





maxDelay

mbs

pir

queueEnabled

Each of the parameter of the objects IpTrafficShapingQueueVIx (i.e. cbs, cir,

congestionEnd, congestionStart, maxDelay, mbs, pir, queueEnabled) keeps the

existing definition.

The EthernetBackhaulPort parameters are modified as follow:

ulBandwidth parameter is removed,

ipTrafficDescriptorVI1 parameter is added,

ipTrafficDescriptorVI2 parameter is added,

ipTrafficDescriptorVI3 parameter is added.

ipTrafficDescriptorVI1, ipTrafficDescriptorVI2 and ipTrafficDescriptorVI3 are defined

with a structure composed of:

ulBandwidth, to indicate the bandwidth,

trafficType to indicate the type of traffic supported. The value of

trafficType can be one of the the following values: notUsed, oamTraffic,

telecomTraffic, ptpTraffic, oamPtpTraffic, telecomOamTraffic,

telecomOamPtpTraffic.

TrafficType Access Right is RO-SC (Read Only Set on Create), default value

is notUsed.


On the Node-B, existing alarm localConfigurationFailure alarm of MO IPIubInterface

is used to indicate mismatch configuration.

FEATURE TYPE

Optional

5.6 OPERATIONAL EFFECTIVENESS

121555 LR14.2W RNC Counters EvolutionFEATURE DESCRIPTION

This feature introduces new RNC counters and other improvements to the existing base,

focusing on customer requirements and other enhancements to improve monitoring and

troubleshooting capabilities.

Specifically, the following counters are introduced:

Multi RAB: VS_MultiRAB_DropsWithAMRRate_DueToSRB and

VS.MultiRAB.DropsWithAMRRate.DueToPs: The number of successfully established

Multi-RAB calls that are subsequently dropped abnormally due to signaling radio

bearer failure (DueToSRB) or to PS (DueToPS).


39/72


40/72





o CS Codec 1 MM-MR 5.9 + 1 or more [PS HSDPA / E-DCH TTI 10ms]




Voice quality estimate (VS.VoiceQualityEstimate). This counter provides voice

Quality Estimate value reported in each UL FP Frame. The following screening are

supported per AMR rate:

o AMR WB 12.65

o AMR NB 12.65

o AMR WB Multirate ( 8.85, 6.60)

o AMR NB Multirate (10.2, 7.95, 7.4, 6.7, 5.9, 5.15, 4.75)

Number of RABs setup with HSDPA Dual Cell.

o VS.RAB.AvgNumEstab.MultiCell : Indicates the average number of Multi-Cell

RABs established per cell.

This counter is incremented / decremented every time a Multi-cell RAB is

established, released, reconfigured, there is a change of primary cell change

or relocation.

o VS.UEStateTransAtt.HsdpaMultiCell: number of Attempted UE State

Transitions where the UE is eligible for HSDPA Multi-cell

o VS.UEStateTransSucc.HsdpaMultiCell : number of Successful UE State

Transitions where the UE is Eligible to be setup as HSDPA Multi-cell

o VS.RAB.AttEstab.HsdpaMultiCell: number of Attempted RAB Setups with

HSDPA Multi Cell

o VS.RAB.SuccEstab.HsdpaMultiCell: Pegged per PS RAB Id listed in a "RAB

Assignment Response" message being sent from the SRNC to the CN indicating

successful Multi-cell RAB Establishment.

To be pegged on the same cell as the related attempt was pegged with

VS.RAB.AttEstab.HsdpaMultiCell

New State Transistion Cancel counters

Improve the precision of the KPI for PCH to DCH success rate. It is now possible to

remove canceled attempt.

o VS.UEStateTransCancel.UraPCH_CellDCH.DCH_HSDSCH pegs the number of

cancelled state transitions from URA_PCH state to DCH_HSDSCH when a UE is

performing Inter-RNC mobility and the SGSN sends the RNC an Iu-Release

command with the cause UEGSCR, due to cell re-selection.

o VS.UEStateTransCancel.PCH_CellDCH.EDCH_HSDSCH: pegs the number of

cancelled state transitions from PCH to E-DCH / HS-DSCH when a UE is


command with the cause UEGSCR, due to cell re-selection


41/72





o VS.UEStateTransCancel.UraPCH_CellDCH.DCH_HSDSCH pegs the number of

cancelled state transitions from URA_PCH state to DCH_HSDSCH when a UE is


command with the cause UEGSCR, due to cell re-selection.

FEATURE BENEFITS

Enhancement of the counter based monitoring and troubleshooting solution, enabling

additional metrics and improving thus the OPEX for network monitoring and troubleshooting.

IMPACTED SYSTEMS

Node B, RNC, OAM (WMS, NPO and Customers Performance Reporting system)

DEPENDENCIES

Hardware


Support S S S


Software feature

None


None

StandardsNone


None

ENGINEERING IMPACTS

Performance Monitoring Metrics


Counters

See feature descriptionConfiguration Management and Parameters

None


None

FEATURE TYPE

Base


42/72





5.7 NODE B EVOLUTIONS

112527 Defense against PA failure in parallel x2PAM configurations

FEATURE DESCRIPTION

A mechanism to detect failure of a paralleled RF PA (x2PAM or HE PAM) within a OneBTS 9391

Macrocell, and to manage the PA and Node B to maintain effective service (at reduced

capacity) until the failed PA can be replaced.

OneBTS 9391 Macrocells can use paralleled RF PAs when supporting multi-carrier

configurations. Currently, if a PA should fail, all carriers supported by the parallel PA group

will fail, and this could be the entire sector. This feature provides a mechanism to manage

the failed PA and to maintain service - at a reduced level - with the remaining PA(s).

For example, in a 3 sector 2 carrier 1900MHz 9391 Macrocell using 1 MCR per sector, assuming

each sector has two paralleled p2PAMs. Before the introduction of this feature, if a PA in this

sector fails the entire Tx Path becomes disabled and service for the entire sector is lost. Withthis feature, one of the two sector-carriers will be dropped and one will be retained with a

reduced power.

On the RNC side, if a sector-carrier is dropped by the OneBTS the corresponding FDDCell will

go operationalStatedisabled. If a sector-carrier is retained by the OneBTS, the corresponding

FDDCell on the RNC will remain operationalState enabled, and, depending on the power

budget for that FDDCell (and the setting of its ac

Date post:	02-Jun-2018
Category:	Documents
Upload:	gauravswami
View:	220 times
Download:	0 times

LR14W_V1_UMTS Access Network - Feature Planning Guide LR14

Documents