RL45TD Feature Description

Prepared by

Nokia Solutions and Networks LTE RAN

Approved by

Date

Page

07.07.2014

1/95

Doc number

Version

LTE RAN Release RL45TD (TD-LBTS4.0) New Features

1.0

Prepared by


Approved by

Date

Page

07.07.2014

2/95

Doc number

Version 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.

Prepared by


Approved by

Date

Page

07.07.2014

3/95

Doc number

Version 1.0

Table of Contents 1 2 3

Introduction ......................................................................................................................... 5 History ................................................................................................................................ 6 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

Prepared by


Approved by

Date

Page

07.07.2014

4/95

Doc number

Version 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

Prepared by


Approved by

Date

Page

07.07.2014

5/95

Doc number

Version 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.

Prepared by


Approved by

2 History V1.0 RL45TD C5 Version on Jul,7th

Date

Page

07.07.2014

6/95

Doc number

Version 1.0

Prepared by


Approved by

Date

Page

07.07.2014

7/95

Doc number

Version 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 TDTech/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 AC～290V 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

Prepared by


Approved by

RL45TD

SW Sales Information: BSW/ASW BSW

Page

07.07.2014

8/95

Doc number

Version 1.0

TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

Date

TDLBTS4.0

BTS Flexi 10 Indoor TDLBTS4.0

NetAct

OMS

-

Licence Control in Network Element -

MME

SAE GW

-

-

UE

Licence Control Attributes

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. Benefits for the Customer: Compact indoor solution for max BF configuration Functional Description: 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.

Prepared by


Approved by

Date

Page

07.07.2014

9/95

Doc number

Version 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.

HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10

NetAct

Release

-

RL45TD


BTS Flexi 10 Indoor not TDsupported LBTS4.0


OMS

MME

SAE GW

UE

-

-

n/a


3.3 RL45TD Site Configurations with FSIH Unique ID: 1570 Short Description: The site configurations in RL45 with new system module FSIH Benefits for the Customer: Allow customer to deploy their network with the new system module FSIH Functional Description: 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

Prepared by


Approved by

Date

Page

07.07.2014

10/95

Doc number

Version 1.0

Up to 3 sectors per site Each sector with up to two carriers RF variants: FZHJ Configuration 3: FSIH(+FBIH) to support 2Tx 2Rx configurations, 2.6GHz Up to 3 sectors per site Each sector with up to two carriers 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 Up to 3 sectors per site Each sector with up to two carriers RF variants: FZHJ Configuration 4: 4Tx 4Rx configurations, 2.6GHz (T111/T222 4T4R) System module and fiber cables are pre-installed ready for T333 4T4R: FSIH+2xFBIH Up to 3 sectors per site Each sector with up to two carriers RF variants: FZHJ Configuration 6: 8Tx 8Rx configurations, 2.6GHz (T111/T222 2T2R) System module and fiber cables are pre-installed ready for T333 2T2R: FSIH+2xFBIH Up to 3 sectors per site Each sector with up to two carriers RF variants: FZHJ Details for the configuraitons can refer to attached ppt. HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10

NetAct

Release

-

RL45TD

SW Sales Information: BSW/ASW

BTS Flexi 10 Indoor not TDsupported LBTS4.0

Licence Control in Network Element

OMS

MME

SAE GW

-

-

UE


Prepared by

Nokia Solutions and Networks LTE RAN BSW

Approved by

Date

Page

07.07.2014

11/95

Doc number

Version 1.0

-

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. Benefits for the Customer: support GPS holdover time of more than 24hours with less than +/-1.5us phase drift Functional Description: 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 HW Requirements: no specific HW requirements

Prepared by


Approved by

Date

Page

07.07.2014

12/95

Doc number

Version 1.0

Interdependencies between Features: no feature interdependencies Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

-


OMS

MME

SAE GW

-

-

UE


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. Benefits for the Customer: Flexi RF Head BD41 8x20W is able to support 8TX/8RX beamforming with high output power. It enables easy installation outdoors close to antennas. Functional Description: 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 80100MHz 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

Prepared by


Approved by

Date

Page

07.07.2014

13/95

Doc number

Version 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 @25˚C * 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 HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

-


OMS

MME

SAE GW

-

-

UE


3.6 RL45TD Site Configurations with FSMF Unique ID: 1707 Short Description: RL45 TDLTE site configuration with FSMF Benefits for the Customer: Allow customer to deploy their network untilizing multiple bandwidth resources. Functional Description: 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

Prepared by


Approved by

Date

Page

07.07.2014

14/95

Doc number

Version 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) Up to 3 sectors per site 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 HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD

TDLBTS4.0

BTS NetAct Flexi 10 Indoor not supported

OMS

MME

SAE GW

-

-

UE

Prepared by



Approved by

Date

Page

07.07.2014

15/95

Doc number

Version 1.0



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. 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 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

Prepared by


Approved by

Date

Page

07.07.2014

16/95

Doc number

Version 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 AC～290V 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 Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0



OMS

MME

SAE GW

-

-

UE


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.

Prepared by


Approved by

Date

Page

07.07.2014

17/95

Doc number

Version 1.0

Benefits for the Customer: 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. Functional Description: 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 @25˚C * RF connector type: Mini-DIN * Weight <=23Kg & Volume <31L

HW Requirements:

Prepared by


Approved by

Date

Page

07.07.2014

18/95

Doc number

Version 1.0

Interdependencies between Features: no feature interdependencies TD-LTE RL Software Dependencies: BTS BTS LTE Flexi 10 Flexi 10 Indoor Release

RL45TD

TDLBTS4.0


TDLBTS4.0

Flexi Zone Micro

NetAct

OMS

MME

SAE GW

UE

not supported



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.

Benefits for the Customer: This feature supports migration of the mobile operator networks and IP transport networks from IPv4 to IPv6. Functional Description: 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

Prepared by


Approved by

Date

Page

07.07.2014

19/95

Doc number

Version 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.

Prepared by


Approved by

Date

Page

07.07.2014

20/95

Doc number

Version 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 Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD

SW Sales Information: BSW/ASW ASW

TDLBTS4.0

Short Description:

NetAct

NetAct8 EP1

Licence Control in Network Element SW Asset Monitoring

4.2 IPSec Emergency Bypass Unique ID: 1390


OMS

MME

SAE GW

UE

x

x

n/a


Prepared by


Approved by

Date

Page

07.07.2014

21/95

Doc number

Version 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. Benefits for the Customer: 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. Functional Description: 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 nonoperational 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.

Prepared by


Approved by

Date

Page

07.07.2014

22/95

Doc number

Version 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 Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0

Short Description:

NetAct

NetAct8 EP1


4.3 Measurement based TAC Unique ID: 1401


OMS

MME

SAE GW

UE

-

-

n/a


Prepared by


Approved by

Date

Page

07.07.2014

23/95

Doc number

Version 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 Benefits for the Customer: 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 Functional Description: 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 nonGBR 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 Dependency to other RATs:No dependency

Prepared by


Approved by

RL45TD


Page

07.07.2014

24/95

Doc number

Version 1.0


Date

TDLBTS4.0


NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

-

-

n/a


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. Benefits for the Customer: 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

Prepared by


Approved by

Date

Page

07.07.2014

25/95

Doc number

Version 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 Functional Description: "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.

HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies Dependency to other RATs:No dependency TD-LTE RL Software Dependencies

Prepared by


LTE Release

BTS Flexi

RL45TD


Approved by

Date

Page

07.07.2014

26/95

Doc number

Version 1.0

BTS Flexi 10 TDLBTS4.0


NetAct

OMS

-


MME

SAE GW

UE

-

-

n/a


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 Benefits for the Customer: Higher reliability for LTE to UTRAN service continuity HW Requirements: no specific HW requirements Interdependencies between Features: The feature is enabled together with LTE56. with TDD, LTE898 needs to be enabled also with target system TD-SCDMA. TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

OSS5.4 CD2


OMS

MME

SAE GW

UE

x

-

3GPP R8 UE capabilities


Prepared by

Nokia Solutions and Networks LTE RAN ASW

Approved by

Date

Page

07.07.2014

27/95

Doc number

Version 1.0

SW Asset Monitoring

5.1.2 RSRQ triggered mobility Unique ID: 1198 Short Description:

Inter-frequency and inter-RAT mobility based on RSRQ triggers. Benefits for the Customer: 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.

Functional Description: 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.

HW Requirements: no specific HW requirements 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 TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD

TDLBTS4.0


NetAct

NetAct8 EP1

OMS

MME

SAE GW

UE

-

-


Prepared by

Nokia Solutions and Networks LTE RAN SW Sales Information: BSW/ASW ASW

Approved by

Date

Page

07.07.2014

28/95

Doc number

Version 1.0



5.1.3 Inter-frequency load balancing extension Unique ID: 1531 Short Description:

The scope of UEs considered for load balancing is increased. Benefits for the Customer: The number of UEs considered for load balancing is increased which leads to a higher likelihood for off-loading a cell. Functional Description: 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. HW Requirements: no specific HW requirements Interdependencies between Features: The feature is enabled together with LTE1387 or LTE1170. TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

-

-

3GPP R8 mandatory


Prepared by

Nokia Solutions and Networks LTE RAN ASW

Approved by

Date

Page

07.07.2014

29/95

Doc number

Version 1.0

SW Asset Monitoring

5.1.4 Multiple Frequency Band Indicator Unique ID: 1534 Short Description:

Intra-LTE MFBI functionality is introduced. Benefits for the Customer: The functionality allows to handle UEs with overlapping bands in one network. Functional Description: 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. HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10

BTS Flexi 10

NetAct

OMS

MME

SAE GW

UE

Prepared by


Release

RL45TD


Approved by

Date

Page

07.07.2014

30/95

Doc number

Version 1.0

TDLBTS4.0

Indoor TDLBTS4.0

NetAct8 EP1


-

-



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. Benefits for the Customer: A multi-frequency balancing scheme for RRC IDLE UEs is introduced. Functional Description: 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. HW Requirements: no specific HW requirements 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. Dependency to other RATs:No dependency

Prepared by


Approved by

RL45TD


Page

07.07.2014

31/95

Doc number

Version 1.0


Date

TDLBTS4.0


NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

-

-



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. Benefits for the Customer: Inter PLMN mobility with HRL in X2 handover Functional Description: 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

Prepared by


Approved by

Date

Page

07.07.2014

32/95

Doc number

Version 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. HW Requirements: no specific HW requirements Interdependencies between Features: Related X2 mobility functionality needs to be enabled, e.g. LTE53, LTE55 or LTE1060. Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

x


OMS

MME

SAE GW

UE

-

-

3GPP R8 mandatory


5.1.7 Extended inter-frequency measurements Unique ID: 2008 Short Description: Extended inter-frequency measurement support Benefits for the Customer: The number os supported inter-frequency layers for cell re-selection and inter-frequency measurements for handover is expanded. Functional Description: 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. HW Requirements: no specific HW requirements

Prepared by


Approved by

Date

Page

07.07.2014

33/95

Doc number

Version 1.0

Interdependencies between Features: The feature is enabled together with LTE55. LTE1060 needs to be enabled for FDD-TDD handover support. Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

x


OMS

MME

SAE GW

UE

-

-



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. Benefits for the Customer: The operator needs to configure less parameters for the network assisted cell change or the RRC connection release with redirect and SIB. Functional Description: 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:

Prepared by


Approved by

Date

Page

07.07.2014

34/95

Doc number

Version 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. HW Requirements: Future study item for Flexi MR10K BTS 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 TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD

TDLBTS4.0



NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

x

-



5.1.9 Intra cell handover Unique ID: 511 Short Description: The eNode B performs a handover to the serving cell. Functional Description: 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

Prepared by


Approved by

Date

Page

07.07.2014

35/95

Doc number

Version 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 HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


5.1.10

TDLBTS4.0


NetAct

-


OMS

MME

SAE GW

UE

-

-

3GPP R8 mandatory


Inter RAT handover from UTRAN

Unique ID: 57 Short Description: Active mode mobility from UTRAN to LTE Benefits for the Customer: The end user may experience better service quality, e.g. peak rates and latency, in LTE as in UTRAN. Functional Description: The Flexi Multiradio BTS supports incoming PS handovers from UTRAN to LTE. The handover procedure is initiated by the RNC.

Prepared by


Approved by

Date

Page

07.07.2014

36/95

Doc number

Version 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. HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


5.1.11

TDLBTS4.0


NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

x

x



Inter RAT handover to eHRPD/3GPP2

Unique ID: 60 Short Description: Coverage based prepared inter RAT handover from LTE to CDMA2000 eHRPD Benefits for the Customer: Reduced service interuption time Functional Description:

Prepared by


Approved by

Date

Page

07.07.2014

37/95

Doc number

Version 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.

Prepared by


Approved by

Date

Page

07.07.2014

38/95

Doc number

Version 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 TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10

BTS Flexi 10

NetAct

OMS

MME

SAE GW

UE

Prepared by


Release

RL45TD


5.1.12

Approved by

Date

Page

07.07.2014

39/95

Doc number

Version 1.0

TDLBTS4.0

Indoor TDLBTS4.0

NetAct8 EP1


x

x



SRVCC to WCDMA

Unique ID: 872 Short Description: Service continuity for VoIP Benefits for the Customer: Seamless handover for voice services to WCDMA when leaving the LTE coverage Functional Description: 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.

Prepared by


Approved by

Date

Page

07.07.2014

40/95

Doc number

Version 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 HW Requirements: no specific HW requirements 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) TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


5.1.13

TDLBTS4.0


NetAct

OSS5.4 CD2


OMS

MME

SAE GW

UE

x

x



SRVCC to GSM

Unique ID: 873 Short Description: Service continuity for VoIP Benefits for the Customer: Seamless handover for voice services to GSM when leaving the LTE coverage Functional Description:

Prepared by


Approved by

Date

Page

07.07.2014

41/95

Doc number

Version 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.

Prepared by


Approved by

Date

Page

07.07.2014

42/95

Doc number

Version 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

Prepared by

Nokia Solutions and Networks LTE RAN 

Approved by

Date

Page

07.07.2014

43/95

Doc number

Version 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

HW Requirements: no specific HW requirements Interdependencies between Features: the following features must be enabled: Support of GBR EPS bearers (LTE 10) Support of multiple EPS bearers (LTE 7) TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD

TDLBTS4.0


5.1.14


NetAct

OMS

OSS5.4 CD2


MME

SAE GW

UE

x

x



CSFB to CDMA/1xRTT for dual RX UEs

Unique ID: 874 Short Description: Service continuity for CS voice. Benefits for the Customer: Redirected call setup for voice calls Functional Description: 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)

Prepared by


Approved by

Date

Page

07.07.2014

44/95

Doc number

Version 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. HW Requirements: no specific HW requirements 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. TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

x

-



Prepared by


Approved by

Date

Page

07.07.2014

45/95

Doc number

Version 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. Benefits for the Customer: A higher uplink cell capacity and improved cell edge throughput can be used for providing additional services and better service coverage. Functional Description: 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. HW Requirements: no specific HW requirements 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. Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

-

-

3GPP R8 mandatory


Prepared by


Approved by

Date

Page

07.07.2014

46/95

Doc number

Version 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. Benefits for the Customer: The uplink intra eNode B CoMP provides up to 50% cell edge improvement compared to a 2RX receiver. Functional Description: 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.

Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD

TDLBTS4.0


NetAct

NetAct8 EP1

OMS

MME

SAE GW

UE

-

-

3GPP R8 mandatory

Prepared by



Approved by

Date

Page

07.07.2014

47/95

Doc number

Version 1.0



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. Benefits for the Customer: 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. Functional Description: 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 longterm 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)

Prepared by


Approved by

Date

Page

07.07.2014

48/95

Doc number

Version 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. Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD

TDLBTS4.0


NetAct

-

OMS

MME

SAE GW

UE

-

-

3GPP R10 mandatory

Prepared by


Approved by

Date

Page

07.07.2014

49/95

Doc number

Version 1.0

3GPP R10 UE capabilities SW Sales Information: BSW/ASW ASW



5.2.4 TDD Downlink carrier aggregation Unique ID: 1558 Short Description: Extend downlink bandwidth up to 40MHz with two component carriers Benefits for the Customer: provide higher peak data rates for UEs and increase average UE downlink throughput at unloaded networks Functional Description: 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,

Prepared by


Approved by

Date

Page

07.07.2014

50/95

Doc number

Version 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)

Prepared by


Approved by

Date

Page

07.07.2014

51/95

Doc number

Version 1.0

* LTE1543:8x2 SU MIMO with TM9 TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

OMS

-


MME

SAE GW

UE

-

-



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.

Benefits for the Customer: Higher uplink peak rates can be offered to customers. Functional Description: 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. HW Requirements: no specific HW requirements Interdependencies between Features: LTE788 needs to be enabled. TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD

TD-

BTS Flexi 10 Indoor TD-

NetAct

-

OMS

MME

SAE GW

UE

-

-

3GPP R8

Prepared by


Approved by

ASW

Page

07.07.2014

52/95

Doc number

Version 1.0

LBTS4.0


Date

LBTS4.0


UE capabilities


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. Benefits for the Customer: Access prioritisation for emergency calls and high priority users Functional Description: 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. HW Requirements: no specific HW requirements Interdependencies between Features: The following features need to be enabled:

Prepared by


Approved by

Date

Page

07.07.2014

53/95

Doc number

Version 1.0

LTE572 IMS Emergency Session LTE534 ARP based Admission Control LTE496 Support of QCI 2,3,4 LTE497 Smart Admission Control Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

OMS

NetAct8 EP1


MME

SAE GW

UE

x

-

3GPP R8 mandatory


5.3.2 Operator-specific GBR QCIs Unique ID: 1231 Short Description:

The operator can define its own QoS profiles for GRB EPS bearers. Benefits for the Customer: The operator-specific QCIs allow for better user and service differentiation of GBR services. Functional Description: 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

Prepared by


Approved by

Date

Page

07.07.2014

54/95

Doc number

Version 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. HW Requirements: no specific HW requirements 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 TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

OMS

NetAct8 EP1


MME

SAE GW

UE

x

-

3GPP R8 mandatory


5.3.3 Cell resource groups Unique ID: 1382 Short Description: The cell resource groups allow to virtually split the cell resources. Benefits for the Customer: The operator is able to pre-define resource shares in case of MOCN or national roaming. Functional Description: 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.

Prepared by


Approved by

Date

Page

07.07.2014

55/95

Doc number

Version 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. HW Requirements: Future study item for Flexi MR10K BTS 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 Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD

TDLBTS4.0


NetAct

NetAct8 EP1

OMS

MME

SAE GW

UE

-

-

3GPP R8 mandatory

Prepared by



Approved by

Date

Page

07.07.2014

56/95

Doc number

Version 1.0



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.

Benefits for the Customer: The functions allows the eSMLC to automatically retrieve OTDOA related parameters from the eNode B. Functional Description: 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

Prepared by


Approved by

Date

Page

07.07.2014

57/95

Doc number

Version 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.

HW Requirements: no specific HW requirements Interdependencies between Features: LTE495 OTDOA needs to be enabled. Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct8 EP1


5.3.5 Multiple emergency areas per cell Unique ID: 1755

NetAct

OMS

MME

SAE GW

UE

x

-



Prepared by


Approved by

Date

Page

07.07.2014

58/95

Doc number

Version 1.0

Short Description: Support of multiple emergency area IDs per cell. Functional Description: 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. HW Requirements: no specific HW requirements Interdependencies between Features: LTE843 or LTE494 needs to enabled. Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

x

-



5.3.6 Commercial Mobile Alert System Unique ID: 494 Short Description: CMAS is a solution to broadcast public warning messages. Benefits for the Customer: The operator is able to a support public warning service. Functional Description: The Flexi Multiradio BTS supports CMAS (Commercial Mobile Alert System).

Prepared by


Approved by

Date

Page

07.07.2014

59/95

Doc number

Version 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. HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

OSS5.4 CD2


OMS

MME

SAE GW

UE

x

-



Prepared by


Approved by

Date

Page

07.07.2014

60/95

Doc number

Version 1.0

5.3.7 IMS emergency sessions Unique ID: 572 Short Description: Support of IMS emergency calls. Benefits for the Customer: The operator can offer IMS emergency sessions for LTE. HW Requirements: no specific HW requirements Interdependencies between Features: LTE10 Support of EPS bearers for conversational voice and LTE7 Support of multiple EPS bearer required. TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

-


OMS

MME

SAE GW

UE

x

x



5.3.8 Smart DRX Unique ID: 585 Short Description: Improved power saving for always on users Benefits for the Customer: The feature allows for UE power saving for the duration of the UE short inactivity timer. Functional Description: 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

Prepared by


Approved by

Date

Page

07.07.2014

61/95

Doc number

Version 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. HW Requirements: no specific HW requirements Interdependencies between Features: The features LTE42 DRX in RRC connected mode and LTE473 Extended DRX Settings must be enabled. TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

OSS5.4 CD2


OMS

MME

SAE GW

UE

-

-



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. Benefits for the Customer: To fulfill regulatory requirement on relevant markets. Functional Description: 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

Prepared by


Approved by

Date

Page

07.07.2014

62/95

Doc number

Version 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. HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

OSS5.4 CD2


OMS

MME

SAE GW

UE

x

-



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. Benefits for the Customer:

Prepared by


Approved by

Date

Page

07.07.2014

63/95

Doc number

Version 1.0

The eNode B ensures with this feature a high control plane throughput is achieved at a high offered load. Functional Description: 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

Prepared by


Approved by

Date

Page

07.07.2014

64/95

Doc number

Version 1.0

The functionality can be enabled / disabled per eNode B with its subordinated cells by O AND M setting. HW Requirements: no specific HW requirements Interdependencies between Features: LTE534 ARP based admission control for E-RABs needs to be enabled Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

OMS

NetAct8 EP1


MME

SAE GW

UE

-

-

3GPP R8 mandatory


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 Benefits for the Customer: Stable operation in case of MME overload Functional Description: 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

Prepared by


Approved by

Date

Page

07.07.2014

65/95

Doc number

Version 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. HW Requirements: no specific HW requirements Interdependencies between Features: related features: LTE 4 - RAN sharing for two operators LTE 2 - S1 Flex TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

OSS5.4 CD2


OMS

MME

SAE GW

UE

x

-

3GPP R8 mandatory


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

Prepared by


Approved by

Date

Page

07.07.2014

66/95

Doc number

Version 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 Benefits for the Customer: 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. Functional Description: 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.

Prepared by


Approved by

Date

Page

07.07.2014

67/95

Doc number

Version 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 Interdependencies between Features: no feature interdependencies Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

-


OMS

MME

SAE GW

UE

-

-

n/a


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.

Prepared by


Approved by

Date

Page

07.07.2014

68/95

Doc number

Version 1.0

Benefits for the Customer: 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. Functional Description: 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. Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

x

-

n/a


Prepared by


Approved by

Date

Page

07.07.2014

69/95

Doc number

Version 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

o o 

Challenges of Parameter Management

 o

high AND growing number of parameters per network element

o 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)

Prepared by

Nokia Solutions and Networks LTE RAN o

Approved by

Date

Page

07.07.2014

70/95

Doc number

Version 1.0

incorrectly set parameters may lead to serious performance issues and trigger RESOLVEs/PRONTOs

o o 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

Benefits for the Customer: 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 Functional Description: 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

Prepared by

Nokia Solutions and Networks LTE RAN o o o

Approved by

Date

Page

07.07.2014

71/95

Doc number

Version 1.0

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) Advanced parameters that require detailed system knowledge and broad experience should be put in this category unless rules for Basic category are violated 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.

HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD

TDLBTS4.0


NetAct

NetAct8 EP1

OMS

MME

SAE GW

UE

-

-

n/a

Prepared by



Approved by

Date

Page

07.07.2014

72/95

Doc number

Version 1.0



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. Benefits for the Customer: Support for Multi-antenna RET devices by Flexi Multiradio BTS. Functional Description: 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 RETdevice, 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).

Prepared by


Approved by

Date

Page

07.07.2014

73/95

Doc number

Version 1.0


RL45TD


TDLBTS4.0


NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

-

-

n/a


6.2.3 System Upgrade from RL35 (TD-LBTS3.0) to RL45 (TD-LBTS4.0) Unique ID: 1675 Benefits for the Customer: Smooth remote upgrade path from major release N-1 to release N. In this case from RL35 to RL45 Functional Description:

Prepared by


Approved by

Date

Page

07.07.2014

74/95

Doc number

Version 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.

Prepared by


Approved by

Date

Page

07.07.2014

75/95

Doc number

Version 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 (TDLBTS3.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) HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

-


OMS

MME

SAE GW

UE

-

-

n/a


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. Benefits for the Customer: With the increase of X2 links in the eNB, more flexible handling of neighbor relations is possible.

Prepared by


Approved by

Date

Page

07.07.2014

76/95

Doc number

Version 1.0

Learning of new important X2 links is not blocked even when seldomly used X2 links are kept. Functional Description: 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. HW Requirements: no specific HW requirements 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

Prepared by


Approved by

Date

Page

07.07.2014

77/95

Doc number

Version 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. Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

OMS

NetAct8 EP1


MME

SAE GW

UE

-

-

n/a


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 Benefits for the Customer: Smooth remote upgrade path from release RL35Ir to release RL45 EP. Functional Description: This feature requires the system upgraded from RL35 (TD-LBTS3.1 to RL45 EP).

Prepared by


Approved by

Date

Page

07.07.2014

78/95

Doc number

Version 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.

Prepared by


Approved by

Date

Page

07.07.2014

79/95

Doc number

Version 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 (TDLBTS3.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)

HW Requirements: no specific HW requirements 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.

Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0



OMS

MME

SAE GW

-

-

UE


Prepared by


Approved by

Date

Page

07.07.2014

80/95

Doc number

Version 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) Benefits for the Customer: Automatic and optimized cell selection avoid any manual planning and setting of cell combinations which are used in LTE mobility scenarios. Functional Description: 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.

HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies Dependency to other RATs:No dependency

Prepared by


Approved by

RL45TD

SW Sales Information: BSW/ASW ASW NetAct

Page

07.07.2014

81/95

Doc number

Version 1.0


Date

TDLBTS4.0


NetAct

OMS

-

Licence Control in Network Element NetAct

MME

SAE GW

-

-

UE


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. Benefits for the Customer: This feature ensures up-to-date Inter RAT relationships, also in case UTRAN/GERAN cells are added to the network. Functional Description: 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.

Prepared by


Approved by

Date

Page

07.07.2014

82/95

Doc number

Version 1.0

HW Requirements: no specific HW requirements Interdependencies between Features: Feature LTE 783 and LTE 784 are pre-requisite for operating feature LTE 510. TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

OSS5.3 CD3


OMS

MME

SAE GW

UE

-

-

n/a


Prepared by

Nokia Solutions and Networks LTE RAN ASW NetAct

Approved by

Date

Page

07.07.2014

83/95

Doc number

Version 1.0

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. Benefits for the Customer: 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. Functional Description: 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 ANRcapable 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.

Prepared by


Approved by

Date

Page

07.07.2014

84/95

Doc number

Version 1.0

Active ANR If Active ANR handling is started, Flexi Multiradio BTS will pro-actively scan for unknown Interfrequency 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.

Prepared by


Approved by

Date

Page

07.07.2014

85/95

Doc number

Version 1.0

HW Requirements: no specific HW requirements Interdependencies between Features: LTE55 Interfrequency Handover required Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

x

-



Prepared by


Approved by

Date

Page

07.07.2014

86/95

Doc number

Version 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.

Benefits for the Customer: SW Monitoring module will provide a complete picture of the network setup and network usage. Functional Description: 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.

Prepared by


Approved by

Date

Page

07.07.2014

87/95

Doc number

Version 1.0


RL45TD


TDLBTS4.0


NetAct

OSS5.4 CD2


OMS

MME

SAE GW

UE

-

-

n/a


Prepared by


6.2.10

Approved by

Date

Page

07.07.2014

88/95

Doc number

Version 1.0

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. Benefits for the Customer: 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. Functional Description: 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.

Prepared by


Approved by

Date

Page

07.07.2014

89/95

Doc number

Version 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. HW Requirements: no specific HW requirements Interdependencies between Features: no feature interdependencies Dependency to other RATs:No dependency TD-LTE RL Software Dependencies BTS BTS LTE Flexi Flexi 10 Release

RL45TD


TDLBTS4.0


NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

-

-

n/a


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 Benefits for the Customer: 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.

Prepared by


Approved by

Date

Page

07.07.2014

90/95

Doc number

Version 1.0

Functional Description: 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 crosscertification. 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 crosssigned 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.

Prepared by


Approved by

Date

Page

07.07.2014

91/95

Doc number

Version 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:

Prepared by


Approved by

Date

Page

07.07.2014

92/95

Doc number

Version 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

Prepared by


Approved by

Date

Page

07.07.2014

93/95

Doc number

Version 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.


RL45TD

TDLBTS4.0


NetAct

NetAct8 EP1

OMS

MME

SAE GW

UE

-

-

n/a

Prepared by



Approved by

Date

Page

07.07.2014

94/95

Doc number

Version 1.0



7 Performance Monitoring 7.1 Additional QoS performance measurements Unique ID: 1361 Short Description: PM counters extension Benefits for the Customer: PM counters enhancements, according to customer requirements. Functional Description: Following PM-counters are implemented:  

Number of established E-RABs per QC o o o

          

NumberOfEstabERABperQCI (#1/#2/#3/#4/#5/#6/#7/#8/#9) Use case: 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.

Prepared by

Nokia Solutions and Networks LTE RAN      

Approved by

Date

Page

07.07.2014

95/95

Doc number

Version 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


RL45TD


TDLBTS4.0


NetAct

NetAct8 EP1


OMS

MME

SAE GW

UE

-

-

n/a


RL45TD Feature Description

Recommend Documents