LR13 UTRAN FPG UMT - SYS - INF - 037991 v01 10EN Preliminary PDF

UMTS ACCESS NETWORK
FEATURE PLANNING GUIDE

R E L E A S E L R13
UMT/SYS/INF/037991
PRELIMINARY EXTERNAL
V01.10/EN
25/APR/2013
LR13 UMTS ACCESS NETWORK FEATURE PLANNING GUIDE 25/APR/2013
Copyright © 2013 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.alcatel-
lucent.com
Notice
At the time of publication, this document reflects the latest information on Alcatel-Lucent’s
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 Alcatel-
Lucent 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 Alcatel•Lucent written authorization
Alcatel-Lucent – Confidential & Proprietary
UMT/SYS/INF/037991 V01.10 Preliminary, External Page 2 of 104
PUBLICATION HISTORY
APRIL 25TH 2013 - ISSUE 01.10 / EN, Preliminary, External

Modification of features description:
• 116232 - Path Diversity Support for User Plane on 9370 RNC
• 120498 - LR13.W Call Trace Developments
• 123895 – 9396 d4U activation of additional CPRI ports
Removal of features:
• 121028 - URC-II Processor Overload Control
• 123198 - OneBTS internal temperature monitor at WMS
APRIL 19TH 2013 - ISSUE 01.09 / EN, Draft, Internal

Internal version for review.
APRIL 2ND 2013 - ISSUE 01.08 / EN, Preliminary, External

Modification of feature description:
• 33648 – Support of 24 cells / 111041 – Support of 12 antenna pairs
MARCH 22ND 2013 - ISSUE 01.07 / EN, Preliminary, External

Updated version to include features:
• 106719 – RNC Call Trace Capacity Realignment
• 119185 - TRDU2x60 900MHz multi-standard support for 2G & 3G (1PA 2G & 1 PA 3G)
• 120498 – LR13.W Call Trace Developments
• 158406 – RRH2x60-21A
• 159246 – Direct PCH to DCH Transition Enhancements
• 159290 – Multiple RRH per cell : extension for 9926 BBU 4U
• 162520 – External alarm logical state inversion
• 164301– LR13.3.W RNC counter evolutions
• 164373 – MCTRX67-09 3G in LR Indoor Cabinet Configuration
• 167400 - TRDU2x60-09 WCDMA configurations in LR indoor cabinet
• 167401 - TRDU2x60-09 WCDMA configurations in LR outdoor cabinet
Modification of features description:
• 33648 – Support of 24 cells / 111041 – Support of 12 antenna pairs
• 89563 – Improved L2 for uplink
• 96298 – LR13.1.W RNC counter evolutions
• 98448 – Access Class Barring (ACB) at Cell Granularity
• 100791 – BTS daisy chaining through the Node B
• 113326 – Node B synchronization enhancements
• 118307 – LR13.W Node B counter evolutions

• 120363/165360 – Smart E-DCH resource usage
• 120494 – Node B IP counters
• 121378 – Enhanced Flexible RAB/TMU role assignment
• 127550/168556 – Traffic filtering in cell overload
Removal of features:
• 100894 - UMTS to LTE HO
• 108103 - Enhanced CELL_FACH for DL & UL (3GPP Rel-8)
• 108956 – IPv6 support for OAM traffic on the Node B (OneBTS)
• 112527 – Defense against PA failure in parallel x2PAM configurations
• 122447 - RRH2x60-1900 Dual-technology (WCDMA-LTE) operation with 9396 digital
units
• 125540 - RRH2x60-850 Dual-technology (WCDMA-LTE) operation with 9396 digital units
FEBRUARY 22ND 2013 - ISSUE 01.06 / EN, Preliminary, Internal
JANUARY 29TH 2013 - ISSUE 01.05 / EN, Draft, Internal
OCTOBER 10TH 2012 - ISSUE 01.04 / EN, Preliminary, External
OCTOBER 8TH 2012 - ISSUE 01.03 / EN, Preliminary, External
JULY 25TH 2012 - ISSUE 01.02 / EN, Preliminary, Internal
JUNE 15TH 2012 - ISSUE 01.01 / EN, Draft, Internal

Document creation
Internal version for review
CONTENTS
1 INTRODUCTION ................................................................................................ 7
1.1 OBJECT ....................................................................................................... 7
1.2 SCOPE OF THIS DOCUMENT .................................................................................... 7
1.3 FEATURES LISTS .............................................................................................. 8
1.4 AUDIENCE................................................................................................... 10
2 RELATED DOCUMENTS ...................................................................................... 11
2.1 APPLICABLE DOCUMENTS .................................................................................... 11
2.2 REFERENCE DOCUMENTS .................................................................................... 11
3 LR13.W MAIN DRIVERS...................................................................................... 12
4 LR13.W OPTIONAL SOFTWARE PACKAGES .............................................................. 13
5 LR13.W FEATURES DESCRIPTION ......................................................................... 15
5.1 BASELINE ................................................................................................. 15
115558 – LR13.W 3GPP Baseline............................................................................ 15
5.2 PERFORMANCES AND CAPACITY ...................................................................... 16
89563 – Improved L2 for uplink............................................................................. 16
168710 – Enhanced CELL_FACH for DL (3GPP Rel-7) .................................................... 17
120363/165360 – Smart E-DCH resource usage........................................................... 18
126055 – UL radio overload handling enhancements .................................................... 21
159246 – Direct PCH to DCH Transition Enhancements ................................................. 23
5.3 SERVICES AND RADIO RESOURCES MANAGEMENT .................................................. 24
120416 – IuPC interface enhancements ................................................................... 24
127550/168556 – Traffic filtering in cell overload....................................................... 28
134302 – CBS enhancements for UE battery savings and increased service reliability ............. 30
5.4 MOBILITY ................................................................................................. 32
83659 – From LTE VoIP to WCDMA CS Continuity (VCC) ................................................. 32
155968 – Cell load exchange for inter-RAT mobility from LTE ......................................... 34
5.5 TRANSPORT AND TRANSMISSION CAPABILITIES .................................................... 35
97427 – Local Node B Iub E-DCH congestion control enhancements .................................. 35
100791 – BTS daisy chaining through the Node B ........................................................ 37
103182 – Ethernet OAM in the Node B ..................................................................... 39
113326 – Node B synchronization enhancements ........................................................ 43
116232 – Path diversity support for user plane on 9370 RNC........................................... 45
5.6 OPERATIONAL EFFECTIVENESS ....................................................................... 47
96298 – LR13.1.W RNC counter evolutions................................................................ 47
106719 – RNC Call Trace Capacity Realignment ......................................................... 51
118307 – LR13.W Node B counter evolutions ............................................................. 53
120494 – Node B IP counters ................................................................................ 55
120498 – LR13.W Call Trace Developments ............................................................... 58
159393 – Configurable VSWR Alarm Threshold ........................................................... 59
164301 – LR13.3.W RNC counter evolutions .............................................................. 60
5.7 NODE B EVOLUTIONS ................................................................................... 64
33648 – Support of 24 cells ................................................................................. 64
111041 – Support of 12 antenna pairs ..................................................................... 64
103774 – 3G only support of RRH2x40-09 (w/o dependency to 2G) ................................... 66
119185 – TRDU2x60 900MHz multi-standard support for 2G & 3G (1PA 2G & 1 PA 3G) ............. 68
167400 - TRDU2x60-09 WCDMA configurations in LR indoor cabinet .................................. 68
167401 - TRDU2x60-09 WCDMA configurations in LR outdoor cabinet ................................ 68
120415 – RRH2x60-850 & -1900 with 9396 digital units - second PA activation ..................... 70
120799 – RRH2x antenna cross-connect for 9396 d2U and d4U ........................................ 71
121018 – MCR-B 1900 with HE PAM at 60W ............................................................... 74
121030 – OneBTS PM processor load counters ............................................................ 75
121537 – U2100 + U900 Daisy Chaining .................................................................... 76
123836 – AISG2.0 on 9396-based RRHs Phase 1 .......................................................... 78
123895 – 9396 d4U activation of additional CPRI ports ................................................. 80
125406 – Monitoring of eCEM and xCEM modem load ................................................... 81
125407 – Overload protection of Node B digital part (Step 2) ......................................... 81
125409 – Dynamic overload management of CPU resources on eCEM / xCEM ....................... 81
125587 – LightRadio Outdoor Cabinet WCDMA ........................................................... 82
133975 – Hosting of 2 Node Bs WCDMA in one 9926 d4U ................................................ 85

158406 – RRH2x60-21A....................................................................................... 87
159290 – Multiple RRH per cell : extension for 9926 BBU 4U ........................................... 90
159429 – LightRadio Indoor Cabinet WCDMA ............................................................. 91
162520 – External alarm logical state inversion ......................................................... 94
164373 – MCTRX67-09 3G in LR Indoor Cabinet Configuration ......................................... 95
5.8 RNC EVOLUTIONS ....................................................................................... 97
98448 – Access Class Barring (ACB) at Cell Granularity ................................................. 97
121337 – 9370 RNC Capacity Evolution with eDCPS ..................................................... 98
121378 – Enhanced Flexible RAB/TMU role assignment ................................................. 99
6 ABBREVIATIONS AND DEFINITIONS ...................................................................... 101
6.1 ABBREVIATIONS ............................................................................................ 101
FIGURES
FIGURE 1: IUPC TRANSPORT PROTOCOL STACK .................................................................................................... 25
FIGURE 2: CBS ALERT MESSAGE SCHEDULING ...................................................................................................... 31
FIGURE 3: EXAMPLE OF 2G BTS WITH ABIS OVER IP/ETHERNET DAISY CHAINED THROUGH THE 3G NODE B ..... 37
FIGURE 4: EXAMPLE OF A 3G NODE B DAISY CHAINED THROUGH THE 3G NODE B ............................................. 37
FIGURE 5: EXAMPLE OF A 4G ENODE B DAISY CHAINED THROUGH THE 3G NODE B ........................................... 38
FIGURE 6: IEEE802.3AH, ITU-T Y.1731 AND IEEE802.1AG SUPPORT ON THE NODE B .......................................... 41
FIGURE 7: RNC EGRESS PATH DIVERSITY ON THE IUB INTERFACE ........................................................................ 45
FIGURE 8: RNC EGRESS PATH DIVERSITY ON THE IU INTERFACE .......................................................................... 46
FIGURE 9: CONFIGURABLE VSWR ALARM THRESHOLD......................................................................................... 59
FIGURE 10: TRI-SECTORS SITE WITH 5/6 CARRIERS PER SECTOR .......................................................................... 64
FIGURE 11: BBU HOSTELLING CONFIGURATION ................................................................................................... 65
FIGURE 12: INDOOR COVERAGE APPLICATION OF BBU HOSTELLING ................................................................... 65
FIGURE 13: TRDU2X60 900MHZ ............................................................................................................................ 69
FIGURE 14: TRADITIONAL RF ASSET – SECTOR ALLOCATION ................................................................................ 72
FIGURE 15: CROSS-CONNECTED ASSET – SECTOR ALLOCATION ........................................................................... 73
FIGURE 16: U2100 + U900 DAISY CHAINING ......................................................................................................... 77
FIGURE 17: LR OUTDOOR CABINET FAMILY .......................................................................................................... 83
FIGURE 18: LR OUTDOOR CABINET STACKABILITY ................................................................................................ 84
FIGURE 19: EXAMPLE OF 2 NODE B IN D4U CONFIGURATION .............................................................................. 86
FIGURE 20: RRH2X60-21A ..................................................................................................................................... 88
FIGURE 21: LR INDOOR CABINETS ......................................................................................................................... 93
FIGURE 22: MCTRX67-09 3G IN LR INDOOR CABINET CONFIGURATION .............................................................. 95
1 INTRODUCTION
1.1 Object
This document provides a high-level description of the features introduced in
release LR13 of Alcatel-Lucent UMTS Radio Access Network (UTRAN). In the rest of
the document the release will be referred as LR13.W (“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 OAM09 [R1].
1.2 Scope of this document

This document lists and describes customer-viewable UTRAN features that are new
in LR13.W.
Features in LR13.W can be delivered into two main software loads, namely LR13.1.W
and LR13.3.W. For features whose delivery is split between LR13.1.W and LR13.3.W
(feature with double ID in the title), the parts only coming in LR13.3.W are listed in
the Restriction/Limitation section of each feature description.
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 [R10] is only deployed in the North American W-
CDMA market. “Other Node B” means any Node B not part of the 939x portfolio.
RNC 9370 Other Node B 939x Node B
Support S, NS S, NS S, NS
HW requirements None, N/A, None, N/A, None, N/A,

required modules required modules 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
The RNC 9370 PSFP modules are not supported starting from UA08.1. As such,
“None” in the RNC 9370 HW requirements column means the feature is supported on
DCPS and eDCPS only.
1.3 Features Lists

The following table provides the list of features described in this FPG, grouped by
Node B family applicability. It also provides an indication on whether the feature is
base or optional.
ID Feature Title Base or Other 939x

Optional Node B Node B
83659 VoIP from LTE VoIP to WCDMA CS Optional S S

Continuity (VCC)
96298 LR13.1.W RNC Counter Evolutions Base S S
98448 Access Class Barring (ACB) at Cell Optional S S
Granularity
106719 RNC Call Trace Capacity Realignment Base S S
115558 LR13.W 3GPP Standards compliance Base S S
120363 Smart E-DCH resource usage Optional S S
120416 IuPC Interface Enhancements Optional S S
121378 Enhanced Flexible RAB/TMU role Optional S S
assignment
121337 RNC capacity evolution with eDCPS Optional S S
125587 LightRadio Outdoor Cabinet WCDMA Optional – S S
Hardware
126055 UL radio overload handling Optional S S
enhancements
127550 Traffic filtering in cell overload Optional S S
134302 CBS enhancements for UE battery savings Optional S S
and increased service reliability
155968 Cell load exchange for I-RAT mobility Optional S S
from LTE
159246 Direct PCH to DCH Transition Optional S S
Enhancements
159429 LightRadio Indoor Cabinet WCDMA Optional – S S
Hardware
164301 LR13.3.W RNC counter evolutions Base S S
33648 Support of 24 cells per Node B Optional S NS
89563 Improved L2 for uplink Optional S NS
97427 Local Node-B Iub E-DCH Congestion Base S NS
Control Enhancements
100791 BTS daisy chaining through the Node B Optional S NS
103182 Ethernet OAM in the Node B Optional S NS
103774 3G only support of RRH2x40-09 (w/o Optional S NS
dependency to 2G)
111041 Support of 12 antenna pairs Optional S NS
113326 Node B Synchronisation Enhancements Optional S NS
118307 LR13.W Node B Counter Evolutions Base S NS
168710 Enhanced CELL_FACH for DL (3GPP Rel- Optional S NS
7)
119185 TRDU2x60 900MHz multi-standard Optional – S NS
support for 2G & 3G (1PA 2G & 1 PA 3G) Hardware
116232 Path Diversity Support for User Plane on Optional S NS
9370 RNC
120498 LR13.W Call Trace Developments Base S NS
121537 U2100 + U900 Daisy Chaining Base S NS
125406 Monitoring of eCEM and xCEM modem Base S NS
load
125407 Overload protection of Node B digital Base S NS
part (Step 2)
125409 Dynamic overload management of CPU Base S NS
resources on eCEM / xCEM
133975 Hosting of 2 Node Bs WCDMA in one 9926 Optional S NS
d4U
158406 RRH2x60-21A Optional – S NS
Hardware
159290 Multiple RRH per cell : extension for Optional S NS
9926 BBU 4U
159393 Configurable VSWR Alarm Threshold Optional S NS
162520 External alarm logical state inversion Optional S NS
164373 MCTRX67-09 3G in LR Indoor Cabinet Optional – HW S NS
Configuration Configuration
165360 Smart E-DCH resource usage Optional S NS
167400 TRDU2x60-09 WCDMA configurations in Optional – HW S NS

LR indoor cabinet Configuration
167401 TRDU2x60-09 WCDMA configurations in Optional – HW S NS
LR outdoor cabinet Configuration
168556 Traffic filtering in cell overload Optional S NS
120415 RRH2x60-850 & -1900 with 9396 digital Base NS S
units – second PA activation
120494 Node B IP Counters Base NS S
120799 RRH2x antenna cross-connect for 9396 Base NS S
d2U
121018 MCR-B 1900 with HE PAM at 60W Optional – NS S
Hardware
121030 OneBTS PM processor load counters Base NS S
123836 AISG2.0 on 9396-based RRHs Phase 1 Base NS S
123895 9396 d4U activation of additional CPRI Optional NS S
ports
1.4 Audience
The primary audience for this document is Alcatel-Lucent customers. This document
is also intended for Alcatel-Lucent functional and operational teams.
2 RELATED DOCUMENTS
2.1 Applicable documents

None
2.2 Reference documents

[R1] UMT/OAM/INF/036831 Wireless Management System for UTRAN – Feature
Planning Guide OAM09
[R2] UMT/SYS/INF/7906 UMTS4.1 Access Network Feature Planning Guide
[R3] UMT/SYS/INF/12239 UMTS4.2 Access Network Feature Planning Guide
[R4] UMT/SYS/INF/16608 UA05.0 Access Network Feature Planning Guide
[R6] UMT/SYS/INF/022664 UA06 Access Network Feature Planning Guide
[R7] UMT/SYS/INF/025020 UA07 Access Network Feature Planning Guide
[R9] 9YZ-03990-0005-FMZZA Alcatel-Lucent LTE Radio Access Network Release

LA5.0.0 FDD Feature Planning Guide
[R10] UMT/BTS/INF/024180 Alcatel-Lucent 939X W-CDMA Node B Family – Product
Description
3 LR13.W MAIN DRIVERS

Improved Smartphone data traffic management
Enhanced CELL_FACH (Rel-7) offers access to HSDPA resources without need for
transition to CELL_DCH for managing small amount of data or “keep-alive” signaling
messages, therefore providing the following benefits:
• Improved user experience with reduced call setup time and Round Trip Time
(RTT)
• Increased FACH capacity
• Stepping stone to Enhanced CELL_FACH Rel-8 (HS-RACH)
Increase Node B site capacity

• With 9926 d4U supporting:
o up to 6 W-CDMA carriers
o up to 6 modems / 2 controllers per d4u
o up to 12 antenna pairs / 24 cells per d4u
Improved HSPA performances

• +5 – 10% UL user and cell throughput with Improved L2 for UL
• Reduce HSPA call drop rate with reconfiguration between 2ms and 10ms TTI
based on RF conditions
• Increase UL cell throughput with smart allocation of 2ms based on user priority,
device type, MBR and UL data volume
• Improve E-DCH overload handling
Mobility with LTE

• Voice service continuity from LTE to UMTS with CS-handover-like user
experience
4 LR13.W OPTIONAL SOFTWARE PACKAGES

A number of LR13.W features compose the optional software packages as detailed in the
below table.
ID Feature Title SI Code Saleable Offer
89563 Improved L2 for uplink 3JR 35053 AF Enhanced
CELL_FACH for
Smartphones
168710 Enhanced CELL_FACH for DL (3GPP Rel-7)
159246 Direct PCH to DCH Transition Enhancements 3JR 35029 AE Smartphone
experience
120363/ Smart E-DCH resource usage 3JR 35051 AF HSUPA LR13.W
165360 Performance
Features
126055 UL radio overload handling enhancements
83659 VoIP from LTE VoIP to WCDMA CS Continuity 3JR 35033 AE added to "Mobility
(VCC) to LTE"
155968 Cell load exchange for inter-RAT mobility from
LTE
127550/ Traffic filtering in cell overload 3JR 35006 AD added to "Mobility
168556 & Traffic Balancing"
98448 Access Class Barring (ACB) at Cell Granularity 3BK 33900 DF added to "Access
Class Restriction"
120416 IuPC Interface Enhancements 3BK 33900 BF added to "Advanced
Location Services”
134302 CBS enhancements for UE battery savings and 3BK 33900 BW added to "UTRAN
increased service reliability Broadcast services"
33648 Support of 24 cells per Node B 3JR 35004 AA included within RF
Carrier Activation
111041 Support of 12 antenna pairs
103774 3G only support of RRH2x40-09 (w/o 3JR 35045 AC MC-TRX / MC-RRH
dependency to 2G) 3G Carrier
Activation
133975 Hosting of 2 Node Bs WCDMA in one 9926 d4U 3JR 35004 AA included within RF
Carrier Activation
159290 Multiple RRH per cell : extension for 9926 BBU 3JR 35048 AE Multiple RRH per
4U cell
162520 External alarm logical state inversion
121337 RNC capacity evolution with eDCPS 3BK 33543 AE eDCPS LR13.W
increased capacity
RTU
121378 Enhanced Flexible RAB/TMU role assignment 3JR 35054 AE RNC Signaling load
management
100791 BTS daisy chaining through the Node B 3JR 35056 AF Node B Ethernet
Hub Option
103182 Ethernet OAM in the Node B 3BK 33920 AA added to "Hybrid
3JR 35012 AA ATM IP Iub" & "All IP
Iub" packages
113326 Node B Synchronisation Enhancements
116232 Path Diversity Support for User Plane on 9370 3BK 33920 AD added to "RNC Iu-
RNC 3JR 35013 AA PS+ Iu-CS+ Iur over
3JR 35014 AA IP" packages
123895 9396 d4U activation of additional CPRI ports 3BK 33922 AF Activation of CPRI
4-6 on 9396 D4U
159393 Configurable VSWR Alarm Threshold 3JR 35057 AF Configurable Alarm
Threshold for IDAS
5 LR13.W FEATURES DESCRIPTION
5.1 BASELINE
115558 – LR13.W 3GPP Baseline
FEATURE DESCRIPTION
Alcatel-Lucent LR13.W software releases is built upon the following 3GPP baseline:
• 3GPP release: Rel-9
• 3GPP specification version: December 2010

This baseline applies to all supported UTRAN external interfaces.
FEATURE BENEFITS
Making use of a recent 3GPP baseline & implementing all the essential changes (CRs)
approved by 3GPP beyond this baseline ensures that Alcatel-Lucent UMTS solution reaches a
high quality level both regarding the behaviour of Alcatel-Lucent UTRAN products for handling
UMTS features (RNC, BTS) & regarding multi-vendor interoperability.
IMPACTED SYSTEMS
Node B, RNC
DEPENDENCIES
Hardware
Support S S S
HW requirements None None None
Software feature
No dependency. On the contrary, this feature is an input to all the LR13.W
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
OPERATIONAL REQUIREMENTS
Counters
None
Configuration Management and Parameters
None
Fault Management and Alarms
None
FEATURE TYPE
Base
5.2 PERFORMANCES AND CAPACITY

89563 – Improved L2 for uplink
FEATURE DESCRIPTION
To overcome the limitations of fixed PDU size, 336 or 656 bit PDU size, the standardization
body has introduced in Rel-8 a new feature, Enhanced Layer 2 for uplink, similar to its
downlink counterpart in Rel-7 (see feature 34388 – L2 Improvements support: flexible RLC and
MAC-ehs [R7]). The feature includes a flexible RLC PDU size and a new MAC entity (MAC-i/is).
Enhanced layer 2 for uplink is applicable to HSPA users in CELL_DCH state and to users in
CELL_FACH state with Enhanced Uplink CELL_FACH.
FEATURE BENEFITS
Enabler for Enhanced CELL_FACH Rel-8

Higher UE and cell throughput in UL
IMPACTED SYSTEMS
RNC, Node B, OAM
DEPENDENCIES
Hardware
Support S S NS
HW requirements None xCEM(-u), eCEM(-u) N/A
Software feature
None
Rel-8 UE supporting MAC i/is
Standards
3GPP Rel-8
None
ENGINEERING IMPACTS
None
Counters
3 new RNC counters are introduced to provide statistics on the occurrence of
flexible PDU size, on the UE transmitted PDU size and to counts the number of
successful reconfigurations between MAC-i/is and other MAC entities.
The feature has an activation flag at the RNC and Cell level. New parameters are
introduced to control the minimum and maximum PDU sizes for different services.
Upon feature activation, an alarm is sent to the OMC in case the Node B has no MAC-
i/is capability.
FEATURE TYPE
Optional
168710 – Enhanced CELL_FACH for DL (3GPP Rel-7)
FEATURE DESCRIPTION
Today’s 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.
With eFACH DL, or HS-FACH, introduced in 3GPP Rel-7, FACH is mapped to HS-DSCH physical
channel. Parameters for HS-DSCH reception in CELL_FACH state are broadcasted in the system
information broadcast (SIB).
FEATURE BENEFITS
Improved call setup time
Increased FACH capacity
Reduced Round Trip Time (RTT) in CELL_FACH
IMPACTED SYSTEMS
RNC, Node B, OAM
DEPENDENCIES
Hardware
Support S S NS
HW requirements None eCEM(-u) N/A
Software feature
None
Rel-7 UE supporting HS-FACH (Common HS-DSCH)
Standards
3GPP Rel-7
None
ENGINEERING IMPACTS
HS-DSCH resources shared between CELL_FACH and CELL_DCH users.
Counters
Several new counters are introduced to monitor HS-FACH capacity and throughput.
The feature has an activation flag at the RNC and cell level. Several new parameters
are introduced to configure the feature (>100). 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
Optional
120363/165360 – Smart E-DCH resource usage

FEATURE DESCRIPTION
120363 contains the part of the feature delivered in LR13.1 and 165360 contains the part of
the feature delivered in LR13.3. The text below describes the full feature, the portion missing
in LR13.1 being mentioned in the “restriction/limitation” section.
This feature brings new control capabilities to the operator for the control of the E-DCH TTI.
Most UEs now support the 2 ms TTI, which potentially opens the door to higher bit rates than
the 10 ms TTI. 2 ms TTI also benefits from a lower round trip time than 10 ms, thus may
improve latency. However, 2 ms TTI consumes more resources, both in terms of processing
and in terms of UL interference (because of the control channels). The cell throughput thus
becomes higher if 10 ms TTI is used in presence of a high number of E-DCH users. 2 ms TTI
latency and high bit rate potential benefits may also not be always visible, depending on what
E-DCH is used for. Furthermore, calls setup on 2 ms TTI are more prone to call drop, e.g.
because of the higher power they require from the UE.
It is thus interesting for the operator to have good control over which UEs benefit from the 2
ms TTI.
Feature 120363, “smart E-DCH resource usage”, provides fine control mechanisms for the E-
DCH TTI allocation. The allocation criteria encompass the following parameters:
Radio conditions: it is recommended to use 2 ms only in good radio conditions, in
order to limit the risk of call drop. In the previous releases, radio conditions were
already taken into account for the TTI allocation (refer to feature 125855 - E-DCH
call retainability improvements [R8]). However, radio conditions were evaluated at
RAB setup time based on Ec/N0 and load condition. Feature 120363 enhances the
load condition check by selecting only 10 ms TTI as soon as either the UL cell load
color reaches the configured limit, or the number of active users reaches the
configured limit. It also introduces an additional check possibility, based on macro-
diversity situation, which may be useful in some low density areas (in dense areas,
the cell radius is short, to cope with high density of users, so that the macro-
diversity condition is not an indication of poor radio conditions, especially in UL): if
this possibility is activated, as soon as the UE enters Soft Handover condition, it is
reconfigured to 10 ms TTI. The TTI will be reconsidered after timer expiry. Note
that this reconfiguration case only applies to Soft Handover, not Softer Handover
condition, because contrary to Soft Handover, Softer Handover is not an indication
that the UE is at NodeB coverage limit and could thus need a lot of UL power.
Note that SRB is configured to DCH when radio conditions lead to select 10 ms TTI.
RAB combinations: As CS call drop KPIs are of particular concern for the operators,
feature 120363 avoids the use of 2 ms TTI for the case of CS+PS (this is reused from
125855 feature in UA08.1 [R8]).
Traffic volume: 2 ms offers higher bit rate potential. It may thus be an objective of
the operator to preferably allocate 2 ms TTI to UEs that do use a high bit rate.
Feature 120363 introduces a double mechanism to help achieving this objective.
The traffic volume is first a priori evaluated, based on the maximum bit rate
indicated by the Core Network at RAB setup time (only high values of MBR will be
eligible to 2 ms TTI, if the operator decides it). In a second step, the RNC will check
what data volume is really sent by the UE. If it is not as high as expected, the UE
can reconfigure the TTI to 10 ms (while the UE is in CELL_DCH state). Conversely,
the RNC may reconfigure the TTI to 2 ms if an eligible UE currently configured with
10 ms uses a high bit rate. A hysteresis is introduced to avoid too frequent
reconfigurations.
UE priority: The operator may wish to reserve 2 ms TTI to high priority users.
Feature 120363 introduces this flexibility.
TTI control mechanisms were already introduced in previous releases (notably thanks to
125567 - E-DCH enhanced Node B CAC [R8] or 82602 - E-DCH user and cell throughput increase
[R8]), and the Node B already has the possibility to refuse an E-DCH call setup requested by
the RNC using 2 ms TTI. This is then followed by a call setup using 10 ms TTI. This however
requires 2 NBAP messages (typically Radio Link Setup Request followed by Radio Link Setup
Failure) that would be avoided if the RNC could choose directly the proper TTI. Feature
120363 introduces a mechanism to reduce the risk of choosing a TTI that the Node B will not
be able to accept, thus improving call setup time and reducing the signaling load as well as
the CPU consumption. When the Node B can no longer accept 2 ms TTI, it informs the RNC of
that situation, thanks to an NBAP Resource Status Indication message. The RNC then stops
asking for 2 ms TTI. Conversely, when the load decreases and again allows use of 2 ms TTI,
the Node B informs the RNC of the new conditions, and the RNC restarts asking for 2 ms TTI
for eligible UEs. A guard timer is used so that around the limit, the situation does not change
too quickly (no “ping-pong” effect).
In addition to TTI control, feature 120363 also introduces an improved initial grant allocation
mechanism, based on buffer measurements reported by the UE (Total E-DCH Buffer Size:
TEBS). If these measurements do not indicate that the UE has a large amount of data to
transmit, the Node B will not allocate a large grant, regardless of the “happy bit” sent by the
UE. This smoothes bursts of data that are otherwise seen. By allocating grant according to the
amount of data in the buffers, E-DCH resource is better shared and the capacity is increased.
The traffic generated by most UEs (smartphones in particular) requires limited amount of
data to be transmitted in UL and does not justify large grants.
Last but not least, feature 120363 adds a number of counters to help follow up of the usage
of 2 ms and 10 ms TTI for E-DCH.
FEATURE BENEFITS
The feature is expected to improve call drop KPIs, and to increase user satisfaction (higher
throughput to users who need it).
IMPACTED SYSTEMS
RNC, Node B, OAM
DEPENDENCIES
Hardware
Support S S S(*)
HW requirements None xCEM(-u), eCEM(-u) UCU-III
(*) Improved initial grant allocation mechanism based on TEBS and Improved
radio conditions on TTI selection corresponding to ID 165360 not supported
Software feature
82602 - E-DCH user and cell throughput increase [R8]
Optional dependency to 125567 - E-DCH enhanced Node B CAC [R8]
This feature applies to UEs supporting E-DCH.
Standards
Interfaces are based on use of 3GPP release 9. No specific feature of release 9
is however required from UE or CN here.
Improved initial grant allocation mechanism based on TEBS will only be available in
LR13.3W and is not supported on 939x Node B.
Improved radio conditions on TTI selection will only be available in LR13.3W and is
not supported on 939x Node B.
ENGINEERING IMPACTS
Parameters tuning
Counters
Distribution of E-DCH UE categories (according to the UE information provided in the

RRC Connection Setup Complete message)
Number of retransmissions of MAC-e PDUs per TTI on serving cell
Number of E-DCH users per TTI and per cell (based on RL setup, RL add, RL Reconf)
Number of E-DCH users per TTI and per modem board (based on RL setup, RL add,
RL Reconf) (iBTS)
Distribution of E-TFCI per E-DCH UE category
Pegging per TTI for number of Radio Links established per cell
Global feature activation flag
Flag for activating the TTI selection according to traffic volume, associated rate
threshold
Flag for activating the TTI selection according to radio conditions (using Ec/N0,
RSCP, SIR error, noise rise) and load (using cell color, number of active E-DCH
users), associated thresholds
Flag for activating TTI selection according to QoS criteria and associated TTI
mapping table per QoS entry
Flag for activating TTI selection according to Soft Handover condition
Flag for activating TEBS measurements
Flag for activating TTI capability resource status indication message

Guard timers (to avoid TTI too frequent toggle)
None
FEATURE TYPE
Optional
126055 – UL radio overload handling enhancements

FEATURE DESCRIPTION
Up to recently, focus on UL radio features has often been on achieving best possible
performance in terms of user throughput. This objective is appropriate when facing a
relatively small UL cell load. It however leads to algorithms and parameters that may not be
optimized for high UL cell load situations. With data explosion, the UL cell load is now getting
most of the time too high and parameter setting and/or algorithms need to be revisited to
accommodate this growing load.
This Feature introduces several E-DCH improvements aiming at optimizing capacity. It also
represents a step in self-tuning the network as a function of the load: for low load, high user
throughput is targeted whereas for high load, the focus is put on capacity.
Initial grant handling: Currently, the initial grant (which defines what the user is
allowed to send on E-DCH before the Node B control loop regulates its flow) ensures
that the user can send sufficient data to achieve a minimum duration when sending
a "ping". In the case of a congested cell, this may lead to new comers being allowed
to send more data than already present users and contributes to further increasing
the UL congestion. This feature aims at adjusting the initial grant according to the
load situation: keeping it relatively high for non-congested situations, and setting a
minimal value in an UL-congested situation.
Switch off some HARQ processes in overload situation: 3GPP offers the possibility
to switch off some E-DCH HARQ processes when 2 ms TTI is used. This feature
introduces the capability to use this option in the scheduler in order to reduce the
load when the Node B detects overload.
Avoid “0 grant”: Prior to this feature, the scheduler already decreases the grants
when a cell is in an overload situation. In the serving cell, the decrease is limited by
the minimum grant, which aims at maintaining the communication between RNC
and UE. In the non-serving cell, the scheduler using a “relative grant” instructs the
UE to decrease its grant. If the UE receives a relative grant requesting a decrease
whilst the UE is already at minimum grant, the UE can no longer transmit user data,
in particular acknowledgements from DL traffic. This may lead to call drops. This
feature provides the mean to get out of this situation by reallocating an Absolute
Grant to UEs that indicate in their Scheduling Information control message that they
can no longer transmit user data.
FEATURE BENEFITS
The feature is expected to improve call drop KPIs, and improve network capacity.
IMPACTED SYSTEMS
Node B, RNC, OAM
DEPENDENCIES
Hardware
Support S S S
HW requirements None xCEM(-u), eCEM(-u) UCU-III
Software feature
None
This feature applies to UEs supporting E-DCH.

Standards
Interfaces are based on use of 3GPP release 9. No specific feature of release 9
is however required from UE or CN here.
None
ENGINEERING IMPACTS
None
Counters
None
Optimized Initial grant usage activation flag

Harq process reduction activation flag and associated timer between changes
None
FEATURE TYPE
Optional
159246 – Direct PCH to DCH Transition Enhancements

FEATURE DESCRIPTION
This feature introduces the two following evolutions to the Direct transition from PCH to DCH
feature (108389) [R8] delivered in UA08.1:
1. Support of SRB 13.6k + PS 0/0 to improve CS call setup time when transitioning
directly from URA_PCH (or CELL_PCH) to CELL_DCH (108389). In UA08.1, SRB 3.4k +
PS 0/0 is used in such scenario.
2. Support of unconditional URA_PCH (or CELL_PCH) to CELL_DCH Direct Transition (DT)

where no parameter checking is performed (Traffic Volume Indicator or Establishment
Cause) for most of the traffic type and for both UL and DL.
FEATURE BENEFITS
1. The introduction of SRB 13.6k + PS 0/0 reduces CS call setup time to provide similar
performance as from Idle.
2. The support of unconditional DT increases URA_PCH to CELL_DCH usage (thereby

decreasing the amount of CELL_FACH usage) and therefore call setup success rate and
setup time as well as retainability are improved for all users regardless of traffic
activity.
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
Support S S S
Software feature
26673 - URA_PCH [R4]
26675 - CELL_PCH [R4]
SRB 13.6k + PS 0/0 can be used with any PCH to DCH DT mechanism, either the
one introduced with feature 108389 [R8] or unconditional DT as described here
above.
None
Standards
None
None
ENGINEERING IMPACTS
None
Counters
No new counter. Existing counters which are pegged for direct PCH to DCH
transitions (108389) are also pegged by this feature
This feature makes use of two activation flags, one for each sub-feature. These flags
are at the RNC level.
None
FEATURE TYPE
Optional
5.3 SERVICES AND RADIO RESOURCES MANAGEMENT

120416 – IuPC interface enhancements
FEATURE DESCRIPTION
IuPC is the interface between the RNC and the SAS (Standalone SMLC). SMLC stands for
Serving Mobile Location Center. In the previous software releases, Alcatel-Lucent RNC
supported a proprietary implementation of the IuPC interface. This interface was based on
ATM transport technology with a proprietary protocol stack at transport layer (called TAL). At
application layer, the RNC-centric mode of operation was supported. This means that the RNC
determines, initiates and controls the positioning method to be used for each positioning
request coming from the Core Network. However it does not interwork with SAS from other
vendors not supporting the RNC centric mode or the ALU proprietary TAL interface.
The scope of the current feature is to introduce the support of the standard IuPC interface
implementation in the RNC as defined by the 3GPP in TS 25.452 and 25.453. This allows the
RNC to interwork with any SAS from 3rd party vendors which is compliant with the 3GPP
standards. The evolutions introduced by this feature can be divided into two parts:
1. Transport part:
This part of the feature provides the capability for the RNC to support the Iu-PC interface
directly over IP/Ethernet according to 3GPP TS 25.452.
The figure below shows the evolution introduced at the transport layer to evolve from a
proprietary transport protocol stack over ATM to a 3GPP standard transport protocol stack
over IP.
Figure 1: IuPC transport protocol stack
The new implementation supports the connectivity of the RNC towards two different SAS for
redundancy purpose. Both SAS are represented by a single Point Code (PC) and are operating
in active-active mode. Load sharing is assumed at the M3UA layer between the two SAS, i.e. a
single transaction is handled by a specific SAS; but different transactions are distributed
across the two SAS. When SCTP connectivity is lost to one of the SAS, the remaining SAS is
used to handle any future location request. Existing transactions to the unreachable SAS
(where SCTP connectivity has been lost) are assumed to be interrupted and failure of any
transactions currently in progress on that SAS is handled at the application layer. Symmetrical
multi-homing is supported on the IuPC interface.
The TAL proprietary protocol stack used for already deployed markets will coexist with the
new implementation. However, for a single RNC, only one transport protocol stack is
supported at the same time.
2. Application part:
This part introduces all the standard functionalities at the upper layers in order for the IuPC
interface in the RNC to be compliant with 3GPP TS 25.453 version 7.12. The introduced
enhancements allow the interaction between the RNC and the SAS in a SAS-Centric mode of
operation. In this mode, the SAS determines, initiates and controls the positioning method to
be used for each positioning request. The RNC executes the requests sent by the SAS.
RNC-centric mode is maintained for already deployed networks but RNC-centric mode and
SAS-centric mode are mutually exclusive on the same RNC and at the same time.
The RNC is able to exchange information on UE positioning whatever the UE location; meaning
whatever the UE is under SRNC cell or DRNC cell.
The three Location Services methods, Basic Cell ID, Enhanced Cell ID/RTT (ECID/RTT) and UE
based A-GPS, are supported over IuPC. Any request by the SAS for another location method
will be rejected by the RNC.
Based on the network and UE capabilities, the switchover from A-GPS to ECID/RTT to Basic
Cell ID methods is requested by the SAS and supported by the RNC in the case of the SAS-
centric mode introduced by the current feature.
The support of the procedures that were introduced in previous software releases for the case
of the iSMLC solution (Alcatel-Lucent Integrated SMLC functionality inside the RNC) are
extended to the current feature; mainly the support of RTT over IuR and the move of the
Reference Time element of the A-GPS assistance data to the first RRC Measurement Control
message.
FEATURE BENEFITS
This feature allows the Alcatel-Lucent RNC9370 to interwork with all the 3rd party SAS
compliant with the 3GPP standards. Depending on the country and the operator’s strategy,
the requirement to have an open IuPC interface may be:
• a regulatory requirement: where the SAS supplier is selected by the local authorities
and all the operators are obliged to have their RANs interworking with that SAS.
• an operator requirement: in order to homogenize the location services strategy over

all its technologies and equipments suppliers.
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
Support S S S
HW requirements 4ptGigE boards None None
Software feature
24089 - Enhanced Cell Coverage positioning with RTT [R6]
117014 - RTT support over Iur [R8]
27615 - GPS Assistance data developments [R7]
116687 - Reference Time Forwarding for AGPS [R8]
25027 - Advanced Location Services [R6]
34406 - UTRAN Positioning For Low-Delay Requests [R7]
34582 - UE Positioning Information to CTg and CTb [R8]
Standalone SMLC (SAS)
Standards
3GPP TS 25.450 UTRAN Iupc interface general aspects and principles
3GPP TS 25.451 UTRAN Iupc interface layer 1
3GPP TS 25.452 UTRAN Iupc interface signalling transport
3GPP TS 25.453 UTRAN Iupc interface Positioning Calculation Application Part
(PCAP) signaling
3GPP TS 25.305 Stage 2 functional specification of UE positioning in UTRAN
At application layer:
• UE-assisted A-GPS mode is not supported
• Periodic measurements are not supported
• Fallback mechanism to iSMLC is not supported

• Only UE based A-GPS, Basic Cell ID and Enhanced Cell ID (RTT) location
methods are supported. Any other location method requested by the SAS
will be rejected by the RNC
At transport layer:
• Separate subnet is used for IuPC. No support of shared subnet with other
RNC Iu or Iur interfaces.
• In case of SAS redundancy, both SAS work in Active-Active mode. No support
of Active-Standby mode.
• ASP and IPSP modes are supported at M3UA layer. The SGP mode is not
supported on the RNC.
• RFC3332 only is supported. RFC4666 is not supported. However, no major

interworking issues are expected, since implementations based on RFC4666
are assumed to be backward compatible with RFC3332 implementations.
• Even though the architecture supports multiple SCTP associations per SAS,
the testing and validation is limited to a single SCTP association per SAS.
• IPv4 is assumed. No support of IPv6.

ENGINEERING IMPACTS
Additional IP addresses needed to be configured in the RNC with separate subnet.

Counters
At application layer: new counters are introduced and some existing counters are
modified. Detailed list can be found in the corresponding System Domain
Specification (SDS).
At transport layer: SCTP counters are currently available per SCTP association; these
counters are applicable on IuPC interface.

New parameters are introduced at both application and transport layers to configure
the feature such as the possibility to select which location method is activated
among UE Based AGPS or CellID /RTT.
Detailed parameters list can be found in the corresponding System Domain
Specification (SDS).
No new alarms but re-use of existing ones at both application and transport layers.
FEATURE TYPE
Optional
127550/168556 – Traffic filtering in cell overload

FEATURE DESCRIPTION
127550 contains the part of the feature delivered in LR13.1W and 168556 contains the part of
the feature delivered in LR13.3W. The text below describes the full feature, the portion
missing in LR13.1W being mentioned in the “restriction/limitation” section.
This feature allows rejecting low priority service while allowing high priority service to
establish on the originating cell, for UE coming from idle mode or CELL_PCH/URA_PCH RRC
connected states.
UE COMING FROM IDLE MODE
New basic call types are created for:
• MO & MT Low Priority Signaling (SMS),

• MO & MT High Priority Signaling,
• Registration,
• Subscribed Traffic Call,

• Detach,
• Call re-establishment
For a configurable percentage of basic & group call types, it is possible to trigger load
balancing or immediate rejection, based on:
• Existing condition such as load color
• New condition as introduced by this feature, i.e. based on Call Admission Control
failure rate and Arrival rate of calls in idle or connected states
UE COMING FROM XXX_PCH STATES
For UE coming from XXX_PCH states, this feature creates a dedicated & simple framework
which manages RRC cell update message sent by UE, to reject low priority services and to
allow high priority service to be processed on the originated cell.
• As input of the algorithm, the Establishment Cause in the RRC cell update message
(Rel-5) determines the service type
• For a given service, it is possible to reject a configurable percentage of calls, based

on the same conditions as described for the idle mode case above.
If the service is not rejected by this feature, it will then handled by the existing iMCTA
feature.
This feature also introduces a trigger for Access Class barring functionality (feature 98448),
which uses the similar framework to decide whether to activate/deactivate ACB feature
based on the conditions as described for the idle mode case.
FEATURE BENEFITS
Increase high priority services (such as CS speech call and SMS) call setup success rate when
cell is overloaded
Reduce potential scale of the RRC storm
Save additional RNC processing in cell overload
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
Support S S S(*)
(*) Improved definitions of Basic Call Type & Group Call type based on
establishment cause including signalling only types (SMS, RRE, and Registration)
as well as Call Upsize filtering from URA_PCH corresponding to ID 168556 are
not supported.
Software feature
89857 – iMCRA - traffic balancing at RRC connection establishment with

Programmable Actions Matrix [R8]
89858 – iMCTA Enhanced with HSPA Load – Blind HHO – Direct HHO on AO Upsize
[R8]
98448 – Access Class Barring (ACB) at Cell Granularity
None
Standards
None
Improved definitions of Basic Call Type & Group Call type based on establishment
cause including signalling only types (SMS, RRE, and Registration) as well as Call
Upsize filtering from URA_PCH are available only from LR13.3W on and are not
supported on 939x Node B.
ENGINEERING IMPACTS
None
Counters
The iMCRA/iMCTA counter set is improved to allow monitoring of the new procedure
Parameters are introduced to activate and configure the feature

None
FEATURE TYPE
Optional
134302 – CBS enhancements for UE battery savings and increased service

reliability
FEATURE DESCRIPTION
This feature introduces three main enhancements to the existing Cell Broadcast Service
available in Alcatel-Lucent products.
1. In the previous releases, the maximum length of the Scheduling Message was fixed
(hardcoded to 40 Bock Sets) and dictated the total number of CTCH Block Sets that have
to be reserved for the Scheduling Message, without considering resource constraints on
the RNC and UE. That caused the UE to invoke RRC layer to start reception of all 40 CTCH
Block Sets despite that many of them did not contain any scheduling data, causing
reduction in the battery life cycle of the UE. The current feature enables the adjustment
of the size of the Schedule Message. The size of the Schedule Message will fluctuate
based on the amount of broadcasted data. This allows the UE to reduce battery
consumption.
2. In the previous releases, collisions were noticed between CTCH and BCCH/CCCH on
SCCPCH#2. This leaded to the loss of some CTCH blocks and hence to the loss of the CBS
message. This is critical when CBS is used for CMAS (Commercial Mobile Alerting System).
The current feature prioritizes the CTCH traffic over the BCCH/CCCH and hence avoids
the loss of CBS messages.
3. In the previous implementation of CBS in Alcatel-Lucent product, when the first CBS alert
arrives after the Schedule Message (SM) of the DRX period (n), the CBS alert is scheduled
in the DRX period (n+2) instead of (n+1) and hence, the transmission of the alert is
delayed until DRX period (n+3). With the current feature enhancement, the first CBS alert
is always scheduled in DRX period (n+1) and sent in the DRX period (n+2) even if it arrives
after the SM of the DRX period (n) – see figure below.
Figure 2: CBS alert message scheduling
FEATURE BENEFITS
This feature extends the UE battery life cycle when the UE is receiving CBS messages.
It also increases the reliability of the CBS messages delivery by reducing the CBS block loss
and reduces the delivery delay of CBS messages. This becomes very important when CBS is
used to deliver alerting messages, i.e. when an operator uses CBS for the Commercial Mobile
Alerting System (CMAS).
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
Support S S S
Software feature
21092 - Cell Broadcast Services (CBS) [R4]
34442 - SMS Cell Broadcast (new Market support) [R7]
UE supporting CBS
Standards
None
None
ENGINEERING IMPACTS
Since this feature prioritizes CTCH over BCCH/CCCH, there may be some delay in
call setup. The probability of occurrence of such delay is proportional to the CTCH
traffic. To reduce the delay impact, the CTCH traffic should be minimized.
Counters
None
One parameter to activate the feature

One parameter to enable the dynamic adjustment of the size of the Schedule
Message (SM).
None
FEATURE TYPE
Optional
5.4 MOBILITY
83659 – From LTE VoIP to WCDMA CS Continuity (VCC)
FEATURE DESCRIPTION
This feature provides support of the SRVCC procedure as defined in 3GPP to enable handover
of IMS VoIP calls from LTE to the UMTS CS domain.
The mobility handling of VoIP bearer from LTE to UTRAN is covered in 3GPP standard TS
23.216, part related to 3GPP GERAN/UTRAN SRVCC.
In case of SRVCC from E-UTRAN to UTRAN, the target RNC can reject the RANAP Relocation
request if there is no resource available in target RNS to support the incoming call. As for 2G
to 3G handover for CS domain the resource allocation for incoming relocation from 4G follows
the same algorithm as for initial call setup resource allocation, i.e. there is no pool of
reserved capacity for incoming relocation from 4G.
In case of CS+PS handover, partial relocation for PS data sessions can be applied if activated
(Please refer to feature 108661 – LTE to UMTS PS HO and cell reselection Enhancement [R8]).
This feature requires the support of Sv interface between MME and the SRVCC enhanced MSC
server in W-CDMA.
FEATURE BENEFITS
SRVCC to UTRAN provides voice call continuity with CS-handover-like user experience from
LTE to UTRAN
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
Support S S S
Software feature
Optional dependency to LTE feature L92126 - SRVCC Support to UTRAN [R10]
UE supports SRVCC
Core Network enhanced with SRVCC functionality supports Sv interface (MSC,
MME & SGSN)
Standards
3GPP Rel-9
None
ENGINEERING IMPACTS
None
Counters
Counters are introduced to monitor the success rate of the SRVCC procedure
Parameters are introduced to activate and configure the feature.

None
FEATURE TYPE
Optional
155968 – Cell load exchange for inter-RAT mobility from LTE

FEATURE DESCRIPTION
The RAN Information Management (RIM) function is a generic mechanism that allows the
request and transfer of information between two RAN nodes. The RIM mechanism allows
starting, stopping and resuming, both on demand and on event, transfer of information. RIM
also provides native error handling function at RIM level and at RIM application level. The RAN
requesting the information is called the controlling RAN, the RAN providing the requested
information is called the serving RAN.
In UA08.1, with feature 115109 - CS fallback enhancement from LTE to UMTS: enhanced
Redirection [R8], the controlling RAN was the eNodeB and the serving RAN was the RNC.
This feature allows the RNC, as serving RAN, to send inter-RAT cell load information to
eNodeB, acting as controlling RAN, using RIM protocol. This information is used to improve
load balancing in case of inter-RAT mobility from LTE to UTRAN, preventive off-loading or CS
fallback triggering (eCSFB procedure, SRVCC and LTE to UMTS PS Handover procedure based
CSFB or not & redirection).
The application identity within the SON Transfer application is Event-Triggered Cell Load
Reporting; meaning this procedure is event-triggered (e.g. as stated in the 3GPP TS 36.413
Rel-10, RNC sends a report each time the cell load crosses a reporting level). Hence, RIM
multiple reports are supported.
FEATURE BENEFITS
This feature provides UTRAN load information to the eNodeB, so that LTE to WCDMA load-
balancing and voice continuity procedures can be triggered to the most adapted UTRAN
carrier.
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
Support S S S
Software feature
Optional dependency to LTE feature 155912 - Target cell load consideration for
IRAT mobility to WCDMA
Core network shall support the RIM procedure

Standards
3GPP Rel-9 & Rel-10
None
ENGINEERING IMPACTS
None
Counters
The counter set related to RIM handling is updated to cover the new procedure.
Parameters to activate the feature and to tune the behavior of the RIM reporting are
provided.
None
FEATURE TYPE
Optional
5.5 TRANSPORT AND TRANSMISSION CAPABILITIES

97427 – Local Node B Iub E-DCH congestion control enhancements
FEATURE DESCRIPTION
This feature brings the following enhancements:
• A new method for local Node B E-DCH congestion control is introduced. The new
method is based on egress queue occupancy monitoring. Node B E-DCH grants are
adjusted as a function of queue occupancy monitoring in addition to packet drop
detection. This allows reacting earlier to a potential UL Iub congestion status, trying
to avoid packets to be lost in the egress buffers that can lead to TCP throughput
reduction.
• The E-DCH throughput is only reduced if congestion is detected on the Node B egress
queue where E-DCH traffic is mapped. In case there are several Bandwidth Pools
carrying E-DCH traffic and only one of them is congested, then only the E-DCH users
using this bandwidth pool will have the throughput reduced.
FEATURE BENEFITS
This feature allows to optimize the Iub bandwidth usage and to improve the end user
experience by avoiding uplink packet losses in the Node B egress buffers in case of Iub
congestion.
IMPACTED SYSTEMS
Node B
DEPENDENCIES
Hardware
Support S S NS
HW requirements None xCCM(-u); eCCM-u N/A

xCEM(-u); eCEM(-u)
Software feature
None
None
Standards
None
For configurations based on 4E1/T1 or 12E1 MDA there is at most one Ethernet
Bandwidth pool with support of 8 EP.
When this feature is activated (and edchLocalCongestionControlActivation is True),

it supersedes the previous mechanism introduced with feature 75786 – Local Node B
E-DCH congestion control [R6] and its extension to IP transport with feature 34559 –
Advanced traffic management solution [R7].
When this feature is not activated (and edchLocalCongestionControlActivation is

True), the previous mechanism of feature 75786 is changed since internal changes
are implemented to provide some optimizations.
For ATM case, management of queue occupancy thresholds is not supported and the
feature relies only on queue overflow with some optimizations versus the previous
implementation.
ENGINEERING IMPACTS
None
Counters
New counter to monitor the total number of 3GPP User Plane IP packets belonging
to a particular Emission Priority queue transmitted on IP Iub interface.
New counter to monitor the total number of 3GPP User Plane octets including
framing characters transmitted on the IP Iub interface associated with a particular
Emission Priority queue.
Feature activation parameter

“IP QUEUE OVERFLOW” alarm is modified

FEATURE TYPE
Base
100791 – BTS daisy chaining through the Node B

FEATURE DESCRIPTION
This feature allows the 3G Node B to act as an Ethernet switch and to daisy chain the
Ethernet traffic from a second 2G, 3G or 4G base station. With this feature the 3G Node B is
the only one requiring an Ethernet interface to the backhaul.
The hub 3G Node B is able to propagate frequency synchronization to the daisy chained base
station through Synchronous Ethernet. The reference clock can be any of the synchronization
sources allowed for the 3G Node B (GPS, IEEE1588v2, SyncE, etc). The daisy chained base
station may as well use its own independent synchronization source.
Figure 3 to Figure 5 show the daisy chaining configurations supported by the current feature.
BSC
Common Packet
Backhaul
2G BTS 3G Node-B
RNC
Figure 3: Example of 2G BTS with Abis over IP/Ethernet daisy chained through the 3G
Node B
Common Packet
Backhaul
3G Node-B
3G Node-B
RNC
Figure 4: Example of a 3G Node B daisy chained through the 3G Node B
3G Node-B BSC
4G eNB RNC
Common Packet
Backhaul
MME
S-GW
Figure 5: Example of a 4G eNode B daisy chained through the 3G Node B
FEATURE BENEFITS
This feature allows using a single Ethernet backhaul interface for sites with multiple base
stations (it avoids using an external Ethernet Aggregator).
IMPACTED SYSTEMS
Node B
DEPENDENCIES
Hardware
Support S S NS
HW requirements N/A xCCM(-u) equipped N/A

with GE MDA
eCCM-u equipped
with GE MDA
Software feature
27649 - Native IP Iub [R7]
113326 - Node B synchronization enhancements
Only 2G, 3G and 4G Alcatel-Lucent base stations are supported as daisy chained
nodes.
Standards
None
Only Alcatel-Lucent base stations supported as daisy chained nodes.

In case of 3G Node B failure or reset the daisy chained traffic will be interrupted.
This feature is not compatible with the use of IEEE803.3ah (EFM) introduced in the
Node B with feature 103182 - Ethernet OAM in the Node B.
ENGINEERING IMPACTS
Traffic shaping shall be configured in the daisy chained base station (egress
direction) or in the transmission network (ingress direction) in order to ensure that
the daisy chained traffic conforms with the transport network available SLA and will
not affect the QoS of locally originated/terminated traffic.
The aggregated traffic (local and daisy chained) shall be dimensioned in order to
ensure that it remains within the capacity of the 1GE interface.
Counters
New counters introduced to count the traffic and number of ingress/egress daisy
chained Ethernet frames.
Feature activation parameter
Possibility to name the backhaul and the daisy chain ports
New alarms to indicate failure in daisy chained port

FEATURE TYPE
Optional
103182 – Ethernet OAM in the Node B

FEATURE DESCRIPTION
Due to the increasing prevalence of Ethernet in carrier networks, wireless operators are now
adopting Ethernet as the preferred transport technology in the UTRAN. However, when
Ethernet standard was originally developed, it was never designed as a bridged WAN transport
technology and therefore it has always lacked robust mechanisms to detect, verify, and
isolate Ethernet connectivity failures. Various standards bodies have addressed these
particular deficiencies, resulting in a series of standards in the area of Ethernet OAM.
Specifically, the following standards have now been developed by the ITU-T and IEEE
standards bodies:
• IEEE 802.3-2008: Part 3: Carrier Sense Multiple Access With Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications - Section Five – Chapter
57 (formally 802.3ah)
• ITU-T Y.1731: Oam functions and mechanisms for Ethernet based networks
• IEEE 802.1ag: Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault
Management
The IEEE 802.3ah working group was established in 2001 to enable the uptake of Ethernet in
access networks, commonly referred to as Ethernet in the First Mile (EFM), which eventually
resulted in the publication of the IEEE 802.3ah standard. This introduces new media types
that are specific to EFM. In addition to these new media types, IEEE 802.3ah also introduces
OAM mechanisms for monitoring the link operation. The OAM protocol specified in IEEE
802.3ah is a link level OAM protocol which operates across point-to-point links. Since its
original publication, IEEE 802.3ah has now been incorporated back into the main body of the
IEEE 802.3-2008 standard. EFM OAM supports the following functions:
• OAM discovery: Provides a mechanism to discover the OAM layer at the remote DTE;
• Link monitoring: Event notifications when the number of errored frames exceed
certain thresholds;
• Remote failure indication: A mechanism is provided to indicate to a peer that the

receive path of the local DTE is non operational;
• Remote Loopback: A mechanism is provided to support a data link layer frame-level

loopback mode.
In contrast, IEEE 802.1ag is a multi-level level OAM protocol that can be used for monitoring
and isolating faults right across different operator domains and therefore, is not confined just
to link the level. This allows an end-to-end service to be monitored and can isolate faults to
within specific network or link segments that comprise the end-to-end service. IEEE 802.1ag
supports the following functions:
• Path Discovery: Uses the Linktrace protocol to determine the path taken to a target
MAC address;
• Fault detection: Uses the Continuity Check protocol to detect both connectivity
failures and unintended connectivity between service instances;
• Fault verification and isolation: Typically performed after Fault detection and Uses
Loopback messages to confirm successful restoration of connectivity;
ITU Y.1731 is compatible extension to IEEE 802.1ag but introduces some additional features
such as:
• Alarm Indication Signal (AIS) and RDI (Remote Defect Indication): These signals can be
used to communicate fault defects between maintenance entities operating at
different logical levels;
• Ethernet Lock Signal (not currently supported by the Node B)
• Fault Verification and Isolation
• Performance Management: Mechanisms to measure frame loss ratio, frame delay,

frame delay variation and throughput.
With the introduction of this feature, the Node B will support the protocols specified in the
above standards. The applicability of these protocols between various NEs in the UTRAN is
depicted Figure 6.
Iub
Ethernet Ethernet Ethernet Ethernet
NodeB
(iBTS)
Ethernet
802.1ag/Y.1731
etc
802.3ah 802.3ah 802.3ah 802.3ah
Figure 6: IEEE802.3ah, ITU-T Y.1731 and IEEE802.1ag support on the Node B
FEATURE BENEFITS
EFM OAM provides mechanisms useful for monitoring link operation such as remote fault
indication and remote loopback control. In general, EFM OAM provides network operators the
ability to monitor the health of the network and quickly determine the location of failing links
or fault conditions.
CFM comprises of capabilities for detecting, verifying, and isolating failures in virtual bridged
networks. These capabilities can be used in networks operated by multiple independent
organizations, each with restricted management access to each other’s equipment. This
allows an L2 end-to-end service to be monitored and can isolate faults to within specific
network or link segments that comprise the L2 Ethernet end-to-end service.
With Y.1731 the Node-B is also capable of:
• React Ethernet AIS,RDI signal reception (transmission is not supported as Node-B is

the end Node in the L2 NW)
• Raising Alarm indicating a link failure somewhere along the L2 path
• Counters for the Number of faulty seconds due to Ethernet AIS or RDI reception
• Perform Ethernet Frame Loss Measurements

The different Ethernet OAM features allow expedite detection and troubleshooting of network
faults and performance helping in reducing the cost to operate the network and respect SLA
commitments.
IMPACTED SYSTEMS
Node B and TIL, OAM
DEPENDENCIES
Hardware
Support S - but feature is S NS

only implemented
on the Node B
HW requirements N/A xCCM(-u) or eCCM-u N/A

equipped with GE
MDA
Software feature
27649 - Native IP Iub [R7]
Backhaul nodes need to support IEEE802.3-2008 (Part 3, Section 5, Chapter 57)
and IEEE803.1ag/Y.1731 standards
Standards
ITU-T Y.1731: OAM functions and mechanisms for Ethernet based networks
IEEE 802.1ad: Media Access Control (MAC) Bridges
IEEE 802.1Q: Virtual Bridged Local Area Networks
IEEE 802.1ag: Virtual Bridged Local Area Networks Amendment 5: Connectivity
Fault Management
EEE 802.3-2008: Part 3: Carrier Sense Multiple Access With Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications - Section Five –
Chapter 57IEEE 802.1D: Media Access Control (MAC) Bridges
Feature only supported on the Node B but not supported in the RNC 9370.
Ethernet OAM only applies to the L2 part of the backbone.

EFM is supported with feature 100791 – BTS daisy chaining through the Node B,but
CFM is restricted to the uppermost BTS of a daisy chain
Other protocols supplying by ITU-T Y.1731 are not supported by the Node B and are
out of scope of this feature:
• Ethernet Lock Signal
• Automatic Protection Switching (APS)

• Maintenance Communications Channel (MCC)
• Experimental (EXP) OAM functionality
• Vendor Specific (VSP) OAM functionality

ENGINEERING IMPACTS
None
Counters
New counters:
• ifY1731FarEndFrameLos
• ifY1731NearEndFrameLos
• ifY1731EthernetAIS
• ifY1731EthernetRDI
Modification of 107xx series of IP counters
eoamCFMActivation parameter: when set to “true” the CFM and ITU-T Y.1731
features are activated, instances of Maintenance Association Object can be created.
eoamEFMActivation parameter: when set to “true” EFM is activated.
New Managed Object “EthernetPort” with EFM configuration parameters.
New Managed Object “MaintenanceAssociation” (includes different standard

objects: MaintenanceDomain, MDLevel,MaintenanceAssociation and MEP) used to
configure h CFM and Y.1731 functionalities.
New alarms related to the new functionalities introduced by this feature.

FEATURE TYPE
Optional
113326 – Node B synchronization enhancements

FEATURE DESCRIPTION
This feature brings several enhancements in the Node B synchronization area in order to
address the following objectives.
• Add a few new functionalities:
o Addition of support of 2.048/10/15 MHz analog synchronization source via

direct front panel interface connector on the eCCM-u
o Allow to monitor the performance of the current synchronous source
monitoring by via another synchronization source (e.g. GPS receiver).
o New support of SYNCE over Fast Ethernet (in addition to GigE)

• Enhance the 1588v2 clock recovering algorithm to:
o Make it more robust to challenging backhaul PDV profiles
o Support of Transparent Clock Correction Field: Take in consideration the

additional “correction” field introduced by the Transparent Clocks in order to
reduce the effects of propagation delay variation on the IEEE1588v2 algorithm
performance.
o Comply with the ITU-T G.8265.1 Telecom Profile
o Support the 7705 SAR products acting as IEEE1588v2 Boundary Clock
FEATURE BENEFITS
This feature introduces several enhancements to the Node B synchronization frame work.
With this feature new synchronization options are available (analogue 2.048/10/15 MHz
signal) and improved performance of IEEE1588v2 (e.g. via support of transparent or boundary
clocks).
IMPACTED SYSTEMS
Node B
DEPENDENCIES
Hardware
Support S S NS
HW requirements N/A eCCM-u required for N/A

analog 2.048/10/15
MHz sync source.
xCCM(-u) or eCCM-u
for remaining items
of the feature
(GE MDA required
for Synchronous
Ethernet)
Software feature
34455 – Node B synchronisation for all IP [R7]
79363 - Synchronous Ethernet for IP Node B synchronization (for Synchronous
Ethernet) synchronization [R7]
Requires external source for analogue 2.048/10/15 MHz sync option
Requires external IEEE1588v2 Time Server for 1588v2 Synchronization
Requires SYNCE compatible network for SYNCE
External GPS receiver in case of GPS synchronization
Standards
IEEE 1588v2 and all ITU-T G.826x
SYNCE is not compatible with 100/1000baseT SFP
ENGINEERING IMPACTS
None
Counters
New counters introduced to monitor the performance of a synchronization source

versus an external reference signal.
New parameters introduced to configure the new functionalities.
New Alarms introduced associated with the performance monitoring of a

synchronization source versus a second synchronization source. Other alarm
evolutions related with SSM insufficient quality (or unavailability) and with
insufficient Priority level (either Pbits or DSCP) for PTP traffic.
FEATURE TYPE
Optional
116232 – Path diversity support for user plane on 9370 RNC

FEATURE DESCRIPTION
In previous releases, all the user plane egress traffic on the RNC interfaces goes through the
same physical path (4ptGigE board, Next Hope Router). With this feature, it will be possible
to split the egress RNC user plane traffic over separate physical paths (different 4ptGigE
board, different NHR, etc.). This functionality allows load sharing user traffic over the
different backhaul equipments of the network. In case of single interface failure the feature
helps as only part of the traffic is lost until the RNC PDR mechanism recovers from the
failure.
Similarly to path diversity on the control plane which is supported with the feature 110760
[R8], the current feature allows the support of path diversity for the user plane over the
different UTRAN interfaces, i.e. Iu-PS, Iu-CS, Iub and Iur.
NodeBs
(Group 1)
Subnet
1
Router A
IP Network 1
IP Network
RNC
Subnet
2 Router B
Single
subnet
NodeBs
(Group 2)
Figure 7: RNC Egress Path diversity on the Iub interface
Single
subnet
CN
Router A node
CN
Subnet
CN
node
1
node
RNC IP Network
CN
CN
node Subnet 2
CN
node
Router B
node
Figure 8: RNC Egress Path diversity on the Iu interface
FEATURE BENEFITS
Without this feature all the user plane traffic on the RNC interfaces always goes out through
the same physical path (4ptGigE board, Next Hop Router). With this feature, it will be
possible to load share the user plane traffic over separate physical paths (different 4ptGigE
board, different NHR, etc).
In case of path or interface outage, only part of the traffics is affected (until the PDR
mechanism recovers from the failure by changing the traffic to the other interface).
IMPACTED SYSTEMS
RNC, Transport Network
DEPENDENCIES
Hardware
Support S S NS
HW requirements 2x4ptGigE N/A N/A
Software feature
None
Transport network nodes
Standards
None
Only User Plane path diversity on the RNC egress direction is addressed by this
feature. In the ingress direction the RNC allows traffic simultaneously on both
4ptGigE but only a single IP subnet is configurable for the UP on each RNC interface.
ENGINEERING IMPACTS
Peer nodes to be configured in different IP subnets in order to allow using different

egress paths out of the RNC.
Transport network routing configurations.

Counters
None
None
None
FEATURE TYPE
Optional
5.6 OPERATIONAL EFFECTIVENESS

96298 – LR13.1.W RNC counter evolutions
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:

• VS.RAB.Mean.CS.Sum – Mean number of successfully established CS voice and data
RABs. The Erlang value can be derived from this counter. CS Services without
streaming are captured with the following screenings:
o CS Speech
o CS Data
• VS.RAB.Mean.CS.Sum.NeighbRnc - Mean number of successfully established CS voice

and data RABs. The Erlang value can be derived from this counter. CS Services
without streaming are captured with the following screenings:
o CS Speech
o CS Data
• VS.MultiRAB.Drops.DueToPs - The number of successfully established Multi-RAB calls

that subsequently have PS RAB(s) abnormally dropped. Multi-RAB Combinations (CS+PS
and PS Only) are captured with the following screenings:
o CS + 1 or more [PS 0/0 Kbps]
o CS + 1 or more [PS DCH / DCH]
o CS + 1 or more [PS HSDPA / PS DCH]
o CS + 1 or more [PS HSDPA / E-DCH TTI 2ms]
o Greater than 1 [PS 0/0 Kbps]
o Greater than 1 PS [DCH / DCH]
o Greater than 1 PS [HSDPA / DCH]
o Greater than 1 [PS HSDPA / E-DCH TTI 2ms]
• VS.MultiRAB.Drops.DueToCs - The number of successfully established Multi-RAB calls

that subsequently have CS Conversational RAB abnormally dropped. Multi-RAB
Combinations (CS+PS) are captured with the following screenings:
• VS.MultiRAB.Drop.DueToSRB - The number of successfully established Multi-RAB calls

that are subsequently dropped due to Signaling Radio Bearer Failure. Multi-RAB
Combinations (CS+PS and PS Only) are captured with the following screenings:
• VS.MultiRAB.Successfully.Established - The number of successfully setup and

reconfigured Multi-RAB calls. Multi-RAB Combinations (CS+PS and PS Only) are
captured with the following screenings:
• VS.MeasurementControlFailure - Number of RRC measurement control failure

messages received from the UE. Measurement control to configure Events are
captured with the following criteria, the last of which (relative to Event 1J) is being
introduced with 96298 (other screenings exist pre-LR13W):
o Due to Measurement Control to configure Events 1A, 1B, 1C, 1D, 1E, 1F
o Due to Measurement Control to configure Events 2D, 2F on CPICH EcNo
quantity
o Due to Measurement Control to configure Events 2D, 2F on CPICH Rscp
quantity
o Due to Measurement Control to configure Events 2C on CPICH EcNo quantity
o Due to Measurement Control to configure Events 2C on CPICH Rscp quantity
o Due to Measurement Control to configure Events 3C
o Due to Measurement Control to configure Events 6A, 6B
o Due to Measurement Control to configure Event 1J
o Other
• VS.ULTimingAdjustment.LargeToA - Total number of UL large ToA received and

ignored by RNC from this cell. This counter has no screenings.
• VS.MultiRAB.DLFramesPerAMRRate - Number of Downlink AMR Frames by Multi-RAB

combination and AMR rate. Multi-RAB Combinations (CS+PS) with CS Codec and CS
AMR Rate are measured with the following screenings:
o CS SM-SR 12.2 + 1 or more [PS 0/0 Kbps]
o CS Codec 1 MM-MR 12.2 + 1 or more [PS 0/0 Kbps]
o CS SM-SR 12.2 + 1 or more [PS DCH / DCH]

o CS Codec 1 MM-MR 12.2 + 1 or more [PS DCH / DCH]
o CS SM-SR 12.2 + 1 or more [PS HSDPA / PS DCH]
o CS Codec 1 MM-MR 12.2 + 1 or more [PS HSDPA / PS DCH]
o CS SM-SR 12.2 + 1 or more [PS HSDPA / E-DCH TTI 2ms]
o CS Codec 1 MM-MR 12.2 + 1 or more [PS HSDPA / E-DCH TTI 2ms]
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
RNC, Node B, OAM (WMS, NPO and Customers Performance Reporting system)
DEPENDENCIES
Hardware
Support S S S
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
Performance Monitoring Metrics

Counters
See feature description
None
None
FEATURE TYPE
Base
106719 – RNC Call Trace Capacity Realignment

FEATURE DESCRIPTION
This feature enables RNC Call Trace capacity realignment with RNC capacity evolutions by
allowing the CTn/CTg/CTa sessions to trace the necessary number of UE calls according to the
additional RNC capacity, which is provided through the introduction of new RNC hardware
modules and through software improvements:
• In UA08.1 CTn/CTg/CTa sessions tracing capacity limits are static and defined as
absolute numbers of UE calls whatever the RNC hardware and software release.
• In LR13.W CTn/CTg/CTa sessions tracing capacity limits are made dynamic and
defined as relative numbers of UE calls expressed as a proportion of the RNC traffic.
FEATURE BENEFITS
The time it takes for the Trace data collected to become statistically relevant is reduced,
also network optimisation and troubleshooting can be done faster.
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
Support S S S
HW requirements CP4 None None
Software feature
None
None
Standards
None
When tracing capacity realignment is activated for the CTg session, whatever the
CTg tracing ratio and the CTg tracing floor that are configured for the CTg session,
the maximum number of calls traced within the CTg session is limited to maximum
900 calls per RNC.
The following are not supported altogether:
• activation of tracing capacity realignment for the CTg session
and
• actual value used for the CTg tracing ratio set to a value different from 0%
and/or actual value used for the CTg tracing floor set to a value different
from 0 calls,
and
• request for the CTg session of any Call Trace specific periodic RRC
Dedicated Measurement (RDM) – Intra-frequency, Quality, and/or UE internal
– and/or of any Call Trace specific periodic NBAP Dedicated Measurement
(NDM) – SIR, Transmitted Code Power, and/or Round Trip Time
ENGINEERING IMPACTS
Some RNC resources are allocated to Call Trace during the time Call Trace sessions
are activated. Limited capacity reductions may be observed depending on how the
sessions are configured. When tracing capacity realignment is activated, capacity
reductions may be more important, again depending on sessions configuration.
Counters
None
For each type of CT (CTn/CTg/CTa) :
• One activation flag

• Relative tracing ratio of the RNC traffic (% of all RRC connected UE to be
traced) and absolute tracing floor (Minimum number of UE to be traced)
None
FEATURE TYPE
Base
118307 – LR13.W Node B counter evolutions

FEATURE DESCRIPTION
This feature introduces performance measurements for IP network monitoring, troubleshoot

of the IP interfaces and detection of packet loss.
Specifically, the following SCTP Counters are introduced:

• VS.IP.SctpPeerKBytes - This counter shows the number of SCTP protocol Kbytes sent
to/received from SCTP remote peer based on the real time traffic. The following
screenings are supported:
o To Peer
o From Peer
• VS.IP.SctpPeerPackets - This counter shows the number of packets SCTP protocol sent
to / received from SCTP remote peer based on the real time traffic. The following
o Send to Peer
o Received from Peer
• VS.IP.SctpOutOfBluePackets - This counter shows the number of out of the blue

packets received by SCTP protocol layer for which the receiver was unable to identify
an appropriate association.
• VS.IP.SctpDataChunks. This counter shows the number of data chunks SCTP protocol
received from or sent to SCTP remote peer and the number of duplicated or re-
transmitted data chunks SCTP protocol received from or sent to SCTP peer based on
the real time traffic. This counter can be used to determine the re-transmission rate.
The following screenings are supported:
o Transmitted Data Chunks
o Re-Transmitted Data Chunks
o Received Data Chunks
• VS.IP.IubCplanePacketsSent - This counter shows the number of C-plane IP packets

sent by each Iub interface.
• VS.IP.IubCplanePacketsReceived - This counter shows the number of C-plane IP

packets received on each Iub interface.
FEATURE BENEFITS
Enhancement of the counter based monitoring and troubleshooting solution allowing the
customer to derive metrics and improvements for IP transport, thus reducing OPEX for
network monitoring and troubleshooting.
IMPACTED SYSTEMS
DEPENDENCIES
Hardware
Support S S NS
HW requirements None None N/A
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
Performance Monitoring metrics

Counters

None
None
FEATURE TYPE
Base
120494 – Node B IP counters

FEATURE DESCRIPTION
This feature introduces performance measurements for IP network monitoring, troubleshoot

of the IP interfaces and detection of packet loss.
Specifically, the following SCTP Counters are introduced:

• VS.IP.SctpPeerKBytes - This counter shows the number of SCTP protocol Kbytes sent
to/received from SCTP remote peer based on the real time traffic. The following
o ToPeer
o FromPeer
• VS.IP.SctpPeerPackets - This counter shows the number of packets SCTP protocol sent
to / received from SCTP remote peer based on the real time traffic. The following
o ToPeer
o FromPeer
• VS.IP.SctpDataChunks - This counter shows the number of data chunks SCTP protocol
received from or sent to SCTP remote peer and the number of duplicated or re-
transmitted data chunks SCTP protocol received from or sent to SCTP peer based on
the real time traffic. This counter can be used to determine the re-transmission rate.
The following screenings are supported:
o Sent
o Retransmitted
o Rcvd
• VS.IP.SctpOutOfBluePackets - This counter shows the number of out of the blue

packets received by SCTP protocol layer for which the receiver was unable to identify
an appropriate association.
• VS.IP.SctpReestablishments - This counter measures the number of times the Sctp

association is re-established. Some reasons for the association to re-establish could be
due to it being dropped due to Sctp protocol level timeout or disconnection.
• VS.IP.IubCplanePacketsSent - This counter shows the number of C-plane IP packets

sent by each Iub interface.
• VS.IP.IubCplanePacketsReceived - This counter shows the number of C-plane IP

packets received on each Iub interface.
The following counters will enable troubleshooting of the IP interfaces (detection of packet
loss, etc):
• VS.IP.ifInDiscards - The number of inbound packets which were chosen to be

discarded even though no errors had been detected to prevent their being deliverable
to a higher layer protocol. One possible reason for discarding such a packet could be
to free up buffer space.
• VS.IP.ifInErrors - The number of inbound packets that contained errors preventing
them from being deliverable to a higher layer protocol.
• VS.IP.ifOutDiscards - The number of outbound packets which were chosen to be

discarded even though no errors had been detected to prevent their being
transmitted. One possible reason for discarding such a packet could be to free up
buffer space.
• VS.IP.ifOutErrors - The number of outbound packets that could not be transmitted
because of errors.
• VS.IP.NumOfUDPPorts.Max - The maximum number of UDP ports in use for the Iub IP
Interface.
• VS.IP.NumOfUDPPorts.Avg - The average number of UDP ports in use for the Iub IP
Interface.
The following counters will provide per-flow Performance Measurements:
• VS.IP.UserPlaneInOctets.Mean - The average number of incoming user plane octets

received on the Ip interface per second during the measurement collection period.
• VS.IP.UserPlaneInOctets.Max - The maximum number of incoming user plane octets
received on the Ip interface during a second within the measurement collection
period.
• VS.IP.UserPlaneInPackets.Mean - The average number of incoming user plane packets
received on the Ip interface per second during the measurement collection period.
• VS.IP.UserPlaneInPackets.Max - The maximum number of incoming user plane packets

received on the IP interface during a second within the measurement collection
period.
• VS.IP.UserPlaneOutOctets.Mean - The average number of outgoing user plane octets

sent on the Ip interface per second during the measurement collection period.
• VS.IP.UserPlaneOutOctets.Max - The maximum number of outgoing user plane octets

sent on the Ip interface during a second within the measurement collection period.
• VS.IP.UserPlaneOutPackets.Mean - The average number of outgoing user plane

packets sent on the Ip interface per second during the measurement collection
period.
• VS.IP.UserPlaneOutPackets.Max - The maximum number of outgoing user plane

packets sent on the IP interface during a second within the measurement collection
period.
• VS.ifInOctets - The total number of octets received on the interface, including

framing characters. User-plane bytes are excluded.
FEATURE BENEFITS
Enhancement of the counter based monitoring and troubleshooting solution allowing the
customer to derive metrics and improvements for IP transport, thus reducing OPEX for
network monitoring and troubleshooting.
IMPACTED SYSTEMS
DEPENDENCIES
Hardware
Support S NS S
HW requirements None N/A None
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
Performance monitoring metrics

Counters
None
None
FEATURE TYPE
Base
120498 – LR13.W Call Trace Developments

FEATURE DESCRIPTION
Call Trace is a very powerful feature that allows collecting very detailed information on UE
calls, and on cells & RNC interfaces, for the purposes of network optimisation, network
monitoring, and network troubleshooting
This feature brings some enhancements to existing RNC CT functionalities as follows :
1. For a 3G to 2G handover, the Cell Global Identifier (CGI) of the target GSM cell is
reported in CTn traces.
2. New CTa/CTb/CTg ASN.1 trace of RRC Connection Request and RANAP message
Relocation Request
FEATURE BENEFITS
1. Ease the optimization of 3G to 2G handover
2. Ensures tracing all 3GPP IEs of these messages in LR13.W and future releases
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
Support S S NS
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
None
Counters
None
None
None
FEATURE TYPE
Base
159393 – Configurable VSWR Alarm Threshold

FEATURE DESCRIPTION
The aim of the feature is to provide a GUI field for operators, in order to define the Voltage
Standing Wave Ratio (VSWR) level 2 and level 3 alarm thresholds according to their actual
implementation needs. VSWR is a measurement which could indicate the reality of the
antenna system errors. ALU provides 2 default levels for the VSWR alarms in the distributed
Node B series:
• Level 2 indicates a return loss (RL) of 9 dB, i.e. VSWR 2.1:1, and requires operator on-
site maintenance;
• Level 3 indicates a return loss of 6 dB, i.e. VSWR 3.01:1, the PA will shutdown in case
this level is reached as the intent is to protect the PA not being damaged by the high
returned signal level.
With this feature the two thresholds values are configurable as follows:
• Level 2 : Return Loss (RL) with range of 8 to 15 dB configurable by step of 1dB;
default 9 dB (i.e. VSWR 2.1)
• Level 3: RL ranges from 6 to 13dB, default 6dB (i.e. VSWR 3.01).
Figure 9: Configurable VSWR Alarm Threshold
FEATURE BENEFITS
Provide flexibility to customize the required VSWR alarm threshold.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S S NS
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
None
Counters
None
Activation parameter and new parameters for VSWR level 2 and level 3 alarm
thresholds configuration
None
FEATURE TYPE
Optional
164301 – LR13.3.W RNC counter evolutions

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:
• VS.MultiRAB.Successfully.Established.CS_1orMore_HsdpaEdch - Number of successfully

setup and reconfigured Multi-RAB calls. This counter is pegged each time a RAB is
established resulting in a new Multi-RAB combination of CS + 1 or More HSDPA/E-DCH
PS RAB. It does not distinguish between 2ms and 10ms E-DCH RABs and has no
screenings.
• VS.MultiRAB.DropsWithAMRRate.DueToCs - The number of successfully established

Multi-RAB calls that are subsequently dropped abnormally due to CS. Screenings are
classified by mode, codec, and DL max rate of a CS AMR RAB, with PS RAB(s) on
different transport channel(s). Multi-RAB Combinations (CS+PS) with CS Codec and CS

o CS Codec 2 MM-MR 5.9 + 1 or more [PS HSDPA / E-DCH TTI 10ms
• VS.MultiRAB.ULFramesPerAMRRate - Number of Uplink AMR Frames by Multi-RAB

combination and AMR rate. Multi-RAB Combinations (CS+PS) with CS Codec and CS

o CS Codec 2 MM-MR 5.9 + 1 or more [PS HSDPA / E-DCH TTI 10ms
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
DEPENDENCIES
Hardware
Support S S S
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
Performance Monitoring Metrics

Counters
None
None
FEATURE TYPE
Base
5.7 NODE B EVOLUTIONS

33648 – Support of 24 cells
111041 – Support of 12 antenna pairs
FEATURE DESCRIPTION
This feature extends the configurations that can be supported by Node Bs. It allows
configurations with an increased numbers of cells, especially useful in multi-band and
distributed configurations.
Current Node B configurations are limited to a maximum of 12 cells (i.e. sector-carriers). As

Node B capacities increase, and as larger configurations are needed to support dual-band
systems, a higher limit is required.
Some customers are also willing to implement BBU hostelling configuration, having one BBU
managing several remote sectors (up to 12), with 2 carriers on each of them. Such
configuration requires to increase the number of cells supported by a BBU.
This feature increases the maximum number of supported cells within 1 BBU to 24 cells.
This feature is a complement to feature 111041 - Support of 12 antenna pairs, which
increases the number of antennas that can be supported by a Node B.
FEATURE BENEFITS
An increasing number of configurations need more than the current limit in number of cells,
and this feature provides the support needed. This means operators do not have to buy and
deploy a complete new base station, but can continue to grow their existing deployed base.
To make full use of this feature, additional channel element, control or other capacities will
be needed.
In certain market, there is plan to deploy 4 carriers in 2100MHz frequency band, plus 1 carrier
900MHz. For a Tri-sector site, such configuration requires to support up to 15 cells per BBU.
Tri sectors site, 5/6 carriers per sector
1 .. 4 carriers
(2100MHz)
1 .. 2 carriers
(900MHz )
BBU
Figure 10: Tri-sectors site with 5/6 carriers per sector
Some operators are expecting to deploy BBU hostelling: they have some optical fibers already
deployed from the site where the BBU will be stored, up to the RF sites, where the RRH will
be installed (12 per BBU). Each of the sectors is expected to cover 2 carriers. As a
consequence, 24 cells are expected to be supported by the BBU:
BBU hostelling, 2 carriers per sector

24 cells required per BBU
1 .. 2 carriers
(2100MHz)
BBU
Figure 11: BBU hostelling configuration
Indoor coverage application of the BBU hostelling:
Figure 12: Indoor coverage application of BBU hostelling
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S S NS
HW requirements None 9926 d4U(*) N/A

eModules
(*) See Restriction/Limitation
Software feature
Feature 125409 - Dynamic overload management of CPU resources on eCEM

shall be activated when more than 12 cells are configured per BBU.
BBU hostelling configuration with up to 12 RRH60-21C/RRH2x60-21 requires the
support of the feature 111041 - Support of 12 antenna pairs.
None
Standards
None
eModules are required, this feature is not supported with iModules or xModules
(i/xCEM-u, i/xCCM-u).
9926 D4U is required
For 9311 cabinet, the digital renovation with 9926 D4U [R8] is required.
ENGINEERING IMPACTS
Node B capacity increase and engineering rules linked to BBU hostelling type of
configuration.
Counters
None
None
None
FEATURE TYPE
Optional
103774 – 3G only support of RRH2x40-09 (w/o dependency to 2G)

FEATURE DESCRIPTION
This feature certifies RRH2x40-09 (MC-RRH900) for operation in a 3G-only network. In this 3G-
only mode, the GSM OMC, BSC and SUM are not required.
The RRH2x40-09 (also called MC RRH900: Multi Carrier – Remote Radio Head 900) is a powerful
remote radio head providing 2x40W of RF over a 25MHz bandwidth anywhere within 3GPP
Band VIII (900MHz). It is an integral part of the Alcatel-Lucent Converged RAN strategy.
This feature provides certification for operation in a 3G-only network for hardware delivered
in previous GSM and WCDMA releases; it introduces configurations of up to 2 WCDMA carriers.
It is anticipated that additional functionality and configurations will be introduced in future
releases.
The RRH2x40-09 is a one sector 900MHz self-contained radio module, including:

• Its own energy system
• Its own cooling system

• Two 900MHz transmit paths of up to 40W each path
• The HW is capable of supporting a single or multiple GSM, WCDMA, and/or LTE

carriers over up to 25 MHz of spectrum of bandwidth anywhere within the 35 MHz
band. It also supports a mix of two technologies at the same time.
• Two receive paths
• Two Multi-Carrier Power Amplifiers

• Two duplexers
• Two CPRI interfaces and two GE interfaces
• AISG connector
RRH2x40-09 is linked to the digital unit using optical fibers supporting CPRI, carrying downlink
and uplink (main and diversity) base band signals, and OAM information.
RRH2x40-09 delivers up to 40W output power per antenna connector.
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.
Use of RRH2x40-09 with other features such as 2.2MHz GSM spacing (features 117822 [R7] and
117823 [R8]) provides a way of maximizing the 2G and 3G use of scarce 900MHz spectrum.
RRH2x40-09 provides benefits of:
• Support of up to 2 WCDMA carriers on a single RRH2X40-09
• 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
• RRH2X40-09 is virtually a no footprint solution, easing site acquisition
• RRH2X40-09 module is light, no craning is needed, and it eases site installation
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S S NS
HW requirements None 9326 d2U or 9926 N/A

d4U
Software feature
None
None
Standards
None
Configurations supported include STSR1, STSR1+1, STSR2
No support of CPRI daisy-chaining or AISG

ENGINEERING IMPACTS
None
Counters
None
None
None
FEATURE TYPE
Optional
119185 – TRDU2x60 900MHz multi-standard support for 2G & 3G (1PA 2G &

1 PA 3G)
167400 - TRDU2x60-09 WCDMA configurations in LR indoor cabinet
167401 - TRDU2x60-09 WCDMA configurations in LR outdoor cabinet
FEATURE DESCRIPTION
Feature 119185 introduces simultaneous support for 2G and 3G on the 9742 lightRadio™
TRDU2x60 900MHz (Band VIII) self contained RF asset. 9742 TRDU is an integral part of the
Alcatel-Lucent Converged RAN strategy designed in the new form factor for cabinet assets.
Thanks to features 167400 and 167401 the TRDU2x60 900 MHz module can be hosted
respectively in lightRadio™ Indoor and outdoor cabinets.
The 9742 lightRadio™ TRDU2x60 900MHz is an EMC compliant, self contained, 19inch RF asset,
combining 2 Multi Carrier power amplifiers into a single product. The 9742 TRDU can be
deployed in an ALU lightRadio™ cabinet or other 19inch compliant cabinet.
Figure 13: TRDU2x60 900MHz
The following description assumes an ALU lightRadio™ cabinet is used and RF performance is
stated at the cabinet antenna connector (ToC) and over a 25MHz IBW anywhere in the 35MHz
of Band VIII.
Feature 119185 utilizes the two multicarrier power amplifiers in the 9742 lightRadio™
TRDU2x60 900MHz to support simultaneous
simultaneous GSM and WCDMA service, where:
where
• GSM is supported on 1PA up to 60W composite output power 0-4

0 4 Carriers
• WCDMA is supported on 1PA up to 60W composite output power 0-2

0 Carriers
GSM WCDMA
Power Toc Power ToC
(W/carrier on PA1) (W/carrier on PA2)
1x60 1x60/50/40/30/20
2x30 2x30/20
3x20 2x30/20
4x15 2x30/20
FEATURE BENEFITS
Feature 119185 allows a single orderable HW asset to be deployed and configured for
simultaneous operation of GSM and WCDMA at high output power.
Support of two technologies at the same time allows cost optimized deployments of two
services.
Deployment with
h features such as reduced GSM to WCDMA carrier spacing of 2.0MHz (134298)
[R8] and 2.2MHz (117823) [R8] provides a way of optimizing the 2G and 3G use of scarce
900MHz spectrum.
Support for both continuous and non-continuous

non spectrum applications.
Enables the deployment of the new form factor 9742 lightRadioTM which provides 120W of RF
at the ToC, includes its own thermal management and is less than 12l, 13.5kg.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
au
Support S S NS
Software feature
Feature 126090 - GSM support on 2PA up to 2x60W composite output power.
None
Standards
None
None
ENGINEERING IMPACTS
None
Counters
None
None
None
FEATURE TYPE
Optional - Hardware
120415 – RRH2x60-850 & -1900 with 9396 digital units - second PA

activation
FEATURE DESCRIPTION
This feature provides for activation of the 2nd RF PA in RRH2x60-850 and RRH2x60-1900 [R8],
and operation of each PA in multi-carrier mode. New configurations using these new
capabilities are defined.
This feature is implemented within the release load, by remote software upgrade. The new
configurations are managed through the management system.
FEATURE BENEFITS
The added functionality provides the operator with additional RF power and carriers for sites
using the RRH2x. It provides increased readiness to VAM for RF power pooling for a future
release, and provides support for an enhanced antenna cross-connect feature (Feature
120799) where use of both PAs increases network availability.
Additional network capacity means the subscriber sees higher network availability and data
throughput.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S NS S
HW requirements None N/A 9396 d2U or d4U,

RRH2x60-850
RRH2x60-1900
Software feature
Optional dependency to:
• 123895 – 9396 d4U activation of additional CPRI ports
• 120799 - RRH2x antenna cross-connect for 9396 d2U
None
Standards
None
None
ENGINEERING IMPACTS
Full support of these higher RF capacities may also require additional capabilities
elsewhere in the Node B – by addition of channel cards, increased CPRI bandwidth
(provided by feature 123895) or other additional features, for instance.
Counters
None
None
None
FEATURE TYPE
Base
120799 – RRH2x antenna cross-connect for 9396 d2U and d4U

FEATURE DESCRIPTION
This feature provides the ability to use antenna cross connect between RRH2xs in which both
PAs are activated, in order to support redundancy schemes.
It allows twin PA RF assets to be cross-connected such that each RF asset supports 2 sectors,
and each sector is supported by 2 RF assets.
This feature is a development of feature 125180 – RRH2x antenna cross-connect for 9396 d2U
(Rx only, 1 TX PA) [R8], for systems based on 9396 d2U and 9396 d4U. It is compatible with a
similar feature (L92812) already included in the LTE roadmap.
FEATURE BENEFITS
This configuration means that in the event of hardware failure, service is maintained in all 3
sectors, with affected sectors continuing to operate with 1 antenna. This maintains service to
subscribers, and is an improvement compared to the complete failure of a sector that would
be suffered with the traditional 1 asset per sector configuration. The diagrams below
illustrate the traditional configuration and the cross-connect configuration.
RRH2x RRH2x
Digital unit
RRH2x
Traditional RF asset – sector allocation
Figure 14: Traditional RF asset – sector allocation
RRH2x
Digital unit
RRH2x RRH2x
Cross-connected RF asset – sector allocation
Figure 15: Cross-connected asset – sector allocation
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S NS S
HW requirements None N/A 9396 d4U or d2U

RRH2x60-850
RRH2x60-1900
Software feature
None
None
Standards
None
9396 digital units only

RRH2x RF units only
ENGINEERING IMPACTS
Antenna cables must be correctly connected.
Counters
None
None
None
FEATURE TYPE
Base
121018 – MCR-B 1900 with HE PAM at 60W

FEATURE DESCRIPTION
This feature provides support for use of a new MCR-B 1900MHz radio at 1900MHz in OneBTS
macrocells. Use of MCR-B with the High Efficiency RF Power Amplifier (HE PAM) previously
introduced (Feature 125076 – HE PAM 1900 with MCR-A at 60W [R8]) provides support for
multi-carrier operation and paralleling of PAs for additional power.
Use of MCR-B with HE PAM provides new configurations that use the higher RF power
available. Multi-carrier operation is supported (up to 3 carriers within a 15MHz bandwidth)
and paralleling to support up to 60W per carrier. Power consumption is reduced compared to
equivalent configurations using p2PAM.
MCR-B also supports operation with p2PAMs. HE PAM 1900s must be operated independently to
p2PAMs: multi-carrier operation and PA paralleling in mixed configurations is not supported.
From this release, MCR-B will be used as the default radio at 1900MHz, for new builds and for
upgrades. The previous MCR-A 1900 will be discontinued.
FEATURE BENEFITS
This feature enables use of HE PAMs in multi-carrier and paralleled configurations, increasing
the types of configurations in which HE PAM can be used. HE PAM provides increased RF
powers per RF PA compared to previous releases. These higher RF powers can be used where
higher losses need to be overcome or to allow 2 carriers to be supported by a single RF PA.
This feature also provides a reduction in OPEX due to the higher efficiency of the HE PAM.
Subscribers gain improved network access as a result of the benefits above.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S NS S
HW requirements N/A N/A MCR-B 1900
Software feature
None
None
Standards
None
Multi-carrier operation and paralleled PAs are not supported in mixed configurations
(per radio) of p2PAM and HE PAM 1900.
ENGINEERING IMPACTS
Increased RF power is available and can be used to increase transmitted power.

Care must be taken not to exceed FCC EIRP limits, especially in urban areas where
the limit is lower than in rural areas.
Counters
None
None
None
FEATURE TYPE
Optional – Hardware
121030 – OneBTS PM processor load counters
FEATURE DESCRIPTION
Feature 121030 provides new counters to monitor and report the load on the LIU and UMC
processors within the URC-II and the PQ2 and PQ3 processors on the UCU-III.
The measurement shows processor loading based on traffic levels. The loads are recorded at 1
second intervals for each processor, and the maximum and mean values are reported at
normal reporting intervals (15 minutes).
FEATURE BENEFITS
Feature 121030 indicates major processor loadings to the operator, which could potentially
lead to disruptions of service. This allows them to have early warning of excessively high
loadings and to plan mitigation actions.
IMPACTED SYSTEMS
Node B, RNC
DEPENDENCIES
Hardware
Support S NS S
HW requirements None N/A URC-II; UCU-III
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
Network planners should take into account possible overload conditions.

Counters
New processor load counters are made available by 121030
None
Feature 121030 load counters can be monitored to check if overload control has
been triggered.
FEATURE TYPE
Base
121537 – U2100 + U900 Daisy Chaining

FEATURE DESCRIPTION
This feature enables a specific RAN Sharing configuration:
• M-RS-U900-GU900-U2100
This configuration requires more than 6 radio assets to be supported from a single d2U in a
“mixed asset CPRI daisy chain”, where:
• MC-TRX67-09 assets support 2G+3G (GU900) and 3G (U900)
• TRDU60-21 assets support 3G (U2100)

• The CPRI daisy chain connects the 3G configured RF assets to a single CPRI port on the
d2U.
• The CPRI daisy chain connects an MC-TRX67-09 (U900) to a TRDU60-21 (U2100), which
is connected to a single port on the d2U.
• Both CPRI electrical and fibre variants are supported.
2G+F1 F3+F4 F2
AND
MC-TRX MC-TRX TRDU

67-09 67-09 60-21
2G+3G 3G 3G
#1 #2 #1
D2U
Direct Connection CPRI Daisy Chain
GU900 RF assets U900 and U2100 RF
assets
M-RS-2U900-U2100
Figure 16: U2100 + U900 Daisy Chaining
Note:
The diagram represents a single electrical or optical CPRI daisy chain in the tested
configuration where the chain length is 2 radio assets. However, longer chains are possible by
adding TRDU60-21 while ensuring the MC-TRX is at the end of the chain.
The daisy chain configurations will be certified in the following 2G cabinets:
• 9100 MBO2 E (AC and DC) variant
• 9100 MBI5 AB
FEATURE BENEFITS
ALU CPRI daisy chain features enable, multiple Radio Units (RU) to be connected to a single
CPRI port on a d2U. This helps to enable future expansion of the BTS beyond 6 radio assets
per digital unit.
Feature 121537 builds on 115183 - TRDU Daisy Chaining [R8], enabling a “mixed daisy chain”
of 2100MHz TRDU and 900MHz MC-TRX radio assets to be connected via a single CPRI interface
to a single CPRI port and minimizes the need to add a second cabinet.
IMPACTED SYSTEMS
Node B
DEPENDENCIES
Hardware
Support S S NS
HW requirements None Tested only with

TRDU60-21 and MC-
TRX67-09
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
MC-TRX67-09 must be at the end of the CPRI daisy chain.

Counters
None
None
None
FEATURE TYPE
Base
123836 – AISG2.0 on 9396-based RRHs Phase 1

FEATURE DESCRIPTION
This feature provides UTRAN-level management of specific AISG 2.0 ALDs connected to
RRH2x60 in a 9396 (OneBTS distributed) based network.
RRH2x includes AISG support in the form of an internal AISG controller, a socket (compliant to
AISG 2.0), and an internal ‘smart’ bias-T for transmitting AISG data and power onto the
antenna feeder. This feature allows operation from WMS, to AISG RET devices connected to
RRH2x.
FEATURE BENEFITS
This feature allows the operator to remotely monitor and manage AISG RETs. It allows
confirmation of configurations, notification of faults, and adjustments to easily take place
from WMS, in many cases eliminating the need for costly site visits and tower climbs.
This in turn allows an operator to more easily and quickly implement adjustments such as
antenna tilt to take into account network, environment or traffic changes over time,
improving network access and performance for subscribers.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S NS S
HW requirements None N/A RRH2x60-850

RRH2x60-1900
Software feature
None
AISG RET antennas compatible with the families listed below:
• Andrew/ Commscope Type 1 e.g. DBXNH-8585A-R2M
• Andrew/ Commscope Type 17 e.g. SBNH-1D6565B
• KWM Type 17 e.g. AM-X-CD-14-65-00T-RET
• Kathrein Type 1 e.g. 800-10764 K
• Powerwave Type 1 e.g. P65-15-XLH-RR
Standards
AISG 2.0
Support is limited to RET antennas, and the devices listed. TMAs are not supported.
ENGINEERING IMPACTS
Connection between RRH2x and ALDs should be made.

Counters
None
None
None
FEATURE TYPE
Base
123895 – 9396 d4U activation of additional CPRI ports

FEATURE DESCRIPTION
This feature activates the 2nd set of 3 CPRI ports on 9396 d4U [R8], increases the number of
supported cells to 12.
When launched, 9396 d4U provided software support for 3 of the 6 hardware CPRI ports. This
feature activates the other 3 CPRI ports, providing full access to all 6 ports.
The internal architecture of 9396 d4U is scaled to provide support for up to 12 RF cells (3
sectors, 4 carriers). This feature provides software to increase this architectural capacity
from the 6 cells provided at launch to the full 12 cells capability. It is important to note that
other factors will impact the actual capacity provided in real deployed configurations – for
example, capacity may be defined by the channel cards capability and the number of them
installed.
This feature is implemented within the release load, by remote software upgrade. It is not
switchable.
FEATURE BENEFITS
This feature increases the capacity and flexibility of 9396 d4U, allowing it to support up to 6
CPRI links and up to 3 sectors x 4 carriers.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S NS S
HW requirements None N/A 9396 d4u
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
With this feature, 9396 d4U can support up to 6 CPRI links and up to 12 RF cells
(typically 3 sectors x 4 carriers/ sector).
CPRI links will operate at rate 1, supporting up to 3 cells per link. Access to the full
4 carriers capacity therefore requires 2 links (and therefore 2 RRHs) per sector. RRH
configurations up to 4 carriers (STSR2+2) will be certified with feature 120415, but

care must be taken to ensure that RF capacity configured and UCU capacity installed
are aligned. Depending on traffic characteristics, it’s likely that UCU count will be
the constraining item.
Counters
None
None
None
FEATURE TYPE
Optional
125406 – Monitoring of eCEM and xCEM modem load

125407 – Overload protection of Node B digital part (Step 2)
125409 – Dynamic overload management of CPU resources on eCEM / xCEM
FEATURE DESCRIPTION
As data traffic continues to grow, there is a need to prevent and manage overload in the
different digital modules of the Node B.
Feature 125406 introduces additional load counters that allow operators to properly supervise
the load on xCEM(-u) and eCEM(-u) modem boards. While in previous release only the load of
PQ3 processor was reported, PQ2 load, DSP load as well as ASIC load is now reported. In
complement, associated to each CPU load counter, a counter giving the distribution of the
CPU load according to the different overload thresholds, as defined in feature 125409, is
added.
Feature 125407 further improves the overload management of Node B controller, namely
xCCM(-u) or eCCM-u, which was introduced in previous release with feature 121543 - Overload
protection of Node B digital part (Step 1) [R8]. While with feature 121543 any new incoming
call is rejected under certain load conditions, feature 125407 ensures that under the same
conditions emergency calls are processed normally and only rejected in case of more critical
overload. Furthermore, the configuration of overload behavior via OMC is improved.
In LR13.1W, feature 125409 introduces defense mechanisms aiming at preventing DSP of

xCEM(-u) and eCEM(-u) modem boards from being (or remaining) in overload. These features
complement the overload management on the controller introduced by feature 125407 and
are based on some of the load counters from feature 125406, i.e. PQ3 CPU and DSP load.
FEATURE BENEFITS
Overall all these features contribute to improve the Node B stability (modem and controller)
in high traffic load conditions.
Feature 125406 allows operators to better supervise the modem load and to avoid modem
overload situation by taking appropriate actions, e.g. adding modem cards to the site when
needed. The status of the different load counters helps to determine the limiting factor on
modem capacity (R99, HSDPA or HSUPA traffic).
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S S NS
HW requirements None xCEM(-u); eCEM(-u) N/A

xCCM(-u); eCCM-u
Software feature
125407 depends on 121543 - Overload protection of Node B digital part (Step 1)
[R8]
None
Standards
None
125406 and 125409are not supported on iCEM(-u)
125407 is not supported on iCCM(-u)

ENGINEERING IMPACTS
None
Counters
Feature 125406 introduces new load counters on ASIC, DSP, PQ2 and PQ3.
125407 and 125409 : one activation parameter per feature and parameters linked to
overload management (e.g. configuration of overload thresholds)
None
FEATURE TYPE
Base
125587 – LightRadio Outdoor Cabinet WCDMA

FEATURE DESCRIPTION
This feature provides support of LR Outdoor cabinet family in WCDMA UTRAN.

The LR Outdoor cabinet is the new converged and flexible platform to improve TCO of mobile
network operators. This solution is proposed for all wireless technologies including GSM,
WCDMA and LTE.
The LR Outdoor cabinet family is composed of the Compact cabinet, the Small cabinet, and
arrangements of these 2 cabinets in stacked configurations.
Figure 17: LR Outdoor cabinet family
The LR outdoor cabinet includes
• Outdoor housing for environmental protection
• Standard 19” space of 13 to 34 Units for telecom equipment

• Direct Air Cooling (DAC) system for -40°C to +50°C temperature
• AC or DC powered
• AC/DC Power System Unit (PSU) of 6kW with N+1 redundancy (optional)
• 1 or 2 Battery stacks of 90Ah (optional)
• DC distribution system
• Alarm collection module
FEATURE BENEFITS
This product has the following main benefits:
• Convergence product for GSM, WCDMA and LTE
• Higher power density, higher power dissipation
• Compact size, foot-print limited to 0,49 m²
• Light Weight, no cramming, could be hand carry.

• Can host legacy Alcatel-Lucent modules as well as new lightRadio™ modules
• Support both macro and distributed configurations
• Stackability and flexibility of the 19” frame. Cabinet are designed to host standard 19
inches item: 13U for the small, 21U for the compact. The stackability allow to have
more space, and to grow as needed without impact on the foot print
Figure 18: LR Outdoor cabinet stackability
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S S S
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
None
Counters
None
New configurations and cabinets associated with LR outdoor configurations
New cabinet alarms

FEATURE TYPE
Optional - Hardware
133975 – Hosting of 2 Node Bs WCDMA in one 9926 d4U

FEATURE DESCRIPTION
This feature introduces the possibility to host two Node Bs inside one 9926 d4U [R8].
With this feature operators will be able to locate two Node Bs in the same d4U in order to
provide higher signaling capacity than what can be offered by a single logical Node-B
supporting up to 6 modems boards. Two controllers (one per Node B) will be plugged inside
d4U. Each modem inside the d4U will be allocated to a controller.
Supervision of common hardware will be provided by one of the two controllers.
Below, an illustration for a site with 4 carriers at 2100MHz and 1 carrier at 900MHz.
NodeB B S2
U2100 – 4C U900 – 1C
S1
S3
NodeB A
RRH2x-09 RRH2x-21
RRH2x-09
RRH2x-09
eCCM #1
eCEM #1
NodeB
eCEM #2
eCEM #3
A
eCEM #4
eCEM #5
eCEM #6 NodeB
eCCM #2
B
RRH2x-21
RRH2x-21
Figure 19: example of 2 Node B in d4U configuration
FEATURE BENEFITS
This feature allows to provide additional signaling capacity beyond what can be offered by a
single controller in a d4U by splitting an existing site without additional footprint.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S S NS
HW requirements None 9926 d4U equipped N/A

with:
eCCM-u/GigE MDA
xCEM-u; eCEM-u
Software feature
None
None
Standards
None
This feature is only supported with the following configuration: 9926 d4U equipped
with eCCM-u/GigE MDA; xCEM-u; eCEM-u
ENGINEERING IMPACTS
None
Counters
None
None
None
FEATURE TYPE
Optional
158406 – RRH2x60-21A
FEATURE DESCRIPTION
This feature covers development of the RRH2x60-21A variant of the RRH2x family, and its
integration within WCDMA UTRAN.
The Remote Radio Head (RRH) specified in this document is has 2 transmit paths, each
supporting 60W RF, and support for 4 receive paths and 4 antenna connections. It covers
operation in 3GPP Band I (2100MHz) and is hardware-ready to support 2x60W over a 45MHz
operational bandwidth. The inclusion of 2 Tx paths & 4 antenna connections means the unit is
ready enable 2x4 MIMO applications. The inclusion of 4 Rx paths provides support of STSRx+y
UTRAN sharing configurations.
At initial introduction the RRH will provide support for configurations up to 20MHz operational
bandwidth in parity with the previous RRH2x60-21.
RRH2x60-21A will replace RRH2x60-21 in production. There is no need to replace RRH2x60-21

already in use.
In summary, the RRH2x60-21A is a 2100MHz self-contained radio module including:
• Its own energy system
• Its own cooling system
• Two 2100MHz transmit paths, each with a Multi Carrier Power Amplifier capable of up
to 60W, and capable of operation over a 45MHz block anywhere within the
operational band.
• Two pairs of 20MHz receive paths, providing support of STSRx+y.

• Four antenna connections
• Two duplexers
• Two CPRI interfaces

• One AISG connector
RRH is linked to the digital part of the Node B using optical fibres supporting CPRI, carrying
downlink and uplink (main and diversity) base band signals, and OAM information.
RRH block diagram is as follows:
Rx.b’ RF to digital
converter LNA
Rx.a RF to digital
converter LNA
Digital to RF
converter PA
Tx.a
Digital E BB
BTS O processing
Rx.b RF to digital
converter LNA
Rx.a’ RF to digital
converter LNA
Digital to RF
converter PA
R xs operate in independently
tunable 45MHz blocks as 2 RxD
Tx.b PAs operate in 2
pairs
indepe ndently tunable
45MHz blocks
Figure 20: RRH2x60-21A
In downlink, the RRH receives the optical signal from the BTS. The signal is converted into an
electrical digital baseband signal, which is then digital to analogue converted and up
converted to a pair of RF signals. These RF signals are amplified through power amplifiers and
sent to duplexers.
In uplink, two signals are received from the main and diversity antenna. They are amplified
through low noise amplification chains and down-converted before being converted into
digital signals, then multiplexed according to I/Q radio signal format and converted into
optical signals that are sent to the digital BTS (Node B). RRH can also process 2 additional RX
signals in order to manage STSRx+y configurations in support of disaggregated spectrum.
FEATURE BENEFITS
Support for high RF power, high capacity applications in a small form factor.
Support for both continuous and more widely disaggregated non-continuous spectrum
applications.
Support of 2x2 MIMO for increased data rates.

Ready for support of LTE, up to 2x4 MIMO in a single unit.
Support of VAM for power balancing between PAs and as readiness for operation with LTE
RRH is virtually a no footprint solution, easing site acquisition.

RRH module is light weight, so no craning is needed, easing site access and installation.
RRH is a no-maintenance unit, reducing operational expense
RRH uses a modern high efficiency amplifier, reducing power consumption

RRH uses no fans, and so offers a noise-free RF solution.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S S NS
HW requirements None 9326 d2U v3 or 9926 N/A

d2U or d4U
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
More RF power on the antenna leads to more DL capacity.
Additional antenna connections must be connected or blanked.
Optical link budget to be managed according to optical TRXs (SFPs) and optical fiber
length and performance
Installation of RRH shall be in accordance with the appropriate engineering rules:

since this product is small, it could be installed indoor but as a macro BTS like
solution, it requires a minimum coupling loss between UE and BTS greater than
70dB, refer to 25.104 R6 Chapter 4.2.
Installation of RRH shall be in accordance with EMR rules: since this product is small,
it could be installed indoor but EIRP (when RRH is connected to 18dBi antenna) can
reach 64 dBm, then an electromagnetic field of 20V/m at 12m from antenna (in the
main antenna lobe direction), this value can overreach some EMR limits in some
countries: limit in Italy is 6V/m (40m no-go area), Belgian limit is 29V/m while
ICNIRP limit is 59V/m. All necessary documentation and warning shall be provided
with RRH product
Installation indoors may have impact on lightning/ surge protection; local rules
should be observed.
Engineering tasks shall take into account the geographical topology and the delays
introduced by the optical fibers.
Where TMA support is required, TMA must be AISG 2.0.
Additional configuration options to be supported due to provision of 2 Tx paths.

Counters
None
New parameters associated with 2nd Tx path
None
FEATURE TYPE
Optional - Hardware
159290 – Multiple RRH per cell : extension for 9926 BBU 4U

FEATURE DESCRIPTION
This feature delivers an extension to feature 118241 - multiple RRH per cell [R8], which was
delivered for d2U in UA08.1, for d4U for indoor deployment scenarios (no support of high
speed train deployment scenarios). The number of MRS (multiple RRH sets) per Node B is
extended to 4 MRS per d4U. Contrarily to 118241, only eCCM-u and eCEM-u are supported, i.e.
eModules and xModules cannot co-exist in the same d4U if 159290 is activated.
Dual-cell HSDPA [R7] [R8] and enhanced CELL_FACH are in restriction in this release and will
be delivered later on with dedicated features.
FEATURE BENEFITS
Increased capacity and possible configurations for in-door coverage based on Multiple RRH per
cell solution.
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S S NS
HW requirements None 9926 d4U equipped N/A

with:
eCCM-u, eCEM-u
RRH60-21C
Software feature
118241 – Multiple RRH per cell [R8]
33648 – Support of 24 cells
111041 – Support of 12 antenna pairs
None
Standards
None
This feature is only supported with the following configuration: 9926 d4U equipped
with eCCM-u, eCEM-u and RRH60-21c.
Dual-cell HSDPA [R7] [R8] and enhanced CELL_FACH features are in restriction.
High speed train deployments are not supported, contrarily to 118241 – Multiple RRH
per cell [R8].
ENGINEERING IMPACTS
None
Counters
None
One activation parameter.
New alarm in case of invalid configuration.

FEATURE TYPE
Optional
159429 – LightRadio Indoor Cabinet WCDMA

FEATURE DESCRIPTION
This feature provides support of LR Indoor cabinet family in WCDMA UTRAN.

The LR Indoor cabinet is the new converged and flexible platform to improve TCO of mobile
network operators. This solution is proposed for all wireless technologies including GSM,
WCDMA and LTE.
The LR Indoor cabinet family is composed of the Compact cabinet and the Small cabinet.
• Indoor housing for environmental protection
• Standard 19” space of 21 to 38 Units for telecom equipment

• Air flow to support -5°C to +45°C temperature
• AC or DC powered
• AC/DC Power System Unit (PSU) of 6kW with N+1 redundancy (optional)
• 1 Battery stacks of 90Ah (optional)
• DC distribution system
• Alarm collection module (optional)
FEATURE BENEFITS
This product has the following main benefits:

• Same width as MBI cabinet

• Compact cabinet is Seismic
• Flexibility of the 19” frame. Cabinet are designed to host standard 19 inches item:
23U for the small, 38U for the compact.
Figure 21: LR Indoor cabinets
IMPACTED SYSTEMS
Node B, OAM
DEPENDENCIES
Hardware
Support S S S
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
None
Counters
None
New configurations and cabinets associated with LR outdoor configurations

New cabinet alarms

FEATURE TYPE
Optional - Hardware
162520 – External alarm logical state inversion

FEATURE DESCRIPTION
The Node B and the RRHs are able to manage external alarms. There are many kinds of
external site equipments in fields to monitor. These site equipments may have different
alarm behavior, alarm current status “Normal Open (High Voltage)” would represent the
“fault” for some site equipments while others use “Normal Closed (low Voltage)”.
This feature will enable the customization of the external alarm logic status, to be either
normally open or normally close. This feature allows adapting the external alarm mode to the
site equipments on an alarm per alarm basis.
A feature activation flag allows the feature to be used. By default, the feature is not
activated.
As the activation flag is set to yes, the feature allows the setup each external alarm on
normally close or normally open mode of the NodeB and of the RRH equipments. By default,
the parameter is setup to do not change the prior behavior.
FEATURE BENEFITS
This feature allows adapting the external alarm mode to the site equipments managed
through external alarm, on an alarm per alarm basis.
With this feature, it is possible to manage any site equipment whatever the alarm logic is.
IMPACTED SYSTEMS
Node B, OAM, TIL
DEPENDENCIES
Hardware
Support S S NS
HW requirements None d2U / d4U and with N/A

eAMx for Node B
Applicable to all
RRHs with exception
of legacy 2OW RRHs
Software feature
74724 – 32 Alarms on 9326 d2U [R7]
None
Standards
None
None
ENGINEERING IMPACTS
None
Counters
None
None
None
FEATURE TYPE
Optional
164373 – MCTRX67-09 3G in LR Indoor Cabinet Configuration

FEATURE DESCRIPTION
The feature gives the possibility to host the MC-TRX67-09 module in Light Radio Indoor
cabinet.
The cabinet can be mono technology or multi-technology usage. In this feature, the MC-
TRX67-09 part of the configuration could be either 3G only or 2G+3G or MSR. In other words,
all the existing usage of the MC-TRX67-09 already allowed in other cabinet should now be
possible in LR Indoor Cabinet.
Example of the configuration allowed:
Figure 22: MCTRX67-09 3G in LR Indoor Cabinet Configuration
FEATURE BENEFITS
The feature allows using the field proven and multi-standard MC-TRX67-09 based solutions in
the new LR Indoor cabinet, with all the benefit to use this new platform:

• Same width as MBI cabinet

• Compact cabinet is Seismic
• Flexibility of the 19” frame. Cabinet are designed to host standard 19 inches item:
23U for the small, 38U for the compact.
IMPACTED SYSTEMS
Node B, OAM, TIL
DEPENDENCIES
Hardware
Support S S NS
HW requirements None MCTRX67-09 3G N/A

LR Indoor Cabinet
Software feature
None
None
Standards
None
None
ENGINEERING IMPACTS
None
Counters
None
None
None
FEATURE TYPE
Optional – HW Configuration
5.8 RNC EVOLUTIONS

98448 – Access Class Barring (ACB) at Cell Granularity
FEATURE DESCRIPTION
Under heavy cell congestion conditions, Domain Specific Access Class Barring (ACB) at Cell
Granularity can help reduce and control the traffic in a much more localized geographical
area. The feature has the ability to activate for a cell or group of cells based on a specified
percentage of normal calls in either the CS, PS or both domains. Triggering can be left to
automatic controls, or manually by the operator.
When ACB is activated, the RNC will sequentially restrict access classes on the cell(s). The
default number and domain of Access Classes restricted at one time, can be increased or
decreased by the operator for greater control if desired. Selected access classes being barred
are rotated in order to improve the end user experience during the overload condition.
FEATURE BENEFITS
This feature maximizes the stability and “good-put” of the network during emergency high
overload situations by reducing the traffic for a group of cells based on a specific percentage
of normal calls in either the CS or PS domain. User experience is improved due to the
rotation of UE barring. Triggering ACB at the cell level ensures larger geographical regions or
cells that have potentially low traffic are not impacted by a localized overload condition. The
feature ensures resources are available for emergency and special services access.
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
Support S S S
Software feature
Interaction with 127550 - Traffic filtering in cell overload
Separate domain barring works for Rel-6 UE categories & beyond
Standards
None
In the case of an Iu Flex configuration, ACB actions are not supported if they are due
to an Iu failure event or a Core Network overload event.
ACB does not support interaction with MOCN (in case several PLMN are broadcasted
in the MIB).
ENGINEERING IMPACTS
None
Counters
None
The functions provided by this feature can be configured by the operator through
the management system. Parameters are available to activate the automatic
behavior of ACB, extending the Access Class Barring capability provided by feature
31805 - Automatic Cell Barring [R4], to include the following:
• Independent control of barring for the CS and PS domain (DSAC)
• The ability for ACB to be triggered automatically for a cell or group of cells
by RRM based on cell overload
In addition, the operator can manually activate this feature and configure the level
of barring. If manually activated, this will override any levels of barring set by
automatic activations.
An alarm is generated whenever ACB is activated

FEATURE TYPE
Optional
121337 – 9370 RNC Capacity Evolution with eDCPS

FEATURE DESCRIPTION
Data traffic and Smartphone devices continue to grow throughout the WCDMA networks, and
thus the 9370 RNC capacity must scale to support this growth. RNC with eDCPS (109443 -
Enhanced Dual Core Packet Server Introduction [R8]) provides the flexibility to further
increase the RNC capacity through software. This feature increases the capacity of the 9370
RNC by offloading RAB software functionality into hardware (FPGA) in order to free up
processing for either; increased data traffic, or increased signaling traffic by enabling further
conversion of RAB processors into TMU processors though the use of (PM109904) Flexible
TMU/RAB Role assignment.
FEATURE BENEFITS
This feature provides the flexibility to increase the capacity of the RNC, when equipped with
eDCPS only, on demand without the need of additional hardware. Prior to this feature, RNC
capacity scaling was limited to the addition of extra DCPS. Once the RNC became fully
populated with DCPS, the only way to increase capacity was by adding another RNC. This
feature provides the option to boost the capacity of a fully populated RNC through software
resulting in fewer RNC compared to an RNC with DCPS. Higher capacity RNC provides
improved mobility, less Iur traffic and the ability to better handle time of data effects.
Furthermore, this feature will yield OPEX savings as more capacity is supported by an RNC
through the same footprint and power consumption.
IMPACTED SYSTEMS
RNC
DEPENDENCIES
Hardware
Support S S S
HW requirements eDCPS; CP4 None None
Software feature
83985 – 9370 RNC Capacity Increase with eDCPS [R8]
None
Standards
None
9370 RNC must only contain eDCPS cards and CP4. This feature is not supported in
RNC with a mixture of DCPS and eDCPS. Feature 121337 is only available for RNC
configurations with 10 or 12 eDCPS cards.
ENGINEERING IMPACTS
RNC Capacity Increase
Counters
None
None
None
FEATURE TYPE
Optional
121378 – Enhanced Flexible RAB/TMU role assignment

FEATURE DESCRIPTION
Additional 9370 RNC flexible TMU/RAB assignments configurations are available with eDCPS
beyond those supported in previous release with feature 109904 – Flexible TMU/RAB
Assignment [R8].
FEATURE BENEFITS
RNC can be further adapted to traffic models with significant control plane signaling without
hardware changes.
RNC capacity is increased in networks that are highly limited by control plane capacity.
The lifespan of an RNC (the time before it reaches capacity exhaust) can be extended in
networks with a large number of Smartphone users.
IMPACTED SYSTEMS
RNC, OAM
DEPENDENCIES
Hardware
Support S S S
HW requirements eDCPS; CP4 None None
Software feature
109904 – Flexible TMU/RAB Assignment [R8]
None
Standards
None
The following configurations are supported:
• 12 eDCPS (22 – 28 TMUs)

ENGINEERING IMPACTS
None
Counters
None
None
None
FEATURE TYPE
Optional
6 ABBREVIATIONS AND DEFINITIONS
6.1 Abbreviations
2G Second Generation
3G Third Generation
3GPP Third Generation PartnerShip Project
AAL2 ATM Adaptation Layer type 2
ACB Access Class Barring
AISG Antenna Interface Standards Group
ALU Alcatel-Lucent
AMR Adaptative Multi Rate
AO Always On
ARP Allocation/Retention Priority
ASN1 Abstract Syntax Notation 1
ATM Asynchronous Transfer Mode
BBU Base Band Unit
BCCH Broadcast Control Channel
BLER Block Error Rate
BMC Broadcast and Multicast Control
BSS Base Station Sub-system
BTS Base Transceiver Station
BW Bandwidth
CAC Call Admission Control
CB Cell Broadcast
CBC Cell Broadcast Center
CBS Cell Broadcast Service
CBE Cell Broadcast Entity
CCH Control Channel
CCCH Common Control Channel
CCM Core Control Module
CELL _PCH Cell-Paging Channel
CEM Channel elements Modules
CID Customer Identificator
CM Compressed Mode
CN Core Network
CRNC Controlling RNC
CS Circuit Switched
CQI Coded Quality Indicator
CT Call Trace
CTCH Common Traffic Channel
DCH Dedicated Channel
DCCH Dedicated Control Channel
DCPS Dual-Core Packet Server
DDM Dual Duplexer Module
DDSM Dual Duplexer Sharing Module

DL Downlink
DPCCH Dedicated Physical Control Channel
DRNC Drift RNC
DRX Discontinuous Reception
DTCH Dedicated Traffic Channel
E-DCH Enhanced Dedicated Channel
eDCPS enhanced Dual-Core Packet Server
FACH Forward Access Channel
FDD Frequency Division Duplex
FPG Feature Planning Guide
FPGA Field-programmable gate array
GBR Guaranteed Bit Rate
GGSN Gateway GPRS Support Node
GPSAM Global Positioning System Alarm Management
GPxOIM Module supporting GPSAM functions and ready for
c2OIM or c3OIM insertion
GSM Global System for Mobile communications
GUI Graphical User Interface
HCS Hierarchical Cell structures
HO Handover
HHO Hard Handover
HLR Home Location Register
HSDPA High Speed Downlink Packet Access
HS-DSCH High Speed – Downlink Shared Channel
HS-PDSCH High Speed – Physical Downlink Shared Channel
HS-SCCH High Speed – Service Control Channel
HSUPA High Speed Uplink Packet Access
HW Hardware
IE Information Element
iMCTA Intelligent Multi Carrier Traffic Allocation
IOT Interoperability testing
MAC Medium Access Control (protocol layering context)
MBR Maximum Bit rate
MCPA Multi Carrier Power Amplifier
MGW Media Gateway
MLP MAC logical channel Priority
MM Multi Mode
MSC Mobile Switching Center
MSS Multi Service Switch
N/A Not Applicable
NBAP Node B Application Part
NRI Network Resource Identifier
OAM Operation, Administration and Maintenance
OIM Optical Interface Module
OLS Olympic Level Service
OPEX Operation Expenses
OS Operating System
OVSF Orthogonal Variable Spreading Factor
PCH Paging Channel
PCR PCR is the base Multiservice Switch (MSS) release
name
PS Domain Packet Switched Domain

RAB Radio Access Bearer
RACH Random Access Channel
RAN Radio Access Network
RANAP Radio Access Application Part
RAT Radio Access Technology
RB Radio Bearer
RF Radio Frequency
RNC Radio Network Controller
RNSAP Radio Network Subsystem Application Part
RoHS Restriction of the use of certain Hazardous Substances
RoT Raise over Thermal noise
RRC Radio Resource Control
RRH Remote Radio Head
RRM Radio Resources Management
RSI Resource Status Indicator
RSSI Received Signal Strength Indication.
RTSP Real Time Streaming Protocol
RTWP Received Total Wideband Power
QoS Quality of Service
SA Service Area
SABP Service Area Broadcast Protocol
SCCH Service Control Channel
S-CCPCH Secondary – Common Control Physical Channel
SGSN Serving GPRS Support Node
SI Sellable Item
SIB System Info Block
SM Single Mode
SMS Short Message Service
SMSCB Short Message Service – Cell Broadcast
SNMP Simple Network Management Protocol
SRB Signalling Radio Bearer
SrHO Softer Handover
SRNC Serving RNC
SRNS Serving Radio Network Subsystem
STSR Sector Transmit Sector Receive
SW Software
TC Traffic Class
TFCS Transport Format Combination Set
TFO Tandem Free Operation
THP Traffic Handling Priority
TIL Terminal d’Installation Local
TMA Tower Mounted Amplifier
TMU Traffic Management Unti
TrFO Transcoder Free Operation
TRM Transceiver module
TTI Transmission Time Interval
UCU UMTS Channel Element Unit
UE User Equipment
UL Uplink (Reverse Link)

UMTS Universal Mobile Telecommunications System
UP User Plane
URA UTRAN Registration Area
URA_PCH UTRAN Registration Area – Paging Channel
UTRA Universal Terrestrial Radio Access
UTRAN Universal Terrestrial Radio Access Network
VCC Virtual Channel Connection
VCI Virtual Channel Identifier
VLR Visitor Location Register
VPI Virtual Path Identifier
VSWR Voltage Standing Wave Ratio
WMS Wireless Management System
WPS Wireless Provisioning System

LR13 UTRAN FPG UMT - SYS - INF - 037991 v01 10EN Preliminary PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

LR13 UTRAN FPG UMT - SYS - INF - 037991 v01 10EN Preliminary PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

UMTS ACCESS NETWORK

FEATURE PLANNING GUIDE

Copyright © 2013 by Alcatel-Lucent Technologies. All Rights Reserved.

APRIL 25TH 2013 - ISSUE 01.10 / EN, Preliminary, External

APRIL 19TH 2013 - ISSUE 01.09 / EN, Draft, Internal

APRIL 2ND 2013 - ISSUE 01.08 / EN, Preliminary, External

MARCH 22ND 2013 - ISSUE 01.07 / EN, Preliminary, External

• 118307 – LR13.W Node B counter evolutions

FEBRUARY 22ND 2013 - ISSUE 01.06 / EN, Preliminary, Internal

JANUARY 29TH 2013 - ISSUE 01.05 / EN, Draft, Internal

OCTOBER 10TH 2012 - ISSUE 01.04 / EN, Preliminary, External

OCTOBER 8TH 2012 - ISSUE 01.03 / EN, Preliminary, External

JULY 25TH 2012 - ISSUE 01.02 / EN, Preliminary, Internal

JUNE 15TH 2012 - ISSUE 01.01 / EN, Draft, Internal

133975 – Hosting of 2 Node Bs WCDMA in one 9926 d4U ................................................ 85

1.2 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

RNC 9370 Other Node B 939x Node B

HW requirements None, N/A, None, N/A, None, N/A,

1.3 Features Lists

ID Feature Title Base or Other 939x

83659 VoIP from LTE VoIP to WCDMA CS Optional S S

167400 TRDU2x60-09 WCDMA configurations in Optional – HW S NS

2.1 Applicable documents

2.2 Reference documents

[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 UA05.1 Access Network Feature Planning Guide

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

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

[R8] UMT/SYS/INF/030972 UA08.1 Access Network Feature Planning Guide

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

3 LR13.W MAIN DRIVERS

Increase Node B site capacity

Improved HSPA performances

Mobility with LTE

4 LR13.W OPTIONAL SOFTWARE PACKAGES

5 LR13.W FEATURES DESCRIPTION

• 3GPP release: Rel-9

• 3GPP specification version: December 2010

RNC 9370 Other Node B 939x Node B

HW requirements None None None

Configuration Management and Parameters

Fault Management and Alarms

5.2 PERFORMANCES AND CAPACITY

Enabler for Enhanced CELL_FACH Rel-8

RNC 9370 Other Node B 939x Node B

HW requirements None xCEM(-u), eCEM(-u) N/A

Increased FACH capacity

Reduced Round Trip Time (RTT) in CELL_FACH

RNC 9370 Other Node B 939x Node B

HW requirements None eCEM(-u) N/A

Fault Management and Alarms

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

120363/165360 – Smart E-DCH resource usage

RNC 9370 Other Node B 939x Node B

HW requirements None xCEM(-u), eCEM(-u) UCU-III

Distribution of E-DCH UE categories (according to the UE information provided in the

Distribution of E-TFCI per E-DCH UE category