LR14W - V1 - UMTS Access Network - Feature Planning Guide LR14

UMTS ACCESS NETWORK
F E A T U R E P L A N N I N G G U I D E L R14
UMT/SYS/INF/041185
STANDARD, EXTERNAL
V01.07/EN
30/JUN/2014
LR14 UMTS ACCESS NETWORK FEATURE PLANNING GUIDE
30/JUN/2014
Copyright 2014 by Alcatel-Lucent Technologies. All Rights Reserved.
About Alcatel-Lucent
Alcatel-Lucent (Euronext Paris and NYSE: ALU) provides solutions that enable service
providers, enterprises and governments worldwide, to deliver voice, data and video
communication services to end-users. As a leader in fixed, mobile and converged broadband
networking, IP technologies, applications, and services, Alcatel-Lucent offers the end-to-end
solutions that enable compelling communications services for people at home, at work and on
the move. For more information, visit Alcatel-Lucent on the Internet: http://www.alcatellucent.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 recommend
that on a bi-monthly basis you obtain the latest version of this document from your AlcatelLucent representative.
Trademarks
The following trademarks are used throughout this document:
Alcatel-Lucent, Alcatel, Lucent Technologies and their respective logos are trademarks and
service marks of Alcatel-Lucent, Alcatel and Lucent Technologies.
Sun, Sun Microsystems, the Sun Logo, Java and all Java-based trademarks and logos are
trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other
countries.
Microsoft, Microsoft Internet Explorer logo, Microsoft Office Compatible logo, NetMeeting,
Outlook, PowerPoint, Visio, Visual Basic, Windows, Windows logo, Windows NT, and/or other
Microsoft products referenced are either registered trademarks or trademarks of Microsoft
Corporation in the U.S. and/or other countries
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/INF/041185
Alcatel-Lucent Confidential & Proprietary

V01.07/EN
Standard, External
Page 2 of 72
30/JUN/2014
PUBLICATION HISTORY
JUNE 30TH 2014 - 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 9926

digital
170506 Support of DC-HSDPA with Multiple RRH per cell
JUNE 11TH 2014 - ISSUE 01.06 / EN, Draft, Internal

Internal version for review
MARCH 31ST 2014 - ISSUE 01.05 / EN, Standard, External
Updated 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) and
enhancement
Removal of features:
100894 UMTS to LTE PS HO
MARCH 17TH 2014 - ISSUE 01.04 / EN, Draft, Internal

OCTOBER 15TH 2013 - ISSUE 01.03 / EN, Preliminary, External
Preliminary version for external distribution.
SEPTEMBER 9TH 2013 - ISSUE 01.02 / EN, Draft, Internal
JULY 19TH 2013 - ISSUE 01.01 / EN, Draft, Internal
Document creation
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 3 of 72
30/JUN/2014
CONTENTS
1
INTRODUCTION ................................................................................................ 6
1.1
1.2
1.3
1.4
OBJECT ....................................................................................................... 6
SCOPE OF THIS DOCUMENT .................................................................................... 6
FEATURES LISTS .............................................................................................. 7
AUDIENCE..................................................................................................... 8
RELATED DOCUMENTS ........................................................................................ 9

2.1
2.2
APPLICABLE DOCUMENTS ...................................................................................... 9

REFERENCE DOCUMENTS ...................................................................................... 9
LR14.2W MAIN DRIVERS .................................................................................... 10
LR14.2W OPTIONAL SW PACKAGES ...................................................................... 11
LR14.2W FEATURES......................................................................................... 12
5.1 BASELINE ................................................................................................. 12
168853 LR14.2W 3GPP Baseline .......................................................................... 12
5.2 PERFORMANCES AND CAPACITY ...................................................................... 13
108103 Enhanced CELL_FACH for DL&UL ............................................................... 13
121209 Enhanced UE DRX in CELL_FACH ................................................................ 15
122612 E-DCH performance enhancement .............................................................. 16
163882 F-DPCH Enhancements ........................................................................... 20
165360 Smart E-DCH resource usage - new Market support (939x Node B) ........................ 21
172598 DC-HSDPA functional enhancement ............................................................ 21
5.3 SERVICES AND RADIO RESOURCES MANAGEMENT .................................................. 23
131683 Selective Paging Discard ......................................................................... 23
164968 Support of GLONASS assistance data over IuPC (SAS Centric mode) ....................... 25
168556 Traffic filtering in cell overload - new Market support (939x Node B) and enhancement27
5.4 MOBILITY ................................................................................................. 27
132010 RRC Connection Re-establishment over Iur support .......................................... 27
170715 Fast return to LTE improvement ................................................................ 28
176914 Support of band 12 MFBI capable UE in WCDMA .............................................. 30
5.5 TRANSPORT AND TRANSMISSION CAPABILITIES .................................................... 32
126921 DSCP Marking Enhancements .................................................................... 32
5.6 OPERATIONAL EFFECTIVENESS ....................................................................... 38
121555 LR14.2W RNC Counters Evolution ............................................................... 38
5.7 NODE B EVOLUTIONS ................................................................................... 42
112527 Defense against PA failure in parallel x2PAM configurations ............................... 42
123826 AISG for TRDU60-21B ............................................................................. 44
125616 W-CDMA/LTE dual-technology support by D4U ............................................... 45
127580 CPICH power level reporting correction for oneBTS DAS .................................... 47
132085 3G support of TRDU2x60 900MHz without dependency to 2G............................... 49
162306 Support of VAM on TRDU60-21B ................................................................. 51
163122 RRH2x60-21A operation with 45MHz Instantaneous Bandwidth ............................. 52
166352 3G AISG support on TRDU2x60 900MHz ........................................................ 54
166354 LR Outdoor Battery cabinet ..................................................................... 55
168705 Noise floor self-learning algorithm for oneBTS ............................................... 57
169488 AISG2.0 on 9396-based RRHs Phase 1A ......................................................... 59
170665 TRDU2x80 2100MHz ............................................................................... 61
174085 AISG management enhancements .............................................................. 62
174283 AISG for MC-RRH 3G-only ........................................................................ 63
177111 Digital DAS using Tyco CDIU with WCDMA 9396 digital Phase 2 ............................. 65
5.8 RNC EVOLUTIONS ....................................................................................... 66
134390 9771 Wireless Cloud Element (WCE) RNC .................................................... 66
ABBREVIATIONS AND DEFINITIONS ....................................................................... 69

6.1
ABBREVIATIONS ............................................................................................. 69
FIGURES
FIGURE 1: OPERATION WITH UL CELL LOAD COLOR (PRIOR TO FEATURE INTRODUCTION)................................. 17
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 4 of 72
30/JUN/2014
FIGURE 2: OPERATION WITH ENHANCED UL CELL LOAD COLOR (WITH FEATURE 122612) ................................. 17
FIGURE 3: E-DCH400 CAPACITY TEST RESULTS...................................................................................................... 18
FIGURE 4: GLONASS ASSISTANCE DATA OVER IUPC .............................................................................................. 25
FIGURE 5 : US 700 MHZ BAND PLAN ..................................................................................................................... 31
FIGURE 6 : EXAMPLE OF UPLINK TRAFFIC SHAPING WITH 3 VLANS WITH THE LR13W IMPLEMENTATION ......... 35
FIGURE 7 : EXAMPLE OF UPLINK TRAFFIC SHAPING IN A ONEBTS WITH 3 VLANS WITH THE FEATURE 126921
IMPLEMENTATION........................................................................................................................................ 36
FIGURE 8 : W-CDMA/LTE DUAL-TECHNOLOGY D4U ............................................................................................. 46
FIGURE 9 : LR OUTDOOR CABINET WITH SMALL CABINET ON TOP ...................................................................... 56
FIGURE 10 : TRDU2X80 B1..................................................................................................................................... 61
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 5 of 72
30/JUN/2014
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 WCDMA market. Other Node B means any Node B not part of the 939x portfolio.
RNC 9370
Other Node B
939x Node B
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 6 of 72

Support
S, NS
HW requirements
None, N/A,
required modules
30/JUN/2014
S, NS
None, N/A,
required modules
S, NS
None, N/A,
required modules
"S" on the line "Support" means the feature is supported with the corresponding
product, 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
121555
LR14.2W RNC Counters Evolution
122612
Base or
Optional
Other
Node B
939x
Node B
Base
E-DCH performance enhancement
Optional
131683
Selective Paging Discard
Optional
164968
Support of GLONASS assistance data over Optional

IuPC (SAS Centric mode)
165360
Smart E-DCH resource usage - new

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

Market support (939x Node B)
Optional
168853
LR14.2W 3GPP Baseline
Base
170715
Fast return to LTE improvement
Optional
108103
Enhanced CELL_FACH for DL&UL
Optional
NS
121209
Enhanced UE DRX in CELL_FACH
Optional
NS
123826
AISG for TRDU60-21B
Base
NS
125616
W-CDMA/LTE dual-technology support by Optional

D4U
NS
132085
3G Support of TRDU2x60 900MHz without Base

dependency to 2G
NS
134390
9771 Wireless Cloud Element (WCE) -
NS
Optional
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 7 of 72
1.4
30/JUN/2014
RNC
Hardware
162306
Support of VAM on TRDU60-21B
Base
NS
163122
RRH2x60-21A operation with 45MHz

Instantaneous Bandwidth
Optional
NS
163882
F-DPCH Enhancements
Optional
NS
166352
3G AISG support on TRDU2x60 900MHz
Base
NS
166354
LR Outdoor Battery Cabinet
Optional
Configuration
NS
170665
TRDU2x80 2100MHz
Optional
Hardware
NS
172598
DC-HSDPA functional enhancement
Optional
NS
174085
AISG management enhancements
Base
NS
174283
AISG for MC-RRH 3G-only
Base
NS
112527
Defense against PA failure in parallel Optional

x2PAM configurations
NS
126921
DSCP Marking Enhancements
Optional
NS
127580
CPICH power level reporting correction Optional

for oneBTS DAS
NS
132010
RRC Connection Re-establishment over

Iur support
Optional
NS
168705
Noise floor self-learning algorithm for Optional

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

WCDMA
NS
177111
Digital DAS using Tyco CDIU with WCDMA Optional HW

9396 digital Phase 2
NS
Audience
The primary audience for this document is Alcatel-Lucent customers. This document
is also intended for Alcatel-Lucent functional and operational teams.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 8 of 72
30/JUN/2014
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
[R5]
UMT/SYS/INF/021994
[R6]
UMT/SYS/INF/022664
UA06 Access Network Feature Planning Guide
[R7]
UMT/SYS/INF/025020
UA07 Access Network Feature Planning Guide
[R8]
UMT/SYS/INF/030972
[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
Description
Alcatel-Lucent 939X W-CDMA Node B Family Product
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 9 of 72
30/JUN/2014
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 TRDU2x80

2100MHz
Increased instantaneous bandwidth (45MHz) on RRH2x60-21A for operation over

disaggregated spectrum
UMTS 900MHz for rural coverage/better indoor penetration
Consolidation of U900 coverage configurations with 3G only mode on TRDU2x60

900MHz
Controller Capacity
Wireless Cloud Element (WCE) RNC introduction - RNC application running on IT

platform providing increased and scalable RNC capacity as well as readiness for
future 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 UL and enhanced UE DRX
LTE SUPPORT
Digital Evolution
3G/LTE dual-technology BBU
Complement 3G/LTE mobility features set
Fast return to LTE improvement
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 10 of 72
30/JUN/2014
LR14.2W OPTIONAL SW PACKAGES

A number of LR14.2W features compose the optional SW packages as detailed in the below
table.
ID
Feature Title
122612 E-DCH performance enhancement
131683 Selective paging discard
164968 Support of GLONASS assistance data over IuPC

(SAS centric mode)
170715 Fast return to LTE improvement
108103 Enhanced CELL_FACH for DL&UL
121209 Enhanced UE DRX in CELL_FACH

163122 RRH2x60-21A operation with 45MHz

instantaneous bandwidth
163882 F-DPCH enhancements
172598 DC-HSDPA functional enhancement
112527 Defense against PA failure in parallel x2PAM
configurations
126921 DSCP marking enhancements

127580 CPICH power level reporting correction for
OneBTS DAS
132010 RRC connection re-establishment over Iur

support
168705 Noise floor self-learning algorithm for OneBTS
169488 AISG2.0 on 9396 based RRHs Phase 1A
SI Code
Saleable Offer
3JR 35055 AF
HSUPA LR14
Mobility &
Performance
Features
3JR 35040 AE RNC Paging
overload
management
3JR 35010 AD Advanced Location
Services
3JR 35033 AE Mobility to LTE
3JR 35053 AF
Enhanced
CELL_FACH for
Smartphones
3BK 33994 AA WCDMA/LTE dualtechnology support

by D4U
3BK 33993 AA RRH RTU 45MHz
iBW unlock
3JR 35029 AE Smartphone
experience
3JR 35009 AD End user Mobility
Improvement
3BK 33992 AA Defense against PA
failure in parallel
x2PAM
configurations
3JR 35052 AF Quality of Service
differentiation
3BK 33991 AB CPICH power level
reporting
correction for
oneBTS DAS
3JR 35006 AD Mobility & Traffic
Balancing
3BK 33991 AA Noise floor selflearning algorithm
for OneBTS
3BK 33991 AC RRH AISG2.0 on
digital 9396
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 11 of 72
30/JUN/2014
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
RNC 9370
Other Node B
939x Node B
Support
HW requirements
None
None
None
Software feature
No dependency. On the contrary, this feature is an input to all the LR14.2W
features 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 interoperability
programs setup by Alcatel-Lucent.
Standards
By definition, this feature depends on 3GPP specifications, especially on 3GPP
specifications for external interfaces.
RESTRICTION/LIMITATION
None
ENGINEERING IMPACTS
None
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 12 of 72
30/JUN/2014
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&UL

FEATURE 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
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
eCEM(-U)
N/A
Software feature
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 13 of 72
30/JUN/2014
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 HSDSCH)
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, ERGCH/E-HICH, F-DPCH.
Common E-DCH resources are taken from existing CELL_DCH dedicated E-DCH
resource.
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 is
already 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 Rel7 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
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 14 of 72
30/JUN/2014
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
RNC 9370
Other Node B
939x Node B
NS
Support
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
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 15 of 72
30/JUN/2014
One new counter is added to count the number of MAC PDUs which are dropped by
NodeB due to either discardTimer expiry or timerT1 expiry 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 normal
operation 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).
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.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 16 of 72
30/JUN/2014
Figure 1:: Operation with UL cell load color (prior to feature introduction)
Figure 2:: Operation with enhanced UL cell load color (with feature 122612)
Note: The load line should always be less than 1 by definition, even in overload situations.
Introduction of E-DCH400
E
- This
his corresponds to a new approach for E-DCH. Classical
E-DCH
DCH targets very high UL bit rates, however, load situation almost never permits
permit
offering these maximum rates. Furthermore, many applications, due to their
primarily DL-oriented
oriented throughput and/or their burstiness, provide only marginal
margina QoE
improvement (if any), when served with a high UL bit rate. Classical E-DCH
E
can then
sometimes turn out to be a waste of resources. Tests have shown that E-DCH
E
is more
costly than R99 in terms of UL Load at equivalent throughput for low bit rates (e.g.
(e.g 32
au
UMT/SYS/INF/041185

V01.07/EN
/EN
Standard, External
Page 17 of 72
30/JUN/2014
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 R99
even 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 EDCH 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).
Cell Throughput
Non EDCH load

60
2000
eDCH 400k 10ms
1800
eDCH 400k 10ms
Classical eDCH 10ms
50
1400
Non EDCH load (%)
Cell Throughput (kbps)
1600
1200
1000
800
600
400
Classical eDCH 10ms
40
30
20
10
200
0
5 UEs
10 UEs
15 UEs
20 UEs
5 UEs
10 UEs
15 UEs
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
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 18 of 72
30/JUN/2014
Hardware
RNC 9370
Other Node B
939x Node B
Support
HW requirements
None
None
None
Software feature
25080 - QoS differentiation based on TC, ARP and THP [R4]: if the operator
wants that calls can benefit from classical E-DCH, feature 25080 must be
activated.
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
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 19 of 72
30/JUN/2014
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 FDPCH 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 FDPCH activation level for Rel-7 & Rel-8 devices.
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
NS
Support
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.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 20 of 72
30/JUN/2014
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 DESCRIPTION
This 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 DualCarrier 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.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 21 of 72
30/JUN/2014
IMPACTED SYSTEMS
Node B, RNC, OAM
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
Capacity increase to N/A

80 Mbit/s: eCEMu
Max number of DCusers: eCEM/eCEMu
AO upsize: x and eCEM(u)
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.
Standards
3GPP 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
None
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 Multicell.
Number of Attempted iMCTA redirection during AO upsizing for traffic Resume, with
screening for DCH, SC and DC.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 22 of 72
30/JUN/2014
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) pagingdiscard-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
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 23 of 72
30/JUN/2014
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
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
Support
HW requirements
None
None
None
Software feature
127550/168556 Traffic Filtering in cell overload [R9]
98448 - Access Class Barring (ACB) at Cell Granularity [R9]
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)
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 24 of 72
30/JUN/2014
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 Centric

mode)
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.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 25 of 72
30/JUN/2014
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
RNC 9370
Other Node B
939x Node B
Support
HW requirements
None
None
None
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
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 26 of 72
30/JUN/2014
168556 Traffic filtering in cell overload - new Market support (939x Node
B) 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.
RNC/Node B detected
UE in CELL_DCH
Old PRL on
New PRL on
UE detected
RLC
Radio Link
RLC
Radio Link
unrecoverable
Failure
unrecoverable
Failure
error
error
SRNC
DRNC
DRNC
DRNC
DRNC
SRNC
FEATURE BENEFITS
Reduce CS call drop rate in case of failures (RL failure or RLC unrecoverable Error) during Iur
mobility.
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
Support
RNC 9370
Other Node B
939x Node B
NS
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 27 of 72

HW requirements
None
N/A
30/JUN/2014
None
Software feature
33821 - RRC Connection Re-Establishment [R6]
34290 - RRC Connection Re-Establishment for CS [R6]
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.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 28 of 72
30/JUN/2014
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
number of CS calls drop after redirection based CSFB
new screening for

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
RNC 9370
Other Node B
939x Node B
Support
HW requirements
None
None
None
Software feature
134661 Redirection to LTE at CS speech call completion [R8]: refer to
Configuration 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 UE
to indicate that the connection request is due to CSFB.
None
ENGINEERING IMPACTS
None
Counters
Total number of CS fallback detected in the RRC connection
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 29 of 72
30/JUN/2014
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")
csfbDetectionMethod defines 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.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 30 of 72
30/JUN/2014
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
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
N/A
None
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
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 31 of 72
30/JUN/2014
None
ENGINEERING IMPACTS
None
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.
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 the
parameter sctpParameters/sctpDscp
The DSCP values for IuB UP traffic flows is done in component RncIn
TransportMap TransportServiceEntry with the parameter Rncin TM TSE
diffServCodePoint(dscp)
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
This feature will test cs4 in conjunction with OneBTS Node-B (support of DSCP
= cs4 is new on the OneBTS)
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 32 of 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)
The DSCP values for Iu-CS UP traffic flows is done in component RncIn

Iur Cplane/Uplane
o
The DSCP values for IuCS Iur CP traffic flows is done in component Ss7 Sctp
The DSCP values for IuB Iur UP traffic flows is done in component RncIn
There are no changes with this feature. Usage of cs4 for Iur control plane is
explicitly tested with this feature.
Iu-PS Cplane/Uplane
o
The DSCP values for IuCS IuPS CP traffic flows is done in component Ss7 Sctp
The DSCP values for IuPS UP traffic flows is done in object

PsCoreNetworkAccess MO with the parameter dscpPerTrafficClass/dscp

There are no changes with this feature. Usage of cs4 for Iu-CS control plane is
30/JUN/2014
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
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 33 of 72

o

30/JUN/2014
There are no changes with this feature. Usage of cs4 for Iu-PC plane is
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 indicated
by 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
nbapTraffic
ptpHighPriorityTraffic
ptpLowPriorityTraffic
ntpTraffic
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:
Done per VLAN with 8 Ip Traffic Shaping queues (defined with CIR, PIR, )
Ulbandwidth parameter (on Ethernet Backhaul Port) defines the UL bandwidth

available on Iub
The OAM and PTP bandwidth are hardcoded for some Vlans configurations
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 34 of 72
30/JUN/2014
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

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:
the usage of CS4 (DSCP=32) in the Iub/Itf-b
oamCmFmTraffic for Configuration Management and Fault Management

Traffic
oamTraceTraffic - for Traces
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)
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 35 of 72
30/JUN/2014
VLAN1 OAM
VLAN3 PTP
VLAN2
Telecom
Layer 3 classifier
Layer 3 classifier
Layer 3 classifier
E P6
EP3
EP2
EP 0
E P1
EP0
EP 1
E P2
EP3
EP4
EP5
EP 6
EP7
af1 1
af 41
ef
C S7
C S6
CS7
CS 6
EF
AF4
AF3
AF2
A F1
DE
ci
ff
ar
TP
Lp
tp
C IR
0%
C IR
15%
CIR
15 %
C IR
2 0%
C IR
2 0%
C IR
2 0%
CIR
5%
CIR
5%
P IR 0%
PIR
1 00%
PIR
100 %
P IR
5 0%
P IR
5 0%
P IR P IR 5 % PIR 5%
2 0%
gn
il
an
gi
S
C
R
R
icff
rat
ap
b
n
r*e
th
O
m
ao
e
l
b
ar
u
gi
f
n
o
C
CIR
40 %
icf
fa
rT
P
H
p
tp
icf
fa
rt
P
TN
m
F
m
C
m
a
o
C IR
5 0%
CIR
10 %
PIR
P IR
100 % 1 00%
PIR
100 %
OAM bandwith
(128 kbit/s )
le
b
ar
gu
if
n
o
C
Priority link sharing

scheduling
CIR
60%
CIR
40%
PIR
100%
PIR
60%
n
o
m
m
o
C
lse
n
n
ah
C
icf
rat
h
ca
tta
9
9
R
t.n
I
9
9
R
kc
aB
A
SP
H
.t
In
A
P
S
H
kc
aB
PTP BW
(8 kbi t/s)
ulBandwi dth OAM bandwith (128 kbit/s)

PTP BW (8 kbit/s)
Priority link shari ng

s cheduling
Priorityl ink sharing scheduli ng
Ethernet port
OAM traffic: DSCP=DE => EP7

ntpTraffic: DSCP=AF31 => EP4
ptpHighPri orityTraffic: DSCP=CS7 => EP0
ptpLowPriorityTraffi c: DSCP=CS6 => EP1
* OamOther means oamFileTransferAndMonitoringToolsTraffic+ oamTraceTraffic
Figure 7 : Example of uplink traffic shaping in a OneBTS with 3 VLANs with the feature
126921 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
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
N/A
None
Software feature
None
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 36 of 72
30/JUN/2014

For Iur, Iu-CS, Iu-PS, Iu-PC, Iur the DSCP values to be configured must be
supported 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
IpTrafficShapingQueue:
are
IpTrafficShapingQueueVI1
created,
with
the
same
properties
as
They are defined with the following parameters:
cbs
cir
congestionEnd
congestionStart
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 37 of 72
maxDelay
mbs
pir
queueEnabled
30/JUN/2014
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 Evolution

FEATURE 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).
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 38 of 72
30/JUN/2014
Note: VS.MultiRAB.DropsWithAMRRate.DueToCs exists since LR13.3W.

Screenings are classified by mode, codec, and DL max rate of a CS AMR RAB, with PS
RAB(s) on different transport channel(s):
o
CS SM-SR 12.2 + 1 or more [PS 0/0 Kbps]
CS Codec 1 MM-MR 12.2 + 1 or more [PS 0/0 Kbps]
CS SM-SR 12.2 + 1 or more [PS DCH / DCH]
CS Codec 1 MM-MR 12.2 + 1 or more [PS DCH / DCH]
CS SM-SR 12.2 + 1 or more [PS HSDPA / PS DCH]
CS Codec 1 MM-MR 12.2 + 1 or more [PS HSDPA / PS DCH]
CS SM-SR 12.2 + 1 or more [PS HSDPA / E-DCH TTI 2ms]
CS Codec 1 MM-MR 12.2 + 1 or more [PS HSDPA / E-DCH TTI 2ms]
CS SM-SR 12.2 + 1 or more [PS HSDPA / E-DCH TTI 10ms]
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 39 of 72
30/JUN/2014
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
AMR NB 12.65
AMR WB Multirate ( 8.85, 6.60)
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.
VS.UEStateTransAtt.HsdpaMultiCell: number of Attempted

Transitions where the UE is eligible for HSDPA Multi-cell
UE
State
VS.UEStateTransSucc.HsdpaMultiCell : number of Successful UE

Transitions where the UE is Eligible to be setup as HSDPA Multi-cell
State
VS.RAB.AttEstab.HsdpaMultiCell: number of Attempted RAB Setups with

HSDPA Multi Cell
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.
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
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 40 of 72
30/JUN/2014
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
RNC 9370
Other Node B
939x Node B
Support
HW requirements
None
None
None
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
Performance Monitoring Metrics
Counters
See feature description
None
None
FEATURE TYPE
Base
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 41 of 72

5.7
30/JUN/2014
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. With
this 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 operationalState disabled. 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 activityFactor) may or may not go
availabilityStatus degraded, in either case still providing service.
For configurations with multiple MCRs/ sector, service remains fully supported for PAs not
paralleled to the failed PA.
Available Power figures after PA failure for 40W X2PAMS:
During amplifier failure scenarios, the loss of power is non-linear. (e.g. if one amp out of two
fails, more than 50% of the power is lost. The figures below were obtained using 40W x2PAM
amplifiers.
1 out of 3 amps fail (3 sector-carriers):
44.54 % of original power pool available, implying a 3.5 dB reduction in power,
i.e. remaining total power available is 53 Watts, implying
18 watts per sector-carrier, if all three carriers are kept in service.
12.6 % of original power pool available, implying 9dB reduction in power,
i.e. remaining total power available is only 15 Watts, implying
5W watts per sector carrier would available, if all 3 sector-carriers were kept in
service, 7.5 Watts per sector-carrier if 2 sector-carriers were kept in service, both of
which are untenable so need to drop two sector-carriers leaving a single sector carrier
at 15 Watts in service.
25% of original power pool available, a 6 dB reduction in power
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 42 of 72
30/JUN/2014
10 watts per sector-carrier, if both carriers are kept in service, however to favour
coverage over capacity it is better to drop one sector-carrier leaving a single sectorcarrier of 20 Watts kept in service.
All 2 or 3 parallel amps fail:
zero power available, related cells/sector-carriers taken out of service.
Available Power figures after PA failure for 60W HEPAMS:

The losses during failure of HEPAMS are the same as above in percentage/dB terms, relative
to the higher power of the HEPAM amplifier. The degradation of the remaining good
amplifier(s) is due to the attenuation in the splitter/combiner which should remain a constant
in percentage terms, regardless of amplifier type. Thus the figures for HEPAMs are inferred as
follows (assuming 60W HEPAMs):
44.5 % of maximum theoretical power pool available (a 3.5 dB reduction)
27 Watts per sector carrier if all three sector carriers are kept in service, which is
acceptable.
2 out of 3 amps fail (3 sector carriers):
12.6% of maximum theoretical power pool available (a 9dB reduction)
i.e. total remaining power available is 22.7 Watts, implying
7.6 Watts per sector carrier if all 3 sector carriers were kept in place, or 11.3
Watts/sector-carrier if 2 sector-carriers were kept in place, however 11.3 Watts is
too low and to favour coverage over capacity it is better to drop two sector-carriers
leaving one sector-carrier of 22.7 Watts.
1 out of 2 amps fail (2 sector carriers):
25% of maximum theoretical power pool available (a 6 dB reduction)
i.e. total remaining power available is 30 Watts, implying
15 Watts per sector carrier if both sector-carriers were to be kept in service.
All 2 or 3 parallel amps fail:
zero power available, related cells/sector-carriers taken out of service.
FEATURE BENEFITS
This feature increases system availability, providing continuation of service (at reduced
capacity) in the event of hardware failure.
Automatically maintains service at reduced capacity in the event of hardware failure.
Prevents complete loss of the sector and allows the operator to schedule replacement when
convenient.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 43 of 72
30/JUN/2014
IMPACTED SYSTEMS
Node B
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
N/A
9391 macros only
Software feature
None
None
Standards
None
Only applicable to OneBTS 9391 macrocells using paralleled Pas
ENGINEERING IMPACTS
None; the feature only activates under exceptional conditions of hardware failure,
and is only active until the failed hardware is replaced
Counters
None
None
PA hardware failure already raises an alarm
FEATURE TYPE
Base
123826 AISG for TRDU60-21B

FEATURE DESCRIPTION
This feature provides AISG support from WMS using the TRDUs internal AISG controller. This
support is in parity with the AISG support on selected RRHs.
TRDU60-21B includes an internal Smart Bias-T so that AISG signals can be transferred to the
tower-top assets over the antenna feeder. It also includes an AISG connector for those
configurations where a direct cable connection is preferred.
FEATURE BENEFITS
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 44 of 72
30/JUN/2014
AISG allows an operator to remotely monitor and manage TMAs (Tower Mounted Amplifiers)
and RETs (Remote Electrical Tilt for antennas) from WMS and TIL. This means they can make
adjustments and updates without visiting the site, significantly reducing OPEX and increasing
flexibility.
Supporting AISG on TRDU60-21B allows operators to support AISG without external AISG
controllers such as CCU, and brings the management into WMS rather than a separate system.
IMPACTED SYSTEMS
Node B
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
TRDU60-21B
N/A
Software feature
The initial AISG features 33213 AISG for RRH [R7}, 97006 - RETA Tilt
Management (OAM07 feature)
AISG enhancement feature (174085)
AISG devices as IOT
Standards
AISG 2.0
None
ENGINEERING IMPACTS
None
Counters
None
None
None
FEATURE TYPE
Optional

FEATURE DESCRIPTION
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 45 of 72
30/JUN/2014
The target of this feature is the operation of WCDMA and LTE technology in parallel inside a
single d4U subrack. Both technologies are operated independently via their respective OAM
systems.
A LTE NodeB with 1 eCCM2 and up to 3 bCEM can be introduced in a d4u hosting already a
WCDMA NodeB (single controller).
Some possible configurations:
5 carriers WCDMA + 1 band LTE
4 carriers WCDMA + 2 bands LTE
3 carriers WCDMA + 3 bands LTE
Only 1 Iub termination is needed in case of Iub hubbing (100791 [R9]).
Figure 8 : W-CDMA/LTE dual-technology D4U
FEATURE BENEFITS
The availability of this feature allows operators cost effective deployments of WCDMA/LTE
dual technology sites with minimal foot print as well as smooth LTE introduction in existing
WCDMA sites.
IMPACTED SYSTEMS
Node B
DEPENDENCIES
Hardware
RNC 9370
Support
Other Node B
939x Node B
S:
NS
9711 LR ID & 9712

LR OD
PSU MD4 & MD6
HW requirements
None
eCCM-u GigE MDA,

eCEM-u
N/A
Software feature
None
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 46 of 72
30/JUN/2014
None
Standards
None
This feature is only supported by the following modems and controllers:
eCCM-u equipped with GigE MDA
eCEM-u
The feature is not supported on xCCM-u, xCEM-u or eCCM-u with 4E1 MDA.
For information: On LTE side eCCM2 and bCEM are targeted.
The d4U in Dual Technology configuration is not supported in 9100 Ev2 cabinets, nor
9311 ID2/OD2 cabinets
ENGINEERING IMPACTS
None
Counters
None
None
None
FEATURE TYPE
Optional
127580 CPICH power level reporting correction for oneBTS DAS

FEATURE DESCRIPTION
The Primary Common Pilot Channel (P-CPICH) power is used as a reference level in a number
of procedures handled between UE and UTRAN. In particular, the NodeB sends the P-CPICH at
a given power level, and broadcasts that power level (on SIB5). It also broadcasts the current
UL interference level for the cell (on SIB7). The UE measures the power received on P-CPICH
(RSCP), reads in SIB5 information the transmit power level used by the NodeB, and deduces
the experienced path loss. The UE reads the interference level currently experienced by
NodeB in the cell and derives from the path loss and from that information, plus a networkconfigured offset, called constant value, the initial power it should use for its first message
to the UTRAN (RRC Connection Request) on Physical Random Access CHannel (PRACH): this is
the open loop power control mechanism:
Pini(PRACH) = P-CPICH Tx Power - P-CPICH_RSCP + UL_interference + constantValue
The open loop power control mechanism aims at using an initial power level that is not too
high (so that the UE does not create too much interference by its first message), and not too
low (so that the message has a good chance of being received). If the power level is too
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 47 of 72
30/JUN/2014
low, the UE will try again, using a higher power level. Open Loop power control should be
configured such that the number of repetitions is null or low, so that the time to connect is
good for the UE, but the generated interference remains low.
The signal sent by NodeB can however be amplified or attenuated by external systems, such
as a Distributed Antenna System (DAS), i.e. a network of spatially separated antennae, which
transmit the signal from a common source in a given area. The intention is usually to ensure
the coverage of the area thanks to multiple low-power antennae instead of a single more
classical higher power antenna. A DAS can be active (using active repeater amplifiers) or
passive (using passive splitters and feeders). The modification of the power level can be
different in uplink and downlink directions.
To some extent, the operator can cope with this modification between power sent by the
NodeB and power actually transmitted at the output of the DAS, thanks to the Constant
Value. Yet, the range of Constant Value turns out to be too small versus the operating range
of the existing DASs.
This feature aims at filling the gap, by providing the possibility for the NodeB to transmit the
P-CPICH at a power level different than the one broadcast on SIB5. This is achieved thanks to
the addition of a new parameter in the data model, which represents the offset between
actual transmit power and broadcast value. Before the introduction of this feature, a single
parameter is used for both the P-CPICH power used in the NodeB transmission, and the value
broadcast in SIB5 (in other words, only a null offset is possible). For a DAS system, the cell
SIB5 PCPICH power offset should be configured as follows:
sib5PcpichPowerOffset = (DLgain ULgain)
where
DLGain = DL DAS Gain DL External Attenuation, ULGain = UL DAS Gain UL External Attenuation
In addition UE tx pwr at transition to DCH is also adjusted by using the broadcast P-CPICH
power thanks to a 2nd parameter: dpcchPowerOffset.
Pini(DPCCH) = dpcchPowerOffset - P-CPICH_RSCP
For the cells using a DAS system, dpcchPowerOffset should be configured as follows:
dpcchPowerOffset = nominal dpcchPowerOffset + DLgain
where DLGain = DL DAS Gain DL External Attenuation. No new parameter is needed for this
modification, but it is recommended that the value of the existing parameter
dpcchPowerOffset is modified as indicated above the default value for a cell in a NodeB not
using DAS is -94 dB.
FEATURE BENEFITS
For NodeBs using DAS systems, this feature enables the operator to configure initial power
levels used on RACH and on DPCCH to an optimized level, with regard to generated
interference level and access time.
IMPACTED SYSTEMS
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 48 of 72
30/JUN/2014
RNC (although this deals with OneBTS configurations, all code and parameters that
deal with this feature are located in RNC, so that impact on OneBTS is limited to
testing the end to end configuration), OAM.
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
N/A
None
Software feature
None
Distributed Antenna System (DAS)
Standards
None
The parameter dpcchPowerOffset has a granularity of 4 dB (because it is not
managed by a direct parameter at cell level, but within a class to which the cell
refers: PowerCtrlConfClass, and the number of possible classes is limited).
ENGINEERING IMPACTS
In addition to populating the SIB5 offset value, it is recommended to modify
dpcchPowerOffset when using a DAS (see above, dpcchPowerOffset = nominal
dpcchPowerOffset + DLgain).
Counters
None
Activation flag
sib5PcpichPowerOffset: offset between PCPICH power used for the NodeB
transmission and value broadcast on SIB5.
None
FEATURE TYPE
Optional
132085 3G support of TRDU2x60 900MHz without dependency to 2G

FEATURE DESCRIPTION
9742 lightRadio TRDU2x60 B8 (TRDU2x60-900) is a self contained, compact and efficient 19
inch rack mount Multi Carrier Transceiver (GSM, WCDMA, LTE) and Duplexer Unit supporting
the UL and DL frequencies defined by 3GPP Band 8: 900MHz (880-915MHz/ 9258-960MHz).
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 49 of 72
30/JUN/2014
TRDU supports operation over a 25MHz IBW anywhere in the 35MHz of Band VIII.It has already
been made available in previous releases, supporting other configurations.
This feature certifies the TRDU for operation in a 3G-only network. Unlike previously
available configurations, in this 3G-only mode 2G assets (GSM OMC, BSC and SUM) are not
required.
This feature complements the TRDUs other operating modes, including the existing support of
1PA 2G + 1 PA 3G delivered with feature 119185.
In 3G-only mode, the TRDU uses its two multicarrier power amplifiers to provide Top of
Cabinet (ToC) RF power of up to 2x60W. Up to 2 carriers are supported on each PA,. providing
support of disaggregated carrier configurations up to 4 carriers x 30W/ carrier, configured as
STSR2+2.
This feature includes connection to 9326 and 9926 WCDMA digital units, support of AISG from
WMS, and optional RF filter settings for WCDMA-GSM spacing of 2.0 and 2.2MHz.
FEATURE BENEFITS
This feature provides a convenient and economic method of deploying WCDMA service at
900MHz.
Compared to 2100MHz, operation at 900MHz provides improved in-building penetration and
larger cell sizes, allowing a network to be deployed with fewer base stations and cell sites
and at lower cost.
Deployment of this feature is expected where provision of GSM services is not needed, or
connection of the TRDU to an Alcatel-Lucent GSM network is not required or is not available.
Use of TRDU2x60-900 with other features such as 2.0 and 2.2MHz GSM spacing provides a way
of maximizing the 2G and 3G use of scarce 900MHz spectrum.
TRDU2x60-900 provides benefits of:
Support of up to 4 WCDMA carriers on a single TRDU2X60-900
Support of RAN sharing
Support for high RF power, high capacity applications in a small form factor
Support for both continuous and non-continuous spectrum applications
TRDU2X60-900 module is light, no craning is needed, and it eases site installation
Full compatibility with the new lightRadio cabinet portfolio
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
RNC 9370
Support
Other Node B
939x Node B
S:
NS
9711 LR ID & 9712

LR OD
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 50 of 72

HW requirements
None
TRDU2x60 900MHz
30/JUN/2014
N/A
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
None
Counters
None
None
None
FEATURE TYPE
Base
162306 Support of VAM on TRDU60-21B

FEATURE DESCRIPTION
This feature extends support of VAM (introduced with feature 118927 [R8]) to include
TRDU60-21B.
FEATURE BENEFITS
TRDU60-21B is the latest single Tx TRDU from WCDMA for 2100MHz band, and is the lead
solution for applications that need such a TRDU. Delivery of VAM on TRDU60-21B provides
parity with the VAM support available for other TRDU types, and helps ensure TRDU60-21B can
be used in all applications required.
The benefits of VAM on TRDU60-21B are the same as the benefits for other RF assets. Please
see feature 118927 [R8] for more information.
IMPACTED SYSTEMS
Node B
DEPENDENCIES
Hardware
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 51 of 72

RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
30/JUN/2014
None
TRDU60-21B
N/A
Software feature
118927 - PA power balancing with VAM [R8]
None
Standards
None
None
ENGINEERING IMPACTS
None
Counters
None
None
None
FEATURE TYPE
Base but requires optional feature 118927 - PA power balancing with VAM [R8]
163122 RRH2x60-21A operation with 45MHz Instantaneous Bandwidth

FEATURE DESCRIPTION
This feature introduces support for operation of the previously-introduced RRH2x60-21A using
its full hardware capability of 45MHz Instantaneous Bandwidth (IBW).
Software is provided to allow RRH2x60-21A to support multiple carriers across a bandwidth of
up to 45MHz. This enables new configurations, including:
Support of 2 or more carriers, each anywhere within the full 60MHz band
PA2
PA1
Support of 2 carriers for 2 operators, anywhere within the band, for a typical UTRAN
sharing scenario
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 52 of 72
30/JUN/2014
PA2
PA1
Support of up to 4 carriers, anywhere within the band, for operators with

disaggregated frequency allocations
PA2
PA1
Use of this wider bandwidth therefore means a single RRH2x can support configurations that
previously needed 2 RRH2xs.
RRH2x60-21A is hardware-ready for support of more than 4 carriers. Certification of these
configurations depends on software support in a future release.
FEATURE BENEFITS
This feature reduces the number of RRHs needed to support disaggregated spectrum, so
reduces CAPEX, weight, visibility and power consumption of the site.
This feature will be used when an operator wishes to support disaggregated spectrum of their
own, or as part o UTRAN sharing, where the spectrum requires wider bandwidth than the
previous 20MHz. This allows the number of RRHs per sector to be reduced.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
RRH2x60-21A
N/A
Software feature
None
None
Standards
None
The large numbers of configurations possible with this feature mean that specific
configurations required in the field may not have been tested. Care should be taken
to check whether any additional test for such configurations is required.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 53 of 72
30/JUN/2014
ENGINEERING IMPACTS
Provides support of disaggregated spectrum wider than previously possible.
Counters
None
None
None
FEATURE TYPE
Optional
166352 3G AISG support on TRDU2x60 900MHz

FEATURE DESCRIPTION
This feature provides AISG support from WMS using the TRDUs internal AISG controller. This
support is in parity with the AISG support on selected RRHs.
TRDU2x60-09 includes an internal Smart Bias-T so that AISG signals can be transferred to the
FEATURE BENEFITS
flexibility.
Supporting AISG on TRDU2x60-09 allows operators to support AISG without external AISG
controllers such as CCU, and brings the management into WMS rather than a separate system.
IMPACTED SYSTEMS
Node B
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
TRDU2x60-09
N/A
Software feature
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 54 of 72
30/JUN/2014

AISG devices as IOTd
Standards
AISG 2.0
None
ENGINEERING IMPACTS
None
Counters
None
None
None
FEATURE TYPE
Base
166354 LR Outdoor Battery cabinet

FEATURE DESCRIPTION
The new designed LR Outdoor Battery cabinet consists of an enclosure acting as an extra-tall
plinth for a 9712 LR Outdoor cabinet; the battery cabinet accommodates batteries only.
The cabinet is part of lightRadio 9712 OD family of cabinets.
The Battery cabinet can be stacked with the Small and Compact cabinets, or can be installed
side by side to any LR OD configuration.
Maximum 2x 190Ah batteries can be accommodated.
FEATURE BENEFITS
The new LR Outdoor battery cabinet is designed to improve TCO over time for mobile network
operators by providing a high-capacity well-integrated battery solution without increasing the
LR cabinet footprint. This solution is proposed for all wireless technologies GSM/UMTS/LTE.
Figure below shows some diagrams of the proposed Battery cabinet acting as an extra-tall
plinth with a LR OD Small cabinet stacked on top.
In addition, the LR Outdoor Battery cabinet can be deployed not as a plinth but as a separate
cabinet beside the cabinet containing digital and/or RF equipment.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 55 of 72
30/JUN/2014
Figure 9 : LR Outdoor cabinet with Small cabinet on top
IMPACTED SYSTEMS
Node B
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
9712 LR OD Node B
N/A
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
None
Counters
None
None
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 56 of 72
30/JUN/2014

The LR OD Battery cabinet is monitored via external alarms. 1 or 2 alarms depending
on configuration.
FEATURE TYPE
Optional Configuration
168705 Noise floor self-learning algorithm for oneBTS

FEATURE DESCRIPTION
This feature introduces on OneBTS a feature, for which an equivalent on iBTS was introduced
in UA05 (feature 27745 UL load estimation [R4]), namely the automatic determination by
the NodeB of the noise floor (reference Received Total Wideband Power value: RTWPref), i.e.
the RTWP value in the absence of any traffic in the cell and its neighbouring cells controlled
by the same NodeB.
RTWP (Received Total Wideband Power) is the name used in the 3GPP terminology to speak
about the total received power in a cell. This parameter is key to manage the admissible load
in Uplink, because the UL load can be expressed by the equation:
UL =1
N0 Nf W
RTWP
Where N0 corresponds to the thermal noise, Nf is the noise factor of the BTS, W is the
bandwidth.
The thermal noise is the reference RTWP (RTWPref) that corresponds to the amount of power
received in the cell when the load is 0. This means there is no connection in the considered
cell and in the neighbor cells.
The reference RTWP (RTWPref) can be expressed by the equation:
RTWPref = N 0 N f W
It is thus clear that the UL load depends on the reference RTWP.

Currently for oneBTS, the value RTWPref is to be provided cell per cell by the operator. The
default value is -106,1 dBm, but the real value depends in particular on e.g. presence of a
TMA and temperature.
Besides, if any permanent external interferer influences the cell, the maximum acceptable
RTWP does not change, so the admissible load due to calls should be a bit reduced to
compensate.
Therefore, a constant value representing RTWPref is not a good solution.
This feature introduces an algorithm that automatically determines RTWPref (the noise floor)
in oneBTS, thus avoiding the need for the operator to guess and provide a value adapted to
each cell, or the workaround to rely on a constant value. It allows to better take into account
the effect of TMAs and any other influence on the BTS noise factor. Thanks to associated
counters, the operator can also observe the variation and distance to default value. This can
help detecting the presence of undesired interferers and trigger action to try and fix the
problem.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 57 of 72
30/JUN/2014
The self-learning mechanism consists in averaging the lowest filtered values (time periods of
40 ms) measured over a 24 hour period when there is no connection in any cell of the NodeB.
The obtained value is used for the next 24 hour period.
For the initial 24 hours, a quick self learning algorithm is applied instead, using the first
minimum measured value in absence of traffic, and updating every 30 minutes, with any
smaller value that may be measured.
The variation from day to day is capped to 0.5 dB (i.e. if the measurement show a higher
variation, the reference is only updated by 0.5 dB).
The determined RTWPref value is stored in case of NodeB reset.
Two counters are available: a first one recording the noise value that is currently used, and a
second one recording the latest self-learnt noise value. This aims at helping the operator
monitoring the value used in the network and the evolution of this value, so that presence of
external interferers may be detected; Note that these counters are to be provided even if the
feature is not activated (in that case, the noise value used in the cell is the one set by the
RNC, the more interesting counter is the NodeB-measured value).
Getting valid samples for the noise floor measurement in a cell (i.e. 40 ms time periods
without any traffic on the carrier of that cell within the NodeB) can prove difficult: thus, the
algorithm can be configured to also consider as valid, time periods with little traffic, rather
than no traffic at all. Load added by this little traffic is estimated and subtracted.
The operator can manually trigger a new determination of the noise floor, using the quick self
learning algorithm. This is useful for instance in case of HW change, for insertion of a
Distributed Antenna System or other external part, or if the operator manages to shut off
some external interferers or any external reason that may suddenly change the noise floor
value.
The current algorithm does not take into account the difference in temperature between the
time the reference RTWP is measured and the time it is used. Variations in a day can be high:
the NodeB can for instance be cold at night when RTWPref is obtained (e.g. -10C / 263 K /
14F) and the NodeB may become hot in the sun (e.g. 50C / 323 K / 122F). The estimation
of the reference thermal noise per Hz in this example varies from -174,4 dBm/Hz to -173,5
dBm/Hz. The observed load when the NodeB is hot will then be a bit pessimistic, which may
lead to unduly rejecting some calls. It can be considered that errors on temperature may
cause an error of up to around 1 dB in RTWPref, which is deemed acceptable.
This feature also introduces the ability for the oneBTS to report the Reference RTWP to the
RNC through the NBAP Common Measurement Report procedure.
FEATURE BENEFITS
This feature provides an accurate value (apart from temperature variations), of the noise
floor in the oneBTS, thus providing better input for the UL Load determination, which in turn
results in more relevant Connection Admission Control decisions.
It also allows the operator to follow the evolution in time of the noise floor (thanks to the
counters), which may help identifying HW issues and presence of abnormal external
interferers, so that the operator can then intervene and correct the problems.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 58 of 72
30/JUN/2014
IMPACTED SYSTEMS
Node B, RNC (the impact on RNC is small as the RNC already supports automatic
noise floor reporting from iBTS: it only needs to adapt so that it accepts the same
behavior from OneBTS), OAM.
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
N/A
Support
HW requirements
None
N/A
None
Software feature
E-DCH has to be activated for the OneBTS to be able to measure the noise
floor. If E-DCH is not activated, the OneBTS reports the last value that was
measured when E-DCH was last active, or the value provided by RNC if E-DCH
was never active.
None
Standards
None
None
ENGINEERING IMPACTS
None
Counters
Value of the reference RTWP that is currently in use
Value of the latest reference RTWP that was learnt
Activation flag per cell for the RTWPref measurement.
Activation flag per cell for allowing little traffic when measuring RTWPref.
Action to restart the measurement using quick self learning algorithm
None
FEATURE TYPE
Optional
169488 AISG2.0 on 9396-based RRHs Phase 1A

FEATURE DESCRIPTION
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 59 of 72
30/JUN/2014
This feature provides Alarm Clear action at the WMS and software download support for ALD
devices at the WMS (configuration files & software image).
FEATURE BENEFITS
This feature allows the AISG alarms to be cleared from WMS without resetting the RRH.
The feature also allows remote download from WMS of initial antenna RET configuration files
where needed, and update of operating firmware.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
N/A
RRH2x60
Software feature
No dependency; new functions based on previously delivered 123836 - AISG2.0
on 9396-based RRHs Phase 1 [R9]
AISG 2.0 RET devices attached to RRH2x60
Standards
AISG 2.0
Only applicable to AISG 2.0 RETs attached to RRH2x60s attached to 9396 digital
units.
ENGINEERING IMPACTS
No new impacts.
Counters
None
None
None
FEATURE TYPE
Base
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 60 of 72
30/JUN/2014
170665 TRDU2x80 2100MHz

FEATURE DESCRIPTION
This feature introduces a new TRDU providing 2x80W in 3GPP Band I (B1, 2100MHz), certified
for use in WCDMA with iBTS digital assets and in the lightRadio cabinet portfolio.
Figure 10 : TRDU2x80 B1
TRDU2x80-B1 (also known as TRDU2x80-21) is an RF module including:
2x 80W RF Power Amplifiers
4 antenna connections
4 RF Receivers
Instantaneous bandwidth of 45MHz
Power system
Thermal system
CPRI interface to a digital unit
AISG controller
Form factor to fit in standard 19 rack systems
This feature delivers the hardware and its WCDMA certification with iBTS digital units in the
lightRadio Compact Outdoor cabinet. Additional features will define additional
configurations and additional cabinet types.
FEATURE BENEFITS
TRDU2x80-21 provides a compact and efficient source of high RF power, with wide
instantaneous bandwidth, making it suitable to provide up to 4 carriers at 40W at Top of
Cabinet in typical disaggregated spectrum, all within a single RF unit. It is ready to support
upgrade to LTE and dual-tech configurations in the future.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
RNC 9370
Support
Other Node B
939x Node B
S:
NS
9711 LR ID & 9712

LR OD
HW requirements
None
None
N/A
Software feature
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 61 of 72
30/JUN/2014
None
None
Standards
None
None
ENGINEERING IMPACTS
Network designers should take into account the additional RF power and
instantaneous bandwidth provided by this new asset.
Counters
None
None
None
FEATURE TYPE
Optional - Hardware
174085 AISG management enhancements

FEATURE DESCRIPTION
This feature provides new capabilities for AISG control from WMS through RRHs and TRDUs. It
is applicable to all AISG supporting assets in the WCDMA portfolio.
The new capabilities included in the feature include support of user-definable names for each
connected ALD, download of ALD configurations files and new firmware, enhanced inventory
reporting, and improved alarm support and alarm clearing.
This feature does not include IOT between additional AISG devices (ALDs) and the AISG
supporting assets: it is important that such IOT is carried out as part of the evaluation of
deployment of this feature and AISG in general.
FEATURE BENEFITS
Reduced operational cost when managing tower-top items such as antenna tilt systems and
tower mounted amplifiers.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 62 of 72
30/JUN/2014
Hardware
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
See list below
N/A
Software feature
33213: RRH40-21, 40-08, 40-19, 40-AWS, 60-21A, 60-08, 60-19 [R7]
74682 & others: RRH2x60-21, -21A, -850, -1900, -1900A [R8]
123826: TRDU60-21B
174283 : RRH2x40-09 (MC-RRH 900)
166352: TRDU2x60-09 (MC-TRDU 900)
170665: TRDU2x80-21
All AISG-supporting devices above also need IOT with target AISG devices.
AISG devices according to IOT with AISG supporting devices
Standards
AISG 2.0
All AISG-supporting devices above also need IOT with target AISG devices.
ENGINEERING IMPACTS
AISG devices require installation and commissioning in addition to normal UTRAN
activities.
Counters
None
None
None
FEATURE TYPE
Base
174283 AISG for MC-RRH 3G-only

FEATURE DESCRIPTION
This feature provides control from WMS or TIL of AISG devices (ALDs) connected to MC-RRH
when operated in 3G-only mode. This feature uses the RRHs internal AISG controller. This
support is in parity with the AISG support on selected other RRHs and later enhancements.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 63 of 72
30/JUN/2014
MC-RRH includes an internal Smart Bias-T so that AISG signals can be transferred to the
IOT is performed with selected ALDs.
FEATURE BENEFITS
flexibility.
Supporting AISG on MC-RRH allows operators to support AISG without external AISG controllers
such as CCU, and brings the management into WMS rather than a separate system.
IMPACTED SYSTEMS
Node B
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
RRH2x40-09
N/A
Software feature
AISG devices as IOTd
Standards
AISG 2.0
None
ENGINEERING IMPACTS
None
Counters
None
None
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 64 of 72
30/JUN/2014
None
FEATURE TYPE
Base
177111 Digital DAS using Tyco CDIU with WCDMA 9396 digital Phase 2
FEATURE DESCRIPTION
This is an extension to previously delivered 176934 Digital DAS using Tyco CDIU with WCDMA
9396 digital [R9].
This feature delivers a new configuration and improved WMS management of the Node B to
better illustrate the actual configurations in use.
FEATURE BENEFITS
The benefits of the previous feature are:
Reduced power consumption in the Node B, because the high power RF is no longer
needed
Elimination of the analog attenuators, reducing dissipated power and saving

significant space
Reduced need for site thermal management, because the heat dissipated by both
Node B and attenuator no longer needs to be removed.
These benefits are extended to a new configuration.

Additionally, the Node B OAM system is extended to show the new configurations and to
provide new alarms for monitoring the CPRI interface between Node B and DAS CDIU.
IMPACTED SYSTEMS
Node B, OAM (WMS)
DEPENDENCIES
Hardware
RNC 9370
Other Node B
939x Node B
NS
Support
HW requirements
None
N/A
9396 d4U
Software feature
None
Tyco Electronics Corp. (TE) FlexWave Prism and Spectrum DAS, including CDIU
interface card
Standards
CPRI
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 65 of 72
30/JUN/2014
Certified only for 9396 d4U and TE FlexWave DAS.

ENGINEERING IMPACTS
The DAS requires specific engineering, which will be performed by the DAS supplier.
The specific new configuration supported is as shown below, or sub-populations:
2 CPRIs from d4U to a CDIU:
1 or 2 carriers 1900MHz on one CPRI link
1 or 2 carriers 1900MHz on second CPRI link
All carriers are 1Tx, 1Rx
All carriers in the same sector
Repeated 3x on a 9396 d4U provides support for:
Up to 12 sector-carriers
Up to 4 carriers in the same sector
Total 3 sectors, 1 band.
This complements the previously introduced configuration for areas where 850MHz
spectrum is not available.
Counters
None
CDIU configuration managed using TE management system.
CDIU alarms managed using TE management system
FEATURE TYPE
Optional - Hardware
5.8
RNC EVOLUTIONS
134390 9771 Wireless Cloud Element (WCE) RNC

FEATURE DESCRIPTION
The Wireless Cloud Element is cloud compatible platform supporting traditional central office
deployment or on existing data center technology with the ability to manage run-time
software processes across multiple hardware processors. The servers can be co-located in one
physical location or distributed in multiple locations. Using this technology, the WCE can be
configured with one or more instances of the same tenant and/or with single or multiple
types of tenants executing simultaneously. This configurability allows resources to be
dynamically shared between similar or different tenant types (e.g. 2 RNC or RNC and Small
Cell Gateway, etc dependent on the configuration). For example, traffic may migrate from
one tenant to another; as a result, the system may reallocate computing power based on the
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 66 of 72
30/JUN/2014
tenant computing needs. Additionally, the WCE can be designed to accommodate a range of
capacity from small to very large systems distributing the processing across the data servers
for an efficient resource use. The tenants are compatible with the existing radio network
infrastructure using native IP communication. The Wireless Cloud Element is a customizable
system designed specifically to meet the network requirements while efficiently using
hardware resources
For the first release the WCE will begin with the Radio Network Controller (RNC) application
as its primary tenant. The RNC is key in the success of any UMTS Terrestrial Radio Access
Network (UTRAN) deployment. As such, it is imperative that deployed RNCs have the ability
to scale efficiently and to cater for flexible deployment scenarios. It is also essential that the
RNC possess the capability to improve performance over time, given the likely exponential
growth of wireless data.
The Wireless Cloud Element introduces many degrees of freedom for managing the telecom
applications by providing:
A unified platform to easily manage several radio network applications
A customizable platform allowing the ability to host a single or multiple applications

and one or more instances of the application
A dynamic platform able to allocate hardware computer processing units between

applications based on demand
A scalable platform to accommodate capacity from small to very large configuration

depending on the needs of the network
A hardware independent platform with the ability to upgrade and maintain hardware
separate from the software execution with minimal to zero downtime
A hardware independent platform which secures backward compatibility to previous

HW generations thus protecting operator CAPEX investments
A multi-tenant platform capable of integrating OAM functions across multiple tenants

and tenant types
A green platform as power is reduced because of fewer hardware units and hardware
can be turned off as software processes are consolidated based on capacity usage
A platform designed in mind with low Total Cost of Ownership (TCO)
A platform which simplifies the network operations and engineering
A compatible platform with native IP capabilities to communicate with existing radio

network infrastructure
FEATURE BENEFITS
General Platform
3G RNC today and other applications (MME, EMS ) in future.
Increased the RNC capacity. Up to 5x capacity from current 9370 architecture.
Longevity recognizing that trend in networks is towards IP interface and Network

Function Virtualization.
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 67 of 72
30/JUN/2014
Hardware independence, 3rd party Commercial Off-The-Shelf (COTS) product.
Expanded controller scalability to meet customer needs.
Flexible deployment configurations.
Cloud-enabled technology.
OPEX gain.
Specific to RNC Application

The Wireless Cloud Element UMTS Radio Network Controller provides a flexible and scalable
solution for network operators. Incorporating this application into their network, the
operators will achieve a reduction in capital and operational spending as a result of the
following benefits:
Reduction in the number of RNCs because of the ability to configure larger RNCs
Reduction in the footprint required for the RNCs because fewer RNCs are required
Reduction in inter-RNC connectivity (Iur) because fewer RNCs are required
Ability to increase capacity without impacts to the network, dynamically and inservice
Reduction in power requirements because fewer RNCs are required and there is
better optimized equipment
Reduction in Iur and Iub re-homing and re-parenting activities because the RNCs can
accommodate more NodeB connections and the RNC capacity can increase without
outages
Reduction in physical sites as the RNC can accommodate large capacity and cover a
large physical area
Reduction in general maintenance activities because there are fewer RNCs to

maintain
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
Support
HW requirements
N/A
RNC 9370
Other Node B
939x Node B
N/A
NS
None
N/A
Software feature
None
IP transport towards Core Network nodes
Standards
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 68 of 72
30/JUN/2014
None
IP transport only
ENGINEERING IMPACTS
Transport Engineering and capacity planning considerations.
Counters
No new application/3GPP counters introduced. New/changed infrastructure
counters for WCE are defined, details can be found in the standard WCE product
documentation.
Configuration management and parameters details come with the standard WCE
product documentation.
Fault Management and Alarms details come with the standard WCE product
documentation.
FEATURE TYPE
Optional - Hardware
ABBREVIATIONS AND DEFINITIONS

6.1
Abbreviations
2G
3G
3GPP
AAL2
ACB
AISG
ALU
AMR
AO
ARP
ASN1
ATM
BBU
BCCH
BLER
BMC
BSS
BTS
BW
Second Generation
Third Generation
Third Generation PartnerShip Project
ATM Adaptation Layer type 2
Access Class Barring
Antenna Interface Standards Group
Alcatel-Lucent
Adaptative Multi Rate
Always On
Allocation/Retention Priority
Abstract Syntax Notation 1
Asynchronous Transfer Mode
Base Band Unit
Broadcast Control Channel
Block Error Rate
Broadcast and Multicast Control
Base Station Sub-system
Base Transceiver Station
Bandwidth
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 69 of 72

CAC
CB
CBC
CBS
CBE
CCH
CCCH
CCM
CELL _PCH
CEM
CID
CM
CN
COTS
CRNC
CS
CQI
CT
CTCH
DAS
DCH
DCCH
DCPS
DDM
DDSM
DL
DPCCH
DRNC
DRX
DTCH
E-DCH
eDCPS
FACH
FDD
FPG
FPGA
GANSS
GBR
GGSN
GLONASS
GPSAM
GPxOIM
GSM
GUI
HCS
HO
HHO
HLR
30/JUN/2014
Call Admission Control

Cell Broadcast
Cell Broadcast Center
Cell Broadcast Service
Cell Broadcast Entity
Control Channel
Common Control Channel
Core Control Module
Cell-Paging Channel
Channel elements Modules
Customer Identificator
Compressed Mode
Core Network
Commercial Off-The-Shelf
Controlling RNC
Circuit Switched
Coded Quality Indicator
Call Trace
Common Traffic Channel
Distributed Antenna System
Dedicated Channel
Dedicated Control Channel
Dual-Core Packet Server
Dual Duplexer Module
Dual Duplexer Sharing Module
Downlink
Dedicated Physical Control Channel
Drift RNC
Discontinuous Reception
Dedicated Traffic Channel
Enhanced Dedicated Channel
enhanced Dual-Core Packet Server
Forward Access Channel
Frequency Division Duplex
Feature Planning Guide
Field-programmable gate array
Galileo and Additional Navigation Satallite System
Guaranteed Bit Rate
Gateway GPRS Support Node
Global Navigational Satellite System
Global Positioning System Alarm Management
Module supporting GPSAM functions and ready for
c2OIM or c3OIM insertion
Global System for Mobile communications
Graphical User Interface
Hierarchical Cell structures
Handover
Hard Handover
Home Location Register
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 70 of 72

HSDPA
HS-DSCH
HS-PDSCH
HS-SCCH
HSUPA
HW
IE
iMCTA
IOT
MAC
MBR
MCPA
MGW
MLP
MM
MSC
MSS
N/A
NBAP
NRI
OAM
OIM
OLS
OPEX
OS
OVSF
PCH
PCR
PS Domain
RAB
RACH
RAN
RANAP
RAT
RB
RF
RNC
RNSAP
RoHS
RoT
RRC
RRH
RRM
RSI
RSSI
RTSP
RTWP
QoS
SA
SABP
30/JUN/2014
High Speed Downlink Packet Access

High Speed Downlink Shared Channel
High Speed Physical Downlink Shared Channel
High Speed Service Control Channel
High Speed Uplink Packet Access
Hardware
Information Element
Intelligent Multi Carrier Traffic Allocation
Interoperability testing
Medium Access Control (protocol layering context)
Maximum Bit rate
Multi Carrier Power Amplifier
Media Gateway
MAC logical channel Priority
Multi Mode
Mobile Switching Center
Multi Service Switch
Not Applicable
Node B Application Part
Network Resource Identifier
Operation, Administration and Maintenance
Optical Interface Module
Olympic Level Service
Operation Expenses
Operating System
Orthogonal Variable Spreading Factor
Paging Channel
PCR is the base Multiservice Switch (MSS) release
name
Packet Switched Domain
Radio Access Bearer
Random Access Channel
Radio Access Network
Radio Access Application Part
Radio Access Technology
Radio Bearer
Radio Frequency
Radio Network Controller
Radio Network Subsystem Application Part
Restriction of the use of certain Hazardous Substances
Raise over Thermal noise
Radio Resource Control
Remote Radio Head
Radio Resources Management
Resource Status Indicator
Received Signal Strength Indication.
Real Time Streaming Protocol
Received Total Wideband Power
Quality of Service
Service Area
Service Area Broadcast Protocol
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 71 of 72

SCCH
S-CCPCH
SGSN
SI
SIB
SM
SMS
SMSCB
SNMP
SRB
SrHO
SRNC
SRNS
STSR
SW
TC
TFCS
TFO
THP
TIL
TMA
TMU
TrFO
TRM
TTI
UCU
UE
UL
UMTS
UP
URA
URA_PCH
UTRA
UTRAN
VCC
VCI
VLR
VPI
VSWR
WCE
WMS
WPS
30/JUN/2014
Service Control Channel

Secondary Common Control Physical Channel
Serving GPRS Support Node
Sellable Item
System Info Block
Single Mode
Short Message Service
Short Message Service Cell Broadcast
Simple Network Management Protocol
Signalling Radio Bearer
Softer Handover
Serving RNC
Serving Radio Network Subsystem
Sector Transmit Sector Receive
Software
Traffic Class
Transport Format Combination Set
Tandem Free Operation
Traffic Handling Priority
Terminal dInstallation Local
Tower Mounted Amplifier
Traffic Management Unti
Transcoder Free Operation
Transceiver module
Transmission Time Interval
UMTS Channel Element Unit
User Equipment
Uplink (Reverse Link)
Universal Mobile Telecommunications System
User Plane
UTRAN Registration Area
UTRAN Registration Area Paging Channel
Universal Terrestrial Radio Access
Universal Terrestrial Radio Access Network
Virtual Channel Connection
Virtual Channel Identifier
Visitor Location Register
Virtual Path Identifier
Voltage Standing Wave Ratio
Wireless Cloud Element
Wireless Management System
Wireless Provisioning System
UMT/SYS/INF/041185

V01.07/EN
Standard, External
Page 72 of 72

LR14W - V1 - UMTS Access Network - Feature Planning Guide LR14

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

LR14W - V1 - UMTS Access Network - Feature Planning Guide LR14

Transféré par

Droits d'auteur :

Formats disponibles

UMTS ACCESS NETWORK

LR14 UMTS ACCESS NETWORK FEATURE PLANNING GUIDE

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

Alcatel-Lucent Confidential & Proprietary

LR14 UMTS ACCESS NETWORK FEATURE PLANNING GUIDE

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

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

170506 Support of DC-HSDPA with Multiple RRH per cell

JUNE 11TH 2014 - ISSUE 01.06 / EN, Draft, Internal

176914 Support of band 12 MFBI capable UE in WCDMA

Modification of features description:

112527 Defense against PA failure in parallel x2PAM configurations

100894 UMTS to LTE PS HO

MARCH 17TH 2014 - ISSUE 01.04 / EN, Draft, Internal

Alcatel-Lucent Confidential & Proprietary

LR14 UMTS ACCESS NETWORK FEATURE PLANNING GUIDE

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

APPLICABLE DOCUMENTS ...................................................................................... 9

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

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

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

Alcatel-Lucent Confidential & Proprietary

LR14 UMTS ACCESS NETWORK FEATURE PLANNING GUIDE

Alcatel-Lucent Confidential & Proprietary

LR14 UMTS ACCESS NETWORK FEATURE PLANNING GUIDE

Scope of this document

Features are grouped by category:

PERFORMANCES AND CAPACITY

SERVICES AND RADIO RESOURCES MANAGEMENT

TRANSPORT AND TRANSMISSION CAPABILITIES

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

Alcatel-Lucent Confidential & Proprietary

LR14 UMTS ACCESS NETWORK FEATURE PLANNING GUIDE

LR14.2W RNC Counters Evolution

E-DCH performance enhancement

Selective Paging Discard

Support of GLONASS assistance data over Optional

Smart E-DCH resource usage - new

Traffic filtering in cell overload - new

LR14.2W 3GPP Baseline

Fast return to LTE improvement

Enhanced CELL_FACH for DL&UL

Enhanced UE DRX in CELL_FACH

AISG for TRDU60-21B

W-CDMA/LTE dual-technology support by Optional

3G Support of TRDU2x60 900MHz without Base

9771 Wireless Cloud Element (WCE) -

Alcatel-Lucent Confidential & Proprietary

LR14 UMTS ACCESS NETWORK FEATURE PLANNING GUIDE

Support of VAM on TRDU60-21B

RRH2x60-21A operation with 45MHz

3G AISG support on TRDU2x60 900MHz

LR Outdoor Battery Cabinet

DC-HSDPA functional enhancement

AISG management enhancements

AISG for MC-RRH 3G-only

Defense against PA failure in parallel Optional

DSCP Marking Enhancements

CPICH power level reporting correction Optional

RRC Connection Re-establishment over

Noise floor self-learning algorithm for Optional

AISG2.0 on 9396-based RRHs Phase 1A

Support of band 12 MFBI capable UE in Optional