RL45TD Feature Description

Prepared by Date Page
07.07.2014 1/95
Nokia Solutions and Networks Approved by Doc number Version

LTE RAN 1.0
LTE RAN Release RL45TD (TD-LBTS4.0)

New Features
07.07.2014 2/95

LTE RAN 1.0
The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This documentation is intended for the
use of Nokia Solutions and Networks customers only for the purposes of the agreement under
which the document is submitted, and no part of it may be used, reproduced, modified or
transmitted in any form or means without the prior written permission of Nokia Solutions and
Networks. The documentation has been prepared to be used by professional and properly
trained personnel, and the customer assumes full responsibility when using it. Nokia Solutions
and Networks welcomes customer comments as part of the process of continuous development
and improvement of the documentation.
The information or statements given in this documentation concerning the suitability, capacity,
or performance of the mentioned hardware or software products are given as is and all liability
arising in connection with such hardware or software products shall be defined conclusively and
finally in a separate agreement between Nokia Solutions and Networks and the customer.
However, Nokia Solutions and Networks has made all reasonable efforts to ensure that the
instructions contained in the document are adequate and free of material errors and omissions.
Nokia Solutions and Networks will, if deemed necessary by Nokia Solutions and Networks,
explain issues which may not be covered by the document.
Nokia Solutions and Networks will correct errors in this documentation as soon as possible. IN
NO EVENT WILL NOKIA SOLUTIONS AND NETWORKS BE LIABLE FOR ERRORS IN THIS
DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,
DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES,SUCH AS BUT
NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS
OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR
THE INFORMATION IN IT.
This documentation and the product it describes are considered protected by copyrights and
other intellectual property rights according to the applicable laws.
NSN is a trademark of Nokia Solutions and Networks. Nokia is a registered trademark of Nokia
Corporation.
Other product names mentioned in this document may be trademarks of their respective
owners, and they are mentioned for identification purposes only.
Copyright Nokia Solutions and Networks 2013. All rights reserved.
07.07.2014 3/95

LTE RAN 1.0
Table of Contents
1 Introduction ......................................................................................................................... 5
2 History ................................................................................................................................ 6
3 BTS Site Solution ................................................................................................................ 7
3.1 FZHG Flexi RRH 2TX 2600 ......................................................................................... 7
3.2 Flexi System Module Indoor Variants FSIH & FBIH .................................................... 8
3.3 RL45TD Site Configurations with FSIH ........................................................................ 9
3.4 Enhanced external GPS box FYGE ............................................................................11
3.5 FZHJ Flexi RRH 8TX 2600 BD41................................................................................12
3.6 RL45TD Site Configurations with FSMF ......................................................................13
3.7 FZHO Flexi RRH 2TX 2600 ........................................................................................15
3.8 FZHJ-b Flexi RRH 8TX 2600 ......................................................................................16
4 Transmission .....................................................................................................................18
4.1 IPv6 for U/C-Plane ......................................................................................................18
4.2 IPSec Emergency Bypass...........................................................................................20
4.3 Measurement based TAC ...........................................................................................22
4.4 Local and Remote IP Traffic Capturing .......................................................................24
5 Radio Resource Management and Telecom ......................................................................26
5.1 LTE:Mobility ................................................................................................................26
5.1.1 Measurement-based Redirect to UTRAN .............................................................26
5.1.2 RSRQ triggered mobility ......................................................................................27
5.1.3 Inter-frequency load balancing extension .............................................................28
5.1.4 Multiple Frequency Band Indicator .......................................................................29
5.1.5 Idle mode mobility balancing extensions ..............................................................30
5.1.6 Serving PLMN ID change during X2 based handover ..........................................31
5.1.7 Extended inter-frequency measurements.............................................................32
5.1.8 RAN Information Management for GSM...............................................................33
5.1.9 Intra cell handover ...............................................................................................34
5.1.10 Inter RAT handover from UTRAN ........................................................................35
5.1.11 Inter RAT handover to eHRPD/3GPP2 ................................................................36
5.1.12 SRVCC to WCDMA .............................................................................................39
5.1.13 SRVCC to GSM ...................................................................................................40
5.1.14 CSFB to CDMA/1xRTT for dual RX UEs ..............................................................43
5.2 LTE:Coverage, capacity and peak rates .....................................................................45
5.2.1 Interference aware UL power control ...................................................................45
5.2.2 Uplink Intra-eNB CoMP ........................................................................................46
5.2.3 8x2 SU MIMO with TM9 .......................................................................................47
5.2.4 TDD Downlink carrier aggregation .......................................................................49
5.2.5 64 QAM in UL ......................................................................................................51
5.3 LTE:QoS, services and end user experience ..............................................................52
5.3.1 Multimedia priority services ..................................................................................52
5.3.2 Operator-specific GBR QCIs ................................................................................53
5.3.3 Cell resource groups ............................................................................................54
5.3.4 LPPa support for OTDOA ....................................................................................56
5.3.5 Multiple emergency areas per cell........................................................................57
07.07.2014 4/95

LTE RAN 1.0
5.3.6 Commercial Mobile Alert System .........................................................................58

5.3.7 IMS emergency sessions .....................................................................................60
5.3.8 Smart DRX ..........................................................................................................60
5.3.9 ETWS broadcast..................................................................................................61
5.4 LTE:Supplementary RRM functions ............................................................................62
5.4.1 Control plane overload handling ..........................................................................62
5.5 LTE:Basic LTE call handling and interworking ............................................................64
5.5.1 S1 Overload Handling ..........................................................................................64
6 Operability..........................................................................................................................65
6.1 Network Monitoring and Maintenance .........................................................................65
6.1.1 BTS Diagnostics Toolkit used by operator ...........................................................65
6.1.2 S1 lock/unlock......................................................................................................67
6.2 Configuration Management .........................................................................................69
6.2.1 Parameter Categorization ....................................................................................69
6.2.2 Support for Multi-antenna RET device .................................................................72
6.2.3 System Upgrade from RL35 (TD-LBTS3.0) to RL45 (TD-LBTS4.0) .....................73
6.2.4 Extend maximum number of X2 links ...................................................................75
6.2.5 System Upgrade from RL35 Ir (TD-LBTS3.1) to RL45 EP....................................77
6.2.6 Automatic cell combination assignment for Carrier Aggregation of TD-LTE .........80
6.2.7 Synchronization of InterRAT neigbhors ................................................................81
6.2.8 ANR Intra-LTE, Inter-frequency - UE based .........................................................83
6.2.9 SW Monitoring Extension with PM Counters ........................................................86
6.2.10 Intelligent configuration synchronization ...............................................................88
6.3 O&M Security..............................................................................................................89
6.3.1 Revocation management .....................................................................................89
7 Performance Monitoring .....................................................................................................94
7.1 Additional QoS performance measurements ...............................................................94
07.07.2014 5/95

LTE RAN 1.0
1 Introduction
This document provides the list of feature candidates for the LTE Radio Access System
Release RL45TD(TD-LBTS4.0).
The scope of the document includes evolved NodeB (eNB) and Transmission. The LTE is
managed with the NetAct Operations Support System (OSS) and its interfaces with Packet
Switched (PS) Core Networks (CN) over the S1 interface. Operation Mediation Subsystem
(OMS) is used to aggregate O&M traffic and mediate data format towards the NetAct. OMS is
usually located at the NetAct.
The LTE Flexi Multiradio BTS functionality is implemented in compliance with the 3GPP
interface specification baseline 3GPP Rel-11 March 2013. There may be changes to the final
solutions due to the final release definition process and 3GPP's standardization changes. This
document covers only Nokia Solutions and Networks LTE RAN level issues and the high level
dependencies for the Core Network, WCDMA, GSM system and Mobile Station support. The
Flexi Multiradio BTS functionality may not work if the support in one or multiple other network
elements, e.g. eNode Bs, UEs, MME, S-GW, eSMLC, MSC, BTS, Node B etc is not provided.
The UE dependency is outlined in the SW dependencies field UE. The other RAT
dependencies are outlined in the field dependencies to other RATs. The core network
dependencies to EPC are outlined in the fields MME and S-GW.
In the fields BTS Flexi for FSMD/E and BTS Flexi 10 for FSMF family the support of the
feature is indicated with release name; blank means not supported. In the field HW
requirements it will be indicated if the feature requires additionally a specific HW in RAN LTE
portfolio. It is left blank if the feature describes a HW item itself or has no specific requirements.
The Flexi Multiradio BTS functionality may rely on the activation of other eNode B features. This
feature interdependency is outlined in the field interdependencies between Features.
IOTs with other network elements, e.g. eNode Bs, MME, S-GW, eSMLC, MSC, BTS, Node B
etc., UEs or applications have to be conducted well in advance in order to ensure the
interoperability with other network elements on protocol level. Such testing need to be agreed
with NSN IOT department according IOT standard process. 3GPP has not defined the
interworking of algorithms, i.e. KPI may depend on multi-vendor scenarios.
The actual performance of the feature in field will depend on several external factors e.g. radio
condition, antenna configuration, UE location, UE speed, cell load, transport network
dimensioning, etc.
In SW Sales Information the optional Sales Items are indicated with ASW (Application SW).
ASW NetAct refer to Sales Items defined within NetAct. Basic SW items are indicated with
BSW. LTE RAN SW is using SW Asset Monitoring as licensing approach.
This document is NON BINDING.

07.07.2014 6/95

LTE RAN 1.0
2 History
V1.0 RL45TD C5 Version on Jul,7th
07.07.2014 7/95

LTE RAN 1.0
3 BTS Site Solution

3.1 FZHG Flexi RRH 2TX 2600
Unique ID: 1493
Short Description:
TD-LTE Flexi Remote Radio Head with 2TX/2RX for frequency range 2635 - 2675 MHz.
Benefits for the Customer:

Remote RF Head is able to support 2TX MIMO with high output power. It enables easy
installation outdoors close to antennas thus maximising BTS site capacity and coverage.
Functional Description:
The supported frequency band (41) is 2635-2675Mhz for TD-LTE(subject to change based on
the official announcement of China BD41 allocation plan).This is an OEM product from TD-
Tech/Huawei(named RRU3675). Main features of TDD RRH 2600 2TX are:
- Marketed 60W + 60W with two power amplifiers; but in reality only reached to 2*50W in -40 to
+45 C working temperature.
- Maximum concurrent bandwidth: 2x20MHz
- Optimized for single sector deployment with 2TX MIMO
- LTE: HW supports 10MHz/20MHz per carrier
- Receiver sensitivity: better than -103.5 dBm
- Spectrum emission mask: 3GPP protocol
- Optical CPRI Interface (2 9.8G hardware capable, backward compatible to support 6.144G,
etc.)
- Optical chaining supported by HW
- IP65
- Operating temperature: -40 to +50 C with natural convection cooling(without wind, without
solar radiation)
- RET functionality via Main TRX RF connector
- Power Inputs: Both DC and AC version are offerred. FZHG-dc: -48V DC(-36V DC ~ -60V DC).
FZHG-ac: ~220V(176V AC290V AC).
- Suggested Size(HxWxD): 400mm*300mm*100mm (includes all interface ports)
- Suggested Volume: 12L
- Suggested Weight: <=14Kg without cover; <=15Kg with cover
HW Requirements: no specific HW requirements
Interdependencies between Features: no feature interdependencies

07.07.2014 8/95

LTE RAN 1.0
TD-LTE RL Software Dependencies

LTE BTS BTS BTS NetAct OMS MME SAE UE
Flexi Flexi 10 Flexi 10 GW
Indoor
Release RL45TD TD- TD- - - -
LBTS4.0 LBTS4.0
SW Sales Information:
BSW/ASW Licence Control in Network Licence Control Attributes
Element
BSW -
3.2 Flexi System Module Indoor Variants FSIH & FBIH

Unique ID: 1510
Short Description:
This is a proposal to introduce FSMr3 indoor variant FSIH and FBIH.

Compact indoor solution for max BF configuration
This is an indoor system module based on FSMr3 with increased DSP(6TurboNyquist/3Nyquist)

and RP3-01 link capacity. HW is capable of supporting TD-LTE 9x20MHz 8T8R Beamforming
within one BBU.
Key system/module requirements:
-Indoor BBU consists of casing, one core module (FSIH), 0~2 capacity and/or technology
extention sub-module (FBIH), backplane panel and fans in same package.
-The casing can accomodate one indoor FSIH module and two FBIH modules.
-Dimension target 2.5HU (current LE: 3HU) and 450mm depth (including front cabling and fans).
-HW Capacity is up to 3x20MHz 8T8R Beamforming cells per FSIH/FBIH FSP board, and up to
9x20MHz 8T8R Beamforming cells per BBU.
-Requires min. 21 (target 24) external RF links; 18 RF links to RRH / RF-Module, 3 RF links to
TD-SCDMA BBU for dual modes RF sharing purposes.
-S1/X2 over Ethernet, supporting > 1G Ethernet throughput (minimum 2x1G). In RL45, only
1x1G SW support is required although HW readiness for both 2 ports are needed.
-Max. 3x9.8G CPRI per FSP, integrated GPS in FSIH, TDL/TDS IQ data Mux/Demux.
-HW ready to support ToP/1588V2 (with chipset) and IQ compression feature (with FPGA).
- GPS/Synchronization holdover design target: min +/-1.5us for 4 hours without SW algorithm.
Guarantee: +/-5us for 4 hours.
- HW ready to support both Obsai and Cpri, while Obsai will be first developed in RL45.
07.07.2014 9/95

LTE RAN 1.0
This feature requires hardware readiness of the following features

* LTE1257 Integrated RFGPS
* LTE1335 9.8Gbps Ir Interface
Site configuration S111 for 8T8R is a basic configuration that FSIH needs to support and is
within the scope of this feature. In RL45, this will be implemented with the constraint that all RF
links will be connected through FCT board.
Dependency to other RATs:No dependency

Indoor
Release RL45TD not TD- - - - n/a
supported LBTS4.0
Element
BSW -
3.3 RL45TD Site Configurations with FSIH

Unique ID: 1570
Short Description:
The site configurations in RL45 with new system module FSIH

Allow customer to deploy their network with the new system module FSIH
Configurations without hardware pre-installation (configuration 1-3)

Configuraton 1:
FSIH(+FBIH) to support 8Tx 8Rx configuration, 2.6GHz
Up to 3 sectors per site
Each sector with up to two carrier
RF variants: FZHJ/FZHA/FZHJ-b
Configuration 2:
FSIH(+FBIH) to support 4Tx 4Rx configurations, 2.6GHz
07.07.2014 10/95

LTE RAN 1.0

Each sector with up to two carriers
RF variants: FZHJ
Configuration 3:
FSIH(+FBIH) to support 2Tx 2Rx configurations, 2.6GHz
RF variants: FZHJ
Configuraitons with hardware pre-install for 3x carriers (configuration 4-6)

Configuration 3:
8Tx 8Rx configurations, 2.6GHz (T111/T222 8T8R)
System module and fiber cables are pre-installed ready for T333 8T8R: FSIH+2xFBIH
RF variants: FZHJ
Configuration 4:
RF variants: FZHJ
Configuration 6:
RF variants: FZHJ
Details for the configuraitons can refer to attached ppt.

Indoor
Release RL45TD not TD- - - -
supported LBTS4.0
Element
07.07.2014 11/95

LTE RAN 1.0
BSW -
3.4 Enhanced external GPS box FYGE

Unique ID: 1668
Short Description:
This is an enhancement to LTE1252 FYGD based on major LTE customer need.
support GPS holdover time of more than 24hours with less than +/-1.5us phase drift
This is an enhancement to LTE1252 FYGD based on LTE customer need.

Extend the capability of LTE1252 GPS box to include more than 24hour holdover time
with less than +/-1.5us phase drift.
Add circuitry to GPS box for eNB to be able to control the on/off of 5V DC bias to GPS
antenna.
Mechanical solution to be able to be mounted external to BBU(eg, FSMF, FSIH) and fix
on a standard 19inch rack, as well as being able to be assembled into current FPFD slot
on FSMF
Separate power supply input(in FYGD, power is supplied from HDMI port which might
not be enough for FYGE)
FYGD function of 1588 in/out ports and primary/secondary timing source selection are
not required
Front panel power ON/OFF button is not required
Other requirements follow and inherit LTE1252 FYGD, these include
1. TSIP protocol compliance
2. Hardware readiness to support hardware module firmware upgrade
3. Working Temperature: -20~55C
4. IP20
Initially, FYGE will be introduced as plug-n-play. The module will behave exactly like an FYGA
or FYGB or FYGD(default mode). So
1. No FYGE holdover is supported
2. FYGE turns off its 1PPS output when GPS is lost
3. eNB holdover is triggered by detection of loss of the 1pps input signal
I and V effort from Release program will be needed for validate the solution
The following functions will be included in separate SW features
1. eNB SW control of the above mentioned 5V DC bias on/off control
2. Complete eNB SW support to FYGE control or alarm reporting and holdover handling
3. Firmware upgrade through eNB

07.07.2014 12/95

LTE RAN 1.0

Indoor
LBTS4.0 LBTS4.0
Element
BSW -
3.5 FZHJ Flexi RRH 8TX 2600 BD41

Unique ID: 1674
Short Description:
FZHJ - Flexi RF Head 8x20W for 3GPP Band 41. This RF Module is based on Broadcom DFE
platform.

Flexi RF Head BD41 8x20W is able to support 8TX/8RX beamforming with high output power. It
enables easy installation outdoors close to antennas.
Main features of Flexi RRH 8TX 2600 are:

* Supported frequency: 3GPP BD41 2496-2690MHz.
* Output power: 20W per path.
* Configurable TX power per path: 20W, 10W, 15W, 5W
* Instantaneous 60MHz per pipe RF bandwidth supported; Stretch goal for iBW up to 80-
100MHz provided no significant cost adder (<20 Euro).
* Occupied bandwidth: 60MHz (3xLTE20MHz) per pipe - non contigous carrier support
* Optimized for single sector deployment with 8-path BF.
* Configuration options: 8T8R 60 MHz as well as 2*4T4R 120MHz. 2 independent pairs of pipes
being tuned to same or different centre frequencies within BD41 supported by 2 sets of LO.
* Able to calibrate the timing, amplitude and phase of the DL/UL paths
* 6Gbps optical interface OBSAI, 6 x duplex LC connectors
* HW support 3 x 9.8G CPRI interfaces dropped due to product schedule impact
* IP65
* -35 to +5o C, with nature conventional cooling design
07.07.2014 13/95

LTE RAN 1.0
* DC-connector (-48V, 0V, Earth)

* External alarms
* 24KM filber delay buffer; Up to 24km fiber link for single hop.
* AISG/RET: RS485 connector
* Receiver Noise Figure: <=3dB
* RX Sensitivity: better than -104dBm; stretch goal is -105dBm.
* MTBF: > 200 000 hours @25C
* MHA: Only reserve board space if feasible
* HW capable to use at least one path to capture the RF- snapshot data with RF- snapshot
duration time at lest 0.13ms

Indoor
LBTS4.0 LBTS4.0
Element
BSW -
3.6 RL45TD Site Configurations with FSMF

Unique ID: 1707
Short Description:
RL45 TDLTE site configuration with FSMF

Allow customer to deploy their network untilizing multiple bandwidth resources.
In RL45 following configuration need to be supported with flexi system module FSMF and
extension module FBBA. And RL35 legacy configurations should be inherited to RL45.
Configuration 2: 2.6G 2pipe FZHG configuration
System Configuration: FSMF+FBBA
Configuration: T1111 2T2R
07.07.2014 14/95

LTE RAN 1.0
20MHz per cell

up to 4 sectors (T1111/T111/T11/T1)
RF variant : FZHG
Single mode
Configuration 3: 1.9G 2pipe FZFE configurations
FZFE dual mode
2Tx 2Rx Outdoor configurations, T111(1.9GHz)
System module: FSMF(no FBBA)
Each sector with one 1.9GHz carrier
Bandwidth: 20MHz
RF variants: FZFE
Working mode: Dual mode
FZFE dual mode (super cell)
2Tx 2Rx configurations, T111 and T222 (1.9GHz)
System module: FSMF(no FBBA)
Up to 3 chains per site
Each chain with up to 2 RRU
All RRU in same super cell.
Bandwidth: 20MHz
RF variants: FZFE
Working mode: Dual mode
Configuration 4: 2.3G FZND 1T1R star configuration.
Star connection, without chaining or cell comination.
Up to 6 RRU per site.
Each RRU is one TM1 cell
RF variant: FZND single mode
And for the not used pipe, PA should be shut off.
(details can be found in attached slides)
Configuration 5: 2.6G 2pipe FZHO configuration
T11111 2T2R
up to 6 sectors (T111111/T11111/T1111/T111/T11/T1)
20MHz bandwidth
Single mode

Indoor
Release RL45TD TD- not - - -
LBTS4.0 supported
07.07.2014 15/95

LTE RAN 1.0
Element
BSW -
3.7 FZHO Flexi RRH 2TX 2600

Unique ID: 1953
Short Description:
TD-LTE Flexi Remote Radio Head with 2TX/2RX for frequency range 2535 - 2575 MHz.

Remote RF Head is able to support 2TX MIMO with high output power. It enables easy
installation outdoors close to antennas thus maximising BTS site capacity and coverage.
The supported frequency band (41) is 2535-2575Mhz for TD-LTE(subject to change based on
the official announcement of China BD41 allocation plan).
This is an OEM product from TD-Tech/Huawei(named RRU3775). Main features of TDD RRH
2600 2TX are:
- Marketed 60W + 60W with two power amplifiers; but in reality only reached to 2*50W in -40 to
+45 C working temperature.
- Maximum concurrent bandwidth: 2x20MHz
- Optimized for single sector deployment with 2TX MIMO
- LTE: HW supports 10MHz/20MHz per carrier
- Receiver sensitivity: better than -103.5 dBm
- Spectrum emission mask: 3GPP protocol
- Optical CPRI Interface (2 9.8G hardware capable, backward compatible to support 6.144G,
etc.)
- Optical chaining supported by HW

07.07.2014 16/95

LTE RAN 1.0
- IP65
- Operating temperature: -40 to +50 C with natural convection cooling(without wind, without
solar radiation)
- RET functionality via Main TRX RF connector
- Power Inputs: Both DC and AC version are offerred. FZHO-dc: -48V DC(-36V DC ~ -60V DC).
FZHO-ac: ~220V(176V AC290V AC).
- Suggested Size(HxWxD): 400mm*300mm*100mm (includes all interface ports)
- Suggested Volume: 12L
- Suggested Weight: <=14Kg without cover; <=15Kg with cover

Indoor
LBTS4.0 supported
Element
BSW -
3.8 FZHJ-b Flexi RRH 8TX 2600

Unique ID: 1780
Short Description:
FZHJ-b - Flexi RF Head 8x20W for China Mobile Band 41 spectrum. This Remote Radio Head
is OBSAI variant based on FZHJ and Broadcom DFE platform.
07.07.2014 17/95

LTE RAN 1.0
Flexi RF Head BD41 8x20W is able to support 8TX/8RX beamforming with high output power. It
enables easy installation outdoors close to antennas.
This is a filter retuned version based on FZHJ, targeted for CMCC and is planned for couple of
month's commercial delivery before FZHM(LTE1847) is available.
Main features of Flexi RRH 8TX 2600 FZHJ-b are same as FZHJ(LTE1674) except the
supported frequency band:
* Supported frequency: 2555-2655MHz

* Output power: 20W per path.
* Configurable TX power per path: 20W, 10W, 15W, 5W
* Instantaneous 60MHz RF bandwidth per pipe supported.

* Occupied bandwidth: 60MHz (3xLTE20MHz) per pipe
* Optimized for single sector deployment with 8-path BF.
* Configuration options: 8T8R 60 MHz as well as 2*4T4R 120MHz.
* Able to calibrate the timing, amplitude and phase of the DL/UL paths
* 6Gbps optical interface OBSAI, 6 x duplex LC connectors
* IP65
* -40 to +50 C, with nature conventional cooling design
* DC-connector (-48V, 0V, Earth)
* External alarms
* >24KM filber delay buffer; Up to 24km fiber link for single hop.
*AISG & RET support
* Receiver Noise Figure: <=4dB
* RX Sensitivity: better than -104dBm
* MTBF: > 150 000 hours @25C

* RF connector type: Mini-DIN
* Weight <=23Kg & Volume <31L
HW Requirements:
07.07.2014 18/95

LTE RAN 1.0
TD-LTE RL Software Dependencies:

LTE BTS BTS Flexi NetAct OMS MME SAE UE
Flexi 10 Flexi 10 Zone GW
Indoor Micro
Release RL45TD TD- TD- not

LBTS4.0 LBTS4.0 supported
Element
BSW -
4 Transmission
4.1 IPv6 for U/C-Plane
Unique ID: 125
Short Description:
The eNB supports IPv6 for User-and Control- Plane
The Management- and Synchronisation-Plane and also Site Support Equipment (SSE) remain
with IPv4.
The eNB supports IPv4 for the IPsec tunnel layer.

This feature supports migration of the mobile operator networks and IP transport networks from
IPv4 to IPv6.
LTE application IP layer:

The eNB supports termination of user and control plane transport on IPv6 addresses. When
activated, it applies to all user and control plane addresses, i.e. only exclusive use of either IPv4
07.07.2014 19/95

LTE RAN 1.0
or IPv6 is supported (This means, there is no dual stack support for the application IP layer with
this feature).
Management-, synchronization application and SSE remain with IPv4 support only.
Note: Consequently the auto-connection procedure remains with IPv4 and uses DHCPv4.
LTE transport network layer:
The eNB supports dual stack IPv4/IPv6 network interfaces. Both IP versions can be used
simultaneously.
Transport network requirements:
- IPsec in use:
* IPv6 can be used solely at the application layer (thus not requiring IPv6 in the transport
network).
* Each IPsec tunnel pair between the eNB and the Security Gateway is using IPv4 in both
directions.
- IPsec not in use:
* A dual stack transport network is required (IPv4 still required for management and
synchronization traffic).
In addition to the existing IPv4 host functions, the eNB supports the functions of an IPv6 host as
described in the following specifications:
- RFC 2460 Internet Protocol Version 6 (IPv6) Specification: Support of all IPv6 header fields
(except Flow Label), support of extension headers for Fragmentation, Encapsulating Security
Payload (acc. to RFC4303), hop-by-hop (router alert) and No Next header
- RFC 4861 Neighbor Discovery for IP Version 6 (IPv6)
- RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6). Support of the following messages: neighbor solicitation/advertisement, destination
unreachable, time exceeded, parameter problem, echo request/reply (router solicitation and
advertisement are not supported)
- RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
- RFC3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6
- RFC4862 IPv6 Stateless Address Autoconfiguration (for link-local addresses only), incl.
Duplicate Address Detection
The following limitations apply:
- IPv6 is not supported for management and synchronization plane termination,
- IPsec tunnels are not supported over IPv6,
- Path MTU Discovery (PMTUD) and ICMPv6 Redirects are not supported,
- Supported global unicast address prefix: 2000::/3..127
- Supported unique local unicast prefix: FC00::/7..127
- SLAAC (RFC4862) functionality is limited to generation of link-local addresses (no further
global addresses will be generated, as eNB does not process Router Advertisement messages),
- Handovers between eNBs with different IP version in use are limited to S1-based handovers
with indirect forwarding.
07.07.2014 20/95

LTE RAN 1.0
HW Requirements: FSME: Transport sub-module FTIB and FTLB is a future study item
FSMF with and without FTIF supported
Interdependencies between Features: N/A

Indoor
Release RL45TD TD- TD- NetAct8 x x n/a
LBTS4.0 LBTS4.0 EP1
Element
ASW SW Asset Monitoring
4.2 IPSec Emergency Bypass

Unique ID: 1390
Short Description:
07.07.2014 21/95

LTE RAN 1.0
In case BTS detects a severe IPsec failure, IPsec at the BTS can be switched off in an operator
controlled way, not requiring any site visit. Switching back from IPsec Emergency bypass mode
to IPsec mode is exclusively controlled by operator.
Feature allows limiting the network outage time in case of a severe IPsec cluster failure to a
minimum
- Security Gateway resilience is broadly implemented by operating a pair of GWs in a HA (high
availability) cluster, one GW being active, one being standby, with stateful failover
- Even the best resilience solution still poses the potential risk that unexpected failures happen,
which are thus not covered by the solution and might affect the whole HA cluster
- If whole Security Gateway HA cluster fails larger area will go out of service
- In failure case it is not possible to deactivate IPsec in the BTS as BTS is managed through the
IPsec tunnel, thus BTS remains from O&M perspective not reachable
- In extreme, depending on duration of Security Gateway HA cluster failure situation, even site
visit would be required
The feature mitigates as well outages due to misconfiguration.
BTS supervises the status of the configured IPsec tunnels. An IPsec tunnel is regarded as IKE
security association (IKE SA) with one or more related IPsec (ESP) security associations (IPsec
SA).
In case it cannot establish an IKE SA and/or IPsec SA or an established one becomes non-
operational it enters IPsec Emergency Bypass "probing state". During probing state the BTS
- continuously retries establishment of non-operational SAs as specified in the "IPsec for BTS"
feature
- periodically accesses an operator controlled server to check allowance for switching off IPsec
The IP address of the Control Server and the timer that controls in what interval BTS accesses
the Control Server is configurable in BTS.
Entering "probing" state after failure occurrence will not take more than 5 minutes. Actual
duration depends on nature of the failure, IKE version and timer configuration with respect to
Dead Peer Detection.
In case BTS in "probing" state succeeds with its re-establishment attempts for all failed SAs, it
will exit the "probing" state, stops accessing the Control Server and ignores return messages
from it.
IPsec Emergency Bypass state transition from "probing" to "active" happens if the Control
Server is reachable and provides the valid return message. Reachability of this server is
controlled by the operator and in this sense is used as "switch" to allow the BTS to enter active
state. After having concluded a severe IPsec failure, the operator typically makes the Control
Server accessible by reconfiguration of the core network edge router and/or Security Gateway
in order to accept unprotected traffic.
When entering IPsec Emergency Bypass "active state" all traffic is sent unprotected to same
peers, using same VLAN ID, interface IP address, application IP addresses, default gateway
and firewall rules as before. Consequently only unprotected traffic is accepted in receive
direction.
07.07.2014 22/95

LTE RAN 1.0
"Active state" will last until it is either exited by an operator command via BTS management
interface or BTS reboot occurs. When leaving this state IPsec is operational again and BTS tries
to establish all SAs as per configuration.
The feature does not support to switch off IPsec selective per policy, but switches off IPsec
completely. Thus it is not suited for scenarios where multiple Security Gateways are connected
to the BTS, e.g. in combination with feature LTE505 "Transport Separation for RAN Sharing".
HW Requirements: Future study item for Flexi MR10K BTS
Interdependencies between Features: Feature can only be applied in conjunction with

LTE689 LTE IPsec Support

Indoor
Release RL45TD TD- TD- NetAct8 - - n/a
LBTS4.0 LBTS4.0 EP1
Element
4.3 Measurement based TAC

Unique ID: 1401
Short Description:
07.07.2014 23/95

LTE RAN 1.0
The Measurement Based Transport Admission Control (MBTAC) grants or rejects requests
based on measurement of the actually used transport bandwidth.
It is a functional enhancement of the feature LTE144 Transport Admission Control which is

based on book-keeping of estimated transport bearer bandwidths
OPEX reductions due to the following:

- Simplified and less configuration work (preventing misconfiguration)
- No estimation on Traffic profiles and traffic mixes are needed for configuration of the eNB
- Optimal e2e performance due to adaptive TAC behavior (in line with RAC).
- Best utilization of backhaul bandwidth with fully automatic adaption to changing traffic profiles
over the time (e.g. week or day).
- No manual optimizations needed in case of changing user traffic patterns, e.g. when using
new voice or video codecs
The measurement based TAC (MBTAC) is continuously measuring the actual traffic in DL and
UL. New calls (GBR services) are accepted or rejected, depending on the transport load
situation.
The following functional principles are used:
- Direct measurement of the actual outgoing (UL) and incoming (DL) GBR traffic rate at the
transport interface. GBR traffic is identified by the DSCP values of the IP packet. Only the
selected DSCP values are included in the measurement.
- The decision for acceptance or rejection of a new connection request is based on a statistical
evaluation of these measurements
- The traffic measurement carried out by MBTAC distinguishes the traffic by DSCP values.
Different sets of DSCP values are assigned to GBR and non-GBR services, such that these can
be distinguished unambiguously. With this guideline, any traffic type mixture of GBR and non-
GBR can be handled.
- Some of the parameters used for the currently used book-keeping algorithm will not be needed
anymore (e.g. average packet sizes, activity factors for QCI=1,2,3,4)
- In contrast to LTE144, MBTAC relies on measured user traffic, and not on traffic estimations
- MBTAC avoids any assumptions about codec types (for voice or video)
- When using transport separation for RAN sharing (LTE505), one instance of TAC is supported
per operator. There is a configurable list of VLANs for each operator, defining which VLANs are
included into the measurements.
- PM counters e.g. for total number of connection requests, number of accepted and rejected
requests.
HW Requirements: N/A
Interdependencies between Features: Solution replaces LTE144 Transport Admission

Control

07.07.2014 24/95

LTE RAN 1.0

Indoor
LBTS4.0 LBTS4.0 EP1
Element
BSW -
4.4 Local and Remote IP Traffic Capturing

Unique ID: 1460
Short Description:
This feature captures ingress and egress IP traffic (like C-, U-, M- and S- planes and as well
SSE and other router traffic like CESoPSN) and allows local streaming to a storing device and
local and remote file retrieval of the captured packets.
Operator User stories:

* As a maintenance engineer I want to capture the transport IP traffic related to a single UE at
a BTS in the field to calculate the KPIs, prove correct BTS behavior and evaluate actual network
performance.As an operator I want faults to be analyzed and solved by the vendor as quickly as
possible so that consequences are as minimal as possible
* As a maintenance engineer I want to capture BTS traffic when being connected remotely in
order to investigate unexpected BTS behavior.
* As an engineer I want to locally capture BTS traffic over a period of up to several days in
order to investigate unexpected BTS behavior, support bugfixing and customer trials.
* As a maintenance engineer I want to avoid extra site visits to retrieve transport capture files
so that I can save time, cost and effort
* As Technical Support engineer I want to have the transport capture files as often as possible
included to the ticket so that I can significantly reduce the ticket resolving times.
* As Technical Support engineer I want local unlimited IP traffic capturing including U-plane
headers so that I can cover all possible faults and use cases that require transport traces
* As a maintenance engineer I want a robust and simple configuration interface so that I
configure the IP traffic capturing even in fault or congestion situations
Other benefits:
* In many fault scenarios mirrored or monitored traffic is required. If IPsec is in use, decrypted
traffic trace is required
07.07.2014 25/95

LTE RAN 1.0
* To avoid site visits and speed up root cause analysis, remote monitoring of decrypted traffic
is required.
* Tickets can be delivered quickly with all required content Incl. TRS capture file
* Customer saves time and effort for root cause analysis
"Local and remote IP traffic capturing" enables technical staff to capture the IP traffic (ingress
and egress) of a BTS and to download it for later offline root-cause analysis.
For local and remote use, the captured packets are stored in a compressed libpcap file for
download (max. size of libpcap file before compression is 150MB). The file can be optionally
protected with a password.
For local use, the captured packets can be alternatively streamed to storage device connected
to a configurable, unused transport port or the LMP.
The feature is configured via a Web-GUI where the user selects the measurement point, the
system module and may select whether U-plane is excluded to maximize the capturing duration
One of two traffic capturing points can be selected at a time:

A) Capturing of complete packets, clear-text (even in IPsec case), U-plane headers; capturing
of traffic of one RAT application only.
B) Capturing of fragments, outer packet header only for IPsecured streams; capturing of
traffic of one RAT application only.
Capturing of IPv4 and IPv6 packets is supported. In order to maintain end user privacy and to
comply with legal regulations in certain countries, user plane payload is never captured. If user
plane is selected, only user plane header information is captured.

07.07.2014 26/95

LTE RAN 1.0

Indoor
Release RL45TD TD- TD- - - - n/a
LBTS4.0 LBTS4.0
Element
BSW -
5 Radio Resource Management and Telecom

5.1 LTE:Mobility
5.1.1 Measurement-based Redirect to UTRAN
Unique ID: 1073
Short Description:
Extended PS handover functionality for UEs supporting IRAT measurements but no PS

handover

Higher reliability for LTE to UTRAN service continuity
Interdependencies between Features: The feature is enabled together with LTE56.
with TDD, LTE898 needs to be enabled also with target system TD-SCDMA.

Indoor
Release RL45TD TD- TD- OSS5.4 x - 3GPP R8
LBTS4.0 LBTS4.0 CD2 UE
capabilities
Element
07.07.2014 27/95

LTE RAN 1.0
5.1.2 RSRQ triggered mobility

Unique ID: 1198
Short Description:
Inter-frequency and inter-RAT mobility based on RSRQ triggers.
The RSRQ measurement trigger allows to better cope with high inter-cell interference scenarios,
e.g. due to missing neighbor cell relations or tight site re-use scheme in re-farming scenarios.
The Flexi Multiradio BTS supports beside the A2 RSRP trigger a parallel A2 RSRQ trigger in
order to start inter-frequency and IRAT measurements.
The termination of the inter-frequency and the inter-RAT measurements is extended in such a
way that the RSRP triggered A1 measurement report contains also a RSRQ measurement
which is compared with an operator configurable threshold. The report amount for the A1 event
is set to infinity.
The related inter-frequency or IRAT measurement events (e.g. A3, A5 or B2) remain
unchanged.
The functionality can be enabled / disabled per eNode B by O and M settings.
Interdependencies between Features: The releated inter-frequency or inter-RAT mobility

features to need be enabled, e.g.
LTE55 LTE56 LTE872 LTE1060 LTE60 LTE442 LTE873 LTE898

Indoor
Release RL45TD TD- TD- NetAct8 - - 3GPP R8
LBTS4.0 LBTS4.0 EP1 UE
capabilities
07.07.2014 28/95

LTE RAN 1.0
Element
5.1.3 Inter-frequency load balancing extension

Unique ID: 1531
Short Description:
The scope of UEs considered for load balancing is increased.
The number of UEs considered for load balancing is increased which leads to a higher
likelihood for off-loading a cell.
The feature introduces the following two extensions for LTE1387 and/or LTE1170:
A periodic retry of load balancing for RRC connected users is applied in case that
the load balancing handover was not successful,
the load balancing handover preparation was not successful or
the UE has not provided a A4 measurement report.
The retries are performed as long as the source cell is at high load. The retry timer is operator
configurable.
UEs enter a cell via a handover are considered as well for inter-frequency load balancing.
Interdependencies between Features: The feature is enabled together with LTE1387 or

LTE1170.

Indoor
LBTS4.0 LBTS4.0 EP1 mandatory
Element
07.07.2014 29/95

LTE RAN 1.0
5.1.4 Multiple Frequency Band Indicator

Unique ID: 1534
Short Description:
Intra-LTE MFBI functionality is introduced.

The functionality allows to handle UEs with overlapping bands in one network.
The Flexi Multiradio BTS supports Multiple Frequency Band Indicators (MFBIs) for UEs in RRC
IDLE and UEs in RRC CONNECTED. The MFBI functionality is supported
for homogenous network deployments, i.e. the same MFBI configuration is applied to all eNode
Bs.
All MFBI related parameters are configured via O and M.
MFBI support for UE in RRC IDLE
The following SIBs are supported for the MFBI:

SIB 1,
SIB 2 and
SIB 5.
One band can be configured for the different multiBandInfo list information elements.
MFBI support for UEs in RRC CONNECTED
UEs supporting MFBI and an overlapping RF band in the RF parameter information element of
the UE capabilities are considered for the following functions (if enabled)
RRC connected mobility (inter-frequency handover, RRC connection release with
redirect and RRC connection release with dedicated priorities)
ANR (intra-frequency ANR, inter-frequency ANR)
Carrier Aggregation
The eNode B uses in the above cases the EARFCN which matches to the UE capabilities.
The functionality can be enabled / disabled per eNode B by O and M settings.

07.07.2014 30/95

LTE RAN 1.0
Indoor
capabilities
Element
5.1.5 Idle mode mobility balancing extensions

Unique ID: 1677
Short Description:
A weighted round robin scheme is introduced for the idle mode mobility balancing target
selection.

A multi-frequency balancing scheme for RRC IDLE UEs is introduced.
The Flexi Multiradio BTS supports for the default and the mobility profiles the following
extensions for LTE487:
A weighted round robin scheme to select the target layer to which a UE shall be released with
dedicated cell re-selection priorities is replacing the LTE487 scheme. The ratio of UEs for which
the IDLE load balancing is applied is controlled by O and M settings.
A weighting factor is introduced for each configured intra LTE and inter-RAT cell re-selection
target.
The eNode B sends all transmitted SIBs with the RRC: RRC Connection Release message. The
highest priority is automatically assigned to the target frequency. The hierarchy of all other cell
re-selection priorities is maintained.
The functionality is enabled together with LTE487.
Interdependencies between Features: The feature is enabled together with LTE487 Idle
mode mobility load balancing.
Mobility profiles can be used only if LTE490 Subscriber profile based mobility has been enabled.

07.07.2014 31/95

LTE RAN 1.0

Indoor
capabilities
Element
5.1.6 Serving PLMN ID change during X2 based handover

Unique ID: 1731
Short Description:
Change of the serving PLMN ID during X2 handover.

Inter PLMN mobility with HRL in X2 handover
The Flexi Multiradio BTS supports following Handover Restriction List (HRL) functionalities in X2
handover.
if HRL was available in eNodeB during X2 handover, the eNodeB shall determine if a target cell
allowed for handover or not with HRL information, which contains the serving PLMN, equivalent
PLMNs, and roaming area or access restrictions.
In case of the UE serving PLMN ID is not supported in the selected target cell of the handover,
source eNodeB shall exchange the 'serving PLMN' in the Handover Restriction List IE with the
PLMN ID from the 'equivalent PLMNs' list which is supported in the target cell, before including
it into the X2AP: HANDOVER REQUEST message.
If the target eNodeB receives a HANDOVER REQUEST message containing the Handover
Restriction List IE, target eNodeB selects the IE "serving PLMN" within the Handover Restriction
List as the UE serving PLMN ID.
If the UE serving PLMN ID is supported by the target cell the handover continues. If the UE
serving PLMN ID is not supported by the target cell, the eNodeB rejects the procedure using the
HANDOVER PREPARATION FAILURE message.
A Handover Restriction List is stored in eNodeB when it is included in initially received or
updated messages of S1AP INITIAL CONTEXT SETUP, S1AP NAS DOWNLINK
TRANSPORT, S1AP HANDOVER REQUESTor X2AP HANDOVER REQUEST of a previous
07.07.2014 32/95

LTE RAN 1.0
handover. If the eNB receives the Handover Restriction List, it shall overwrite previously
received HRL information.
eNodeB shall not change serving PLMN ID during X2 handover if no HRL was available.
Interdependencies between Features: Related X2 mobility functionality needs to be enabled,

e.g.
LTE53, LTE55 or LTE1060.

Indoor
Release RL45TD TD- TD- x - - 3GPP R8
LBTS4.0 LBTS4.0 mandatory
Element
BSW -
5.1.7 Extended inter-frequency measurements

Unique ID: 2008
Short Description:
Extended inter-frequency measurement support

The number os supported inter-frequency layers for cell re-selection and inter-frequency
measurements for handover is expanded.
The following extensions are introduced for the Flexi Multiradio BTS:
Up to 8 inter-frequency layers (combination of FDD and TDD) can be broadcasted with SIB5 for
cell re-selection.
Up to 6 inter-frequency measurements (combination of FDD and TDD) can be configured per
UE depending on the configured inter-frequency bands.

07.07.2014 33/95

LTE RAN 1.0
Interdependencies between Features: The feature is enabled together with LTE55.
LTE1060 needs to be enabled for FDD-TDD handover support.

Indoor
Release RL45TD TD- TD- x - - 3GPP R8
LBTS4.0 LBTS4.0 UE
capabilities
Element
BSW -
5.1.8 RAN Information Management for GSM

Unique ID: 498
Short Description:
RAN information management (RIM) allows to transfer information between the source and
target cell via the core network. This mechansm allows for a reduction of parameter setting.

The operator needs to configure less parameters for the network assisted cell change or the
RRC connection release with redirect and SIB.
The Flexi Multiradio BTS supports the RAN information management (RIM) for NACC to GSM.
The eNode B acts always as a controller.
The RIM function enables the eNode B to retrieve system information from a target GSM cell:
if a PBCCH is allocated in the cell, PSI1, PSI2, PSI14
if no PBCCH is allocated in the cell, SI1, SI3, SI13
The RIM protocol is encapsulated in the S1AP.MME DIRECT INFORMATION TRANSFER and
the S1AP:ENB DIRECT INFORMATION TRANSFER messages.
The retrieved information is used to automatically fill and update the related SIB attributes for
the features:
eNACC to GSM or
RRC Connection Release with redirect and SIB.
The following RIM procedures are supported:
07.07.2014 34/95

LTE RAN 1.0
RAN Information Request/Multiple Report procedure

RAN Information Request/Stop procedure
RAN Information Send procedure
RAN Information Application Error procedure
RAN Information Error procedure
The functionality can be enabled / disabled per eNode B by O and M setting.
Interdependencies between Features: The feature
LTE42 DRX in RRC Connected Mode or LTE984 GSM Redirect with System Infoneeds to be
enabled.
Dependency to other RATs:GSM

Indoor
Release RL45TD TD- TD- NetAct8 x - 3GPP R8
capabilities
Element
5.1.9 Intra cell handover

Unique ID: 511
Short Description:
The eNode B performs a handover to the serving cell.
The Flexi Multiradio BTS supports intra cell handover.

The intra cell handover is triggered on UE basis in order to
refresh security keys triggered by S1AP: UE CONTEXT MODIFICATION REQUEST
with Security Key IE or UE Security Capabilies IE (e.g. after IRAT handover)
refresh of security keys triggered by eNB itself to avoid a cypherstream re-usage,
caused for example by
o triggered by low amount of remaining "unused" radio bearer IDs
07.07.2014 35/95

LTE RAN 1.0
o triggered by a approaching wrap-around of a PDCP COUNT value

synchronize selected RRC procedures between the UE and the eNode B
The above mentioned security use cases are supported by this feature including its application.
The synchronization use case is supported only in combination with the related feature (e.g. TTI
bundling).
Intra cell handovers are not checked against admission control thresholds.
eNode B triggered and RRC triggered intra cell handovers are not performed during
ongoing handovers and
UE gap measurements.
The following performance management counters are supported per cell, e.g.:
number of intra cell handover attempts
number of successful intra cell handovers
number of failed intra cell handovers

Indoor
Release RL45TD TD- TD- - - - 3GPP R8
Element
BSW -
5.1.10 Inter RAT handover from UTRAN

Unique ID: 57
Short Description:
Active mode mobility from UTRAN to LTE

The end user may experience better service quality, e.g. peak rates and latency, in LTE as in
UTRAN.
The Flexi Multiradio BTS supports incoming PS handovers from UTRAN to LTE.
The handover procedure is initiated by the RNC.
07.07.2014 36/95

LTE RAN 1.0
The Flexi Multiradio BTS gets during the handover preparation phase a S1AP:HANDOVER
REQUEST message from the MME.
The Flexi Multiradio BTS applies the same admission control thresholds for the handover
request as for other incoming mobility handovers, e.g. intra LTE handovers, and either
acknowledges or rejects the handover request.
The RNC issues after a successful handover preparation phase a handover command to the UE
with embedded RRCConnectionReconfiguration information.
The UE performs an access to LTE and finalizes the handover with a
RRC:RRCConnectionReconfigurationComplete message to the eNode B.
The Flexi Multiradio BTS sends afterwards a S1AP:HandoverNotify message to the MME.
The handover is performed without data forwarding.
The MME may trigger after a successful handover a security key update via the
S1AP:ContextModificationRequest message. The eNode B performs the security key update via
an intra-cell handover.
The feature can be enabled/disabled per BTS by O AND M settings.

Indoor
Release RL45TD TD- TD- NetAct8 x x 3GPP R8
capabilities
Element
5.1.11 Inter RAT handover to eHRPD/3GPP2

Unique ID: 60
Short Description:
Coverage based prepared inter RAT handover from LTE to CDMA2000 eHRPD

Reduced service interuption time
07.07.2014 37/95

LTE RAN 1.0
The LTE to eHRPD optimized handover functionality of the Flexi Multiradio BTS allows for a
service continuity of data services with minimal interruption time when changing from a LTE cell
to a CDMA2000 eHRPD cell.
The functionality is only applicable for multimode devices supporting both LTE and CDMA2000
eHRPD for the according frequency band and the according feature support.
Pre-registration
The UE initiates the pre-registration to the CDMA2000 eHRPD Access.
The eNode B provides up to three operator configurable Zone ID for the pre-registration either in
SIB8 for RRC Idle UEs or in the measurement configuration IE for RRC Connected UEs. The
three Zone IDs (Primary Zone ID and two Secondary Zone IDs) are operator configurable per
cell. The same Zone IDs are applied for SIB 8 and the measurement configuration. However
different preRegistrationAllowed flags can be configured for SIB8 and the measurement
configuration.
The eNode B supports the following messages for the pre-registration:
the RRC:ULInformationTranfer message and
the RRC:DLInformationTransfer message are supported between the UE and the eNode
B.
the S1AP:DownlinkS1CDMA2000Tunneling message and
the S1AP:UplinkS1CDMA2000Tunneling are supported between the eNode B and the
MME.
The eNode B adds during the pre-registration procedure a CDMA2000 Sector ID to the
S1AP:UplinkS1CDMA2000Tunneling message.
The sector ID for the pre-registration is selected with a weighted round robin mechanism out of
an operator configurable pool of sector IDs.
Handover trigger
The handover is a network controlled handover with support of the UE.
The following measurement events are used:
A1 - deactivate IRAT/IF measurements (RSRP)
A2 - activate IRAT eHRPD measurements (RSRP)
B2 - IRAT eHRPD measurements
The operator configurable measurements events A2 and A1 are used to start and stop IRAT
measurements.
The UE capabilities are considered for the IRAT measurements, e.g. UE support of
measurement gaps and UE support of the target cell frequency band. The measurement gap
gp0 is used.
The target cells for the IRAT measurements are operator configurable. The operator can select
whether cells shall be considered for IRAT measurement or not. A target cell load balancing
between different frequency layers is applied for the initial target frequency considering operator
configurable weights. The selection valid as long as the UE is RRC CONNECTED in the same
cell.
The B2 measurement configuration of the source cell thresholds (RSRP), target cell threshold
(pilotStrength), hysteresis (specific to eHRPD), time to trigger (specific to eHRPD) and speed
dependent scaling are operator configurable on a per eHRPD carrier basis.
Handover
The Flexi Multiradio BTS initiates the optimized eHRPD handover after receiving a B2
measurement report from the UE.
07.07.2014 38/95

LTE RAN 1.0
Upon receiving a B2 measurment report, the eNode B takes the first target cell indicated by the
UE measurements for the handover to eHRPD.
The handover comprise of the following steps:
A RRC:HandoverFromEUTRAPreparationRequest message is send to the selected UE.
The content of the response message from the UE
(RRC:ULHandoverPreparationTransfer) is forwarded with the
S1AP:UplinkS1CDMA2000Tunneling message via the MME to the CDMA2000 HRPD
Access. The CDMA2000 Sector ID is set to the first target indicatedby the UE
measurement report. The S1AP:UplinkS1CDMA2000Tunneling message also contains
the EUtran Round Trip Delay Estimation IE.
The CDMA200 HRPD Access provides the respones via the
S1AP:DownlinkS1CDMA2000Tunneling message.
The eNode B sends in case of a positve handover preparation response a
RRC:MobilityFromEUTRA message to the UE. The UE leaves LTE and starts to
establish a traffic channel to CDMA2000 HRPD Access.
The eNode B recieves in case of a successful handover a
S1AP:UEContextReleaseCommand message.
A non optimized handover to eHRPD is performed in case that the UE does not support an
optimized handover to eHRPD.
The Flexi Multiradio BTS supports the following counters per cell in order to track the
performance:
Inter System Handover preparations
Failed Inter System Handover preparations per cause
Inter System Handover attempts
Successful Inter System Handover completions
Failed Inter System Handover per cause
Number of B2 measurement configurations
Number of received B2 measurement reports
The handover functionality can be enabled or disabled per eNode B by O and M settings.
HW Requirements: Future study item for FSMD/FSME
Interdependencies between Features: The feature requires the support of GPS time retrieval.
LTE426 System time broadcast for SIB8 and LTE870 Idle mode mobility from LTE to
CDMA/eHRPD needs to be enabled
WCDMA and GSM mobility can not be enabled in parallel with this functionality (LTE56,
LTE872, LTE873, LTE442, LTE736).
Mobility profiles LTE490 are not supported for this feature.
Dependency to other RATs:CDMA

07.07.2014 39/95

LTE RAN 1.0
Indoor
Release RL45TD TD- TD- NetAct8 x x 3GPP R8
capabilities
Element
5.1.12 SRVCC to WCDMA

Unique ID: 872
Short Description:
Service continuity for VoIP

Seamless handover for voice services to WCDMA when leaving the LTE coverage
The LTE to WCDMA Single Radio Voice Call Continuity (SRVCC) functionality of the Flexi
Multiradio BTS allows for a service continuity of voice services to the CS domain when changing
from an LTE cell to a WCDMA cell. All non-voice services will be handed over to the PS domain.
The functionality is only applicable for SRVCC capable multimode devices supporting both LTE
and WCDMA at the corresponding frequency band. The SRVCC capability of the UE and the
MME is indicated by the MME with the S1AP:INITIAL CONTEXT SETUP REQUEST message.
A target eNB is informed in case of a handover either via the S1AP:HANDOVER REQUEST
message by the MME or via the X2AP:HANDOVER REQUEST message by the source eNB.
The handover procedure itself is identical to the LTE to WCDMA handover, i.e. the same
neighbor cells list, measurements and thresholds are used.
The eNB indicates the MME with the S1AP:HANDOVER REQUIRED message that SRVCC
should be initiated.
The eNB will trigger SRVCC only if the UE has an EPS bearer with QCI=1 established and the
MME and UE are SRVCC capable.
07.07.2014 40/95

LTE RAN 1.0
Performance counters are provided per cell in order to track the SRVCC performance, e.g.
Attempted Inter System HO to WCDMA with SRVCC

Successful Inter System HO to WCDMA with SRVCC
Total number of Inter System HO to WCDMA with SRVCC failures per cause
Total number of Inter System HO to WCDMA with SRVCC drops per cause
The SRVCC functionality can be enabled / disabled per cell via O&M
Interdependencies between Features: the following features must be enabled: Support of

GBR EPS bearers (LTE 10) Support of multiple EPS bearers (LTE 7) Inter RAT handover to
WCDMA (LTE 56)

Indoor
Release RL45TD TD- TD- OSS5.4 x x 3GPP R8
capabilities
Element
5.1.13 SRVCC to GSM

Unique ID: 873
Short Description:
Service continuity for VoIP

Seamless handover for voice services to GSM when leaving the LTE coverage
07.07.2014 41/95

LTE RAN 1.0
The LTE to GSM Single Radio Voice Call Continuity (SRVCC) handover functionality of the
Flexi Multiradio BTS allows for a service continuity of voice services to the CS domain when
changing from an LTE cell to a GSM cell.
The SRVCC functionality does not support DTM/PSHO, i.e. established non-voice bearers are
not handed over to GSM. An operator configurable switch is supported which determines
whether to suspend the data session or not.
The functionality is only applicable for SRVCC capable multimode devices supporting both LTE
and GSM at the according frequency band. The SRVCC capability of the UE and the MME is
indicated by the MME with the S1AP:INITIAL CONTEXT SETUP REQUEST message. A target
eNB is informed in case of a handover either via the S1AP:HANDOVER REQUEST message by
the MME or via the X2AP:HANDOVER REQUEST message by the source eNB.
Handover trigger
The SRVCC is a network controlled handover with support of the UE.
The following measurement events are used:
A1 - deactivate IRAT measurements

A2 - activate IRAT measurements
B2 - IRAT measurements
The measurements events A2 and A1 are used to start and stop IRAT measurements and can
be configured by the operator.
The eNB will trigger IRAT measurements only if the UE has a EPS bearer with QCI=1
established and the MME and UE are SRVCC capable.
The UE capabilities are considered for the setup of the IRAT measurement configuration, e.g.
support of measurement gap and support of frequency bands.
07.07.2014 42/95

LTE RAN 1.0
The target cells for the IRAT measurements can be configured by the operator. Blacklisting of
target cells is supported as well.
The event B2 is used for the IRAT measurements.
The measurement configuration such as source cell thresholds (RSRP), target cell thresholds
(RSSI), hysteresis, time to trigger and speed dependent scaling can be configured by the
operator.
Handover preparation
The Flexi Multiradio BTS initiates a handover after receiving a measurement report form the UE
by sending a S1AP:HANDOVER REQUIRED message with a SRVCC HO indication to the
MME.
The Flexi Multimode BTS takes the first target cell indicated by the UE measurements for the
handover.
Handover execution
The MME responds to this with a S1AP:HANDOVER COMMAND message indicating that the
resources at the target have been reserved.
The Flexi Multiradio BTS sends after receiption of this message a

RRC:MobilityfromEUTRAcommand message to the UE, which forces the UE to a GSM cell.
Performance counter
Performance counters are provided per cell in order to track the SRVCC performance, e.g.
Attempted Inter System HO to GSM with SRVCC

Successful Inter System HO to GSM with SRVCC
Total number of Inter System HO to GSM with SRVCC failures per cause
07.07.2014 43/95

LTE RAN 1.0
Total number of Inter System HO to GSM with SRVCC drops per cause
The SRVCC functionality can be enabled/disabled per cell via O&M
Interdependencies between Features: the following features must be enabled: Support of

GBR EPS bearers (LTE 10) Support of multiple EPS bearers (LTE 7)

Indoor
Release RL45TD TD- TD- OSS5.4 x x 3GPP R8
capabilities
Element
5.1.14 CSFB to CDMA/1xRTT for dual RX UEs

Unique ID: 874
Short Description:
Service continuity for CS voice.

Redirected call setup for voice calls
The Flexi Multiradio BTS supports a RRC release based Circuit Switched Fallback (CSFB) to
CDMA/1xRTT for dual receiver multimode UEs and for single radio UEs emulating dual receiver
mode. UE stays attached to CDMA/1xRTT network to perform idle mode mobility procedures
and to listen paging also while being in RRC connected to LTE network. When voice call is
initiated or received on CDMA/1xRTT system by the UE, eNodeB will release the RRC
connection to allow voice call setup on CDMA.
The following scenarios are supported:
-Mobile originated CSFB with a Initial context setup (UE in IDLE prior to CSFB)
07.07.2014 44/95

LTE RAN 1.0
-Mobile originated CSFB with a UE context modification (UE in RRC Connected prior to CSFB)
-Mobile terminated CSFB with a Initial context setup (UE in IDLE prior to CSFB)
-Mobile terminated CSFB with a UE context modification (UE in RRC Connected prior to CSFB)
The MME triggers in all cases the CSFB procedure at the eNode B by sending the IE CSFB with
the S1AP:UE Context Modification Request (RRC connected cases) or Initial context setup
request (RRC idle cases) message to the eNode B.
The eNode B performs upon the CSFB trigger a RRC connection release without redirect
information for UEs.
There is no need for redirect information or measurements as the UE is already attached to
CDMA/1xRTT. Towards MME, eNodeB will send S1AP: UE context release request with cause
value "Redirection towards 1xRTT" (terminal still gets a RRC release without actual redirection).
The eNode B indicates with the SIB 8 the capability to support dual receiver UEs.
The following existing counters related to CSFB will be incremented
UE Context modification attempts due to CS Fallback (M8000C31)
UE Context modification attempts (M8000C23)
UE Context modification failures (M8000C25)
CS Fallback attempt via RRC Connection Release(M8016C11)
CS Fallback attempt via RRC Connection release (UE in connected mode)( M8016C12)
CS Fallback via RRC Connection Release for Emergency sessions(M8016C13)
The operator can enable / disable the LTE874 functionality per eNodeB by O&M setting.
Interdependencies between Features: LTE1441 eCSFB can be enabled simultaneously in the

same cell as LTE874 (this feature).
CSFB to WCDMA/GSM/TDSCDMA is not supported simultaneously with LTE874.
When used together with LTE116 / LTE117 (1.4/3 MHz LTE bandwidth), only SIB8 elements
mandatory for this feature are broadcast.

Indoor
capabilities
Element
07.07.2014 45/95

LTE RAN 1.0
5.2 LTE:Coverage, capacity and peak rates

5.2.1 Interference aware UL power control
Unique ID: 1336
Short Description:
Improved uplink cell capacity and cell edge performance through interference aware closed loop
uplink power control.

A higher uplink cell capacity and improved cell edge throughput can be used for providing
additional services and better service coverage.
The Flexi Multiradio BTS supports an interference aware uplink power control algorithm for
PUSCH.
The eNode B controls the UE specific transmit power such that the tradeoff between the
throughput achieved in the own cell and the uplink interference injected to neighbor cells is
optimized. The eNode B uses UE as well as eNode B measurements as input for the algorithm.
The functionality can be enabled or disabled per cell by O and M setting.
Interdependencies between Features: LTE28 Closed loop UL power control needs to be

enabled for SRS and PUCCH power control. The feature replaces the PUSCH power control.

Indoor
Element
07.07.2014 46/95

LTE RAN 1.0
5.2.2 Uplink Intra-eNB CoMP

Unique ID: 1402
Short Description:
The uplink intra eNode B CoMP (Co-ordinated Multipoint) functionality improves the cell
capacity and the cell edge performance by taking uplink information from neighbor cells into
account.
The uplink intra eNode B CoMP provides up to 50% cell edge improvement compared to a 2RX
receiver.
The Flexi Multiradio BTS supports uplink intra eNode B CoMP. The uplink intra eNode B CoMP
functionality is applied for cells with 2RX paths. The eNode B selects automatically per UE and
per TTI the most suitable neighbor cell out of the CoMP candidate set. The selection of the
neighbor cell for the joint reception is based on uplink SINR measurement before combining.
The joint reception is applied for the PUSCH. The CoMP candidate set, i.e. which neighbor cell
shall be considered for the selection, is operator configurable.
The feature can be enabled or disabled per eNode B by O&M setting.
HW Requirements: Not supported on FSMD/FSME
Interdependencies between Features: LTE979 IRC for 2 RX paths (FDD) or LTE936 IRC for
2 RX paths (TDD)needs to be enabled. The feature is supported in combination with LTE614
Distributed sites under the assumption that the distance between RF module is smaller than 1
km.
The feature is not supported in combination with
LTE48 High speed users, LTE117 1.4 MHz, LTE116 3 MHz, LTE72 4-way RX diversity,
LTE980 IRC for 4 RX paths, LTE993 TDD Supercell and LTE1542 FDD Supercell.

Indoor
07.07.2014 47/95

LTE RAN 1.0
Element
5.2.3 8x2 SU MIMO with TM9

Unique ID: 1543
Short Description:
The Flexi Multiradio BTS support transmission mode 9 of Rel-10 with 8 port CSI-RS configured,
and support up to 2 layers per UE.

This feature can provide more accurate channel feedback based on 8 port CSI-RS and relax the
strict requirement of sounding, compared with TM7/8. The additional overhead of CSI-RS is
very low.
The Flexi Multiradio BTS supports a 8 port CSI-RS transmission mode 9 SU-MIMO with up to 2
layers per UE.
The adaptive close loop MIMO is applied for UE category 2 and higher.
The Flexi Multiradio BTS provides an automatic switch between:

2 Tx Tx-Divertity based on 2 CRS ports
single codeword, single layer transmission with single DM-RS
port, port 7 or 8.
dual codeword, dual layer transmission with dual DM-RS port,
port 7 and port 8.
During initial access phase, TM2 is used as default transmission mode. Then if cell specific
parameter of transmission mode is set to TM9, then Rel-10 UE will work in transmission mode9;
legacy UE will work in transmission mode 8 if UE capability is supported, else will work in TM7.
Two PMI parameter configuration sets are supported, one is for wideband and long-
term feedback another for the narrowband and short-term feedback.
A pre-configured set of 8 port CSI-RS resource allocations is supported.
The 2 port CRS based TX diversity, SFBC(Space-Frequency Block Code) is applied for
PDCCH, PCFICH, PHICH and PBCH as well for PDSCH for class 1 UEs.
Precoding vector switching is applied for the primary synchronization channel (PSS) and the
secondary synchronization channel (SSS).
The following existing performance counter is applied for this functionality:

MIMO mode time distribution(single code word / dual code word)
07.07.2014 48/95

LTE RAN 1.0
The performance of this feature is shown within the following figures:
The functionality can be enabled / disabled per cell by O&M settings.
HW Requirements: Flexi Multiradio 10 (FSMF) and FSIH
This feature is supported only in combination with 8Rx/8Tx RFMs
Interdependencies between Features: LTE541 (dual stream beamforming) needs to be

enabled.
LTE493 8 RX diversity or LTE 936 8 Rx IRC needs to be enabled.

Indoor
07.07.2014 49/95

LTE RAN 1.0
3GPP R10
UE
capabilities
Element
5.2.4 TDD Downlink carrier aggregation

Unique ID: 1558
Short Description:
Extend downlink bandwidth up to 40MHz with two component carriers

provide higher peak data rates for UEs and increase average UE downlink throughput at
unloaded networks
The Flexi Multiradio BTS supports intra-band carrier aggregation in downlink for two component
carriers. A mix of non carrier aggregation UEs and carrier aggregation UEs is supported in
downlink. The maximum aggregated downlink bandwidth is 40 MHz and uplink is only on PCell.
The supported band combinations for the deployment scenario 1 described by 3GPP TS 36.300
are:
* band38 + band38
* band40 + band40
* band41 + band41
The supported cell bandwidth combinations are:

* 20Mhz + 20Mhz
The downlink carrier aggregation is applied for UEs with the related UE capabilities. Non-GBR
DRBs can be served on both cells. GBR DRB(s), Voice DRB and SRBs are served on the PCell
only.
The following functional extensions are introduced for the downlink carrier aggregation:
Radio Admission control
UEs are admitted based on the primary cell (Pcell) and Secondary cell (Scell) admission control
settings. The same thresholds as for non carrier aggregation capable UEs are applied.
Mobility
The following mobility scenarios are supported:
* handover of UEs with carrier aggregation activated to carrier aggregation enabled cells,
07.07.2014 50/95

LTE RAN 1.0
* handover from a non carrier aggregation enabled cells to carrier aggregation enabled cells and
* handover of UEs with carrier aggregation activated to non carrier aggregation enabled cells.
The mobility for carrier aggregation configured UEs is based on Pcell measurements. The same
measurements configurations as for non CA configured UEs are applied, e.g. A3 and/or A5.
Secondary cell (Scell) handling

The Scell is configured blindly with a RRC:RRCConnectionReconfiguration message once the
UE capabilities are known to the eNode B. The SCell activation can be triggered either blindly or
depending on the non-GBR data in buffer. The Scell is deactivated in case that the MAC timer
expires.
Barred cell can be used as Scell for UE which have already configured the Scell. New Scell
configurations are not allowed for barred cells.
Scheduling
UEs with an activated Scell are scheduled by separate and coordinated downlink schedulers.
The fairness between carrier aggregation UEs and non carrier aggregation UEs can be
controlled by an operator configurable parameter. The DRX handling as well as the
measurement gap handling is synchronized between the two downlink schedulers. The
combined downlink throughput is used for the proportional fair scheduling and UE AMBR
control.
PUCCH
The PUCCH resource allocation for CQI, SR and HARQ-ACK is adapted in order to handle two
downlink component carriers.
Performance Counters
The following additional performance counters are supported per cell:
* average number of DL carrier aggregation capable UEs
* average number of UEs with a configured Scell
* average number of UEs with an activated Scell
* number of Scell configuration attempts
* number of successful Scell configurations
* Pcell RLC data volume in DL via Scell
The functionality can be enabled / disabled per eNode B by O&M setting.
HW Requirements: Carrier aggregation requires that the eNode B is configured with a

sufficient number of cells.
Interdependencies between Features: LTE496 (Support of QCI 2,3 and 4) feature needs to
be enabled.
The interworking with the following features is excluded:
* LTE993:Cell Combination (Super cell)
* LTE493:Single stream beamforming(TM7)

07.07.2014 51/95

LTE RAN 1.0
* LTE1543:8x2 SU MIMO with TM9

Indoor
LBTS4.0 LBTS4.0 UE
capabilities
Element
5.2.5 64 QAM in UL
Unique ID: 44
Short Description:
Increase of the uplink peak rate by up to
70% compared to MCS20 rsp.
40% compared to MCS24.

Higher uplink peak rates can be offered to customers.
The Flexi Multiradio BTS supports with this feature 64 QAM modulation in uplink for UEs with
concerning UE capabilities (e.g. CAT5, CAT8)
The supported MCS (modulation and coding scheme) range is extended up to MCS 28.
The MCS related performance counters are extended for the additional MCS.
The feature can be enabled / disabled per cell by O&M setting.
Interdependencies between Features: LTE788 needs to be enabled.

Indoor
07.07.2014 52/95

LTE RAN 1.0
LBTS4.0 LBTS4.0 UE
capabilities
Element
5.3 LTE:QoS, services and end user experience

5.3.1 Multimedia priority services
Unique ID: 1074
Short Description:
Priority controlled admission and paging priority handling.

Access prioritisation for emergency calls and high priority users
The Flexi Multiradio BTS supports admission control for high priority calls and paging
prioritization. The paging priority handling considers the paging priority provided by the
S1AP:paging message. UEs with a higher paging priority are preferred over UEs with a lower
priority for the assignment of paging resources. A subsequent RRC connection request from an
UE which has been paged with a paging priority is admitted like an emergency RRC connection
request. High priority access UEs are identified either by the RRC connection establishment
cause value 'High Priority Access' or by a dedicated operator configurable high priority ARP
value range associated to a data radio bearer. High priority calls are treated as emergency calls
during admission control in serving cell and in target cell. They are treated as normal calls at
handover target selection.
The following PM counters are supported per cell, e.g.:
Number of signalling connection establishment attempts for high priority calls
Signalling connection establishment completions for high priority calls
E-RAB setup requests for high priority calls
E-RAB setup completions for high priority calls
The functionality can be enabled / disabled per eNode B with its subordinated cells by O AND M
setting.
Interdependencies between Features: The following features need to be enabled:

07.07.2014 53/95

LTE RAN 1.0
LTE572 IMS Emergency Session
LTE534 ARP based Admission Control
LTE496 Support of QCI 2,3,4
LTE497 Smart Admission Control

Indoor
Element
5.3.2 Operator-specific GBR QCIs

Unique ID: 1231
Short Description:
The operator can define its own QoS profiles for GRB EPS bearers.

The operator-specific QCIs allow for better user and service differentiation of GBR services.
Up to 21 operator-specifc QCIs for GBR EPS bearers are supported per eNB.
The QCI value for each QCI is operator-configurable in the range from 128 to 254.
Each operator-specific QCI is defined by at least the following set of parameters:
QCI value
RLC profile
PDCP profile
DRX profile (DRX functionality needs to be enabled)
Delay target
Priority
logical channel group ID
07.07.2014 54/95

LTE RAN 1.0
DSCP
scheduling priority
BSD (bucket size duration)
TTI bundling enforcement (TTI bundling needs to be enabled)
The PM counter groups for non GBR QCIs are applied as well to operator-specific GBR QCIs.
Operator-specific GBR bearers are treated by admission control as standard GBR bearers.
Robust header compression is not applied for operator specific GBR QCIs.
The support of operator-pecific GBR QCIs can be enabled/disabled per eNB by O AND M
settings.
Interdependencies between Features: The following features need to be enabled: LTE496

Support of QCI 2, 3 and 4 LTE497 Smart admission control LTE534 ARP based admission
control for E-RABs

Indoor
Element
5.3.3 Cell resource groups

Unique ID: 1382
Short Description:
The cell resource groups allow to virtually split the cell resources.

The operator is able to pre-define resource shares in case of MOCN or national roaming.
The Flexi Multiradio BTS provides a resource split control function for up to four resource
groups. A resource group can be assigned to a single or multiple PLMN IDs configured per cell
The total cell capacity is divided up according to an operator configurable share of the resource
groups with a 1% step size granularity, e.g. 30% - 40% - 30% in case of three resource groups.
07.07.2014 55/95

LTE RAN 1.0
The resource split can be configured on cell level. O AND M consistency check ensures a share
configuration to 100%. Not assigned PLMN-IDs will be mapped to a default CRG.
The resource group share is applied to

admission control thresholds (exception: RRC connection requests),
TTI assignments for PDSCH and PUSCH and
Congestion control for GBR traffic
The uplink resource split can be disabled via O AND M. The resource split affects the admitted
GBR rates. The pre-emption functionality at the radio admission control considers the resource
group, i.e. pre-emption is done within the resource group (LTE534 needs to be enabled).
Congestion handling is as well done per resource group. The resource shares are as well
applied for emergency sessions. Emergency sessions without a resource group assignment are
mapped to a default resource group. TTIs not used by a resource group are automatically
reused by other resource groups. Almost empty TTIs might be deferred in scheduling as long as
the timing constrains are met.
The following performance counters are provided in order to track the performance per resource
group, e.g.
number of used TTIs per direction and resource group,
number of available TTIs in UL and DL in total per measurement interval.
The functionality can be enabled / disabled per cell by O AND M setting.
Interdependencies between Features: The interworking with the following features is not
supported:
LTE1387 / LTE1170 - Inter-frequency load balancing LTE115 - Cell bandwidth - 5 MHz LTE116
- Cell bandwidth - 3 MHz LTE117 - Cell bandwidth - 1.4 MHz LTE616 - Usage based PDCCH
adaptation LTE907 - TTI bundling in combination with cell resource groups in uplink Asymmetric
TD LTE frame configurations with cell resource groups in uplinkThe following features needs to
be enabled:
LTE 496 Support of QCI 2,3 and 4 LTE 497 Smart admission control LTE 534 ARP based
admission control

Indoor
07.07.2014 56/95

LTE RAN 1.0
Element
5.3.4 LPPa support for OTDOA

Unique ID: 1433
Short Description:
The eNode B signals OTDOA related settings via the S1AP to the eSMLC.

The functions allows the eSMLC to automatically retrieve OTDOA related parameters from the
eNode B.
The Flexi Multiradio BTS supports the LPPa OTDOA information request procedure via the
S1AP.
The LPPa protocol is encapsulated in the S1AP:Downlink Non UE Associated LPPa Transport
rsp. S1AP:Uplink Non UE Associated LPPa Transport message.
The following LLPa messages are supported:
OTDOA Information Request

OTDOA Information Response

OTDOA Information Failure
The following OTDOA cell information elements are supported:
PCI

Cell ID

TAC

07.07.2014 57/95

LTE RAN 1.0
EARFCN

PRS Bandwidth

PRS Configuration Index

CP Length

Number of DL Frames

Number of Antenna Ports

SFN Initialization Time

EUTRAN Access Point Position (O AND M configured)

PRS Muting Configuration
The functionality can be enabled / disabled per eNode B by O AND M setting.
Interdependencies between Features: LTE495 OTDOA needs to be enabled.

Indoor
capabilities
Element
5.3.5 Multiple emergency areas per cell

Unique ID: 1755
07.07.2014 58/95

LTE RAN 1.0
Short Description:
Support of multiple emergency area IDs per cell.
The Flexi Multiradio BTS allows to configure up to 15 emergency area IDs per cell for CMAS or
ETWS. The emergency area IDs are used to check if emergency messages need to be
broadcasted in a cell.
The emergency area IDs can be different for different cells.
Interdependencies between Features: LTE843 or LTE494 needs to enabled.

Indoor
capabilities
Element
BSW -
5.3.6 Commercial Mobile Alert System

Unique ID: 494
Short Description:
CMAS is a solution to broadcast public warning messages.

The operator is able to a support public warning service.
The Flexi Multiradio BTS supports CMAS (Commercial Mobile Alert System).
07.07.2014 59/95

LTE RAN 1.0
The CMAS notifications are sent by the MME to the eNB via the S1AP:WRITE-REPLACE
WARNING REQUEST.
UEs in RRC IDLE and in RRC CONNECTED are informed via paging about the presence of
CMAS notifications.
The Flexi Multiradio BTS broadcasts the CMAS notifications via SIB12. A segmentation of
warning messages in consecutive SIB12s and the autonomous adaptation of the SIB1
Scheduling Info List are supported.
The Flexi Multiradio BTS is able handle the S1AP:WRITE-REPLACE WARNING REQUEST as
a new notification if the Concurrent Warning Message Indicator is present
The Flexi Multiradio BTS acknowledges a S1AP:WRITE-REPLACE WARNING REQUEST
message received from a second MME (i.e., a message with the same Message Identifier value
and Serial Number value has been received from a different MME and being notified).
The Flexi Multiradio BTS stops the broadcast
with the S1AP:KILL REQUEST message or

after sending the max number of required broadcasts.
The CMAS functionality can be enabled/disabled per eNB with its subordinated cells by O&M
setting.

Indoor
capabilities
Element
07.07.2014 60/95

LTE RAN 1.0
5.3.7 IMS emergency sessions

Unique ID: 572
Short Description:
Support of IMS emergency calls.

The operator can offer IMS emergency sessions for LTE.
Interdependencies between Features: LTE10 Support of EPS bearers for conversational

voice and LTE7 Support of multiple EPS bearer required.

Indoor
Release RL45TD TD- TD- - x x 3GPP R9
LBTS4.0 LBTS4.0 UE
capabilities
Element
5.3.8 Smart DRX

Unique ID: 585
Short Description:
Improved power saving for always on users

The feature allows for UE power saving for the duration of the UE short inactivity timer.
The Flexi Multiradio BTS introduces with this feature additional flexibility for the DRX handling in
RRC connected.
The short DRX cycle is introduced in addition to the long DRX cycle for UE with according UE
capabilities. The short DRX is used to collect additional UE reports for a reliable timing advance
07.07.2014 61/95

LTE RAN 1.0
(TA) estimation. This change allows for a more flexible configuration of the DRX Inactivity Timer
for long DRX cycles ( 160ms).
The feature can be enabled / disabled per cell by O&M setting.
Interdependencies between Features: The features LTE42 DRX in RRC connected mode and
LTE473 Extended DRX Settings must be enabled.

Indoor
Release RL45TD TD- TD- OSS5.4 - - 3GPP R8
capabilities
Element
5.3.9 ETWS broadcast

Unique ID: 843
Short Description:
The Flexi Multiradio BTS supports ETWS (Earthquake and Tsunami Warning System) by a
warning delivery procedure. Broadcast of primary and secondary notifications are supported.

To fulfill regulatory requirement on relevant markets.
The Flexi Multiradio BTS can be enabled via O&M for the ETWS support.
The Flexi Multiradio BTS executes in this case warning distribution under control of MME over
S1 AP (write-replace warning procedure).
The following use cases are supported:
Broadcast of primary notification as immediate warning about threat, like earthquake

and/or tsunami
Broadcast of secondary notifications for delivering additional information, like where to
get help
In case of S1-flex Flexi Multiradio BTS may receive each warning message item from
multiple MMEs
07.07.2014 62/95

LTE RAN 1.0
Stop delivery of notification

The primary notification is broadcasted as soon as possible to all camping and connected UEs
under the coverage of a eNB. The eNB executes repeated paging in all paging groups as
indication about primary notification. The primary notification is broadcasted in the system
information block (SIB) 10.
The secondary notification is broadcasted in segmented manner in SIB 11. The indication of the
secondary notification will be implemented according to 3GPP decision. The warning notification
may be updated. The eNB will broadcast only the newest notification based on message ID. In
case of S1-flex Flexi Multiradio BTS acknowledges also later delivery requests per message
item while requested by multiple MMEs.
The warning message is broadcasted in all cells under control of a Flexi Multiradio BTS when
the warning area ID is not given.
The warning delivery is prioritized in case of congestion.
The feature can be enabled/disabled per eNB and its subordinated cell by O&M settings.

Indoor
capabilities
Element
5.4 LTE:Supplementary RRM functions

5.4.1 Control plane overload handling
Unique ID: 1047
Short Description:
The eNode B provides a control plane overload detection mechanism and related counter
actions.

07.07.2014 63/95

LTE RAN 1.0
The eNode B ensures with this feature a high control plane throughput is achieved at a high
offered load.
The Flexi Multiradio BTS supports an overload handling for the control plane covering the UU,
X2 and S1 interface.
The control plane overload functionality on eNode B level comprises of
an overload management function and

a set of triggered overload actions on application level.
Control plane overload management
A control plane overload is detected by evaluating a certain overload level metrics (queue length
and/or queuing time and/or CPU load). The control plane load is characterised by three states
depending on the metrics:
overload level 0 (normal operation)

overload level 1 (for graceful overload handling)
overload level 2 (preserving stability, self-defense)
The overload detection mechanism allows to differentiate peak load scenario from sustained
traffic increase. The overload management function realizes overall the load control loop(s)
including timeout/hysteresis values for the different load levels and the corresponding overload
actions (activation/deactivation).
Control plane overload counter actions
The eNode B performs the following counter actions in case of overload level 1:
Reject of low priority RRC connection requests(Establishment Cause set to
'delayTolerantAccess', 'mo-data' or 'mo-signalling'
Rejection of incoming non emergency HO without GBR bearer in combination and HO
cause other than Time Critical Handover or Handover Desirable For Radio Reasons
The eNodeB performs the following counter actions in case of overload level 2:
Reject of low priority RRC connection requests as defined in overload level 1
Reject all non emergency HO
The following performance counters are provided to monitor the control plane overload
functionality for the affected cells, e.g.
time period of overload level 1

time period of overload level 2
number of rejected RRC connection requests due to overload handling
07.07.2014 64/95

LTE RAN 1.0
The functionality can be enabled / disabled per eNode B with its subordinated cells by O AND M
setting.
Interdependencies between Features: LTE534 ARP based admission control for E-RABs
needs to be enabled

Indoor
Element
5.5 LTE:Basic LTE call handling and interworking

5.5.1 S1 Overload Handling
Unique ID: 440
Short Description:
Support of S1 overload message from the MME

Stable operation in case of MME overload
The Flexi Multiradio BTS supports S1 overload handling.

The MME can indicate to the Flexi Multiradio BTS an overload situation by sending S1
messages:
S1AP:OVERLOAD START
S1AP:OVERLOAD STOP
The Flexi Multiradio BTS performs the following actions during the overload period depending
on the MME configuration:
Single MME configuration
reject RRC connection requests except emergency RRC connections
07.07.2014 65/95

LTE RAN 1.0
reject all connection requests for signaling

MMEs in pool or RAN sharing configuration (if enabled)
admit all RRC connections in order to identify the target MME
reject UEs from overloaded MME except emergency calls
assign new UEs to not overloaded MMEs
UEs performing handovers within the MME area are not affected by the overload handling.
The overload functionality can be enabled/disabled via O&M.
Interdependencies between Features: related features: LTE 4 - RAN sharing for two
operators LTE 2 - S1 Flex

Indoor
LBTS4.0 LBTS4.0 CD2 mandatory
Element
BSW -
6 Operability
6.1 Network Monitoring and Maintenance
6.1.1 BTS Diagnostics Toolkit used by operator
Unique ID: 1909
Short Description:
The BTS Diagnostics Toolkit is supporting operator and technical support and NSN
development with efficient data collection from eNB. The data set, as e.g. trace data, BTS
snapshot data, .. is send from operator to NSN with tool support. It will allow resolving an error
at first occurrence as all necessary information is available for detailed analysis. The toolkit is
- Supervising the eNBs via cell tracing

07.07.2014 66/95

LTE RAN 1.0
- Triggering the BTS Snapshot creation in time based on trigger events in cell trace content
- Comes along with LTE SW
- Is easy to install and use

This feature will improve the trouble shooting situation with the "PRESS ONE BUTTON" support
for data collection. This leads to reduction of OPEX and time for error solving with a high
correction hit rate. Additionally the pressure is minimized
- to reproduce faults,
- and extensively train engineers on site.

Diagnostics Toolkit Setup
The Diagnostics Toolkit based on L3DC can be connected to a relevant bundle (up to 200) of
eNB via TCP based connection.
Those eNBs can be chosen by operator according to strategic relevance, occurrance of high
load, or suspicion of malfunction.
The configuration data for the connection settings can be imported via xls to the toolkit easily,
and can be changed at any time.
The L3DC is installed on a PC or server with Windows OS, and needs to be "placed" inside
customer secured IP area.
Monitoring of eNBs
After connection with selected eNBs the cell traces are captured online and all time (no user
plane data).
The cell trace content will be made visible to operator by decoding the messages relevant for
him.
07.07.2014 67/95

LTE RAN 1.0
Detection of critical situation in eNB and snapshot is triggered
Some cell trace messages indicate a suspected or actual malfunction. These are used as
triggers to invoke a snapshot on that specific eNB. From a set of pre-defined trigger events, the
operator can choose which should be actually trigger a snapshot.
The delay between trigger event detection and snapshot trigger is maximal 10ms.
The snapshot itself takes about 10 minutes currently, and has a size of ca. 10MB. The data is
stored at local directory in Flexi Multiradio BTS and is then going to be uploaded to BTS
Diagnostics Toolkit.
The snapshot file is after that available to be delivered to NSN for further analysis.
HW Requirements: L3DC required

Indoor
LBTS4.0 LBTS4.0
Element
BSW -
6.1.2 S1 lock/unlock
Unique ID: 1910
Short Description:
S1 Lock/Unlock offers an operator a possibility to lock and unlock the eNB S1 link to a target
MME via eNodeB O AND M.
07.07.2014 68/95

LTE RAN 1.0
Cells of the eNodeB can be kept in service during e.g. MME re-homing if LTE2 S1 Flex is in use
allowing several MMEs per eNodeB.
Operator is able to lock and unlock a eNB S1_MME link. The target MME can be any operator's
MME in case of RAN sharing is in use.
When S1_MME is locked, eNodeB will release all the UEs in RRC connected mode supported
by the locked S1. RRC release is made with cause code "other". For UL driven cases, UE will
initiate new RRC connection setup and will be directed to another MME if present. For DL data
driven cases the UE will be paged from an available MME connected to the eNodeB. Calls of
the eNodeB connected to potential other MMEs are unaffected by the lock procedure. Locked
MME is not considered in any MME selection procedures in the eNodeB. SCTP association of
the eNodeB to the MME is terminated.
NetAct Configurator and BTS Site manager shows the S1_MME administrative state as
"unlocked" or "locked" and separately operational state as "available" or "unavailable" to make
distinction between locked and faulty link. No alarm is raised when operator sets S1_MME as
"locked".
When S1 is unlocked, eNodeB establishes the SCTP association to the MME and handles the
scenario in the same way as MME link recovery.
The feature is controlled with a new O AND M parameter per MME, with default value
"unlocked".
HW Requirements: None
Interdependencies between Features: LTE2 S1 Flex is required to get the most benefits of S1
lock/unlock feature, but is not mandatory.

Indoor
Release RL45TD TD- TD- NetAct8 x - n/a
LBTS4.0 LBTS4.0 EP1
Element
BSW -
07.07.2014 69/95

LTE RAN 1.0
6.2 Configuration Management

6.2.1 Parameter Categorization
Unique ID: 1486
Short Description:
In LTE, WCDMA and GSM we are facing a high and still growing number of parameters per
Network Element.
Parametrization and optimization becomes more and more complex due to the high
number of interdependent parameters.
The customer feedback is:
o too many parameters
o difficult to understand their role
o complex parametrization and optimization
o poor Customer Documentation for parameters
Challenges of Parameter Management
o high AND growing number of parameters per network element
o complex, error prone, time consuming network parameterization/optimization
o some parameters most probably will never be touched
o some have very minor impact on network operations
o others very risky to be tuned (default not recommended to be changed)

07.07.2014 70/95

LTE RAN 1.0
o incorrectly set parameters may lead to serious performance issues and trigger
RESOLVEs/PRONTOs
In order to improve/ease the challenges of Parameter Management it is proposed to introduce a

categorization of parameters by,
limiting parameters to be set mandatorily
definition of parameters to be touched only when advanced optimization really needed
improve O AND M tools handling related to parameter settings e.g. network element
configuration, network configuration and optimization, wizards for feature activation,
advanced parameters visible only when necessary
By simplfication of the plan file and limitation of the number of parameters to be managed
customer expenses (OPEX) is reduced.
Simplified network parameterization

Faster product rollouts and less effort for competence development
The following two new parameter categories are introduced:
Basic (operator configurable)

o Configuration parameters like NE ids, IP address etc.
o Planning parameters like neighbor definitions, frequency plan, scrambling code
plan, PCI plan, RA preamble plan etc
o Output from dimensioning (parameters defining amount of resources)
o Parameters defining operators' strategy, e.g. traffic steering, thresholds for power
control, handovers, cell resections, high level parameters defining feature
behavior, etc.
o Parameters are visible in Network Element Manager, MML and NetAct,
contained in CuDo and explained in NEI's
o
o
Advanced (Configurable by NSN Service and/or Operator Advanced Staff)
o Network optimization and fine tuning parameters
o Decent network performance should be achieved without tuning of these
parameters
07.07.2014 71/95

LTE RAN 1.0
o Universal defaults ensuring decent network performance need to be defined for

all parameters in this category (if this is not possible for given parameter this
must be put in Basic parameters Category)
o Advanced parameters that require detailed system knowledge and broad
experience should be put in this category unless rules for Basic category are
violated
o All parameters (even with no defaults) that are related to advanced features like
DFCA, IUO, tracing etc are to be defined in Advanced Parameters category
o
o
There is another, existing parameter category, not visible to customers.

Restricted (Accessible only with special guidance from R AND D (and NetEng)

o this parameter category is already reflected by existing vendor parameters which
will be not modified/changed by this feature request
o
There are different existing tools/applications involved in parameter handling and which are
affected by a parameter categorization.
This feature requests to start introduction of parameter categories at NetAct CM-editor since this
NetAct-application is used at almost all operator use cases, requiring the management of
parameters.
For implementation of parameter categories, changes at CM-editor as well as Parameter

Dictionary (PDDB) are required.

Indoor
LBTS4.0 LBTS4.0 EP1
07.07.2014 72/95

LTE RAN 1.0
Element
BSW -
6.2.2 Support for Multi-antenna RET device

Unique ID: 1657
Short Description:
This feature introduces support for Multi-antenna RET devices to Flexi Multiradio BTS,
according to Iuant-interface specifcation, as described in 3GPP TS25.466.
An antenna may support tranmission/reception on different frequency bands wihin one physical
housing, whereby the antenna beam downtilt for each freaquency band can be controlled
separately via a build-in Multi-antenna RET-device.

Support for Multi-antenna RET devices by Flexi Multiradio BTS.
An operator may deploy antenna types, supporting more than one frequency band (e. g. Dual
band antenna).
For each supported frequency band the physical downtilt of the beam can be be configured per
given frequency band using a build-in Multi-antenna RET-device (Remote Electrical Tilt).
At the moment Flexi Multiradio BTS supports only single antenna RET-device.
This feature introduces Flexi Multiradio BTS support for communication to a Multi-antenna RET-
device, as used by antenna types supporting more than one frequency band (device type '0x11',
type 17), according to Iuant-interface specification (3GPP TS25.466).
Furtheron Flexi Multiradio BTS supports from an object modelling perspective the configuration
of a tilt for each supported frequency band (configuration of beam tilt per frequency band per
sector), which can be controlled and configured independently by NSN network management
system (NetAct/3prd party NMS or BTS Site Manager).
07.07.2014 73/95

LTE RAN 1.0

Indoor
LBTS4.0 LBTS4.0 EP1
Element
BSW -
6.2.3 System Upgrade from RL35 (TD-LBTS3.0) to RL45 (TD-LBTS4.0)

Unique ID: 1675

Smooth remote upgrade path from major release N-1 to release N. In this case from RL35 to
RL45
07.07.2014 74/95

LTE RAN 1.0
Following functionality is supported with the upgrade from release N-1 to release N:
1) The upgrade from release N-1 to release N is possible in one step. No intermediate SW
versions are necessary to be installed.
The impacted NEs are the Flexi Multiradio BTS, NetAct with all LTE relevant applications
including Optimizer, Trace Viewer, the Northbound interfaces and the iOMS, Traffica, Layer
Data Collector with its application, as L3 data analysis.
2) All operator-configured data are maintained in the system. If necessary, configuration data is
converted into new format.
This implies that the data from the previous release can be re-used after the upgrade. No
manual intervention is required.
This data does include
Most obvious all configuration data of the Flexi Multiradio BTS, iOMS, NetAct, Traffia, L3DC.
Adaptations done by operator for different (graphical) presentations in BTS SM or NetAct, for
example: top level user interface: topology view, as for example:
PM configuration
3) System data will be stored before system upgrade. A user-friendly backup concept is in
place. The data will be available after upgrade.
This data does include as for example:
Measurements, as PM data
PM data which is not yet uploaded to NetAct before System Upgrade activation in Flexi
Multiradio BTS will be lost.
User security, as data like user accounts/passwords, log files, ..

. Network security, as data like certificates, keys, ..
4) Command line/script execution
In case there are command line or scripts used they need to be backward compatible or a
converter is in place for the upgrade support from release N-1 to release N.
5) NetAct is prepared to handle both NE releases (release N-1, release N) with release N
timeframe. A mixed configuration support is ensured.
6) BTS SM is prepared to handle both NE releases, at least as co-existing versions of BTS SM
with release N.
7) Layer3 Data Collector is prepared to handle both NE releases.
8) If a conversion of the data is required the related converter Software is available either in
online or offline mode.
9) An LTE system wide top-down upgrade sequence is defined.
10) The downtime of a network entity during the system upgrade is reduced to the activation of
the new software. The switch to the new release (activation of the software) will be performed
on operator request from NetAct or BTS SM.
L3DC are supporting local SW management, no remote handling.
11) In case of an upgrade failure, an automatic fallback to the original release takes place. In
addition the fallback can be initiated from the operator on command.
For L3DC, a manual rollback can be initiated by operator.
The fallback has to consider as well the correct CM database and the consistency between
them needs to be ensured.
The automatic fallback is available for Flexi Multiradio BTS.
07.07.2014 75/95

LTE RAN 1.0
12) A delta description lists all differences to the old version as part of the customer
documentation. This is valid for all data.
13) This feature does not include the upgrade of any HW.
The upgrade paths have to consider Flexi Multiradio platform FSMr3 in following way:
FSMr3 RL35 (TD-LBTS3.0) to FSMr3 RL45 (TD-LBTS4.0)
This is valid for configurations which are fullfilled with FSMr3 configurations in RL35 (TD-
LBTS3.0)
14) Additional requests introduced with RL45 upgrade:
a)automatic CM upload of eNBs to NetAct for CM consistency after SW upgrade
b) NetAct8 is introduced in RL45 ( Even with the new NetAct 8, the backward compatibility with
N-1 is ensured)

Indoor
LBTS4.0 LBTS4.0
Element
BSW -
6.2.4 Extend maximum number of X2 links

Unique ID: 1708
Short Description:
Extend the maximum amount of potentially supported X2 links up to 256 for Flexi Multiradio 10
family and up to 128 X2 links for FSMD/E.
With the increase of X2 links in the eNB, more flexible handling of neighbor relations is possible.
07.07.2014 76/95

LTE RAN 1.0
Learning of new important X2 links is not blocked even when seldomly used X2 links are kept.
The increase of the X2 links is done in following way:
The number of supported X2 links is increased up to 256 for Flexi Multiradio 10 family and up
to 128 X2 links for FSMD/E. Those X2 links can be used arbitrary as enbControlled or
oamControlled.
The X2 black-list table is also increased correspondingly.
With the setup of 256 X2 links, also the learned neighbor cells are considered. Taking here
12 cells per eNB an overall amount of 256x12 + 11 = 3083 neighbor cells are able to be
considered (based on simple eNB level calculation)
The PM Counter concept for the neighbor cell related counters is adapted to avoid significant
increase due to increase of the X2 links from 64 X2 links to 256 X2 links.
The neighbor cell related counters are based on the real neighbor cell relations (mapped to
LNREL object) instead to be based on all potential neighor relations (mapped to LNADJL
objects).
The same concept is also applied for the neighbor cell related HO counters for GERAN and
WCDMA/TD-SCDMA.
An operator parameter is introduced. This parameter is able to configure the maximum

amount of X2 links that are wanted by operator per eNB.
With the increase of the X2 links, the following restrictions are accepted:
1) The setup time for the X2 links is considered independent of eNB restart time. The
finalization of the X2 links setup might take much longer as the eNB restart time.
The oamControlled X2 links are setup first (as already today) within a time limit of 20 minutes.
The enbControlled X2 links can be setup after the oamControlled, but do not need to be
established within the time limit.
2) The OAM driven ANR features in Optimizer (as LTE539, LTE492) are not be affected by this
increase and keep the values of the current design (64 LNADJ/ X2 links and PCI/IP mapping
table with up to 200 entries).
3) The LNREL (per LNCEL) amount will not increase and stay with 389.
Interdependencies between Features: With the change of the PM counter concept for the
neighbor related counters:
The following legacy features are affected by this change

07.07.2014 77/95

LTE RAN 1.0
LTE56 Inter RAT handover to WCDMA
LTE872 SRVCC to WCDMA
LTE873 SRVCC to GSM
LTE442 Network Assisted Cell Change to GSM
Changed requirements on PM counters related to above features is specified within CFAM

LTE1708.

Indoor
LBTS4.0 LBTS4.0 EP1
Element
BSW -
6.2.5 System Upgrade from RL35 Ir (TD-LBTS3.1) to RL45 EP

Unique ID: 1758
Short Description:
This feature enables the smooth upgrade from RL35 Ir (TD-LBT3.1) to RL45 EP.
Note: RL45 EP is CPRI Ir branch of RL45. For themore information about the RL45 EP,
please see the feature attachment

Smooth remote upgrade path from release RL35Ir to release RL45 EP.
This feature requires the system upgraded from RL35 (TD-LBTS3.1 to RL45 EP).
07.07.2014 78/95

LTE RAN 1.0
RL45 EP is introduced due to the market requirement. RL45 EP supports Ir interface only (note:
the OBSAI part in RL45 EP is not released), so the target SW of RL35 (TD-LTE3.1) for next
migration is changed to RL45 EP ( see CRL1540).
NetAct starts SW upgrading as legacy procedure, eNB downloads SW package RL45 EP from
NetAct. The loader script (see LTE1757) checks the version information from SCF file . If the
version information shows that it is upgrading from LNT3.1, BTSOM_IR.exe is assigned to be
used as BTSOM.exe. The Link_flag is added to SCF and set to Ir. System restarts after
successful upgrading.
Following normal requirement for system upgrading keeps the same:
1) The upgrade from release RL35 Ir to release RL45 EP is possible in one step. No
intermediate SW versions are necessary to be installed.
The impacted NEs are the Flexi Multiradio BTS, NetAct with all LTE relevant applications
including Optimizer, Trace Viewer, the Northbound interfaces and the iOMS, Layer Data
Collector with its application, as L3 data analysis.
2) All operator-configured data are maintained in the system. If necessary, configuration data is
converted into new format.
This implies that the data from the previous release can be re-used after the upgrade. No
manual intervention is required.
This data does include
* Most obvious all configuration data of the Flexi Multiradio BTS, iOMS, NetAct, L3DC.
* Adaptations done by operator for different (graphical) presentations in BTS SM or NetAct, for
example: top level user interface: topology view, as for example:
* PM configuration
3) System data will be stored before system upgrade. A user-friendly backup concept is in
place. The data will be available after upgrade.
This data does include as for example:
* Measurements, as PM data
PM data which is not yet uploaded to NetAct before System Upgrade activation in Flexi
Multiradio BTS will be lost.
* User security, as data like user accounts/passwords, log files, ..

. Network security, as data like certificates, keys, ..
4) Command line/script execution
In case there are command line or scripts used they need to be backward compatible or a
converter is in place for the upgrade support from release RL35 Ir to release RL45 EP.
5) NetAct is prepared to handle both NE releases (release N-1 (RL35Ir), release (RL45 EP))
with release RL45 EP timeframe. A mixed configuration support is ensured.
6) BTS SM is prepared to handle both NE releases, at least as co-existing versions of BTS SM
with release RL45 EP.
7) Layer3 Data Collector is prepared to handle both NE releases.
8) If a conversion of the data is required the related converter Software is available either in
online or offline mode.
9) An LTE system wide top-down upgrade sequence is defined.
10) The downtime of a network entity during the system upgrade is reduced to the activation of
the new software. The switch to the new release (activation of the software) will be performed
on operator request from NetAct or BTS SM.
L3DC are supporting local SW management, no remote handling.
07.07.2014 79/95

LTE RAN 1.0
11) In case of an upgrade failure, an automatic fallback to the original release takes place. In
addition the fallback can be initiated from the operator on command.
For L3DC, a manual rollback can be initiated by operator.
The fallback has to consider as well the correct CM database and the consistency between
them needs to be ensured.
The automatic fallback is available for Flexi Multiradio BTS.
12) A delta description lists all differences to the old version as part of the customer
documentation. This is valid for all data.
13) This feature does not include the upgrade of any HW.
The upgrade paths have to consider Flexi Multiradio platform FSMr3 in following way:
FSMr3 RL35 Ir (TD-LBTS3.1) to FSMr3 RL45 EP
This is valid for configurations which are fullfilled with FSMr3 configurations in RL35 Ir (TD-
LBTS3.1)
14) Additional requests introduced with RL45 EP upgrade:
a)automatic CM upload of eNBs to NetAct for CM consistency after SW upgrade
b) NetAct8 is introduced in RL45 EP ( Even with the new NetAct 8, the backward compatibility
with N-1 is ensured)
Interdependencies between Features: Yijin (2013. 10.30):
LTE1757": Single eNB SW package for CPRI IR and OBSAI"
is a available in RL45 EP for migration preparation purpose, even only CPRI Ir part is released.

Indoor
LBTS4.0 supported
Element
BSW -
07.07.2014 80/95

LTE RAN 1.0
6.2.6 Automatic cell combination assignment for Carrier Aggregation of

TD-LTE
Unique ID: 1813
Short Description:
Specific LTE mobility features, as e.g. carrier aggregation, require to indicate the cells which
shall build a group of cells which shall interwork. LTE1813 offers an automatic cell selection for
identifying the best candidates for Carrier Aggregation. Saving the manual selection efforts
(Note: this feature is only TDD related. FDD side is covered by LTE1367)

Automatic and optimized cell selection avoid any manual planning and setting of cell
combinations which are used in LTE mobility scenarios.
This automated configuration feature identifies the best cell pair candidates which shall be used
for Carrier Aggregation.
The specific conditions for the cell pairs applicable for carrier aggregation are considered.
The sector ID and the Carrier Aggregation Relation Parameter (CAREL) used in carrier
aggregation are generated for the cells in primary component carrier (PCC) and cells in
secondary component carrier (SCC).
The cells in the same sector are configured with the same sector ID and the CAREL identify the
cell pairs used for carrier aggregation.
The selection of the corresponding cell pairs is proposed by Optimizer algorithms. If no
corresponding cell pair can be identified, the operator will be informed about possible mismatch
in the configuration.
The operator can decide, if he would like to activate the proposed changes in the network or
discard them or would still like to change them.
The generation of cell candidates can be triggered during auto configuration or on manual
trigger by operator.
The functionality will be applied for the eNBs / cells in the network for which carrier aggregation
is enabled.

07.07.2014 81/95

LTE RAN 1.0

Indoor
LBTS4.0 LBTS4.0
Element
ASW NetAct NetAct
6.2.7 Synchronization of InterRAT neigbhors

Unique ID: 510
Short Description:
Feature LTE 783 and LTE 784 enable an operator to configure Inter-RAT neighbor relations
when new LTE eNBs are existing/created using pre-planned data (network planning and
configuration file download onto Flexi Multiradio BTS). The established Inter RAT neighbor
relations are also updated/synchronized automatically.
Feature LTE 510 adds mechanism to establish new InterRAT neighbor relations also in case
new UTRAN/GERAN cells are created to optimization scope of an existing LTE cell.

This feature ensures up-to-date Inter RAT relationships, also in case UTRAN/GERAN cells are
added to the network.
Feature LTE 510 adds mechanism to establish new InterRAT neighbor relations also in case
new UTRAN/GERAN cells are created to optimization scope of an existing LTE cell.
All relevant parameters for Inter RAT neighbor relation establishment will be provided by NSN
management system (NetAct) in case of a co-existing NSN 2G/3G network or by NSN
management via northbound interface (Itf-N), in case of another NSN NetAct regional cluster or
other vendor's co-existing 2G/3G network.
The creation of Inter-RAT neighbor relations is evaluated basing on

* the location (co-location) of the BTS
* the distance between the BTS
* the direction of antenna radio lobe
This process need to be triggered manually on demand by an operator.

07.07.2014 82/95

LTE RAN 1.0
Interdependencies between Features: Feature LTE 783 and LTE 784 are pre-requisite for
operating feature LTE 510.

Indoor
Release RL45TD TD- TD- OSS5.3 - - n/a
LBTS4.0 LBTS4.0 CD3
Element
07.07.2014 83/95

LTE RAN 1.0
ASW NetAct NetAct
6.2.8 ANR Intra-LTE, Inter-frequency - UE based

Unique ID: 556
Short Description:
Automated Neighbour Relation (ANR) for Intra-LTE, Inter-frequency neighbor cells is based on
UE measurements, searching on demand for currently unknown Intra-LTE, Inter-frequency
neighbor cells. It can be started to properly update and configure the Neighbor Cell List for
adjacent LTE cells.
This feature handles the use case when an operator adds a new Flexi Multiradio BTS to the
network, operating on a different EUTRAN-carrier than the installed neigbhor Flexi Multiradio
BTS.

The automated detection of unknown adjacent Intra-LTE, Inter-frequency LTE-cells supports the
self configuration of the Neighbor Cell List for Intra-LTE, Inter-frequency neighbor cells reducing
operational expenses in neighbor cell planning and keeping neighbor relations up-to-date.
In LTE networks the UE mobility in RRC Connected State trusts in information given by an
explicit neighbour cell list. To support and allow the automated configuration and update of
Intra-LTE, Inter-frequency neighbour cells without the need of a complete pre-planning of the
neighbour cell configurations a mechanism is implemented to discover unknown cells.
The trigger to start a search for Intra-LTE, Inter-frequency neighbours could be given from the
network management system or as result of internal RRM/Mobility Management algorithms.
The detection of unknown neighbour cells can happen during event triggered inter-frequency
measurements or during periodic measurements activated by the Flexi Multiradio BTS for ANR-
capable UEs.
Upon detection of an unknown cell, Flexi Multiradio BTS will try to resolve the corresponding
ECGI. This can be done ordering EGCI measurement at the UE, if supported by the UE, or via
any other information which may be locally available (e.g. from X2 interface).
In order to reduce the probability of call drops in case of a first HO to a newly detected neighbor
cell Flexi Multiradio BTS supports ANR-mechanisms in order to detect and configure any
unknown Intra-LTE, Inter-frequency neighbor cell as early as possible and not at the time when
the first HO to a newly detected cell is triggered. This kind of operational mode of ANR is further
referred to as active ANR.
07.07.2014 84/95

LTE RAN 1.0
Active ANR
If Active ANR handling is started, Flexi Multiradio BTS will pro-actively scan for unknown Inter-
frequency neigbhor cells.
Passive ANR
If there are no new unkown neighbor cells detected anymore ANR will be operated more as
background task, e. g. Flexi Multiradio BTS does not configure ANR-specific measurements but
uses the normal measurement reports (as received for HO) for detection of unkn0own cells.
The operator is able to control the behaviour of these ANR-mechanisms by providing
configuration parameters.
> switching ON/OFF ANR per Flexi Multiradio BTS

> operator-configurable parameters for switching between active and passive ANR
Monitoring of ANR is supported by means of performance measurements. The following events

can be monitored:
> number of successful/failed/attempted ECGI-resolutions

> number of successful/failed/attempted MMI-queries (IP@ resolution)
> number of successful/failed/attempted X2-setups
> number of HO-failures due to unresolved ECGI
After new neighbour cell relations have been successfully included into the local configuration
data the Flexi Multiradio BTS sends a configuration change notification to NetAct to inform the
operator about the new neigbhor cell configurations.
07.07.2014 85/95

LTE RAN 1.0
Interdependencies between Features: LTE55 Interfrequency Handover required

Indoor
capabilities
Element
07.07.2014 86/95

LTE RAN 1.0
6.2.9 SW Monitoring Extension with PM Counters

Unique ID: 646
Short Description:
Purpose of this feature is to extend the content of the SW monitoring report for the calculating of
the price for customers.
The existing SW monitoring module considers the evaluation of the configuration management
database for optional features.
Additionally to that evaluation now also additionally dedicated LTE PM counter shall be included
into the SW monitoring report, which are important to calculate the SW price for customer on a
usage basis.

SW Monitoring module will provide a complete picture of the network setup and network usage.
In addition to the report generated based on configuration data, now also dedicated PM Counter
are included into the SW monitoring report, for example the PM counter for counting the active
users shall be included to the report.
The SW monitoring roadmap illustrates this evolution.
The selection of the PM Counter, the detailed handling of the PM counter values, failure cases,
etc will be clarified in analysis phase.
07.07.2014 87/95

LTE RAN 1.0

Indoor
Release RL45TD TD- TD- OSS5.4 - - n/a
LBTS4.0 LBTS4.0 CD2
Element
BSW -
07.07.2014 88/95

LTE RAN 1.0
6.2.10 Intelligent configuration synchronization

Unique ID: 954
Short Description:
This proposal introduces an e2e mechanism for data synchronization to avoid unnecessary
uploads. Configuration Change ID information is added in network element and provided to
NetAct with the change notifications. NetAct uses the information to check if configuration
upload is needed. In case an upload is needed, NetAct triggers an automatic upload of the CM
data of that eNB.
The operator can reduce operating expenses due to more reliable date available in NetAct. No
upload required before planned configuration changes.
The feature increases the grade of service for the end user by maintaining up-to-date network
information automatically. No scheduled uploads are needed anymore.
Today, to ensure that the actual configuration stored in NetAct databases is up to date, an
upload of the CM data of eNB has to be done to NetAct. This is because configuration change
events may be lost due to several reasons which may happen in the network, as e.g. outage of
management plan connection for longer time and limited storage capacity of change
notifications in network element.
With this feature an e2e mechanism for data synchronization is introduced. For Configuration
Change Notification (CCN) a Configuration Change ID information is added in eNB and
provided via OMS to NetAct.
The Configuration Change ID is increased in eNB when real changes are done to the
configuration.
In case of re-sending of CCNs, the Configuration Change ID is not changed. The configuration
change may be caused by an autonomous action in the network element , or CM change
executed from BTS SM or NetAct
NetAct uses the Configuration Change ID information to check if configuration upload is needed.
In case an upload is needed, NetAct triggers an automatic upload of the CM data of that eNB.
07.07.2014 89/95

LTE RAN 1.0
When an upload is triggered by operator, NetAct requests first only the Configuration Change ID
value. An upload is then only requested to network element, if the Configuration Change ID
value in NetAct and network element does not match.
The Configuration Change ID is also checked in each management connection recovery.

Whether the mismatch in the value leads to automatic upload is up to the NetAct application and
operator preference.
The Configuration Change ID information is saved in network element's permanent memory.
Thus it is valid also after network element restart.

Indoor
LBTS4.0 LBTS4.0 EP1
Element
BSW -
6.3 O&M Security

6.3.1 Revocation management
Unique ID: 1245
Short Description:
This feature provides capabilities to manage cross-certified certificates and an enhanced

certificate revocation list (CRL) management with new activation and configuration capabilities
for multiple revocation list location

The customer is able to include a partner operators PKI by a cross signed CA certificate in case
of RAN sharing (MOCN or MORAN). It adds flexible control of revocation list configuration and
execution for the own PKI as well as for a partner operators PKI system.
07.07.2014 90/95

LTE RAN 1.0
Cross-signed certificate enrolment:
The BTS support the integration of a second operator PKI. In case the trust relation shall be
established by cross-certification the operator is able to store a cross signed certificate into the
BTS trust pool by the following options:
- Manually with the BTS Site Manager per individual BTS

- or with a NetAct script utilizing the BTS Site manager command line for a list of BTS
Cross-signed certificate update:
The operator may update a stored cross signed CA certificate at any point in time. Nevertheless
the BTS sends an alarm to NetAct when a cross-certificate is close to expire. The BTS applies
the same pre-warning time value as used for the own CA signing certificate expiry supervision.
If notified the operator may now add a cross-signed CA certificate manually via the BTS Site
Manager, either individual per BTS or with NetAct scripting for a list of BTS. The available cross
signed certificate is not automatically removed to allow a smooth migration to a new cross-
certification. Thus for a certain time 2 cross signed certificate can be handled by the BTS.
Cross-signed certificate removal:
An expired or unneeded cross-signed certificate can be deleted from the trust pool with the
NetAct NMCTool or with the BTS Site Manager. The BTS does not remove expired cross-
signed certificates autonomously.
Revocation List Management:
The revocation list management enhances the existing BTS CRL management by the capability
to configure additional CRL distribution points.
Overall CRL Activation:
The operator is able to activate or deactivate CRL handling for the whole BTS by a configurable
attribute with the BTS Site Manger and NetAct Configurator. If deactivated peers certificates are
not checked upon revocation.
CRL distribution points given within X.509 certificates:
The BTS ignores all CRL Distribution Points (CRLDP) contained within the entity certificate and
within all sub-ordinate CA certificates sent by the peers as part of the secured connection
establishment.
07.07.2014 91/95

LTE RAN 1.0
The BTS automatically downloads and regularly updates all CRL which may given as CRLDP
within the own entity certificate and all sub-ordinate CA certificates of the own signing chain.
Configurable CRL distribution points:
The BTS offers 8 additional OAM configurable CRL entries which can be configured for LDAP
download either as static IP address with path to directory or as FQDN with path to directory.
The parameters can be set with the BTS Site Manger and NetAct Configurator.
The operator may use them
- to configure CRLDP in addition or instead to the X.509 certificates method of the own
certification path and/or further CRL signing paths of the own operators PKI. A typical use case
would be if the security gateway is signed by a different sub-ordinate CA than the BTS.
- and to allow the revocation of corrupted SeGW certificates revoked by the partner operators
PKI by configuring additional CRL distribution points holding relating CRL information according
to operator agreements.
CRL information update:
CRL of the own certification path are initially added as part of the operator certificate enrollment
and updated with a later operator certificate update.
CRL of configurable CRLDP are added when a new CRLDP is configured.
A known CRL is updated (common for all types of CRLDP):
- Periodically when the BTS fetch timer expires(common for all types of CRLDP)
- With NextUpdate point in time given within a CRL (with random delay)
- At eNB start-up
- Triggered on demand by operator with NetAct NMCTool (with random delay) or with the BTS
Site Manager
A CRL is kept in the BTS as long as:

07.07.2014 92/95

LTE RAN 1.0
- a CRL is configured by CRLDP entry
- a CRL is part of own certification path
CRL check behavior configuration:
The operator is able to configure the usage and behavior for the CRL handling with the BTS Site
Manger and NetAct Configurator in a flexible manner.
Possible settings:
1. only CRLDP found within the certificates of the own certification path are taken into account ,
possibly found operator configured CRLDP are ignored.
2. only operator configured CRLDP are taken into account.
3. both CRLD within certificates of the own certification path and operator configured ones are
taken into account.
Each operator configurable entry can contain 2 CRLDP:
- a primary CRLDP
- and an optional secondary CRLDP
In case of 2 entries found the BTS treats them a primary and secondary CRL source. Hence the
BTS tries first to download the CRL from the primary CRLDP (1st entry) and if this fails it tries
download the CRL from the CRLDP (2st entry).
An alarm is only sent if the access to both locations fails. If only one CRLDP found then an
alarm is always sent if the access to the file location fails.
Configurable Trust chain for configured CRLDP:
CRLs are signed by the issuing CA. In case of the CRLs issued by a s sub-ordinate CA within
the BTS own signing chain the CRL origin can be automatically validated up till the own Trust
Anchor to verify the authenticity of this CRLs.
CRLs obtained from configured CRLDPs may be issued by sub-ordinate CA(s) either from
within the BTS own PKI hierarchy or from a partner operator PKI hierarchy. Thus the operator is
able to configure up to 8 additional sub-ordinate CA certificates to allow proper check of the
07.07.2014 93/95

LTE RAN 1.0
CRL origins. These CRL verification certificates can be added with the BTS Site Manager, either
individual per BTS or with NetAct scripting for a list of BTS.
The BTS informs NetAct when such a sub-CA certificate is close to expire. The BTS applies the
same pre-warning time value as used for the own CA signing certificate expiry supervision.
An expired or unneeded CRL verification sub-CA certificate can be deleted from BTS with the
NetAct NMCTool or with the BTS Site Manager. The BTS does not remove expired certificates
autonomously.

Indoor
LBTS4.0 LBTS4.0 EP1
07.07.2014 94/95

LTE RAN 1.0
Element
BSW -
7 Performance Monitoring
7.1 Additional QoS performance measurements
Unique ID: 1361
Short Description:
PM counters extension

PM counters enhancements, according to customer requirements.
Following PM-counters are implemented:
Number of established E-RABs per QC

o NumberOfEstabERABperQCI (#1/#2/#3/#4/#5/#6/#7/#8/#9)
o Use case:
o Provide feedback about the number of established (simultaneous) E-RAB per
supported QCI, implicitly the used services in the network (voice, streaming etc.)
Delay Budget Monitoring per QCI
Use case:
This measurement provides the PDCP SDU delay per QCI on the downlink. It is an
indicator for the delay experienced by the end-user. It also can be used to monitor the
packet delay budget characteristics of the E-RAB's QCI.

The measurement is done separately per QCI#1, #2, #3, #4, #5, #6, #7, #8, #9
Number of Uplink and Downlink PDCP Packet Loss (accord. to 3GPP 36.314) per
QCI (#5/#6/#7/#8 /#9)
Use case:
The objective of this measurement is to measure user plane packets that are lost on the
air interface. As such, it can also be used to monitor the packet error loss rate
characteristics of the E-RAB's QCI.

NOTE:
Packet Loss PM-counters for QCI #1/#2#/3 /#4 implemented with CRL 734.
07.07.2014 95/95

LTE RAN 1.0

Counters for RRC measuring RRC setup success rate, differentiating on additional
establishment causes as follows
- Mobile Originated Data (MO-Data)
- Mobile Orignated Signalling (MO-Signalling)
- Mobile Terminated Access (MT-Access)
Use case:
The objective is to be able to provide RRC Connection Establishment Success Rate for
RRCConnectionRequest message (from UE to eNB) in order to break down and classify
RRC Connection Setup failures currently for troubleshooting/drill down purposes

Indoor
LBTS4.0 LBTS4.0 EP1
Element
BSW -

RL45TD Feature Description

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

RL45TD Feature Description

Transféré par

Droits d'auteur :

Formats disponibles

Prepared by Date Page

Nokia Solutions and Networks Approved by Doc number Version

LTE RAN Release RL45TD (TD-LBTS4.0)

Nokia Solutions and Networks Approved by Doc number Version

Nokia Solutions and Networks Approved by Doc number Version

Nokia Solutions and Networks Approved by Doc number Version

5.3.6 Commercial Mobile Alert System .........................................................................58

Nokia Solutions and Networks Approved by Doc number Version

This document is NON BINDING.

Nokia Solutions and Networks Approved by Doc number Version

Nokia Solutions and Networks Approved by Doc number Version

3 BTS Site Solution

Benefits for the Customer:

HW Requirements: no specific HW requirements

Interdependencies between Features: no feature interdependencies

Nokia Solutions and Networks Approved by Doc number Version

TD-LTE RL Software Dependencies

3.2 Flexi System Module Indoor Variants FSIH & FBIH

This is a proposal to introduce FSMr3 indoor variant FSIH and FBIH.

Benefits for the Customer:

This is an indoor system module based on FSMr3 with increased DSP(6TurboNyquist/3Nyquist)

Nokia Solutions and Networks Approved by Doc number Version

This feature requires hardware readiness of the following features

HW Requirements: no specific HW requirements

Interdependencies between Features: no feature interdependencies

Dependency to other RATs:No dependency

TD-LTE RL Software Dependencies

3.3 RL45TD Site Configurations with FSIH

The site configurations in RL45 with new system module FSIH

Benefits for the Customer:

Configurations without hardware pre-installation (configuration 1-3)

Nokia Solutions and Networks Approved by Doc number Version

Up to 3 sectors per site

Configuraitons with hardware pre-install for 3x carriers (configuration 4-6)

HW Requirements: no specific HW requirements

Interdependencies between Features: no feature interdependencies

Dependency to other RATs:No dependency

TD-LTE RL Software Dependencies

Nokia Solutions and Networks Approved by Doc number Version

3.4 Enhanced external GPS box FYGE

This is an enhancement to LTE1252 FYGD based on major LTE customer need.

Benefits for the Customer:

This is an enhancement to LTE1252 FYGD based on LTE customer need.

HW Requirements: no specific HW requirements

Nokia Solutions and Networks Approved by Doc number Version

Interdependencies between Features: no feature interdependencies

Dependency to other RATs:No dependency

TD-LTE RL Software Dependencies

3.5 FZHJ Flexi RRH 8TX 2600 BD41

Benefits for the Customer:

Main features of Flexi RRH 8TX 2600 are:

Nokia Solutions and Networks Approved by Doc number Version

* DC-connector (-48V, 0V, Earth)

HW Requirements: no specific HW requirements

Interdependencies between Features: no feature interdependencies

Dependency to other RATs:No dependency

TD-LTE RL Software Dependencies

3.6 RL45TD Site Configurations with FSMF

RL45 TDLTE site configuration with FSMF

Benefits for the Customer:

Nokia Solutions and Networks Approved by Doc number Version

20MHz per cell

HW Requirements: no specific HW requirements

Interdependencies between Features: no feature interdependencies