LTE ENB Feature Description SLR 2 4 V2 0 en PDF 1

2600-00FBQLGAP Ver. 2.
LTE eNB (SLR 2.4)
Feature Description
2600-00FBQLGAP Ver. 2.0
COPYRIGHT
This manual is proprietary to SAMSUNG Electronics Co., Ltd. and is protected by copyright.
No information contained herein may be copied, translated, transcribed or duplicated for any commercial
purposes or disclosed to the third party in any form without the prior written consent of SAMSUNG Electronics
Co., Ltd.
TRADEMARKS
Product names mentioned in this manual may be trademarks and/or registered trademarks of their respective
companies.
This manual should be read and used as a guideline for properly installing and operating the product.
All reasonable care has been made to ensure that this document is accurate. If you have any comments on
this manual, please contact our documentation centre at the following address:
Address: Document Center 3rd Floor Jeong-bo-tong-sin-dong. 129, Samsung-ro, Yeongtong-gu, Suwon-si,
Gyeonggi-do, Korea 443-742
Homepage: http://www.samsungdocs.com
©2013 SAMSUNG Electronics Co., Ltd. All rights reserved.

INTRODUCTION
INTRODUCTION
Purpose
The feature description describes the feature of eNB system.
Relevance
This manual applies to the following Samsung network software releases:
Technology Software Release
LTE SLR 2.4
Related Document
Listed below is the entire document set of the product:
Document Describes…
Feature Description features across a Samsung telecommunications

network’s products.
Software Block Description software blocks across a Samsung telecommunications
Command Description commands across a Samsung telecommunications
Printout Message Description Printout messages across a Samsung
telecommunications network’s products.
Network Planning Manual network plans across a Samsung telecommunications
Optimisation Guidelines Manual optimisation guidelines across a Samsung
telecommunications network’s products.
Product Description the product.
Dimensioning Manual Dimensioning in the product.
© SAMSUNG Electronics Co., Ltd. page 3 of 1021

INTRODUCTION
(Continued)
Document Describes…
System Parameter Description system parameters used in the product.

System Counter Description counters in the product.
Installation Manual the installation of the Product
Commissioning and Integration Manual commissioning and integration of the product.
Operation Manual Operation of the product.
Maintenance Manual Maintenance of the product.
Hardware Inspection and Replacement hardware inspection and replacement of the product.
Manual
EMS User Manual the Element Management System (EMS) from
Samsung.
Revision History
VERSION DATE OF ISSUE REMARKS
2.0 02. 2013. - Add SLR 2.4 features

LTE-SW0111, LTE-SW1206, LTE-SW2004, LTE-
SW2006, LTE-SW2011, LTE-SW2012, LTE-SW4210,
LTE-SO0601, LTE-SO0603
1.0 01. 2013. First Version

TABLE OF CONTENTS
TABLE OF CONTENTS
INTRODUCTION 3
Feature Description 10
COM-ET0101, VLAN Tagging .............................................................................................................10
COM-ET0201, Ethernet CoS ..............................................................................................................14
COM-ET0301, Link Aggregation ........................................................................................................17
COM-ET0501, MTU Configuration .....................................................................................................23
COM-ET0601, ARP ..............................................................................................................................27
COM-ET0701, Ethernet OAM EFM (802 3ah) ....................................................................................30
COM-ET0901, Statistics per VLAN ....................................................................................................36
COM-IP0101, IPv4 support.................................................................................................................41
COM-IT0201, ICMP .............................................................................................................................45
COM-IT0301, Ping...............................................................................................................................50
COM-IP0401, SCTP .............................................................................................................................53
COM-IP0402, SCTP multi-homing .....................................................................................................57
COM-IP0501, COM-IP0601 .................................................................................................................63
COM-IP0701, Diffserv .........................................................................................................................69
COM-IP0801, Static IP configuration.................................................................................................77
COM-IP0802, DHCP for IPv4 ..............................................................................................................81
COM-IP1001, ECMP ............................................................................................................................84
COM-IP1101, IP address duplication detection ...............................................................................87
COM-IP1201, Static Routing ..............................................................................................................90
COM-IP1301, IP Fragmentation/Reassembly ...................................................................................94
COM-IP1601, ROHC for VoIP .............................................................................................................98
COM-SE0701, OS hardening ...........................................................................................................105
COM-SY0101, GPS ...........................................................................................................................108
COM-SY0601, Clock Holdover......................................................................................................... 114

TABLE OF CONTENTS
COM-TM0101, Traffic Scheduling ................................................................................................... 117
COM-TM0201, UL Traffic Shaping................................................................................................... 125
COM-TM0301, DSCP to Ethernet CoS mapping ............................................................................ 128
COM-TM0401, COM-TM0403, CAC Considering Transport Link .................................................. 131
COM-TM0402, Load sharing between multiple transport links .................................................... 137
COM-TM0601, Transport QoS ......................................................................................................... 140
LTE-ME0104, 10 MHz Bandwidth .................................................................................................... 144
LTE-ME0105, 15 MHz Bandwidth .................................................................................................... 149
LTE-ME0401, Downlink QSPK, 16QAM, 64QAM Support ............................................................. 154
LTE-ME0402, Uplink QPSK, 16QAM Support ................................................................................. 160
LTE-ME0501, Cell specific Reference Signal ................................................................................. 166
LTE-ME0504, Positioning Reference Signal .................................................................................. 172
LTE-ME0506, Synchronization Signal ............................................................................................ 177
LTE-ME0507, Demodulation Reference Signal .............................................................................. 183
LTE-ME0508, Sounding Reference Signal ..................................................................................... 189
LTE-ME0601, RACH Preamble Type for FDD ................................................................................. 195
LTE-ME0603, Random Access Procedure ..................................................................................... 199
LTE-ME1001, Variable Number of OFDM Symbols for PDCCH .................................................... 207
LTE-ME1002, ME1004, CCE Aggregation for PDCCH.................................................................... 212
LTE-ME1101, PDSCH Resource Allocation .................................................................................... 217
LTE-ME1503, PUSCH Frequency Hopping ..................................................................................... 223
LTE-ME1504, PUCCH Format .......................................................................................................... 230
LTE-ME2019, ME2030, DL SU 2x2 MIMO ........................................................................................ 234
LTE-ME2020, 4Rx Diversity ............................................................................................................. 242
LTE-ME3001, ME3003, ME3004, Power Control ............................................................................. 245
LTE-ME3005, DL Power Allocation ................................................................................................. 252
LTE-ME3101, HARQ in DL and UL .................................................................................................. 258
LTE-ME3201, Basic Link Adaption.................................................................................................. 265
LTE-ME3205, CQI Correction .......................................................................................................... 274
LTE-ME3202, ME3206, ME3207, ME3208, Periodic Channel Status Reporting ........................... 278
LTE-ME3301, ME3302, ME3303, ME3304, Scheduling with QoS Support ................................... 285
LTE-ME3305, Semi-persistent Scheduling ..................................................................................... 293
LTE-ME3306, Frequency Selective Scheduling ............................................................................. 300

TABLE OF CONTENTS
LTE-ME3307, UL Sub frame Bundling ............................................................................................304
LTE-ME3401, Paging DRX................................................................................................................309
LTE-ME3402, Active DRX .................................................................................................................314
LTE-ME4005, IRC ..............................................................................................................................320
LTE-OM5400, RET Support with AISG2.0 .......................................................................................324
LTE-OM9001, Cell Traffic Trace .......................................................................................................330
LTE-OM9002, Subscriber and Equipment Trace ............................................................................341
LTE-OM9003, Call Detail Trace ........................................................................................................351
LTE-OM9004, CSL(Call Summary Log) Report ..............................................................................362
LTE-OM9005, Packet Loss Detection over S1 ................................................................................369
LTE-SO0101, Self Establishment ....................................................................................................373
LTE-SO0201, Intra-LTE ANR ............................................................................................................382
LTE-SO0301, PCI Optimization ........................................................................................................398
LTE-SO0401, RACH optimization ....................................................................................................407
LTE-SO0501, Intra-LTE Mobility Robustness Optimization ..........................................................419
LTE-SO0601, Cell Outage Detection ...............................................................................................430
LTE-SO0603, Sick Cell Detection ....................................................................................................435
LTE-SV0101, IMS based Emergency Call Support.........................................................................441
LTE-SV0103, Emergency Call via CSFB to UTRAN_5UK ..............................................................451
LTE-SV0201, CMAS ..........................................................................................................................463
LTE-SV0202, ETWS ..........................................................................................................................474
LTE-SV0301 A-GNSS (LPP)..............................................................................................................481
LTE-SV0302, Enhanced Cell ID........................................................................................................485
LTE-SV0303, OTDOA ........................................................................................................................491
LTE-SW0101, Support for UE Category 1, 2, 3, and 4....................................................................497
LTE-SW0111, UE Counting per Category .......................................................................................500
LTE-SW0301, MIB & SIB Broadcast (SIB1-4)..................................................................................505
LTE-SW0305, SIB Broadcast (SIB5) ................................................................................................512
LTE-SW0310, SIB Broadcast (SIB10, SIB11) ..................................................................................529
LTE-SW0312, SIB Broadcast (SIB12) ..............................................................................................533
LTE-SW0320, RRC Connection Management_6UK .......................................................................537

TABLE OF CONTENTS
LTE-SW0321, UE Context Management ......................................................................................... 550
LTE-SW0322, LTE-SW0324, E-RAB Setup and Release_7UK ....................................................... 560
LTE-SW0323, RAB modification ..................................................................................................... 570
LTE-SW0501, S1 Interface Management ........................................................................................ 576
LTE-SW0502, NAS Signaling Transport ......................................................................................... 587
LTE-SW0503, MME Overload Control ............................................................................................. 593
LTE-SW0504, SW0505, MME Selection and Load Balancing ....................................................... 601
LTE-SW0506, eNB Configuration Update ....................................................................................... 608
LTE-SW0507, RIM Procedure .......................................................................................................... 612
LTE-SW0521, X2 Interface Management ........................................................................................ 622
LTE-SW1001, Paging ....................................................................................................................... 633
LTE-SW1002, Idle Mobility Support ................................................................................................ 639
LTE-SW1003, Intra-eNB Handover .................................................................................................. 649
LTE-SW1004, S1 Handover ............................................................................................................. 657
LTE-SW1005, X2 Handover ............................................................................................................. 672
LTE-SW1006, Data forwarding ........................................................................................................ 687
LTE-SW1007, Inter-Frequency Handover ....................................................................................... 693
LTE-SW1009, Multi-target Preparation ........................................................................................... 707
LTE-SW1010, Inter-Frequency Redirection .................................................................................... 711
LTE-SW1201, Idle Mobility to UTRAN ............................................................................................. 718
LTE-SW1202, PS Handover to UTRAN ........................................................................................... 724
LTE-SW1203, PS Handover from UTRAN ....................................................................................... 734
LTE-SW1204, Redirection to UTRAN without SI ............................................................................ 746
LTE-SW1205, Redirection to UTRAN with SI ................................................................................. 752
LTE-SW1206, SRVCC to UTRAN ..................................................................................................... 763
LTE-SW1207, CSFB to_UTRAN with_Redirection without SI ....................................................... 771
LTE-SW1208, CSFB to_UTRAN with_Redirection with SI ............................................................ 782
LTE-SW1209, CSFB to_UTRAN with_PS Handover ...................................................................... 792
LTE-SW2001, SW2002, SW5006: Intra-LTE Load Balancing ......................................................... 801
LTE-SW2003, Idle UE Distribution .................................................................................................. 814
LTE- SW2004, Blind Offloading to WCDMA ................................................................................... 820
LTE- SW2006, Load-based Idle UE Distribution ............................................................................ 824
LTE-SW2011, Service based Intra-LTE Handover.......................................................................... 831

TABLE OF CONTENTS
LTE-SW2012, Service based Handover from LTE to UTRAN ........................................................840
LTE-SW2102, eNB Overload control (Adaptive Access Barring) .................................................850
LTE-SW3001, SW3002, SW3003, AM, UM and TM Data Transfer at RLC Layer ...........................857
LTE-SW3011, Header Compression RoHCv1 (RTP, UDP, IP).........................................................866
LTE-SW3051, Integrity Protection: Null/SNOW3G/AES .................................................................874
LTE-SW3052, SW3053, SW3056, Ciphering:Null/SNOW 3G/AES..................................................879
LTE-SW4101, Capacity based Call Admission Control .................................................................884
LTE-SW4102, QoS based Call Admission Control .........................................................................895
LTE-SW4103, Preemption ................................................................................................................907
LTE-SW4104, Cell Barring ...............................................................................................................920
LTE-SW4201, Standard QCI Support ..............................................................................................930
LTE-SW4202, Operator Specific QCIs Support ..............................................................................936
LTE-SW4203, QCI to DSCP Mapping ..............................................................................................942
LTE-SW4204, SW4205, GBR and MBR Support .............................................................................948
LTE-SW4206, UE-AMBR Support ....................................................................................................954
LTE-SW4207, Max 8 Bearers per UE ...............................................................................................958
LTE-SW4208, QCI-based Throughput Differentiation for Non-GBR Bearers ..............................963
LTE-SW4210, SPID-based Throughput Differentiation for Non-GBR UEs ...................................969
LTE-SW5001, Multiple PLMN support .............................................................................................974
LTE-SW5002, Flexible Configuration for Radio Resources Sharing ............................................981
LTE-SW5005, Inter-PLMN Handover ...............................................................................................989
LTE-SW5007, Usage Report per PLMN .........................................................................................1010
ABBREVIATION 1016
A ~ D ................................................................................................................................................1016
E ~ K ................................................................................................................................................1017
L ~ P ................................................................................................................................................1018
Q ~ T ................................................................................................................................................1019
U ~ X ................................................................................................................................................1020

Feature Description
Feature Description
COM-ET0101, VLAN Tagging

Overview
Introduction
This feature supports logical network separation at LAN. (IEEE 802.1Q VLAN)
Benefits
Operator can have virtually multiple LAN with physically single LAN. VLAN can be used
to separate traffic at backhaul network.
Release History
SLR 2.3
Basic or Optional
Basic
Dependency and Limitation

N/A
Reference
IEEE 802.1p, IEEE 802.1q

Feature Description
Feature Description
Operation Scenario
The following shows how to configure the VLAN.
1) Check the current configuration of the VLAN interface using the RTRV-
VLAN_CONF command.
2) Create the VLAN interface using the CRTE-VLAN-CONF command.
3) Change the administrative-state of the VLAN interface using the CHG-VLAN-CONF
command.
4) Delete the VLAN interface using the DLT-VLAN-CONF command.
The BBU should configure the VLAN that to be used for loading using the environment
variables. This VLAN in the environment variables can be set only at the loading point and
is not used after loading. After loading, use the VLAN configured as above.
Multiple VLANs support OAM/signaling/bearer traffic separation, traffic separation per

RAT, and traffic separation per operator during RAN sharing. For details, refer to the
following features.
 COM-IP0601 Multiple-VLAN-Traffic separation: OAM, Signaling, User traffic
 COM-IP0602 Multiple-VLAN-Traffic separation per RAT
 COM-IP0603 Multiple-VLAN-Traffic separation for RAN Sharing
System Specification
IEEE 802.1ad Q-in-Q is not supported.
The maximum number of VLANs that can be configured by the BBU is as follows.
Category Per System Per Interface
4G eNB 16 8

Feature Description
System operation
Commands and Parameters
 Related Command List
Command Description
CHG-VLAN-CONF CHANGE VLAN CONFIGURATION

CRTE-VLAN-CONF CREATE VLAN CONFIGURATION
DLT-VLAN-CONF DELETE VLAN CONFIGURATION
RTRV-VLAN-CONF RETRIEVE VLAN CONFIGURATION
 Related Parameter List
Default
Parameter Description Range
value
DB_INDEX Index for the VLAN interface. 0~MAX_VLAN_PER_ 0
SYS_CDD
VR_ID (Note.1) The virtual routing domain ID. 0~MAX_VRID_PER_ 0
SYS_CDD
ifName The name of the GE interface 0~255 -
connected to the VLAN interface
(e.g. ge_0_0_0).
The VLAN interface is created as a
combination of the GE interface name
and VLAN_ID.
VLAN_ID The ID of the VLAN interface 1~4094 1
(for example, to create ge_0_0_0.100,
VLAN_ID is 100).
ADMINISTRATI The administrative state for determining linkLocked, linkUnlocked
VE_STATE usage of the VLAN interface. linkUnlocked
- linkLocked: The port is disabled.
- linkUnlocked: The port is enabled.
DESCRIPTION The description of the VLAN interfaces 0~255 -
usage.
Note.1) VR_ID is used when the VR function is supported.

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-ET0201, Ethernet CoS

Overview
Introduction
This feature supports for marking Ethernet COS (802.1p). COS value is marked on
Ethernet frame according to DSCP to COS mapping table.
Benefits
Operator can manage QoS at the level of Ethernet.
Release History
SLR 2.3
Basic or Optional
Basic

Supported with VLAN Tagging (COM-ET0101)
Reference
IEEE 802.1p, IEEE 802.1q

Feature Description
Feature Description
The Ethernet COS marking function is performed for a VLAN interface that performs the
VLAN tagging function. It sets the user priority bit in the 802.1Q VLAN header according
to the QoS level. The user priority consists of 3 bits and up to 8 (0-7) priorities can be set.
Following figure is VLAN header format:
Operation Scenario
For Ethernet CoS marking, the following setup procedure is required.
1) Grow a VLAN interface in a link that is connected to outside of the system.

For details, refer to VLAN Tagging (COM-ET0101) FDD.
2) Set the CoS values for DSCP marking by configuring DSCP to Ethernet CoS mapping.
For more information, refer to the DSCP to Ethernet CoS mapping (COM-TM0301)
FDD.
N/A

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-ET0301, Link Aggregation

Overview
Introduction
This feature supports to aggregate multiple Ethernet links as one logical link. It can provide
enhanced reliability and higher bandwidth of Ethernet links.
Benefits
Operator can aggregate multiple Ethernet links to deliver more bandwidth and improve the
transmission reliability.
Release History
SLR 2.3
Basic or Optional
Basic

N/A
Reference
IEEE 802.3ad

Feature Description
Feature Description
The link aggregation function combines multiple physical links to allow routing
configuration and operation with a single logical link. This will result in increased link
bandwidth, improved availability and load sharing between links.
The link aggregation is supported in the following two ways.

 Static link aggregation: This method configures a link aggregation separately and
manually to both devices to be connected.
 Dynamic link aggregation: Automatically configures a link aggregation using the
LACP standard protocol defined in IEEE 802.3ad. If negotiation through LACP (Link
Aggregation Control Protocol) frame exchange with the peer is successful, the link
aggregation function operates normally. Compared with the static link aggregation, the
dynamic link aggregation function has advantages such as rapid automatic
configuration and rapid reconfiguration.
Operation Scenario
BBU supports the static link aggregation only. The following shows how to configure a
static link aggregation.
1) Check the current configuration of the LAG interface using the RTRV-LAG-CONF
command.
2) Create the LAG interface using the CRTE-LAG-CONF command.
 The LAG_ID indicates an ID of the LAG interface.
3) Set the member link of the LAG using the CHG-ELINK-CONF command.
 The PORT_ID is the index of the external link to set as a member.
 Use the LAG_ID for the LAG interface created in the above.
 Other parameters are not relevant to the member configuration.
Change state of the LAG interface using the CHG-LAG-CONF command.
The following shows how to delete the static link aggregation.
1) Delete a member link of the LAG using the CHG-ELINK-CONF command.

 The PORT_ID indicates an index of an external link being configured as a member.
 Set the LAG_ID to 0.
 Other parameters are not relevant to the member deletion.
2) Delete the LAG interface using the DLT-LAG-CONF command.
Enter DB_INDEX of the LAG interface to be deleted in the DB_INDEX.

Feature Description
The following is features of the link aggregation function.
 An IP allocation to a physical link set as a member of a link aggregation is restricted
and it cannot be used as a separate link.
 The change of system-priority, port priority and timeout is not supported.
 A member link can be added or deleted during configuration and operation of a link
aggregation.
 Only supports the static mode.
 Can set up to 2 link aggregation interfaces.
 ID of link aggregation interface can be set 1 to 2.
 Up to 4 member links can be set for a link aggregation interface.

Feature Description
System operation
Configure Link Aggregation Group Interface
Command Description
CRTE-LAG-CONF CREATE LAG CONFIGURATION

DLT-LAG-CONF DELETE LAG CONFIGURATION
CHG-LAG-CONF CHANGE LAG CONFIGURATION
RTRV-LAG-CONF RETRIEVE LAG CONFIGURATION
Parameter Description Range Default value
DB_INDEX dbindex 0~1 0

ADMINISTRATIVE_ The administrative state for determining linkUnlocked linkUnlocked
STATE usage of the LAG interface. linkLocked
LAG_ID This field indicates Link aggregation 1~2 1
Interface ID
DESCRIPTION The description of the LAG interface 0~255 -
usage.
Configure the Members of Link Aggregation Group

Command Description
CHG-ELINK-CONF CHANGE EXTERNAL LINK CONFIGURATION

RTRV-ELINK-CONF RETRIEVE EXTERNAL LINK CONFIGURATION

Feature Description
PORT_ID The port ID of the external link. 0~5 0

VR_ID (Note.1) The virtual routing domain ID. 0~6 0
STATUS The EQUIP information for the backhaul N_EQUIP, N_EQUIP
interface port. EQUIP
- N_EQUIP: Indicates that the unit is
unmounted on the PLD and unavailable in
the system.
- EQUIP: Indicates that the unit is mounted
on the PLD and available in the system.
ADMINISTRATIVE_ The administrative state. linkLocked, linkUnlocked
STATE - linkLocked: The port is disabled. linkUnlocked
CONNECT_TYPE The connect type of the external link. Backhaul, Backhaul
UDE
SPEED_DUPLEX The speed and duplex of the backhaul AUTO, AUTO
port. S10_HALF,
- AUTO: The speed is determined by auto- S10_FULL,
negotiation. S100_HALF,
- S10_HALF: A speed of 10 Mbps, half- S100_FULL,
duplex mode. S1000_FULL
- S10_FULL: A speed 10 Mbps, full-duplex
mode.
- S100_HALF: A speed of 100 Mbps, half-
duplex mode.
- S100_FULL: A speed of 100 Mbps, full-
duplex mode.
duplex mode.
MTU The maximum transmission unit of the 68~8270 1500
external link.
FLOW_CONTROL Whether flow control of the external link is False, True False
enabled.
- False: Flow control is disabled.
- True: Flow control is enabled.
LAG_ID The link aggregation ID (0 means it is not 0~2 0
link aggregation).
DESCRIPTION Describes the use of the external link. 0~255 -
Note.1) The VR_ID is used when the VR function is used.

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-ET0501, MTU Configuration

Overview
Introduction
This features supports Maximum Transmission Unit (MTU) size configuration at Ethernet
interface. It also supports jumbo frames with MTU size exceeding 1518 bytes.
Benefits
Operator can configure MTU depending on transport network condition.
Release History
SLR 2.3
Basic or Optional
Basic

N/A
Reference
IETF RFC 791, RFC 894

Feature Description
Feature Description
Maximum Transmission Unit (MTU) is the maximum payload size that can be transmitted
from the Ethernet interface. If packets with the size exceeding the MTU size are
transmitted, fragmentation will be generated and the receiving end will perform re-
assembly.
Operation Scenario
Ethernet interface’s MTU size can be changed as follows.
1) Check the current Ethernet interface settings using the RTRV-ELINK-CONF command.
2) If the operator selected the interface to change the MTU value, the operator can set the
MTU value in the CHG-ELINK-CONF. The results displayed in 1) should be entered
as inputs for all other parameters.
3) Check whether the changes are properly reflected using the RTRV-ELINK-CONF
command.
MTU configuration range: 68-8270

Feature Description
System operation
Command Description
CHG-ELINK-CONF CHANGE EXTERNAL LINK CONFIGURATION

RTRV-ELINK-CONF RETRIEVE EXTERNAL LINK CONFIGURATION
PORT_ID The port ID of the external link. 0~5 0

VR_ID The virtual routing domain ID. 0~6 0
(Note.1)
STATUS The EQUIP information for the backhaul N_EQUIP, EQUIP N_EQUIP
interface port.
- N_EQUIP: Indicates that the unit is
unmounted on the PLD and unavailable in
the system.
- EQUIP: Indicates that the unit is mounted
on the PLD and available in the system.
ADMINISTRA The administrative state. linkLocked, linkUnlocked
TIVE_STATE - linkLocked: The port is disabled. linkUnlocked
CONNECT_ The connect type of the external link. Backhaul, UDE Backhaul
TYPE
SPEED_DUP The speed and duplex of the backhaul port. AUTO, S10_HALF, AUTO
LEX - AUTO: The speed is determined by auto- S10_FULL,
negotiation. S100_HALF,
- S10_HALF: A speed of 10 Mbps, half- S100_FULL,
duplex mode. S1000_FULL
- S10_FULL: A speed 10 Mbps, full-duplex
mode.
- S100_HALF: A speed of 100 Mbps, half-
duplex mode.
duplex mode.
duplex mode.

Feature Description
(Continued)
MTU The maximum transmission unit of the 68~8270 1500

external link.
FLOW_CON Whether flow control of the external link is False, True False
TROL enabled.
- False: Flow control is disabled.
- True: Flow control is enabled.
LAG_ID The link aggregation ID (0 means it is not 0~2 0
link aggregation).
DESCRIPTI Describes the use of the external link. 0~255 -
ON
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-ET0601, ARP
Overview
Introduction
ARP (Address Resolution Protocol) is a network protocol for resolution of network layer
address into link layer addresses. When IP packet is transmitted, ARP is used to search the
corresponding MAC address from destination IP address.
Benefits
N/A
Release History
SLR 2.3
Basic or Optional
Basic

N/A
Reference
IETF RFC 826

Feature Description
Feature Description
The transmitter must know the MAC address of the destination to transmit IP packets in the
Ethernet Backhaul network. The transmitter uses the Address Resolution Protocol (ARP)
function to obtain the MAC address corresponding to the destination IP address.
Operation Scenario
When the transmitter transmits IP packets, the ARP table should be checked to obtain the
MAC address of the destination. If the ARP table inthat the transmitter mesage does not
have the MAC address, then transmitterit has to broadcast ARP requests to all the hosts.
Here if a host has the same IP address as the ARP packet’s destination IP address as the
transmitter’s IP address, then the host replies to the transmitter with its MAC address via
unicast. A transmitter registers the MAC address in its ARP table. The below figure
describes the ARP procedures.
Following figure is ARP procedure:
 The ARP aging time is set to 60 s by default.
 The ARP table size is set to 512 by default.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-ET0701, Ethernet OAM EFM (802 3ah)

Overview
Introduction
This feature is link level OAM. It operates on point-to-point link, not propagated beyond a
single hop. As a Layer 2 protocol, Ethernet O&M can report the status of the network at the
data link layer. Thus, the network is monitored and managed more effectively.
Benefits
Operator can monitor the status of Ethernet link.
Release History
SLR 2.3
Basic or Optional
Optional

N/A
Reference
IEEE 802.3ah

Feature Description
Feature Description
The Ethernet OAM EFM function is defined in IEEE 802.3ah, and it is used to monitor the
status of a network and to detect a link fault on a point-to-point link. The EFM OAM layer
belongs to the data link layer among OSI layers and it is defined between MAC and LLC
sub-layer as shown in the below figure.
The EFM has the following functions:

 Discovery
 Link Monitoring
 Remote Fault Detection
 Remote Loopback
Operation Scenario
The EFM function can be configured/retrieved using the CHG-ETHOAM-CONF/RTRV-
ETHOAM-CONF command.
 ETH_OAM_ADMIN_STATE: Configures enable/disable of the EFM function.
 ETH_OAM_LAYER_STATE: Configures operation mode of EFM function.
(Active/Passive)
The operation and configuration of each EFM function are as follows:
Discovery
The discovery function checks whether the EFM function of a remote DTE is working and
also the scope of provided EFM function by using the information OAMPDU.
If there is a link loss or the OAMPDU is not received within the time set in the
ETH_OAM_CLIENT_TIMEOUT parameter after the BBU completes loading, the
discovery function is initialized by assuming the connection to a remote station is lost.
In active mode, the Discovery function is executed again. In passive mode, it waits for the
information OAMPDU of the target. The BBU is basically working in passive mode, but it
can be set to active mode, if necessary.

Feature Description
Link Monitoring
The link monitoring function detects a link fault and notifies the fault to a remote DTM.
A local DTE detects a link fault through ‘Errored Frame Period Event’.
‘Errored Frame Period Event’ is generated when the number of errored frames among the
ERR_FRAME_PERIOD_WINDOW x 1,000 frames is higher than the threshold value.
Below is the procedure for configuring the threshold.
 ERR_FRAME_PERIOD_THR_HI: If the number of errored frames is greater than this,
the ‘Threshold high cross event’ is generated.
 ERR_FRAME_PERIOD_THR_LO: If the number of erroneous frames is greater than
this but less than ERR_FRAME_PERIOD_THR_HI, the ‘Threshold low cross event’
is generated.
When a link fault occurs, a local DTE notifies the fault to a remote DTF using the Event
Notification OAMPDU
Remote Fault Detection

When a fault occurs at an external link, the BBU notifies the event to a remote DTE and
LSM.
Remote Loopback
The remote loopback diagnoses the validity of a path between the targets which are directly
connected. It performs loopback diagnosis for the 1hop section that is directly connected to
a backhaul link and also can measure the performance such as delay or jitter, etc.
The TEST-ETH-LB command is used to perform the loopback test.
The loopback function can be triggered only in active mode. In passive mode, only reply
for the loopback request from a remote DTE is possible. While the remote loopback
function is executed, the backhaul link communication is temporarily stopped and only the
EFM packets can be transmitted/received. When the loopback function is executed in
passive mode, a local DTE re-transmits all the received packets other than OAMPDU
through a receiving link and also periodically transmits its own OAMPDU.
The features of the EFM function are as follows:
 Only the Errored Frame Period Event function is provided among the link monitoring
function.
 When the remote loopback is executed, the backhaul link is disconnected.
Therefore, the system admin status must be ‘locked’ to execute the command.

Feature Description
System operation
EFM parameter configuration
Command Description
RTRV-ETHOAM-CONF Retrieves the EFM configuration information.

CHG-ETHOAM-CONF Changes the EFM configuration information.
PORT_ID Port ID of an external link that 0~MAX_PORT_PER_ 0

will execute Ethernet loopback UNIT_CDD
ETH_OAM_ Administrator status of EFM. Enable, Disable Disable
ADMIN_STATE Enter Enable or Disable for
AdminState.
- Enable: The 802.3ah function
is enabled.
- Disable: The 802.3ah function
is disabled.
ETH_OAM_ Layer status of the EFM. Active, Passive Passive
LAYER_STATE - Active: Discovery is performed
through the external link and
the Ethernet loopback
command can also be
executed.
- Passive: Cannot trigger the
packets directly. It only
responds to the EFM packets
transmitted through the
external port.
ETH_OAM_ Maximum number of OAMPDUs 1~10 10
PDU_MAX_ that can be transmitted from the
RATE OAM layer for one second.
OAMPDUs that exceed the
maximum value will be dropped.
ETH_OAM_ Minimum number of OAMPDUs 1~10 1
PDU_MIN_ that can be transmitted from the
RATE OAM layer for one second.

Feature Description
(Continued)
ETH_OAM_ Timeout that determines 2~30 5

CLIENT_ whether the connection to the
TIMEOUT target is lost If an OAMPDU is
not received from the target
within a specified time, the
connection is determined to be
lost.
ERR_FRAME_ The frame window size for a link 0~65535 1000
PERIOD_ fault in the OAM layer, which is
WINDOW calculated by multiplying this
parameter by 1000.
ERR_FRAME_ Upper threshold of an errored 0~65535 0
PERIOD_THR_ frame If this is ‘0’, the frame
HI period theshold high error is
disabled. For enable, enter 1-
65535.
ERR_FRAME_ Lower threshold of an errored 0~65535 1
PERIOD_THR_ frame This value must be less
LO than the upper threshold when
ErrFramePeriodThrHi is Enable.
Remote Loopback test configuration

Command Description
TEST-ETH-LB Runs the loopback test for the EFM function.
PORT_ID Port ID of a backhaul port that 0~MAX_PORT_PER_UNIT_ 0

will execute Ethernet Loopback CDD
DURATION The run time of Ethernet 1~10 1
loopback test.

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-ET0901, Statistics per VLAN

Overview
Introduction
This feature provides statistics per VLAN interface. With RAN Sharing feature, it allows
that operator can monitor the backhaul data usages per MOCN operator.
Benefits
Operator can monitor the backhaul data usages per VLAN interface.
Release History
SLR 2.4
Basic or Optional
Optional

 Supported with VLAN tagging (COM-ET0101)
 Supported with Virtual Routing and Forwarding (VRF)
 Traffic separation for RAN Sharing (COM-IP0604)
Reference
N/A

Feature Description
Feature Description
Multiple VLAN’s for a physical port or Link Aggregation Group (LAG) can be set, and the
following statistics from each VLAN can be collected.
 Tx/Rx throughput
 Number of Tx/Rx byte
 Number of Tx/Rx packet
 Number of Tx/Rx packet drop
For more details on statistics, see chapter 3.2.
Operation Scenario
The VLAN statistics function is used to classify interface statistics of each operator when
the RAN sharing function is supported. The RAN sharing function can be used to share the
transport resource among operators or use them separately. To separate the transport
resource among operators, networks can be separated using multiple VLAN. For more
details, refer to the FDD of Multiple-VLAN-Traffic separation for RAN Sharing (COM-
IP0603).
The VLAN configuration contains index to distinguish operators. Each NE includes this
index on the VLAN statistics when transmitting statistics information to the EMS.
The EMS uses it to extract the VLAN information and deliver it when interconnecting with
upper OSS of each operator. It can be illustrated as follows.

Feature Description
For more details on how to set the VLAN and operate the RAN sharing, refer to the
following FDD documents.
 VLAN tagging (COM-ET0101)
 Multiple-VLAN-Traffic separation for RAN Sharing (COM-IP0603)
N/A

Feature Description
System operation
N/A
Related Counters
 Related Counter List
Family Name Counter Name Description & Impact
STAT_VLAN_ VLAN_PORT_RX_THROUGHPUT Average incoming throughput per VLAN

PORT interface over a periodic time interval
VLAN_PORT_RX_BYTE Total Octet number of packet received per
VLAN interface over a periodic time interval
VLAN_PORT_RX_BYTE_COUNT The number of calling incoming throughput
increment over a periodic time interval
VLAN_PORT_RX_PACKET Total number of packets received per VLAN
interface over a periodic time interval
VLAN_PORT_RX_DROP Number of Rx packets dropped per VLAN
VLAN_PORT_TX_THROUGHPUT Average outgoing throughput per VLAN
VLAN_PORT_TX_BYTE Total Octet number of packets sent per
VLAN interface over a periodic time interval
VLAN_PORT_TX_BYTE_COUNT The number of calling incoming throughput
increment over a periodic time interval
VLAN_PORT_TX_PACKET Total number of packets sent per VLAN
VLAN_PORT_TX_DROP Number of Tx packets dropped per VLAN
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A

Feature Description
Related Call Faults

N/A

Feature Description
COM-IP0101, IPv4 support

Overview
Introduction
IPv4 support.
Benefits
Operator can have IPv4 transport option for all interfaces.
Release History
SLR2.3
Basic or Optional
Basic

N/A
Reference
RFC 791

Feature Description
Feature Description
The IPv4 is a protocol for data exchange on a packet network. The IPv4 address consists of
total 32 bits and it is divided into four parts. Each part is expressed in 3 digits, i.e. 0-255.
The configuration of an IPv4 address is as follows:
 IPv4 Address Class
CLASS Range
A Class 1.0.0.1~126.255.255.254
B Class 127.1.0.1~191.255.255.254
C Class 192.0.1.1~223.255.254.254
D Class 224.0.0.0~239.255.255.255
E Class 240.0.0.0~254.255.255.254
 Class A: Class A is the highest class that has the IP address of 0.0.0.0-127.0.0.0.
The second, third, and fourth 3-digits are the IP addresses that the Class A can allocate
to network users.
 Class B: Class B is the second highest class. In its IP configuration, the first 3-digit is a
number between 127 and 191. The second 3-digit indicates a network that the Class B
can connect to.
 Class C: Class C is the lowest class. In its IP configuration, the first 3-digit is a number
between 192 and 223. The second and third 3-digit indicates a network that the Class
C can connect to. The IP that the C class can allocates is the fourth 3-digit, i.e. 254
addresses. (1 is reserved.)
In an IPv4 address, the following addresses are reserved for special use.
 Reserved IP address blocks
IP Address Description
0.0.0.0/8 Current network

10.0.0.0/8 Private network
127.0.0.0/8 Loopback
169.254.0.0/16 Link local
192.0.2.0/24 Used in documentation and examples
192.88.99.0/24 IPv6 to IPv4 relay anycast
198.18.0.0/15 Network benchmark tests
224.0.0.0/4 Multicast
240.0.0.0/4 Reserved

Feature Description
Operation Scenario
For more details on how to configure an IP for each system, refer to the FDD document for
Static IP Configuration (COM-IP-0801).
N/A

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IT0201, ICMP
Overview
Introduction
Internet Control Message Protocol (ICMP) is a network protocol used for diagnostic, test,
and error reporting functions in IP network.
Benefits
N/A
Release History
SLR 2.3
Basic or Optional
Basic

N/A
Reference
IETF RFC 792, RFC 950, RFC 1122

Feature Description
Feature Description
Internet Control Message Protocol (ICMP) is an error reporting mechanism on the IP layer.
IP operates as connectionless, so it is very hard to find out whether the transmitted data has
successfully reached the destination. It provides a method that the router detected ICMP
errors reports errors to the origin. ICMP can be used to exchange the network status/
communication errors between two IP hosts.
ICMP’s packet format is shown as follows.
 TYPE field-8 bits, it is used to identify a message.

 CODE field-8 bits, it provides additional information about message types.
 CHECKSUM field-Consist of 16 bits and provides a checksum.
The ICMP provides the following functions.
Type Name Code Code-Name
0 Echo Reply 0 Ping command is a type of response message to an ICMP

echo request.
3 Destination 0 Network Unreachable
Unreachable 1 Host Unreachable
2 Protocol Unreachable
3 Port Unreachable
4 Fragmentation Needed and Don’t Fragment was Set
5 Source Route Failed
6 Destination Network Unknown
7 Destination Host Unknown
8 Source Host Isolated
9 Communication with Destination Network is Administratively
Prohibited (Prohibited communication with the destination
network by the administrator.)
10 Communication with Destination Host is Administratively
Prohibited (Administrator prohibits the communication with
destination host)

Feature Description
(Continued)
3 Destination 11 Destination Network Unreachable for Type of Service

Unreachable (Routing to the destination network fails and the router will
transmit it, since the TOS value does not match the routing
table.)
12 Destination Host Unreachable for Type of Service
13 Communication Administratively Prohibited
(This message is transmitted when the IP datagram is
blocked by an IP router or firewall filtering policy. Most of
firewalls are set not to transmit this message when a filtering
policy blocks it.)
14 Host Precedence Violation
15 Precedence cutoff in effect
4 Source 0 No Code
Quench (The transmitter received this message, and lengthens the
transmission intervals because the message means that
traffic congestion has occurred somewhere in the line.)
5 Redirect 0 Redirect Datagram for the Network (or subnet)
(If it is detected that the IP router is using a route not suitable
for the node on the transmitter side, it will transmit an ICMP
reassignment message to the node, and so that the node on
the transmitter side can configure a better route.)
1 Redirect Datagram for the Host
2 Redirect Datagram for the Type of Service and Network
3 Redirect Datagram for the Type of Service and Host
6 Alternate Host 0 Alternate Address for Host
Address
8 Echo Request 0 No Code
9 Router 0 Normal router advertisement
Advertisement (It provides the function that routers connected to the
network report to their own network on their existence.)
10 Router 0 No Code
Selection (This message is used by hosts to detect the existences of
routers.)
11 Time 0 Time to Live exceeded in Transit
Exceeded (When the TTL value reaches 0, the packet will be
discarded. At this moment, the IP router transmits a time
expiration message to the transmitter to notify of the fact that
the packet is discarded.)
1 Fragment Reassembly Time Exceeded

Feature Description
(Continued)
12 Parameter 0 Pointer indicates the error

Problem (While the router or the receiver’s host is processing the IP
datagram if failure occurs due to the missing information in
the IP header, this error message is used to express an error
message that another ICMP error message cannot express.)
1 Missing a Required Option
2 Bad Length
13 Timestamp 0 No Code
Request (Message transmitted by the node on transmitter to learn
about the current time of the node on the opposite side.
This message contains the information about the data
transmitting time by the transmitter, the data receiving time
by the opposite node, and the time right before the opposite
node transmits a response. The transmitter can use this
information to calculate the network passage time.)
14 Timestamp 0 No Code
Reply (Response message for a timestamp request)
15 Information 0 No Code
Request (Message transmitted to figure out its own IP address. RARP
is currently used to determine the address)
16 Information 0 No Code
Reply (Response message of Information Request)
17 Address Mask 0 No Code
Request (Message transmitted to learn about subnet mask of their
equipment.)
18 Address Mask 0 No Code
Reply (Response message of Address Mask Request)
Operation Scenario
No additional setting is required for the ICMP function.
All the general ICMP functions are supported. But the destination unreachable function is
not supported due to the risk of hackings.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IT0301, Ping
Overview
Introduction
Ping is a network protocol used to check the reachability of a host on IP network and
measure the round-trip time between source and destination hosts.
Benefits
Operator can measure network reachability and latency.
Release History
SLR 2.3
Basic or Optional
Basic

N/A
Reference
IETF RFC 792

Feature Description
Feature Description
Ping is a basic internet protocol that is used to check whether the IP network to the
destination host or router is working properly. No reply to a ping to a specific host means
IP communication to the host is currently unavailable. Ping uses the ICMP echo request
messages. When the transmitter transmits the ICMP echo request message to the receiver,
the recipient system replies with the ICMP echo response message. The transmitting side
can determine if the network is working properly by checking whether the ICMP echo
response was received, and can also calculate the round-trip time.
Following figure is Ping procedure:
Operation Scenario
N/A
N/A

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IP0401, SCTP
Overview
Introduction
Stream Control Transmission Protocol (SCTP) is the transport protocol designed to
transport signaling messages over IP networks.
Benefits
Operator can deliver signaling message more reliably.
Release History
SLR 2.3
Basic or Optional
Basic

N/A
Reference
RFC4960

Feature Description
Feature Description
SCTP (Stream Control Transmission Protocol) is a message-oriented protocol link UDP
and ensures reliable and in-sequence transport of messages with congestion control like
TCP.
Operation Scenario
Samsung eNB uses SCTP protocol to transport signaling messages over S1-MME and X2-
CP interface.
Operator can configure SCTP parameters for S1-MME and X2-CP using the command
‘CHG-SCTP-PARA’ and ‘RTRV-SCTP-PARA’.
N/A

Feature Description
System operation
Command Description
RTRV-SCTP-PARA RETRIEVE SCTP CONFIGURATION

CHG-SCTP-PARA CHANGE SCTP CONFIGURATION
dbIndex The index for accessing the information. 0~0 0

mmeFailoverTimer The timer to maintain the call connected to 1~30 10
the MME if the SCTP returns to normal
within a specified time (mmeFailoverTimer)
after the MME SCTP is disconnected in
seconds.
heartBeatInterval The transmission interval of the HeartBeat 100~60000 1500
message to be sent to verify the normality
of the SCTP Link in milliseconds.
numPathReTx The number of times to re-send heartbeat 1~100 5
messages in order to check whether the
SCTP link is normal. The SCTP link is
disconnected if responses to the
heartbeats are not received during
specified (numPathReTx) attempts.
rtoInitial The threshold used to calculate the SCTP 100~60000 1000
round-trip time (RTT). It is an initial value of
Retransmission Time-Out used before the
RTT by packet transmission is measured.
rtoMin The minimum value of Retransmission 100~60000 1000
Time-Out used to calculate the SCTP RTT.
rtoMax The maximum value of Retransmission 100~60000 1400
Time-Out used to calculate the SCTP RTT.
connectInterval The timer to establish connections 1~10 4
periodically when the SCTP link is not
currently established while the peer node is
EQUIP in PLD in seconds.

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IP0402, SCTP multi-homing

Overview
Introduction
SCTP (Stream Control Transmission Protocol) is designed to support network-level fault
tolerance through multi-homing. SCTP can setup multiple paths using one or more IP
address at each endpoint and when primary path fails, SCTP tries to send the data through
alternative path if exists.
Benefits
Operator can have network-level redundancy for signaling traffic.
Release History
SLR 2.3
Basic or Optional
Basic

 The remote peer should supports SCTP multi-homing.
 Each peer can have up to 2 IP addresses for SCTP multi-homing.
 SCTP multi-homing with IPv6 address will be available in later software release.
Reference
RFC4960

Feature Description
Feature Description
The following figure shows SCTP multi-homing architecture. Samsung eNB sets up one
primary path and one secondary path based on the configuration parameters (eNB’s
primary IP address and secondary IP address, MME’s primary IP address and secondary IP
address, neighbor eNBs’ primary IP address and secondary IP address). Each endpoint can
have one IP address but it is not possible that both endpoints have one IP address.
Primary path is used to transfer the data and secondary path operates as an idle state.
Secondary path is monitored it’s availability through periodic heartbeat chunk.
When primary path fails, SCTP uses secondary path to transfer the data according to the
standardized SCTP operation.
Following figure is SCTP multi-homing architecture:
Operation Scenario
Primary IP address and secondary IP address of eNB for SCTP multi-homing is configured
in the system parameter SystemSigIP.
Primary IP address and secondary IP address of MME and neighbor eNBs for SCTP multi-
homing is configured in the system parameter ProxyMMEConf and ExternalEnbConf.
N/A

Feature Description
System operation
eNB IP Configuration
Refer to the following FDD for eNB IP Configuration
 Static IP Configuration (COM-IP0801)
 Multiple-VLAN-Traffic separation: OAM, Signaling, User traffic (COM-IP0601)
MME IP Configuration
Command Description
CHG-MME-CONF CHANGE MME IP CONFIGURATION

RTRV-MME-CONF RETRIEVE MME IP CONFIGURATION
mmeIndex The index used to access the information. 0~15 0

Since there are a total of 16 MMEs that can be
connected to an eNB, the index range is 0 to 15.
Status The EQUIP status information on the MME. N_EQUIP, N_EQUIP
- N_EQUIP: The MME to connect does not exist EQUIP
- EQUIP: The MME to connect exists.
activeState The state information on the specified MME in Active, Active
operation. Of the MMEs for which the S1 Setup Inactive
is established, if there is an undesired MME,
this parameter value must be changed to
Inactive. The default is active. If the STATUS
parameter is set to Equip, it is better not to
change this parameter value to inactive.
- Active: MME (S1 assigned) is used.
- Inactive: MME (S1 assigned) is not used.
ipVer The IP address version of the MME. Either IPv4 IPv4, IPv6 IPv4
or IPv6 is assigned.
mmeIPv4 Information on the IPV4 address of the MME. 0~255 ‘0.0.0.0’
This parameter value is valid only if the IP_VER
parameter is set to IPv4. It is not used if the
IP_VER parameter is set to IPv6.

Feature Description
(Continued)
mmeIPv6[16] Information on the IPV6 address of the eNB. 0~255 ‘0:0:0:0:0:0:0:0’

administrativeS The status of the MME link. locked, unlocked
tate - locked: A state where active calls connected to unlocked,
the MME are all dropped, and new call shutting
connections are not possible. down
- unlocked: Connection to the MME is normal.
- shutting down: A state where active calls
connected to the MME are maintained, but
new call connections are not possible.
secondaryMme The secondary IP address of the IPv4 type set 0~255 ‘0.0.0.0’
IPv4 in the MME node to support the SCTP Multi
Homing function. It is valid only if the IP_VER
parameter is set to IPv4.
secondaryMme The secondary IP address of the IPv6 type set 0~255 ‘0:0:0:0:0:0:0:0’
IPv6 in the MME node to support the SCTP Multi
Homing function. It is valid only if the IP_VER
mmeMcc[4] The PLMN information (MCC) that represents 000~999 Customer’s
the MME. It is a three-digit number with each Primary PLMN
digit being from 0 to 9. ID
mmeMnc[4] The PLMN information (MNC) that represents 00f~999 Customer’s
the MME. It is a three-digit or two-digit number Primary PLMN
with each digit being from 0 to 9. ID
Neighbor eNB IP Configuration

Command Description
CHG-NBR-ENB CHANGE NEIGHBIR ENB IP CONFIGURATION

RTRV-NBR-ENB RETRIEVE NEIGHBIR ENB IP CONFIGURATION
CRTE-NBR-ENB CREATE NEIGHBIR ENB IP CONFIGURATION
DLT-NBR-ENB DELETE NEIGHBIR ENB IP CONFIGURATION

Feature Description

nbrEnbIndex Index of the neighboring eNB. The value 0~255 0

entered when registering the neighboring
eNB is used.
Status The validity of the neighboring eNB N_EQUIP, N_EQUIP
information. EQUIP
- N_EQUIP: Invalid.
- EQUIP: Valid.
noX2 Whether to make X2 connection to the False, True False
neighboring eNB.
- False: X2 connection with the neighboring
eNB is made.
- True: X2 connection to the neighboring
eNB is not made.
noHO Whether to perform handover to the False, True False
neighboring eNB.
- False: Handover to the neighboring eNB is
performed.
- True: Handover to the neighboring eNB is
not performed.
enbId The eNB ID represents the neighboring 0x0~0xFFFFFFF 0
eNB.
If the enbType value is macro eNB, 20 bit of
the value is eNB ID. If the enbType value is
home eNB, 28 bit of the value is eNB ID.
enbType eNB type of the neighboring eNB. ci_Macro_eNB, ci_Macro_eNB
- ci_Macro_eNB: Indicates the macro eNB. ci_Home_eNB
- ci_Home_eNB: Indicates the home eNB.
enbMcc[4] The PLMN information (MCC) that 0~0 ‘DIGIT_MCC’
represents the neighboring eNB. It is a
three-digit number with each digit being from
0 to 9.
enbMnc[4] The PLMN information (MNC) that 0~0 ‘DIGIT_MNC’
represents the neighboring eNB. It is a
three-digit or two-digit number with each
digit being from 0 to 9.
ipVer The IP version, which is the IP address of IPv4, IPv6 IPv4
the neighboring eNB.
nbrEnbIPv4 Enter the IP address of the neighboring eNB 0~255 ‘0.0.0.0’
in the IP version 4 format.
nbrEnbIPv6 Enter the IP address of the neighboring eNB 0~255 ‘0:0:0:0:0:0:0:0’
in the IP version 6 format.

Feature Description
(Continued)
secondaryNbr Enter the secondary IP address of the 0~255 ‘0.0.0.0’

EnbIPv4 neighboring eNB in the IP version 4 format.
secondaryNbr Enter the secondary IP address of the 0~255 ‘0:0:0:0:0:0:0:0’
EnbIPv6 neighboring eNB in the IP version 6 format.
administrative This parameter defines Neighbor eNB Link locked, unlocked, unlocked
State Status shutting down
ownerType This parameter defines how NRT is InitialNRT, CreatedByUser
updated. This filed can be classfied Initial ANRbyServer, Command
NRT/ANR by Server/ ANR by UE/Created ANRbyUE,
by User Command/CreatedByUserUI. CreatedbyUserC
ommand,
CreatedByUserUI
remoteFlag This parameter defines the target eNB is False, True False
managed local EMS or other EMS
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IP0501, COM-IP0601
Overview
Introduction
This feature supports traffic separation between OAM traffic, signaling traffic and bearer
traffic.
Benefits
Operator can separate OAM, Signaling, and User traffic into different VLANs.
Release History
SLR2.3
Basic or Optional
Optional

Supported with VLAN tagging (COM-ET0101)
Reference
N/A

Feature Description
Feature Description
The BBU supports a flexible configuration for an IP that is used for OAM, signaling and
user traffic. In other words, a single IP can be commonly used for OAM, signaling, or user
traffic or each different IP also can be used. If different IPs are used, separation between
traffics is supported using multiple VLANs.
Operation Scenario
IP address for OAM, signaling or user traffic of the BBU can be set as follows:
1) Configure multiple VLAN. No multiple VLAN configuration is required for the single
IP operation. For more information about VLAN configuration, refer to the FDD for
VLAN Tagging (COM-ET0101).
2) Configure an IP per VLAN interface. Attributes can be configured for each IP and the
attributes that an IP can have are listed in the below table. The purpose of an IP is
determined based on the configured attribute and one IP can have multiple attributes.
If a single IP is used, the attributes of OAM, signaling, and user traffic are configured
on the single IP. For more information about IP configuration, refer to the FDD for
Static IP configuration (COM-IP0801).
 IP Attributes
Category Attribute Description
OAM oam OAM traffic

Signaling lteSignalS1 LTE S1 Signaling traffic
lteSignalX2 LTE X2 Signaling traffic
Bearer lteBearer LTE Bearer traffic
3) Based on the IP attribute information of PLDIPAddrConf that is configured in 2), an IP

for OAM, signaling, and user traffic that will be used in the BBU is selected and the
selected IP is updated to related PLD to enable call processing and OAM application
to be able to refer to it. Each PLD is shown below.
 List of PLDs to refer to per IP type
Category IP type PLD
OAM OAM traffic PLDSystemOamIp

LTE S1 Signaling traffic PLDSystemSigIp
Signaling
LTE X2 Signaling traffic PLDSystemSigIp
Bearer LTE Bearer traffic PLDEthInfo

Feature Description
4) If there are many IPs that have the same attributes in the PLDIPAddrConf, select an IP
for OAM, signaling, and user traffic based on the following criteria:
The PLDIPAttrPriorityConf can be configured per attribute if there is an IP that the
operator wants to use preferentially and it has the highest priority when selecting
OAM or signaling IP.
 Selection criteria per IP type
Category IP type Priority
OAM OAM traffic 1. IP entered in PLDIPAttrPriorityConf

2. Ethernet > ATM > PPP
3. Input order
Signaling LTE S1 Signaling traffic 1. IP entered in PLDIPAttrPriorityConf
LTE X2 Signaling traffic 2. Input order
1. Input order
Bearer LTE Bearer traffic 1. Input order
N/A

Feature Description
System operation
PLDSystemOamIp
Command Description
RTRV-SYS-OAMIP Retrieves OAM IP address of a system.

CHG-SYS-OAMIP Change OAM IP version of a system.
vrId (Note.1) The virtual routing domain ID. 0~MAX_VRID_PER_SYS_ 0

CDD
oamIPVer The IP version for OAM. InetAddressType IPV4
oamIPv4Addr The IPv4 address for OAM. 0~255 0.0.0.0
oamIPv6Addr[16] The IPv6 address for OAM. 0~255 0:0:0:0:0:0:0:0
Note.1) The VR_ID is used when supporting the VR function.
PLDSystemSigIp
Command Description
RTRV-SYS-SIGIP Retrieves signaling IP addresses of a system.

CHG-SYS-SIGIP Change signaling IP version of a system.
vrId (Note.1) The virtual routing domain ID. 0~MAX_VRID_PER_SYS 0

_CDD
sigIPVer The IP version for Signal. InetAddressType IPV4
s1PriIPv4Addr The primary IPv4 address for 0~255 0.0.0.0
S1 signal.
s1SecIPv4Addr The secondary IPv4 address for 0~255 0.0.0.0
S1 signal.

Feature Description
(Continued)
x2PriIPv4Addr The primary IPv4 address for 0~255 0.0.0.0

X2 signal.
x2SecIPv4Addr The secondary IPv4 address 0~255 0.0.0.0
for X2 signal.
s1PriIPv6Addr[16] The primary IPv6 address for 0~255 0:0:0:0:0:0:0:0
S1 signal.
s1SecIPv6Addr[16] The secondary IPv6 address 0~255 0:0:0:0:0:0:0:0
for S1 signal.
x2PriIPv6Addr[16] The primary IPv6 address for 0~255 0:0:0:0:0:0:0:0
X2 signal.
x2SecIPv6Addr[16] The secondary IPv6 address 0~255 0:0:0:0:0:0:0:0
for X2 signal.
PLDIPAttrPriorityConf
Command Description
RTRV-IPV4-PRIOR Retrieves configured IP priority for each IP attribute which is

OAM and Signal.
CHG-IPV4-PRIOR Changes configuration of IP priority for each IP attribute which is
OAM and Signal.
vrId (Note.1) The virtual routing domain ID. 0~MAX_VRID_PER_SYS_ 0

CDD
dbIndex Index of the IP attribute for 0~2 0
which IP priority is to be
changed.
attribute IP Attribute Type. IPAttributeType 1
PriIPv4Addr Primary IPv4 Address. 0~255 0.0.0.0
SecIPv4Addr Secondary IPv4 Address. 0~255 0.0.0.0

Feature Description
PLDEthInfo
dbIndex It is index of Ethernet Information. 0~45 0

ipv4AttrType It is attribute type of IPv4 address IPAttributeType 0
ipv4Addr It is ipv4 address 0~255 0
addrState It is addr state (valid or invalid) of this 0 or 1 0
IPv4 address. (0 = invalid, 1 = valid)
linkState It is link state (up or down) of this IPv4 0 or 1 0
address. (0 = down, 1 = up)
vrId (Note.1) The virtual routing domain ID. 0~MAX_VRID_ 0
PER_SYS_CDD
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IP0701, Diffserv
Overview
Introduction
Diffserv (Differentiated services) is used for classifying and managing traffic and providing
IP layer QoS. This feature enables to configure DSCP (Differentiated Services Code Point)
value per traffic type.
Benefits
Operator can manage QoS at the level of IP layer.
Release History
SLR2.3
Basic or Optional
Basic

N/A
Reference
RFC2474, RFC2475

Feature Description
Feature Description
The Diffserv function is provided based on the DSCP value in an IP header. The DSCP
consists of 6 bits and it can define total 64 traffic classes. A higher DSCP value has a higher
priority. The traffic class example of DSCP is shown below.
 DSCP traffic class example
DSCP Value
DSCP Name
Binary Decimal
CS0 000 000 0

CS1 001 000 8
AF11 001 010 10
AF12 001 100 12
AF13 001 110 14
CS2 010 000 16
AF21 010 010 18
AF22 010 100 20
AF23 010 110 22
CS3 011 000 24
AF31 011 010 26
AF32 011 100 28
AF33 011 110 30
CS4 100 000 32
AF41 100 010 34
AF42 100 100 36
AF43 100 110 38
CS5 101 000 40
EF 101 110 46
CS6 110 000 48
CS7 111 000 56

Feature Description
Operation Scenario
The DSCP can be configured per traffic type and the traffics which are used in the system
are largely divided into the followings:
 Control and Management Traffic
 Signaling Traffic
 Bearer Traffic
You can configure as follows as follows:
ENV configuration
The DSCP used for the traffic before PKG loading must be set to ENV. The following ENV
parameters are used for configuration.
 DSCP_DHCP: DSCP value that is used for DHCP traffic before PKG loading.
 DSCP_SSH: DSCP value that is used for SSH and telnet traffic before PKG loading.
 DSCP: DSCP value that is used for OAM traffic (e.g. sftp/ftp, ping), before PKG
loading. This is used for all the traffics that do not use DSCP_DHCP and DSCP_SSH.
Neither DSCP_DHCP nor DSCP_SSH is configured, both the DHCP traffic and
SSH/telnet traffic use this DSCP value.
DSCP configuration for Control and Management traffic

The control traffic and management traffic which are used by the system are as follows:
A traffic type is mapped for each class ID.
 Control and Management Traffic Type
Class-ID Traffic Type
0 SNMP
1 SSH
2 sftp/ftp
3 OAM traffic, CSL, Trace
4 ICMP (Ping)
5 Network control traffic
6 IEEE 1588 traffic
The control traffic and management traffic can be configured as follows:
1) Change a DSCP value per Class-ID using CHG-SYSDSCP-DATA.

2) Retrieve the setting value using RTRV-SYSDSCP-DATA.

Feature Description
DSCP configuration for Signaling and Bearer traffic

In an eNB, additional commands are used to set the DSCPs of signaling traffic and bearer
traffic. The signaling traffic types are as follows:
 LTE Signaling Traffic Type
Class-ID Traffic Type
0 S1 Signaling
1 X2 Signaling
2 S1/X2-U Management
You can configure as follows:
1) Change the DSCP value per Class-ID using CHG-SIGDSCP-DATA.

2) Retrieve the setting value using RTRV- SIGDSCP-DATA.
The bearer traffics of LTE are classified as below based on QoS Class Identifier (QCI).
 LTE Bearer Traffic Type
QCI Traffic Type
0 QCI 0
1 QCI 1
2 QCI 2
3 QCI 3
4 QCI 4
5 QCI 5
6 QCI6
7 QCI 7
8 QCI 8
9 QCI 9
… …
255 -
You can configure as follows:
1) Change the DSCP value per Class-ID using CHG-QCIDSCP-MAP.

2) Retrieve the setting value using RTRV-QCIDSCP-MAP.

Feature Description
The operator can set any DSCP value for each traffic type and the default values are as
follows:
 Default DSCP values for Control and Management traffic
Class-ID Traffic Type DSCP
0 SNMP 24
1 SSH 24
2 sftp/ftp 16
3 OAM traffic, CSL, Trace 16
4 ICMP (Ping) 24
5 Network control traffic 48
6 IEEE 1588 traffic 48
 Default DSCP values for Signaling Traffic
Class-ID Traffic Type DSCP
0 S1 Signaling 40
1 X2 Signaling 40
2 S1/X2-U Management 40
 Default DSCP values for LTE Bearer Traffic
QCI Traffic Type DSCP
1 QCI 1 46
2 QCI 2 36
3 QCI 3 34
4 QCI 4 38
5 QCI 5 32
6 QCI6 26
7 QCI 7 28
8 QCI 8 30
9 QCI 9 10

Feature Description
System operation
DSCP configuration for Control and Management traffic
Command Description
CHG-SYSDSCP-DATA CHANGE SYSDSCP INFORMATION

RTRV-SYSDSCP-DATA RETRIEVE SYSDSCP INFORMATION
ClassId The index defined to set the DSCP 0~6 0

mapping information with control and
management traffic type. 7 traffic types
are defined as follows depending on the
ClassId.
DSCP The DSCP value that will be mapped 0~63 0
with the specified control and
management traffic type.
DSCP configuration for Signaling traffic

Command Description
CHG-SIGDSCP-DATA CHANGE DSCP FOR LTE SIGNALING TRAFFIC.

RTRV- SIGDSCP-DATA RETRIEVE DSCP FOR LTE SIGNALING TRAFFIC.

Feature Description
ClassId The index defined to set the DSCP 0~2 0

mapping information with signaling
traffic type. 3 traffic types are defined
as follows depending on the ClassId.
0: S1 Signaling
1: X2 Signaling
2: S1/X2-U Management
DSCP The DSCP value that will be mapped 0~63 0
with the specified signaling traffic
type.
DSCP configuration for Bearer traffic

Command Description
CHG-QCIDSCP-MAP CHANGE QCI-TO-DSCP INFORMATION.

RTRV- QCIDSCP-MAP RETRIEVE QCI-TO-DSCP INFORMATION.
qci QCI 0~255 0

DSCP The DSCP value that will be mapped with the 0~63 0
specified QCI.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A

Feature Description
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IP0801, Static IP configuration

Overview
Introduction
This feature means manual configuration of IP address.
Benefits
N/A
Release History
SLR2.3
Basic or Optional
Basic

N/A
Reference
N/A

Feature Description
Feature Description
Operation Scenario
IP address can be set as follows.
1) Set the IPv4 address using the CRTE-IP-ADDR command.

Enter the interface name to set the IPv4 address in IF_NAME.
Enter the A.B.C.D types of IPv4 Address in IP_ADDR.
Enter the network mask in IP_PFX_LEN, which ranges from 1 to 30.
Set whether to use the IP address entered in OAM for OAM.
Set whether to use the IP address entered in LTE_SIGNAL_S1 for LTE S1
signaling.
Set whether to use the IP address entered in LTE_SIGNAL_X2 for LTE X2
signaling.
Set whether to use the IP address entered in LTE_BEARER for LTE bearer.
2) Retrieve the IPv4 address using the RTRV-IP-ADDR command.
3) Change the IPv4 address using the CHG-IP-ADDR command.
4) Delete the IPv4 address using the DLT-IP-ADDR command.
Maximum number of IP address that can be set is 30.
The following IP subnets are used for IPC (IP communication inside a system) but can’t be
used for external communication.
 192.168.0.0/16

Feature Description
System Operation
Command Description
RTRV-IP-ADDR RETRIEVE IP ADDRESS CONFIGURATION

CRTE-IP-ADDR CREATE IP ADDRESS CONFIGURATION
DLT-IP-ADDR DELETE IP ADDRESS CONFIGURATION
CHG-IP-ADDR CHANGE IP ADDRESS CONFIGURATION
DB_INDEX Index for setting the IP address. 0~29 0

IF_NAME The name of the interface to be set with the IP 24chars -
address. Enter the name of the interface grown.
For example, enter ge_0_0_0 for the GE interface,
ge_0_0_1.100 for the VLAN interface, or sa1 for the
LAG interface.
IP_ADDR The IP address to be set. A.B.C.D -
IP_PFX_LEN The prefix length of the IP address determining the 1~30 1
network mask. If the network mask is
255.255.255.0, the length is 24.
OAM Attribute of the IP address, whether to use the IP False, True
address entered for OAM. True
- False: The IP address is not used for OAM.
- True: The IP address is used for OAM.
LTE_Signal_S1 Attribute of the IP address. Whether to use the IP False, True
address entered for LTE S1 signals. True
- False: The IP address is not used for LTE S1 signals.
- True: The IP address is used for LTE S1 signals.
LTE_Signal_X2 Attribute of the IP address. Whether to use the IP False, True
address entered for LTE X2 signals. True
- False: The IP address is not used for LTE X2 signals.
- True: The IP address is used for LTE X2 signals.
LTE_Bearer Attribute of the IP address. Whether to use the IP False, True
address entered for LTE bearer. True
- False: The IP address is not used for LTE bearer.
- True: The IP address is used for LTE bearer.

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IP0802, DHCP for IPv4

Overview
Introduction
The Dynamic Host Configuration Protocol (DHCP) is a network configuration protocol for
hosts on IP networks. This feature enables to configure IP address dynamically.
Benefits
Operator can configure BBU IP address dynamically.
Release History
SLR 2.3
Basic or Optional
Optional

N/A
Reference
IETF RFC2131

Feature Description
Feature Description
The BBU can obtain an IP address prior to the initial loading by using one of the following
two ways.
1) STATIC mode: Obtains an IP by setting Environment Variables (ENV).

2) DHCP mode: Obtains an IP automatically from the DHCP server.
In the Dynamic Host Configuration Protocol (DHCP) mode, the IP is automatically

allocated to the DHCP client from the DHCP server. DHCP procedures are as follows.
DHCP DHCP
CLIENT SERVER
DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
Operation Scenario
Below is the procedure to allocate IP from BS to DHCP.
1) Sets the ENV as follows. The DHCP server to provide an IP should be connected to
the backhaul.
setenv p BOOTMODE dhcp
2) DHCP Client-id can be identified in DHCPKEY ENV variable and it can be set as
following 2 types. If DHCPKEY is not specified in ENV, BBU can choose ‘snport’ by
default.
 mac: MAC address in loading port, can be get from Inventory (getinv -a)
 snport: Serial number + port number (ex. 123456_0), can be get from Inventory
(getinv -a)
setenv p DHCPKEY enbid

setenv p NE_ID 26
N/A

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IP1001, ECMP
Overview
Introduction
Equal-cost multi-path routing (ECMP) is a routing strategy for forwarding packets over
multiple route paths of each cost. This feature enables to achieve almost equally distributed
link load sharing.
Benefits
This feature can provide enhanced reliability and higher bandwidth of Ethernet links.
Release History
SLR2.3
Basic or Optional
Basic

N/A
Reference

Feature Description
Feature Description
ECMP (Equal-cost multi-path routing) allows all paths with the same cost value for the
same destination to be used. ECMP can be used combined with most routing protocols.
In ECMP, the next hop is determined by either the round-robin or flow based method.
Samsung’s system uses the flow based method. In the flow based method, the packet’s
source and destination IP address combination is used as the key to determine the path for
forwarding.
Operation Scenario
ECMP works properly without any additional configuration if there are more than one path
with the same cost for the same destination. The following shows how to configure a
routing for ECMP.
1) Static route settings

 Prepare two links in the running up state.
 Configure the static route for multiple paths for the same destination.
 For details, refer to Static Routing (COM-IP1201) FDD.
ECMP of flow based type, which determines the next hop by using the combination of
source and destination addresses, is supported.
Up to 12 ECMP routes can be operated for the same destination. Configuration with more
than 12 routes is not used.

Feature Description
System operation
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IP1101, IP address duplication detection

Overview
Introduction
When Ethernet interface is up and IP address is configured, IP address duplication detection
procedure is performed as specified in RFC 5227 to protect the previously deployed system.
Benefits
This feature enables to avoid IP address duplication and data corruption.
Release History
SLR 2.3
Basic or Optional
Optional

N/A
Reference
IETF RFC5227

Feature Description
Feature Description
The IP address duplication detection functions detects a collision of the IP address by using
RFC5227’s ARP probing and ongoing detection functions. This function is used to detect
whether the IP address set in the environment variable during initial BS installation collides
with another IP address. During the operation, it is used to detect a collision caused by IP
address change.
The ARP probing detection function uses the ARP request packets. For ARP probing, ARP
request packet sets the target IP address as the destination IP address, and zero as the source
IP address. A conflict ARP packet has its own IP address but the sender MAC address is
different from its own MAC address. When a conflict ARP is received, collisions of the IP
addresses are detected.
The ARP ongoing detection functions detects conflict ARP packets while listening to ARP
packets, and announce its own IP address by using an ARP reply packet.
Operation Scenario
The IP address duplication detection function is activated or deactivated by using the
ACD_ENABLE_FLAG, the environment variable.
 setenv p ACD_ENABLE_FLAG 1
Assuming that an IP address is entered on the condition of the IP address duplication

detection function activated, and if the duplication is detected before setting the IP address,
the IP address is not set. But if the duplication is detected after setting the IP address, the
currently configured IP address is maintained.
Depending on the interface’s up/down, the system operates as follows.
1) If the interface is down, the interface’s IP address is deleted.

2) If the interface is up, the IP address duplication detection function operates to detect
collisions. If no collision is detected, the IP address will be set for the interface.
If a collision is detected, the IP address is not set.
The IP address duplication detection function allows the operator to check an IP address
collision using the RTRV-SYSIP-INFO command.
1) If the AddrState is set to 0, it means a collision or the interface is down.

2) If the AddrState is set to 1, it means there is no collision.
IP address duplication detection function operates only at the time of initial system loading.

Feature Description
System operation
Command Description
RTRV-SYSIP-INFO Retrieves system IP addresses information.
dbIndex Index of SystemIpInfo PLD 0~MAX_IP_PER_SY 0

S_CDD
ipv4Addr It is ipv4 address. 0~255 0.0.0.0
AddrState Address valid state Invalid, Valid Invalid
ifName[24] The name of the interface to be 0~127 -
set with the IP address.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IP1201, Static Routing

Overview
Introduction
Static routing provides manual and static configuration of routing path.
Benefits
There is no overhead on CPU and no bandwidth usage on transport links.
Release History
SLR 2.3
Basic or Optional
Basic

N/A
Reference
N/A

Feature Description
Feature Description
The static routing is one of methods to select paths of a router. The operator can configure
the path directly to define the routing table. This can be compared with the dynamic routing
where the routing table is automatically configured. The operator configures a routing table
of a fixed path on his or her own. For this reason, even if the path experiences troubles or
the network is changed, the traffic transmission path does not change. Thus, unless the
trouble is fixed or the operator changes the path, the traffic cannot be transmitted.
Operation Scenario
The following method is used to create, retrieve, and delete the static routing setting.
1) Set the static routing using the CRTE-IP-ROUTE command.

The IP_PREFIX and IP_PFX_LEN are the route prefix information. Enter the
destination IP address and the prefix length in each field.
Set the IP_GW or IP_NAME to designate the routing path. Enter Nexthop’s IP
address in the IP_GW field and enter the interface name in the IP_NAME field.
Enter the route’s distance value in the DISTANCE.
2) Retrieve the static routing setting using the RTRV-IP-ROUTE command.
3) Delete the static routing setting using the DLT-IP-ROUTE command.
The max number of static routes supported by BBU is 128.

Feature Description
System operation
Command Description
RTRV-IP-ROUTE Retrieves static IP route.

CRTE-IP-ROUTE Creates static IP route.
DLT- IP-ROUTE Deletes static IP route.
VR_ID (Note.1) The virtual routing domain ID. 0~6 0

DB_INDEX Index for the IP route. AC: 0~1000 0
BS: 0~127
IP_PREFIX The prefix length of the IP route determining A.B.C.D -
the network mask. If the network mask is
255.255.255.0, the length is 24.
IP_PFX_LEN The prefix length of the IP route determining 0~32 0
the network mask. If the network mask is
255.255.255.0, the length is 24.
IP_GW The nexthop IP (or gateway IP) address of A.B.C.D -
the IP route.
DISTANCE The distance of the IP route. 1~255 1
Entered between 1 and 255. The default is 1.
Smaller the distance value, the higher the
priority of the route becomes.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A

Feature Description
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IP1301, IP Fragmentation/Reassembly
Overview
Introduction
IP fragmentation and reassembly is supported by IP layer. If IP packet has bigger size than
link MTU size, IP fragmentation is performed at the transmitter. Multiple fragmented
packets are transferred over the network and they are re-constructed to original packet at
the receiver.
Benefits
N/A
Release History
SLR 2.3
Basic or Optional
Basic

N/A
Reference

Feature Description
Feature Description
IP packet fragmentation is used to divide up the original packet into a smaller size than the
output link’s Maximum Transfer Unit (MTU) size if the original IP packet size is greater
than the output link’s MTU, and then transmits the packet. The router divides the IP
payload part into MTU sizes if the packet fragmentation is needed, and creates a new
fragment packet for transmission by attaching the original packet’s header.
IP fragmentation is applied only if the Don’t Fragment (DF) flag is not set inside the IP
header. If the DF flag is set, then a router will drop the packet and send the ‘Packet Too
Big’ ICMP message to the packet source.
Following figure is IP packet fragmentation:
Original Packet
IP header Payload
IP header IP header
IP header Payload (offset field Payload ..... (offset field Payload
changed) changed)
Fragment 1 Fragment 2 Last Fragment
IP packet reassembly is a function to recover the original packet by reassembling packets

transmitted as fragments. If the More Fragment (MF) flag is set inside the IP header or the
packet’s offset field is not zero, then it is a fragmented packet. If the MF flag is not set and
the IP packet’s offset field is not zero, then it is the last fragment packet. Packets
fragmented from the same original IP packet have the same IP header ID. The router
buffers fragmented packets of each IP header ID, and carries out the packet reassembly.
If the packet reassembly is not completed within the specific timeout limit, then buffered
packets would be dropped.
Following figure is IP packet reassembly:
Fragment 1 Fragment 2 Last Fragment
IP header IP header
IP header Payload (offset field Payload ..... (offset field Payload
changed) changed)
IP header Payload
Original Packet

Feature Description
Operation Scenario
The IP packet fragmentation and reassembly do not have an execution scenario but they
basically operate at the time of IP packet sending and receiving. For more on how to set the
fragmentation size, please refer to the FDD document called MTU Configuration (COM-
ET0501).
N/A

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-IP1601, ROHC for VoIP

Overview
Introduction
IP header contains the routing related information such as source IP address/port number,
destination IP address/port number and so on. However, the IP header is not needed for
several transmission sections since the most of the transmission section is a layer 2 logical
link connection. Thus, even transport layer information such as UDP and RTP header is not
needed for transmission.
RoHC (Robust Header Compression) algorithm compresses 40 bytes overhead in
RTP/UDP/IP headers into only 1 or 3 bytes and is mainly used for VoIP which uses a
typical RTP/UDP/IP packet.
Benefits
 This feature enables to increase user data throughput by applying RoHC to user data
transmitted over the radio link.
 When this feature is enabled for VoIP, the system can accommodate more VoIP users
at the same time.
Release History
SLR 2.3
Basic or Optional
Optional

 UE needs to support RoHC for header compression over the radio link.
 This feature is supported only for IPv4.
Reference
RFC3095, RFC4815, RFC4995

Feature Description
Feature Description
RoHC Architecture and Configuration
PDCP is responsible for RoHC compression and integrity protection and ciphering.
The RoHC compression is only applied to the user plane, and should not be applied to the
control plane.
Following figure is user-plane protocol stack:
Following figure is PDCP layer functional architecture:
In 3GPP specification following ROHC profiles are defined. Each profile can be applied to
each IPv4 and IPv6. In this release we only support following IPv4 profiles, 0x0000 (No
Compression), 0x0001 (RTP/UDP/IP), 0x0002 (UDP/IP), and 0x0004 (IP) with compliant
of IETF RFC 4995, RFC3095, RFC4815.

Feature Description
 RoHC Protocols and Profiles
Profile Identifier Usage Reference
0x0000 No compression RFC 4995

0x0001 RTP/UDP/IP RFC 3095, RFC 4815
0x0002 UDP/IP RFC 3095, RFC 4815
0x0003 ESP/IP RFC 3095, RFC 4815
0x0004 IP RFC 3843, RFC 4815
0x0006 TCP/IP RFC 4996
0x0101 RTP/UDP/IP RFC 5225
0x0102 UDP/IP RFC 5225
0x0103 ESP/IP RFC 5225
0x0104 IP RFC 5225
Upon connecting to eNB, UE shall be able to negotiate with eNB, RoHC profile
information over UE-EUTRA-CAPABILITY message. Each RoHC profile is bearer
specific, therefore the operator may set RoHC profile for each QCI through LSM interface.
For each bearer, maximum 16383 RoHC context sessions are supported. One thing to
worth noting is ROHC context is never transferred during handover. An operator can set
Enable/Disable RoHC for each QCI, profile list, and max RoHC Context sessions
One thing to worth noting is ROHC context is never transferred during handover.
An operator can set Enable/Disable RoHC for each QCI, profile list, and max RoHC
Context sessions.
RoHC Operation
RoHC is made of the two sides and two functions. The transmission side supports
Compressor function and the reception side supports Decompressor function.
The compression consists of the three states, initialization and refresh state, First order state,
and Second order state. In the beginning of the packet transmission, it starts with the
Initialization and Refresh state. The full packet is sent several times during this state, and
then state transits to First Order state followed by Second order state accordingly.
In the case of the mismatch of the state happen, due to the change of the header information,
the compressor in the eNB side begins to transmit full header to synchronize the context
state. There are currently three mode of the operations are defined as Unidirectional mode,
Bidirectional optimistic mode and Bidirectional Reliable mode. Detailed RoHC operation
is described in following specifications, RFC4995, RFC3095 and RFC4815.

Feature Description
Operation Scenario
RoHC algorithm is provided by PDCP layer between eNB and UE. Upon connecting to
eNB, UE shall be able to negotiate with eNB, RoHC profile information over UE-EUTRA-
CAPABILITY message. Each RoHC profile is bearer specific, therefore the operator may
set RoHC profile for each QCI through EMS interface.
 The eNB supports the following profile for IPv4 in the PDCP layer.
Profile Identifier Usage
0x0000 No compression
0x0001 RTP/UDP/IP
0x0002 UDP/IP
0x0004 IP
 The eNB determines which RoHC profile to apply based on the UE-EUTRA-
Capability information of the UE. In other words, the operator applies the most
efficient RoHC profile based on the configuration by the operator for each QCI and
the UE-capability information of the UE.
 The operator can set up whether to use the header compression function for each QCI
and which profile to use.

Feature Description
System operation
Command Description
CHG-ROHC-INF CHANGE ROHC CONFIGURATION

RTRV-ROHC-INF RETRIEVE ROHC CONFIGURATION
QCI QCI index. The standard QCIs 0~255 -

defined in the standard documents
is 1 to 9.
ROHC_SUPPORT Whether to support the ROHC. False, True False
- False: ROHC is not used (default).
- True: ROHC is used.
MAX_CONTEXT_ The maximum number of ROHC ci_maxROHC_Sessi ci_maxROHC
SESSION context sessions supported per call. ons_cs2~ci_maxRO _Sessions_cs
- ci_maxROHC_Sessions_csX: Up HC_Sessions_cs163 16
to X sessions per call are 84
supported.
PROFILE0001 Whether to support the profile0001 False, True True
(RTP/UDP/IP).
- False: The profile001 is not
supported.
- True: The profile001 is supported.
(UDP/IP).
supported.
- True: The profile002 supported.
PROFILE0003 Whether to support the profile0003 False, True False
(ESP/IP).
supported.
(IP).
supported.

Feature Description
(Continued)

(TCP/IP).
supported.
(RTP/UDP/IP).
supported.
- True: The profile0101 is
supported.
(UDP/IP).
supported.
supported.
(ESP/IP).
supported.
supported.
(IP).
supported.
supported.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A

Feature Description
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-SE0701, OS hardening
Overview
Introduction
OS hardening resolves security weaknesses in operation systems by implementing the
latest OS patches, hotfixes and updates.
Benefits
The weakness of OS is minimized.
Release History
SLR 2.3
Basic or Optional
Basic

N/A
Reference
N/A

Feature Description
Feature Description
The link aggregation function combines several physical links into a single logical link to
support routing configuration and operation. This will result in increased bandwidth and
improved availability of the link and also load sharing between links.
The OS hardening function is defined by assuming the use of Linux OS and it is classified
as follows:
 General Security Requirements on OS installation
Installation of minimum components is required because of Linux kernel configuration
and unused network services remains disabled. To operate data and log separately,
each storage is separated and operated in different partitions. The SSH and Sftp are
provided instead of telnet and ftp for NE access. The IMISH is used as a basic shell
and execution privilege is allocated for each account.
 User Administration
The IMISH is used as a basic shell and individual execution privilege is allocated for
each account. Security related logs are saved and the user administration related
commands are executable depending on execution privilege.
 Access Privileges for files, program, and directories
The IMISH is used as a basic shell and individual execution privilege is allocated for
each account. All the commands are executed based on the execution privilege defined
in the IMISH account and only the commands with defined execution privilege can be
used to access the directories and various files.
 Auditing and System Logging
Log files are saved in security mode. Every login attempt is saved and it is reported
when failed.
 Network Configuration
Minimum level of preventive measures is implemented for Dos attacks.
Operation Scenario
The following IMISH command is provided for user administration and logging related
retrieval and configuration.
 sys access-attempt-limit-count: Sets login attempt times. If the login attempt fails after
trying the set login attempt times, login becomes disabled.
 show login-history: When a user successfully logs in, the last login detail is saved into
a file and the login history can be retrieved.
N/A

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-SY0101, GPS
Overview
Introduction
The Global Positioning System (GPS) is a space-based satellite navigation system that
provides location and time information in all weather, anywhere on or near the Earth,
where there is an unobstructed line of sight to four or more GPS satellites.
Benefits
Operator can acquire system clock from GPS.
Release History
SLR 2.3
Basic or Optional
Optional

N/A
Reference
N/A

Feature Description
Feature Description
Synchronization between BS and BS is required to support communication between BS
and MS or handoff between BS and BS. At this time, the BS needs synchronization source
that provides a clock and standard time to secure synchronization. The Samsung BS can
use GPS as a synchronization source. However, it provides the holdover function that
supports continued service even when a GPS signal is weak or a GPS signal is not available
due to temporary interruption.
Following figure is GPS concept:
The procedure of obtaining timing information from GPS is as follows:
1) Known Position of the satellites (Almanac/Ephemeris from satellites)

2) Range measurement from the satellites
3) Calculate user position & time

Feature Description
Operation Scenario
Use the RTRV-GPS-STS command to retrieve the status information of GPS. You can
retrieve GPS antenna delay value, electronic frequency control value, FFOM value, Hold
over status, GPS ID, GPS locking status, location (latitude, longitude, or altitude)
information, number of satellites being traced, list of satellites being traced, TFOM value,
and Time Of Day (TOD) information.
Use the RTRV-GPS-INVT command to retrieve the inventory information of a GPS unit.
The inventory information is unique information that a Field Replaceable Unit (FRU) has.
It contains the information such as serial number, HW/FW version, unit type, unit ID,
family type, and installation date, etc. You can retrieve the inventory information proposed
in TS32.692.
Use the INIT-GPS command to reset GPS. GPS is reset when a power is blocked and then
supplied to GPS.
The GPS Receiver (GPSR) specifications are as follows:
1) Timing (Phase) accuracy: ±1 us

2) Frequency accuracy: ±0.05 ppm
3) Holdover: 24 hours

Feature Description
System operation
Retrieving GPS status information
Command Description
RTRV-GPS-STS Retrieves GPS status information.
LOCK_STATE Locking State - -

HOLDOVER_STATE Holdover State - -
TOD Time Of Day - -
POS Positioning information (latitude, - -
longitude, altitude)
TFOM Time Figure Of Merit - -
ANT_DLY GPS Antenna Delay (second) - -
SAT_C Number of satellites being traced. - -
SAT_N List of satellites being traced. - -
EFC Electronic frequency control value - -
TINT Difference or time movement - -
between SmartClock 1PPS and GPS
1 PPS signals
FFOM Frequency Figure Of Merit - -
IDN GPSR ID (vendor name, product part - -
number, product serial number, F/W
version, H/W revision)
SAT_ID Satellite ID Displays S/N with - -
SAT_ID
S/N is expressed down to 33.
A number lower than 33 is not used.

Feature Description
Retrieve Inventory Information of GPS Unit

Command Description
RTRV-GPS-INVT Retrieve Inventory Information of GPS Unit.
UNIT_ID The ID of the inventory unit (unique in the - -

eNB).
FAMILY_TYPE Vendor Family Type of Inventory Unit - -
TYPE_NUM Vendor Type Number of Inventory Unit - -
(System Number same as PBA_ID).
VERSION Version of Inventory Unit (Hardware or - -
Firmware Version).
FW_VERSION Display Firmware Version of Inventory Unit - -
SERIAL Serial Number of Inventory Unit - -
VENDOR Vendor Name of Inventory Unit - -
MNF_DATE Manufacturing date of an inventory unit - -
INSTALL_DATE Installation date of an inventory unit (Date - -
when installed on a field).
SERV_DATE Last repair date of an inventory unit - -
SERV_DATA Last repair details of an inventory unit - -
POSITION Location of an inventory unit - -
MNF_DATA Additional information for an inventory unit - -
provided by a manufacturer
GPS Reset
Command Description
INIT-GPS Reset the GPS

Feature Description
Related Alarms
 Related Alarm List
Alarm Name Description & Impact
FUNCTION FAIL When initialization due to GPSR restart or GPSR module failure has
generated
- Power failure (when the input power is 5.2 V or lower and 5.8 V or higher).
- The Electronic Frequency Control (EFC) value is either +100 % or -100 %.
- Time Not Set: GPS time is not set and it is not either Active or Standby
TOD MSG MISSED The main processor (UMP) fails to receive a TOD message from the GPSR.
HOLDOVER_24H 24-hour is elapsed after transition to Holdover status
ANTENNA FAIL The feeding current to the antenna side is in open or short state or the
antenna cable is disconnected.
: Occurs when lower than 5 mA or 120 mA or higher is continuously
maintained for 10 sec.
LOCKING FAIL When the normal GPS satellite signal cannot be received
: No GPS satellite tracking for one hour.
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-SY0601, Clock Holdover

Overview
Introduction
Clock holdover is the time during which system can operate without external clock source.
Benefits
Operator can keep the system working even if external clock source is not operable with
internal clock source.
Release History
SLR 2.3
Basic or Optional
Optional

N/A
Reference
N/A

Feature Description
Feature Description
The BS can operate by using the GPS as a synchronization source. However, the handover
function is provided for continued service even when the GPS signal is weak or the GPS
signal cannot be acquired due to temporary interference. State transition including the
holdover is as follows.
 BS operation state
Unit State transition
BS Initialization-initial capture of the satellite

Initial capture of the satellite-normal operation
Normal operation-holdover
Holdover-recapture of the satellite
Recapture of the satellite-normal operation
For the BS to enter the normal operation state, at least four GPS satellites should be
operating and tracked, so it enters the GS Lock state. After the GPS lock state, at least one
satellite should remain and be tracked. To maintain the normal holdover feature, 48 hours’
learning time should elapse for OCXO stabilization.
Operation Scenario
N/A
1) Holdover time of the eNB
 the system’s normal operation can be maintained (hold over) for 24 hours even
when synchronization is not made due to problems other than the eNB failure.
2) Accuracy during the eNB’s holdover
 Frequency accuracy below ±0.05 ppm
 Timing (Phase) accuracy: Less than 8μs

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-TM0101, Traffic Scheduling

Overview
Introduction
Since there are 8 CoS queues at Ethernet interface, Traffic Scheduling selects the buffer
which contains the packet what should be transmitted based on the policy such as PQ
(Priority Queuing) and RR (Round Robin). This feature enables to transmit the traffic with
higher priority first.
Benefits
Operator can schedule traffic based on CoS.
Release History
SLR 2.3
Basic or Optional
Basic

Supported with Ethernet CoS (COM-ET0201), DiffServ (COM-IP0701), DSCP to Ethernet
CoS mapping (COM-TM0301)
Reference
N/A

Feature Description
Feature Description
Two kinds of scheduling algorithms are supported, SPQ (Strict Priority Queuing) and DRR
(Deficit Round Robin).
1) SPQ (Strict Priority Queuing)

SPQ is an algorithm that transmits all packets, if any, waiting in the queue, and then
transmits the packets in the next queue. As shown in the figure below, SPQ transmits
all packets on the highest priority queue first and then transmits packets on the next
priority queue. This algorithms guarantees service for high priority packets, but there
is the disadvantage that no service will be provided for low priority packets if there are
many high priority packets.
Following figure is diagrams of SPQ algorithm:
2) DRR (Deficit Round Robin)

DRR is an algorithm that guarantees the minimum bandwidth set for each queue.
It selects queues using the Round-Robin method per each queue according to the
bandwidth set for each queue. If the bandwidth set for the queue is exceeded, it
transmits the packet from the next queue instead of the current queue. Comparing with
shaping, a different method is used. It transmits packets without loss if the total traffic
does not exceed the total rate of the port. And it guarantees the minimum bandwidth
set for each queue only if the total traffic exceeds the total rate of the port.
For example, assume that the total rate for the port is 1Gbps and 50 % and 50 % of the
bandwidth is set for Queue0 and Queue1 respectively. If packets of 600 Mbps are
transmitted to Queue0 and 200 Mbps to Queue 1, all packets are transmitted without
any loss because the total traffic of 800 Mbsp is less than the total rate 1 Gbps.
However, if packets of 600 Mbps are transmitted to Queue0 and 500 Mbps to Queue 1,
all of 500 Mbps are transmitted to Queue1 without loss, but 100 Mbps are dropped for
Queue0.

Feature Description
Operation Scenario
The following shows how to configure traffic scheduling.
1) Class-map Settings
① Set the class-map using the CRTE-QOS-CLASS command.
 The CLASS_NAME is needed to group and manage settings for the
classification operation. Use the CLASS_NAME to apply the classification rule
when creating a policy-map.
 For DSCP_NUMBER, set the DSCP value for classification.
 If the operator wants to use more than one identical classification rule types for
the same CLASS_NAME, s/he can define a rule by assigning a new
DB_INDEX to the identical CLASS_NAME.
② Retrieve the class-map using the RTRV-QOS-CLASS command.
③ Delete the class-map using the DLT-QOS-CLASS command.
3) Policy-map Settings
① Set the policy-map using the CRTE-QOS-POLICY command.
 The POLICY_NAME is an ID used when QoS is applied. It defines the QoS
rule for multiple class-maps.
 Enter the CLASS_NAME to use a class-map created using CRTE-QOS-
CLASS.
 For the SCHEDULER_TYPE, select one of NONE, SPQ or DRR can be
selected. NONE means scheduling is not used. To configure the scheduling
setting, select the SPQ or DRR. If the DRR is selected, the
BW_PERCENTAGE value should be entered; if SPQ is selected, the
QUEUE_PRIORITY value should be entered.
 The QUEUE_PRIORITY is a parameter the operator can enter if the SPQ is
selected as the SCHEDULER_TYPE.
 The BW_PERCENTAGE is a parameter that can be selected as the
SCHEDULER_TYPE if DRR is selected.
 The QUEUE_RATE is a parameter to enter the maximum RATE-LIMIT value
supported by the QUEUE when the SCHDULER_TYPE is not NONE.
 The QUEUE_LIMIT is a parameter to enter the allowable number of
BUFFERs if the SCHDULER_TYPE is DRR.
② Retrieve a policy-map using the RTRV-QOS-POLICY command.

Feature Description
3) QoS Settings to Interface

① Apply the QoS using the CRTE-BHQOS-CONF command.
 For the IF_NAME, enter the name of the interface where the QoS will be
applied.
 For DIRECTION, select the direction of the interface where the QoS will be
applied. Either IN or OUT can be selected.
 For POLICY_NAME, enter the name of the policy-map set by CRTE-QOS-
POLICY.
② The RTRV-QOS-CONF command allows the operator to retrieve the QoS
application status
③ Release the QoS using the DLT-QOS-CONF command.
To delete each traffic scheduling setting, execute the commands in reverse order to the
above.
The traffic scheduling function has the following features.
QUEUE-ID of the SET_PRIORITY must be specified consecutively if one or more
SCHDULER_TYPE SPQs are used.
1) The maximum number of scheduling that can be set for each interface is 7 including
the SPQ and DRR.
2) Scheduling setting can be applied only to the egress direction of the interface.
3) For the SPQ, Queue0 has the highest priority.

Feature Description
System operation
Setting the Class-map
Command Description
RTRV-QOS-CLASS Retrieves the class-map settings.

CRTE-QOS-CLASS Adds a setting to be mapped to the class-map.
DLT-QOS-CLASS Deletes a setting mapped to the class-map.
CLASS_NAME Enters a class name to be used for 32 chars -

mapping between the DSCP value and the
class. To map multiple DSCP values to
one class, the operator can enter different
indexes and DSCP values for the same
class. Use the name entered here when
the operator adds a new class to a policy
with the CRTE-QOS-POLICY command.
DSCP_ Enters a DSCP value to be mapped to the 0~63 0
NUMBER entered class. You can map multiple DSCP
values to one class.
Setting the Policy-map

Command Description
RTRV-QOS-POLICY Retrieves the classes added to a policy and the QoS operation of
those classes.
CRTE-QOS-POLICY Adds a new class to a policy and configures the QoS operation of the
class.
DLT-QOS-POLICY Deletes classes from a policy.

Feature Description
POLICY_ The name of the policy to add a new class. 32 chars -

NAME Use the name entered here when applying a
policy to a backhaul interface with the
CRTE-BHQOS-CONF command.
CLASS_NAME The name of the new class to be added to 32 chars -
the policy. Enters the CLASS_NAME
parameter that is entered when the class is
set up with the CRTE-QOS-CLASS
command.
SCHEDULER_ Sets the type of the scheduler for the class NONE, NONE
TYPE (queue). SPQ,
- NONE: Do not configure the scheduler DRR
- SPQ: Strict Priority Queue. Transmits
packets out of SPQ classes newly added to
the policy according to the priority entered
for the QUEUE_PRIORITY.
- DRR: Deficit Round Robin. If the traffic
transmitted to the backhaul interface
exceeds the PORT_RATE set by CRTE-
BHRATE-CONF, SPQ packets are
transmitted first according to the priorities.
And the remaining packets are transmitted
from the bandwidth guaranteed by the ratio
set by the BW_PERCENTAGE parameter.
QUEUE_ If the SCHEDULER_TYPE is SPQ, priorities 0~6 0
PRIORITY are set among SPQ classes within the
policy. It is valid only when the
SCHEDULER_TYPE is SPQ.
BW_ If the SCHEDULER_TYPE is DRR, sets the 1~99 1
PERCENTAGE ratio of the minimum guaranteed bandwidth
when the traffic transmitted to the backhaul
interface exceeds the bandwidth limit.
It is valid only when the SCHEDULER_
TYPE is DRR. [UNIT: %]
QUEUE_RATE Sets the rate of the bandwidth function of the 1024~999936 1024
class (queue). Shaping occurs if the traffic
transmitted to the class (queue) exceeds the
set rate. A multiple of 128, sets to a value in
the range of 1024-999936 kbps. [UNIT: %]

Feature Description
(Continued)
QUEUE_ Sets the number of buffers of the class 1~2500 1

LENGTH (queue). It can be set to a value in the range
of 1-2500. If not set, the default value is
2500.
MARKER_ Sets whether to use the marker function of NONE, NONE
TYPE the class. DSCP,
- NONE: Do not use the marker function COS
- DSCP: Marks the DSCP field with the
MARKER_NUMBER value
- COS: Marks the 802.1q VLAN tag priority
field with the MARKER_NUMBER value
METER_ Sets whether to use the Two Rate Three DISABLE, DISABLE
MODE Color Marker (TrTCM) meter function of the ENABLE
class. The TrTCM meter function enters two
rates of CIR and PIR, and measures the rate
of the packet transmission. To perform the
set operation, it classifies the measurement
(using three colors) into three cases of the
value being less than or equal to CIR,
greater than CIR and less than or equal to
PIR, and greater than PIR. (Refer to
RFC2698)
- DISABLE: Do not use the TrTCM meter
function
- ENABLE: Use the TrTCM Meter function
Apply the Policy-map in Interface

Command Description
RTRV-BHQOS-CONF Retrieves a policy applied to the interface.

CRTE-BHQOS-CONF Applies a policy to the interface.
DLT-BHQOS-CONF Deletes a policy applied to the interface.

Feature Description
IF_NAME Enters the name of the backhaul interface 24 chars 0

where the policy will be applied. Can be
applied only to a current grown interface.
POLICY_NAME Enters the name of the policy to be applied to 32 chars -
the entered backhaul interface. Enters the
POLICY_NAME parameter entered when the
policy was set up with the CRTE-QOS-
POLICYCRTE-(AC)QOS-POLICY command.
DIRECTION Selects the direction of the backhaul IN, OUT IN
interface where the policy will be applied.
- IN: Apply the policy to the packet received
by the interface. Can be applied only to the
policy that includes a meter or marker
setting.
- OUT: Apply the policy to the packet
transmitted by the interface. Can be applied
only to the policy that includes a scheduler
setting.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-TM0201, UL Traffic Shaping

Overview
Introduction
UL traffic shaping enables to restrict the maximum transmit rate at Ethernet interface.
Benefits
Operator can prevent backhaul congestion at Ethernet interface.
Release History
SLR2.3
Basic or Optional
Optional

N/A
Reference
N/A

Feature Description
Feature Description
The UL traffic shaping function allows the operator to control the traffic rate of the port
when transmitting traffics from the BBU to an external port. If the received packets exceed
the preset traffic-rate, the traffic shaping is carried out while buffering a certain number of
packets. The UL traffic shaping function provides a prioritized transmission of specific
traffics, and this specific traffic can be determined by a DSCP value of packet’s IP header.
Operation Scenarios
The UL traffic shaping setting consists of IF_NAME, PORT_RATE. It sets the shaping rate
for the interface in the PORT_RATE field. The following explains how to create, retrieve
or delete the UL traffic shaping function.
1) Set the shaping rate using the CRTE-BHRATE-CONF command.

2) Retrieve the configured shaping rate using the RTRV-BHRATE-CONF command.
3) Delete the shaping set for the interface using the DLT-BHRATE-CONF command.
The UL traffic shaping function has the following characteristics.
The maximum number of UL traffic shaping is equal to the maximum number of interfaces
supported by the BBU.
 The portRate should be a multiple of 128.
 You can only set one shaping for each interface.
 It is unable to set in the member port of the Link Aggregation (LA).
 It is unable to set in the VLAN interface.

Feature Description
System operation
Command Description
CRTE-BHRATE-CONF CREATE BH RATE CONFIGURATION

DLT-BHRATE-CONF DELETE BH RATE CONFIGURATION
RTRV-BHRATE-CONF RETRIEVE BH RATE CONFIGURATION
ifName Set the backhaul interface name for 24 -

setting bandwidth limitation rate.
portRate Set the rate of bandwidth limitation. 1024~999936 999936
This parameter should be multiples of
128 and range is 1024~999936 kbps.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-TM0301, DSCP to Ethernet CoS mapping

Overview
Introduction
Ethernet CoS is marked based on DSCP to Ethernet CoS mapping table. This table can be
configured by operators.
Benefits
N/A
Release History
SLR 2.3
Basic or Optional
Basic

Supported with Ethernet CoS (COM-ET0201) and Diffserv (COM-IP0701)
Reference
N/A

Feature Description
Feature Description
The DSCP-to-CoS mapping function is generally used along with the VLAN setting.
It is used to set the CoS value mapped to a specific DSCP in the priority field of 802.1p.
Operation Scenario
Prior to loading, the operator must set the DSCP#_CoS field in ENV to provide the DSCP-
to-CoS function, and set the CoS value for the DSCP value set in the ENV, and the DSCP
value is entered into #. The # is a DSCP value ranging from 0 to 63.
After loading, the following method is used to set DSCP-to-CoS.
1) Set the CoS value of each DSCP using the CHG-DSCPCOS-MAP command.
2) Deletion command is not provided, but deletion can be carried out by mapping the
DSCP value on CoS 0 using the CHG-DSCPCOS-MAP command.
The DSCP to Ethernet CoS mapping function is not set on the basis of interface, but it is set
on the basis of the entire system. The DSCP value is initialized to CoS 0 unless specified
otherwise.

Feature Description
System operation
Command Description
CHG-DSCPCOS-MAP CHANGE DSCPCOSMAP INFORMATION

RTRV-DSCPCOS-MAP RETRIEVE DSCPCOSMAP INFORMATION
dscp DSCP value for which the COS mapping 0~63 0

information will be set.
CoS The CoS value that will be set for the specified 0~7 0
DSCP value.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-TM0401, COM-TM0403, CAC Considering

Transport Link
Overview
Introduction
Call Admission Control (CAC) considering transport link determines whether to admit or
reject the requests of setup or modification of radio bearers, based on the backhaul
bandwidth with overbooking factor. CAC considering transport link is performed for GBR
bearer. On the other hand, a non-GBR bearer is always accepted without decision by this
function.
Benefits
Operator can provide QoS guaranteed service to UEs considering the limitation of backhaul
resource.
Release History
SLR2.2
Basic or Optional
Optional

N/A
Reference
N/A

Feature Description
Feature Description
The Call Admission Control (CAC) considering transport link determines whether to admit
a call or not based on the backhaul bandwidth that is supported in the eNB. This function
receives and processes GBR bearer configuration request (idle-to-active transition,
handover, E-RAB setup) or GBR change request (E-RAB modify). For non-GBR bearer, it
accepts it unconditionally.
When this function is triggered because GBR bearer configuration/change request is

received, it determines whether to accept a call based on the following procedure:
1) The eNB calculates the minimum required S1 backhaul bandwidth of the new/change
requested bearer. At this time, the minimum required S1 backhaul bandwidth is equal
to GBR (UL/DL).
2) The eNB estimates the estimated S1 backhaul load that will be used when the GBR
bearer configuration/change request is accepted. Calculate after reflecting the allocated
S1 backhaul bandwidth of GBR bearers under service to the calculation result in 1).
3) The eNB determines whether to accept a call by comparing the estimation result in 2)
to the maximum capability limit of S1 backhaul (per service group, per QCI, UL/DL).
If an overbooking ratio is configured, call acceptance is determined by reflecting the
overbooking ratio to the maximum capability limit of S1 backhaul.
4) Although a call cannot be accepted in 3), call acceptance is finally determined after
executing the pre-emption function if the pre-emption can be executed.
Operation Scenario
To configure, retrieve, or change the CAC considering transport link function, follow the
below procedure.
1) Check the current CAC configuration per cell. (RTRV- CELLCAC-INF)

2) Configure/change whether to use the CAC considering transport link function and its
options. (CHG-CELLCAC-INF)
3) Configure, retrieve, or change the total backhaul capability of the eNB. (CHG-ENB-
INF/RTRV-ENB-INF)
4) Configure, retrieve, or change the backhaul service group per QCI when the CAC
considering transport link function per service group is turned on. (CHG-QCI-VAL/
RTRV-QCI-VAL)
5) Configure, retrieve, or change the CAC threshold (UL, DL, normal call, HO &
emergency call) and overbooking ratio for each backhaul service group of the CAC
considering transport link function per service group. (CHG-BHBW-SVCGR/RTRV-
BHBW-SVCGR)
6) Configure, retrieve, or change the CAC threshold (UL, DL, normal call, HO &
emergency call) and overbooking ratio for each QCI of the CAC considering transport
link function per service. (CHG-QCIBHBW-INFO/RTRV-QCIBHBW-INFO)

Feature Description
N/A

Feature Description
System operation
Command Parameter Description
CHG-CELLCAC- cellNum Cell number for which the CAC function is to be executed
INF by considering transport link
RTRV- bhBwCacUsage Sets whether to execute the CAC function that considers
CELLCAC-INF the transport link of a cell
- no_use: 0
- use: 1
bhBwCacOption Sets an option to the CAC function that considers the
transport link of a cell
- bhBwCac_QCI_only: 0
- bhBwCac_ServiceGroup_only: 1
- bhBwCac_Both_QCI_ServiceGroup: 2
CHG-BHBW- serviceGroup Service group of bhBwCacOption
SVCGR - voipService: Service group that uses the Voice Over
RTRV-BHBW- Internet Protocol (VOIP) service.
SVCGR - videoService: Service group that uses the video service.
bhBwCacDlThres As a downlink for a normal call, this is the percentage of
hForNormal total backhaul bandwidth that can be allocated to each
service group.
Range: 0-100, Init: 30, Unit: %
bhBwCacDlThres As a downlink for an emergency call and handover call,
hForEmerHo this is the percentage of total backhaul bandwidth that can
be allocated to each service group.
bhBwCacUlThres As an uplink for a normal call, this is the percentage of
hForNormal total backhaul bandwidth that can be allocated to each
service group.
bhBwCacUlThres As an uplink for an emergency call and handover call, this
hForEmerHo is the percentage of total backhaul bandwidth that can be
allocated to each service group.
overBookingRatio Over booking ratio to the downlink and uplink thresholds
Range: 1.0-10.0, Init: 1.0

Feature Description
(Continued)
CHG-QCI-VAL qci QCI defined in the standard The standard QCI defined in
RTRV-QCI-VAL the standard is 1-9. The operator can use an arbitrary
number between 128-254. (0, 10-27, 255: reserved value)
Range: 0-255
bhServiceGroup Sets service group per QCI
- voipService: Service group that uses the Voice Over
Internet Protocol (VOIP) service.
- videoService: The service group which uses the video
service.
CHG-ENB-INF bhLinkCapacity Total backhaul link capacity of a base station
RTRV-ENB-INF Range: 0-10000, Init: 1000, Unit: Mbps
CHG- qci QCI defined in the standard The standard QCI defined in
QCIBHBW-INFO the standard is 1-9. The operator can use an arbitrary
RTRV- number between 128-254. (0, 10-27, 255: reserved value)
QCIBHBW-INFO Range: 0-255
bhBwCacDlThres Percentage of backhaul bandwidth that can be allocated
hForNormal to each QCI for the downlink of a normal call
Range: 0-100, Init: 30 (1)/10 (2, 3, 4)/0 (0, 5-255), Unit: %
bhBwCacDlThres Percentage of backhaul bandwidth that can be allocated
hForEmerHo to each QCI for the downlink of an emergency call and
HO call
Range: 0-100, Init: 35 (1)/12 (2, 3, 4)/0 (0, 5-255), Unit: %
bhBwCacUlThres Percentage of backhaul bandwidth that can be allocated
hForNormal to each QCI for the uplink of a normal call
Range: 0-100, Init: 30 (1)/10 (2, 3, 4)/0 (0, 5-255), Unit: %
bhBwCacUlThres Percentage of backhaul bandwidth that can be allocated to
hForEmerHo each QCI for the uplink of an emergency call and HO call
Range: 0-100, Init: 35 (1)/12 (2, 3, 4)/0 (0, 5-255), Unit: %
overBookingRatio Over booking ratio to the downlink and uplink thresholds
Range: 1.0-10.0, Init: 1.0
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A

Feature Description
Related Status
N/A
Related Call Faults

 Related Call Fault List
Call Fault Name Description & Impact
RRM_BHCAC_FAIL Occurs when the backhaul link usage of QoS (GBR Bearer) is higher than
a threshold and checks the status of resources in a base station A call
under call setup is cleared and a call under handover fails.

Feature Description
COM-TM0402, Load sharing between multiple

transport links
Overview
Introduction
When multiple backhaul links are used, bearer traffic will be evenly distributed to the
multiple links. However, the packet ordering within a single call will be maintained.
Benefits
Operator can maximize link efficiency by balancing load between multiple links.
Release History
SLR 2.3
Basic or Optional
Basic

N/A
Reference
N/A

Feature Description
Feature Description
Operation Scenario
The following figure shows backhaul link allocation and backhaul link release procedure.
When eNB receives Initial Context Setup Request message or Handover Request message
from MME, eNB selects a backhaul IP address which has smaller allocated UE count
among multiple backhaul IP addresses. And then, allocated UE count of a selected IP
address is increased. This selected IP address is used to set up a GTP tunnel as a source IP
address. When eNB receives UE Context Release Command from MME, eNB decreases
allocated UE count of the backhaul IP address to be released. With this backhaul link
allocation/release mechanism, UEs will be evenly distributed to the multiple backhaul links
and load sharing between multiple links is achieved.
Following figure is the procedure of backhaul link allocation and release:
N/A

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
COM-TM0601, Transport QoS

Overview
Introduction
This feature provides QoS according to the type of traffic on the transport network.
IP DSCP and Ethernet CoS values are used to control traffic priority and perform
scheduling for packet transmission.
Benefits
Operator can manage QoS on the transport network.
Release History
SLR 2.3
Basic or Optional
Basic

Supported with Diffserv (COM-IP-0701), DSCP to Ethernet CoS mapping (COM-TM-
0301), Ethernet CoS (COM-ET-0201) and Traffic Scheduling (COM-TM0101)
Reference
N/A

Feature Description
Feature Description
The backhaul network transmits and receives mixtures of various traffics such as signaling
traffic, OAM traffic, bearer traffic, and network control traffic, so the traffics should be
controlled according to the priority of each traffic. For instance, in case of losing signaling
traffic or network control traffic, the entire service can be affected, so it requires a higher
priority than a general user’s traffic. In addition, latency of voice traffic is important, so it
should have a higher priority than internet data traffic.
Likewise, the transport QoS function is required to control the priority of each traffic type.
In the Ethernet backhaul network, the IP layer and the Ethernet layer uses DSCP and CoS
respectively to provide the transport QoS function. The operator can control the priorities
by setting DSCP/CoS for each traffic type. Full conceptual diagram of transport QoS’s is as
follows.
This Samsung device basically provides the transport QoS functions based on the DSCP
values.
1) Set the DSCP value that will be marked for each traffic type. For more details, refer to
the FDD of Diffserv (COM-IP-0701).
2) DSCP is mapped to a specific CoS value. Multiple DSCPs can be mapped to a single
CoS value. For more details, refer to the FDD of DSCP to Ethernet CoS mapping
(COM-TM-0301).
3) The above settings 1) and 2) determine the Ethernet CoS value that is marked for each
traffic type. For more details on the Ethernet CoS, refer to Ethernet CoS (COM-ET-
0201).
4) The egress port transmits packets according to the scheduling scheme set for each
queue. For more details, refer to the FDD of traffic scheduling (COM-TM0101).

Feature Description
Operation Scenario
For more details on functional setting and operation, refer to the FDD document for each
function.
 Diffserv (COM-IP-0701)
 DSCP to Ethernet CoS mapping (COM-TM-0301)
 Ethernet CoS (COM-ET-0201)
 Traffic Scheduling (COM-TM0101)
N/A

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME0104, 10 MHz Bandwidth
Overview
This feature supports a transmission structure of 10 MHz channel bandwidth in FDD-LTE
system.
Introduction
In LTE system, total 6 channel bandwidths are standardized in 3GPP specification: 1.4, 3, 5,
10, 15 and 20 MHz channel bandwidth. In this feature, it is described of 10 MHz channel
bandwidth configuration, which is composed of total 50 resource block (RB). 1 RB is 180
kHz frequency spacing, and actually the bandwidth of 9 MHz is used for transmission
except for guard bandwidth. Therefore, the spectral efficiency is 90 % for 10 MHz channel
bandwidth configuration.
Benefits
Operator Benefits:
 Operator can support LTE service with channel bandwidth of 10 MHz.
Release History
SLR2.2
Reference
1) 3GPP TS 36.101: Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) radio transmission and reception
2) 3GPP TS 36.104: Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station
(BS) radio transmission and reception
3) 3GPP TS 36.211: Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation
4) 3GPP TS36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2

Feature Description
Feature Description
 3GPP has specified a set of 6 channel bandwidths, ranging from 1.4 MHz to 20 MHz.
Below table is Channel bandwidth for LTE.
Below figure is Definition of Channel Bandwidth and Transmission Bandwidth

Configuration for one E-UTRA carrier.
 A Resource Block represents the basic unit of resource for the LTE air-interface.
The eNB scheduler allocates Resource blocks to UE when allowing data transfer.
 The subcarriers belongs to the Orthogonal Frequency Division Multiple Access
(OFDMA) technology in the downlink, and the Single Carrier Frequency Division
Multiple Access (SC-FDMA) technology in the uplink.
 There are 12 subcarriers per Resource Block so the number of subcarriers equals 12 x
number of Resource Blocks.
 Each subcarrier occupies 15 kHz so the total subcarrier bandwidth equals 15 kHz x
number of subcarriers.
 The downlink subcarrier bandwidth includes an additional 15 kHz to accommodate a
null subcarrier at the center of all other subcarriers. The null subcarrier provides 15
kHz of empty spectrum within which noting is transmitted.
 The total subcarrier bandwidth is less than the channel bandwidth to allow for the roll-
off of emissions and to provide some guard band.

Feature Description
 The larger channel bandwidths provide support for the higher throughputs.
Smaller channel bandwidths provide support for lower throughputs but are easier to
accommodate within existing spectrum allocations.
 3GPP also specifies a subcarrier spacing of 7.5 kHz (in addition to the subcarrier
spacing of 15 kHz). The subcarrier spacing of 7.5 kHz is only used in cells which are
dedicated to Multimedia Broadcast Multicast Services (MBMS). There are 24 rather
than 12 carriers per resource Block when using the 7.5 KHz subcarrier spacing so the
total bandwidth of a Resource Block remains the same.
 3GPP References: TS 36.101, TS 36.104, TS 36.211
Below figure is Time-frequency resource structure in LTE (10 MHz BW).

Feature Description
Upper figure presents the time-frequency resource structure for 10 MHz channel bandwidth
LTE system. The time-frequency resources are subdivided according to the following
structure: the largest unit of time is the 10 ms radio frame, which is further subdivided into
ten 1 ms subframes, each of which is split into two 0.5 ms slots. Each slot comprises seven
OFDM symbols in the case of the normal cyclic prefix length, or six if the extended cyclic
prefix is configured in the cell. In the frequency domain, resources are grouped in units of
12 subcarriers (thus occupying a total of 180 kHz), such that one unit of 12 subcarriers for
a duration of one slot is termed a Resource Block (RB). The smallest unit of resource is the
Resource Element (RE), which consists of one subcarrier for duration of one OFDM
symbol. A resource block is thus comprised of 84 resource elements in the case of the
normal cyclic prefix length.

Feature Description
System operation
 Related Commands and Parameters
Command Parameters Description
RTRV-CELL-IDLE dlBandwidth, ulBandwidth Retrieve BW of DL and UL

ci_SystemBandwidth_n6 (1.4 MHz),
ci_SystemBandwidth_n15 (3 MHz),
ci_SystemBandwidth_n100 (20 MHz)
CHG-CELL-IDLE dlBandwidth, ulBandwidth Change BW of DL and UL
 Related System Parameters
Parameters Description How to Set/Change
PLDEutranCell dlBandwidth, ulBandwidth See Related Commands

ConfIdle setting
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME0105, 15 MHz Bandwidth

Overview
This feature supports a transmission structure of 15 MHz channel bandwidth in FDD-LTE
system.
Introduction
In LTE system, total 6 channel bandwidths are standardized in 3GPP specification: 1.4, 3, 5,
10, 15 and 20 MHz channel bandwidth. In this feature, it is described of 15 MHz channel
bandwidth configuration, which is composed of total 75 resource block (RB). 1 RB is 180
kHz frequency spacing, and actually the bandwidth of 13.5 MHz is used for transmission
except for guard bandwidth. Therefore, the spectral efficiency is 90 % for 10 MHz channel
bandwidth configuration.
Benefits
Operator Benefits:
 Operator can support LTE service with channel bandwidth of 15 MHz.
Release History
SLR2.2
Reference
1) 3GPP TS 36.101: Evolved Universal Terrestrial Radio Access (E-UTRA); User
2) 3GPP TS 36.104: Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station
(BS) radio transmission and reception
3) 3GPP TS 36.211: Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
4) 3GPP TS36.300: Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Feature Scope
R1 LTE eNB supports 15 MHz.
R2 Operator can set the BW.

Feature Description
Feature Description
 3GPP has specified a set of 6 channel bandwidths, ranging from 1.4 MHz to 20 MHz.
Below table is Channel bandwidth for LTE.
Below figure is Definition of Channel Bandwidth and Transmission Bandwidth

Configuration for one E-UTRA carrier.
 A Resource Block represents the basic unit of resource for the LTE air-interface.
The eNB scheduler allocates Resource blocks to UE when allowing data transfer.
 The subcarriers belong to the Orthogonal Frequency Division Multiple Access
(OFDMA) technology in the downlink, and the Single Carrier Frequency Division
Multiple Access (SC-FDMA) technology in the uplink.
 There are 12 subcarriers per Resource Block so the number of subcarriers equals 12 x
number of Resource Blocks.
 Each subcarrier occupies 15 kHz so the total subcarrier bandwidth equals 15 kHz x
number of subcarriers.
 The downlink subcarrier bandwidth includes an additional 15 kHz to accommodate a
null subcarrier at the center of all other subcarriers. The null subcarrier provides 15
kHz of empty spectrum within which noting is transmitted.
 The total subcarrier bandwidth is less than the channel bandwidth to allow for the roll-
off of emissions and to provide some guard band.

Feature Description
 The larger channel bandwidths provide support for the higher throughputs.
Smaller channel bandwidths provide support for lower throughputs but are easier to
accommodate within existing spectrum allocations.
 3GPP also specifies a subcarrier spacing of 7.5 kHz (in addition to the subcarrier
spacing of 15 kHz). The subcarrier spacing of 7.5 kHz is only used in cells which are
dedicated to Multimedia Broadcast Multicast Services (MBMS). There are 24 rather
than 12 carriers per resource Block when using the 7.5 KHz subcarrier spacing so the
total bandwidth of a Resource Block remains the same.
 3GPP References: TS 36.101, TS 36.104, TS 36.211
Below figure is Time-frequency resource structure in LTE (15 MHz BW)
Upper figure presents a time-frequency resource structure in 15 MHz channel bandwidth

LTE system. The time-frequency resources are subdiv1ided according to the following
structure: the largest unit of time is the 10 ms radio frame, which is further subdivided into
ten 1 ms subframes, each of which is split into two 0.5 ms slots. Each slot comprises seven
OFDM symbols in the case of the normal cyclic prefix length, or six if the extended cyclic
prefix is configured in the cell.

Feature Description
In the frequency domain, resources are grouped in units of 12 subcarriers (thus occupying a
total of 180 kHz), such that one unit of 12 subcarriers for a duration of one slot is termed a
Resource Block (RB). The smallest unit of resource is the Resource Element (RE), which
consists of one subcarrier for duration of one OFDM symbol. A resource block is thus
comprised of 84 resource elements in the case of the normal cyclic prefix length.

Feature Description
System operation
RTRV-CELL-IDLE dlBandwidth, ulBandwidth Retrieve BW of DL and UL

ci_SystemBandwidth_n6 (1.4 MHz),
ci_SystemBandwidth_n100 (20 MHz)
CHG-CELL-IDLE dlBandwidth, ulBandwidth Change BW of DL and UL
Parameters Description How to Set/Change
PLDEutranCellConfIdle dlBandwidth, ulBandwidth setting SeeRelated Commands
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME0401, Downlink QSPK, 16QAM, 64QAM

Support
Overview
UE can be configured to report CQI (Channel Quality Indicator) to assist the eNB in
selecting an appropriate MCS to use for the downlink transmissions. Support QPSK,
16QAM and 64QAM modulation in DL. eNB selects among QPSK, 16QAM and 64QAM
schemes in response to the CQI feedback from UE.
Introduction
LTE systems employ adaptive modulation and coding (AMC) in order to take advantage of
fluctuations in the channel over time and frequency. The basic idea is quite simple: transmit
as high data rate as possible when and where the channel is good, and transmit at a lower
rate when and where the channel is poor in order to avoid excessive dropped packets.
Lower data rates are achieved by using a small constellation, such as QPSK, and low rate
error correcting codes such as rate 1/3 turbo codes. The higher data rates are achieved with
large constellations, such as 64QAM, and less robust error correcting codes, for example,
either higher rate 3/4 codes. To perform AMC, the transmitter must have some knowledge
of the instantaneous channel gain. Once it does, it can choose the modulation and coding
combination that will achieve the highest possible data rate while still meeting a BER of
packet error rate (PER) requirement.
Benefits
Operator Benefits:
 Operator can dynamically change modulation order according to the downlink channel
environment.
End User Benefits:

 N/A
Release History
SLR2.2 and Later|New Entry|Basic Feature
Reference
1) 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 2

Feature Description
Feature Scope
R1 LTE eNB supports BPSK, QPSK, 16QAM, and 64QAM.

Feature Description
Feature Description
Modulation
 A different modulation scheme can be applied to each Resource Element, e.g. one
Resource Element can be a QPSK modulation symbol while the adjacent Resource
Element can be a 64QAM modulation symbols.
 Resource Elements can be allocated to either a Physical Channel or a Physical Signal.
 In the case of Physical Channels, the modulation scheme applied to a specific
Resource Element depends on the type of Physical Channel to which the Resource
Element has been allocated. Below table presents the relationship between Physical
Channel and modulation scheme.
Below table is Modulation schemes applied to each downlink Physical Channel.
 The PDSCH modulation scheme depends on the RF channel conditions and the
quantity of data to be transferred. The modulation scheme is selected by the eNB link
adaptation.
 The PMCH modulation scheme depends on the throughput requirements of the
broadcast service.
 64QAM provides the greatest throughput by generating a single modulation symbol
from a group of 6 bits. 64QAM requires good signal to noise ratio conditions at the
receiver to avoid mis-interpreting one 64QAM symbol for another.
 Bits are mapped onto the modulation symbols using Gray coding. This approach helps
to minimize bit errors by mapping the bits such that neighboring modulation symbol
differ by only a single bit. If the receiver mis-interprets a modulation symbol for its
neighbor then only a single bit error is introduced. The concept of Gray coding for
16QAM is illustrated in below figure. The first two bits identify the quadrant while the
second two bits identity the location within the quadrant.

Feature Description
Below figure is Modulation Constellation for 16QAM
 In the case of Physical Signals, modulation is not necessary because the signal itself is
a series of complex numbers which can be mapped directly onto the appropriate set of
Resource Elements.
 3GPP reference: TS 36.211.
Link Adaptation
In LTE, link adaptation is based on the Adaptive Modulation and Coding (AMC).
AMC can adapt modulation scheme and code rate in the following way:
 Modulation scheme: if the SINR (Signal-to-Interference plus Noise Ratio) is
sufficiently high, higher-order modulation schemes with higher spectral efficiency
(hence with higher bit rates) like 64QAM are used. In the case of poor SINR a lower-
order modulation scheme like QPSK, which is more robust against transmission errors
but has a lower spectral efficiency, is used.
 Code rate: for a given modulation scheme, an appropriate code rate can be chosen
depending on the channel quality. The better the channel quality, the higher the code
rate is used and of course the higher the data rate.
For the downlink data transmissions in LTE, the eNB typically selects the modulation
scheme and code rate depending on a prediction of the downlink channel conditions.
An important input to this selection process is the Channel Quality Indicator (CQI)
feedback transmitted by the User Equipment (UE) in the uplink. CQI feedback is an
indication of the data rate which can be supported by the channel, taking into account the
Signal to Interference plus Noise Ratio (SINR) and the characteristics of the UE’s receiver.
For the LTE uplink transmissions, the link adaptation process is similar to that for the
downlink, with the selection of modulation and coding schemes also being under the
control of the eNB.

Feature Description
An identical channel coding structure is used for the uplink, while the modulation scheme
may be selected between QPSK and 16QAM, and, for the highest category of UE, also
64QAM. The main difference from the downlink is that instead of basing the link
adaptation on CQI feedback, the eNB can directly make its own estimate of the supportable
uplink data rate by channel sounding, for example using the Sounding Reference Signals
(SRSs). A final important aspect of link adaptation is its use in conjunction with multi-user
scheduling in time and frequency, which enables the radio transmission resources to be
shared efficiently between users as the channel capacity to individual users varies.
The CQI can therefore be used not only to adapt the modulation and coding rate to the
channel conditions, but also for the optimization of the time/frequency selective scheduling
and for inter-cell interference management.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME0402, Uplink QPSK, 16QAM Support

Overview
For UL transmissions, the link adaptation process is similar to that for DL, with the
selection of modulation and coding schemes also being under the control of the eNB.
eNB estimates the supportable uplink data rate by channel sounding and selects appropriate
modulation for the result of estimated UL channel quality. Support QPSK and 16QAM
modulation in UL.
Introduction
LTE systems employ adaptive modulation and coding (AMC) in order to take advantage of
fluctuations in the channel over time and frequency. The basic idea is quite simple: transmit
as high data rate as possible when and where the channel is good, and transmit at a lower
rate when and where the channel is poor in order to avoid excessive dropped packets.
Lower data rates are achieved by using a small constellation, such as QPSK, and low rate
error correcting codes such as rate 1/3 turbo codes. The higher data rates are achieved with
large constellations, such as 64QAM, and less robust error correcting codes, for example,
either higher rate 3/4 codes. To perform AMC, the transmitter must have some knowledge
of the instantaneous channel gain. Once it does, it can choose the modulation and coding
combination that will achieve the highest possible data rate while still meeting a BER of
packet error rate (PER) requirement.
Benefits
Operator Benefits:
 Operator can dynamically change modulation order according to the downlink channel
environment.
End User Benefits:

 N/A
Release History
SLR2.2

Feature Description

Dependency:
 In order to support UL 64QAM, category 5 UE terminal needs to be commercialized.
Limitation:
 In spite of the readiness of UL 64QAM in eNB system. current UE does not support
category 5 specification. When UE is support the UL 64QAM, it will be commercially
supported UL 64QAM after additional 3 months of verification.
Reference
Feature Scope
R1 LTE eNB supports QPSK and 16QAM modulation scheme.

Feature Description
Feature Description
Modulation
 A different modulation scheme can be applied to each Resource Element, e.g. one
Resource Element can be a QPSK modulation symbol while the adjacent Resource
Element can be a 64QAM modulation symbols.
 Resource Elements can be allocated to either a Physical Channel or a Physical Signal.
 In the case of Physical Channels, the modulation scheme applied to a specific
Resource Element depends on the type of Physical Channel to which the Resource
Element has been allocated. Below table presents the relationship between Physical
Channel and modulation scheme.
Below table is Modulation schemes applied to each downlink Physical Channel
 The PDSCH modulation scheme depends on the RF channel conditions and the
quantity of data to be transferred. The modulation scheme is selected by the eNB link
adaptation.
 The PMCH modulation scheme depends on the throughput requirements of the
broadcast service.
 64QAM provides the greatest throughput by generating a single modulation symbol
from a group of 6 bits. 64QAM requires good signal to noise ratio conditions at the
receiver to avoid mis-interpreting one 64QAM symbol for another.
 Bits are mapped onto the modulation symbols using Gray coding. This approach helps
to minimize bit errors by mapping the bits such that neighboring modulation symbol
differ by only a single bit. If the receiver mis-interprets a modulation symbol for its
neighbor then only a single bit error is introduced. The concept of Gray coding for
16QAM is illustrated in below figure. The first two bits identify the quadrant while the
second two bits identity the location within the quadrant.

Feature Description
Below figure is Modulation Constellation for 16QAM.
 In the case of Physical Signals, modulation is not necessary because the signal itself is
a series of complex numbers which can be mapped directly onto the appropriate set of
Resource Elements.
 3GPP reference: TS 36.211.

Feature Description
Link Adaptation
In LTE, link adaptation is based on the Adaptive Modulation and Coding (AMC). AMC can
adapt modulation scheme and code rate in the following way:
 Modulation scheme: if the SINR (Signal-to-Interference plus Noise Ratio) is
sufficiently high, higher-order modulation schemes with higher spectral efficiency
(hence with higher bit rates) like 64QAM are used. In the case of poor SINR a lower-
order modulation scheme like QPSK, which is more robust against transmission errors
but has a lower spectral efficiency, is used.
 Code rate: for a given modulation scheme, an appropriate code rate can be chosen
depending on the channel quality. The better the channel quality, the higher the code
rate is used and of course the higher the data rate.
For the downlink data transmissions in LTE

The eNB typically selects the modulation scheme and code rate depending on a prediction
of the downlink channel conditions. An important input to this selection process is the
Channel Quality Indicator (CQI) feedback transmitted by the User Equipment (UE) in the
uplink. CQI feedback is an indication of the data rate which can be supported by the
channel, taking into account the Signal to Interference plus Noise Ratio (SINR) and the
characteristics of the UE’s receiver.
For the LTE uplink transmissions

The link adaptation process is similar to that for the downlink, with the selection of
modulation and coding schemes also being under the control of the eNB. An identical
channel coding structure is used for the uplink, while the modulation scheme may be
selected between QPSK and 16QAM, and, for the highest category of UE, also 64QAM.
The main difference from the downlink is that instead of basing the link adaptation on CQI
feedback, the eNB can directly make its own estimate of the supportable uplink data rate by
channel sounding, for example using the Sounding Reference Signals (SRSs). A final
important aspect of link adaptation is its use in conjunction with multi-user scheduling in
time and frequency, which enables the radio transmission resources to be shared efficiently
between users as the channel capacity to individual users varies. The CQI can therefore be
used not only to adapt the modulation and coding rate to the channel conditions, but also
for the optimization of the time/frequency selective scheduling and for inter-cell
interference management.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME0501, Cell specific Reference Signal

Overview
Cell-specific reference signal (CRS) is transmitted in all downlink subframes in a cell
supporting PDSCH transmission. CRS is transmitted on one or several of antenna ports 0 to 3.
It is used for both demodulation and channel estimation purpose in downlink.
Introduction
Cell-specific reference signals (CRS) are transmitted in every downlink subframe and in
every resource block in the frequency domain, thus covering the entire cell bandwidth.
The cell-specific reference signals can be used by the terminal for channel estimation for
coherent demodulation of any downlink physical channel except for PMCH and for
PDSCH in the case of transmission modes 7, 8, or 9, such as non-codebook based
precoding.
The cell-specific reference signals can also be used by the terminal to acquire channel state
information (CSI). Finally measurements on cell-specific reference signals are used as the
basis for cell-selection and handover decisions.
Benefits
Operator Benefits:
 Operator can provide multiple antenna transmission.
End User Benefits:

 LTE user can estimate downlink channel and demodulate control and traffic channel
data.
Release History
SLR2.2

Dependency:
 CRS transmission depends on whether UE supports 2CRS or 4CRS.
Limitation:
 None

Feature Description
Reference
Feature Scope
R1 LTE eNB should provide the cell specific reference signal structure among downlink
reference signals.
R2 LTE eNB should be operated in the 2CRS mode to support 2 antenna ports.
R3 LTE eNB should be operated in the 4CRS mode to support 4 antenna ports.

Feature Description
Feature Description
The cell specific reference signal (also known as the common reference signal (CRS)) is:
 Used to support CQI reporting, demodulation, cell selection, cell reselection and
handover.
 Allocated resource elements which are distributed in both the time and frequency
domains
 Broadcast from antenna ports 0 to 3 during subframes supporting PDSCH
transmission
The cell specific reference signal is only defined for the 15 kHz subcarrier spacing, i.e.
it is not supported for the 7.5 kHz subcarrier spacing used for Multimedia Broadcast
Multicast Service (MBMS). The sequence used to generate each cell specific reference
signal onto the set of resource elements is the same for both FDD and TDD.
In general, the values of the reference symbols vary between different reference symbol
positions and also between different cells. Thus, a cell specific reference signal can be seen
as a two-dimensional cell specific sequence. The period of this sequence equals one 10 ms
frame. Furthermore, regardless of the cell bandwidth, the reference signal sequence is
defined assuming the maximum possible LTE carrier bandwidth corresponding to 100
resource blocks in the frequency domain. For cell bandwidths less than the maximum
possible value, only the reference symbols within that bandwidth are actually transmitted.
There are 504 different reference signal sequences defined for LTE, where each sequence
corresponds to on of 504 different physical layer cell identities. During the cell search
procedure the terminal detects the PCI of the cell as well as the cell frame timing.
Thus, from the cell search procedure, the terminal knows the reference signal sequence of
the cell (given by the physical layer cell identity) as well as the start of the reference signal
sequence (given by the frame timing).
The set of reference symbol positions is outlined in below figure. The frequency shift to
use in a cell depends on the PCI of the cell such that each shift corresponds to 84 different
cell identities. Thus, the six different frequency shifts jointly cover all 504 different cell
identities. By properly assigning PCI to different cells, different reference signal frequency
shifts may be used in neighboring cells. The resource element allocation cycles once every
6 physical cell identities, e.g. identity 6 has the same resource element allocation as identity
0. This corresponds to 1 cycle for every 2 physical layer cell identity groups.

Feature Description
Below figure is Cell specific reference signal as a function of the physical cell identity.
Below figure illustrates the reference signal structure in the case of multiple, more
specifically two and four, cell specific reference signals, and corresponding multiple
antenna ports within a cell.
 In the case of two reference signals within a cell, the second reference signal is
frequency multiplexed with the first reference signal, with a frequency domain offset
of three subcarriers
In the case of four reference signals, the third and fourth reference signals are frequency
multiplexed and transmitted within the second OFDM symbol of each slt, thus being time
multiplexed with the first and second reference signals.

Feature Description
Below figure is Cell specific reference signal.
Obviously, the reference symbol density for the third and fourth reference signals is lower,
compared to the density of the first and second reference signals. The reason for this is to
reduce the reference signal overhead in the case of four reference signals. More specifically,
while the first and second reference signals each correspond to a relative over grid of
approximately 5 % (four reference symbols within a resource block consisting of a total
84 resource elements), the relative overhead of the third and fourth reference signals is
only half of that or approximately 2.5 %.
The cell specific reference signal represents an overhead which reduces the number of
resource elements available for user plane data:
 Overhead increases when multiple transmit antenna ports are used
 Overhead increases when using the extended cyclic prefix
In the case of FDD, the overhead generated by the cell specific reference signal is
presented in below table.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME0504, Positioning Reference Signal

Overview
Positioning reference signals shall only be transmitted in resource blocks in downlink
subframes configured for positioning reference signal transmission. Positioning reference
signals for OTDOA, which is one of UE positioning methods
Introduction
Positioning Reference signals (PRS) were introduced within the release 9 version of the
3GPP specifications. Their main objective is to improve the ‘hearability’ of neighbouring
cells within completing measurements for the downlink Observed Time Difference of
Arrival (OTDOA) positioning method. 3GPP recognized that the hearability of the existing
cell specific reference signals was not sufficient to support the OTDOA positioning method.
Hearability can be challenging as a result of neighboring cells being co-channel with the
serving cell, especially at locations where the serving cell signal strength is high.
Benefits
Operator Benefits:
 Operator can provide an OTDOA based location service to LTE user using positioning
reference signal.
End User Benefits:

 N/A
Release History
SLR2.2

Dependency:
 Positioning reference signal is used for the OTDOA positioning method.
Limitation:
 OTDOA is defined in the release 9 version of 3GPP specifications. Therefore, Rel.9
supportable UE is required.

Feature Description
Reference
2) 3GPP TS 36.305 Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
Stage 2 functional specification of User Equipment (UE) positioning in E-UTRAN
3) 3GPP TS 36.355 Evolved Universal Terrestrial Radio Access (E-UTRA); LTE
Positioning Protocol (LPP)
4) 3GPP TS 36.133 Evolved Universal Terrestrial Radio Access (E-UTRA);
Requirements for support of radio resource management
Feature Scope
R1 LTE eNB supports the Positioning Reference Signal (PRS) as a downlink reference
signal.

Feature Description
Feature Description
The OTDOA positioning method makes use of Reference Signal Time Difference (RSTD)
measurements from the UE. The RSTD quantifies the subframe timing difference between
a reference cell and a neighboring cell. The accuracy of the positioning calculation is
improved if the UE can provide RSTD measurements from an increased number of cells.
RSTD is measured in units of Ts (1/30720 ms) and is reported to the Enhanced Serving
Mobile Location Center (E-SMLC) where the location calculation is completed.
The E-SMLC is a network element within the EPC.
Positioning reference signals are able to coexist with both the cell specific reference signals
and the physical layer control information at the start of each subframe (PCFICH, PHICH,
PDCCH). Positioning reference signals occupy an increased number of resource elements
within a subframe relative to the cell specific reference signals to help improve RSTD
measurement accuracy. The sequence used to generate the positioning reference signal is a
function of the physical cell identity (PCI) and the cyclic prefix duration (normal or
extended). Positioning reference signals are broadcast using antenna port 6. They are not
mapped onto resource elements allocated to the PBCH, Primary synchronization signal nor
secondary synchronization signal. Positioning reference signals are only defined for the 15
kHz subcarrier spacing. They are not supported for the 7.5 kHz subcarrier spacing used by
Multimedia Broadcast Multicast Services (MBMS). Figure. 1 illustrates examples of the
positioning reference signal for normal cyclic prefix. There is a dependancy upon the
number of antenna ports used for the cell specific reference signal. Additional symbols are
used by the cell specific reference signal when broadcast from 4 antenna ports.
Below figure is Mapping of positioning reference signals (normal cyclic prefix).
The UE receives an LTE Positioning Protocol (LPP) Provide Assistance Data message
from the E-SMLC. This message is packaged by the MME as a NAS message before being
packaged by the eNB as an RRC message. The Provide Assistance Data message includes
information regarding both the reference and neighboring cells. The reference cell does not
have to be the current serving cell for the UE.

Feature Description
The content of the reference cell information is presented in below table.

Similar information is also provided for each of the neighboring cells.
Below table is Content of OTDOA Reference Cell Information.
The positioning reference signal bandwidth is signalled to the UE with a value of 6, 15, 25,
50, 75 or 100 resource blocks. The positioning reference signal bandwidth is always
centered around the middle of the channel bandwidth. The positioning reference signal
configuration index is used to define both a periodicity and subframe offset for the timing
of the positioning reference signal. The look-up table presented in below table is used to
link the configuration index to the periodicity and subframe offset.
Below table is Positioning Reference Signal subframe configuration.
The number of consecutive downlink subframes defines the number of subframes during
which the positioning reference signal is broadcast within each positioning reference signal
period. The number of consecutive downlink subframes can be configured with values of 1,
2, 4 or 6 subframes.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME0506, Synchronization Signal

Overview
Synchronization signal is composed of primary and secondary synchronization signals.
The synchronization signals always occupy the 72 sub-carrier (6RBs) of the channel, which
make a same cell search procedure regardless of channel bandwidth.
Primary Synchronization Signal (PSS) detection to obtain the physical layer cell ID (within
a group of three) and slot synchronization. Secondary Synchronization Signal (SSS)
detection to obtain the Cyclic Prefix (CP) length, the physical layer cell group ID and the
frame synchronization.
Introduction
Both the FDD and TDD versions of LTE broadcast Synchronization Signals in the
downlink direction:
 Primary Synchronization Signal (PSS)
 Secondary Synchronization Signal (SSS)
Synchronization Signals are broadcast within every 10 ms radio frame

The UE uses the Synchronization Signals to:
 achieve radio frame, subframe, slot and symbol synchronization in the time domain
 identify the center of the channel bandwidth in the frequency domain
 deduce the Physical layer Cell Identity (PCI)
Detecting the Synchronization Signals is a prerequisite to measuring the cell specific

Reference Signals and decoding the Master Information Block (MIB) on the Physical
Broadcast Channel (PBCH)
Benefits
Operator Benefits:
 Operator can make a time synchronization with LTE UE by using synchronization
signal.
End User Benefits:

 UE can find out a physical cell ID of serving cell by resolving synchronization signal.
 UE can find out frame and slot starting time by resolving synchronization signal.
Release History
SLR2.2

Feature Description

Dependency:
 None
Limitation:
 None
Reference

Feature Description
Feature Description
Primary Synchronization Signal
The Primary Synchronization Signal (PSS) is broadcast twice during every radio frame and
both transmissions are identical.
In the case of FDD,

 the PSS is broadcast using the central 62 subcarriers belonging to the last symbol of
time slots 0 and 10.
In the case of TDD,

 the PSS is broadcast using the central 62 subcarriers belonging to the third symbol of
time slot 2 (subframe 1) and the third symbol of time slot 12 (subframe 6)
 subframe 1 is always a special subframe so the PSS is sent as part of the Downlink
Pilot Time Slot (DwPTS)
subframe 6, may or may not be a special subframe, depending upon the uplink-
downlink subframe configuration. It is a special subframe for configurations 0, 1, 2
and 6. Otherwise it is a normal downlink subframe.
Te PSS is used to:

 achieve subframe, slot and symbol synchronization in the time domain
 identify the center of the channel bandwidth in the frequency domain
 deduce a pointer towards 1 of 3 Physical layer Cell Identities (PCI)
− PCI are organised into 168 groups of 3 so the Primary Synchronization Signal
identifies the position of the PCI within the group but does not identify the group
itself
The PSS cannot be used to achieve radio frame synchronization because both transmissions
within the radio frame are identical and equally spaced in time.
Secondary Synchronization Signal

The Secondary Synchronization Signal (SSS) is broadcast twice within every radio frame.
The two transmissions of the SSS are different so the UE can detect which is the first and
which is the second
In the case of FDD:

 the SSS is broadcast using the central 62 subcarriers belonging to the second to last
symbol of time slots 0 and 10

Feature Description
In the case of TDD:

 the SSS is broadcast using the central 62 subcarriers belonging to the last symbol of
time slot 1 (subframe 0) and the last symbol of time slot 11 (subframe 5)
 both time slots 1 and 11 are always within normal downlink subframes
The SSS is used to achieve radio frame synchronization and deduce a pointer towards 1 of
168 Physical layer Cell Identity (PCI) groups allows the PCI to be deduced when combined
with the pointer from the PSS. The set of Resource Elements allocated to the
Synchronization Signals is independent of the channel bandwidth. The UE does not require
any knowledge of the channel bandwidth prior to detecting the Synchronization Signals.
The downlink channel bandwidth is subsequently read from the Master Information Block
(MIB) on the Physical Broadcast Channel (PBCH). Below figure illustrates the timing of
the PSS and SSS for FDD. This example assumes the normal cyclic prefix because there
are 7 symbols within each time slot. The extended cyclic prefix follows a similar pattern
except there are only 6 symbols within the time slot (the SSS and PSS remain within the
last two symbols of the time slot).
Below figure is Timing of Synchronization Signals for FDD.
Below figure illustrates the timing of the PSS and SSS for TDD. The example assumes the
normal cyclic prefix, uplink-downlink subframe configuration 0 and special subframe
configuration 0. The extended cyclic prefix follows a similar pattern except there are
only 6 symbols within the time slot (the SSS remains within the last symbol of time slots 1
and 11, while the PSS remains within the third symbol of time slots 2 and 12).

Feature Description
Below figure is Timing of Synchronization Signals for TDD.
In the case of TDD, the SSS and PSS are not in adjacent symbols. The first two symbols
within time slots 2 and 12 are left available for the PCFICH, PHICH and PDCCH.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME0507, Demodulation Reference Signal

Overview
Demodulation reference signal is used for channel estimation in the eNodeB receiver in
order to demodulate control and data channels. It is located on the 4th symbol in each slot
(for normal cyclic prefix) and spans the same bandwidth as the allocated uplink data.
Introduction
In LTE there are two types of reference signals defined in the uplink
 Demodulation reference signals, which are transmitted on uplink resources assigned
to the UE, are for coherent demodulation of data and control information at the eNB.
As PUCCH cannot be transmitted simultaneously with PUSCH, there are
demodulation reference signals defined for each of them, that is, there are
demodulation reference signals for PUSCH and demodulation reference signals for
PUCCH.
 Sounding reference signals are wideband reference signals for the eNB to measure
uplink channel quality information for uplink resource allocation. They are not
associated with the transmission of PUSCH or PUCCH.
The reason for having two types of reference signals in the uplink is because, unlike the
downlink, the demodulation reference signals in uplink are only transmitted on subcarriers
assigned to the UE and therefore cannot provide sufficient wideband channel quality
information for resource allocation, particularly over the resource blocks that are not
allocated to the UE. Unlike the downlink, the reference signal in the uplink cannot be
transmitted at the same time as user data. Instead, the uplink reference signals are time
division multiplexed with the uplink data in the assigned subcarriers. In this way, the power
level of the reference signal can be different from that of the data symbol as they are
transmitted over different SC-FDMA symbols, so the PAPR is minimized over each SC-
FDMA symbol.
Benefits
Operator Benefits:
 eNB can demodulate uplink data and control information by the channel estimate from
this signal.
End User Benefits:

 N/A

Feature Description
Release History
SLR2.2
Reference
Feature Scope
R1 LTE eNB should supports the structure of the demodulation reference signal for
uplink channel estimation and coherent demodulation.

Feature Description
Feature Description
Reference Signal Sequence
Both the demodulation reference signal and the sounding reference signal are defined by a
cyclic shift of the same base sequence. The generation of the base sequence depends on the
reference signal sequence length.
 If m ≥ 3, m is the size of the resource blocks assigned to the UE (the UE is assigned
three resource blocks or more), the base sequence is based on prime-length Zadoff-
Chu sequences that are cyclically extended to the desired length.
 For m = 1 or m = 2, the base sequence form given in [1].
Multiple reference signals can then be created by different shifts of the same base sequence.
As the Zadoff-Chu sequence has the property that cyclic shifted versions of the same
sequence are orthogonal to each other, generating reference signals in such a manner can
reduce inter-cell interference for the reference signal transmission. The orthogonality of
reference signals for each UE are only carried in resource blocks assigned to that UE.
The reference signal in the uplink is always UE-specific.
Resource Mapping of Demodulation Reference Signals

The resource mapping of the demodulation reference signal is different for PUSCH and
PUCCH channels. In addition, different from the downlink, the reference signals are
inserted in the time domain, which is to preserve the low PAPR property of SC-FDMA.
For PUSCH, the demodulation reference signal sequence is mapped to resource elements
(k, l) with l=3 for normal CP and l=2 for extended CP, with increasing order first in k and
then in the slot number. An example odd demodulation reference signal mapping for
PUSCH is shown in below figure, with the normal CP.

Feature Description
Below figure is Resource mapping of DM-RS for PUSCH with the normal CP.
 DM-RS location for different PUCCH Formats
PUCCH supports six different formats, and the resource mapping to SC-FDMA symbols
for different formats is listed in upper table. Note that the number of PUCCH demodulation
reference symbols are different for different formats, which is related to the number of
control symbols for each format. For example, there are 10 CQI/PMI modulated symbols
for PUCCH format 2/2a/2b, and there are 2 reference symbols in each slot as shown in
upper table, so there are a total of 14 symbols that fill the whole subframe, which is of 14
SC-FDMA symbols. As PUCCH format 1/1a/1b has fewer information bits than PUCCH
format 2/2a/2b, there are more reference symbols for format 1/1a/1b than there are for
format 2/2a/2b, which can be used to improve the channel estimation performance.
The resource mapping of PUCCH demodulation reference signals, together with PUCCH
symbols. Note that due to the resource mapping of PUCCH, the two consecutive slots
shown in below figure (a) and (b) are at the two edges of the whole bandwidth.

Feature Description
Below figure is Resource mapping of DM-RS for PUCCH with normal CP.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME0508, Sounding Reference Signal

Overview
Sounding reference signal provides uplink channel quality information as a basis for
scheduling decisions in the base station. The UE sends a sounding reference signal in
different parts of the bandwidths where no uplink data transmission is available.
The sounding reference signal is transmitted in the last symbol of the subframe.
The configuration of the sounding signal, e.g. bandwidth, duration and periodicity, are
given by higher layers.
Introduction
In LTE there are two types of reference signals defined in the uplink
 Demodulation reference signals, which are transmitted on uplink resources assigned to
the UE, are for coherent demodulation of data and control information at the eNB.
As PUCCH cannot be transmitted simultaneously with PUSCH, there are
demodulation reference signals defined for each of them, that is, there are
demodulation reference signals for PUSCH and demodulation reference signals for
PUCCH.
 Sounding reference signals can be used to measure the uplink channel quality over a
section of the channel bandwidth. The eNB can use this information for uplink
frequency selective scheduling and link adaptation. When uplink/downlink channel
reciporcity is assumed, measuremens from the SRS can also be used to support
downlink transmission, e.g. the SRS can be used to support Angle of Arrival (AoA)
measurements for downlink beamforming. Channel reciprocity is most applicable to
TDD in which case the same RF carrier is used for uplink and downlink transmissions.
The SRS was introduced within the release 8 version of 3GPP specifications, and was
subsequently enhanced within the release 10 version. Enhancements provide support
for uplink MIMO and rapid triggering of SRS transmissions using a flag within the
DCI.
The reason for having two types of reference signals in the uplink is because, unlike the
downlink, the demodulation reference signals in uplink are only transmitted on subcarriers
assigned to the UE and therefore cannot provide sufficient wideband channel quality
information for resource allocation, paticularly over the resource blocks that are not
allocated to the UE. Unlike the downlink, the reference signal in the uplink cannot be
transmitted at the same time as user data. Instead, the uplink reference signals are time
division multiplexed with the uplink data in the assigned subcarriers. In this way, the power
level of the reference signal can be different from that of the data symbol as they are
transmitted over different SC-FDMA symbols, so the PAPR is minimized over each SC-
FDMA symbol.

Feature Description
Benefits
 eNB can estimate uplink channel response from receiving this signal.
 The channel estimate is utilized in next uplink scheduling.
Release History
SLR2.2
Reference
Feature Scope
R1 A base station may use SRS for frequency selective scheduling, time alignment (TA)
control and the antenna selection of a smart solution system.

Feature Description
Feature Description
SRS is delivered through the symbol of the last SC-FDMA from the subframe as shown
below. The sending interval of SRS by UE may be settable shortly to be 2 ms and lengthily
320 ms. SRS sequence provides the index for cyclic shift from 0 to 7. Accordingly, if other
indexes for cyclic shift are used, multiple phones are possible to transmit SRS at the same
time with the same resources. In addition, SRS is not transmitted over all subcarriers of RB
but it is transmitted in a comb pattern by selecting an even or odd subcarrier as shown in
the figure below.
If a different transmission comb is used, even a same phone whose the index for cyclic
shift is same may transmit the SRS resource at the same time.
The assignment of the subframe resource of the cell for transmitting SRS may be set
through srs-SubframeConfig consisting of 4 bits as shown below. For example, if 3 is set,
SRS resource is assigned every 5 ms over no. 0 to no. 6 subframe.
SRS- Configuration Period

Binary Transmission offset (subframes)
SubframeConfig (subframes)
0 0000 1 {0}
1 0001 2 {0}
2 0010 2 {1}
3 0011 5 {0}
4 0100 5 {1}
5 0101 5 {2}
6 0110 5 {3}
7 0111 5 {0,1}
8 1000 5 {2,3}
9 1001 10 {0}

Feature Description
(Continued)
SRS- Configuration Period Transmission offset

Binary
SubframeConfig (subframes) (subframes)
10 1010 10 {1}
11 1011 10 {2}
12 1100 10 {3}
13 1101 10 {0, 1, 2, 3, 4, 6, 8}
14 1110 10 {0, 1, 2, 3, 4, 5, 6, 8}
15 1111 Inf N/A
At the time, the size of RS assigning resources is decided to be srs-BandwidthConfig.

For example, the size of the assigning resources under srs-BandwidthConfig in10 MHz
bandwidth is as shown below.
The size of RB corresponding to m_SRS, 0 is that of SRS BW assigned to the cell, and the
size of SRS BW by phone is determined by the number of RB corresponding to m_SRS,
0~m_SRS, 3 according to the UE-specific srs-Bandwidth 0 to 3.
For example, if srs-BandwidthConfig is 3, 36RB is assigned to SRS BW, and if 2 is
transmitted to the phone with srs-Bandwidth, the phone transmits SRS in the size of 4 RB.
At the time, each phone may decide whether SRS is transmitted while hopping all SRS
BWs according to a srsHoppingBandwidth set value as a parameter by phone or only to a
specific band.
SRS-Bandwidth SRS-Bandwidth SRS-Bandwidth SRS-Bandwidth

SRS bandwidth B_SRS = 0 B_SRS=1 B_SRS=2 B_SRS=3
configuration m_SRS, N0 m_SRS, N1 m_SRS, N2 m_SRS, N3
0 1 2 3
0 48 1 24 2 12 2 4 3
1 48 1 16 3 8 2 4 2
2 40 1 20 2 4 5 4 1
3 36 1 12 3 4 3 4 1
4 32 1 16 2 8 2 4 2
5 24 1 4 6 4 1 4 1
6 20 1 4 5 4 1 4 1
7 16 1 4 4 4 1 4 1

Feature Description
System operation
SRS configuration can be specified by parameters in below:

CHG-DPHY- srsHoppingBandwidth SRS frequency hopping bandwidth. b_hop =

ULSRS duration ENUMERATED {hbw0, hbw1, hbw2, hbw3}, where
RTRV-DPHY- hbw0 corresponds to value 0, hbw1 to value 1 and
ULSRS so on.
SRS transmit duration. FALSE (=0) corresponds to
‘single’ and value TRUE (=1) to’indefinite’.
CHG-SRS-IDLE srsPeriodicity SRS transmit period in ms. Valid input set
RTRV-SRS-IDLE according to the 3GPP specification is {2, 5, 10, 20,
40, 80, 160, 320}
CHG-SNDRS- srsUsage Config whether to setup SRS or not. Value TRUE
CONF ackNackSrsSimulTran (=1) corresponds to ‘setup’.
RTRV-SNDRS- smission Config whether to support simultaneous
CONF transmission of ACK/NACK or SR, and SRS.
Value TRUE (=1) corresponds to support’.
Parameter Description How to Set/Change
srsHoppingBandwi Range: 0~3 This parameter can be changed/retrieved from the

dth Default: 0 command of CHG-DPHY-ULSRS/RTRV-DPHY-
ULSRS.
duration Range: 0~1 This parameter can be changed/retrieved from the
Default: 1 command of CHG-DPHY-ULSRS/RTRV-DPHY-
ULSRS.
srsPeriodicity Range: 2, 5, 10, 20, This parameter can be changed/retrieved from the
40, 80, 160, 320 command of CHG-SRS-IDLE/RTRV-SRS-IDLE.
Default: 10
srsUsage Range: 0~1 This parameter can be changed/retrieved from the
Default: 1 command of CHG-SNDRS-CONF/RTRV-SNDRS-
CONF
ackNackSrsSimulTr Range: 0~1 This parameter can be changed/retrieved from the
ansmission Default: 1 command of CHG-SNDRS-CONF/RTRV-SNDRS-
CONF

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME0601, RACH Preamble Type for FDD

Overview
Introduction
Since the random access mechanism is used by the UE when it is not synchronized on the
uplink a guard time needs to be introduced to avoid collisions with other transmissions.
The duration of the guard time needs to account for the round trip propagation time and is
dependent upon the cell size supported. With propagation speed of 1 km/3.33us,
approximately 6.7us of guard time per kilometer is required to accommodate the round-trip
time. In order to support cell size up to 100 km as required for LTE, the guard time should
be in the range of 670us. However, this large guard time would be an undesired overhead
when the system is deployed with smaller cells, which are most common.
Therefore, multiple random access preamble formats with both small and large guard times
are defined.
Benefits
Operator Benefits:
 Enabling this feature can support various cell sizes defined in 3GPP standard.
End User Benefits:

 N/A.
Release History
SLR2.2

Dependency:
 None.
Reference
2) 3GPP TS 36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Feature Scope
R1 LTE eNB supports the RACH preamble format 0-3 in the FDD mode.

Feature Description
Feature Description
As shown in upper figure, the random access preanble consists of a CP length T CP and a
sequence part of length T SEQ . As uplink synchronization may not be established prior to the
random access procedure, a guard time (GT) is also needed to account for the round trip
propagation delay between the UE and the eNB. The value of T CP and T SEQ . depend on the
cell size and base station implementation.
 Random Access Preamble Parameters
There are five different preamble formats defined in LTE specified in upper table.
where T s = 1/(15000 × 2048) sec. Format 0 is for normal cells; format 1, also known as the
extended format, is used for large cells; format 2 and format 3 use repeated preamble
sequences to compensate for increased path loss, and are used for small cells and large cells,
respectively; format 4 is defined for frame structure type 2 only. This random access
preamble formats are described in below figure.
Below figure is Random access preamble formats.

Feature Description
The random access preambles are generated from Zadoff-Chu sequence, which are similar
to reference signals. The network configures the set of preamble sequences that the UE is
allowed to use. In each cell, there are 64 available preambles, which are generated from
one or several root Zadoff-Chu sequences. Due to the zero cross-correlation between
different cyclic shifts of the same Zadoff-Chu sequence, there is no intra-cell interference
from multiple random acess attempts using different preambles in the same cell.
The transmission of a random access preamble is restricted to certain time and frequency
resources. The Physical Random Access Channel (PRACH) resources within a radio frame
are indicated by a PRACH configuration index, which is given by higher layers.
For frame structure type 1 with preamble format 0-3, there is at most one random access
resource per subframe; for frame structure type 2 with preamble format 0-4, there might be
multiple random access resources in an uplink subfrmae depending on the uplink/downlink
configuration.
In the frequency domain, the random access burst occupies a bandwidth corresponding to six
consecutive resource blocks (72 subcarriers) in a subframe or a set of consecutive subframes.
The PRACH uses a different subcarrier spacing (Δf RA ) than other physical channels, which is
listed in Table. 2 together with the preamble sequence sequence length N ZC .
Note that the data symbol subcarrier spacing Δf = 15 kHz is an integer multiple of the
PRACH subcarrier spacing Δf RA . This is to minimize the orthogonality loss in the
frequency domain and can also reuse the IFFT/FFT component.
 Random access preamble format 4
In TDD mode, there are only two values for UpPTS duration (one or two OFDM symbols).
As a result, UpPTS usage by the UE is limited to either sounding reference signals or
random access transmission. Random access requires UpPTS length of two OFDM
symbols. When one OFDM symbol is allocated to the UpPTS, only sounding reference
signals transmission is possible. Random access on the UpPTS is limited by the length of
the UpPTS and therefore not applicable to all deployment scenarios. An illustration of the
random access transmission in the UpPTS is shown in below figure.
Below figure is Random access format in UpPTS.
Random access begins at 4832 × Ts seconds, where Ts = 1/(15000 × 2048), before the end
of the UpPTS with a duration of 4544 × Ts seconds. This leaves a guard period of 288 × Ts
seconds, allowing for a maximum supported cell size of approximately
1.4 km. For larger cell sizes, RACH will have to be supported in regular uplink subframes
to provide a sufficient guard period.

Feature Description
System operation
RTRV-PRACH- prachConfigIndex Defines the subframe, period, and subframe index

CONF that are used for transmission of the preamble
RTRV-PRACH- format and preamble.
CONF Range: 0~63
Default: 3
zeroCorrelZoneConfig Defines the zero correlation zone config which is
used for creation of random preamble.
Range: 0~15
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME0603, Random Access Procedure

Overview
Random Access Procedure are of two types contention-based and non-contention operation.
Introduction
The LTE random access procedure comes in two forms, allowing access to be either
contention-based (implying an inherent risk of collision) or contention-free. A UE initiates
a contention-based random access procedure. In this procedure, a random access preamble
signature is randomly chosen by the UE, with the result that it is possible for more than one
UE simultaneously to transmit the same signature, leading to a need for a subsequent
contention resolution process. For the use-cases (2) (new downlink data) and (3)
(handover) the eNodeB has the option of preventing contention occurring by allocating a
dedicated signature to a UE, resulting in contention-free access. This is faster than
contention-based access-a factor which is particularly important for the case of handover,
which is time-critical. Unlike in WCDMA, a fixed number (64) of preamble signatures is
available in each LTE cell, and the operation of the two types of RACH procedure depends
on a partitioning of these signatures between those for contention-based access and those
reserved for allocation to specific UEs on a contention-free basis.
Benefits
Operator Benefits
 eNB support contention based and contention free operation of random access
procedures.
 Help in minimizing the chance of collision.
End user Benefits

 Contention-free random access procedure helps UE minimize the chance of collision.
Release History
SLR2.2
Reference

Feature Description
Reference
1) 3GPP TS 36.201 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer; General description’
Channels and Modulation’
3) 3GPP TS 36.212 ‘Evolved Universal Terrestrial Radio Access (E-UTRA);
Multiplexing and channel coding’
layer procedures’
layer; Measurements’
6) 3GPP TS 36.300 ‘Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2’
Feature Scope
R1 For random access, LTE eNB must support contention-free random access and
contention based random access.

Feature Description
Feature Description
 Contention-based Random Access Procedure
The contention-based procedure consists of four-steps as shown in below figure:
Below figure is Contention-based Random Access Procedure.
− Step 1: Preamble transmission

The UE selects one of the 64-NCF available PRACH contention-based signatures,
where NCF is the number of signatures reserved by the eNB for contention-free
RACH. The set of contention-based signatures is further subdivided into two
subgroups, so that the choice of signature can carry one bit of information to
indicate information relating to the amount of transmission resource needed to
transmit the message at Step 3. The broadcast system information indicates which
signatures are in each of the two subgroups (each subgroup corresponding to one
value of the one bit of information), as well as the meaning of each subgroup.
The UE selects a signature from the subgroup corresponding to the size of
transmission resource needed for the appropriate RACH use case (some use cases
require only a few bits to be transmitted at Step 3, so choosing the small message
size avoids allocating unnecessary uplink resources), which may also take into
account the observed downlink radio channel conditions. The eNodeB can control
the number of signatures in each subgroup according to the observed loads in each
group. The initial preamble transmission power setting is based on an open-loop
estimation with full compensation for the path-loss. This is designed to ensure that
the received power of the preambles is independent of the path-loss; this is
designed to help the eNB to detect several simultaneous preamble transmissions in
the same time-frequency PRACH resource. The UE estimates the path-loss by
averaging measurements of the downlink Reference Signal Received Power (RSRP).
The eNB may also configure an additional power offset, depending for example on
the desired received Signal to Interference plus Noise Ratio (SINR), the measured
uplink interference and noise level in the time-frequency slots allocated to RACH
preambles, and possibly also on the preamble format

Feature Description
− Step 2: Random access response;

The Random Access Response (RAR) is sent by the eNodeB on the Physical
Downlink Shared CHannel (PDSCH), and addressed with an ID, the Random
Access Radio Network Temporary Identifier (RA-RNTI), identifying the time-
frequency slot in which the preamble was detected. If multiple UEs had collided by
selecting the same signature in the same preamble time-frequency resource, they
would each receive the RAR.
The RAR conveys the identity of the detected preamble, a timing alignment
instruction to synchronize subsequent uplink transmissions from the UE, an initial
uplink resource grant for transmission of the Step 3 message, and an assignment of
a Temporary Cell Radio Network Temporary Identifier (C-RNTI) (which may or
may not be made permanent as a result of the next step-contention resolution).
The RAR message can also include a ‘backoff indicator’ which the eNodeB can set
to instruct the UE to back off for a period of time before retrying a random access
attempt. The UE expects to receive the RAR within a time window, of which the
start and end are configured by the eNodeB and broadcast as part of the cell-
specific system information. The earliest subframe allowed by the specifications
occurs 2 ms after the end of the preamble subframe, as illustrated in below figure.
However, a typical delay (measured from the end of the preamble subframe to the
beginning of the first subframe of RAR window) is more likely to be 4 ms. Below
figure shows the RAR consisting of the step 2 message (on PDSCH) together with
its downlink transmission resource allocation message ‘G’ (on the Physical
Downlink Control CHannel (PDCCH). If the UE does not receive a RAR within
the configured time window, it retransmits the preamble. The minimum delay for
preamble retransmission after the end of the RAR window is 3 ms. The eNodeB
may configure preamble power ramping so that the transmission power for each
retransmitted preamble is increased by a fixed step. However, since the random
access preambles in LTE are normally orthogonal to other uplink transmissions, it
is less critical than it was in WCDMA to ensure that the initial preamble power is
kept low to control interference. Therefore, the proportion of random access
attempts which succeed at the first preamble transmission is likely to be higher than
inWCDMA, and the need for power ramping is likely to be reduced.
Below figure is Random Access Response.

Feature Description
− Step 3: Layer 2/Layer 3 (L2/L3) message;

This message is the first scheduled uplink transmission on the PUSCH and makes
use of Hybrid Automatic Repeat reQuest (HARQ). It conveys the actual random
access procedure message, such as an RRC connection request, tracking area update,
or scheduling request. It includes the Temporary C-RNTI allocated in the RAR at
Step 2 and either the C-RNTI if the UE already has one (RRC_CONNECTED
UEs) or the (unique) 48-bit UE identity. In case of a preamble collision having
occurred at Step 1, the colliding UEs will receive the same Temporary C-RNTI
through the RAR and will also collide in the same uplink time-frequency resources
when transmitting their L2/L3 message. This may result in such interference that
no colliding UE can be decoded, and the UEs restart the random access procedure
after reaching the maximum number of HARQ retransmissions. However, if one
UE is successfully decoded, the contention remains unresolved for the other UEs.
The following downlink message (in Step 4) allows a quick resolution of this
contention.
− Step 4: Contention resolution message.
The contention resolution message is addressed to the C-RNTI or Temporary C-
RNTI, and, in the latter case, echoes the UE identity contained in the L2/L3
message. It supports HARQ. In case of a collision followed by successful decoding
of the L2/L3 message, the HARQ feedback is transmitted only by the UE which
detects its own UE identity (or C-RNTI); other UEs understand there was a
collision, transmit no HARQ feedback, and can quickly exit the current random
access procedure and start another one. The UE’s behaviour upon reception of the
contention resolution message therefore has three possibilities:
 The UE correctly decodes the message and detects its own identity: it sends
back a positive ACKnowledgement, ‘ACK’.
 The UE correctly decodes the message and discovers that it contains another
UE’s identity (contention resolution): it sends nothing back (Discontinuous
Transmission, ‘DTX’).
 The UE fails to decode the message or misses the DL grant: it sends nothing
back (‘DTX’).
 Contention-Free Random Access Procedure
The slightly unpredictable latency of the random access procedure can be
circumvented for some use cases where low latency is required, such as handover and
resumption of downlink traffic for a UE, by allocating a dedicated signature to the UE
on a per-need basis. In this case the procedure is simplified as shown in below figure.
The procedure terminates with the RAR.

Feature Description
Below figure is Contention-Free Random Access Procedure.

Feature Description
System operation
RTRV-RACH- numberOfRAP Number of non-dedicated preambles

CONF reambles ENUMERATED (n4, n8, n12, n16, n20, n24, n28, n32, n36,
CHG-RACH- n40, n44, n48, n52, n56, n60, n64)
CONF Range: 0-15
Default: 14 (n60)
sizeOfRAPrea Number of preambles group A
mblesGroupA ENUMERATED (n4, n8, n12, n16, n20, n24, n28, n32, n36,
n40, n44, n48, n52, n56, n60)
Range: 0-14
Default: 6 (n28)
messageSize Criteria for the size of the message for selecting preambles
GroupA group A
ENUMERATED (b56, b144, b208, b256)
Range: 0-3
Default: 0 (b56)
messagePowe Criteria for the power offset for selecting preamble group B
rOffsetGroupB ENUMERATED (minusinfinity, dB0, dB5, dB8, dB10, dB12,
dB15, dB18)
Range: 0-7
Default: 1 (dB0)
powerRamping Power ramping step size during preamble transmission
Step ENUMERATED (dB0, dB2, dB4, dB6)
Range: 0-10
Default: 3 (dB6)
preambleInitRc Value used to set the initial target reception power of
vTargetPower preamble
ENUMERATED (dBm-120, dBm-118, dBm-116, dBm-114,
dBm-112, dBm-110, dBm-108, dBm-106,
dBm-104, dBm-102, dBm-100, dBm-98, dBm-96, dBm-94,
dBm-92, dBm-90)
Range: 0-15
Default: 6 (dBm-108)
preambleTrans Maximum number of transmission of the preamble
Max ENUMERATED (n3, n4, n5, n6, n7, n8, n10, n20, n50, n100,
n200)
Range: 0-10
Default: 0 (n3)

Feature Description
(Continued)
RTRV-RACH- contentionRes Specifies the contention resolution timer.

CONF olutionTimer ENUMERATED (sf8, sf16, sf24, sf32, sf40, sf48)
CHG-RACH- Range: 0-7
CONF Default: 5 (sf7)
maxHARQMsg Maximum number of HARQ Msg3 transmissions
3Tx Range: 1-8
Default: 8
RTRV-RACH- raResponseWi The period of time for which the UE waits the RA response
IDLE ndowSize ENUMERATED (sf2, sf3, sf4, sf5, sf6, sf7, sf8, sf10)
CHG-RACH- Range: 0-7
IDLE Default: 5
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME1001, Variable Number of OFDM Symbols

for PDCCH
Overview
The number of resources (OFDM symbols) used in each sub frame for PDCCH shall be
dynamic based on the requirement of the CCE (control channel element) by the load of
control signaling. There shall be dynamically varying CFI (control format indicator) within
the range specified in the standards for different bandwidths.
Introduction
The number of resources (OFDM symbols) used in each sub frame for PDCCH shall be
dynamic based on the requirement of the CCE (control channel element) by the load of
control signaling. There shall be dynamically varying CFI (control format indicator) within
general, the downlink control channels can be configured to occupy the first 1, 2 or 3 OFDM
symbols in a subframe. There are two special cases: in subframes containing MBSFN
transmissions there may be 0, 1 or 2 symbols for control signalling, while for narrow
system bandwidths (less than 10 resource blocks) the number of control symbols is
increased, and may be 2, 3 or 4 to ensure sufficient coverage at the cell border.
This flexibility allows the control channel overhead to be adjusted according to the
particular system configuration, traffic scenario and channel conditions.
The PCFICH carries a Control Format Indicator (CFI) which indicates the number of
OFDM symbols (i.e. normally 1, 2 or 3) used for transmission of control channel
information in each subframe. In principle the UE could deduce the value of the CFI
without a channel such as the PCFICH, for example by multiple attempts to decode the
control channels assuming each possible number of symbols, but this would result in
significant additional processing load. For carriers dedicated to MBSFN there are no
physical control channels, so the PCFICH is not present in these cases. Three different CFI
values are used in the first version of LTE, and a fourth codeword is reserved for future use.
In order to make the CFI sufficiently robust each codeword is 32 bits in length. These 32 bits
are mapped to 16 resource elements using QPSK modulation.
The PCFICH is transmitted on the same set of antenna ports as the PBCH, with transmit
diversity being applied if more than one antenna port is used. In order to achieve frequency
diversity, the 16 resource elements carrying the PCFICH are distributed across the
frequency domain. This is done according to a predefined pattern in the first OFDM
symbol in each downlink subframe, so that the UEs can always locate the PCFICH
information, which is a prerequisite to being able to decode the rest of the control
signalling. To minimize the possibility of confusion with PCFICH information from a
neighbouring cell, a cell-specific frequency offset is applied to the positions of the PCFICH
resource elements; this offset depends on the Physical Cell ID, which is deduced from the
primary and secondary synchronization signals. In addition, a cellspecific scrambling
sequence (again a function of the Physical Cell ID) is applied to the CFI codewords, so that
the UE can preferentially receive the PCFICH from the desired cell.
hin the range specified in the standards for different bandwidths.

Feature Description
Benefits
Operator Benefits:
 Cell capacity is increased in cases where not all available PDCCH resource are needed.
End User Benefits:

 Subscribers may experience higher throughput in downlink in typical scenarios with
low load on PDCCH and high utilization of PDSCH
Release History
SLR2.2
Feature Scope
R1 LTE eNB operates the CFI adaptation.
R2 LTE eNB determines the number of CIFs based on the average number of CCEs and
the number of required CCEs.

Feature Description
Feature Description
CFI is transmitted via PCFICH and indicates the number of OFDM symbols used for
PDCCH in each DL subframe. The range of CFI value is between 1 and 3. The larger the
CFI value, more symbols are allotted for control region thus the number of available CCE
(Control Channel Element) is increased.CCE is a basic resource unit used for PDCCH.
To accommodate more PDCCH in a subframe, number of available CCE should be large
enough. However keeping large number of CCEs for PDCCH will be result in higher
control channel overhead and eventually reduce the system efficiency. CFI adaptation in
Samsung LTE system estimates appropriate number of required CCE for resource allocation
based on the result of past scheduling experience and decides the number of OFDM symbols
to be used for PDCCH while keeping the control channel overhead as low as possible.
CFI Adaptation
Basically, CFI value is determined first considering both average number of CCEs needed
in previous subframes and number of required CCEs needed in current subframes which
will be used for broadcast control channel allocation such as SIB, RAR and paging.
Then, TTI scheduler tries to allocate resource to selected UEs checking availability of CCE
if PDCCH is necessary for this allocation. Detailed procedure is as follows.
 Calculate the number of required CCEs in each DL subframe
− The number of CCEs successfully allocated is counted
− If a resource allocation trial fails by lack of CCE resource, the number of CCEs
needed at that trial is counted
− Resource allocation fail by CCE search space corruption is not counted
 Calculate average number of required CCEs
− IIR Filtering is used to calculate the average value
 Calculate final number of required CCEs
− Final number of required CCEs = Average number of required CCEs + number of
required CCEs for broadcast control channel (SIB, RAR, Paging)
 Determine CFI value based on the final number of required CCEs
Choose a CFI value that can accommodate the size of CCEs calculated above considering
the number of available CCEs in a symbol

Feature Description
System Operation
The CFI indicates how many OFDM symbols the DCI spans in the subframe. Such an
indicator is needed because the load on PDCCH varies, depending on the number of
resource blocks and the signaling format conveyed on PDCCH. As shown in below table,
for the system bandwidth N_RB > 10, the DCI spans 1, 2 or 3 OFDM symbols, given by
the value of the CFI; for system bandwidths N_RB < = 10, the DCI spans 2, 3, or 4 OFDM
symbols, given by CFI + 1.
Number of OFDM symbols Number of OFDM symbols

Subframe
for PDCCH when N_RB > 10 for PDCCH when N_RB <= 10
Subframe 1 and 6 for frame 1.2 2
structure type 2
MBSFN subframe on a carrier 1.2 2
supporting PDSCH, configured
with 1 or 2 cell-specific antenna
ports
MBSFN subframe on a carrier 2 2
supporting PDSCH, configured
with 4 cell-specific antenna
ports
Subframes on a carrier not 0 0
supporting PDSCH
Non-MBSFN subframes 1, 2, 3 2, 3
(except subframe 6 for frame
structure 2)
configured with positioning
reference signal
All other cases 1, 2, 32 2, 3, 4
The CFI uses a block code predefined based on (3, 2) simplex coding with repetition of
coding rate 1/16, the codewords of which are listed in below table. QPSK is the modulation
scheme. In addition, cell-specific scrambling tied to the cell identity is used.

N/A

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME1002, ME1004, CCE Aggregation for

PDCCH
Overview
The number of OFDM symbols used for PDCCH is determined based on the estimation
how many number of Control Channel Elements (CCE) was needed in previous subframes.
For a given CFI value, number of OFDM symbols reserved for PDCCH is determined and
finally derives number of available CCE. Using these available CCE, TTI scheduler tries to
allocate resource to selected UEs assuming those reserved symbols for PDCCH are not
changed until next TTI.
Introduction
A PDCCH carries a message known as Downlink Control Information (DCI), which
includes resource assignments and other control information for a UE or group of UEs.
In general, several PDCCHs can be transmitted in a subframe. Each PDCCH is transmitted
using one or more so-called Control Channel Elements (CCEs), where each CCE
corresponds to nine sets of four physical resource elements known as Resource Element
Groups (REGs). Four QPSK symbols are mapped to each REG. The resource elements
occupied by reference symbols are not included within the REGs, which means that the
total number of REGs in a given OFDM symbol depends on whether or not cell-specific
reference signals are present. The concept of REGs (i.e. mapping in groups of four resource
elements) is also used for the other downlink control channels (the PCFICH and PHICH).
Four PDCCH formats are supported, as listed in below table
PDCCH format Number of CCEs (n) Number of REGs Number of PDCCH bits
0 1 9 72
1 2 18 144
2 4 36 288
3 8 72 576
CCEs are numbered and used consecutively, and, to simplify the decoding process, a
PDCCH with a format consisting of n CCEs may only start with a CCE with a number
equal to a multiple of n. The number of CCEs used for transmission of a particular PDCCH
is determined by the eNodeB according to the channel conditions. For example, if the
PDCCH is intended for a UE with a good downlink channel (e.g. close to the eNodeB),
then one CCE is likely to be sufficient. However, for a UE with a poor channel (e.g. near
the cell border) then eight CCEs may be required in order to achieve sufficient robustness.
In addition, the power level of a PDCCH may be adjusted to match the channel conditions.

Feature Description
Benefits
Operator Benefits:
 Cell capacity is increased in cases where not all available PDCCH resource are needed.
End User Benefits:

 Subscribers may experience higher throughput in downlink in typical scenarios with
low load on PDCCH and high utilization of PDSCH.
Release History
SLR2.2
Reference
layer procedures’
Feature Scope
R1 LTE eNB determines the CCE aggregation level based on the wideband CQI and
outer-loop offset.
R2 LTE eNB updates the outer-loop offset in the light of reception of the DL/UL grant.
R3 LTE eNB supports the CCE aggregation level 4 boosted by 3 dB instead of the CCE
aggregation level 8.

Feature Description
Feature Description
Aggregation level of PDCCH is adaptively determined based on the channel status of target
UE to control PDCCH reception error rate as well as control channel overhead.
 Decision of CCE aggregation level
Basically, aggregation level of CCE is determined based on the channel status of target
UE. To estimate the channel status, wideband CQI as well as outer-loop offset is used
to reduce PDCCH overhead while maintaining PDCCH reception error rate lower than
a target value (e.g. 1 %). uter-loop offset value for PDCCH is managed by eNB and is
updated according to PDCCH is received by target UE successfully or not. Detection
of PDCCH reception by target UE is depicted in the following picture. For DL grant,
HARQ feedback is used to detect PDCCH missing. For UL grant, UL burst is used to
detect PDCCH missing.

Feature Description
 PDCCH Error Detection (DL grant)
 PDCCH Error Detection (UL grant)

If PDCCH fail is detected, eNB increases the outer-loop offset value to better protect
PDCCH. On the contrary, if PDCCH is successfully transmitted to the target UE, eNB
decreases the outer-loop offset value to use more aggressive aggregation level. To keep
the PDCCH error rate lower than target value, outer loop offset increment step size is
larger than decrement step size. Using wideband CQI and outer-loop offset, channel
quality of PDCCH for target UE is determined. By comparing the channel quality with
threshold value aggregation level of CCE is determined.
 CCE aggregation and power boosting for PDCCH

In LTE specification, CCE aggregation level of 1, 2, 4, 8 are supported but in Samsung
LTE system aggregation level of 8 is not used instead aggregation level 4 with 3 dB
boosting is used to avoid CCE search space corruption and to reduce control channel
overhead.
Common search space is mainly used for the allocation of broadcast control message
such as SIB (System Information Block), RAR (Random Access Response) and
paging. Size of common search space is 16 (CCE #0~#15) and aggregation level 4
with 3 dB boosting is used thus up to 4 PDCCH can be allocated at the same time.
Overlap between common search space and UE specific search space is allowed to
reduce waste of CCEs in common search space. Especially, broadcast control message
is allocated first in the common search space with higher priority than other UE
specific traffic, and remained CCEs can be used for UE specific allocation.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME1101, PDSCH Resource Allocation

Overview
PDSCH resource allocation types 0, 1 and 2
Introduction
In an SC-FDMA or OFDM system, the frequency-domain resource allocation information
needs to be signed to the UE. Because of the large number of resource blocks within the
frequency band, the resource allocation is one of the largest fields in the downlink control
information. In the case of SC-FDMA uplink, the allocated resource blocks need to be
contiguous to guarantee single-carrier property. While the contiguous resource allocation
can be signaled with the minimum of signaling bits, it also results in limiting the
scheduling flexibility. In the case of OFDM, non-contiguous resource blocks can be
allocated thus providing maximum scheduling flexibility. However, the signaling overhead
also increases for non-contiguous resource block allocation. In order to provide various
choices of scheduling performance and signaling overhead, multiple resource allocation
types are defined. A contiguous resource allocation scheme is defined for both and the
uplink and the downlink. As pointed out earlier, a contiguous resource allocation is
necessary in the uplink due to single-carrier access. In the downlink, contiguous resource
allocation provides a low overhead alternative while limiting scheduling flexibility, In
addition to contiguous resource allocation, two types of non-contiguous resource allocation
using a bitmap-based signaling are defined for the downlink.
Benefits
Operator Benefits:
 Enable to enhance a flexibility in spreading the resources across the frequency domain
to exploit frequency diversity.
Release History
SLR2.2

Dependency:
 None
Limitation:
 Samsung eNB currently does not consider downlink resource allocation type 1.

Feature Description
Reference
1) Telefonica, Req20, ‘The Vendor’s LTE solution shall support functionality to enquire
UE capability and record number of UEs per eNodeB and per cell for each UE
category’, Telefonica RFP (‘12.04)
layer procedures
Feature Scope
R1 LTE eNB supports the resource allocation type 0 / 2.
R2 LTE eNB allocates the RB or RBG according to the resource allocation type.
R3 LTE eNB applies the DCI format according to the resource allocation type.
R4 LTE eNB provides a function to automatically change the resource allocation type te
be applied for system optimization.

Feature Description
Feature Description
Downlink Resource Allocation Type 0
 A type 0 downlink Resource Block allocation can be signaled from the eNB to the UE
using Downlink Control Information (DCI) format 1, 2, 2A, 2B and 2C.
 An allocation received during downlink subframe ‘n’ defined the allocated Resource
Blocks within the same downlink subframe.
 A type 0 Resource Block allocation uses a bitmap to indicate which Resource Block
Groups (RBG) are allocated to the UE. A single RBG is a set of consecutive Resource
Blocks. The allocated RBG do not need to be contiguous.
 The number of Resource Blocks within an RBG is predetermined and is a function of
the channel bandwidth. The RBG size as a function of the channel bandwidth is shown
in below table.
 Resource Block Group (RBG) for Resource Block Allocation type 0
 Each channel bandwidth includes a number of complete RBG. A partial RBG is also
included if the total number of Resource Block is not a multiple of the RBG size.
 The bitmap signaled using the Type 0 Resource Block allocation includes a single bit
for each RBG. A value of 1 indicates that the RBG has been allocated to the UE.
 Below figure illustrates the RBG for the channel bandwidth of 5MHz.
 3GPP Reference: TS 36.213
Below figure is Type 0 downlink Resource Block Allocation.

Feature Description

using Downlink Control Information (DCI) format 1, 2, 2A, 2B and 2C. An allocation
received during downlink subframe ‘n’ defined the allocated Resource Blocks within
the same downlink subframe.
 Type 1 Resource Block allocations are not applicable to the 1.4 MHz channel
bandwidth. DCI formats 1, 2, 2A always signal a type 0 Resource Block allocation
when the channel bandwidth is 1.4 MHz.
 Type 1 Resource Block allocations are divided into 3 sections: Resource Block Group
(RBG) subset number, Resource Block offset flag, Resource Block bitmap
 The RBG sizes are the same as those specified for a Type 0 Resource Block allocation.
The number of RBG subsets is equal to the RBG size. The RBG size and the number
of RBG subsets for each channel bandwidth are shown in the Table. 2.
Below table is RBG sizes and RBG subsets for Resource Block Allocation type 1
 The number of bits used to signal the RBG subset is either 1 or 2 depending on the
number of subsets. The Resource Blocks allocated to a UE always belong to a single
RBG subset.
 The Resource Block offset flag indicates whether the subsequent Resource Block
bitmap should be aligned with the bottom of the lowest Resource Block within the
subset, or aligned with the top of the highest Resource Block within the subset.
This offset is necessary because the bit map is not sufficiently large to include all
Resource Blocks within the subset.

Feature Description

using Downlink Control Information (DCI) format 1A, 1B, 1C and 1D.
 An allocation received during downlink subframe ‘n’ defined the allocated Resource
Blocks within the same downlink subframe.
 The resource allocation can be made in terms of: contiguous virtual Resource Blocks
(also known as localized Resource Blocks), or distributed virtual Resource Blocks.
 DCI 1A, 1B and 1D include a flag to indicate whether the resource allocation is
contiguous or distributed. DCI 1C always allocates distributed virtual Resource Blocks.
 The set of allocated virtual Resource Blocks are mapped onto the set of allocated
physical Resource Blocks.
 Contiguous virtual Resource Blocks are contiguous both before and after mapping
onto their physical Resource Blocks. In this case, the set of allocated physical
Resource Blocks is the same as the set of allocated virtual Resource Blocks.
In addition, the Resource Block allocation is the same in both time slots belonging to
the subframe.
 Contiguous allocations can range from a single virtual Resource Block to the complete
set of virtual Resource Blocks spanning the entire channel bandwidth.
 Contiguous virtual Resource Block allocation are signaled using Resource Indication
Values (RIV). The calculation of the RIV is the same as when calculating the RIV for
type 0 uplink resource allocations.
 Distributed Resource Block allocations make use of ‘Gap 1’ and ‘Gap 2’ parameters.
These parameters define an offset between the physical Resource Block allocations
during the first and second time slots of the subframe.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME1503, PUSCH Frequency Hopping

Overview
Support PUSCH hopping types 1 and 2. Two types for frequency hopping, enabled by
higher layer signaling, from one to the other time slot (intra-subframe) and from one to the
other subframes (inter-subframe), or just between subframes. Using hopping enables the
UE to exploit the frequency diversity of the wideband channel used in LTE while keeping
the required contiguous allocation.
Introduction
Uplink resource blocks allocated by type 0 resource allocations are always contiguous.
This helps to reduce the peak-to-average ratio of the transmitted signal and consequently
improves the transmit power amplifier efficiency. A drawbach of contiguous allocation is
reduced potention for frequency diversity. Allocating a small number of resource blocks
means that the resource allocation spans only a small bandwidth and the propagation
channel is relatively well correlated for all resource blocks within the allocation.
Allocating a large number of resource blocks increases the potential for frequency diversity
because the resource allocation spans a wider bandwidth.
Uplink frequency hopping provides frequency diversity while allowing the resource
allocations to remain contiguous. This is particularly beneficial to small resource block
allocations which do not inherently benefit from frequency diversity. Uplink frequency
hopping is applicable to type 0 resource allocations when the frequency hopping flag
within DCI format 0 is set to 1. Frequency hopping is not applied to type 1 resource
allocations, nor to any uplink resource allocation made using DCI format 4. When hopping
is used, the resource block allocation field within DCI format 0 includes either 1 or 2
hopping bits. The number of bits is dependent on the channel bandwidth. The value of the
hopping bits determines whether type 1 or type 2 hopping is applied. Below table presents
the number of hopping bits associated with each channel bandwidth, and their relationship
with type 1 and type 2 hopping.
 Hopping bits within the Resource block allocation of DCI format 0

Feature Description
Benefits
Operator Benefits:
 Frequency diversity effects can be exploited and interference can be averaged.
Release History
SLR2.2

Dependency:
 For DCI format type 0
Reference
layer procedures
2) 3GPP TS 36.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification

Feature Description
Feature Description
The resource mapper maps the complex-valued modulation symbols in sequence on to the
physical resource blocks assigned for transmission of PUSCH. In LTE, only localized
resource allocation is supported in the uplink due to its robustness to frequency offset
compared to dustrnbuted resource allocation. Localized resource allocation also retains the
single-carrier property in the uplink transmission. As a consequence, there is very little
frequency diversity gain. On the contrary, in the downlink it is possible to allocate disjoint
sets of resource blocks to a UE to extract some frequency diversity gain. To alleviate this
issue, LTE supports frequency hopping on PUSCH, which provides additional frequency
diversity gain in the uplink. Frequency hopping can also provide interference averaging
when the system is not 100 % loaded.
Type 1 PUSCH Hopping

Type 1 hopping divides the channel bandwidth into a fixed number of subbands.
Hopping is then supported between those subbands. The number of subbands is fixed by
3GPP and is dependent on the channel bandwidth. The number of subbands associated with
each channel bandwidth is presented in below table. This table also presents the maximum
number of contiguous resource blocks which can be allocated when using type 1 hopping.
 Number of subbands and Max. contiguous resource blocks for Type 1 hopping
Below figure illustrates an example for the 5MHz channel bandwidth. This example
assumes that the PUCCH occupies a total of 4 resource blocks per time slots at the upper
and lower edges of the channel bandwidth. RRC signaling is used to inform the UE that
these resource blocks are not available for hopping. The PUSCH hopping offset (H RB HO)
which can be included within an RRC connection reconfiguration message is used for this
purpose. The signaled value of the hopping offset is rounded up to an even number if an
odd number is sent to the UE.

Feature Description
Below figure is Type 1 hopping for 5MHz channel bandwidth.
The example in Figure assumes that DCI format 0 allocates the UE with 4 resource blocks
at the lowest possible position within hopping subband 1. The resource blocks move to the
lowest possible position within hopping subband 2 when hopping is applied.
The allocated resource blocks are contiguous before and after hopping.
Type 2 PUSCH Hopping

Type 2 hopping allows the number of subbands to be configured by the network.
The number of subbands can be set to a value between 1 and 4, and is signaled to the UE
using RRC signaling, e.g. within the PUSCH configuration of an RRC connection
reconfiguration message. The maximum number of contiguous resource blocks which can
be allocated to a UE is dependent on the channel bandwidth, the number of subbands and
the number of resource blocks reserved for the PUCCH. The maximum number of
contiguous resource blocks which can be allocated to a UE is dependent on the channel
bandwidth, the number of subbands and the number of resource blocks reserved for the
PUCCH. Some example figures are presented in below table. The hopping offset represents
the total number of resource blocks reserved for the PUCCH within a time slot.

Feature Description
 Maximum contiguous allocated resource blocks for type 2 hopping
The resource block allocations of {2, 4, 10, 10, 13, 20} appearing in the fourth row of
results in Table represent the upper limit of the contiguous allocation sizes. These figures
decrease as the number of subbnads and as the PUCCH reservation increases. Configuring
a single subband represents a special case which generates ‘mirroring’ of the resource
block allocation around the center of the channel bandwidth. Example of mirroring are
illustrated in below figure. Below figure is Type 2 hopping with single subband in 5 MHz
channel bandwidth (Mirroring).

Feature Description
Configuring multiple subbands leads to hopping based on predefined hopping patterns.

These hopping patterns are defined such that the allocations belonging to different UE do
not clash. The function used to generate the hopping pattern is presented in [1].
The results from the hopping pattern function is the allocated physical resource blocks with
indexing which starts at 0 just above the lower PUCCH allocation.

Feature Description
System operation
RTRV-PUSCH-CONF nSB Define the number of subband at PUSCH Hopping

CHG-PUSCH-CONF Range: 1~4
Default: 1
hoppingMode PUSCH Hopping mode connect
0: Inter-subfrfame hopping
1: Intra-and-inter subframe hopping
Range: 0~1
Default: 0
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME1504, PUCCH Format

Overview
The PUCCH supports different formats depending on the information to be signaled.
The mapping between the PUCCH format and the Uplink Control Information (UCI)
supported in LTE. PUCCH format 1,1A, 1B, 2, 2A, 2B
Introduction
The amount of control information which a UE can transmit in a subframe depends on the
number of SC-FDMA symbols available for transmission of control signaling data (i.e.
excluding SC-FDMA symbols used for reference signal transmission for coherent
detection of the PUCCH). The PUCCH supports seven different formats depending on the
information to be signaled. In this feature, PUCCH format 1, 1A, 1B, 2, 2A, 2B will be
described except for format 3, which transfer HARQ acknowledgements for carrier
aggregation and scheduling requests.
Benefits
Operator Benefits:
 minimize the resources needed for transmission of control signaling
Release History
SLR2.2
Reference
2) 3GPP TS 36.212 Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing
and channel coding
layer procedures

Feature Description
Feature Description
 The Physical Uplink Control Channel (PUCCH) is used to transfer uplink control
information (UCI). UCI can be transferred using the PUCSH.
 The release 8 and 9 versions of the 3GPP specifications do not allow an individual UE
to transmit both the PUCCH and PUSCH during the same subframe. If a release 8 and
9 UE has application data or RRC signaling to send then UCI is transfered to using the
PUSCH. A release 8 and 9 UE transfers UCI using the PUCCH if it does not have any
application data nor RRC signaling to transfer.
 In the case of TDD, the PUCCH is not transmitted within the UpPTS field of special
subframes.
 3GPP TS 36.211 and TS 36.213 specify the 6 PUCCH format presented in below table.
PUCCH formats 2a and 2b are not applicable when using the extended cyclic prefix.
Below table is Information transferred by each PUCCH format.
 The PUCCH is able to transfer various combinations of Scheduling Requests (SR),

Hybrid Automatic Repeat reQuest (HARQ) acknowledgements and Channel State
Information (CSI) reports. CSI reports can include Channel Quality Indicators (CQI),
Precoding Matrix Indicators (PMI), and Rank Indicators (RI). In summary,
1) PUCCH formats 1, 1a and 1b transfer HARQ acknowledgements and scheduling
requests
2) PUCCH format 2, 2a and 2b transfer HARQ acknowledgements and CSI reports
 The number of bits associated with PUCCH format is used to generate modulation
symbols prior to further baseband processing and mapping onto Resource Elements.
The number of bits is small when HARQ acknowledgements and scheduling requests
are transferred.
 The modulation scheme and the number of Resource Elements occupied by each
PUCCH format is presented in below table.

Feature Description
Below table is Modulation scheme and number of Resource Elements for each PUCCH
format.
 A single PUCCH transmission always occupies 2 Resource Blocks which are

distributed across the 2 time slots belonging to a subframe.
 Each pair of REsource Blocks allocated to the PUCCH can be used simultaneously by
multiple UE. The use of different cyclic shifts and different orthogonal spreading
codes allows the eNB to differentiate the PUCCH transmissions from multiple UE
sharing pair of Resource Blocks.
 PUCCH format 1/1a/1b is based in the combination of CAZAC sequence modulation
and block-wise spreading whereas PUCCH format 2/2a/2b utilizes only CAZAC
sequence modulation. As a result, format 1/1a/1b can only carry one information
symbol (1 or 2 bits) per slot while format 2/2a/2b is capable of conveying 5 symbols
per slot (20 coded bits + ACK/NACN per sub-frame).
 With format 2/2a/2b, the CQI data is encoded using a punctured (20, N) Reed-Muller
block codes.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME2019, ME2030, DL SU 2x2 MIMO

Overview
The Long Term Evolution (LTE) standard for mobile broadband includes multi-antenna
transmission modes that improve performance in terms of coverage, spectral efficiency and
peak throughput. Single-user multi-antenna technologies are well supported in current
standard specifications like LTE Release 8/9. Further development of the specification is
expected to conform to the requirements for IMT-Advanced systems. Here, it is focused on
a major operations i.e. transmit diversity and spatial multiplexing, of SU-MIMO in 2x2
downlink MIMO channel environment.
Introduction
Multiple Input Multiple Output (MIMO) configurations benefit from multiple antenna
elements at the transmitter and multiple antenna elements at the receiver. MIMO contrasts
with receiver diversity which only requires multiple antenna at the receiver, and transmit
diversity which only requires multiple antenna at the transmitter. The general concept of
MIMO is illustrated in below figure. The Multiple input component refers to multiple
transmissions into the propagation change, whereas the multiple output component refers to
multiple signals being received out of propagation channel. Similar terminology is used for
Single Input Multiple output (SIMO), Multiple Input Single Output (MISO) and Single
Input Single output (SISO).

Feature Description
The benefits of MIMO are summarized as follows:

 Diversity gain reduces the impact of fading when the fades on each propagation path
are uncorrelated, i.e. one path may experience a fade while another path may not
experience a fade. The receiver takes advantage of the paths which are not
experiencing fades
 Spatial multiplexing gain increases throughput by transferring multiple streams of data
in parallel using the same set of time and frequency resources. Uncorrelated
transmission paths allow the receiver to differentiate between the data streams.
UE experiencing good coverage (with high signal to noise ratios) can take advantage of the
spatial multiplexing gain and can receive multiple parallel streams of data. The maximum
number of parallel streams is given by the minimum of the number of transmit and receive
antenna. For example 2x2 MIMO are capable of transferring a maximum of 2 parallel
streams of data. Maximizing throughput also relies on having uncorrelated propagation
paths between the transmit and receive antenna. UE in poor coverage (with a low signal to
noise ratios) can take advantage of the diversity gain to help improve their signal to noise
ratio. The magnitude of the diversity gain is dependent on the number of receive antenna
and the level of correlation between each of the propagation paths, i.e. the gain is
maximized for a large number of receive antenna and uncorrelated propagation paths.
This dependency on channel conditions means that MIMO is used to transfer multiple
parallel streams of data in good coverage conditions to maximize throughput, and is used to
transfer a single stream of data in poor coverage conditions to maximize the diversity gain.
Benefits
Operator Benefits
 Provide improvement in cell capacity and throughput as UEs with good channel
conditions can benefit from the multiple streams transmission.
End User Benefits

 Served the improved throughput or reliable communication due to the multiple
streams transmission.
Release History
SLR2.2

Feature Description
Reference
layer procedures’
Feature Scope
R1 LTE system should be supported MIMO scheduling.
R2 LTE Channel Card should be supported 2x2 MIMO scheduling.
R3 LTE system should be supported 2x2 open/close-loop spatial multiplexing SU-MIMO
function.

Feature Description
Feature Description
MIMO is referred to as spatial multiplexing within 3GPP TS 36.211. This specification has
separate sections for spatial multiplexing, transmission on a single antenna port and
transmit diversity. The release 8 and 9 versions of the 3GPP specifications support:
 2x2 MIMO: 2 transmit antenna ports + 2 receive antenna ports
 4x4 MIMO: 4 transmit antenna ports + 4 receive antenna ports
3GPP has specified the following variants of MIMO

 open loop spatial multiplexing
 closed loop spatial multiplexing
Open loop spatial multiplexing involves feedback from the UE in terms of Rank indication
(RI) and Channel Quality Indicator (CQI). It is categorized as ‘open loop’ because the UE
is not required to provide feedback in terms of a Precoding Matrix Indicator (PMI).
Closed loop spatial multiplexing involves feedback from the UE in terms of RI, CQI and
PMI. The UE selects a PMI to maximize the signal to noise ratio at its receiver.
Applying the set of precoding weights at the eNB represents a form of maximum ratio
combining at the transmitter.
MIMO can transfer either 1 or 2 codewords during each 1ms subframe. A codeword is a
transport block which has been processed by the physical layer in terms of CRC addition,
channel coding and rate matching. When 2 codewords are transferred, they do not need to
be of equal size. CQI reporting, link adaptation and HARQ run independently for each
codeword. In some cases, a single HARQ acknowledgement is used for multiple
codewords due to the constraints in signaling capacity, e.g. ACK/NACK multiplexing for
TDD.
Generating a MIMO signal at the transmitter involve:

 Layer mapping: maps the modulated symbols belonging to either 1 or 2 codewords
onto a number of ‘layers’ where the number of layers is less than or equal to the
number of antenna ports.
 Precoding: applies coding to the ‘layers’ of modulated symbols prior to mapping onto
resource elements and subsequent OFDMA signal generation
The general structure of layer mapping and precoding is illustrated in below figure.

Feature Description
Below figure is Signal processing for transmit diversity and spatial multiplexing (MIMO).
The symbols d, x and y are used in the specifications to denote signals before and after
layer mapping and after precoding, respectively
2x2 MIMO is limited to transmitting either 1 or 2 layers from 2 antenna ports:

 using 1 layer allows 1 codeword to be transferred during each 1ms subframe and is
applicable to when RF channel condition relatively poor, or when the eNB does not
have much data to transfer
 using 2 layers allows 2 codewords to be transferred during 1ms subframe and is
applicable to when RF channel conditions are good. Transferring 2 codewords across
2layers allows peak connection throughputs to be doubled.
1) Transmit Diversity
Transmit diversity increases resilience against the propagation channel.
Transmit diversity requires multiple antenna elements at the transmitter and one or
more antenna elements at the receiver. 3GPP has specified open loop transmit diversity
so precoding feedback from the UE is not required. The UE provides feedback in
terms of CQI to help the eNB select an appropriate transport block size.
Transmit diversity transfers a single modulated codeword during each 1ms subframe.
The LTE transmit diversity scheme for 2 antenna ports is known as a Space-Frequency
Block Code (SFBC) approach
The term ‘space’ is used because each modulated symbol is transmitted from
multiple antenna elements, and those antenna elements have a physical separation
The term ‘frequency’ is used because each modulated symbol is mapped onto
multiple resource elements, and those resource elements have a frequency
separation, i.e. they use different subcarriers
Transmit diversity can be applied to the PDSCH, PBCH, PCFICH, PDCCH and
PHICH physical channel. Below figure illustrates the flow of two example modulation
symbols through the processing for transmit diversity with 2 antenna ports

Feature Description
Below figure is Flow of two example modulation symbols through processing for transmit
diversity.
2) Open Loop Spatial Multiplexing

Open loop spatial multiplexing was introduced within the release 8 version of 3GPP
specifications. This mode is applicable to transmission 3, and relies on the UE
providing feedback in terms of: Rank Indicator (RI): suggested number of ;layer’ and
Channel Quality Indicator (CQI): suggested transport block size. This approach is
categorized as ‘open loop’ because the UE is not required feedback in terms of a
Precoding Matrix Indicator (PMI). 3GPP has specified Large Delay Cyclic Delay
Diversity (CDD) as a solution for open loop spatial multiplexing. Introducing delays
generates diversity across the transmitted signals. The input samples belonging to each
layer are multiplied by Unitary matrix prior to having the CDD applied. The unitary
matrix ensures that each input provided to the CDD includes a combination of the
original input layers. This means that each antenna port transmits a combination of all
layers but with different time delays.
2x2 open loop spatial multiplexing always transfer 2 codewords during each subframe.
Transmit diversity provides the 2x2 openloop solution for transferring a single
codeword. UE can be switched between 2x2 transmit diversity and 2x2 open loop
spatial multiplexing depending on coverage conditions:
 transmit diversity can be used to transfer 1 codeword when coverage is poor
 open loop spatial multiplexing can be used to transfer 2 codewords when coverage
is good
In spatial diversity there is no signal redundancy as there is with transmit diversity;

antenna ports transmit different symbols. There are two modes that provide spatial
diversity; TM3 and TM4. TM3 uses a predetermined CDD-based precoding and
favorable to high speed UEs. TM4 uses a codebook-based precoding and favorable to
low speed UEs because scheduler adopts the best precoder per UE based on the
precoder feedbacked by UE. For both TM3 and TM4, rank adaptation based on
feedbacked rank information is supported so that the most appropriate number of
transmission layers (and codewords) can be adopted.

Feature Description
3) Transmission mode 4
TM 4 is spatial multiplexing scheme that uses channel feedback-a PMI index from UE,
to construct downlink PDSCH codeword to maximize signal to noise ratio at UE
receiver. A PMI index is a pointer to a set of pre-coding weights that are applied to
downlink code-words prior to transmission. The process of applying pre-coding is
defined in 3GPP specification TS 36.211. TM 4 is suitable for scenarios when the UE
is in slow time-varying channel because there is a delay associated with a PMI report
from UE and a corresponding downlink transmission that utilizes the requested PMI
index. A stationary or pedestrian speed UE in good RF coverage scenario will get the
most benefit from this mode.

Feature Description
System operation
 Related Commands
Command Description
RTRV-DL-SCHED Retrieves the downlink MIMO scheduling configuration information for

MAC layer within the eNB.
CHG-DL-SCHED Changes the downlink MIMO scheduling configuration information for
MAC layer within the eNB.
 Related Parameters
dlMimoMode Set the DL MIMO parameter value. Refer to the related commands
Range: 0, 1, 3
- 0 (SM/MU-MIMO disable),
- 1 (SM enable),
- 3 (Test Mode: CL-SM default mode)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME2020, 4Rx Diversity

Overview
Rx diversity is a combining technique to obtain diversity gain in eNB receiver.
Introduction
Tho most prevalent form of spatial diversity is retrieve diversity, often with just two
antennas. This type of diversity is nearly ubiquitous: 2 receive antennas being by far the
most common on cellular base stations and wireless LAN access points, and is mandatory
for eNBs and handsets. Receive diversity on its own places no particular requirements on
the transmitter, but requires a receiver that processes the multiple received streams and
combines them in some fashion. Because receiver diversity places no requirements in the
transmitter, these techniques are not specified in the LTE specification. Nevertheless, they
most certainly are used in all LTE handsets and eNBs.
Benefits
Operator Benefits:
 Enable to facilitate receiving diversity to select one better qualified path or combine
two paths.
 Enable to communicate the more reliable transmission condition.
Release History
SLR2.2

Dependency:
 For DCI format type 0
Reference
1) 3GPP TS 36.201 Evolved Universal Terrestrial Radio Access (E-UTRA); LTE physical
layer; General description
2) Goldsmith, A. J. Wireless communications. Cambridge University Press, 2005
Feature Scope
R1 The decoding is performed after combining the signals received from two physical
antennas within the same sector.

Feature Description
Feature Description
Selection Combining (SC)
Selection combining is the simplest type of combiner in that it simply estimates the
instantaneous strengths of each of the N r streams, and select the highest one.
Since SC ignores the useful energy on the other streams, it is clearly suboptimal, but its
simplicity and reduced hardware and power requirements make it attractive for narrowband
channels. In a wideband channel, different coherent band will have different SNRs, and so
although selection diversity can be used on each band, which nullifies one of the main
arguments in favor of selection diversity.
Below figure is Receive diversity: Selection combining (SC) and Maximal ratio combining
(MRC).
Maximum Ratio Combining (MRC)

Maximum ratio combining (MRC) combines the information from all the received
branches in order to maximize the ratio of signal-to-noise power, which gives it its name.
MRC works by weighting each branch with a complex factor weight and then adding up
the N r branches as shown in upper figure. An important advantage of MRC in frequency
selective fading channels is that all the frequency diversity can be utilized, whereas an RF
antenna selection algorithm would simply select the best average antenna and then must
live with the potentially deep fades at certain frequencies. Samsung eNB considers MRC as
a receiver diversity technique.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME3001, ME3003, ME3004, Power Control

Overview
In the uplink, the terminal decides output power from the RSRP measurement and system
parameter setting value and this is called open-loop power control. The base station may
adjust output power by transmitting TCP (transmit power control) command to the phone
for various purposes of scheduling. This is called close-loop power control.
Introduction
In the uplink, the output power of the phone may be adjusted variously through the system
parameter setting by physical channel. The phone decides its output power through system
parameter setting and RSRP measurement. The base station may adjust the output power of
the terminal for various purposes including the purposes of improving the performance of
cell throughput, etc., expanding coverage through interference mitigation or guaranteeing a
proper reception level to satisfy the specific service.
Benefits
 Possible to achieve various purposes including the purposes of improving performance
or expanding coverage according to the operating environment through the close-loop
power control.
 Possible to prevent the unnecessary power consumption of the terminal and stabilize
receiving performance.
Release History
SLR2.2
Reference
layer procedures
3) 3GPP TS 36.101 Evolved Universal Terrestrial Radio Access (E-UTRA); User
Feature Scope
R1. In case of PUSCH power control, the function excluding ICIC is basically operated.
ICIC increases the uplink interference level and if performance or coverage is
lowered, it can be used by additionally setting enable.
R2. Possible to use the grouped TPC (DCI format 3) for PUSCH/PUCCH.

Feature Description
Feature Description
The output power of the phone in the LTE uplink is performed by physical channel
including PRACH, SRS, PUSCH and PUCCH. Herein, PRACH is operated only by the
system parameter set without any control of the base station and SRS is operated in
connection with the output power of PUSCH. Accordingly, the power control of PUSCH
and PUCCH is handled focusing on the role of the base station.
PUSCH
In the LTE uplink, the PUSCH transmission power of the phone is under the following
formula as defined in the TS 36.213[1] standard:
P_PUSCH(i) = min{P_cmax, Po_PUSCH + alpha*PL + 10*log10 (M_PUSCH(i)) +
delta_TF(i) + f(i)
 Pcmax: The max power of UE (dBm)
 M_PUSCH(i): No. of PUSCH RBs to transmit in subframe i
 Po_PUSCH: The target value of reception power of PUSCH (dBm).
Po_nominalPUSCH.
 alpha: A constant deciding the compensation percentage when compensating pathloss
 PL: The downlink pathloss measured by the phone (dB)
 f(i): Reflecting the accumulated or absolute value of TPC command received from the
base station
The LTE uplink power control may be largely divided into open-loop power control and
closed-loop power control and the main features are as shown below.
Open-loop power control

In the LTE uplink, the phone decides the initial transmission power according to the open-
loop power control and changes the transmission power according to TPC power control
obtained from the base station. The open-loop power control decides transmission power to
make the defined target receiving signal power value, i.e. the value from Formula (1) be
measured from the base station. To set the target signal level from the receiver of the base
station, the phone decides transmission power to presume the pathloss of the base station
and compensate the pathless. The estimate of the pathloss of the base station and the phone
is obtained by using the difference between the transmission power and reception power of
the reference signal (RS). At the time, the transmission power of RS can be identified
through SIB, a broadcast message transmitted from the base station. In short, the value
reflected to the transmission power of the uplink becomes the pathloss of the down link.
When the transmission power is decided in the LTE, not all but part of pathlosses may be
compensated and the percentage is decided with the alpha value of Formula (1).
In the specifications, eight values including 0, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, and 1.0 may be
used. If the alpha is 0, no pathloss is compensated and if it is 1, all pathlosses are
compensated.

Feature Description
If all pathlosses are compensated, unless the phone has the lack of the power, the signals of
all phones received from the base station have the same intensity (without fading or in the
long term perspective). If partial compensation is applied, it is possible to mitigate
interference between cells by increasing the SINR of the phone from the base station in the
cell center area relatively higher than the SINR in the cell middle or edge areas and
reducing the transmission power of the phone in the cell edge area. Accordingly, this has
the advantage to increase cell throughputs.
Closed loop power control

In the LTE, the base station may control the transmission power of the terminal by
transmitting the TPC (transmit power control) command to the phone. The TPC command
may be transmitted to the phone through PDCCH DCI format 0, 3 or 3A, and the phone
controls transmission power by reflecting the received TPC command value to the f(i) of
Formula (1). The TPC command value received from the base station may be applied by
accumulating the received value under the designated method in the upper layer (an
accumulated mode) or the received absolute value (an absolute mode). As such, the method
for controlling the uplink transmission power of the phone from the base station is called
closed loop power control (CLPC) and the main purposes are as follows:
 Inter-cell interference coordination (ICIC): The excessively high interference between
cells triggers throughput and coverage loss. Accordingly, the base station controls the
reception power of each phone to mitigate interference between cells, and may
enhance the throughput of the UE in the cell-edge area and prevent the reduced cell
coverage.
 Compensation of output power error of phones: The phone finds its scheduling
information by performing the blind detection of PDCCH. At the time, even though
the base station did not transmit the UL grant to a specific phone but the phone may
mistake as if the UL grant was transmitted to it and this is called the false alarm of
PDCCH (detection). In case of the false alarm of PDCCH, the terminal reflects a
random TPC command value included in the UL grant to the output power. The base
station may compensate the output power error of such phone through LPC.
 Guarantee of properly received SINR: If the phone has unnecessarily high output
power over the required SINR of the maximum MCS, the power is limited or if it fails
to satisfy the required SINR based on the minimum MCS or the target MCS of the
specific service, the output power of the phone is increased to stably receive PUSCH.

Feature Description
PUCCH
The purpose of the power control of PUCCH channel is to guarantee the stabilized
reception of each PUCCH format that is transmitted by the phone. The output power of
PUCCH of the phone is decided as follows under the TS 36.213[1] standard:
P_PUCCH(i) = min{Pcmax, Po_PUCCH + PL + h(n_CQI, n_HARQ) + delta_F + g(i)
 Pcmax: The max power of UE (dBm)
 h(n_CQI, n_HARQ): number of information bit for CQI or HARQ.
 Po_PUCCH: The target value of reception power of PUSCH (dBm).
Po_nominalPUSCH.
 PL: The downlink pathloss measured by the phone (dB)
 delta_F: The transmission power offset values of other formats compared to the
PUCCH format 1a standard.
 g(i): The accumulated value of the TPC command received from the base station.
Differently from PUSCH, PUCCH compensates all pathlosses measured by the phone and
the number of RB is also set to be 1. In addition, the output power is decided depending on
the number of transmission information bits. The base station transmits the TPC command
to the phone to collect to the received SINRdl target SINR by comparing the received
PUCCH SINR and the target SINR. The TPC command for PUCCH is transmitted to the
phone through the DL grant.

Feature Description
System operation
CHG-PWR-PARA p0NominalPUSCH Target received signal power on PUSCH. Valid range

RTRV-PWR-PARA alpha set is {-126~24} in dBm. Default value is -80 dBm.
p0NominalPUCCH Pathloss compensation factor for PUSCH
deltaFPUCCHForm transmission. Valid range set is ENUMERATED {al0,
at1 al04, al05, al06, al07, al08, al09, al1}, where al0
deltaFPUCCHForm corresponds 0, al01 to 0.1 and al1 to 1 and so on.
at1b Default value is 5 (0.8).
deltaFPUCCHForm Target received signal power on PUCCH. Valid range
at2 set is {-127~-96} in dBm.Default value is -112 dBm.
deltaFPUCCHForm The difference in the transmission power between
at2a PUCCH format1a and PUCCH format1. Valid range
deltaFPUCCHForm set is ENUMERATED {deltaF-2, deltaF0, deltaF2}
at2b and default value is 1 (0 dB)
deltaPreambleMsg3 The difference in the transmission power between
PUCCH format1a and PUCCH format1b.Valid range
set is ENUMERATED {deltaF1, deltaF3, deltaF5} and
default value is 0 (1 dB)
The difference in the transmission power between
PUCCH format1a and PUCCH format2.Valid range
set is ENUMERATED {deltaF-2, deltaF0, deltaF1,
deltaF2} and default value is 1 (0 dB)
PUCCH format1a and PUCCH format2a.Valid range
set is ENUMERATED {deltaF-2, deltaF0, deltaF2}
and default value is 1 (0 dB)
PUCCH format1a and PUCCH format2b.Valid range
set is ENUMERATED {deltaF-2, deltaF0, deltaF2}
and default value is 1 (0 dB)
preamble and message3. Valid range set is (-1~6)
and default value is 0. The actual value is IE value *
2[dB].

Feature Description
(Continued)
CHG-ULPWR-CTRL p0UePUSCH UE specific power offset in dB for PUSCH

RTRV-ULPWR-CTRL p0UePUCCH transmission. Valid range set is (-8~7) and default
accumulationEnabled value is 0.
deltaMCSenabled UE specific power offset in dB for PUCCH
pSRSoffset transmission. Valid range set is (-8~7) and default
value is 0.
Config whether to accumulate the TPC (transmit
power control) command receiving from eNB in
PUSCH transmission. TRUE corresponds to
‘enable’ and default value is TRUE.
Ks. Config whether to apply different PUSCH
power offset for each MCS. TRUE corresponds to
‘enable’ and default value is FALSE (disable).
PUSCH and SRS. Valid range set is (0~15) and
default value is 7. The actual value is -10.5 +
1.5*IE value[dB] for Ks=0.
srsHoppingBandwidth Range: 0~3 This parameter can be changed/retrieved from

Default:0 the command of CHG-DPHY-ULSRS/RTRV-
DPHY-ULSRS.
duration Range: 0~1 This parameter can be changed/retrieved from
Default:1 the command of CHG-DPHY-ULSRS/RTRV-
DPHY-ULSRS.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A

Feature Description
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME3005, DL Power Allocation

Overview
Relative PDSCH power for reference symbols defined by two different parameters: p A and
p B.
Introduction
Unlike the uplink power control, there is no explict feedback from the UEs to control the
eNB transmit power for the downlink power control, The power levels for dedicated
control channels such as PDCCH and PHICH can be determined based on downlink
channel quality feedback from the UEs. The downlink channel quality feedback is provided
by the UEs to support channel sensitive scheduling in the downlink. Therefore, the
downlink transmit power control is fundamentally a power allocation scheme rather than a
power control scheme. Since the control channel transmissions are spread over the whole
system bandwidth, wideband channel quality information is used to determine the power
levels for these control channels. It should be noted that various channel quality feedback
formats are supported and wideband channel quality is always present in all the feedback
formats to enable power control for the downlink control channels. The downlink power
control determines the energy per resource element (EPRE) prior to cyclic prefix insertion.
The EPRE also denotes the average energy taken over all constellation points for the
modulation scheme applied. The eNB determines the downlink transmit energy per
resource element. A UE may assume the downlink reference symbol EPRE is constant
across the downlink system bandwidth and constant across all subframes untill different
reference signal power information is received.
Benefits
End-User Benefits
 Optimized downlink power allocation will have an impact on the performance of an
LTE UE
Release History
SLR2.2
Reference
layer procedures

Feature Description
Feature Scope
R1 LTE LSM supports the parameter which can set the ratio of RS RE to PDSCH RE.
R2 LTE eNB transmits values of related parameter to the UE according to the ratio of RS
RE to PDSCH RE, and set the RS/PDSCH RE power.

Feature Description
Feature Description
The eNB determines the downlink transmit energy per resource element. A UE may assume
downlink cell-specific reference signal (RS) EPRE is constant across the downlink system
bandwidth and constant across all subframes until different cell-specific RS power
information is received. The downlink cell-specific reference-signal EPRE can be derived
from the downlink reference-signal transmit power given by the parameter
referenceSignalPower provided by higher layers. The downlink reference-signal transmit
power is defined as the linear average over the power contributions (in [W]) of all resource
elements that carry cell-specific reference signals within the operating system bandwidth.
The ratio of PDSCH EPRE to cell-specific RS EPRE among PDSCH REs for each OFDM
symbol is denoted by either ρ A or ρ B according to the OFDM symbol index as given by
below table.
Below table is OFDM symbol indices within a slot of a non-MBSFN subframe where the
ratio of the corresponding PDSCH EPRE to the cell-specific RS EPRE is denoted ρ A or ρ B.
For a UE in transmission mode 8 when UE-specific RSs are not present in the Physical
Resource Blocks (PRB) upon which the corresponding PDSCH is mapped or in
transmission modes 1-7, the UE may assume that for 16 QAM, 64 QAM, spatial
multiplexing with more than one layer or for PDSCH transmissions associated with the
multi-user MIMO transmission scheme,
 ρ A is equal to δ power -offset + P A + 10log 10 2 [dB] when the UE receives a PDSCH data
transmission using precoding for transmit diversity with 4 cell-specific antenna ports
according to Section 6.3.4.3 of [1]
 ρ A is equal to δ power -offset + P A [dB] otherwise
where, δ power -offset is 0 dB for all PDSCH transmission schemes except multi-user MIMO
and where P A is a UE specific parameter provided by higher layers. The cell-specific ratio
is given by below table. according to cell specific parameter signalled by higher layers and
the number of configured eNB cell specific antenna ports.

Feature Description
 The cell-specific ratio ρ A /ρ A for 1, 2, or 4 cell specific antenna ports

Feature Description
System operation
Command Description
RTRV-PDSCH- Retrieves the Physical Downlink Shared Channel (PDSCH) configuration

IDLE information within the eNB. It can retrieve the power ratio of the Resource
Element (RE) which transmits the reference signal and the RE which
transmits the data over the PDSCH.
CHG-PDSCH- Changes the physical downlink shared channel (PDSCH) configuration
IDLE information within the eNB. It can change the power ratio of the resource
element (RE) which transmits the reference signal and the RE which
transmits the data over the PDSCH. To apply the changes to this parameter,
the cell must be switched to the lock state or forcedModeFlag must be set to
True before making changes.
How to
Parameter Description
Set/Change
dlPowerOption Power setting option. The power per resource grid of Refer to the
RS must be two times of the power per resource grid of related commands
data.
Range: ci_pwrOpt_Same, ci_pwrOpt_OneHalf,
ci_pwrOpt_Twice, ci_pwrOpt_Half
- ci_pwrOpt_Same: The power per resource grid of RS
is the same as the power per resource grid of data.
- ci_pwrOpt_OneHalf: The power per resource grid of
RS is 1.5 times of the power per resource grid of data.
- ci_pwrOpt_Twice: The power per resource grid of RS
is 2 times of the power per resource grid of data.
- ci_pwrOpt_Half: The power per resource grid of RS is
0.5 times of the power per resource grid of
data.Range:
forcedMode Whether to configure PLD change value regardless of Refer to the
cell status.Range: related commands
Range: true, false
Default: false

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME3101, HARQ in DL and UL

Overview
MAC Layer Hybrid ARQ uses Incremental redundancy technique to discard erroneously
received packets and request retransmission providing robustness against transmission
errors
Introduction
HARQ is used for facilitating fast error detection and correction. HARQ is a stop and wait
protocol; subsequent transmission can take place only after receiving ACK/NACK from the
receiving entity. In case an ACK is received a new transmission is done else a
retransmission is done. This scheme can be improved by using multiple channels for
supporting HARQ service. In LTE, HARQ is implemented as MAC level (L1) module
called HARQ entity. HARQ entity is associated with N HARQ processes to implement N
stop and wait HARQ protocol.
Benefits
Operator Benefits:
 Achieve reliable data transmission by sending a message of ACK/NACK.
Release History
SLR2.2

Dependency:
 None
Limitation:
 None
Reference
and channel coding
layer procedures
3) 3GPP TS 36.321 Evolved Universal Terrestrial Radio Access (E-UTRA); Medium
Access Control (MAC) protocol specification

Feature Description
Feature Scope
R1 LTE eNB provides the Downlink/Uplink HARQ function.
R2 LTE eNB provides a function that the TB received by the UE via downlink HARQ
retransmission can be restored normally.
R3 LTE eNB provides a function that the TB received by the UE via uplink HARQ
retransmission can be restored normally.
R4 LTE eNB supports a function that automatically determines which of the synchronous
or asynchronous HARQ transmission is applied for system optimization during the
uplink HARQ operation.

Feature Description
Feature Description
Scheduling HARQ
In the downlink, HARQ is asynchronous and the schedule for HARQ transmissions is not
predeclared to the UEs. When the HARQ blocks are transmitted they need to be
accompanied by control information such as HARQ process ID, new transmission/
retransmission.
This scheme has following advantages:
1) Complete flexibility of scheduling different data flows as per their respective priorities
2) In case of frequency selective fading, link adaptation is possible. As the resources for
HARQ processes are not predetermined, the blocks (new transmission/retransmission)
can be modulated and coded as per the link conditions.
In uplink the HARQ transmission is synchronous, which means that the HARQ blocks are
predetermined for transmission and retransmission. The modulation, coding scheme for the
blocks is predetermined by the eNB. Thus, for uplink transmission, there is no need for
transmitting control information along with the HARQ data blocks. The modulation and
coding scheme for the different UEs may be tuned by the eNB based on the reports
submitted by the UEs.
HARQ in downlink
The downlink HARQ transmission is asynchronous; the UE receives the information about
HARQ transmissions on control channel. Downlink assignments and HARQ information is
transmitted on PDCCH and the TB (transport blocks) are transmitted on DL-SCH. HARQ
entity in UE deciphers the HARQ information. HARQ information consists of parameters
such as HARQ process ID, New Data Indicator (NDI), Redundancy Version (RV),
Transport Block (TB) size. HARQ entity maintains a number of HARQ processes, HARQ
information and TB is forwarded by HARQ entity to relevant process.
A transmission is considered new transmission in case
1) This is first transmission ever received for this process ID or

2) NDI has toggled in HARQ information.
Otherwise TB is considered retransmitted. For a new transmission, HARQ process replaces

the old contents of associated HARQ buffer with the new contents. If the decoding of this
data block is successful the data is handed over to disassembly and demultiplexing MAC
module. If decoding fails, data is preserved in this buffer.
For retransmission, the retransmitted data is soft combined with old buffer contents.

Feature Description
HARQ process decodes the new contents; if the decoding is successful the retransmitted
block is handed over to disassembly and demultiplexing unit. It may happen that the
retransmission is done using some different coding scheme and the TB is of different size,
in this case soft combining is not possible and HARQ buffer contents are replaced with the
new received buffer contents. HARQ process generates a positive ACK for the successfully
decoded data and negative ACK for the unsuccessful ones. HARQ feedback has a lower
priority than measurement gaps. HARQ feedback is transmitted when measurement gaps
are not scheduled.
HARQ in uplink
Uplink HARQ is synchronous; UE receives the Uplink grant for transmission on control
channel. The grant indicates control information such as HARQ process ID, type of
transmission (new/retransmission), redundancy version. Downlink ACK/NACK are sent on
PHICH and uplink grants are sent via PDCCH. If a PDCCH grant is received, data is
considered ack/nack based on HARQ info. HARQ feedback is not considered in this case.
In case PDCCH is not received, HARQ feedback is considered. In case NACK is received-
non-adaptive retransmission is planned.
In case ACK is received, no non-adaptive retransmission can be planned.
HARQ buffer is preserved as-is (till PDCCH grant indicative of ACK arrives)
On receiving PDCCH grant for new transmission, HARQ entity receives a PDU for
transmission from ‘Multiplexing and assembly’ module. HARQ entity delivers the PDU,
uplink grant and HARQ info to HARQ process (that was indicated in control information)
and instructs the HARQ process to transmit the new block. The HARQ process stores the
received PDU in its HARQ buffer and sets the redundancy version IRV indicated in control
information. HARQ process then instructs the PHY layer to transmit the block.
On receiving the PDCCH grant for retransmission, HARQ entity delivers uplink grant and
HARQ info to relevant HARQ process and instructs it to generate an adaptive
retransmission. HARQ process instructs PHY to retransmit the buffer contents as per the
redundancy version instructed by eNB in control information. If max limit for
retransmissions is reached HARQ process flushes the contents of buffer.

Feature Description
HARQ ARQ Interaction

ARQ uses the knowledge from HARQ about transmission status of a MAC PDU.
This interaction is useful in handling HARQ residual error cases. HARQ provides
indications to ARQ block when:
1) HARQ transmitter reaches maximum retransmissions for a TB without getting an ACK

2) HARQ receiver is able to detect a transmission failure
First indication is called as NACK1 and the second one is called NACK2. We discuss the
two conditions in detail in following sections.
NACK 1
This situation may be caused when HARQ block transmissions could not be successfully
decoded at receiver. After reaching max limit for number of retransmission MAC sends
NACK1 indication to RLC layer. On getting this indication ARQ block in RLC can
recode/re-segment the block for transmission.
Max number of retransmission in Uplink should be known to the eNB, as eNB has to stop
scheduling retransmissions after UE has reached the max transmissions. Maximum number
of retransmission suited for a connection depends on the type of QoS. For a real time traffic
flow, more than 1-2 retransmissions may be unnecessary.
However, for a file transfer kind of flow it would be useful to have greater number of
retransmissions. This radio bearer specific max limit has to be indicted in UE reports to
eNB. However, the scheme is prone to failure in case UE reports are received
late/erroneously at eNB. The other option is to have a common limit for max
retransmissions for all the radio bearers. Generation of NACK1 from MAC to RLC may
also be caused if an ACK from receiver is misinterpreted as NACK. This misinterpretation
leads to unnecessary retransmissions.
 NACK 2
When HARQ receiver transmits NACK for a HARQ block, it expects the block to be
retransmitted. If the receiver sees no transmission in the expected TTI or when the
receiver sees the HARQ process ID rescheduled for a new transmission; the receiver
knows that the NACK has been misinterpreted as ACK by the transmitter.
MAC indicates this to RLC and RLC sends a control message to peer to indicate the
missing block. The scheme requires a request for resource grant for UE and eNB
followed by transmission of control message. Synchronous HARQ was adopted in
uplink to save on control channel resources and this control messaging becomes
overhead.
This NACK2 interaction provides little performance gain compared to added
complexity and has been dropped from recent versions of specifications.

Feature Description
System operation
Command Description
RTRV-TRCH-INF Retrieves the information required for transport channel operation.

Retrieves the maximum number of UL HARQ retransmissions.
CHG-TRCH-INF This command changes the information required for transport channel
operation. Changes the maximum number of UL HARQ retransmissions.
How to
Set/Change
maxHARQTx Enters the max HARQ Tx for each cell. Refer to the related
The UE performs PUSCH retransmission based on the commands.
parameter value entered.
Range:
- ci_maxHARQ_Tx_n1: 1 transmission,
- ci_maxHARQ_Tx_n2: 2 transmissions,
Default:
Related Counters
N/A
Related KPI/PI
N/A

Feature Description
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME3201, Basic Link Adaption

Overview
MCS adaptation based upon channel information and error statistics
Introduction
The principle of link adaptation is fundamental to the design of a radio interface which is
efficient for packet-switched data traffic. Unlike the early versions of UMTS (Universal
Mobile Telecommunication System), which used fast closed-loop power control to support
circuit-switched services with a roughly constant data rate, link adaptation in HSPA (High
Speed Packet Access) and LTE adjusts the transmitted information data rate (modulation
scheme and channel coding rate) dynamically to match the prevailing radio channel
capacity for each user.
For the downlink data transmissions in LTE, the eNodeB typically selects the modulation
control of the eNodeB. An identical channel coding structure is used for the uplink, while
the modulation scheme may be selected between QPSK and 16QAM, and, for the highest
category of UE, also 64QAM. The main difference from the downlink is that instead of
basing the link adaptation on CQI feedback, the eNodeB can directly make its own
estimate of the supportable uplink data rate by channel sounding, for example using the
Sounding Reference Signals (SRSs). A final important aspect of link adaptation is its use in
conjunction with multi-user scheduling in time and frequency, which enables the radio
transmission resources to be shared efficiently between users as the channel capacity to
individual users varies. The CQI can therefore be used not only to adapt the modulation
and coding rate to the channel conditions, but also for the optimization of the
time/frequency selective scheduling and for inter-cell interference management.
Benefits
Operator Benefits:
 Match the transmission parameter such as modulation and coding scheme (MCS) as
well as MIMO transmission rank and precoding to the channel condition on resource
allocated by the scheduler.
 Serve the best resource allocation under the restriction of limited resource pool.

Feature Description
Release History
SLR2.2

Dependency:
 In case of uplink 64
Limitation:
 None
Reference
and channel coding
layer procedures
Feature Scope
R1 The Adaptive Modulation and Coding (AMC) function using the CQI feedback
should be provided in LTE eNB.

Feature Description
Feature Description
Link Adaptation
In cellular communication systems, the quality of the signal received by a UE depends on
the channel quality from the serving cell, the level of interference from other cells, and the
noise level. To optimize system capacity and coverage for a given transmission power, the
transmitter should try to match the information data rate for each user to the variations in
received signal quality. This is commonly referred to as link adaptation and is typically
based on Adaptive Modulation and Coding (AMC).
The degrees of freedom for the AMC consist of the modulation and coding schemes:
 Modulation Scheme. Low-order modulation (i.e. few data bits per modulated symbol,
e.g. QPSK) is more robust and can tolerate higher levels of interference but provides a
lower transmission bit rate. High-order modulation (i.e. more bits per modulated
symbol, e.g. 64AQM) offers a higher bit rate but is more prone to errors due to its
higher sensitivity to interference, noise and channel estimation errors; it is therefore
useful only when the SINR is sufficiently high.
 Code rate. For a given modulation, the code rate can be chosen depending on the radio
link conditions: a lower code rate can be used in poor channel conditions and a higher
code rate in the case of high SINR. The adaptation of the code rate is achieved by
applying puncturing or repetition to the output of a mother code.
A key issue in the design of the AMC scheme for LTE was whether all Resource Blocks
(RBs) allocated to one user in a subframe should use the same Modulation and Coding
Scheme (MCS) or whether the MCS should be frequency dependent within each subframe.
It was shown that in general only a small throughput improvement arises from a frequency-
dependent MCS compared to an RB-common MCS in the absence of transmission power
control, and therefore the additional control signalling overhead associated with frequency-
dependent MCS is not justified. Therefore in LTE the modulation and channel coding rates
are constant over the allocated frequency resources for a given user, and time-domain
channel-dependent scheduling and AMC is supported instead. In addition, when multiple
transport blocks are transmitted to one user in a given subframe using multistream
Multiple-Input Multiple-Output (MIMO), each transport block can use an independent MCS.
In LTE the UE can be configured to report CQIs to assist the eNodeB in selecting an
appropriate MCS to use for the downlink transmissions. The CQI reports are derived from
the downlink received signal quality, typically based on measurements of the downlink
reference signals. It is important to note that, like HSDPA, the reported CQI is not a direct
indication of SINR in LTE. Instead, the UE reports the highest MCS that it can decode with
a transport block error rate probability not exceeding 10 %. Thus the information received
by the eNodeB takes into account the characteristics of the UE’s receiver, and not just the
prevailing radio channel quality.

Feature Description
Hence a UE that is designed with advanced signal processing algorithms (for example,
using interference cancellation techniques) can report a higher channel quality and,
depending on the characteristics of the eNodeB’s scheduler, can receive a higher data rate.
The list of modulation schemes and code rates which can be signalled by means of a CQI
value is shown in below table.
AMC can exploit the UE feedback by assuming that the channel fading is sufficiently slow.
This requires the channel coherence time to be at least as long as the time between the UE’s
measurement of the downlink reference signals and the subframe containing the
correspondingly-adapted downlink transmission on the Physical Downlink Shared
CHannel (PDSCH). However, a trade-off exists between the amount of CQI information
reported by the UEs and the accuracy with which the AMC can match the prevailing
conditions. Frequent reporting of the CQI in the time domain allows better matching to the
channel and interference variations, while fine resolution in the frequency domain allows
better exploitation of frequency-domain scheduling. However, both lead to increased
feedback overhead in the uplink. Therefore, the eNodeB can configure both the time-
domain update rate and the frequency-domain resolution of the CQI.

Feature Description
CQI Feedback
The periodicity and frequency resolution to be used by a UE to report CQI are both
controlled by the eNodeB. In the time domain, both periodic and aperiodic CQI reporting
are supported. The PUCCH is used for periodic CQI reporting only; the PUSCH is used
for aperiodic reporting of the CQI, whereby the eNodeB specifically instructs the UE to
send an individual CQI report embedded into a resource which is scheduled for uplink data
transmission.
The frequency granularity of the CQI reporting is determined by defining a number of
subbands The CQI reporting modes can be Wideband CQI, eNodeB configured sub-band
feedback, or UE-selected sub-band feedback. In addition, in the case of multiple transmit
antennas at the eNodeB, CQI value(s) may be reported for a second codeword. For some
downlink transmission modes, additional feedback signalling consisting of Precoding
Matrix Indicators (PMI) and Rank Indications (RI) is also transmitted by the UE.
 Aperiodic CQI Aperiodic CQI reporting on the PUSCH is scheduled by the eNodeB
by setting a CQI request bit in an uplink resource grant sent on the PDCCH. The type
of CQI report is configured by the eNodeB by RRC signalling. Table. 2 summarizes
the relationship between the configured downlink transmission mode and the possible
CQI reporting type. The CQI reporting type can be:
− Wideband feedback. The UE reports one wideband CQI value for the whole
system bandwidth.
− eNodeB-configured sub-band feedback. The UE reports a wideband CQI value
for the whole system bandwidth. In addition, the UE reports a CQI value for each
subband, calculated assuming transmission only in the relevant sub-band.
Sub-band CQI reports are encoded differentially with respect to the wideband CQI
using 2-bits as follows:
Sub-band differential CQI offset = Sub-band CQI index-Wideband CQI index
 Aperiodic CQI feedback types on PUSCH for each PDSCH

Feature Description
Below table is Sub-band size (k) versus system bandwidth for eNodeB-configured
aperiodic CQI reports
− UE-selected sub-band feedback. The UE selects a set of M preferred sub-bands

of size k (where k and M are given in Table 4 for each system bandwidth range)
within the whole system bandwidth. The UE reports one wideband CQI value and
one CQI value reflecting the average quality of the M selected sub-bands. The CQI
value for the M selected sub-bands for each codeword is encoded differentially
using 2-bits relative to its respective wideband CQI as defined by
Differential CQI = Index for average of M preferred sub-bands-Wideband CQI index
Below table is Sub-band size k and number of preferred sub-bands (M) versus downlink
system bandwidth for aperiodic CQI reports for UE-selected sub-bands feedback
 Periodic CQI
If the eNodeB wishes to receive periodic reporting of the CQI, the UE will transmit
the reports using the PUCCH. Only wideband and UE-selected sub-band feedback is
possible for periodic CQI reporting, for all downlink (PDSCH) transmission modes.
As with the aperiodic CQI reporting, the type of periodic reporting is configured by
the eNodeB by RRC signalling. For the wideband periodic CQI reporting, the period
can be configured to {2, 5, 10, 16, 20, 32, 40, 64, 80, 160} ms or Off. While the
wideband feedback mode is similar to that sent via the PUSCH, the ‘UE selected sub-
band’ CQI using PUCCH is different. In this case, the total number of sub-bands N is
divided into J fractions called bandwidth parts. The value of J depends on the system
bandwidth as summarized in Table 5. In case of periodic UE-selected sub-band CQI
reporting, one CQI value is computed and reported for a single selected sub-band from
each bandwidth part, along with the corresponding sub-band index.

Feature Description
Below table is Periodic CQI reporting with UE-selected sub-bands: sub-band size (k) and
bandwidth parts (J ) versus downlink system bandwidth.
Multiple Antenna Transmission Case

 Channel Quality Indicator (CQI)
A CQI index is defined in terms of a channel coding rate value and modulation scheme
(QPSK, 16QAM, 64QAM) as given in upper table. In addition to 4-bit absolute CQI
indices, three differential CQI values are defined to reduce the CQI signaling overhead.
In the case of two codewords MIMO, 3 bit-spatial differential CQI represents the
difference between CQI value for codeword 1 and CQI value codeword 2 as:
CQIDIiff-spatial = CQICW1-CQICW2.
The set of CQIDIiff-spatial values is {-4, -3, -2, -1, 0 +1 +2 +3}. The subband CQI is
for each codeword are also encoded differentially with respect to their respective
wideband CQI using 2 bits as defined by:
CQIDIiff-sb[i] = CQIsb[i]-CQIWB
The set of possible subband differential CQI value is {-2. 0, +1, +2}. Note that two
values are used to represent subband CQIs larger than the wideband CQI {+1, +2}
while only a single value {-2} is used to represent a subband CQI lower than the
wideband CQI. The CQI value for the M selected subbands for each codeword is
encoded differentially using 2 bits relative to the respective wideband CQI as:
CQIDIiff-M = CQIavg-M[i]-CQIWB.
The possible differential CQI CQIDIiff-M values are {+1, +2, +3, +4}. It should be
noted that when best M subbands are selected, the average CQI on these subbands is
always larger than the wideband CQI, which is averaged over a large bandwidth.
Note that a UE always reports the wideband CQI even when it selects a subset of
subbands. This is because wideband CQI is required for setting the power levels for
downlink control channels that are transmitted in a frequency diverse transmission
format over the wideband to exploit frequency diversity.

Feature Description
 Precoding Matrix and Rank Indicator (PMI and RI)

The MIMO transmission rank can be either one or two for the case of two-antenna
ports requiring single-bit rank indicator (RI). The numbers of precoders for the two
antenna ports are four and two for rank-1 and rank-2 respectively. Therefore, the
precoding matrix indicator (PMI) requires tow bits for rank-1 and a single bit for rank-
2. For the case of four antenna ports, the MIMO transmission rank can be one, two,
three or four requiring two bit rank indication. The number of precoders for each rank
is 16 and therefore requires four bit PMI indication.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME3205, CQI Correction

Overview
CQI correction operation to compensate the link adaptation inaccuracy.
Introduction
CQI correction performs CQI adaptation in order to compensate possible non-idealities of
the link adaptation in LTE. e.g. CQI estimation error of the UE, CQI quantization error.
Benefits
Operator Benefits:
 Enable the better link adaptation from facilitating this feature
 Enable downlink radio resource scheduling to serve the best resource allocation
Release History
SLR2.2

Dependency:
 None
Limitation:
 None
Reference
and channel coding
Feature Scope
R1. LTE LSM provides a function for setting the target BLER to compensate CQI.
R2. LTE eNB updates the outer-loop offset by reflecting the reception of PDSCH to
compensate CQI.

Feature Description
Feature Description
CQI correction performs CQI adaptation in order to compensate possible non-idealities of
the link adaptation in LTE. For this object, Outer-loop offset value for PDSCH is managed
by eNB and is updated according to whether PDSCH is received by target UE successfully
or not. HARQ feedback is used to detect the successful reception of PDSCH.
If PDSCH fail is detected, eNB increases the outer-loop offset value to better protect
PDSCH. On the contrary, if PDSCH is successfully transmitted to the target UE, eNB
decreases the outer-loop offset value to use more aggressive MCS. To keep the PDSCH
error rate lower than target value, outer loop offset increment step size is larger than
decrement step size.

Feature Description
System operation
Command Description
RTRV-BLER-CTRL Retrieves the use of target BLER value and function required to set the
target BLER in Modem/DSP.
CHG-UDA-CTRL Changes the use of target BLER value and function required to set the
target BLER in Modem/DSP.
 Related System Parameters: The PLD parameters relating to this feature are explained
in the following table:
enableDLTargetBL This parameter is to enable the DL BLER Refer to related commands.

ER control of cells in the base station.
Range: True, False
Default: False
DLTargetBLER This parameter is the value of DL Target Refer to related commands.
BLER. The unit is %.
Range: 1~50
Default: 10
enableULTargetBL This parameter is to enable the UL BLER Refer to related commands.
ER control of cells in the base station.
Range: True, False
Default: False
ULTargetBLER This parameter is the value of UL Target Refer to related commands.
BLER. The unit is %.
Range: 1~50
Default: 10
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A

Feature Description
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME3202, ME3206, ME3207, ME3208, Periodic

Channel Status Reporting
Overview
DL channel status reporting by CQI (Channel Quality Indicator), RI (Rank Indicator) and
PMI (Precoder Matrix Indicator).
Introduction
The principle of link adaptation is fundamental to the design of a radio interface which is
efficient for packet-switched data traffic. Unlike the early versions of UMTS (Universal
Mobile Telecommunication System), which used fast closed-loop power control to support
circuit-switched services with a roughly constant data rate, link adaptation in HSPA (High
Speed Packet Access) and LTE adjusts the transmitted information data rate (modulation
scheme and channel coding rate) dynamically to match the prevailing radio channel
capacity for each user.
For the downlink data transmissions in LTE, the eNodeB typically selects the modulation
control of the eNodeB. An identical channel coding structure is used for the uplink, while
the modulation scheme may be selected between QPSK and 16QAM, and, for the highest
category of UE, also 64QAM. The main difference from the downlink is that instead of
basing the link adaptation on CQI feedback, the eNodeB can directly make its own
estimate of the supportable uplink data rate by channel sounding, for example using the
Sounding Reference Signals (SRSs). A final important aspect of link adaptation is its use in
conjunction with multi-user scheduling in time and frequency, which enables the radio
transmission resources to be shared efficiently between users as the channel capacity to
individual users varies. The CQI can therefore be used not only to adapt the modulation
and coding rate to the channel conditions, but also for the optimization of the
time/frequency selective scheduling and for inter-cell interference management.
Benefits
Operator Benefits:
 Enable link adaptation from facilitating this feature
 Enable downlink radio resource scheduling to serve the best resource allocation

Feature Description
Release History
SLR2.2

Dependency:
 In case of uplink 64
Limitation:
 None
Reference
and channel coding
layer procedures
Feature Scope
R1 LTE LSM supports the setting of a periodic wideband and a subband.
R2 LTE eNB performs AMC by reflecting the periodic CQI.
R3 LTE eNB supports to set a reporting mode fit for the transmission mode of UE.
R4 LTE eNB receives and manages RI or PMI fit for the transmission mode of UE.
R5 LTE eNB supports a function to automatically decide the cycle and transmission
offset for periodic reporting.

Feature Description
Feature Description
Link Adaptation
In cellular communication systems, the quality of the signal received by a UE depends on
the channel quality from the serving cell, the level of interference from other cells, and the
noise level. To optimize system capacity and coverage for a given transmission power, the
transmitter should try to match the information data rate for each user to the variations in
received signal quality. This is commonly referred to as link adaptation and is typically
based on Adaptive Modulation and Coding (AMC).
The degrees of freedom for the AMC consist of the modulation and coding schemes:
 Modulation Scheme. Low-order modulation (i.e. few data bits per modulated symbol,
e.g. QPSK) is more robust and can tolerate higher levels of interference but provides a
lower transmission bit rate. High-order modulation (i.e. more bits per modulated
symbol, e.g. 64AQM) offers a higher bit rate but is more prone to errors due to its
higher sensitivity to interference, noise and channel estimation errors; it is therefore
useful only when the SINR is sufficiently high.
 Code rate. For a given modulation, the code rate can be chosen depending on the radio
link conditions: a lower code rate can be used in poor channel conditions and a higher
code rate in the case of high SINR. The adaptation of the code rate is achieved by
applying puncturing or repetition to the output of a mother code.
A key issue in the design of the AMC scheme for LTE was whether all Resource Blocks
(RBs) allocated to one user in a subframe should use the same Modulation and Coding
Scheme (MCS) or whether the MCS should be frequency dependent within each subframe.
It was shown that in general only a small throughput improvement arises from a frequency-
dependent MCS compared to an RB-common MCS in the absence of transmission power
control, and therefore the additional control signalling overhead associated with frequency-
dependent MCS is not justified. Therefore in LTE the modulation and channel coding rates
are constant over the allocated frequency resources for a given user, and time-domain
channel-dependent scheduling and AMC is supported instead. In addition, when multiple
transport blocks are transmitted to one user in a given subframe using multistream
Multiple-Input Multiple-Output (MIMO), each transport block can use an independent
MCS.
In LTE the UE can be configured to report CQIs to assist the eNodeB in selecting an
appropriate MCS to use for the downlink transmissions. The CQI reports are derived from
the downlink received signal quality, typically based on measurements of the downlink
reference signals. It is important to note that, like HSDPA, the reported CQI is not a direct
indication of SINR in LTE. Instead, the UE reports the highest MCS that it can decode with
a transport block error rate probability not exceeding 10 %.

Feature Description
Thus the information received by the eNodeB takes into account the characteristics of the
UE’s receiver, and not just the prevailing radio channel quality. Hence a UE that is
designed with advanced signal processing algorithms (for example, using interference
cancellation techniques) can report a higher channel quality and, depending on the
characteristics of the eNodeB’s scheduler, can receive a higher data rate. The list of
modulation schemes and code rates which can be signaled by means of a CQI value is
shown in below table.
CHannel (PDSCH). However, a trade-off exists between the amount of CQI information
reported by the UEs and the accuracy with which the AMC can match the prevailing
conditions. Frequent reporting of the CQI in the time domain allows better matching to the
channel and interference variations, while fine resolution in the frequency domain allows
better exploitation of frequency-domain scheduling. However, both lead to increased
feedback overhead in the uplink. Therefore, the eNodeB can configure both the time-
domain update rate and the frequency-domain resolution of the CQI.
CHannel (PDSCH).

Feature Description
However, a trade-off exists between the amount of CQI information reported by the UEs
and the accuracy with which the AMC can match the prevailing conditions.
Frequent reporting of the CQI in the time domain allows better matching to the channel and
interference variations, while fine resolution in the frequency domain allows better
exploitation of frequency-domain scheduling. However, both lead to increased feedback
overhead in the uplink. Therefore, the eNodeB can configure both the time-domain update
rate and the frequency-domain resolution of the CQI.
CQI Feedback
For CQI feedback, eNodeB employs periodic reporting of the CQI and the UE will transmit
the reports using the PUCCH. Only wideband and UE-selected sub-band feedback is
possible for periodic CQI reporting, for all downlink (PDSCH) transmission modes.
The type of periodic reporting is configured by the eNodeB by RRC signalling. For the
wideband periodic CQI reporting, the period can be configured to {2, 5, 10, 16, 20, 32, 40,
64, 80, 160} ms or Off, and the UE reports one wideband CQI value for the whole system
bandwidth. In the case of ‘UE selected sub-band’, the total number of sub-bands N is
divided into J fractions called bandwidth parts. One CQI value is computed and reported
for a single selected sub-band from each bandwidth part, along with the corresponding sub-
band index. The value of J depends on the system bandwidth as summarized in below table.
Below table is Periodic CQI reporting with UE-selected sub-bands (sub-band size (k) and
bandwidth parts (J ) versus downlink system bandwidth)

Feature Description
Multiple Antenna Transmission Case

Channel Quality Indicator (CQI)
A CQI index is defined in terms of a channel coding rate value and modulation scheme
(QPSK, 16QAM, 64QAM) as given in Table. 1. In addition to 4-bit absolute CQI indices,
three differential CQI values are defined to reduce the CQI signaling overhead. Note that a
UE always reports the wideband CQI even when UE-selected sub-band feedback is used
for periodic reporting. This is because wideband CQI is required for setting the power
levels for downlink control channels that are trasmitted in a frequency diverse transmission
format over the wideband to exploit frequency diversity.
Precoding Matrix and Rank Indicator (PMI and RI)

The MIMO transmission rank can be either one or two for the case of two-antenna ports
requiring single-bit rank indicator (RI). The numbers of precoders for the two antenna ports
are four and two for rank-1 and rank-2 respectively. Therefore, the precoding matrix
indicator (PMI) requires two bits for rank-1 and a single bit for rank-2. For the case of four
antenna ports, the MIMO transmission rank can be one, two, three or four requiring two bit
rank indication. The number of precoders for each rank is 16 and therefore requires four bit
PMI indication.

Feature Description
System operation
Command Description
RTRV-CQI-REP Retrieves the information required for CQI reporting operation.

It can retrieve whether only wideband CQI is operated or wideband CQI and
subband CQI are operated simultaneously for each DL transmission mode.
CHG-CQI-REP Changes the parameter information required for CQI reporting operation.
It can set whether only wideband CQI is operated or wideband CQI and
wideSubbandSelect This parameter is the value used to select Refer to related commands.
either wideband or subband CQI.
Range: ci_WideBand, ci_SubBand
- ci_WideBand: wideband CQI only.
- ci_SubBand: wideband + subband CQI.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME3301, ME3302, ME3303, ME3304,

Scheduling with QoS Support
Overview
Based on the QoS profile of the user, the MAC scheduler will be aware of the priority GBR
and AMBR requirements of the users. Accordingly, the scheduler can prioritize the users,
ensure guaranteed bit rate and also control the Maximum Aggregate Bit rate allowed for the
user
Introduction
The LTE scheduler is responsible for dynamically allocating downlink and uplink resources
among the bearers appropriately while maintaining their desired QoS level in both
downlink and uplink directions. In order to make a scheduling decision, the LTE scheduler
uses the following information as input:
 Radio conditions at the UE identified through measurements made at the eNB and/or
reported by the UE.
 The state of different bearers, such as uplink buffer status reports (BSR) that are
required to provide support for QoS-aware packet scheduling.
 The QoS attributes of bearers and packet forwarding parameters associated with the
QCIs.
The proportional fair (PF) scheduler uses channel quality (proportional factor) information
and average throughput (fairness factor) as the knobs to determine the priority of
scheduling users. When QCI based priority information is available, along with the PF
parameters, the priority and delay budget information are used as well to decide upon the
scheduling priority.
Benefits
Operator Benefits:
 Operator can differentiate traffic data according to the QoS class of LTE user.
 LTE users can be served the better QoS with their priority in the system.
Release History
SLR2.2

Feature Description

Dependency:
 None
Limitation:
 None
Reference
Feature Scope
The feature scope of scheduling with QoS support is as follows:
R1 LTE EPC provides a function to transmit to eNB by creating QoS profile.
R2 LTE eNB receives QoS profile from EPC and reflects it to scheduling and this
includes following parameters:
 QCI (QoS Class Indicator)
 GBR (Guaranteed Bit Rate)
 MBR (Maximum Bit Rate)
 AMBR (Aggregated Maximum Bit Rate)
R3 LTE eNB provides a function to map the QCI received from EPC to the following
parameters:
 priority
 PDB (Packet Delay Budget)
 PELR (Packet Error Loss Rate)
 service type
R4 LTE eNB provides GBR and MBR for the bearers whose service type is GBR.
R5 LTE eNB provides AMBR for the aggregate data rates of the bearers whose service
type is non-GBR.
R6 TE eNB performs scheduling for the bearers whose service type is GBR to get
resources assigned in priority when the priority is higher or PDB is smaller.
R7 LTE eNB performs scheduling to satisfy PELR condition.
R8 LTE eNB supports round robin scheduling.
R9 LTE eNB supports equal bit rate scheduling.
R10 LTE eNB supports proportional fair scheduling.

Feature Description
Feature Description
Multi-user scheduling is one of the main feature in LTE systems because it is in charge of
distributing available resources among active users in order to satisfy their QoS needs.
In fact, the data channel (i.e. the PDSCH) is shared among the users, meaning that portions
of the spectrum should be distributed every TTI among them. Packet schedulers (for both
the downlink and the uplink) are deployed at the eNB, and, since OFDMA ideally provides
no inter-channel interference. They work with a granularity of one TTI and one RB in the
time and frequency domain, respectively.
Resource allocation for each UE is usually based on the comparison of per-RB metrics: the
k-th RB is allocated to the j-th user if its metric mj,k is the biggest one, i.e. if it satisfies the
equation: mj,k = max { mi,k }. These metrics can be somehow interpreted as the
transmission priority of each user on a specific RB. Based on the desired performance
requirement, their computation is usually evaluated starting from information related to
each flow and useful to drive the allocation decision:
 Status of transmission queues: the status of transmission queues at UEs could be used
for minimizing packet delivery delays (e.g. the longer the queue, the higher the metric).
 Channel Quality: reported CQI values could be used to allocate resources to users
experiencing better channel conditions (e.g. the higher the expected throughput, the
higher the metric).
 Resource Allocation History: information about the past achieved performance can be
used to improve fairness (e.g. the lower the past achieved throughput, the higher the
metric).
 Buffer State: receiver-side buffer conditions might be used to avoid buffer overflows
(e.g. the higher the available space in the receiving buffer, the higher the metric).
 Quality of Service Requirements: the QCI value associated to each flow might be used
to drive specific policies with the aim of meeting QoS requirements.
Every TTI the scheduler performs the allocation decision valid for the next TTI and sends
such information to UEs using the PDCCH. DCI messages in the PDCCH payload inform
UEs about RBs allocated for data transmission on the PDSCH in the downlink direction.
Moreover, DCI messages are used to inform users about the dedicated radio resources for
their data transmission on the PUSCH in the uplink direction.
A relevant importance in LTE schedulers is assigned to the ‘channel sensitivity’ concept.

The basic idea is to schedule transmission for UEs that, at the current time and on a given
frequency, are experiencing ‘good’ channel conditions based on the selected metric.
This approach, also known as Frequency Domain Packet Scheduler (FDPS), counteracts
the time-varying and frequency-selective nature of the wireless channel.

Feature Description
Furthermore, the characteristic of the fast fading to be independent on users can be

exploited by allocation procedures, obtaining what is usually addressed as ‘multi-user
diversity’ gain. In fact, in a scenario with many users experiencing independent fading
effects, the probability to find a user with good channel conditions at a given time is very
high. The advantage of this behavior is twofold: it enables the transmission when high data
rates are achievable (i.e. under good channel conditions the AMC module will select a
more effective MCS) and, at the same time, it is naturally immune to frequency-selective
fading effects (i.e. a user experiencing very bad channel condition will not be served).
Key Design Aspect

Differences among resource allocation strategies are mainly based on the trade-off between
decision optimality and computational complexity. Hereafter, we present a list of the main
design factors that always should be taken into account before defining an allocation policy
for LTE.
 Complexity and Scalability: A LTE packet scheduler works with a time granularity of
1 ms: it has to take allocation decisions every TTI. Low complexity and scalability are
therefore fundamental requirements for limiting processing time and memory usage.
Finding the best allocation decision through complex and non-linear optimization
problems or through an exhaustive research over all the possible combinations would
be too expensive in terms of computational cost and time. For this reason, FDPS
decisions are usually based on the computation of per-RB metrics for each user. In this
manner, complexity reduction is achieved because each RB is allocated to the user
with the highest metric independently of other RBs. Let N and R be the number of
active users in the current TTI and the number of available RBs, respectively; the
scheduler has to calculate M = N • R metrics every TTI. This assures the scalability
requirement thanks to the linear dependence on the number of resource blocks and
users.
 Spectral Efficiency: Effective utilization of radio resources is one of the main goals to
be achieved. To this aim, several types of performance indicators can be considered:
for instance, a specific policy could aim at maximizing the number of users served in a
given time interval or, more commonly, the spectral efficiency (expressed in bit/s/Hz)
by always serving users that are experiencing the best channel conditions. One of the
most used efficiency indicators is the user goodput, that is a measure of the actual
transmission data rate without including layer two overheads and packet
retransmissions due to physical errors.
 Fairness: A blind maximization of the overall cell throughput surely enables effective
channel utilization in terms of spectral efficiency, but also brings to very unfair
resource sharing among users. Fairness is therefore a major requirement that should be
taken into account to guarantee minimum performance also to the cell-edge users (or
in general to users experiencing bad channel conditions).

Feature Description
 QoS Provisioning: As well-known, QoS provisioning is very important in next

generation mobile networks. It is a major feature in all-IP architectures. LTE maps
QoS constrained flows to dedicated radio bearers that, depending on their QCIs,
enable special RRM procedures. QoS constraints may vary depending on the
application and they are usually mapped into some parameters: minimum guaranteed
bit-rate, maximum delivering delay, and packet loss rate. Thus, it is important to define
QoS-aware schedulers.
Scheduling Strategies
In this section, we will illustrate different allocation strategies introduced for LTE systems.
To simplify the reading, we have classified them in five groups of strategies: (i) channel-
unaware; (ii) channel-aware/QoS-unaware; (iii) channel-aware/QoS-aware;
Channel unaware-strategy
Firstly introduced in wired networks, channel unaware strategies are based on the
assumption of time-invariant and error-free transmission media. While their direct
application in LTE is not realistic, they are typically used jointly with channel-aware
approaches to improve system performance.
1) First In First Out: The simplest case of channel unaware allocation policy serves users
according to the order of resource requests, exactly like a First In First Out (FIFO)
queue. This technique is very simple, but both inefficient and unfair.
2) Round Robin: It performs fair sharing of time resources among users. Round Robin
(RR) metric is similar to the one defined for FIFO. In this context, the concept of
fairness is related to the amount of time in which the channel is occupied by users.
Of course, this approach is not fair in terms of user throughput, that, in wireless
systems, do not depend only on the amount of occupied resources, but also on the
experienced channel conditions. Furthermore, the allocation of the same amount of
time to users with very different application-layer bit-rates is not efficient.
3) Equal bit-rate: Throughput Fairness can be achieved with equal bit-rate scheduling
which stores the past average throughput achieved by each user and uses it as metric.
Thanks to its interesting properties, this metric is widely used in most of the state of
the art schedulers. First of all, it is easy to note that every TTI, equal bit-rate
scheduling allocates resources to flows that have been served with lower average
throughput in the past. Under this allocation policy, the user experiencing the lowest
throughput, performs, in practice, resource preemption: he will be served as long as he
does not reach the same throughput of other users in the cell. In this way, users with
bad channel conditions are allocated more often that others, with a consequent fairness
improvement.

Feature Description
Channel-aware/QoS-unaware Strategies
Thanks to CQI feedbacks, which are periodically sent (from UEs to the eNB) using ad hoc
control messages, the scheduler can estimate the channel quality perceived by each UE;
hence, it can predict the maximum achievable throughput. Let d(t) and dk(t) be the
achievable throughput expected for a certain user at the t-th TTI over all the bandwidth and
over the k-th RB, respectively. The mentioned values can be calculated using the AMC
module or simply estimated, considering the well-known Shannon expression for the
channel capacity, as dk(t) = log[1 + SINRk (t)].
1) Maximum C/I Scheduling: The strategy known as Maximum C/I Scheduling aims at
maximizing the overall throughput by assigning each RB to the user that can achieve
the maximum throughput (indeed) in the current TTI. On the other hand, it performs
unfair resource sharing since users with poor channel conditions (e.g. cell-edge users)
will only get a low percentage of the available resources (or in extreme case they may
suffer of starvation). A practical scheduler should be intermediate between Max C/I
scheduling, that maximizes the cell throughput, and Equal bit-rate scheduling, that
guarantees fair throughput distribution among users, in order to exploit fast variations
in channel conditions as much as possible while still satisfying some degrees of
fairness.
2) Proportional Fair Scheduler: A typical way to find a trade-off between requirements on
fairness and spectral efficiency is the use of Proportional Fair (PF) scheme.
The idea is that the past average throughput can act as a weighting factor of the
expected data rate, so that users in bad conditions will be surely served within a certain
amount of time. Scheduling priority used in RB allocation is PF (Proportional Fair)
priority, and PF priority is calculated as following equation,
PF Priority = (R)^(β)/(Average_Tput)^(α)
R is the available data rate determined by channel quality, Channel quality is

calculated from UE’s feedback information. Average_Tput is the UE’s average
throughput. Parameters α and β are fairness weight and channel quality weight,
respectively. By configuring α and β as 1 and 1, scheduler operates as PF scheduling.
To operate scheduler as Maximum C/I scheduling, it is needed to configure α and β as
0 and 1, respectively.

Feature Description
Channel-aware/QoS-aware Strategies
Standard allows 9 QCI profiles. eNB also supports configuring operator specific QCI
(128~254). Each QCI profile maps to a set of parameters such as priority, packet delay
budget, packet error loss rate and service type. The QCI information is received by the eNB
from EPC. Each UE can support more than one bearer and each bearer can be configured
with a specific QCI. The priority is used in the QOS based scheduling to prioritize the users.
Packet delay budget specifies the a soft upper bound for the time that a packet may be
delayed between the UE and the PGW and is interpreted as the maximum delay with a
confidence level of 98 %. PELR defines an upper bound for the rate of SDUs (e.g. IP
packets) that have been processed by the sender of a link layer protocol (e.g. RLC in E-
UTRAN). This parameter is used to determine appropriate link layer protocol
configurations (e.g. RLC and HARQ retransmissions in E-UTRAN). The Service Type
defines whether the service is a Guaranteed Bit Rate Service or a Non-Guaranteed Bit Rate
Service. The QOS information also includes information such as GBR, MBR and UE-
AMBR. GBR and MBR information are provided on per bearer basis for GBR bearers.
UE-AMBR is provided on per UE Basis. These parameters are provided from EPC to eNB.
GBR (Guaranteed Bit Rate) provides the rate that needs to be guaranteed for a GBR Bearer
by the scheduler. MBR (Maximum Bit Rate) indicates the maximum allowed rate for the
GBR Bearer. UE-AMBR or the Aggregate Maximum Bit Rate specifies the maximum
allowed rate for all the non-GBR Bearers of the UE. eNB enforces the GBR, MBR and UE-
AMBR rules as required during scheduling operation.
With QOS Based scheduling, eNB always prioritizes scheduling of GBR bearers over non-
GBR bearers except QCI 5 (which is typically configured for IMS Signaling).
QCI 5 always has the highest priority. Among GBR bearers, the QCI Priority and the PDB
budget of the bearer is used to determine the ranking along with the PF Scheduler
parameters (Channel Quality and Fairness Criteria). Among non-GBR bearers only the PF
Scheduler parameters are used to prioritize the bearers. Usage of QCI parameters for non-
GBR bearers is considered for future development. For GBR Bearer scheduling, the
algorithm for ranking is provided as following:
Rank = Function [(Channel Quality, Beta Weight Factor), (Average Throughput, Alpha
Weight Factor), (QCI PDB Budget, Gamma Weight Factor), (QCI Priority)],
In the above equation, Alpha and Beta are configurable PF Scheduler weight factors and
Gamma is configurable QOS Scheduler weight factor. PDB Budget is considered in
ranking such that the bearer with small delay budget requirement will get higher priority.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME3305, Semi-persistent Scheduling

Overview
Semi Persistent scheduling allocates periodic resources semi-statically for applications
such as VoIP, instead of dynamic allocation of resources.
Introduction
The 3GPP solution to avoid control channel limitation for VoIP capacity is the Semi-
Persistent Scheduling (SPS) method, where the initial transmissions of VoIP packets are
sent without associated scheduling control information by using persistently allocated
transmission resources instead. The semi-persistent scheduling is configured by higher
layer (Radio resource control, RRC), and the periodicity of the semi-persistent scheduling
is signaled by RRC. At the beginning of a talk spurt, the semi-persistent scheduling is
activated by sending the allocated transmission resources by Physical Downlink Control
Channel (PDCCH) and the UE stores the allocation and uses it periodically according to
the periodicity. With semi-persistent scheduling only retransmissions and SID frames are
scheduled dynamically, implying that the control channel capacity is not a problem for the
semi-persistent scheduler. On the other hand, only limited time and frequency domain
scheduling gains are available for semi-persistent scheduling. The semi-persistent
allocation is released during the silence periods.
Benefits
 Enabling this feature is useful for services such as VoIP for which the data packets are
small, periodic and semi-static in size.
 This reduces the control signaling overhead and improves capacity.
Release History
SLR2.2 and Later|New Entry|Basic Feature

Dependency:
 UE device supporting SPS
Limitation:
 For TDD, E-UTRAN does not simultaneously enable TTI bundling and semi-
persistent scheduling in this release of specification. (3GPP TS. 36.331)

Feature Description
Reference
2) 3GPP TS36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
3) 3GPP TS36.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Feature Scope
Follwing is the feature scope of Semi-persistent scheduling
R1 LTE LSM supports on/off for SPS function.

R2 LTE eNB supports SPS activaiton/deactivation according to the voice status
(Talkspurts/Silence) of UE in the case of operating SPS function.
R3 LTE eNB supports SPS reactivation for link adaptation to SPS activated UE in the
case of operating SPS function.
R4 LTE eNB supports the function to allocate pre-determined RB resource according to
the pre-determined periodicity in the case of operating SPS function
R5 LTE eNB support to achieve the target BLER performance for SPS transmission per
UE in the case of operating SPS function.

Feature Description
Feature Description
With semi-persistent scheduling, eNB allocates resource blocks semi-statically for a longer
period of duration and on periodic basis. The period of allocation is performed via the RRC
signaling layer.
As shown in above figure, when the packet spurt ends, the semi-persistent scheduling
resources are de-allocated. When the packet spurt restarts the semi-persistent scheduling
resources are re-allocated. Basically, semi-persistent scheduling is operated for supporting
voice packet service, and can change the related parameter adaptively, according to the
voice packet size and vocoder rate.
For example, the semi-persistent scheduling allocations are done for a fixed period of 20
msec intervals aligning to the typical VoIP packet generation period by VoIP codecs.
The semi-persistent scheduling allocation also assigns a fixed MCS of 11 for DL and MCS
of 10 for UL. The number of RBs is fixed to 2. The SID (Silence Interval Duration) Packets
that are generated by the VoIP codec are handled using dynamic scheduling. Also, any
retransmission packets are handled using dynamic scheduling.
According to the 3GPP TS. 36.331, eNB does not simultaneously enable semi-persistent
scheduling and TTI bundling in TD-LTE.

Feature Description
Semi-persistent scheduling configuration information is as below:
The UE is allocated a Semi-persistent scheduling C-RNTI (SPS C-RNTI). This is used to

address the UE within any subsequent PDCCH transmissions relevant to the allocation and
release of SPS resources. The SPS downlink interval defines the periodicity with which
persistent downlink resources will be allocated to the UE. The eNB can signal values of
{10, 20, 32, 40, 64, 80, 128, 160, 320, 640} subframes. For example, the VoIP service can
be configured with an interval of 20 subframes so speech frames can be transferred at a rate
of one per 20 ms. The number of HARQ processes for SPS in the downlink can be
configured with a value between 1 and 8. Configuring a relatively high number of HARQ
processes allows greater scope for retransmissions without impacting the flow of data.
The SPS uplink interval defines the periodicity with which persistent uplink resources will
be allocated to the UE. The eNB can signal values of {10, 20, 32, 40, 64, 80, 128, 160, 320,
640} subframes. The ‘implicit release after’ information defines the number of consecutive
empty transmissions after which the UE releases the uplink SPS resource allocation.
This prevents the UE from holding on to an unused resource allocation. The P0 parameters
are optional within the SPS configuration, and the two intervals configuration flag is
optional and only applicable to TDD.

Feature Description
System Operation
cellNum The Cell number to change -

Range: 0~MAX_CELL_PER_SYS_CDD
Default: 0
semiPersistSchedInt The reserved interval of resources for SPS UL See Related
ervalUL Range: 0~9, enumSemiPersistSchedInterval_type Commands
= value(index), {10 (0), 20 (1), 32 (2), 40
(3), 64 (4), 80 (5), 128 (6), 160 (7), 320 (8),
640 (9)}
Default: 1
implicitReleaseAfter The number of SPS release for empty MAC SDUs See Related
transmissions of UE Commands
Range: 0~3, enumimplicitReleaseAfter_type =
value(index), {2 (0), 3 (1), 4 (2), 8 (3)}
Default: 2
p0NominalPUSCHP P0 value for SPS in powr control See Related
ersistent Range: -126~24 Commands
Default: -80
p0UEPUSCHPersist SPS P0 value to use power control per UE See Related
ent Range: -8~7 Commands
Default: 0
semiPersistSchedInt SPS DL resources interval to be reserved See Related
ervalDL Range: 0~9, enumSemiPersistSchedInterval_type Commands
= value(index), {10 (0), 20 (1), 32 (2), 40
(3), 64 (4), 80 (5), 128 (6), 160 (7), 320 (8),
640 (9)}
Default: 1
numberOfConfSPSp Number of configured HARQ processes for Semi- See Related
rocesses Persistent Scheduling Commands
Range: 1~8
Default: 4
semiPersistSchedT Range: 0~40, enumTbsSPSDl_type = value(index), See Related
bsDL {120 (0), 136 (1), 152 (2), 176 (3), 208 (4), Commands
224 (5), 256 (6), 296 (7), 328 (8), 376 (9),
392 (10), 408 (11), 424 (12), 440 (13),
456 (14), 472 (15), 488 (16), 504 (17),
536 (18), 552 (19), 584 (20), 600 (21),
616 (22), 680 (23), 712 (24), 744 (25),

Feature Description
(Continued)
semiPersistSchedT 776 (26), 808 (27), 840 (28), 872 (29), See Related
bsDL 904 (30), 936 (31), 1000 (32), 1032 (33), Commands
1128 (34), 1192 (35), 1256 (36), 1352 (37)
semiPersistSchedT 1416 (38), 1544 (39)} See Related
bsDL Default: 8 Commands
semiPersistSchedT Range: 0~40, enumTbsSPSUl_type= value(index), See Related
bsUL {120 (0), 136 (1), 152 (2), 176 (3), 208 (4), Commands
224 (5), 256 (6), 296 (7), 328 (8), 376 (9),
392 (10), 408 (11), 424 (12), 440 (13),
456 (14), 472 (15), 488 (16), 504 (17),
536 (18), 552 (19), 584 (20), 600 (21),
616 (22), 680(23), 712(24), 744(25),
776 (26), 808 (27), 840 (28), 872 (29),
904 (30), 936 (31), 1000 (32), 1032 (33),
1128 (34), 1192 (35), 1256 (36), 1352 (37),
1416 (38), 1544 (39)}
Default: 8
amcOptionSPSDL Link adaptation option for DL SPS See Related
Range: 0~3, enumAmcOptionSPS_type{ci_amc_ Commands
opt0 (0), ci_amc_opt1 (1), ci_amc_opt2 (2),
ci_amc_opt3 (3)}
Default: 0
reserved reserved -
Range: 0~255
Default: 255
twoIntervalsConfig Trigger of two-intervals-Semi-Persistent Scheduling See Related
in uplink. See TS 36.321. If this field is present, Commands
two-intervals-SPS is enabled for uplink. Otherwise,
two-intervals-SPS is disabled.
Range: 0~1, enumTwoIntervalsConfig_type
{ci_false (0), ci_true (1)}
Default: 1
semiPersistSchedM The maximum allowable number of PRBs for DL See Related
axnumberOfRbDL SPS Commands
Range: 1~64
Default: 12
semiPersistSchedM The maximum allowable number of PRBs for UL See Related
axnumberOfRbUL SPS Commands
Range: 1~64
Default: 12

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME3306, Frequency Selective Scheduling

Overview
Frequency selective Scheduling allows eNB to select the best subband for resource
allocation on downlink based on the subband CQI feedback from UE.
Introduction
Frequency selective scheduling is one of the key features to provide high spectrum
efficiency in LTE. To better exploit the channel selectivity, the packet scheduler is located
in the eNB, which allocates physical layer resources for the DL-SCH transport channels
every transmission time interval (TTI). Resource assignment consists of physical resource
block (PRB) and modulation and coding scheme (MCS). Such scheduling depends on
heavily on the channel information available at the eNB, which is provided by the uplink
channel quality indicator (CQI) reporting for the downlink channel. The scheduler should
also take account of the traffic volume and the QoS requirement of each UE and associated
radio bearers. Due to the implementation of OFDMA/SC-FDMA, LTE is able to exploit the
channel variation in both the time and frequency domain, which is a major advantage
compared to HSPA, which is able to exploit channel variation only in the time domain.
Benefits
 Exploiting available channel knowledge to schedule a UE to transmit using specific
Resource Blocks (RBs) in the frequency domain where the channel response is good.
 Maximizing radio resource utilization
Release History
SLR2.2

Dependency:
 None
Limitation:
 None

Feature Description
Reference
Feature Scope
R1 LTE LSM supports a function to turn on or off frequency selective scheduling.
R2 LTE eNB supports a function to transmit the best subband by selecting it in the
assignment of RB to each UE if the frequency selective scheduling is on.

Feature Description
Feature Description
DL frequency selective scheduling involves in selecting the best sub-bands for RB
allocation. To achieve this, eNB enables UEs to report Sub-band CQI information.
Sub-band CQI information from UE reports the best sub-band that the UE determines as
the region with less interference. As part of the scheduling, during RB allocation (after user
prioritization) eNB allocates to the user the RBs in the best sub-band as requested by the
UE. Frequency Selective Scheduling is a configurable option. There are two types of CQI
Report that the UE can be configured to provide – Wideband CQI and Sub-band CQI.
Wideband CQI is measured across the entire Downlink Bandwidth and one CQI is reported
by the UE for the entire bandwidth. When frequency selective scheduling is enabled, UE is
configured to provide sub-band CQI report. A Sub-band is defined as set of contiguous RBs.
A set of contiguous sub-bands is called a BandWidth part. In case of 5 Mhz (25RBs), 1
Sub-band contains 4 RBs and 7 sub-bands are present. Two Bandwidth parts are present: 1
bandwidth part has 4 sub-bands and the other has 3 sub-bands. In each CQI report period,
the UE measures one bandwidth part and reports the CQI of the best sub-band along with
the selected best sub-band information to the eNB. Each bandwidth part is sequentially
cycled through by UE during each CQI report period. This cycle of bandwidth parts is
repeated for a period of time before reporting a Wideband CQI (note that both UE Selected
sub-band and Wideband CQI are reported when sub-band mode is enabled)

Feature Description
System operation
Command Description
CHG-CQI-REP Changes the information required to operate CQI reporting. It can set
whether to operate Wideband CQI or both of Wideband CQI and Subband
CQI per DL transmission mode.
RTRV-CQI-REP Retrieves the information required for CQI reporting operation. It can
retrieve whether only wideband CQI is operated or wideband CQI and
wideSubbandSelect Selects a Wideband/Subband CQI option. See Related

- ci_WideBand: wideband CQI only. Commands
- ci_SubBand: wideband CQI + subband CQI.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME3307, UL Sub frame Bundling

Overview
UL sub-frame bundling, which is also call TTI bundling, allows continuous transmission of
the same packet through 4 TTIs. This operation lowers effective data rate, extends uplink
cell coverage and helpful for applications such as VoIP
Introduction
When a User Equipment (UE) is at the cell edge, it may undergo power shortage due to the
transmission power limitation. To overcome the power shortage at cell edge, 3GPP LTE
provides TTI bundling operation. When TTI bundling is configured by RRC, HARQ
transmissions for a transport block are performed in consecutive TTIs without waiting for
HARQ feedback. Each HARQ transmission depends on incremental redundancy.
The eNB accumulates the received energy of all transmissions and sends HARQ feedback
only one time after the last redundancy version of the transport block is received.
Therefore, TTI bundling operation reduces the number of required HARQ feedback
messages and the overhead resulting from uplink grant.
Benefits
Operator Benefits
 Extending uplink cell coverage and helpful for applications such as VoIP
End User Benefits

 N/A
Release History
SLR2.2

Dependency
 TTI bundling supportable UE
Limitation
 None

Feature Description
Reference
layer procedures
Feature Scope
R1 eNB provides the sub-frame bundling function.
R2 eNB maintains the sub-frame bundling function during HO.

Feature Description
Feature Description
TTI bundling (or subframe bundling) is intended to improve the uplink coverage
performance of Voice over IP (VoIP), i.e. improve air-interface performance in scenarios
where coverage is limited by the UE transmit power capability. The general concept of TTI
bundling is illustrated in below figure. Each VoIP transport block is passed to the physical
layer where it has CRC bits added before being channel coded using turbo coding. 4
duplicates of the channel coded transport block are generated prior to rate matching.
Each duplicate is processed using a different Redundancy Version (RV). This provides the
eNB receiver with an Incremental Redundancy soft combining gain. The set of codewords
are modulated and mapped onto 4 consecutive uplink subframe.
Below figure is Concept of TTI bundling.
TTI bundling groups 4 consecutive uplink TTI to generate an effective TTI duration of 4 ms.
These consecutive TTI define the bundle size. 3GPP TS36.321 specifies a fixed bundle size
of 4. Transmissions belonging to each bundle size are sent without waiting for any HARQ
acknowledgements. This corresponds to using autonomous retransmission.
Each bundle of 4 TTI requires a single resource allocation from the eNB and a single
HARQ acknowledgements.
3GPP TS 36.321 specifies that a maximum of 3 resource block can be allocated when TTI
bundling is used. In addition, the modulation scheme is limited to QPSK. The combination
of upto 3 resource blocks and QPSK provides sufficient capacity to transfer the bit rate
required by VoIP. The same modulation and coding scheme (MCS) and frequency
bnadwidth are used for all 4 TTI belonging to the bundle.

Feature Description
The eNB can instruct the UE whether or not to use TTI bundling within the RRC
Connection Setup, RRC Connection Reconfiguration or RRC Connection Re-establishment
messages.
TTI bundling is applicable to both FDD and TDD. In the case of FDD, the number of
HARQ process is halved from 8 to 4. The eNB generates a single HARQ
acknowledgement for each bundle of 4 TTI. The timing of HARQ acknowledgement is
based on the timing of the last TTI within the bundle, i.e. the acknowledgement is sent 4
subframes after the last TTI in the bundle. The complete bundle of 4 TTI is retransmitted
when a HARQ acknowledgement indicates that a retransmission is required.
The retransmission delay is 16 subframe (16 ms) when using TTI bundling, comparing to
the retransmission delay of 8 subframes (8 ms) when TTI bundling is not used.
Below figure illustrates the set of 4 HARQ processes for TTI bundling with FDD.
Each transmission belonging to a specific HARQ process is separated by 16 subframes.
Below figure is FDD HARQ processes for TTI bundling.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME3401, Paging DRX

Overview
Paging DRX refers to the discontinuous operation of the UE in idle mode, where in UE
periodically wakes up from sleep mode to monitor the control channels for Paging operation.
Introduction
In LTE, DRX mode can be enabled in both RRC_IDLE and RRC_CONNECTED states.
In the RRC_IDLE state, the UE is registered with the evolved packet system (EPS)
mobility management (EMM) but does not have an active session. In this state the UE can
be paged for DL traffic, and this DRX mode can be callled as paging DRX. UE can also
initiate UL traffic by requesting RRC connection with the serving eNB. DRX mode can
also be enabled in RRC_CONNECTED state. In the RRC_CONNECTED state DRX mode
is enabled during the idle periods during the packet arrival process, and this DRX mode can
be called as active DRX. When there are no outstanding/new packets to be transmitted/
received, eNB/UE may initiate the DRX mode.

Feature Description
Below figure is Network Architecture.
The EPS network interfaces are depicted in active and various DRX enabled modes in Fig.
1. LTE-U_u is the new LTE air link interface between the eNB and the UE. S1_c is the
control plane reference point between the mobility management entity (MME) and the eNB.
The serving gateway (SGW) acts as the gateway for the evolved packet core (EPC).
Similarly, the packet data network gateway (PDNGW) acts as the gateway to the core
network. S1_u is the user plane reference point between the eNB and SGW. S11 and S5 are
the control plane reference point between the MME and SGW, and the user plane reference
point between the SGW and PDNGW, respectively. As shown in Fig. 1, when the UE is in
DRX enabled/RRC_CONNECTED state, the S1, non-access stratum (NAS), and RRC
connections are active. Only the discontinuous data exchange is on the air interface.
The rest of the network is unaware of the DRX operation. When the UE is in DRX enabled/
RRC_IDLE state, the S1, NAS, and RRC connections are removed.

Feature Description
Benefits
End User Benefits
 Enabling this feature results in longer battery life times.
Release History
SLR2.2
Reference
2) 3GPP TS 36.331 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC) protocol specification’.
Feature Scope
R1 eNB should advertise the paging cycle in system information broadcast message.

Feature Description
Feature Description
When the UE does not have packets to be received and/or transmitted for an extended
period of time, the eNB may initiate the release of UE’s RRC connection and request MME
to release the UE’s S1 connection. Furthermore, eNB removes the UEs context from the
database. MME and SGW only remove the eNB specific part of the UE context.
During the idle mode, the UE wakes up periodically to listen to the DL transmissions,
following the DRX cycle. During the idle mode, the mobility is fully controlled by UE,
since the network is not aware of the UE existence continuously. UE should perform the
signal quality measurements with respect to the serving and neighboring eNBs according to
measurement thresholds recommended by the serving eNB. Based on the signal quality
measure, the UE selects a new serving eNB when UE moves away from the current serving
eNB. When the system information advertised by the new serving eNB does not include its
tracking area, UE will perform a tracking area update to indicate its presence so that the
network knows where to page the UE in case of DL data transfer. UE may be paged by the
network when there is data addressed to that particular UE. UE returns to EMM_ACTIVE/
RRC_CONNECTED mode as soon as packet arrival is detected.
Below figure is Paging DRX.
UE may be paged by the network when there is data addressed to that particular UE. UE
returns to EMM_ACTIVE/RRC_CONNECTED mode as soon as packet arrival is detected.
However, as shown in Fig. 2, the UE takes some delay to reenter the network.
The delay depends on the paging DRX cycle, time to acquire UL synchronization, and time
to set up the RRC connection with the eNB. For DL, the difference between the actual
arrival of the packet and the UE listening to the PDCCH results in the extra delay of the
new transmission. For UL, the additional delay is as a result of the bandwidth grant from
the eNB. The paging DRX cycle has to be optimized to reduce this delay

Feature Description
System Operation
Parameters are transmitted on the overhead channel SIB2 which are used by the UE to
calculate when to wake to monitor the paging channel.
 Paging Occasion (PO): Subframe where there may be P-RNTI transmitted on PDCCH
addressing in paging message.
 Paging Frame (PF): Radio frame, which may contain one or multiple paging
occasion(s)
Two parameters are transmitted in SIB2 which allow UEs to calculate the DRX period and
determine when to wake up to monitor for paging message.
Parameter PCCH Configuration: part of SIB2
default Paging - Default paging cycle, referred to as ‘T’. T indicates the number of radio frames
Cycle in the paging cycle. Valid values are 32, 64, 128, 256 radio frames.
- The time between paging messages for each UE can be calculated
(=T x 10 msec)
- The UE specific DRX parameter, if allocated and having shorter DRX then T,
shall override T. UE specific DRX is FFS
nB - The parameter nB is used to derive the number of subframes used for paging
within each radio frame.
- Valid values of nB are 4T, 2T, T, 1/2T, 1/4T, 1/8T, 1/16T, 1/32T

N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME3402, Active DRX

Overview
When Active DRX mode is used, even in RRC Connected state, UE sleeps during inactive
periods and monitors PDCCH only during certain wake periods. This functionality
improves battery life while UE is in connected state. This feature includes both Short DRX
and Long DRX
Introduction
The 4th generation communication technique like Long Tern Evolution (LTE) needs highly
complex circuit techniques such as advanced coding, Multiple-input multiple output
(MIMO) combined with convolutional turbo coding in receiver for high data rate
communication. However, such a high complexity of receiver is one reason that consumes
battery power of User Equipment (UE), and this has become a limitation of the 4th
generation communication service. In LTE, one of the technique to improve the battery
power consumption of UE is discontinuous reception (DRX). Packet data traffic is very
bursty such that it transmits traffic for a short period and there is not transmission for a
long time. Naturally, in a delay point of view, scheduler will be better to observe downlink
control signal at every subframe and react instantly according to the traffic condition in
order to receive uplink scheduling grant or downlink data transmission. However, the
power consumption of UE is also important point not to be neglected. In this point of view,
DRX technique make a active (or RRC_connected) state UE to improve power
consumption. Active UE only observes control signal in a subframe indicated by DRX
cycle, and in other subframes switches off it’s receiver circuit to reduce power consumption.
Benefits
Enabling this feature results in longer battery life times
Release History
SLR2.2

Dependency
 None
Limitation
 None

Feature Description
Reference
2) 3GPP TS36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
Feature Scope
R1 LTE LSM supports the DRX function on/off per every QCI.
R2 LTE LSM supports to configure DRX parameters per every QCI.
R3 LTE LSM supports to configure DRX parameters of normal status and reportCGI
status for ANR.
R4 LTE eNB supports to configure the related parameters described in bottom table
according to the UE status.
R5 LTE eNB supports to schedule PDCCH according to the configured DRX parameters

Feature Description
Feature Description
LTE provides methods for the UE to micro-sleep even in the active state to reduce power
consumption while providing high QoS and connectivity. DRX in the LTE sense means
that the UE is not monitoring the PDCCH in the given subframe and is allowed to go to
power saving mode. As uplink is scheduled in downlink PDCCH, the DRX parameter
impacts both uplink and downlink performance for a UE. The DRX concept contains
different user-specific parameters that are configured via higher layer signaling.
These parameters are described in following table.
DRX Parameter Description
DRX Cycle Specifies the periodic repetition of the On Duration followed by a possible
period of inactivity
On Duration timer This parameter specifies the number of consecutive subframes the UE
follows the short DRX cycle after the DRX Inactivity Timer has expired.
DRX Inactivity Timer Specifies the number of consecutive PDCCH-subframe(s) after
successfully decoding a PDCCH indicating an initial uplink or downlink
user data transmission for this UE
DRX Retransmission Specifies the maximum number of consecutive PDCCH-subframe(s)
Timer where a downlink retransmission is expected by the UE after the first
available retransmission time.
DRX Short Cycle Specifies the periodic repetition of the On Duration followed by a possible
period of inactivity for the short DRX cycle
DRX Short Cycle This parameter specifies the number of consecutive subframe(s) the UE
Timer follows the short DRX cycle after the DRX Inactivity Timer has expired.
Basically, upon knowledge of the activity requirements in uplink and downlink for a certain
UE, the regular DRX period including a certain planned on time can be set.
These two parameters are illustrated in following figure.

Feature Description
For highly predictable traffic (e.g. VoIP), the On Duration can be set to 1 subframe and the
DRX Cycle to 20 ms or 40 ms if packet bundling is used.
For traffic that is more dynamic and in bursts with tight delay requirements, it is possible to
configure the user with a DRX Inactivity Timer where the packet scheduler can keep the
UE awake by scheduling it within a certain time window. HARQ retransmissions are
planned outside of the predefined DRX cycle to allow for a tighter DRXoptimization
without having to plan for worst case retransmissions. There is a DRX retransmission timer
defined so that a UE does not have wait for a full DRX cycle for an expected
retransmission that has been lost due to either ACK/NACK misinterpretation or PDCCH
failed detection. Signaling of SRS and CQI is tied to the DRX parameters to reduce the use
of PUCCH resources when signaling is not specifically needed for link adaptation and
scheduling purposes and thus increases the power saving for the UE in long DRX periods.
For very long DRX periods and a long time between SRS transmissions, the network and
the UE may lose the time alignment and so the UE has to the RRM management function
to properly set available DRX/SRS parameters according to the planned load on the RACH
channel.
Additionally, a short DRX cycle can be triggered that allows for periodic activity within the
regular DRX cycle if additional and time-distributed scheduling resources are needed to
facilitate the best power saving and QoS tradeoff for the given UE. The Short DRX concept
is shown in following figure and if the UE is scheduled in the current DRX window, new
scheduling opportunities are created in distributed form within the current DRX cycle.
The availability of the scheduling resources is controlled by the Short DRX Inactivity
Timer and if it expires, the UE returns to the normal DRX pattern immediately.

Feature Description
System Operation
Command Parameters
RTRV-DRX-INF Related System Parameters

CHG-DRX-INF Related System Parameters
 Related System Parameter List

drxConfigSetup Range: release, setup, reportCGI

DRX On/Off configure option.
onDurationTimerNormal Range: psf1, psf2, psf3, psf4, psf5, psf6, psf8, psf10,
psf20, psf30, psf40, psf50, psf60, psf80, psf100, psf200
normal status onDurationTimer.
drxInactivityTimerNormal Range: psf1, psf2, psf3, psf4, psf5, psf6, psf8, psf10,
psf20, psf30, psf40, psf50, psf60, psf80, psf100, psf200,
psf300, psf500, psf750, psf1280, psf1920, psf2560
normal status drx-InacitivityTimer.
drxRetransmissionTimerNormal Range: psf1, psf2, psf4, psf6, psf8, psf16, psf24, psf33
normal status drx-RetransmissionTimer.
longDRXCycleStartOffsetTypeNormal Range: sf10, sf20, sf32, sf40, sf64, sf80, sf128, sf160,
sf256, sf320, sf512, sf640, sf1024, sf1280, sf2048, sf2560
normal status longDRX-CycleStartOffset type.
shortDRXConfigSetup Range: release, setup
DRX On/Off configuration option.
shortDRXcycleNormal Range: 1~16
normal status drxShortCycleTimer value
drxShortCycleTimerNormal Range: 1~16
normal status drxShortCycleTimer value
drxSelectionOrder Range: 0~15
DRX seletion order per QCI.
onDurationTimerReportCGI Range: psf1, psf2, psf3, psf4, psf5, psf6, psf8, psf10,
Intra-RAT reportCGI status onDurationTimer value.
drxInactivityTimerReportCGI Range: psf1, psf2, psf3, psf4, psf5, psf6, psf8, psf10,
Intra-RAT status drx-InacitivntyTimer value.
drxRetransmissionTimerReportCGI Range: psf1, psf2, psf4, psf6, psf8, psf16, psf24, psf33
Intra-RAT status drx-RetransmissionTimer value.

Feature Description
(Continued)
longDRXCycleStartOffsetTypeReportC Range: sf10, sf20, sf32, sf40, sf64, sf80, sf128, sf160,
GI sf256, sf320, sf512, sf640, sf1024, sf1280, sf2048,
sf2560
Intra-RAT status longDRX-CycleStartOffset type.
onDurationTimerInterRat Range: psf1, psf2, psf3, psf4, psf5, psf6, psf8, psf10,
Inter-RAT reportCGI status onDurationTimer value.
drxInactivityTimerInterRat Range: psf1, psf2, psf3, psf4, psf5, psf6, psf8, psf10,
Inter-RAT status drx-InacitivntyTimer value.
drxRetransmissionTimerInterRat Range: psf1, psf2, psf4, psf6, psf8, psf16, psf24, psf33
Inter-RAT status drx-RetransmissionTimer value.
longDRXCycleStartOffsetTypeInterRat Range: sf10, sf20, sf32, sf40, sf64, sf80, sf128, sf160,
sf256, sf320, sf512, sf640, sf1024, sf1280, sf2048,
sf2560
Inter-RAT status longDRX-CycleStartOffset type.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-ME4005, IRC
Overview
Estimate each channel independently and calculates the Covariance matrix. After knowing
the coherence between each channel, interference from other channels can be removed.
Introduction
Advanced receivers provide an implementation method to enhance further the capacity of
the LTE system. A typical example is the Minimum Mean squared Error (MMSE) receiver
with Interference Rejection Combining (IRC). The ability of an IRC receiver to suppress
interference is a function of many factors including the number and strength of the
interfering signals and the number of receive antennas. Samsung eNB supports interference
rejection combining based on MMSE criterion to provide the improved performance at cell
boundary users that experience serious interference from other cells.
Benefits
Operator benefits
 Achieve the better quality of signal and improve system performance by cancelling the
interference at eNB receiver.
Release History
SLR2.2

Dependency
 None
Limitation
 None

Feature Description
Reference
layer procedures’
Feature Scope
R1 eNB receiver utilizes IRC scheme based on MMSE criterion to support interference
cancellation function.
R2 eNB supports IRC function ON/OFF.

Feature Description
Feature Description
In uplink, the eNB receiver utilizes interference rejection combining (IRC) scheme which
is based on MMSE criterion to support interference cancellation function.
Interference Rejection Combining (IRC)

The eNB receiver performs interference rejection combining to support interference
cancellation as follows.
Step1. The channel estimator of the eNB receiver estimates the channel of the desired
signal, and generates the covariance matrix of interference and noise.
Step2. Using the estimated channel and the covariance matrix, MMSE weight is calculated
to perform IRC.
Step3. Interference rejection is achieved by MMSE combining at the eNB receiver.
IRC scheme based on MMSE criterion achieves an optimal balance of noise
enhancement and interference suppression. Hence, IRC provides the enhanced
performance to UEs at the cell boundary that experience serious interference from
other cell.
Performances
The following curves show the example of SNR gain of MMSE (IRC) over MMSE (no IRC).
Below figure is IRC performance in uplink.
In the figure, 25 RBs, QPSK 1/3 PUSCH is used at SIR of 5 dB. EPA 5 Hz channel is
assumed.

Feature Description
System Operation
IRC function is turned off or on by changing the following parameter in the register map.

Command Parameters
IRC_Mode 0: IRC OFF, 1: IRC ON
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-OM5400, RET Support with AISG2.0

Overview
The RET Support with AISG 2.0 makes it possible to retrieve and change downtilt of RET
device.
Introduction
The RET Support with AISG 2.0 makes it possible to retrieve and change downtilt of RET
device. Using this feature, the operator can adjust remotely downtilt of RET device without
site visit.
Benefits
Operator Benefits:
 This feature enables operator to adjust remotely downtilt of RET antennas so that the
cost of network optimization is reduced.
Release History
SLR2.2

Dependency:
 This feature is supported by eNodeB to which RET device is connected.
Limitation:
 None
Reference
Standard or Technical Reports:
1) 3GPP TS 25.466 UTRAN Iuant interface: Application part
Feature Scope
1) The eNB shall be able to download application software to the RET device.
2) The eNB shall be able to control RET antenna.
3) The eNB shall be able to get the active alarms from the addressed antenna.

Feature Description
Feature Description
From AISG 2.0, multi-antenna device can be supported. If the operator want to change
downtilt of some antenna, he/she has to specify the antenna number.

Feature Description
The above two configurations need only one HDLC address.

But the below configuration (Daisy-chain configuration) needs multiple HDLC address.
It depends on the number of RET devices which are connected to the RRH.

Feature Description
System Operation
Command Description
INIT-RET This command resets the Remote Electrical Tilting (RET) equipment.
Two RETs can be connected to one RU/RRH, and each RET can run
independently.
UDT-RET-FW This command updates the firmware on the RET. When this command is
executed, verification of the specified firmware is performed and then update
is made to the RET via the defined proprietary interface. Once the update is
completed, the target unit should be reset for the updated firmware to run.
RTRV-RET-INVT This command retrieves the inventory information of the RET unit.
The inventory information is unique information held by the Field
Replaceable Unit (FRU), and includes information such as the serial number,
HW/FW version, unit type, unit ID, family type and install date. You can
retrieve inventory information recommended by TS32.692
RTRV-RET-ALM This command retrieves the list of active alarms on the RET.
CHG-RET-INF This command sets the tilt of the Remote Electrical Tilting (RET).
RTRV-RET-INF This command retrieves the tilt information of the Remote Electrical Tilting
(RET). The operator can specify the RET location to retrieve the antenna tilt,
or the operator can retrieve all the RET information without specifying the
location.
CLR-RET-ALM Deletes a specific RET alarm.
SCAN-RET-DEV Resets the connection of the connected RET. When the operator executes
the command, the operator can check the Device Scan Start Noti in the
Event window. At this point, all RET connections are initialized and RET H/W
reset is performed. (All RET lists are deleted. The operator can check the
result with RTRV-RET-INF.) When the device scan is completed, the operator
can check the Device Scan End Noti in the Event window.
TEST-RET Displays the self test results of the specified RET.
RTRV-ALDEV-INF Retrieves the device data of the RET.
CHG-ALDEV-INF Changes the device data of the RET.

Feature Description

Default
Value
INIT-RET CONN_BD_ID NONE ID of the board connected to the REIT to be
reset.
CONN_PORT_ID NONE Port ID of the board connected to the REIT
to be reset.
RET_ID NONE ID of the RET to be reset.
RESET_TYPE NONE Selects the reset type (SW/HW).
UDT-RET-FW FW_UNIT_NAME 256 Name of the firmware unit to be updated.
CONN_BD_ID NONE ID of the board connected to the RET to be
searched.
CONN_PORT_ID NONE ID of the port connected to the RET to be
searched.
RET_ID NONE ID of the RET to be searched.
RTRV-RET-INVT CONN_BD_ID NONE ID of the board connected to the RET to be
searched.
searched.
RTRV-RET-ALM CONN_BD_ID NONE ID of the board connected to the RET to be
searched.
searched.
RTRV-RET-INF CONN_BD_ID NONE ID of the board connected to the RET to be
(CHG-RET-INF) searched.
searched.
ANT_ID NONE ID of the antenna belonging to the RET.
TILT -32768~ Tilt value used to adjust the elevation angle
32767 of the antenna.
If the operator enters 100, the actual angle to
be applied is 10.0.
CLR-RET-ALM RET_ID NONE ID of the RET to be searched.
ANT_ID NONE ID of the antenna belonging to the RET.
SCAN-RET-DEV CONN_BD_ID NONE ID of the board connected to the RET to be
searched.
searched.

Feature Description
(Continued)
Default
Value
TEST-RET CONN_BD_ID NONE ID of the board connected to the RET to be
searched.
searched.
RTRV-ALDEV- CONN_BD_ID NONE ID of the board connected to the RET to be
INF (CHG- searched.
ALDEV-INF) CONN_PORT_ID NONE ID of the port connected to the RET to be
searched.
ANT_INDEX NONE ID of the RET antenna to be searched.
INSTALL_DATE 6 Install date of the RET antenna to be
searched.
INSTALLER_ID 5 Installer ID of the RET antenna to be
searched.
SECTOR_ID 32 Sector ID of the RET antenna to be
searched.
ANT_BEARING 0~65535 AntBearing of the RET antenna to be
searched.
INSTALLED_TILT -32768~ Installed tilt of the RET antenna to be
32767 searched.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-OM9001, Cell Traffic Trace

Overview
Cell traffic trace is to collect all the signaling messages going through a specific cell, which
is implemented based on 3GPP TS 32.422 and 32.423. It enables tracing of all active calls
in a cell without prior knowledge of the UEs’ identification (IMEI or IMEISV).
Introduction
The cell traffic trace function is a function to collect signaling messages on all UEs
connected to a specific cell. The operator may designate the specific cell through the LSM.
The result of the trace is transmitted to the LSM.
To trace only a certain UE specific message, it is possible to use the function to trace
subscribers and equipments.
Benefits
This feature allows operator to analyze all the signaling messages transmiting and receiving
in a specific cell, which can be used for troubleshooting.
Release History
SLR2.2

Dependency:
 LSM and MME required to use this feature
Limitation:
 The number of cells that can be traced simultaneously are limited by LSM capacity
Reference
2) 3GPP TS36.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP)
3) PP TS32.422 Telecommunication management; Subscriber and equepment trace; Trace
control and configuration management
4) PP TS32.423 Telecommunication management; Subscriber and equepment trace; Trace
data definition and management

Feature Description
Feature Scope
R1 In the EMS, it is possible to designate a cell to trace cell traffic. The operator may set
CellID, Trace Session Reference, InterfaceToTrace, Trace Depth, TCE Address, etc.
R2 The eNB allocates a trace recording session reference to each call of the cell, and then
starts the trace. Then, for each new call, the trace is started when the RRC Connection
Request message is received for it. For each existing call, the trace is started
immediately when the msgCellTrafficTraceActTrmEccb message is received from the
TRM.
R3 When receiving the first message (Downlink NAS Transport or Initial Context Setup
Request message) from the MME during call setup, the eNB sends the Cell Traffic
Trace message to the MME to notify that the call belongs to the trace targets.

Feature Description
Feature Description
The management based trace (cell traffic trace) function performs tracing of all calls
connected to the cell. When the EMS performs this trace on a specified cell using the ACT-
TRC-JOB command, the trace control and configuration parameters are relayed via the
TRM to the ECCB, and the ECCB starts tracing all calls for the cell.
In order to terminate the trace, operator can use the command DEACT_TRC_JOB at LSM.
This command orders eNB (ECCB) to stop the tracing immediately.
Cell Traffic trace will not be propagated on the X2 interface or on the S1 interface in case
of handover.

Feature Description
Management Based Trace Activation (New Call)

Feature Description

Feature Description
Management based trace activation procedure is as follows:
1) The cell to be traced is specified from the EMS using the ACT_TRC_JOB command
and the trace control and configuration information is relayed to the TRM.
2) The ECCB receives the msgCellTrafficTraceTrmEccb message from the TRM.
This message includes the CellID, Trace Session Reference, InterfaceToTrace, Trace
Depth, and TCE Address information within itself.
3) The ECCB allocates a trace recording session reference to each call of the cell, and
starts the trace. Then, for each new call, the trace is started when the RRC Connection
Request message is received for it. For each existing call, the trace is started
immediately when the msgCellTrafficTraceActTrmEccb message is received from the
TRM.
4) When sending or receiving a protocol message, the ECCB checks the InterfaceToTrace
(Uu, X2, S1-MME) value, and if it is a corresponding interface message, it sends the
msgCallTraceEccbTrm message to the TRM.
5) When receiving the first message (Downlink NAS Transport or Initial Context Setup
Request message) from the MME during call setup, the ECCB sends the Cell Traffic
Trace message to the MME to notify that the call belongs to the trace targets.

Feature Description
Management Based Trace Deactivation
If the call ends normally by sending the RRC Connection Release message to the UE, the
trace for that call is terminated. Tracing can be stopped for a cell currently being traced at
the EMS by using the DEACT-TRC-JOB command. When the ECCB receives the
msgCellTrafficTraceDeactTrmEccb message from the TRM, tracing for all calls for the cell
is stopped.

Feature Description
System Operation
The procedure for enabling cell traffic trace is as follows:
1) Log into the LSM and select Performance Management >> Call Trace.
2) Perform the management-based trace for a trace type.
3) If the management-based trace is selected, the list of ESM is displayed and when the
ESM is selected, the list of NE connected to the ESM is displayed.
4) If eNB or EPC System NE is selected, the result of viewing is displayed on the screen.
When the management-based trace is selected and the NE is not selected, the list of all
traces in the table of managing the trace list of the LSM is displayed.
5) Press the REGISTER button and then the [Register Call Trace] screen is displayed.
6) Press the Start button and then the [Display Real Time Data] screen is displayed.
7) Click the DELETE button and then the trace is deleted.
8) Click the REFRESH button and then the list in the trace list table is re-displayed.

Command Description
ACT-TRC-JOB Enable a trace.
Default
value
Trace Type To trace a specific call, performs the signaling-based trace. - -
ESM If the signaling-based trace is selected, the list of ESM is - -
displayed and when the ESM is selected, the list of NE
connected to the ESM is displayed.
Target NE If eNB or EPC System NE is selected, the result of viewing is - -
displayed on the screen. When the management-based trace
is selected and the NE is not selected, the list of all traces in
the table of managing the trace list of the LSM is displayed.
IMSI Information on IMSI of the phone to trace - -
DEPTH TRACE DEPTH-Regarding MIN, MED, MAX, MIN (VSE), - -
MED (VSE), MAX (VSE) and
VSE depth, prints out all including AS secured messages,
traffic traces, and RF traces.
NE Type Possible to set an interface and an event to trace by NE type. - -

Feature Description
Related Counter and KPI

 Collected Data on Uu Interface according to the trace depth
Trace Trace
Data Name Message Name Description Depth Depth
(Min) (Med)
Cs fallback MOBILITY FROM Whether a fallback to the CS M M
indicator EUTRA COMMAND network is possible
CN domain Identifies whether the domain is M M
PAGING
the CS network or PS network.
S-TMSI S-TMSI information of the UE M M
PAGING
(MME code, M-TMSI)
Reestablishmen RRC CONNECTION Cause of UE’s re-establishment M M
tCause REESTABLISHMENT
REQUEST
Wait time The period of time for which the M M
RRC CONNECTION
system waits until the UE attempts
REJECT
a call again
Release Cause RRC CONNECTION The reason for which the UE’s M M
RELEASE connection has been released
Redirection The carrier frequency of the RAT M M
RRC CONNECTION
Information used by the UE during cell
RELEASE
reselection
Establishment RRC CONNECTION The reason for which the UE’s M M
Cause REQUEST connection has been established
Selected PLMN- RRC CONNECTION UE selected PLMN ID M M
Identity SETUP COMPLETE
RegisteredMME RRC CONNECTION Information of the MME with which M M
SETUP COMPLETE the UE is registered
Rat-Type UE CAPABILITY The RAT information of the M M
INFORMATION capabilities given by the UE
Measured MEASUREMENT The results measured by the X M
Results REPORT terminal
CDMA2000- HANDOVER FROM CDMA2000Type information M M
Type EUTRA (1xRTT, HRPD)
PREPARATION
REQUEST
UL HANDOVER
PREPARATION
TRANSFER
UL INFORMATION
TRANSFER
Target RAT MOBILITY FROM The RAT information for the target M M
Type EUTRA COMMAND

Feature Description
 Collected Data on S1 Interface according to the trace depth
Trace Trace
(Min) (Med)
E-RAB ID All messages containing the ID E-RAB ID M M
E-RAB Level E-RAB SETUP REQUEST QoS for the E- M M
QoS E-RAB MODIFY REQUEST RAB
Parameters INITIAL CONTEXT SETUP REQUEST
Cause INITIAL CONTEXT SETUP FAILURE Cause for failure M M
UE CONTEXT RELEASE REQUEST of the message
UE CONTEXT RELEASE COMMAND
UE CONTEXT MODIFICATION
FAILURE
HANDOVER REQUIRED
HANDOVER PREPARATION FAILURE
HANDOVER REQUEST
HANDOVER FAILURE
HANDOVER CANCEL
PATH SWITCH REQUEST FAILURE
NAS NON DELIVERY INDICATION
Handover Type HANDOVER REQUIRED Handover type M M
HANDOVER COMMAND (IntraLTE,
HANDOVER REQUEST LTEtoUTRAN...)
E-UTRAN CGI HANDOVER NOTIFY Cell global ID of M M
PATH SWITCH REQUEST the eNB (PLMN ID
INITIAL UE MESSAGE + cell ID)
UPLINK NAS TRANSPORT
TAI HANDOVER NOTIFY Tracking area ID M M
PATH SWITCH REQUEST of the eNB (PLMN
UPLINK NAS TRANSPORT ID + TAC)
Target ID HANDOVER REQUIRED ID of the target M M
RAT which is the
handover target
CDMA2000 HO DOWNLINK S1 CDMA2000 Whether the HO to M M
Status TUNNELING the CDMA2000 is
successful
CDMA2000 DOWNLINK S1 CDMA2000 RAT information of M M
RAT Type TUNNELING the CDMA2000
UPLINK S1 CDMA2000 TUNNELING (1xRTT, HRPD)
CDMA2000 UPLINK S1 CDMA2000 TUNNELING Sector ID of the M M
Sector ID CDMA2000

Feature Description
(Continued)
Trace Trace
(Min) (Med)
CDMA2000 HO UPLINK S1 CDMA2000 TUNNELING Whether the UE M M
Required has to prepare
Indication handover to the
CDMA2000
 Collected Data on X2 Interface according to the trace depth
Trace Trace
(Min) (Med)
E-RAB id All messages where it is present ID of the E-RAB M M
E-RAB Level HANDOVER REQUEST QoS for the E- M M
QoS RAB
Cause HANDOVER REQUEST Cause information M M
HANDOVER PREPARATION FAILURE of each message
HANDOVER CANCEL
Target Cell ID HANDOVER REQUEST Handover target’s M M
cell ID
GUMMEI HANDOVER REQUEST Handover target’s M M
GUMMEID
UE History HANDOVER REQUEST History of the UE M M
Information
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-OM9002, Subscriber and Equipment Trace

Overview
Subscriber and equipment trace allows operator to collect signaling messages that are
releated to the UE. The S1-MME, X2 and Uu interfaces can be traced based on 3GPP TS
32.422 and 32.423
Introduction
To analyze a message for a specific call, the eNB provides UE-based trace function.
The operator enables a call trace based on IMSI through MME (or LSM-C).
The trace for the specific call uses the signaling-based trace function. If the Trace
Activation IE is included in the Initial Context Setup Request message or the Trace Start
message received from MME by the eNB, the eNB starts tracing the call. If the X2 or S1
handover is processed and the Trace Activation IE is included when the Handover Request
message is received from Source eNB or MME, the trace is started for the call.
Because the subscriber and equipment trace captures the signaling message based on a call,
a random access signaling message is not collected before the broadcast message instead of
the UE associated message or UE is identified. To do this, a cell traffic trace function to
collect all messages based on cells must be used.
Benefits
For a designated user, operator can monitor signaling messages traveling through S1-MME,
X2 and Uu interfaces. Call trace helps operator do network and operation analysis based on
the trace results.
Release History
SLR2.2

Dependency:
 LSM, MME
Limitation:
 Maximum 6 UEs can be traced per cell at the same time.
 LSM may allow a limited number of call traces at the same time.

Feature Description
Reference
2) 3GPP TS36.413 Evolved Universal Terrestrial Radio Access Network(E-UTRAN); S1
pplication Protocol (S1AP)
3) 3GPP TS32.422 Telecommunication management; Subscriber and equepment trace;
Trace control and configuration management
Trace data definition and management
Feature Scope
R1 If Trace Activation IE is included in the Initial Context Setup Request message, the
Trace Start message or the Handover Request (S1/X2) message from the MME, the
eNB starts the trace for the call.
R2 If the tracing UE processes S1 or X2 Handover, Trace Activation IE is included in the
Handover Request (S1/X2) message to continuously trace even in Target eNB.
R3 The trace subjects all signaling messages of Uu, X2, and S1-MME protocols.
R3 The result of the trace is transmitted to TCE.

Feature Description
Feature Description
The Call Trace function allows operator to check the detailed information for one or more
UEs more easily. The main purpose of the call trace function is to analyze dropped calls.
However, it is also used to solve a functional problem with UE, analyze resource usage of
UE, and provide quality optimization. Basically, the call tracing function captures signaling
messages as per 3GPP standard. There are two trace activation methods; ‘Management
Based Trace Activation’ and ‘Signaling Based Trace Activation’.
eNB starts call tracing when eNB receives the tracing request message from MME.
eNB sends the tracing results to Trace Collection Entity (TCE). TCE information is
included in the tracing request message.
Signaling Based Trace Activation

Tracing a specific call is only possible using the Signaling Based Trace function.
If the Trace Activation IE is contained in the Initial Context Setup Request message, or
Trace Start message received from the MME, the ECCB starts a trace for the call. When X2
or S1 handover is performed, if the Trace Activation IE is contained in the Handover
Request message received from the source eNB or the MME, the ECCB starts a trace for
the call.

Feature Description
Below figure is Signaling Based Trace Activation.
1) When the target eNB receives the Initial Context Setup Request message or Trace Start
message from the MME, or receives the Handover Request message during X2 or S1
handover, if the Trace Activation IE is contained the received message, the ECCB
starts a trace for the call immediately.
2) When sending or receiving a protocol message, the ECCB checks the InterfaceToTrace
(Uu, X2, S1-MME) value, and if it is a corresponding interface message, it sends the
msgCallTraceEccbTrm message to the TRM.

Feature Description
Signaling Based Trace Deactivation
If the call ends normally by sending a RRC Connection Release message to the UE, the
trace is ended. In order to stop the tracing, MME sends the Deactivate Trace message to
eNB.

Feature Description
System Operation
A trace function for the specific call is triggered from the MME. Trace methods are as
follows:
1) Log into the LSM and select Performance Management >> Call Trace.
2) Perform the signaling-based trace for a trace type.
3) If the signaling-based trace is selected, the list of ESM is displayed and when the ESM
is selected, the list of NE connected to the ESM is displayed.
4) If eNB or EPC System NE is selected, the result of viewing is displayed on the screen.
When the management-based trace is selected and the NE is not selected, the list of all
traces in the table of managing the trace list of the LSM is displayed.
5) Press the REGISTER button and then the [Register Call Trace] screen is displayed.
6) Press the Start button and then the [Display Real Time Data] screen is displayed.
7) Click the DELETE button and then the trace is deleted.
8) Click the REFRESH button and then the list in the trace list table is re-displayed.

Default
Value
Trace Type To trace a specific call, performs the signaling-based - -
trace.
ESM If the signaling-based trace is selected, the list of ESM - -
is displayed and when the ESM is selected, the list of
NE connected to the ESM is displayed.
Target NE If eNB or EPC System NE is selected, the result of - -
viewing is displayed on the screen.
- When the management-based trace is selected and
the NE is not selected, the list of all traces in the
table of managing the trace list of the LSM is
displayed.
IMSI Information on IMSI of the phone to trace - -
DEPTH TRACE DEPTH-Regarding MIN, MED, MAX, MIN - -
(VSE), MED (VSE), MAX (VSE) and
VSE depth, prints out all including AS secured
messages, traffic traces, and RF traces.
NE TYPE Possible to set an interface and an event to trace by - -
NE type.

Feature Description

 Collected Data on Uu Interface according to the trace depth
Trace Trace
(Min) (Med)
Cs fallback MOBILITY FROM EUTRA Whether a fallback to the M M
indicator COMMAND CS network is possible
CN domain PAGING Identifies whether the M M
domain is the CS network
or PS network.
S-TMSI PAGING S-TMSI information of the M M
UE (MME code, M-TMSI)
Reestablishmen RRC CONNECTION Cause of UE’s re- M M
tCause REESTABLISHMENT establishment
REQUEST
Wait time RRC CONNECTION REJECT The period of time for M M
which the system waits
until the UE attempts a
call again
Release Cause RRC CONNECTION RELEASE The reason for which the M M
UE’s connection has
been released
Redirection RRC CONNECTION RELEASE The carrier frequency of M M
Information the RAT used by the UE
during cell reselection
Establishment RRC CONNECTION REQUEST The reason for which the M M
Cause UE’s connection has
been established
Selected PLMN- RRC CONNECTION SETUP UE selected PLMN ID M M
Identity COMPLETE
RegisteredMME RRC CONNECTION SETUP Information of the MME M M
COMPLETE with which the UE is
registered
Rat-Type UE CAPABILITY INFORMATION The RAT information of M M
the capabilities given by
the UE
Measured MEASUREMENT REPORT The results measured by X M
Results the terminal
CDMA2000- HANDOVER FROM EUTRA CDMA2000Type M M
Type PREPARATION REQUEST information (1xRTT,
UL HANDOVER PREPARATION HRPD)
TRANSFER
UL INFORMATION TRANSFER

Feature Description
(Continued)
Trace Trace
(Min) (Med)
Target RAT Type MOBILITY FROM EUTRA COMMAND The RAT information M M
for the target
 Collected Data on S1 Interface according to the trace depth
Trace Trace
(Min) (Med)
E-RAB ID All messages containing the ID E-RAB ID M M
E-RAB Level E-RAB SETUP REQUEST QoS for the E-RAB M M
QoS E-RAB MODIFY REQUEST
Parameters INITIAL CONTEXT SETUP
REQUEST
Cause INITIAL CONTEXT SETUP FAILURE Cause for failure of M M
UE CONTEXT RELEASE REQUEST the message
UE CONTEXT RELEASE COMMAND
UE CONTEXT MODIFICATION
FAILURE
HANDOVER REQUIRED
HANDOVER PREPARATION
FAILURE
HANDOVER REQUEST
HANDOVER FAILURE
HANDOVER CANCEL
PATH SWITCH REQUEST FAILURE
Handover Type HANDOVER REQUIRED Handover type M M
HANDOVER COMMAND (IntraLTE,
HANDOVER REQUEST LTEtoUTRAN...)
E-UTRAN CGI HANDOVER NOTIFY Cell global ID of the M M
PATH SWITCH REQUEST eNB (PLMN ID +
INITIAL UE MESSAGE cell ID)
TAI HANDOVER NOTIFY Tracking area ID of M M
PATH SWITCH REQUEST the eNB (PLMN ID +
UPLINK NAS TRANSPORT TAC)
Target ID HANDOVER REQUIRED ID of the target RAT M M
which is the
handover target

Feature Description
(Continued)
Trace Trace
(Min) (Med)
CDMA2000 HO DOWNLINK S1 CDMA2000 Whether the HO to M M
Status TUNNELING the CDMA2000 is
successful
CDMA2000 DOWNLINK S1 CDMA2000 RAT information of M M
RAT Type TUNNELING the CDMA2000
UPLINK S1 CDMA2000 TUNNELING (1xRTT, HRPD)
CDMA2000 UPLINK S1 CDMA2000 TUNNELING Sector ID of the M M
Sector ID CDMA2000
CDMA2000 HO UPLINK S1 CDMA2000 TUNNELING Whether the UE M M
Required has to prepare
Indication handover to the
CDMA2000
 Collected Data on X2 Interface according to the trace depth
Trace Trace
(Min) (Med)
E-RAB id All messages where it is present ID of the E-RAB M M
E-RAB Level HANDOVER REQUEST QoS for the E- M M
QoS RAB
Cause HANDOVER REQUEST Cause information M M
HANDOVER PREPARATION FAILURE of each message
HANDOVER CANCEL
Target Cell ID HANDOVER REQUEST Handover target’s M M
cell ID
GUMMEI HANDOVER REQUEST Handover target’s M M
GUMMEID
UE History HANDOVER REQUEST History of the UE M M
Information
Related Alarms
N/A
Related Status
N/A

Feature Description
Related Call Faults

N/A

Feature Description
LTE-OM9003, Call Detail Trace

Overview
Call Detail Trace provides more specific information that the standard defined subscriber
equipment trace. The trace result includes traffic and RF information.
Introduction
As a call detail trace for a specific phone, the more detailed information than the level
defined in the standard is provided. The detailed information and the RF information for
the traffic is included. The operator may trigger the call detail trace through LSM-C.
The result of the trace is transmitted to the LSM-R.
Benefits
Cell detail trace helps to analysis traffic (throughput,. etc) and RF information per UE.
Release History
SLR2.2

Dependency:
 Possible to designate a specific phone in connection with LSM-R and LSM-C
Limitation:
 With the limited performance of the DSP, the calls for detail traces are limited to six
per cell.
 The trace is performed by the cycle of 2.56 seconds.
Reference
Trace control and configuration management
Trace data definition and management

Feature Description
Feature Scope
R1 If the trace depth in the signaling-based trace is Min/Med/Max (with VSE), the eNB
performs the call detail trace.

Feature Description
Feature Description
Unlike the signaling trace of the existing standard, the call detail trace function is to
perform traces for traffic and RF information of the designated phone. Because this
function is non-standard, it operates only when the trace depth is selected as the vendor
specific element. In other words, if the detailed call trace is started through the signaling-
based trace, the base station performs the detailed traffic trace for the Min/Med/Max (with
VSE) depth (All depths which are VSE).
The trace procedure is as follows:

Feature Description
 If the Trace Activation IE is contained in the Initial Context Setup Request message, or
Trace Start message received from the MME, the ECCB starts a trace for the call.
 When the signaling trace is started, the ECCB transmits the detailed trace (Start) to
TRM, PDCB, RLC, and MAC.
 PDCB and RLC transmits the traffic information to TRM at a fixed interval and MAC
transmits traffic and RF information to TRM at a fixed interval.
 TRM transmits traffic and RF trace data received from PDCB, RLC, and MAC to
EMS.
 When the signaling trace is closed, the ECCB transmits the detailed trace (Stop)
message to TRM, PDCB, RLC, and MAC.

Feature Description
System Operation
N/A
Related Counter and KPIs

The information collected as the result of the call detail trace is as follows:
Counter Type Description
Equip - In case of Equip, transmits the value periodically./In case

of N_Equip, stops transmission.
Trace Reference ID - The trace reference ID of the phone
DL PDCP Bytes_TOTAL - No. of DL bytes transmitted from S-GW to eNB within the
collection interval.
UL PDCP Bytes_TOTAL - No. of bytes transmitted to UL within the collection interval
Number of DL PDCP - No. of user data packets transmitted to UE
Packets_TOTAL
Number of UL PDCP - No. of user data packets received from UE
Packets_TOTAL
Number of Dropped DL - No. of DL packets dropped from PDCP
PDCP Packets_TOTAL
Number of Dropped UL - No. of UL packets dropped from PDCP
PDCP Packets_TOTAL
Active Bearer Count Range: Maximum number of the bearers being used in the
1~8 interval
Bearer1 ID Range: RB_ID (1~8)
1~8
Bearer1 QCI Range: QoS ID
1~255
DL PDCP Bytes_Bearer1 - No. of DL bytes transmitted from S-GW to eNB within the
collection interval.
UL PDCP Bytes_Bearer1 - No. of bytes transmitted to UL within the collection interval
Packets_Bearer1
Packets_Bearer1
PDCP Packets_Bearer1

Feature Description
(Continued)

Bearer 8 ID Range: RB_ID (1~8)
1~8
Bearer8 QCI Range: QoS ID
1~255
DL PDCP Bytes_Bearer8 - DL Byte number of transmit from S-GW to eNB for
gathering period
UL PDCP Bytes_Bearer8 - No. of bytes transmitted to UL within the collection interval
Packets_Bearer8
Packets_Bearer8
DL RLC Bytes - DL RLC bytes transmitted within the collection interval
UL RLC Bytes - UL RLC bytes transmitted within the collection interval
Number of DL RLC - DL RLC packets transmitted within the collection interval
Packets
Number of UL RLC - UL RLC packets transmitted within the collection interval
Packets
Number of Lost Packet at - No. of lost packets in RLC DL Air section (In case of UL,
RLC DL impossible to measure)
However, at the second inspection of Yota in May 2011,
collects only with 0 (Not indicated in the LSM).
Number of DL - Possible to measure accurate losses only in the DL AM
Retransmitted Packets mode.
Number of Dropped - No. of packets discarded from RLC
Packet at RLC DL However, at the second inspection of Yota in May 2011,
Number of Delayed - No. of packets delayed from RLC
Packet at RLC layer However, at the second inspection of Yota in May 2011,
User Plane Latency - IP latency (unit = ms)
Active Bearer Count - Maximum number of the bearers being used in the
interval
Bearer 1 ID - RB_ID (1~8)

Feature Description
(Continued)
Bearer 1 QCI Range: QoS ID

1~255
DL RLC Bytes_Bearer 1 - DL RLC bytes transmitted within the collection interval
UL RLC Bytes_Bearer 1 - UL RLC bytes transmitted within the collection interval
Packets_Bearer 1
Packets_Bearer 1
RLC DL_Bearer 1 impossible to measure)
Retransmitted mode.
Packets_Bearer 1
Packet at RLC However, at the second inspection of Yota in May 2011,
DL_Bearer 1 collects only with 0 (Not indicated in the LSM).
layer_Bearer 1 collects only with 0 (Not indicated in the LSM).
User Plane - IP latency (unit = ms)
Latency_Bearer 1
Bearer 8 ID - RB_ID (1~8)
1~255
DL RLC Bytes_Bearer 8 - DL RLC bytes transmitted within the collection interval
UL RLC Bytes_Bearer 8 - UL RLC bytes transmitted within the collection interval
Packets_Bearer 8
Packets_Bearer 8
RLC DL_Bearer 8 impossible to measure)
Retransmitted mode.
Packets_Bearer 8

Feature Description
(Continued)

DL_Bearer 8 collects only with 0 (Not indicated in the LSM).
layer_Bearer 8 collects only with 0 (Not indicated in the LSM).
User Plane - IP latency (unit = ms)
Latency_Bearer 8
DL Traffic ratio  DL - Transmitted in DL traffic bytes (integers)
Traffic Bytes (Total of Aggregate of 8 DRBs (SRB information excluded)
DRBs)
UL Traffic ratio  UL - Transmitted in UL traffic bytes (integers)
Traffic Bytes (Total of Aggregate of 8 DRBs (SRB information excluded)
DRBs)
Active Bearer Count Range: Maximum number of the bearers being used in the
1~255 interval
Bearer 1 ID Range: RB_ID
1~255
1~255
DL Traffic Bytes (DRB #1) - DL Traffic Bytes DRB #1
UL Traffic Bytes (DRB #1) - UL Traffic Bytes DRB #1
Bearer 8 ID Range: RB_ID
1~255
1~255
DL Traffic Bytes (DRB 8) - DL Traffic Bytes DRB #8
UL Traffic Bytes (DRB 8) - UL Traffic Bytes DRB #8
The RF information included in the result of the call detail trace is as follows:
Equip - In case of Equip, transmits the value periodically./In case

of N_Equip, stops transmission.
Trace Reference ID - The trace reference ID of the phone
UE’s Power Headroom - The average value received during the fixed interval (dB)
A negative number allowed.

Feature Description
(Continued)
BSR (buffer Status Report) - The average value received during the fixed interval
information on RBG (Radio (bytes)
Bearer Group)
CQI 1 - Widbad CQI (1-15). Accumulated count type by CQI level
in the given interval
CQI 15 - -
SRS snr - Provides SRS received power as the mean of the valid
value in the given interval.
DL MCS 0 - Possible to six counts per cell to the maximum by phone
due to the performance issue. Interval of 2.56 seconds
DL MCS 31 - Possible to six counts per cell to the maximum by phone
UL MCS 0 - Possible to six counts per cell to the maximum by phone
UL MCS 31 - Possible to six counts per cell to the maximum by phone
UL BLER - No. of CRC error-occurring blocks/no. of total blocks
received (MAC PDU). (Unit: %)
DL assigned RE count - DL direction assigned RE count
DL assigned RB count - DL direction assigned RB count
UL assigned RE count - UL direction assigned RE count
UL assigned RB count - UL direction assigned RB count
TPC for PUCCH[0] (-1 dB) - Accumulated PUCCH power control statistics
(Accumulated value of the TPC (transmit power control)
command (-1 dB) transmission count)
TPC for PUCCH[1] (0 dB) - Accumulated PUCCH power control statistics
command (0 dB) transmission count)

Feature Description
(Continued)
TPC for PUSCH[0] (-1 dB) - Accumulated PUCCH power control statistics
TPC for PUSCH[1] (0 dB) - Accumulated PUCCH power control statistics
Time Advance - Accumulated value of TA (Average RTD)
- The unit of raw data provided from MAC is the multiple
of 0.52 us. In short, the actual output must be the value
of 0.52us * time advance (Unit: us).
UE  eNB PMI 0 - Information informed by UE (Precoder Metric Indicator)
(UL PMI 0) index 0
UL PMI = PMI received from UE
(UL PMI 1) index 1
(UL PMI 2) index 2
(UL PMI 3) index 3
eNB  UE PMI 0 - Information given by the base station (Precoder Metric
(DL PMI 0) Indicator) index 0
PMI allocated to UE
PMI allocated to UE
PMI allocated to UE
PMI allocated to UE
eNB  UE RI 0 - # of assignment on layer 0 (during 2.56 sec)
(UE DL RI 0)

Feature Description
(Continued)
eNB  UE RI 1 - # of assignment on layer 1 (during 2.56 sec)

(UE DL RI 1)
UE  eNB RI 0 - RI requested by UE-Count by index (index 0)
(UE UL RI 0)
UE  eNB RI 1 - RI requested by UE-Count by index (index 1)
(UE UL RU 1)
DL ACK - DL Number of HARQ feedback for PUCCH (ACK)
DL NACK - DL Number of HARQ feedback for PUCCH (NACK)
DL DTX - DL Number of HARQ feedback for PUCCH (DTX)
UL ACK - UL Number of HARQ feedback for PUCCH (ACK)
UL NACK - UL Number of HARQ feedback for PUCCH (NACK)
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-OM9004, CSL(Call Summary Log) Report

Overview
Call Summary Logs are delivered from eNB to LSM-R or an external server. These logs
are provided on a per call basis and contain other useful information such as call setup time,
call release time, handover information, failure information etc.
Introduction
The Call Summary Log (CSL) report collects the statistics information for a call. The call
release type, call duration, or handover information, etc. is automatically collected and
transmitted to the CSL server. Although the default server that collects CSL information is
LSM, you can also use a separate server by considering collected information.
Benefits
Operator can collect summary of calls with detail information such as call setup time, call
release time, handover information, failure information etc
Release History
SLR2.2

Dependency
 LSM
Limitation
 The number of CSL records that can be saved depends on the LSM capacity.
Reference
Feature Scope
The R1. eNB collects and saves CSL Record information for all the calls.
The R2. eNB transmits a created CSL record at every 5 s. to the LSM or when there are 10
CSL records.

Feature Description
Feature Description
The Call Summary Log (CSL) data collected by eNB is stored at eNB. When a given
amount of CSL data is accumulated in the memory or when a given amount of buffering
time (RTRV-CSL-INFO) elapses, eNB sends the data to the LSM. When the LSM receives
CSL data, it stores the raw data to the /log/csl directory; the data can be displayed through
the LSM’s call history window.
The CSL data includes various information for a call. It includes a total of 10 information
items: call information, common item information, connection information, release
information, handover information, throughput information, RF information, adjacency
information, UE history information, and call debugging information.

Feature Description
System operation
N/A
Related Counters and KPI

CSL Data Items is as follows.
CSL Data Item Data Name Description
Call Information cslEvent The information for the CSL event

- 0: RRC Release
- 1: Outgoing Handover
sTmsi The STMSI information for the call.
This consists of the 1-byte mmeCode information and the 4-
byte mTmsi value.
mmeUeS1APId The S1AP ID of the call allocated by the MME
enbUeS1APId The S1AP ID of the call allocated by the eNB
Common Item mmeId This global unique compatible MME ID consists of reserved
Information (1 byte) + PLMN ID (3 bytes) + MME group (2 bytes) + MME
code (1 byte).
tai The tracking area ID which consists of PLMN ID (3 bytes) +
TAC (1 byte)
enbId The eNBID to create the CSL consists of reserved (1 byte) +
PLMN ID (3 bytes) + enbType (4 bytes) + eNBid (4 bytes).
enbType: 0 (Macro enb), 1 (Home enb)
enbName The eNB that created the CSL. Max 20 bytes
callReleaseCau The reason for call failure
se
Connection attemptYear The year/month/day on which the call is connected
Information attemptMon The year/month/day on which the call is connected
attemptMday The year/month/day on which the call is connected
attemptHour The time at which the call is connected (hour/minute/second)
attemptMin The time at which the call is connected (hour/minute/second)
attemptSec The time at which the call is connected (hour/minute/second)
attemptMilisec The time at which the call is connected (hour/minute/second)

Feature Description
(Continued)
Connection setupHour The time at which the DRB was established

Information (hour/minute/second)
setupMin The time at which the DRB was established
(hour/minute/second)
setupSec The time at which the DRB was established
setupMilisec The time at which the DRB was established
freqBandIndicator The bandclass when the target call is released (e.g. 1.5 G
or 800 M, etc.)
cgi The cell ID when the target call is connected (CGI: Cell
Global ID)
reserved (1 byte), PLMN ID (3 bytes) + Cell ID (28 bits)
pci The cell ID when the target call is connected (PCI: Physical
Cell ID)
mmeIpAddr The information for the upper equipment communicated
when the call is connected (ID and IP address, etc.)
sGateIpAddr The information for the upper equipment communicated
TA The round-trip delay time (distance) between the UE and
eNB when the call is connected
cardId The resource information for the channel card accessed
when the target call is connected
transmitMode The transmission antenna mode when the call is connected
callType Identifies the type of the call, such as origination,
termination, or handover call.
mmeIpAddr The information for MME’s upper equipment communicated
sGateIpAddr The information for S-GW communicated when the call is
connected (ID and IP address, etc.)
reserved reserved
reserved reserved
Release year The year/month/day on which the call is released
Information month The year/month/day on which the call is released
mday The year/month/day on which the call is released

Feature Description
(Continued)
Release hour The time at which the call is released (hour/minute/second)

Information min The time at which the call is released (hour/minute/second)
sec The time at which the call is released (hour/minute/second)
milisec The time at which the call is released (hour/minute/second)
pci The cell ID when the target call is released (PCI: Physical
Cell ID)
cgi The cell ID when the target call is released (CGI: Cell Global
ID)
freqBandIndicat The bandclass when the target call is released (e.g. 1.5 G or
or 800 M, etc.)
cqi The CQI reported by the UE before the call is released
TA Round-trip delay time (distance) between the UE and eNB
when the call is released
cardId The card information for the node accessed when the target
call is released
pA The downlink power control parameter PA when the call is
released
transmitMode Transmission antenna mode when the call is released
mmeIpAddr The information for the upper equipment communicated when
the call is connected (ID and IP address, etc.)
sGateIpArrd The information for the upper equipment communicated when
the call is connected (ID and IP address, etc.)
reserved reserved
Handover enbId The eNBID of the target eNB when handover is performed.
Information This consists of PLMN ID (3 bytes) + enbType (4 bytes) +
eNBid (4 bytes). enbType: 0 (Macro enb), 1 (Home enb)
enbIpAddr The IP address of the target eNB when handover is
performed
cgi The cell ID of the target cell when handover is performed
(CGI: Cell Global ID)
PLMN ID (3 bytes) + Cell ID (28 bits).
pci The physical cell ID of the target cell when handover is
performed (PCI: Physical Cell ID)

Feature Description
(Continued)
Throughput rbId Radio Bearer ID

Information epsbearerId E-RAB ID
txDataToSG The total bytes of data sent to the upper node during the
time between connection and release
qci QoS class identifier
rxDataFromSG The total bytes of data received from the upper node during
the time between connection and release
txDataToUE The total bytes of data sent to the UE during the time
between connection and release
reTxDataToUE The total bytes of data resent to the UE during the time
rxDataFromUE The total bytes of data received from the UE during the time
RF Information txPower The power sent from the eNB
ueTxPower The power sent from the UE
rsrp Reference signal received power
rsrq Reference signal received quality
Adjaency cgi The cell ID of the cell with the highest PSRP among the
Information adjacent cells reported by the UE (CGI: Cell Global ID)
PLMN ID (3 bytes) + Cell ID (28 bits)
pci The physical cell ID of the cell which has the highest RSRP
of the adjacent cells reported by the UE
rsrp RSRP of the adjacent cell ID #1
rsrq RSRQ of the adjacent cell ID #1
UE History cgi The cell global ID of the cell to which the UE belonged
Information PLMN ID (3 bytes) + Cell ID (28 bits)
cellSize The size of the cell to which the UE belonged
stayTime The time for which the UE belongs to the cell
Call Debugging stateCmd The state which changes according to the message
Informaiton received externally
callState The ECCB state which changes according to the message
received internally and externally
msgId The ID of the message with which the call failure occurred
cslsequenceNum The sequence number of the CSL generated
callId Call ID

Feature Description
(Continued)
Call Debugging Imsi ID used to distinguish UE in CN (IMSI: International Mobile

Informaiton Subscriber Identity)
C-RNTI ID used to distinguish UE in the cell
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-OM9005, Packet Loss Detection over S1

Overview
eNB counts and provide statistics about lost packets and out-of sequence packets occurred
during delivery from SGW to eNB. This feature can be enabled only when eNB interworks
with Samsung EPC.
Introduction
This function is used to judge the quality or status of backhaul network in the DL section
between SGW and eNB.
This function is used to count the number of lost packets for a user data transmitted from
SGW to eNB and also the number of packets whose order is changed. The SGW records
the sequence number of GTP protocol for each packet and the eNB checks the sequence
number of a received packet to measure statistics. The statistics is measured for each QCI.
The eNB counts only downlink packets and the uplink packets are measured by the SGW.
This is for GTP, but the same function is applied even for X2 connection
Benefits
Operator can decide the quality of backhaul network.
Release History
SLR2.2

Dependency
 This feature can be enabled with Samsung SGW only.
Limitation
 eNB counts downlink packets only. Uplink packets are counted at SGW.
Reference
3GPP TS36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Feature Scope
The R1. eNB transmits an uplink GTP packet after marking a sequence number to help the
SGW count lost packets.
The R2. eNB counts lost packets and out-of-sequence packets for the packets received from

Feature Description
the SGW.
Feature Description
The eNB collects the statistics for the number of lost packets and also for the number of
Out of Sequence packets for downlink user packets in the GTP layer. For the objective, the
eNB and SGW adds a sequence number for each GTP packet to transmit. The eNB and
SGW checks the sequence number for a received packet. If a packet with the specific
sequence number is not received, it is judged as a lost packet. If there is a packet whose
order is changed based on the sequence number, the out-of-sequence packet count is
increased. Each statistics must be collected per QCI to judge the effect of applying QoS in
the backhaul network. The statistics collection interval is 2 s.

Feature Description
System operation
N/A

Related counters are as follows.
Item Type Description
GtpSnPeakLos Integer Count of downlink GTP packets which have been regarded to
sQci Range:0~2147 be lost until the statistics collection time.
483647 eNB counts the number of packets lost during the
Measured per measurement period.
QCI
GtpSnOosQci Integer Count of Out of Sequence downlink packets for each QCI.
Range:0~2147 That is, the accumulated count of the packets whose GTP
483647 sequence numbers were changed for each QCI.
Measured per eNB counts the number of packets whose sequence numbers
QCI were changed during the measurement period.
GtpSnPeakLos Integer Count of downlink GTP packets which have been regarded to
sEnb Range:0~2147 be lost until the statistics collection time.
483647 eNB counts the number of packets lost during the
eNB
GtpSnOosEnb Integer Count of Out of Sequence downlink packets for each QCI.
Range:0~2147 That is, the accumulated count of the packets whose GTP
483647 sequence numbers were changed.
Measured per eNB counts the number of packets whose sequence numbers
eNB were changed during the measurement period.
GtpDlCntEnb Integer Count of downlink GTP packets received until the statistics
Range:0~2147 collection time.
483647 eNB counts the number of packets received during the
eNB
GtpSnLossEnb Integer Ratio of the lost packets to the total number of downlink GTP
Rate Range: 0~100 packets received until the statistics collection time.
(%) * loss packet = GtpSnPeakLossEnb
Measured per * total packet = GtpDlCntEnb + (GtpDlCntEnb -
eNB GtpSnOosEnb) GtpSnPeakLossEnb/(sum (GtpDlCntEnb +
GtpSnPeakLossEnb-GtpSnOosEnb) * 100

Feature Description
(Continued)
GtpSnOosEnb Integer Ratio of the Out of Sequence packets to the total number of
Rate Range: 0~100 downlink GTP packets received until the statistics collection
(%) time.
Measured per * Out of Sequence Packet = GtpSnOosEnb
eNB * total packet = GtpDlCntEnb + (GtpSnPeakLossEnb -
GtpSnOosEnb) GtpSnOosEnb/(GtpDlCntEnb +
GtpSnPeakLossEnb-GtpSnOosEnb) * 100
Related Alarms and Status

N/A
Related Call Faults

N/A

Feature Description
LTE-SO0101, Self Establishment

Overview
When eNB is powered on after physically installed, the following self establishment
procedures occur: self test (H/W test), VLAN scanning, automatic IPs acquisition,
Certificate Enrollment, IPsec tunnel establishment, eNB authentication and registration,
S/W download, configuration data download, S1/X2 SCTP setup, RRH configuration &
RRH delay calibration, inventory report, self-test report and eNB gets into service mode.
Introduction
1) Self Establishment is to automate eNB commissioning procedure and minimize the
on-site manual operation.
2) To implement Self Establishment, the following procedures need to be implemented.
Automatic H/W test
Automatic Transport configuration (VLAN, IPs) through DHCP server
Certificate Enrollment through CMPv2
IPsec tunnel establishment with Security Gateway
Planned Transport Configuration download from EMS
Benefits
 Self-establishment of eNodeBs will reduce the amount of manual processes involved
in the initial radio parameter auto-configuration such as PCI/RSI/NR, integration and
configuration of new eNodeBs.
 This will result in a faster network deployment and reduced costs for the operator in
addition to a more integral inventory management system that is less prone to human
error.
Release History
SLR2.2

Dependency
 DHCP server
 Security Gateway
 PKI (CA/RA) server
Limitation
 N/A

Feature Description
References
N/A
Feature Scope
1) The LTE eNB provides configuration for applying Self Configuration and Backhaul
Security functions.
2) The LTE eNB should be able to read the unique key value (serial number) of the main
card.
3) The LTE eNB provides the H/W Test (POST: Power On Self Test) function after power
on.
4) The LTE eNB can have the eNB ID entered for its use. The following two input
methods are supported.
 Manual input
 Input through the bar code reader (DT requirement)
5) The LTE eNB acquires the VLAN information from VLAN scanning.
6) The LTE eNB should be able to receive the eNB IP, EMS IP, Security Gateway IP,
CA/RA IP/Port/Distinguished Name from the DHCP server.
7) The LTE eNB provides the certificate enrollment function using the CA/RA server and
CMPv2 (Certificate Management Protocol ver.2).
8) The LTE eNB provides the Security Gateway and Temporary IPsec tunnel
configuration functions.
 Performs Certificate based authentication.
 Uses the Endpoint-to-Gateway mode (Client-to-Server mode). Receives the Inner IP
from the Security Gateway and uses it for communication with the EMS.
9) The LTE eNB acquires the SW image and Configuration (PLD) online from the EMS
and performs automatic configuration.
 The LTE eNB provides the IPsec tunnel configuration function using the planned
VLAN/IP information included in the configuration received from the EMS.
a) Performs Certificate based authentication.
b) Configures the IPsec tunnel following the method set in the planned VLAN/IP.

Feature Description
Feature Description
When installing the LTE system, the Self Establishment (SE) function allows the eNB to
perform initialization automatically to provide convenience for operation of the LTE
system. This function is turned on by default.
The eNB supports configuration for applying the Self Configuration (SC) and Backhaul
Security (BS) functions during the automatic initial configuration. The following options
are provided.
 SC enable, BS enable (Option 1): Default
 SC enable, BS disable (Option 2)
 SC disable, BS disable (Option 3)

Feature Description
1. Apply IPsec, Apply Self Configuration: SC enable, BS enable (Option 1)

The SE function is performed through the following processes.
Below figure is eNB Self Establishment Process-Apply IPsec, Apply Self Configuration.
1) The eNB hardware installation is performed.

2) After power on, the eNB hardware test (Power On Self-Test) is performed.
3) When the hardware test is complete, the initial configuration parameter is entered.
Initial input parameter: eNB ID (In the case of DTAG: SiteID)
The eNB ID is given by the provider; in the case of DTAG, the information is input
from a bar code reader.

Feature Description
4) Determines Self-Configuration and Backhaul Security policy.

SC enable: Automatic configuration (DHCP enable) BS enable: Apply IPsec
5) Acquires the VLAN information to be used by the eNB through VLAN scanning.
6) Performs eNB/EMS/CA/RA/Security Gateway IP address acquisition procedures.
The eNB obtains its eNB IP address and EMS IP address from the DHCP server.
The IP address of the eNB is given as a response to the DHCP request, and other IP
addresses are given by the option field (Option 43) of the DHCP response message.
The VLAN scanning and IP acquisition processes are as follows.
7) The eNB requests an issuance of the operator signed certificate via CMPv2.
The eNB has the vendor signed certificate when coming out of the factory, and uses it
to request an issuance of the operator signed certificate. For details concerning CMPv2,
refer to COM-SE0602.
8) The eNB connects the security gateway with the IPsec tunnel.
9) The eNB sends the authentication request message to the LSM.
(Information included in the authentication request message: RAT Type, eNB ID, eNB
S/N)
10) The LSM saves the eNB IP address of the eNB’s authentication message and sends the
authentication response message to the eNB.
11) The eNB checks the S/W related information included in the authentication response
message and downloads the S/W list.
12) The eNB downloads and installs the S/W image and configuration data (PLD) file from
the LSM. At this point, the planned VLAN/IP information to be used by the eNB in the
subsequent procedures is included in the PLD being downloaded, and this information
is applied immediately.
13) The eNB sends the cold start message to the LSM after loading software. The eNB ID
and S/W version information is included in the message.
14) Performs rebooting.
 Steps 5, 6, 7 and 8 are skipped after rebooting.
15) The eNB performs the transport configuration using the planned VLAN/IP and
connects the security gateway with the permanent IPsec.
 Then performs steps 9, 10, 11, 12 and 13 again.
16) IPsec tunnel connection is made based on the configuration received from the PLD.
And it uses information such as number of tunnels, connection mode and IP to be used.
17) The eNB performs the S1 setup with the MME.
18) The eNB performs the X2 setup with neighbor eNBs.
19) The eNB reports the Self-Test result to the LSM.
 POST Result
 S1/X2 Setup status
 Inventory Information report
 eNB status (Cell Operation State) report
20) After receiving the Initialization Complete message, the LSM allows the operator to
manage the eNB of the EMS.

Feature Description
2. IPsec not applied, Self Configuration applied: SC enable, BS disable (Option 2)
The SE function is performed through the following processes.

Below figure is eNB Self Establishment Procedure-IPsec not applied, Self Configuration
applied

Feature Description
1) The eNB hardware installation is performed.

2) After power on, the eNB hardware test (Power On Self-Test) is performed.
3) When the hardware test is complete, enter the initial configuration parameter.
Initial input parameter: eNB ID (In the case of DTAG: SiteID)
The eNB ID is given by the provider; in the case of DTAG, the information is input
from a bar code reader.
4) Determines Self-Configuration and Backhaul Security policy.
 SC enable: Automatic configuration (DHCP enable)
BS disable: IPsec not applied
5) Acquires VLAN information to be used by the eNB from VLAN scanning.
 For the VLAN scanning procedure, refer to upper figure.
6) The eNB and LSM IP addresses are obtained.
The eNB obtains its eNB IP address and LSM IP address from the DHCP server.
The eNB IP address and LSM IP address are obtained through the DHCP service.
The IP address of the eNB is given as a response to the DHCP request, and the LSM IP
addresses is given by the option field (Option 43) of the DHCP response message.
7) The eNB sends the authentication request message to the LSM. Information included
in the authentication request message: RAT Type, eNB ID, eNB S/N)
8) The LSM saves the eNB IP address of the eNB’s authentication message and sends the
authentication response message to the eNB.
9) The eNB checks the S/W related information included in the authentication response
message and downloads the S/W list.
10) The eNB downloads and installs the software and configuration data file from the LSM.
11) The eNB sends the cold start message to the LSM after loading software. The eNB ID
and S/W version information are included in the message.
12) The eNB performs the S1 setup with the MME.
13) The eNB performs the X2 setup with neighbor eNBs.
14) The eNB reports the Self-Test result to the LSM.
 POST Result
 S1/X2 Setup status
 Inventory Information report
 eNB status (Cell Operation State) report
15) After receiving the Initialization Complete message, the LSM allows the operator to
manage the eNB of the EMS.

Feature Description
System Operation
Commands Parameters Description
CHG-SONFN- ANR_ENABLE Controls SON ANR in 3 modes

CELL - sonFuncOff: The ANR function is disabled
except for the NR deletion (X2 based)
- sonManualApply: The NR adding and NR
ranking are performed automatically.
The management of HO Black List and NR
detion are performed manually.
- sonAutoApply: The NR adding and NR ranking,
managing HO Black List, NR deleting, and NR
adding are performed automatically.
CHG-SON-ANR MAX_NRTSIZE Maximum size of NRT per cell
DEFAULT_WEIGHT Newly added NBR has a default weighting value
during specific duration.
DEFAULT_PERIOD Newly added NBR has a default weighting value
during specific duration.
HO_ATTEMPT_WEIGHT Weighting value of handover attempt rate.
HO_SUCCESS_WEIGHT Weighting value of handover success rate.
LOWER_HO_ATTEMPT_ Threshold of handover attempt rate and handover
RATE success rate. If a NBR has a statistics value
lower than these two thresholds, ANR function
includes the NBR into handover blacklist.
LOWER_HO_SUCCSS_ Threshold of handover attempt rate and handover
TO_KPI success rate. If a NBR has a statistics value
lower than these two thresholds, ANR function
includes the NBR into handover blacklist.
RTRV-SONFN- ANR_ENABLE Retrieves the flag for SON ANR by the cell.
CELL
RTRV-SON- - Retrieves the configuration parameter information
ANR of ANR functions.
RTRV-RRH- - It is normal if OPERATIONAL_STATE is enable,
STS FA0_ON_OFF is ON and TX/RX_ON_OFF is ON.
RTRV-CELL- - It is normal if interoperating with RRH is normal
STS and the OPERATIONAL_STATE of the cell is
enable.
RTRV-ALM- - It is normal if no unusual alarms occur.
LIST
RTRV-ACT-SW - It is normal if DEACT_COUNT = 0 after the
execution of the command.

Feature Description

N/A
Related Status and Alarm

It is normal if the eNB follows normal loading procedures and no unusual alarms occur.
Related Call Faults

N/A

Feature Description
LTE-SO0201, Intra-LTE ANR

Overview
The Samsung ANR configures and manages the intra-LTE NRT to guarantee stable UE
mobility in the LTE system. The Samsung ANR fully meets the requirements of the 3GPP
LTE standard. At the self-configuration stage, it provides the initial NRT creation function
based on the location information of active cells during the eNB or cell grow. At the self-
optimization stage, it provides the periodic NRT management function, the automatic NR
addition function and the automatic X2 interface configuration function triggered by a
moving UE during the system operation.
Introduction
The Samsung ANR automatically configures and manages the intra-LTE NRT, and it aims
to maintain the optimal NRT reflecting changes in the communication environment during
the system operation. Stable UE mobility of Samsung LTE cells is guaranteed by optimized
NRT management. They are classified as follows according to the UE’s connection status.
1) RRC_CONNECTED: Guarantees stable intra-LTE HO of the UE while connected to

the cell.
2) RRC_IDLE: Guarantees stable execution of cell selection/reselection of the UE while
the cell is disconnected.
The Samsung ANR provides the following functions depending on the SON phase.
1) Self-configuration phase

Configures an initial neighbor cell through O & M: Create an initial NRT by using
the location information of active cells during the eNB or cell grow in the LSM.
2) Self-optimization phase
 Finds and adds new neighbor cells during HO execution due to UE mobility.
(1) Adds new neighbor cells to the NRT based on the UE or LSM.
(2) Establishes bi-directional NR relations by adding the serving cell to the NRT
of a new neighbor cell with the help of the LSM.
(3) Configures the X2 interface automatically between a serving cell and a new
neighbor cell.
 Periodic NRT management
(1) Calculates NR priorityPeriodic NRT management (ranking): The HO statistics
(HO attempts and successes) is used
(2) Maintains NRT size: Deletes a NR using the NR priority when the NRT size
exceeds a specific threshold value
(3) Registers and restores the HO blacklist.
HO blacklist: A set of neighbor cells (HO black cells) where HO operation is
prohibited
Registration of a HO blacklis:Finds the cells with low HO quality statistics
among HO available cells, and registers the cells in the HO blacklist

Feature Description
Restoration from the HO blacklist: Finds the cells with high HO-to-Black-
Cell statistics among HO black cells, and restores the cells as a HO
available cell
Benefits
Samsung ANR provides the following advantages.
1) Operator aspects: The operator can reduce previously spent CAPEX and OPEX cost
for configuring and managing the NRT of the LTE cells.
2) End user aspects: System performance indicators such as HO success rate and call
drop rate are optimized by configuring an NRT optimized for coverage and air status
of each LTE cell through guarantee of stable mobility of UEs in the RRC_ILDE mode
and the RRC_CONNECTED mode.
Release History
SLR2.2
Basic or Optional
Optional Feature: The ANR operation mode can be set to automatic, manual, or deactivate.

There are the following dependencies and limitations in the Samsung ANR function.
1) Dependency

Support of the ECGI acquisition function of the UE: For UE-based NR addition, the
UE must support the ECGI acquisition function.
 Support of the LSM-based NR addition function: The operator must set the LSM-
based NR addition flag to true.
2) Limitation
Bi-directional NR addition: Available only when the newly added neighbor cell
belongs to the same LSM as the serving cell (Bi-directional NR cannot be established
for a neighbor cell that belongs to a different LSM or vendor).
Reference
1) 3GPP 36.300: E-UTRA and E-UTRAN; overall description Stage 2 (Release 9)
2) 3GPP 36.331: E-UTRAN; Radio Resource Control (RRC); Protocol specification
(Release 9)
3) 3GPP 36.902: E-UTRAN; Self-configuring and self-optimizing network (SON) use
cases and solutions
4) 3GPP 32.500: E-UTRAN; Concepts & Requirements
5) 3GPP 32.501: E-UTRAN; Self-configuration of network elements; OAM
Requirements for Self Configuration Use Cases

Feature Description
Feature Scope
The feature scope of the Samsung ANR functions is as follows.
1) The Samsung ANR allows the operator to set the ANR operation mode to automatic/
manual/deactivate through the LSM.
2) The Samsung ANR allows the operator to create an initial NRT through the LSM
during eNB or cell grow.
3) The Samsung ANR provides a function that detects new neighbor cells and adds them
to the NRT based on the measurement report message caused by the HO triggering of
the UE.
4) The Samsung ANR supports the ECGI acquisition function of the UE and provides a
function that acquires the ECGI information of the new neighbor cell detected by the
UE if the serving cell is currently using DRX.
5) The Samsung ANR provides a function that acquires the ECGI and X2 TNL address
information of the new neighbor cell, detected by the UE, through the LSM.
6) The Samsung ANR provides a function that acquires the X2 TNL address, required for
establishing the X2 interface with the neighbor cell newly added to the NRT, from the
MME by using the S1 eNB/MME configuration transfer message.
7) The Samsung ANR provides a function that changes the following NR attributes set by
the operator.
Application of the HO blacklist settings
Application of the X2 whitelist/blacklist settings
8) The Samsung ANR provides a function that determines the NR priority based on the
HO operation history and KPI information for each NR that exists in the NRT
periodically.
9) The Samsung ANR provides a function that deletes NRs to adjust the NRT size to the
threshold value based on the NR priority calculated at the time if the NRT size is
bigger than a specified threshold value at the point of NR priority calculation.
10) The Samsung ANR provides a function that performs addition to the Handover Black
List (HO BL).
Registration of a HO blacklist: Finds the NRs with low HO quality statistics
among HO available cells existing in the NRT at the point of NR priority
calculation, and registers the NRs in the HO blacklist.
Restoration from the HO blacklist: Finds NRs with high RRC connection
reestablishment occurrence statistics among HO black cells at the point of NR
priority calculation, setting them as HO available cells.

Feature Description
Feature Description
Architecture
The Samsung ANR function operates in the eNB and LSM. The overall architecture is
shown in the below.
In the above architecture, the Samsung ANR function is performed in the SON agent of the
eNB and the SON manager of the LSM. Each entity provides the following operations.
1) LSM
 SON Manager: NRT Management Function
Create initial NRT
Operate ANR based on the LSM
Establish bi-directional NR relationship based on the LSM
2) eNB
 SON Agent: NR Detection Function
Reception of a measurement report message from the call processor
Acquire the ECGI and the X2 TNL address from the call processor
 SON Agent: NR Add Function
Add NR using the ECGI and the X2 TNL address

Feature Description
 SON Agent: NR Removal Function

Receive the NR removal information from the call processor and delete NRs
Delete NRs to maintain the NRT below a certain size
 SON Agent: NR Ranking Function
Calculate the NR priority using the HO statistics
 SON Agent: NRT Management Function
Decide whether to perform NR addition/retrieval/attribute value update/deletion
LSM SON Manager: Synchronize between the NRT management function and
the NRT
Management of the HO blacklist
Intra-LTE ANR Function

Self-Configuration phase-Initial NRT auto configuration
The operator can create an initial NRT using the location information of the cells
previously entered at the time of SW download into the cells by checking the initial NRT
creation in the SON option box in the eNB or cell grow window provided by the Samsung
LSM. The operator can set parameters related to the initial NRT creation in the SON
property window provided by the Samsung LSM.
1) NRT.type: Decides the initial NRT creation method

2) NRT.multiple: A multiple to multiply R counts (used in initial NRT creation) and an
average distance to the cells
3) NRT.limitDistance: The maximum distance to the neighbor cell that can be included in
the initial NRT
The Samsung LSM provides the following methods to create an initial NRT.
1) NRT.type = average
(1) Creation method: Includes neighbor cells up to NRT.size in the NRT within the
radius of max{NRT Multiple × Ravg, NRT.limitDistance}
Ravg: The average distance of R Count of cells within the NRT.limitDistance.
R Count: The number of cells to be used for Ravg calculation
(2) NRT.size: The number of the initial NRT configurations
2) NRT.type = distance
Creation method: Includes NRT.size neighbor cells within the radius of
NRT.limitDistance in the NRT.
3) NRT Type = minimum
Creation method: Creates an initial NRT in the same way as NRT.type = average, but
the distance to the closest cell among cells existing within NRT.limitDistance is used
instead of Ravg.

Feature Description
Self-Optimization phase-Automatic NRT management in operational state

At the self-optimization stage, the Samsung ANR provides the following functions.
1) Finds and adds new neighbor cells during HO execution due to UE mobility.
A) Add the UE-based NR
B) Add the LSM-based NR
2) Periodic NRT management
A) Calculates NR priority (ranking):The HO statistics (HO attempts and successes)
is used
B) Maintains NRT size:Deletes a NR using the NR priority when the NRT size
exceeds a specific threshold value
C) Registers and restores the HO blacklist.
Finds and adds new neighbor cells during HO execution due to UE mobility.
The NR addition operation of the Samsung ANR is triggered by an event that occurs when
a new neighbor cell is detected during the HO operation due to UE mobility. Later the cell
can be added to the NRT by carrying out the UE-based NR addition if the ECGI can be
acquired from the UE, or by performing the LSM-based NR addition if not. The ECGI can
be acquired from the UE only if the UE is not currently using the GBR service, the UE
feature supports the ECGI acquisition function, and the serving cell is currently operating
DRX.
1) The following shows UE-based NR addition procedures.

The UE performs measurement according to the measurement configuration
transmitted by the serving cell.
The UE transmits the measurement report message to the serving cell.
The serving cell detects the PCI (Unknown PCI) of the new cell that does not
exist in its own NRT, then it transmits the reportCGI configuration requesting the
UE to acquire the ECGI.
The UE reads the ECGI of the new cell corresponding to the Unknown PCI in the
DRX section.
The UE transmits the measurement report message including the acquired ECGI
to the serving cell.
The serving eNB acquires the IP address (X2 TNL address) of the new eNB from
the MME.
The serving cell adds the new cell to its NRT.
The serving eNB reports to the LSM that the new cell added to its NRT.
The LSM adds the serving cell to the new cell’s NRT (Bi-directional NR adding).
The serving eNB and new eNB establish X2 connection.

Feature Description
Below figure is UE-based NR addition procedure.
2) The LSM-based NR addition procedures are as follows, as shown in the image below.
The UE performs measurement according to the measurement configuration
transmitted by the serving cell.
The UE transmits the measurement report message to the serving cell.
The serving cell detects the PCI (Unknown PCI) of the new cell that does not
exist in its own NRT and reports to the LSM that the Unknown PCI is detected
because the ECGI could not be acquired from the UE.
The LSM finds the closest cell that corresponds to the serving eNB, and then adds
the new cell to the serving cell’s NRT.
The LSM adds the serving cell to the new cell’s NRT (Bi-directional NR adding).
The serving eNB and new eNB establish X2 connection.

Feature Description
Below figure is LSM-based NR addition procedure.
Periodic NRT management

The following shows periodic NRT management procedures performed by the Samsung
ANR are as follows, as shown in the image below.
1) The serving cell collects the HO statistics data on neighbor cells included in the NRT.
2) When the serving cell reaches a point of calculating the NR priority, it calculates the
priority of the NRs included in the NRT/low HO quality/RRC connection
reestablishment occurrence rate by using the collected statistics data.
3) The serving cell deletes NRs by using the NR priority to ensure that the NRT size
meets a specific threshold value.
4) The serving cell finds the cells with low HO quality statistics among HO available
cells, and registers the cells in the HO blacklist.
5) The serving cell finds the cells with high HO-to-Black-Cell statistics among HO black
cells, and restores the cells as HO available cells.

Feature Description
Below figure is Periodical NRT management procedure.
1) Calculates NR priority (ranking):

The NR priority means the level of validity or importance of the NR included in the
intra-LTE NRT. Calculation of the NR priority is performed at a specified interval (e.g.
1 day). When the Samsung ANR reaches a point of calculating the NR priority, it
calculates the rank value to determine the priority, as shown below.
Rank (i ) = W1 ⋅ HOAttemptRatio(i ) + W2 ⋅ HOSuccessRatio(i ) + W3 (1)
The HOAttemptRatio(i) and HOSuccessRatio(i) for the NR i included in the NRT are
calculated as follows.
NumberHOAttempt (i )
HOAttemptRatio(i ) = N
,
∑ NumberHOAttempt ( j )
j =1
NumberHOSuccess(i )
HOSuccessRatio(i ) =
NumberHOAttempt (i ) (2)
W1 and W2 used in the formula (1) represent the weight factors for
HOAttemptRatio(i) and HOSuccessRatio(i) respectively. W3 is the weight factor for
the NR newly added to the NRT and prevents incorrect priority due to insufficient HO
statistics for the cell.

Feature Description
2) NRT size management

The Samsung ANR function ensures that NRs of up to the hard limit of the Samsung
eNB can be included in the NRT, and performs periodic NRT size management.
The periodic NRT size management procedures are as follows.
Calculates the number of NRs in the NRT when it reaches to the point of
calculating the NR priority.
If there are more NRs than the specified threshold value, it starts to delete NRs
with the lowest priority based on the priority calculated at the time.
The threshold that controls the NRT size can have a value between 1 and 256, which
can be set by the operator.
3) Registers and restores the HO blacklist.

When it reaches a point of calculating the NR priority, the Samsung ANR checks
whether the NR shows low HO quality statistics through the following conditions by
using the HO statistics on the NRi included in the NRT.
NumberHOAttempt > Th1 & HOAttemptRatio(i ) < Th2 &

HOSuccessRatio(i ) < α ⋅ HOSuccessKPI (3)
Th1, Th2 and Alpha used in the formula (3) are used for the following purposes.
Th1: The threshold in which the number of HO attempts to NRi meets the low HO
quality condition
Th2: The threshold in which the rate of HO attempts to NRi meets the low HO
quality condition
Alpha: The weight factor for the HO success rate KPI determined by the operator
where the HO success rate to NRi meets the low HO quality condition
The NR i that meets all of the above conditions is registered with the HO blacklist at
the point of the NR priority.
When it reaches to the point of calculating the NR priority, the Samsung ANR function
finds NRjs with HO-to-Black-Cell statistics exceeding a specified threshold value among
HO black cells, and restores them as HO available cells. The HO-to-Black-Cell statistics
used in these restoration conditions is collected in the serving cell if the following
situations occur.
 HO triggering to NRj is caused by the UE mobility
 The serving cell prevents the HO operation because NR j is registered with the HO
blacklist.
 The UE generates RLF in a short period of time after the HO operation to another NR
succeeds or fails.

Feature Description
 The UE performs reestablishment of the RRC connection to NR j.
If the above situations occur frequently, the HO to NR j becomes valid and is restored as an
HO available cell. The serving cell can collect the HO-to-Black-Cell statistics to NR j by
using RLF INDICATION and HANDOVER REPORT messages included in the X2
interface to provide the MRO function, one of the SON use-cases.

Feature Description
System operation
The operator can set the operation mode of the Samsung ANR function to automatic/
manual/deactivate or retrieve the mode through the following commands and parameters.
CHG-SONFN-CELL ANR_ENABLE; Command that changes the operation mode of

(Range = [0, 2], Init = 0) ANR function, controlled by cell.
1) sonFuncOff (= 0): All ANR functions are
disabled except the NR deletion triggered
by X2.
2) sonManualApply (= 1): Registering to HO
blacklist and ranking-based NR deletion is
performed if operator confirms these
operations. Other ANR functions such as
NR adding and NR ranking are performed
automatically.
The NR adding and NR ranking are
performed automatically.
3) sonAutoApply (= 2): All ANR functions such
as NR adding, NR ranking, managing HO
Black List, NR deleting are performed
automatically.
RTRV-SONFN-CELL - Command that retrieves the operation mode of
ANR function, controlled by cell.

Feature Description
The operator can control the operations of the Samsung ANR functions with the following
commands and parameters.
CHG-SON- MAX_NRTSIZE, Command that changes the parameter

ANR LSM_USAGE_FLAG, values used to ANR function.
DEFAULT_WEIGHT,
DEFAULT_PERIOD,
HO_ATTEMPT_WEIGHT,
HO_SUCCESS_WEIGHT,
LOWER_HO_ATTEMPT_RATE,
LOWER_HO_SUCCESS_TO_KPI,
UPPER_HO_TO_BLACK_RATE;
MAX_NRTSIZE The maximum size of Neighbor Relation
(Range = [1, 256]. Init = 256) Table (NRT) per cell
LSM_USAGE_FLAG The flag is used to decide whether the
(Range = [0, 1]. Init = 1) LSM-based ANR function is adopted or
not, in the operational state.
1) FALSE (0): LSM-based ANR function
is not adopted in the operational state.
2) TRUE (1): LSM-based ANR function is
adopted in the operational state.
DEFAULT_WEIGHT The default weight for a new NR.
(Range = [0.000, 1.000], Init = 0.5) A neighbor cell newly added has a
disadvantage in both of the handover
attempt rate and the handover success
rate, when determining its ranking.
Therefore, the default weight specified by
this parameter value is given to the newly
added neighbor cell during the specified
period of time. (DEFAULT_PERIOD).
DEFAULT_PERIOD A period of time for which the default
(Range = [1, 30], Init = 30) weight (DEFAULT_WEIGHT) is applied to
a new NR, in a unit of day.
HO_ATTEMPT_WEIGHT The weight given to a handover attempt
(Range = [0.000, 1.000], Init = 1.0) rate when calculating the NR ranking.
HO_SUCCESS_WEIGHT The weight given to the handover success
(Range = [0.000, 1.000], Init = 1.0) rate when calculating the NR ranking.
LOWER_HO_ATTEMPT_RATE The threshold of handover attempt rate of
(Range = [0.000, 1.000], Init = 0.001) NR, used to the condition of low handover
quality.
LOWER_HO_SUCCESS_TO_KPI The weight factor to handover success
(Range = [0.000, 1.000], Init = 0.5) KPI, used to the condition of low handover
quality.

Feature Description
(Continued)
CHG-SON-ANR UPPER_HO_TO_BLACK_RATE The threshold of the HO-to-Black

(Range = [0.000, 1.000], Init = 0.1) Cell occurrence rate of NR, used to
the condition of restoration from
handover blacklist.
RTRV-SON-ANR - Command that retrieves the
parameter values used to ANR
function.
Related Counters
The Samsung ANR function uses the following statistics information.
Counter Description How to check
IntraEnbPrepSucc The number of Intra-eNB handover Operator can check this with PM
preparation success to intra-eNB statistics in the LSM
neighbor cell
IntraEnbSucc The number of Intra-eNB handover Operator can check this with PM
execution success to intra-eNB statistics in the LSM
neighbor cell
InterX2OutPrepSucc The number of X2 HO preparation Operator can check this with PM
success to inter-eNB neighbor cell statistics in the LSM
InterX2OutSucc The number of X2 HO execution Operator can check this with PM
InterS1OutPrepSucc The number of S1 HO preparation Operator can check this with PM
InterS1OutSucc The number of S1 HO execution Operator can check this with PM

Feature Description
Related KPI/PI
KPIs related to the Samsung ANR function are as follows:
KPI Description How to check
EutranMobilityHOIntra Intra-eNB handover success rate of E- Operator can check this

UTRAN mobility with PM statistics in the
LSM
EutranMobilityHOX2Out X2 handover success rate of E-UTRAN Operator can check this
mobility with PM statistics in the
LSM
EutranMobilityHOS1Out S1 handover success rate of E-UTRAN Operator can check this
mobility with PM statistics in the
LSM
CallDropRatio Call drop rate Operator can check this
with PM statistics in the
LSM
Related Status and Alarms
Alarm Monitoring Condition

Importance
name device Generation Condition Restoration condition
PCI_ Major UMP - Collision: A problem The PCI collision/

CONFLICT occurs because the confusion problem are
cell’s PCI coincides with resolved.
the neighbor cell’s PCI.
- Confusion: A PCI
confusion problem
occurs because the
cell’s PCI coincides with
the neighbor to neighbor
cell’s PCI.

Feature Description
Related Call Faults
Call Release Cause Description
C_ECCB_TMOUT_intra_Handover The target cell cannot receive the RRC Connection

CmdComplete Reconfiguration Complete message during the intra-HO.
C_X2AP_CauseMisc_unspecified The call is released after the target eNB receives a
handover cancel message from the source eNB.
C_X2AP_no_radio_resources_ The Sin receives the handover preparation failure message
available_in_target_cell because the Ten cannot check the targetCellID included in
the handover request message as it is not a cell under the
target eNB.

Feature Description
LTE-SO0301, PCI Optimization

Overview
The Samsung PCI optimization provides functions such as auto PCI configuration for
initial PCI allocation during network installation, PCI collision, confusion detection and
auto PCI optimization for PCI reallocation.
Introduction
There are 504 PCIs in the LTE system. PCIs consist of the formula (1) using 168 unique
physical layer cell identity groups, and 3 physical layer identities within the physical
layer cell identity group, .
(1)
PCIs are used in synchronization and reference signal generation, which are involved in
cell selection, handover and channel estimation procedures. And PCIs are also used in
fields where cell specific randomness is required in physical channel scrambling of the DL
and UL, resource element mapping, cyclic shift and hopping.
PCI collision occurs when the same PCIs are used in the overlapping coverage area of two
cells. The UE existing on the border of two cells with the same PCI cannot perform
handover because it cannot distinguish between the serving cell and the neighbor cell.
PCI confusion occurs when neighbor cell uses the same PCI. PCI confusion causes
handover ambiguity because in the eNB, the cell which received a handover request cannot
find out which is the target cell. If the neighbor cells use the same PCI, the network system
is affected in many aspects. Therefore, the PCI allocation should be performed in a way to
avoid such problem.
The Samsung PCI optimization exists in each eNB and EMS. In the eNB, it performs
functions such as PCI collision and confusion monitoring and detection by using the NRT,
and PCI allocation and reallocation functions are carried out in the EMS.
The configuration function of the Samsung PCI optimization automatically determines the
PCI of the newly installed or grown cell. It sets the reference distance based on the location
of the installed cell to minimize the PCI reuse within the reference distance.
The optimization function automatically detects PCI collision and confusion, and performs
PCI reallocation by selecting the cell that needs PCI reallocation among the detected cells.
PCI reallocation can be performed in either a location based or an Neighbor Relation Table
(NRT) based method. In the location based method, the reallocation PCI is selected based
on the distance between the cell that needs PCI reallocation and the other cells. In the NRT
based method, the reallocation PCI is selected by referring to the NRT and the NRT’s NRT.

Feature Description
Benefits
The operator and the user can expect the following benefits from the Samsung PCI
optimization.
 Operator
With the Samsung PCI optimization, the operator can reduce CAPEX/OPEX required
for network installation and expansion.
 User
The Samsung PCI optimization guarantees the end users have improved mobility
between cells.
Release History
SLR2.2

Dependency
 Application of the PCI optimization requires location information of the cell where the
PCI allocation is required.
Limitation
 The location based PCI reallocation method of the PCI optimization might cause a PCI
collision and confusion with a cell that does not use the same EMS.
 The NRT based PCI reallocation method of the PCI optimization might cause a PCI
reconfiguration failure if there is no X2 interface between cells when the PCI collision
or confusion occurs in a cell in the inter EMS.
References
(Release 9)
cases and solutions
6) 3GPP 32.521: E-UTRAN; Self-Organizing Networks (SON) Policy Network Resource
Model (NRM) Integration Reference Point (IRP); Requirements
Model (NRM) Integration Reference Point (IRP); Information Service (IS)
8) 3GPP 32.541: E-UTRAN; OAM Requirements for Self Healing Use Cases

Feature Description
Feature Scope
The feature scope of the Samsung PCI functions is as follows.
1) The eNB of the Samsung PCI optimization provides a function that disables/enables
automatic configuration of the physical cell ID according to directions from the EMS.
2) The eNB of the Samsung PCI optimization detects and reports to the EMS inter-cell
physical cell ID collision or confusion.
 PCI collision/confusion information exchange via X2 detection
(X2_SETUP_REQUEST/RESPONSE, X2_ENB_CONFIGURATION_UPDATE)
 PCI collision/confusion report function

Feature Description
Feature Description
Architecture
The Samsung PCI optimization operates in the eNB’s SON agent and EMS’s SON manager.
The overall structure is as follows.
Below figure is PCI optimization architecture.

Feature Description
Operations of each entity are as follows:.
1) eNB: SON Agent

 PCI Management Function
Transmits a notify information message to the EMS and stores it in the DB when
PCI collision/confusion is determined.
 PCI collision/confusion Detection Function
: Detects PCI collision/confusion using the X2_SETUP_REQUEST and
eNB_CONFIGURATION_UPDATE messages received from the call processor.
: Detects a PCI collision/confusion using the ECGI information received from the
neighbor detection function.
2) EMS: SON Manager
 PCI Management Function
: Performs a PCI reallocation upon receiving the PCI collision/confusion notify
information message.
: PCI reallocation cell selection
: Transmits a new PCI to the eNB of the cell whose PCI has been changed.
PCI configuration
The PCI configuration function is performed in the EMS. It aims to allocate PCIs based on
the distance between cells to avoid PCI collision/confusion. Selects the reference distance
from the cells that allocates PCI, and then allocates PCIs, assuring that all cells belonging
to the same EMS within the reference distance avoid PCI collision/confusion.
The following picture shows a brief overview of the PCI configuration.
Below figure is PCI configuration.

Feature Description
The PCI configuration involves the following operations.
1) The EMS receives latitude/longitude coordinates of the installed cell from the operator
or the GPS during eNB installation.
2) The EMS receives the reference distance from the operator. The following values can
be used as a reference distance.
 Case1: fixed distance
: A certain distance from the PCI allocation cell
 Case2: average cell distance
: Average distance of the cells within 10 km from the PCI allocation cell.
The number of cells, which is needed to calculate the average distance between
cells, and the calculated expansion of the inter-cell distances can be adjusted by the
scaling factor.
3) is allocated first for the PCI allocation cell. For the cell existing at the same
location, make sure is not in neighborhoods with it by using its cell number.
4) Select PCIs other than the ones used by all cells that use the same EMS within the
reference distance from the PCI allocation cell. If the cells within the reference
distance use all allocable PCIs, select PCIs by using the number of PCI reuse and the
distance between cells that use the same PCI.
PCI optimization
The PCI optimization function avoids PCI collision/confusion by making adaptation to the
surrounding wireless environment during the network operation. That is, it automatically
detects PCI collision/confusion and automatically reallocates PCIs that resolve PCI
collision/confusion.
PCI collision/confusion detection

PCI collision refers to a situation where two cells with adjacent coverage use the same FA
and PCI. In this case, handover ambiguity occurs because the UE existing on the border
between the two cells cannot distinguish the serving cell from the neighbor cell.
PCI confusion refers to a situation where two adjacent cells to the coverage and the serving
cell use the same FA and PCI. If the UE transmits a measurement report for handover for a
cell where PCI confusion occurred, the serving cell cannot distinguish which is the target
cell. Also, if the eNB of the serving cell requests for handover preparation for one of the
two cells, the eNB might send to the UE a handover command to a wrong cell, causing
Radio Link Failure (RLF) of the UE. The PCI collision/confusion detection function is
performed in the SON agent of the eNB. In addition to the existing NRT, a 2TierNRT must
be created and operated for PCI confusion detection. The 2TierNRT can be created by
collecting the information about the neighbor cell of the cell that has a neighbor relation
with the serving cell.

Feature Description
The PCI collision/confusion detection function is performed by using the 2TierNRT

operated in each cell; the PCI collision/confusion detection through the 2TierNRT is
performed upon the request by the operator for PCI or neighbor change, or every time a
message is received for cell configuration change of the neighbor cell via the X2 interface.
The PCI collision/confusion detection function is also performed when the neighbor
information changes neighbor information of the cell that belongs to the same SON agent.
When PCI collision/confusion is detected, the SON agent reports to the SON manager of
the EMS on the occurrence of PCI conflict and the 2TierNRT creation.
PCI reallocation
Upon receiving the report of the PCI conflict, the SON manager of the EMS selects the
target cell for PCI reallocation. PCI reallocation procedures are performed once the PCI
reallocation cell is selected. There are two PCI reallocation methods -location-based and
NRT-based-from which the operator can make a selection.
1) Location based PCI reallocation

The location based PCI reallocation method selects the PCI with the largest distance
between the same PCIs during PCI reuse among PCIs with the smallest number of PCI
reuses for cells that exist in the same EMS within a certain distance based on the
distance from neighbor cells.
2) NRT based PCI reallocation
The NRT based PCI reallocation method deletes the PCIs in the 2TierNRT reported by
the SON agent from the pool of available PCIs set by the operator. Randomly selects
PCIs from the set of PCIs remaining after PCI deletion. An available is
considered first so that it coincides with the PCI where PCI conflict occurred.
The EMS notifies the operator of the depletion of PCIs if there is no allocable PCI
after deletion of PCIs in the 2TierNRT from the PCI pool.

Feature Description
SYSTEM OPERATION
1) Whether to use the auto PCI configuration function for the initial PCI allocation during
network installation can be selected in the System Grow window during eNB grow.
2) Auto PCI optimization

Commands Description
RTRV-SONFN-ENB Retrieves the SON function eNB control flag. This command retrieves the
current mode of the SON function controlled for each eNB. Available modes
include three modes of Function Off, Manual Apply, and Auto Apply or two
modes except for Manual Apply.
CHG-SONFN-ENB Changes the SON function eNB control flag. This command is used for
setting the SON function controlled for each eNB to three options of
Function Off, Manual Apply, and Auto Apply or to two options except for
Manual Apply.

Parameter Default Value Description
PCID_ENABLE sonFuncOff Controls SON PCID operation at 3 stages.

- sonFuncOff: Performs X2 monitoring.
- sonManualApply: After initial PCI auto configuration, X2
monitoring and PCI collision/confusion detection are
performed, the PCID in which collision/confusion was
detected can be reallocated manually.
- sonAutoApply: After initial PCI auto configuration, X2
monitoring and PCI collision/confusion detection are
performed, the PCID in which collision/confusion was
detected is reallocated automatically by the EMS SON
manager.
DELAY_COMP sonfAutoApply A function irrelevant to the PCI optimization.
ENSATION Controls the SON delay compensation operation in two steps.
- sonFuncOff: Disables SON delay compensation.
- sonAutoApply: Starts SON delay compensation.

N/A

Feature Description

Status/Notification Description
SON_PCI_CONFLICT The notification occurs when there is PCI conflict.

Collision:
A duplicate PCID exists in the source cell and neighbor cells of the ENB.
Confusion:
1) A duplicate PCID exists in the eNB’s source cell’s neighbor cell and
another neighbor cell.
2) A duplicate PCID exists in the source cell of the ENB and the
neighbor cell’s neighbor cell.
Related Call Faults

N/A

Feature Description
LTE-SO0401, RACH optimization

Overview
Introduction
The SON-RACH Optimization (RO) function allows optimization of the RACH
parameters during system operation. The operator can turn individual RO functions on/off
per cell or eNB.
References
(Release 9)
cases and solutions
4) 3GPP 32.500: E-UTRAN; Self-Organizing Networks (SON); Concepts and
requirements
5) 3GPP 32.501: E-UTRAN; Self-configuration of network elements; Concepts and
requirements
Model (NRM) Integration Reference Point (IRP); Requirements
Model (NRM) Integration Reference Point (IRP); Information Service (IS)
8) 3GPP 32.541: E-UTRAN; Self-Organizing Networks (SON); Self-healing concepts
and requirements
Feature Scope
The features of the RACH optimization function are described below.
R1 The LTE eNB provides the automatic apply/manual apply/off functions of the RACH
optimization according to the command by LSM.
R2 The LTE LMS provides the initial root sequence index auto-configuration function
when a new eNB is added.
R3 The LTE eNB detects the root sequence index collision. Detects the root sequence
index collision through exchanging X2 information (X2 SETUP REQUEST/
RESPONSE, ENB CONFIGURATION UPDATE).
R4 The LTE eNB sets up the high speed flag.
Decides each high speed flag based on the rules determined as a result of provisioning
(highSpeedFlag).
R5 The LTE eNB optimizes the number of RA preambles.
R6 The LTE eNB optimizes PRACH configuration index.
R7 The LTE eNB optimizes RACH power control.
R8 The LTE eNB provides the RACH parameter fallback function.
R9 The LTE eNB reports the RACH abnormality.

Feature Description
Feature Description
RO function
SON supports a collision detection of RSI automatically and re-configures of RSI to avoid
the conflict of RSI with neighboring eNBs. Every single RO-period, SON supports
statistics- based RACH parameter optimization.
Event triggering RO
RO supports the RSI collision check and the RSI re-configuration when needed.
If the RACH information of a neighbor eNB changed, a neighbor eNB sends the changed
information via X2 interface. Then, SON starts the RSI collision check and decides the RSI
collision occurred or not. If collision occurred, SON
Below figure is RSI Collision in Event triggering RO.
Periodic RO
SON supports automatic configuration of PCI and avoids conflict of PCI with neighboring
eNBs.
RO Objectives
 Minimizing UE access delay
 Minimizing interference to PUSCH resource

Feature Description
RACH parameters Optimization

SON optimizes the RACH parameter to satisfy the RO objectives & KPI. SON gathers the
HO log/RACH contention/re-transmission information to calculate Decision Statistics for
KPI. Decision Statistics decides the RACH parameters as follows:
 Consist of preambles: number of contention based/free preambles.
− numberOfRA-preambles
 RACH resource: allocating RACH in a particular subframe
− PRACH configuration Index
 Setting of transmit power: RACH transmit power is a sum of Initial value and the
ramping value which multiplied by the number of re-transmission
− InitialReceivedTargetPower/powerRampingStep
Below figure is Periodic RO in Action.
Below is RO Function List.
RO Function Description
RACH_OPT_ENABLE Retrieval Checks if the RO function is configured.

RACH_OPT_ENABLE Change Specifies execution of the RO function.
RO Function Execution Data Queries the data related to RO function execution.
Retrieval
RO Function Execution Data Specifies the data needed to execute RO function.
Change
Statistical Data Collection Checks the collection function of the statistical data needed to
needed to execute RO function execute the RO function.
RACH Parameter Manual Checks whether the confirmation is requested to the operator
Change when the RACH parameter is changed by the RO function.
RACH Parameter Automatic Checks whether the change is automatically implemented
Change without the confirmation requested to the operator when the
RACH parameter is changed by the RO function.

Feature Description
RACH Optimization Functions

Get RACH_OPT_ENABLE
The inputs of the RTRV-SONFN-CELL command, which checks whether the RO function
is configured, are described below.
CELL_NUM: A cell number to retrieve RACH_OPT_ENABLE.
The execution of RTRV-SONFN-CELL command outputs whether the selected cell

performs the RO function.
Set RACH_OPT_ENABLE
The inputs of the CHG-SONFN-CELL command, which enables the RO function
execution, are described below.
CELL_NUM: A cell number to change RACH_OPT_ENABLE.
RACH_OPT_ENABLE: Option to enable the RO function execution.
RESULT = OK is output if CHG-SONFN-CELL is successfully executed, and the reason

for the failure is output if is not successfully executed.
Get RO Function Execution Data Retrieval

The RTRV-SON-RO command retrieves the data configured to execute the RO function.
It is meaningful when the RACH_OPT_ENABLE value is not sonFuncOff.
The execution of the RTRV-SON-RO command outputs the RO related data of the selected
eNB.
Set RO Function Execution Data Retrieval

A. The inputs of the CHG-SON-RO command, which configures the data needed for RO
function execution, are described below.
T_PERIOD: A period to monitor the statistics. It is a timer value (1Day/1Week/1Month,

default 1Month) used to trigger the RACH parameter control.
T_PERIOD_TEMP: A period to monitor the statistics to determine the need for fallback.
It is a timer value (1Hour/1Day/1Week, default 1Week) to review the problem of
temporarily not satisfying the RACH performance after changing the RACH parameter.
RACH_FILTERING_COEFF: A coefficient applied to filtering in RACH statistical data

processing.
DEDICATED_INCREASE: A critical value to increase the number of dedicated preambles.
DEDICATED_DECREASE: A critical value to decrease the number of dedicated

Feature Description
preambles.
PROB_DEDICATED_INCREASE: A reference probability value to increase the number of

dedicated preambles.
PROB_DEDICATED_DECREASE: A reference probability value to decrease the number

of dedicated preambles.
DEDICATED_MAX: A maximum number of dedicated preambles.
DEDICATED_MIN: A minimum number of dedicated preambles.
POWER_INCREASE: A critical value to increase the preamble Tx related power resources.
POWER_DECREASE: A critical value to decrease the preamble Tx related power

resources.
POWER_INCREASE_DED: A critical value to increase the dedicated preamble Tx related

power resources.
POWER_DECREASE_DED: A critical value to increase the dedicated preamble Tx related

power resources.
PROB_POWER_INCREASE: A reference probability value to increase the preamble Tx

related power resources.
PROB_POWER_DECREASE: A reference probability value to decrease the preamble Tx

related power resources.
PREAMBLE_INITIAL_RECEIVED_TARGET_POWER_MAX: A maximum value of the

initially received target power.
PREAMBLE_INITIAL_RECEIVED_TARGET_POWER_MIN: A minimum value of the

initially received target power.
POWER_RAMPING_STEP_MAX: A maximum value of the ramping step.
POWER_RAMPING_STEP_MIN: A minimum value of the ramping step.
CONTENTION_INCREASE: A critical value to increase the PRACH configuration index.
CONTENTION_DECREASE: A critical value to decrease the PRACH configuration index.
PROB_CONTENTION_INCREASE: A value to increase the PRACH configuration index.

Feature Description
PROB_CONTENTION_DECREASE: A reference probability value to decrease the

PRACH configuration index.
TIME_CHANCE_MAX: A maximum value of the time chance index related to the

PRACH configuration index.
TIME_CHANCE_MIN: A minimum value of the time chance index related to the PRACH
configuration index.
HIGH_SPEED_FLAG_ON: Threshold for tunning on the high speed flag
HIGH_SPEED_FLAG_OFF: Threshold for tunning off the high speed flag
PROB_HIGH_SPEED_FLAG_ON: Probability Threshold for tunning on the high speed

flag
PROB_HIGH_SPEED_FLAG_OFF: Probability Threshold for tunning off the high speed

flag
B. RESULT = OK is output if CHG-SON-RO is successfully executed, and the reason for

the failure is output if is not successfully executed.
Collection of Statistical Data Needed for RO Function Execution

sonAutoApply is selected as the value of RACH_OPT_ENABLE of CHG-SONFN-CELL.
It specifies the parameter values needed to execute the RO function in CHG-SON-RO.
The operator can check the RA/DedicatedPreamblesAssignFail, RA/HighSpeedMonitoring,
RA/NoofHighSpeed, HO_INTRA/IntraEnbAtt, HO_X2_IN/InterX2InAtt, and
HO_S1_IN/InterS1InAtt statistical data collection function in the statistical retrieve
window.
The operator can execute the UE information procedure to check whether the internal
statistical data are collected using a debug command.
RACH Parameter Manual Change

sonManualApply is selected as the value of RACH_OPT_ENABLE of CHG-SONFN-
CELL.
It specifies the parameter value to execute the RO function in CHG-SON-Ro with
reference to RO algorithm.
It generates the statistical data with reference to RO algorithm.
It monitors whether the RO algorithm is enabled in the CSAB block.
When an event of the change of the numberOfRA-Preambles, powerRampingStep,
preambleInitialReceivedTargetPower, prach-ConfigIndex, or highSpeedFlag value is
generated, the operator can select Confirm on the ‘SON Management’/‘SON Manual

Feature Description
Apply’ window of LSM.

Run the RTRV-RACH-CONF and RTRV-PRACH-CONF commands to check if the
parameters listed in 5 are changed.
RACH Parameter Automatic Change

sonAutoApply is selected as the value of RACH_OPT_ENABLE of CHG-SONFN-CELL.
It specifies the parameter value to execute the RO function in CHG-SON-Ro with
reference to RO algorithm.
It generates the statistical data with reference to RO algorithm.
It monitors whether the RO algorithm is enabled in the CSAB block.
When an event of the change of the numberOfRA-Preambles, powerRampingStep,
preambleInitialReceivedTargetPower, prach-ConfigIndex, or highSpeedFlag value is
generated, the operator can run the RTRV-RACH-CONF and RTRV-PRACH-CONF
commands to check if the parameter value is changed.

Feature Description
System Operation
RTRV-PRACH- ZERO_CORREL_ZONE_CO The zero correlation zone used to create a

CONF NFIG random preamble.
CHG-PRACH- HIGH_SPEED_FLAG Whether to use unrestricted or restricted
CONF set. When this parameter is set to TRUE, a
restricted set is used. When set to FALSE,
an unrestricted set is used.
RTRV-PRACH- PRACH_FREQUENCY_OFF Provides information about the first
CONF SET physical resource block available for
CHG-PRACH- PRACH expressed. This value depens on
CONF UL bandwidth.
PRACH_CONFIG_INDEX Index for the preamble format, subframe
sent by preamble, and interval.
ROOT_SEQUENCE_INDEX The first logical root sequence index used
to create a random preamble.
Different values should be assigned to
neighboring cells.
RTRV-RACH-CONF NUMBER_OF_RAPREAMBL The number of non-dedicated preambles.
CHG-RACH-CONF ES
SIZE_OF_RAPREAMBLES_ The number of PreamblesGroup A.
GROUP_A
MESSAGE_SIZE_GROUP_A Standard for message size to select
PreamblesGroup A.
MESSAGE_POWER_OFFS Standard for power offset to select
ET_GROUP_B PreambleGroup B.
POWER_RAMPING_STEP Power ramping steps when sending a
preamble.
PREAMBLE_INIT_RCV_TAR The threshold used to set an initial-target
GET_POWER receiving power of preambles.
PREAMBLE_TRANS_MAX The maximum number of times to transmit
a preamble.
CONTENTION_RESOLUTIO Contention resolution timer.
N_TIMER
MAX_HARQMSG3_TX The maximum number of transmission of
HARQ Msg3.

Feature Description
(Continued)
RTRV-SONFN- IRAT_ANR_ENABLE_C1_X Controls SON ANR in 3 modes when ANR

CELL RTT_B800_M operations are applied to CDMA2000
1xRTT neighbor cells included in the
800MHz band-class.
- sonFuncOff: The ANR function is
disabled.
ranking are performed automatically, and
The HO Black List adding and NR deletion
are performed manually.
- sonAutoApply: The NR adding, NR
ranking, HO Black List management, NR
deletion are performed automatically.
IRAT_ANR_ENABLE_C1_X Controls SON ANR in 3 modes when ANR
RTT_B2_G operations are applied to CDMA2000
1xRTT neighbor cells included in the 2 GHz
band-class.
disabled.
IRAT_ANR_ENABLE_HRPD Controls SON ANR in 3 modes when ANR
_B800_M operations are applied to CDMA2000
HRPD neighbor cells included in the 800
MHz band-class.
disabled.

Feature Description
(Continued)
RTRV-SONFN- IRAT_ANR_ENABLE_HRPD_ Controls SON ANR in 3 modes when ANR

CELL B2_G operations are applied to CDMA2000
HRPD neighbor cells included in the 2 GHz
band-class.
disabled.
INTER_FREQ_ANR_MEAS The period of time taken for a UE to
UREMENT_PERIOD perform the inter-frequency ANR
measurement, in a unit of second.
C1_XRTT_ANR_MEASURE The period of time taken for a UE to
MENT_PERIOD perform the CDMA2000 1xRTT ANR
HRPD_ANR_MEASUREME The period of time taken for a UE to
NT_PERIOD perform the CDMA2000 HRPD ANR
ANR_UE_SEARCH_RATE_T The total searching rate of UE (User
OTAL Equipment) which measures intra-LTE and
inter-RAT neighbor cells in a ANR-specific
operation period, in a unit of percentage.
ANR_UE_SEARCH_RATE_I The searching rate of UE (User Equipment)
NTRA_FREQ which measures intra-LTE intra-frequency
neighbor cells in a ANR-specific operation
period, in a unit of percentage.
ANR_UE_SEARCH_RATE_I The searching rate of UE (User Equipment)
NTER_FREQ which measures intra-LTE and inter-
frequency neighbor cells in a ANR-specific
operation period, in a unit of percentage.
ANR_UE_SEARCH_RATE_ The searching rate of UE (User Equipment)
C1_XRTT which measures CDMA2000 1xRTT
ANR_UE_SEARCH_RATE_ The searching rate of UE (User Equipment)
HRPD which measures CDMA2000 HRPD

Feature Description
(Continued)
RTRV-SONFN- CENTRALIZED_MRENABLE Control SON MRO in 2 modes.

CELL - Off(0): eNB does not collect the MRO
statistics. Any X2 messages (RLF
INDICATION and HANDOVER REPORT)
are not exchanged between eNBs. eNB
does not also deliver the MRO statistics.
- On(1): eNB collects the MRO statistics
and it delivers the statistics every period
of time (e.g. 5 minutes)
PCI_CONFLICT_RELEASE_ In case that a PCI conflict (collision or
WAITING_TIMER confusion) problem occurrs between two
eNBs, the eNB which has a smaller ECGI
waits the release of this problem during the
period of the value of this parameter.
The unit of this parameter is minute.
ANR_ENABLE_BAND800_M Controls SON ANR in 3 modes when ANR
operations are applied to neighbor cells
included in the 800MHz band-class.
disabled.
ANR_ENABLE_BAND1_DO Controls SON ANR in 3 modes when ANR
T5_G operations are applied to neighbor cells
included in the 1.5GHz band-class.
disabled.

Feature Description
(Continued)
RTRV-SONFN- ANR_ENABLE_BAND2_G Controls SON ANR in 3 modes when ANR

CELL operations are applied to neighbor cells
included in the 2 GHz band-class.
disabled.
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SO0501, Intra-LTE Mobility Robustness

Optimization
Overview
Samsung MRO supports HO parameter auto setup function to enhance HO performance
during the system operation. Samsung MRO is triggered at intervals set by the operator,
analyzes causes of HO-related problems, and collects statistics on the causes of the
problems. At the end of the interval, Samsung MRO analyzes the collected statistics to
determine whether HO parameter needs to be changed. If required, it changes the value
appropriately.
Introduction
Samsung MRO optimizes the HO performance automatically during system operation, in
order to satisfy KPI for HO success rate and to reduce ping-pong HO to the extent of
satisfying KPI. Samsung MRO is triggered at regular intervals, and controls HO parameters
based on the HO statistics collected during the interval. The HO-related statistics used by
Samsung MRO include all the HO-related problems specified in 3GPP standard (Too-late
HO/Too-early HO/HO to Wrong Cell). RLF indication messages and handover report
messages delivered through X2 interface are used to collect statistics on the above
problems.
Samsung MRO controls CIO, the HO parameter that changes HO time at the cell’s level, in
order to satisfy KPI on HO success rate and to reduce ping-pong HO; if KPI is not satisfied,
the function controls the CIO value based on the tendency of the HO-related problems.
It also monitors if the HO performance sharply slows down for a certain period of time
after changing the CIO value. If so, it performs fallback action to return to the previous
CIO value, maintaining stability of HO performance.
Benefits
The Samsung MRO function provides the following benefits:
1) For operator: CAPEX and OPEX expenses used to enhance HO performance during
the system operation can be reduced.
2) For end user: As the optimized HO is performed in consideration of coverage and air
status of each neighbor cell, it provides great user experience through maximum
performance with high HO success rate and low call drop rate. eNB uses the
RSRP/RSRQ of serving cell and best neighbor cell. The information is reported by UE
and shared between eNBs via X2. If there is no neighbor cell that has stronger signal
strength than the source cell, the algorithm decides that there is a coverage hole
between two cells.

Feature Description
Release History
SLR2.2
Basic or Optional
Optional feature: Auto/Manual/Off modes are available for the MRO function operation.

The Samsung MRO function has following dependencies and limitations:
1) Dependency
 X2 interface setting: To activate the MRO function, X2 interface must be
established with neighbor eNBs.
2) Limitation
 N/A
Reference
(Release 9)
cases and solutions
Feature Scope
The scope of features of Samsung MRO is as follows:
R1 Samsung MRO enables the operator to set the MRO operation mode to
Auto/Manual/Off through LSM.
R2 Samsung MRO enables the operator to retrieve statistical data collected for each HO-
related problem through LSM.
R3 Samsung MRO supports the HO problem classification function (based on RRC
connection reestablishment message).
R4 Samsung MRO supports the HO problem classification function (based on X2 RLF
INDICATION message).
R5 Samsung MRO supports the HO problem classification function (based on X2
HANDOVER REPORT message).
R6 Samsung MRO supports the HO parameter optimization function (based on CIO).
R7 Samsung MRO supports the HO parameter fallback function.
R8 Samsung MRO supports the HO parameter optimization abnormality reporting
function.

Feature Description
Feature Description
Architecture
The Samsung MRO function works in eNB. Below figure illustrates the overall
architecture of the function.
In the above architecture, the Samsung MRO function is performed by the SON agent of
eNB. The detailed procedures are as follows:
 SON Agent: HO-related problem detection function
Receives the RLF INDICATION/HANDOVER REPORT message from X2.
Receives UE context from RRC.
Collects and delivers the statistics on the causes of HO-related problems to OAM.
 SON Agent: HO parameter control triggering function
Monitors the MRO algorithm action interval.
Monitors change in HO performance for certain period of time after change of CIO.
Collects statistics on HO and HO-related problems from OAM.
Determines whether to control HO parameters.
Triggers HO parameter control action and delivers the MRO algorithm input.
 SON Agent: HO parameter control function
Controls HO parameters to reduce Ping-pong HO.
Controls HO parameters based on the HO-related problems.
Provides the changed CIO to RRC.

Feature Description
MRO Function
Collection of handover-related problem statistics
The Samsung MRO function collects and categorizes the HO-related problems as
following:
 HO-related problem classification
Time that RLF Re-establishment cell

occurs Serving cell Target cell Other Cell
Before HO initiation 1) CoverageHole N/A 2) TooLateHO

(RLFBeforeTriggering)
After HO triggering 3) CoverageHoleN 4) TooLateHO 6) HOtoWrongCell
(RLFAfterTriggering) (RLFAfterTriggering)
5) CoverageHoleN
During HO 7) TooEarlyHO 4) TooLateHO 6) HOtoWrongCell
execution (HOFailure) (RLFAfterTriggering) (RLFAfterTriggering)
5) CoverageHoleN
After HO execution 8) TooEarlyHO 1) CoverageHole 9) HOtoWrongCell
(RLFAfterHO) (RLFAfterHO)
The details of statistics items mentioned in the above table are as follows:
1) CoverageHole
RLF occurs without any HO initiation in UE.
UE requests for RRC connection reestablishment to the serving cell.
2) TooLateHORLFBeforeTriggering
RLF occurs without any HO initiation in UE.
UE requests for RRC connection reestablishment to the other cell.
The cell transmits the RLF indication message to the serving cell through the X2
interface.
3) CoverageHoleN
UE transmits the MR message initiated by triggering HO.
4) TooLateHORLFAfterTriggering
UE fails to receive a HO command from the service cell, or fails to perform HO
with the target cell after receiving a HO command.
UE requests for RRC connection reestablishment to the target cell.
UE informs retention of RLF report information in the reestablishment with the
target cell. (If UE retains the RLF report information, this information is provided
through the UE information procedure.)

Feature Description
The target cell transmits the RLF indication message to the serving cell through
the X2 interface. (This message contains the RLF report information if it is
acquired.)
5) CoverageHoleN
UE requests for RRC connection reestablishment to the target cell.
UE informs whether RLF report information is available during the
reestablishment with the target cell. (If UE retains the RLF report information,
this information is provided through the UE information procedure.)
the X2 interface. (This message contains the RLF report information if it is
acquired.)
6) HOtoWrongCellRLFAfterTriggering
UE requests for RRC connection reestablishment to the other cell, not to the
serving cell or the target cell.
The third cell transmits the RLF indication message to the serving cell through the
X2 interface.
7) TooEarlyHOHOFailure
UE receives the HO command from the serving cell.
UE fails HO with the target cell.
8) TooEarlyHORLFAfterHO
UE creates RLF in a short period of time (Tstore_ue_cntxt).
UE requests for RRC connection reestablishment to the current serving cell.
The serving cell transmits the RLF indication message to the target cell through
the X2 interface.
the X2 interface.
9) HOtoWrongCellRLFAfterHO
UE creates RLF in a short period of time (Tstore_ue_cntxt).
UE requests for RRC connection reestablishment to the other cell, not to the
serving cell or the target cell.

Feature Description
The other cell transmits the RLF indication message to the target cell through the
X2 interface.
The target cell transmits the handover report message to the serving cell through
the X2 interface.
Detection of coverage hole

The Samsung MRO function detects and compiles statistics on coverage holes based on the
RLF report included in the RLF indication message. In the Samsung MRO function, the
target cell acquires RLF report information from UE through the following procedures:
1) UE transmits the MR message initiated by triggering HO.

2) UE fails to receive a HO command from the service cell, or fails to perform HO with
the target cell after receiving a HO command.
3) UE requests for RRC connection reestablishment to the target cell.
4) If RLF report information is included in the RRC connection reestablishment complete
message, UE sets the rlf-InfoAvailable-r9 IE value in this message to True.
5) The target cell sets the rlf-ReportReq IE value in the UE information request message
to True.
6) UE includes the RLF report information (RLF-Report-r9) in the UE information
response message.
Out of the RLF report information transmitted by UE, measResultLastServCell contains

the serving cell measurement results before RLF, and measResultNeighCells contains the
measurement results of the neighbor cells before RLF. The cell that makes the highest
result is placed at the top, and other cells are lined up in the descending order.
If MeasConfig contains MeasObjectEUTRA of different EUTRA frequencies,
MeasResultList2EUTRA contains carrier frequency information and the corresponding
MeasResultListEUTRA information.
To detect coverage holes, the Samsung MRO function checks if the following formula is
true by using Serving cell RSRP (RSRPServingCell) and Best neighbor cell RSRP
(RSRPBestNeighborCell) values included in the RLF report received from the target cell:
RSRPBestNeighborCell − RSRPServingCell < 0 (1)
If the formula (1) is true, it means that there is no neighbor cell having higher RSRP than
the serving cell RSRP before RLF. Therefore, the RLF is determined to be occurred by the
coverage hole. If the above formula is not satisfied, it means that there is a neighbor cell
having higher RSRP than the serving cell, but RLF occurred as UE triggered HO late.
In this situation, it is considered that the RLF is due to Too-late HO. The following figure
illustrates the situation that the Samsung MRO detects a coverage hole.

Feature Description
Below figure is Coverage hole detection.
Control of handover parameter

The Samsung MRO algorithm is performed in the following procedures, and expressed as
illustrated in below figure:
1) At the end of MRO algorithm period (T_PERIOD),

If HO success rate by neighbor cell ≥ HO success rate KPI, the Samsung MRO
function adjusts the CIO value to decrease ping-pong HO, raising HO margin.
If HO success rate measurement < HO success rate KPI,
 and if Too-late HO problem occurrence rate > Too-early HO problem
occurrence rate, the function extends the CIO value to advance the HO point
for reducing the HO margin;
 and if Too-late HO problem occurrence rate ≤ Too-early HO problem
occurrence rate, the function reduces the CIO value to put off the HO point for
raising HO margin.
2) If the HO performance is deteriorated after a certain period of time after the changed
CIO is applied, the function performs fallback action to return to the previous CIO
value for maintaining stability of HO performance.
Collecting HO-related problems

T_PERIOD timer expiry
Calculating HO success rate per

each neighbor cell
(1) Increasing the value of CIO

by 1 step for reducing Too-late
HO occurrence rate Decreasing the value of CIO by 1
Does HO Success rate per
(2) Decreasing the value of CIO step for Reducing Ping-pong HO
neighbor cell satisfy KPI?
by 1 step for reducing Too-early No Yes
HO occurrence rate
Is HO performance monitored CIO fallback (maintaining stable

during some period lower than HO stable performance)
No previous one? Yes

Feature Description
System operation
The operator can use the following commands and parameters to set the operation mode of
the Samsung MRO function to Auto/Manual/Off, or to retrieve the operation mode:
CHG- MOBILITY_ROBUSTNESS_ Command that changes the operation mode

SONFN- ENABLE; of MRO function, controlled by cell.
CELL (Range = [0, 2], Init = 0) 1) sonFuncOff (= 0): The MRO function is
disabled except collecting the HO-
related problem statistics.
2) sonManualApply (= 1): The change of
handover parameter is performed if
operator confirms this change.
3) sonAutoApply (= 2): The change of
handover parameter is performed
automatically.
RTRV- N/A Command that retrieves the operation mode
SONFN- of MRO function, controlled by cell.
CELL
The operator can control Samsung MRO function operations with the following commands
and parameters:
CHG-SON- T_PERIOD, Command that changes the parameter

MRO T_PERIOD_TEMP, values used to MRO function.
HANDOVER_SUCCESS_KPI,
N_HANDOVER_THRESH,
OFFSET_MAX,
OFFSET_MIN;
T_PERIOD The period of time that collects the HO-
(Range = [0, 2]. Init = 1) related problem statistics.
1) one_day 0): MRO function is triggered
based on the statistics collected for 1 day.
2) one_week 1): MRO function is triggered
based on the statistics collected for 1 week.
3) one_month 2): MRO function is triggered
based on the statistics collected for 1 month.

Feature Description
(Continued)
CHG-SON- T_PERIOD_TEMP The period of time that monitors sudden

MRO (Range = [0, 2]. Init = 1) degradation of handover success rate. If this
situation occurs, handover parameter is
fallback to the previous value.
1) one_hour 0): The statistics is collected for
1 hour to monitor the fallback situation.
2) one_day 1): The statistics is collected for
1 day to monitor the fallback situation.
3) one_month 2): The statistics is collected for
1 month to monitor the fallback situation.
HANDOVER_SUCCESS_KPI The threshold related to handover success
(Range = [90.0, 100.0], Init = 99.0) rate, used to trigger the handover parameter
control algorithm which reduces HO-related
problems.
N_HANDOVER_THRESH The threshold related to the number of
(Range = [0, 100000], Init = 10000) handover attempt, used to trigger the
handover parameter control algorithm.
OFFSET_MAX The maximum value allowable for HO
(Range = [0, 39], Init = 5) margin which is equal to A3Offset-CIO, by
the unit of dB.
OFFSET_MIN The minimum value allowable for HO margin
(Range = [-39, 0], Init = 0) which is equal to A3Offset-CIO, by the unit of
dB.
RTRV-SON- N/A Command that retrieves the parameter
MRO values used to MRO function.

Feature Description
Related Counters
The Samsung MRO function uses following statistics:
CoverageHole The number of RLFs due to coverage Operator can check this with
hole existed in the serving cell PM statistics in the LSM
CoverageHoleN The number of RLFs due to coverage Operator can check this with
hole existed in the serving cell and, PM statistics in the LSM
especially, in direction to neighbor
cell N.
TooEarlyHOFailure The number of RLFs occurred during Operator can check this with
HO procedure then UE re-establishes PM statistics in the LSM
the connection in the source cell.
TooEarlyHORLFAfterHO The number of RLFs occurred during Operator can check this with
short time after the UE was PM statistics in the LSM
successfully connected to the target
cell then UE re-establishes the
connection in the source cell.
TooLateHORLFBeforeTri The number of RLFs in the source Operator can check this with
ggering cell occurred before the HO was PM statistics in the LSM
initiated then UE re-establishes the
connection in a cell different than the
source cell.
TooLateHORLFAfterTrig The number of RLFs in the source Operator can check this with
gering cell occurred during HO procedure PM statistics in the LSM
then UE re-establishes the
connection in a cell different than the
source cell.
WrongCellRLFAfterTrigg The number of RLFs occurred during Operator can check this with
ering HO procedure then UE re-establishes PM statistics in the LSM
the connection in a cell other than the
source cell or the target cell.
BlackCellRLFAfterHO The number of RLFs occurred during Operator can check this with
short time after the UE was PM statistics in the LSM
successfully connected to the target
cell then UE re-establishes the
connection in a cell other than the
source cell or the target cell.
PingpongHandover The number of handovers in which Operator can check this with
the time that UE stays in the target PM statistics in the LSM
cell is less than a predefined
threshold.

Feature Description
(Continued)
IntraEnbPrepSucc The number of Intra-eNB handover Operator can check this with
preparation success to intra-eNB PM statistics in the LSM
neighbor cell
IntraEnbSucc The number of Intra-eNB handover Operator can check this with
execution success to intra-eNB PM statistics in the LSM
neighbor cell
InterX2OutPrepSucc The number of X2 HO preparation Operator can check this with
success to inter-eNB neighbor cell PM statistics in the LSM
InterX2OutSucc The number of X2 HO execution Operator can check this with
InterS1OutPrepSucc The number of S1 HO preparation Operator can check this with
InterS1OutSucc The number of S1 HO execution Operator can check this with
Related KPI/PI
KPI Description How to check
EutranMobilityHOIntra Intra-eNB handover success rate of Operator can check this with
E-UTRAN mobility PM statistics in the LSM
EutranMobilityHOX2Out X2 handover success rate of E- Operator can check this with
UTRAN mobility PM statistics in the LSM
EutranMobilityHOS1Out S1 handover success rate of E- Operator can check this with
UTRAN mobility PM statistics in the LSM

Feature Description
LTE-SO0601, Cell Outage Detection

Overview
Introduction
The sleeping cell detection feature detects sleeping cells (i.e., abnormal state) in advance
before the eNB alarms.
Benefits
 Operator Benefits:
− Sleeping cell is automatically detected by analyzing the CRR.
− The automating of this minimizes human intervention in the network management
and self-healing tasks.
Release History
SLR 2.4

 Dependency
− None
 Limitation
− None
Feature Scope
R1 CRR statistics monitoring
R2 Sleeping cell detection
R3 Sleeping cell report
Reference
1) 3GPP TS32.541 Telecommunication management; Self-Organizing Networks (SON);
Self-healing concepts and requirements

Feature Description
Feature Description
Sleeping Cell Detection
Sleeping cell detection operates in the following steps. If the sleeping cell condition is
satisfied, an alarm is generated and notified to the operator.
1) Detection is performed every 0, 15, 30, and 45 minutes of every hour by counting the
number of normal CRRs.
2) At a detection time, the function checks whether the number of normal Call Release
Reasons (CRRs) for last 15 minutes for all cells that meet the detection condition is
equal to or less than the threshold.
3) If the number of normal CRRs is equal to or less the threshold, the LSM checks
whether the number of CRRs for a specific past time period is equal to or less than the
threshold by referring to the current detection period and the detection start and end
times.
4) If the number of normal CRR for a specific past time period is equal to or less the
threshold, a silent alarm is generated.
5) The operator can set a specific past time period.
6) If the number of normal CRR is the same or higher than the threshold, and a silent
alarm is generated to the cell, then a silent alarm is cleared.
7) If an alarm is generated, the cell ID is added in which the alarm information is saved.
8) The operator can set the ON/OFF and threshold values of the silent alarm node
detection feature for each Pico eNB and change them in the EMS client GUI.
9) Silent alarm nodes are displayed on the screen as shown below.
Field Description Example
eNB ID eNB ID 1
Name eNB name Roppongi
ON : Sleeping cell detection is
performed for the cell.
Cell Whether to detect a sleeping cell
OFF : Sleeping cell detection is not
performed for the cell.
Threshold that determines whether
Threshold 0
to generate a silent alarm.
Period 1 for checking the number of
normal CRRs to determine whether to
PERIOD_1ST Range (unit:15min)
generate an alarm. If it is zero, it is
deactivated (PERIOD_ALL value).
Start Hour Start time of Period 1. 0
End Hour End time of Period 1. 4

Feature Description
(Continued)
Field Description Example
Period 2 for checking whether CRR is

normal and generating an alarm. If it is
PERIOD_2ND Range (unit:15min)
zero, it is deactivated (PERIOD_ALL
value).
Start Hour Start time of Period 2. 12
End Hour End time of Period 2. 17
All other periods than Periods 1 and 2
for checking the number of normal
PERIOD_ALL Range (unit:15min)
CRRs to determine whether to generate
an alarm.
10) By designating cells to be excluded from detection, misjudgment on increasing traffic

caused by events such as concerts can be prevented.
Conditions for Excluding from Detection

The detection function is not performed when:
1) eNB is non-active or access to the eNB is restricted.
2) The cell is locked.
3) The number of CRRs collected for the five minute is No Data (ND) or No Good (NG).
4) The detection of the previous period is not complete yet.
5) An alarm is generated in the eNB.
6) The sleeping cell detection is turned off.

Feature Description
Sleeping Alarm Detection Flow
Start the sleeping

cell detection
Whether to
exclude from
detection
NO
A sleeping cell
Recent CRR A sleeping cell
NO alarm is being YES
<= threshold alarm is cleared
generated
YES
NO
Number of normal
CRRs for a specific
past time period <=
threshold
YES NO
YES
A sleeping cell
A sleeping cell
alarm is being NO
alarm is generated
generated
YES
END

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SO0603, Sick Cell Detection

Overview
Introduction
The sick cell detection feature provides the user interface that displays the performance
limit status of cells and eNBs as Normal or Warning based on the traffic statistics, so the
operator can easily identify whether air and backhaul resources reached the performance
limit in a cell and eNB.
Benefits
This feature allows the operator to identify cells and eNBs where air and backhaul
resources reached the performance limit and to manage these resources efficiently.
If a warning keeps occurring in the same cell and eNB over a certain period of time, the
cell and eNB can be used as reference for backhaul expansion.
Release History
SLR 2.4

 Dependency
− None
 Limitation
− None
Feature Scope
R1 Statistics monitoring
R2 Sick cell detection
R3 Sick cell detection report
Reference
N/A

Feature Description
Feature Description
eNB load
This feature provides the GUI that shows warning status of eNB which have reached
performance limit for air resources and backhaul resources over a certain period of time.
The operator can view traffic statistics (minimum, average, maximum) of eNB for a
specified period (month, day, hour).
Below table is tatistics Items for Identifying eNB Status.
eNB Status Quality Indicator Statistics Collected Criteria (Example)
Usage rate of air DL/UL PRB(*) Usage - Normalized NGBR DL

resources Throughput per UE < M
Insufficient air - Normalized NGBR UL
Number of active RRC connected User
resources Throughput per UE < N
users
Air Throughput DL/UL Throughput
Backhaul usage rate Rx/Tx Backhaul - (Rx Backhaul Usage > A)
Usage && (Normalized NGBR DL
Usage rate of air DL/UL PRB(*) Usage Throughput per UE < M)
Insufficient
resources - (Tx Backhaul Usage > B)
backhaul
&& (Normalized NGBR UL
resources Number of active RRC connected User
Throughput per UE < N)
users
Air Throughput DL/UL Throughput
PRB: Physical Resource Block
Description of judgment criteria
 Air resources are insufficient

In general, air resources are allocated to GBR traffic first and then the remaining resources
to NGBR traffic. Therefore, as NGBR users increase, NGBR throughput per user decreases.
As such, assuming that the quality of service for GBR traffic is always guaranteed,
dropping of NGBR throughput per user below a certain level can be used as a reference for
judging insufficient air resources.
In this case, since the case of low throughput due to low use of air resources by the
subscribers needs to be isolated from the case of low throughput due to performance limit,
PRB usage is normalized.
The formula for defining normalized NGBR DL throughput per UE is as follows.

Feature Description
Where, available PRB means the maximum available resources to be used for NGRB
traffic. It can be expressed as the sum of PRB used for the current NGBR traffic and
remaining PRB.
Below figure shows an example of calculating normalized NGBR DL throughput per UE.
 Backhaul resources are insufficient

When backhaul resources are insufficient, even if there are sufficient air resources, the
overall throughput decreases. Therefore, dropping of NGBR throughput per user below a
certain level, as a result of backhaul resources becoming bottlenecks, can be used as a
reference for judging insufficient backhaul resources.
 Setting the thresholds (M, N, A, B)

The thresholds (M, N, A, B) for identifying air resource and backhaul resource status are
subject to change by throughput policy and actual network operation status of the operator
and may be adjusted by the operator.
Just for your information, the Samsung default values are shown in below table.
Below table is judgment threshold setup.

Judgment Threshold Dafault Value
M 512 kbps
N 128 kpbs
A 70 %
B 70 %
Usage
Enter search conditions in the search window.

Feature Description
 Use the [15 Min] or [1 Hour] radio button to set the statistics type to search..
 Use the [Period] field to set a period to search. (Only the statistics data for this period
will be retrieved.)
 Use the [Rows] combo box to set how many rows of data to show on each page.
 Use the [Search] button to search the traffic statistics for the period specified.
Refer to the Analysis result column in the results table. (This is an example of analysis
results and User Interface can be upgrade)
 When the data is retrieved, traffic statistics for eNBs registered for the current LSM is
shown in a table. Traffic levels exceeding the judging thresholds are indicated in red.
 eNBs with the statistics that exceed the processing performance limit are marked as
Warning in the Analysis Result column.
Result display statistics items
Quality Statistics Collection Description

Indicator Collected Point
Throughput per cell and per QCI.
DL/UL bytes transferred in 10 second
RLC
Air Throughput DL/UL Throughput periods are collected and then DL/UL
PM
transfer rate is calculated on 5-minute
cumulative data.
Average RRC connections per cell.
RRC connections are collected in 2 second
Number of Number of RRC
ECCB periods and then average is calculated on
active users connected users
15-minute cumulative data.
(Average is cumulative/polling count)

Feature Description
(Continued)
Quality Statistics Collection Description
Indicator Collected Point
PRB usage per cell and per QCI.
Usage rate of Among total PRB, DL PDSCH/PDCCH and
DL/UL PRB Usage MAC
air resources PRB occupancy of UL PUSCH are
collected as percentage.
Rx/Tx backhaul resource usage per eNB
Backhaul usage Rx/Tx Backhaul
Ethernet Average utilization of Rx/Tx link connected
rate Usage
to the backhaul.

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SV0101, IMS based Emergency Call Support

Overview
Introduction
To support IMS emergency call, eNB performs emergency call specific admission control,
security handling and mobility control.
Benefits
Operator can provide Emergency service to its subscribers while they are staying in E-
UTRAN.
Users can do an emergency call while staying in E-UTRAN, as well as in legacy CS
network.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 IMS capable device, IMS deployment
Limitation:
 None
Reference

Feature Description
Feature Description
IMS Emergency call support indication is provided to inform the UE that emergency bearer
services are supported. If IMS connectivity via MME is supported and IMS Emergency call
is available, eNB broadcasts IMS Emergency call support indicator via SIB1.
Operator can change the indicator based on IMS deployments.
eNB identifies an emergency call based on the RRC establishment cause from UE.
When new emergency call is requested, eNB performs the emergency call specific
admission control. This is achieved by applying higher threshold as decision criteria of
CAC for emergency calls (including handover calls) than normal calls.
If at the time of an IMS emergency call origination, the UE is already RRC connected to a
EPC that does not support IMS emergency calls, it should autonomously release the RRC
connection and originate a fresh RRC connection in a cell that is capable of handling
emergency calls.
Security procedures are activated for emergency calls with ‘NULL’ algorithms.
During handover from cell in non-restricted area to restricted area, security is handled
normally with normal key derivation etc. for both the intra-LTE and inter-RAT handover.

Feature Description
System operation
Command Description
RTRV- Retrieve cell information whether the cell supports IMS (IP Multimedia Subsystem)
CELL-INFO emergency calls. This information is broadcast to UE via SIB 1.
CHG-CELL- Retrieve cell information whether the cell supports IMS (IP Multimedia Subsystem)
INFO emergency calls. This information is broadcast to UE via SIB 1.
RTRV-ENB- Retrieves the capacity based CAC (call admission control) parameter information of
CAC the eNBs in the BS. This command performs call count based CAC at the eNB
level. It also retrieves the threshold information and the MAX call count information
required for CAC at the eNB level.
CHG-ENB- Changes the capacity based CAC (call admission control) parameter information of
CAC the eNBs in the BS. This command performs call count based CAC at the eNB
level. It also changes the threshold information and the MAX call count information
RTRV- Retrieves the CAC (call admission control) parameter information of the cells
CELL-CAC operating within the eNB. As cell-level CACs, backhaul based CAC, call count
based CAC, DRB count based CAC, and QoS based CAC are performed.
Retrieves threshold, CAC option, and preemption status for performing CAC at the
cell level.
CHG-CELL- Changes the CAC (call admission control) parameter information of the cells
CAC operating within the eNB. As cell-level CACs, backhaul based CAC, call count
based CAC, DRB count based CAC, and QoS based CAC are performed.
Changes threshold, CAC option, and preemption status for performing CAC at the
cell level.
Relation Parameter Default value Description
RTRV- CELL_NUM 0 The cell number to be changed or retrieved.

CELL-INFO CELL_SIZE enumCellSize_type_ The is cell size.
CHG-CELL- DEFAULT_CELL_ - ci_cellsize_verysmall: Very Small size cell
INFO SIZE - ci_cellsize_small: Small size cell
- ci_cellsize_medium: Medium size cell
- ci_cellsize_large: Large size cell
HNB_NAME ‘SAMSUNG_LTE’ The name of the home eNB. Broadcast to
the UE through SIB (System Information
Block) 9 when the cell is operated as a CSG
cell or as a hybrid cell in bytes.

Feature Description
(Continued)
RTRV- MCC0 ‘DIGIT_MCC’ Mobile Country Code (MCC) that comprises

CELL-INFO Public Land Mobile Network (PLMN).
CHG-CELL- It is broadcast to UE via SIB 1 when cells are in
INFO operation. A total of 6 PLMN lists are sent.
MCC of PLMN #0, one of the six lists, is entered.
MNC0 ‘DIGIT_MNC’ MNC that comprises PLMN. It is broadcast to
UE via System Information Block (SIB) 1 when
cells are in operation. A total of 6 PLMN lists are
sent. MNC of PLMN #0, one of the six lists, is
entered.
CELL_RESERV ci_notReserv CellReservedOpUse of PLMN #0. Broadcast to
ED_OP_USE0 ed the UE through SIB (System Information Block) 1.
- ci_reserved: Selection/re-selection is reserved
for UEs that have a specific access class (AC)
to PLMN #0.
- ci_notReserved: Selection/re-selection is
available for UEs that have all access classes
(AC) to PLMN #0.
MCC1 ‘FFF’ MCC that comprises PLMN. It is broadcast to
UE via SIB 1 when cells are in operation. A total
of 6 PLMN lists are sent. MCC of PLMN #1, one
of the six lists, is entered.
MNC1 ‘FFF’ MNC that comprises PLMN. It is broadcast to
of 6 PLMN lists are sent. MNC of PLMN #1, one
CELL_RESERV ci_notReserv cellReservedOpUse of PLMN #1. It is broadcast
ED_OP_USE1 ed to UE via SIB 1.
for UEs that have a specific AC to PLMN #1.
(AC) to PLMN #1.

Feature Description
(Continued)
RTRV- CELL_RESERV ci_notReserv cellReservedOpUse of PLMN #2. It is broadcast

CELL-INFO ED_OP_USE2 ed to UE via SIB 1.
CHG-CELL- - ci_reserved: Selection/re-selection is reserved
INFO for UEs that have a specific AC to PLMN #2.
(AC) to PLMN #2.
CELL_RESERV ci_notReserv cellReservedOpUse of PLMN #3. It is broadcast
ED_OP_USE3 ed to UE via SIB 1.
(AC) to PLMN #3.
CELL_RESERV - cellReservedOpUse of PLMN #4. It is broadcast
ED_OP_USE4 to UE via SIB 1.
(AC) to PLMN #4.
MCC5 ‘FFF’ Mobile Country Code (MCC) that comprises
PLMN. It is broadcast to UE via SIB 1 when
cells are in operation. A total of 6 PLMN lists are
sent. MCC of PLMN #5, one of the six lists, is
entered.

Feature Description
(Continued)
RTRV- MNC5 ‘FFF’ MNC that comprises PLMN. It is broadcast

CELL-INFO to UE via SIB 1 when cells are in operation.
CHG-CELL- A total of 6 PLMN lists are sent. MNC of
INFO PLMN #5, one of the six lists, is entered.
CELL_RESERV ci_notReserved cellReservedOpUse of PLMN #5. It is
ED_OP_USE5 broadcast to UE via SIB 1.
- ci_reserved: Selection/re-selection is
reserved for UEs that have a specific
access class (AC) to PLMN #5.
available for UEs that have all access
classes (AC) to PLMN #5.
ADD_SPECTRU 1 Additional spectrum emission used by the
M_EMISSION active cell. At max power, UE can
additionally reduce power. See 6.2.4 in
3GPP TS 36.101. This information is
broadcast to UE via SIB 2.
TRACKING_AR 0 TAC (Tracking Area Code) used by the
EA_CODE active cell. It is used for warning message
transmission and interruption when paging
the UE. This information is broadcast to UE
via SIB 1.
IMS_EMERGEN False supports IMS (IP Multimedia Subsystem)
CY_SUPPORT emergency calls. This information is
- False: The cell in operation does not
support IMS Emergency.
- True: The cell in operation supports IMS
Emergency.
RTRV-ENB- DB_INDEX 0 The index to be changed or retrieved. (range
CAC is fixed to 0~0, so not changeable)
CHG-ENB- CALL_COUNT_ CI_use Whether to execute the Capacity-based Call
CAC CAC_USAGE : PLD value is 1 Admission Control (CAC) function per cell.
- CI_no_use: The capacity-based CAC
function per base station is not performed.
- CI_use: The capacity-based CAC function
per base station is performed.
MAX_ENB_CAL MAX_CALL_ The limit for capacity based CAC (call
L_COUNT COUNT_PER_ admission control) at the eNB level.
SYS The number of calls that can be allowed by
the eNB.

Feature Description
(Continued)
RTRV-ENB- CALL_CAC_T 90 (%) The percentage of the allowable calls to the

CAC HRESH_FOR_ total normal calls. When a normal call is
CHG-ENB- NORMAL requested, if the number of connected calls
CAC exceeds MAX_ENB_CALL_COUNT * CALL_
CAC_THRESH_FOR_NORMAL, the
Capacity-based CAC Fail is generated.
CALL_CAC_T 100 (%) Emergency call availability of total handover
HRESH_FOR_ calls in percentage. When a normal call is
EMER_HO requested, if the number of connected calls
exceeds MAX_ENB_CALL_COUNT * CALL_
CAC_THRESH_FOR_EMER_HO, the
Capacity-based CAC Fail is generated.
CHECK_UE_I 1 Whether to execute the SAE Temporary
D_USAGE Mobile Station Identifier (S-TMSI) Duplication
Check function for a new call.
- CI_no_use: The S-TMSI Duplication Check
function is not performed.
- CI_use: The S-TMSI Duplication Check
function is performed. If a call is found as a
duplicate, the existing call is released and
the new call is accommodated.
RESERVED 0 -
PLMN_ENB_C CI_co_use -
AC_USAGE
RTRV- cellNum 0 The cell number to be changed or retrieved.
CELL-CAC cellCountCacU CI_use Whether to execute the call count-based CAC
CHG-CELL- sage : PLD value is 1 function, which is one of the capacity-based
CAC Call Admission Control (CAC) functions per
cell.
- CI_no_use: The capacity-based CAC
function per cell is not performed.
- CI_use: The capacity-based CAC function
per cell is performed.
maxCallCount MAX_CALL_C The call count limit in the capacity based CAC
OUNT_PER_C (call admission control) at the cell level.
ELL The number of calls that can be allowed by
the cell.
callCacThresh 90 (%) The percentage of the allowable calls to the
ForNormal total normal calls. When a normal call is
requested, if the number of connected calls
exceeds MAX_CALL_COUNT * CALL_CAC_
THRESH_FOR_NORMAL, the Capacity-
based CAC Fail is generated.

Feature Description
(Continued)
RTRV- callCacThresh 100 (%) Emergency call availability of total handover

CELL-CAC ForEmerHo calls in percentage. When a normal call is
CHG-CELL- requested, if the number of connected calls
CAC exceeds MAX_CALL_COUNT * CALL_CAC_
THRESH_FOR_EMER_HO, the Capacity-
drbCountCacU CI_use Whether to execute the E-UTRAN Radio
sage : PLD value is 1 Access Bearer (E-RAB)-based CAC function,
which is one of the capacity-based Call
Admission Control (CAC) functions per cell.
- CI_no_use: The E-RAB count-based CAC
function per cell is not executed.
- CI_use: The E-RAB count-based CAC
function per cell is executed.
maxDrbCount MAX_DRB_CO The limit for the E-RAB (E-UTRAN Radio
UNT_PER_CE Access Bearer) count in capacity based CAC
LL (call admission control) at the cell level.
The number of E-RABs (E-Utran Radio Access
Bearers) allowed in the cell.
drbCacThresh 90 (%) The percentage of the allowable calls to the
ForNormal total normal calls. When a normal call is
exceeds ‘MAX_DRB_COUNT * DRB_CAC_
THRESH_FOR_NORMAL’, the Capacity-
drbCacThresh 100 (%) Emergency call availability of total handover
ForEmerHo calls in percentage. When a normal call is
exceeds ‘MAX_DRB_COUNT * DRB_CAC_
THRESH_FOR_EMER_HO’, the Capacity-
qosCacOption 1 The policy of the QoS (Quality of Service)
based CAC (call admission control) at the cell
level.
- QoSCAC_option0: The QoS based CAC
function at the cell level is not used.
- QoSCAC_option1: The QoS-based CAC
function per cell is used.

Feature Description
(Continued)
RTRV- qosPolicyOption 1 The policy used when executing the Quality of

CELL-CAC Service (QoS)-based Call Admission Control
CHG-CELL- (CAC) function per cell.
CAC - QoSPolicy_option0: For a GBR bearer newly
requested, the PRB usage is calculated
based on the resource type (GBR or non-
GBR) of the QCI. Then CAC is executed
based on the calculated PRB usage.
Non-GBRs are always allowed.
- QoSPolicy_option1: For a GBR bearer newly
requested, the PRB usage is calculated
based on the priority of the QCI. Then CAC is
executed based on the calculated PRB
usage. Non-GBRs are always allowed.
prbReportPeriod 2 [UNIT: sec]
PRB (Physical Resource Block) report period
for QoS CAC at the cell level.
estimationOpt 0 The policy of the Expected PRB usage
calculation. (0: auto, 1: manual)
- EstimationOption_auto(0): The PRB Usage is
automatically calculated.
- EstimationOption_manual(1): The PRB
Usage is manually calculated.
preemptionFlag 1 Whether to use preemption at the cell level.
- CI_no_use: The Preemption function per cell
is disabled.
- CI_use: The Preemption function per cell is
enabled.
bhBwCacUsage 1 Whether to use backhaul bandwidth based
CAC at the cell level.
- CI_no_use: Backhaul Bandwidth-based CAC
function per cell is not used.
- CI_use: Backhaul Bandwidth-based CAC
bhBwCacOption 1 The policy used when executing the Backhaul-
based Call Admission Control (CAC) function
per cell.
- bhBwCac_QCI_only: QoS-based CAC.
- bhBwCac_ServiceGroup_only: Service
group-based CAC.
- bhBwCac_Both_QCI_ServiceGroup: QoS
amp; Service group-based CAC.
plmnCellCacUsa CI_no_use -
ge

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SV0103, Emergency Call via CSFB to

UTRAN_5UK
Overview
Introduction
In case operator provides Emergency service to its subscribers via legacy UTRAN CS
domain, CSFB to UTRAN shall be performed when emergency call is requested.
Benefits
Operator Benefits:
 Operator can provide Emergency service to its subscribers by using legacy CS
network (UTRAN).
End User Benefits:

 Users can do an emergency call while staying in E-UTRAN, by transition to legacy CS
network (UTRAN).
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 None
Limitation:
 None
Reference
3) 3GPP TS36. 413 Evolved Universal Terrestrial Radio Access (E-UTRA); S1
4) 3GPP TS23.272 Circuit Switched (CS) fallback in Evolved Packet System (EPS);
Stage 2

Feature Description
Feature Description
If the emergency service is provided via the legacy UTRAN CS domain, the procedure for
CSFB to the UTRAN is processed during emergency call setup of the subscriber within the
E-UTRAN.
 CSFB to UTRAN with Redirection without SI (Refer to LTE-SW1207)
 CSFB to UTRAN with Redirection with SI (Refer to LTE-SW1208)
 CSFB to UTRAN with PS handover (Refer to LTE-SW1209)
The following is an example of the CSFB to UTRAN procedure of an emergency call.

(CSFB to UTRAN with PS handover case)

Feature Description
1) The UE starts the CSFB procedure. If the UE is in an idle state, it processes the RRC
connection establishment procedure with the eNB to switch to a connected state.
The UE includes RRC establishment cause=emergency in the RRC connection request
message.
2) The UE transmits NAS EXTENDED SERVICE REQEUST. (If it is an outgoing call)
The service type for the emergency call is included.
3) The MME transmits the S1 request message including the CSFB indicator (CS
Fallback High Priority) to the eNB. If the CSFB is of an UE in an idle, the eNB
processes the AS security activation and default bearer setup procedures.
4) The eNB transmits the S1 response message to the MME.
5) The eNB instructs the UE to perform UTRAN measurement.
6) The procedure for handover preparation between the source E-UTRAN and the target
UTRAN is processed. The eNB includes CSFB Information (CSFB High Priority) in
the Source to Target Transparent Container sent to the target UTRAN.
7) The eNB transmits the Mobility from EUTRA command including the CSFB indicator
and the HO command received from the target UTRAN to the UE.
8) The UE switches to the UTRAN target cell specified by the eNB and transmits HO to
UTRAN Complete to the UTRAN.
9) The UE performs the UTRAN location registration procedure. Afterward the UE
continues the CS service after the CS call setup at the UTRAN.
10) The procedure of handover completion between the source E-UTRAN and the target
UTRAN is processed.
11) The source MME releases resources used by the E-UTRAN after the PS handover with
the UTRAN is completed.

Feature Description
System operation
Command Parameter Default Description
RTRV-EUTRA-FA cellNum 0 [INDEX GROUP: CELL_NUM, FA_INDEX]

CHG-EUTRA-FA The cell number to be changed.
faIndex 0 [INDEX GROUP: CELL_NUM, FA_INDEX]
EUTRA frequency index. Up to 8 FAs can
be assigned per cell.
status 1 Whether the EUTRA FA is valid.
- N_EQUIP: Invalid.
- EQUIP: Valid.
earfcnUl EARFCN_UL Uplink E-UTRA Absolute Radio Frequency
Channel Number.
earfcnDl EARFCN_DL Downlink E-UTRA Absolute Radio
Frequency Channel Number.
priority 7 Priority of EUTRA FA.
qRxLevMin -64 [UNIT: dBm] The minimum RX level
required in a cell in dBm units.
pMaxUsag 1 Whether to use pMax.
e - CI_no_use: pMax value is not used.
- CI_use: pMax value is used.
pMax 0 [UNIT: dBm] The maximum TX power level
in the UE.
tReselectio 1 [UNIT: sec] Reselection timer value.
n
sfUsage 0 Whether to use scaling factors.
- CI_no_use:
T_RESELECTION_SF_MEDIUM and
T_RESELECTION_SF_HIGH values are
not used.
- CI_use: T_RESELECTION_SF_MEDIUM
and T_RESELECTION_SF_HIGH values
are used.
tReselectio TRESELECT The medium timer value of the reselection
nSfMedium _SF_MEDIU scaling factors.
M
tReselectio TRESELECT The high timer value of the reselection
nSfHigh _SF_HIGH scaling factors.

Feature Description
(Continued)
RTRV-EUTRA- sIntraSearch 1 Whether to use sIntraSearch.

FA Usage - CI_no_use: sIntraSearch is not used.
CHG-EUTRA- - CI_use: sIntraSearch is used.
FA sIntraSearch 31 [UNIT: dB] The threshold for intra-frequency
measurement.
sNonIntraSe 1 Whether to use sNonIntraSearch.
archUsage - CI_no_use: sNonIntraSearch is not used.
- CI_use: sNonIntraSearch is used.
sNonIntraSe 31 [UNIT: dB] The threshold for inter-RAT and
arch intra-frequency measurement.
threshServin 31 [UNIT: dB] The low threshold for serving
gLow frequency during reselection evaluation.
threshXhigh 31 [UNIT: dB] The threshold used in the UE to
reselect a frequency whose priority is higher
than the current camped frequency.
threshXLow 31 [UNIT: dB] The threshold used to reselect
low-priority frequency from high-priority
frequency.
mesaBandwi 1 Whether to use measurementBandwidth.
dthUsage - CI_no_use: measurementBandwidth is not
used.
- CI_use: measurementBandwidth is used.
measuremen 3 The maximum measurement bandwidth
tBandwidth allowed for carrier frequency.
presenceAnt 0 Whether Antenna Port1 exists.
Port1 - False: Antenna Port1 does not exist.
- True: Antenna Port1 exists.
neighCellCon 1 The neighboring cell settings.
fig
qOffsetFreq 15 [UNIT: dB] Frequency offset value applied to
q-OffsetFreq in SIB5.
offsetFreq 15 [UNIT: dB] Frequency offset value applied to
offsetFreq in RRC Connection
Reconfiguration.
sIntraSearch 0 Whether to use the sIntraSearch for Rel-9.
Rel9Usage - CI_no_use: sIntraSearch is not used.
- CI_use: sIntraSearch is used.
sIntraSearch 31 [UNIT: dB] The threshold P for an intra-
P frequency measurement in Rel-9.

Feature Description
(Continued)
RTRV-EUTRA- sIntraSearchQ 31 [UNIT: dB] The threshold Q for an intra-

FA frequency measurement in Rel-9.
CHG-EUTRA- sNonIntraSear 0 Whether to use sNonIntraSearch for Rel-9.
FA chRel9Usage - CI_no_use: sNonIntraSearch is not used.
sNonIntraSear 31 [UNIT: dB] The threshold P for inter-RAT and
chP an intra-frequency measurement.
sNonIntraSear 31 [UNIT: dB] The threshold Q for inter-RAT and
chQ an intra-frequency measurement.
qQualMinRel9 0 Whether to use the qQualMin for Rel-9.
Usage - CI_no_use: SqQualMin is not used.
- CI_use: qQualMin is used.
qQualMinRel9 -3 qQualMin value for Rel-9.
threshServing 0 Whether to use the threshServingLowQ for
LowQRel9Usa Rel-9.
ge - CI_no_use: threshServingLowQ is not used.
- CI_use: threshServingLowQ is used.
threshServing 31 [UNIT: dB] threshServingLowQ value for Rel-9.
LowQRel9
threshXhighQ 31 [UNIT: dB] The threshold used in the UE to
Rel9 reselect a frequency whose priority is higher
than the current camped frequency in Rel-9.
threshXLowQ 31 [UNIT: dB] The threshold used to reselect low-
Rel9 priority frequency from high-priority frequency
in Rel-9.
mcc0 ‘FFF’ Mobile Country Code (MCC) that comprises
Public Land Mobile Network (PLMN).
FA have the Preference of Preference0 for
PLMN #0
mnc0 ‘FFF’ MNC that comprises PLMN.FA have the
Preference of Preference0 for PLMN #0
preference0 not_allowed Preference of PLMN #0 for FA.
_
prefer
PLMN #1

Feature Description
(Continued)
RTRV-EUTRA- mnc1 ‘FFF’ MNC that comprises PLMN.FA have the

FA Preference of Preference1 for PLMN#1
CHG-EUTRA- preference1 not_allowed_ Preference of PLMN #1 for FA.
FA prefer
PLMN #2
preference2 not_allowed_ Preference of PLMN #2 for FA.
prefer
PLMN #3
prefer
PLMN#4
Preference of Preference4 for PLMN#4
prefer
PLMN #5
Preference of Preference5 for PLMN
prefer

Feature Description
(Continued)
RTRV-NBR- cellNum 0 The cell number to be changed.

UTRAN relationIdx 0 Database index of UTRAN neighboring cell.
CHG-NBR-
status 0 The validity of the UTRAN neighboring cell
UTRAN
information.
CRTE-NBR-
- N_EQUIP: UTRAN neighboring cell
UTRAN
information is invalid.
DLT-NBR-
- EQUIP: UTRAN neighboring cell
UTRAN
information is valid.
rncId 0 RNC ID of UTRAN neighboring cell to the
eNB.
cId 0 CID of UTRAN neighboring cell to the eNB.
lac 0 The location area code of UTRAN
neighboring cell to the eNB.
rac 0 The routing area code of UTRAN neighboring
cell to the eNB.
reserved2 0 reserved
mcc0 ‘DIGIT_MCC’ The broadcast PLMN list information (MCC)
of UTRAN neighboring cell to the eNB. It is a
0 to 9.
mnc0 ‘DIGIT_MNC’ The broadcast PLMN list information (MNC)
three-digit or two-digit number with each digit
being from 0 to 9.
mcc1 ‘FFF’ The broadcast PLMN list information (MCC)
0 to 9.
mnc1 ‘FFF’ The broadcast PLMN list information (MNC)
being from 0 to 9.
mcc2 ‘FFF’ The broadcast PLMN list information (MCC)
0 to 9.
mnc2 ‘FFF’ The broadcast PLMN list information (MNC)
being from 0 to 9.

Feature Description
(Continued)
RTRV-NBR- mcc3 ‘FFF’ The broadcast PLMN list information (MCC) of

UTRAN UTRAN neighboring cell to the eNB. It is a three-
CHG-NBR- digit number with each digit being from 0 to 9.
UTRAN mnc3 ‘FFF’ The broadcast PLMN list information (MNC) of
CRTE-NBR- UTRAN neighboring cell to the eNB. It is a three-
UTRAN digit or two-digit number with each digit being
DLT-NBR- from 0 to 9.
UTRAN
mcc4 ‘FFF’ The broadcast PLMN list information (MCC) of
UTRAN neighboring cell to the eNB. It is a three-
digit number with each digit being from 0 to 9.
mnc4 ‘FFF’ The broadcast PLMN list information (MNC) of
digit or two-digit number with each digit being
from 0 to 9.
mcc5 ‘FFF’ The broadcast PLMN list information (MCC) of
mnc5 ‘FFF’ The broadcast PLMN list information (MNC) of
from 0 to 9.
duplexType 0 The broadcast PLMN list information (MNC) of
from 0 to 9.
pScmCode 0 The primary scramble code of UTRAN
neighboring cell to the eNB, which needs only for
FDD.
cellParaId 0 The cell parameter ID of UTRAN neighboring cell
to the eNB, which needs only for TDD.
arfcnUl 0 The uplink absolute radio frequency channel
number (ARFCN) of UTRAN neighboring cell to
the eNB.
arfcnDl 0 The downlink absolute radio frequency channel
number (ARFCN) of UTRAN neighboring cell to
the eNB.
isRemoveAll 1 Whether to delete a certain neighboring cell to
owed the eNB using the ANR (Automatic Neighbor
Relation) function.
- True: The neighboring cell can be deleted.
- False: The neighboring cell cannot be deleted.

Feature Description
(Continued)
RTRV-NBR- isHOAllowed 1 Whether to perform handover to UTRAN

UTRAN neighboring cell.
CHG-NBR- - True: Handover is allowed.
UTRAN - False: Handover is not allowed.
CRTE-NBR- rimStatus 0 This parameter shown RIM Association
UTRAN Status
DLT-NBR-
voipIncapable True Whether to support VoIp of UTRAN
UTRAN
neighboring cell.
- True: VoIP is support.
- False: VoIP is not supported.
rimSupport False Whether to support RIM Procedure of
UTRAN neighbor cell.
- False: RIM is not support.
- True: RIM is support.
ownerType - This parameter defines how NRT is updated,
This filed can be classfied Initial NRT/ANR by
Server/ANR by UE/Created by User
Command/CreatedByUserUI.
highPriorityFo - Whether to decide CSFB_Hysteresis
rCsfb application availability about CSFB with PS
HO

Feature Description
Related Counters
Category Family Name Type Name Description
HO CSFB_PSHO_ CsfbPsHoAttUTRAN CSFB with UTRAN PS handover attempt

UTRAN UTRAN_OUT count
CsfbPsHoPrepSuccUT CSFB with UTRAN PS handover
RAN preparation success count
CsfbPsHoSuccUTRAN CSFB with UTRAN PS handover
execution success count
CsfbPsHoPrepFailUT Preparation fails due to reset notice from
RAN_CP_CC_FAIL ECMB (node failure or block restart) or
ECCB block during the CSFB with
UTRAN PS handover preparation
CsfbPsHoPrepFailUT Preparation fails due to the S1AP
RAN_S1AP_CU_FAIL specification cause during the CSFB with
UTRAN PS handover preparation
CsfbPsHoPrepFailUT Preparation fails due to the S1 SCTP link
RAN_S1AP_LINK_ failure during the CSFB with UTRAN PS
FAIL handover preparation
CsfbPsHoPrepFailUT Preparation fails due to S1AP relocprep
RAN_S1AP_RP_TO timeout (not received) during the CSFB
with UTRAN PS handover preparation
CsfbPsHoPrepFailUT Preparation fails due to receiving S1AP
RAN_S1AP_SIG_FAIL signaling during the CSFB with UTRAN
PS handover preparation
CsfbPsHoFailUTRAN_ A call is released due to call control
CP_CC_TO timeout in the protocol blocks (MAC,
RLC, PDCP, GTP) during the outgoing
inter-frequency handover (measurement
gap assisted) execution.
CsfbPsHoFailUTRAN_ A call is released due to reset notification
CP_CC_FAIL (eNB failure or block restart) from ECMB
or by the ECCB block during the CSFB
with UTRAN PS handover execution.
CsfbPsHoFailUTRAN_ A call is released due to the failure in the
UP_GTP_FAIL GTP block during the CSFB with UTRAN
PS handover execution.
UP_MAC_FAIL MAC block during the CSFB with UTRAN
UP_PDCP_FAIL PDCP block during the CSFB with
UTRAN PS handover execution.

Feature Description
(Continued)
HO CSFB_PSHO_ CsfbPsHoFailUTRAN_ A call is released due to the failure in the

UTRAN UTRAN_OUT UP_RLC_FAIL RLC block during the CSFB with UTRAN
CsfbPsHoFailUTRAN_ A call is released due to receiving RRC
RRC_SIG_FAIL signaling during the CSFB with UTRAN
CsfbPsHoFailUTRAN_ A call is released due to the S1AP
S1AP_CU_FAIL specification cause during the CSFB with
CsfbPsHoFailUTRAN_ A call is released due to the S1 SCTP link
S1AP_LINK_FAIL failure during the CSFB with UTRAN PS
handover execution.
CsfbPsHoFailUTRAN_ A call is released due to the S1AP
S1AP_RO_TO relocoverall timeout (not received) during
the CSFB with UTRAN PS handover
execution.
CsfbPsHoFailUTRAN_ A call is released due to receiving S1AP
S1AP_SIG_FAIL signaling during the CSFB with UTRAN
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SV0201, CMAS
Overview
Introduction
Commercial Mobile Alert Service (CMAS) is a public warning system to notify military
threats, kidnapping, or disasters. CMAS warning notification is composed of multiple short
text messages and they support multiple/concurrent transmission. When an eNB receives
CMAS warning notification from an MME, it uses SIB12 to notify UEs in the notification
areas which has specified by the warning notification provider designated areas.
Benefits
Operator can provide public warning notifications to its subscribers while they are staying
in E-UTRAN.
Users can be notified for public warning messages from network, and then they can avoid
some disasters or accidents.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 Require CMAS capable device
Limitation:
 Need verification test with the supported device, EPC and CBC
Reference
3) 3GPP TS36.413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1

Feature Description
Feature Scope
R1 The eNB supports CMAS based public warning system.
R2 The eNB supports the S1 warning-replace warning procedure to MME for CMAS
warning.
R3 The eNB broadcasts the warning notification to a specified domain using SIB12 upon
receiving a CMAS warning request from MME.
R4 The eNB performs CMAS notification through RRC paging in the case of a CMAS
warning.
R5 The eNB supports the S1 kill procedure to terminate the CMAS warning.
R6 The eNB terminates the CMAS disaster warning upon receiving the request for
CMAS warning termination request from MME.
R7 When receiving the duplicated warning notifications, The eNB detects it through the
message ID and serial number and does not transmit the duplicated warning
notification.
R8 The eNB transmits the ETWS warning according to the specified CMAS warning
schedule.
R9 The eNB supports segmentation of the CMAS warning according to the data volume.

Feature Description
Feature Description
The following figure represents overall operation of the CMAS public alarm system.

Feature Description
The CMAS warning notification transmission procedure is as follows.
1) The CBE (e.g. Information Source such as PSAP or Regulator) sends emergency
information (e.g. ‘warning type’, ‘warning message’, ‘impacted area’, ‘time period’) to
the CBC.
2) Using the ‘impacted area’ information, the CBC identifies which MMEs need to be
contacted and determines the information to be place into the Warning Area
Information Element. Then CBC sends a Write-Replace Warning Request message
containing the warning message to be broadcast and the delivery attributes to MMEs,
i.e. Message identifier, Serial number, Tracking Area list, Warning Area, etc.
3) The MME sends a Write-Replace Warning Response message that indicates to the
CBC that the MME has started to distribute the warning message to eNodeBs.
Then, the CBC may confirm to the CBE.
4) The MME forwards Write-Replace Warning Request message to eNBs. The MME
shall use the Tracking Area list to determine the eNBs in the delivery area.
If the Tracking Area list is empty the message is forwarded to all eNBs that are
connected to the MME.
5) When reception of the Write-Replace Warning Request message from the MMEs, eNB
checks the Message identifier and Serial number fields within the warning message for
duplicate detection. If any redundant messages are detected only the first one received
will be broadcasted by the cells. The eNBs return a Write-Replace Warning Response
message to the MME, even if it was a duplicate.

Feature Description
6) The eNB shall use the Warning Area information to determine the cell(s) in which the
message is to be broadcast. The eNB broadcasts the message frequently according to
the attributes set by the CBC that originated the Warning Message distribution.
During CMAS warning notification, eNB also indicates CMAS warning notification
via Paging.
The CMAS warning notification termination procedures also take place in (1) to (5).
1) The CBE requests stop of emergency broadcast to the CBC.

2) The CBC identifies which MMEs need to be contacted and CBC sends a Stop Warning
Request message to MMEs.
3) The MME sends a Stop Warning Response message that indicates to the CBC that the
MME has started to distribute the warning message to eNodeBs. Then, the CBC may
confirm to the CBE.
4) The MME forwards Kill Request message to eNBs. The MME shall use the Tracking
Area ID list to determine the eNBs that may have warning message broadcast ongoing.
If the Tracking Area ID list is empty the message is forwarded to all eNBs that are
connected to the MME.
5) When reception of the Kill Request message from the MMEs, eNB checks the
Message identifier and Serial number fields within the request message. The eNBs
return a Kill Response message to the MME.
6) The eNB shall stop broadcasting the warning message identified by the Message
identifier and Serial number in the areas identified by Warning Area IDs.
If the Warning Area is absent, it shall be interpreted as all cells on the eNB.

Feature Description
System operation
Command Description
CHG-SIB-INF Changes the System Information Block (SIB) interval of cells. SIB2-SIB12 is
sent as an SI (System Information) message and the mapping information for
SIB and SI messages of SIB2-SIB12 is included in schedulingInfoList of SIB1.
Each SIB is included in its own SI message and SIBs of the same period are
mapped to the same SI message. Multiple SI messages may also be
transmitted in the same period. SIB2 is always mapped to the first SI message
in the SI message list of schedulingInfoList
RTRV-SIB-INF Retrieves the SIB period of the cell. SIB2-SIB12 is sent as an SI (System
Information) message and the mapping information for SIB and SI messages
of SIB2-SIB12 is included in schedulingInfoList of SIB1. Each SIB is included
in its own SI message and SIBs of the same period are mapped to the same SI
message. Multiple SI messages may also be transmitted in the same period.
SIB2 is always mapped to the first SI message in the SI message list of
schedulingInfoList.
CHG-SIB-IDLE Changes the maximum size of the packed SI that can be sent by the cell. It can
be changed only when the cell is in the idle state.This parameter, in order to
apply the changes, CELL_LOCK or forcedModeFlag is set to True.
RTRV-SIB-IDLE Retrieves the max size of the packed SI for transmission in the cell. The size
for SIB information transmission is determined by considering downlink
bandwidth, DCI formation type, SIB reception time at cell edge, and payload
size.
CHG-SIB-INF cellNum 0 The cell number to be changed or

RTRV-SIB-INF retrieved.
sib2Period 1 The transmission period for the
system information block type 2 of
the cell in the eNB.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
- ci_not_used: SIB2 is not sent.

Feature Description
(Continued)
CHG-SIB-INF sib3Period 2 The transmission period for the

RTRV-SIB-INF system information block type 3 of
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
sib5Period enumSibPeriodicity_ The transmission period for the
type_DEFAULT_SIB5 system information block type 5 of
_PERIOD the cell in the eNB.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.

Feature Description
(Continued)
CHG-SIB-INF sib7Period enumSibPeriodicity_ The transmission period for the

RTRV-SIB-INF type_DEFAULT_SIB5 system information block type 7 of
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.

Feature Description
(Continued)
CHG-SIB-INF sib11Period 6 The transmission period for the

RTRV-SIB-INF system information block type 11 of
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
siWindow enumSiWindowLengt The system information window size
h_type_DEFAULT_SI of the cell in the eNB. Each SI
_WINDOW_LENGTH message is related with one SI
window, and does not overlap with
SI windows of other SI messages.
I.e, one SI is sent in each SI window.
All SI messages have the same
window size. Corresponding SI
messages within the SI window are
sent repeatedly. The range is as
follows:
- ci_si_WindowLength_ms1: 1 ms.
WARNING_M - This is the value of Warning
SG_TYPE Message Type

Feature Description
(Continued)
CHG-SIB-INF cellNum 0 The cell number to be changed or

RTRV-SIB-INF retrieved.
maxPackedSi 217 The maximum size of the packed SI
Size for transmission in the cell.
This value takes into account the DL
RB count by bandwidth, maximum
RB count allocated to each SI
message, PDSCH RE count for each
RB, payload size of DCI Format 1A,
max aggregation level and PDCCH
coderate. Recommend values are 9
for 1.4 MB (i.e. mega bytes); 26 for 3
MB; 49 for 5 MB; 97 for 10 MB; 141
for 15 MB; 217 for 20 MB.
forcedMode 0 This parameter defines forced mode
for changed value.
CHG-SIB-INF cellNum It is the cell number transmitting CMAS.

RTRV-SIB-INF sib12Period It is a transmission period of CMAS SIB12 of the cell.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
CHG-SIB-IDLE cellNum It is the cell number transmitting CMAS.
RTRV-SIB-IDLE maxPackedSi It is the maximum size of the warning message segment.
Size The value is determined with consideration to the number of
DL RBs for each bandwidth, the maximum number of RBs to
be allocated to an SI message, the number of PDSCH REs
per RB, payload size of DCI format 1A, max aggregation
level, and PDCCH Coderate.
The recommended value is 9 byte for 1.4 M, 26 byte for 3 M,
49 byte for 5 M, 97 byte for 10 M, 141 byte for 15 M, and 217
byte for 20 M.
Range: 0-217 init: 217

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SV0202, ETWS
Overview
Introduction
Earthquake and Tsunami Warning System (ETWS) is a public warning system to notify
earthquake and/or tsunami events. ETWS warning notification can be either a primary
notification (short notifications delivered within 4 seconds) or secondary notification
(providing detailed information). When an eNB receives ETWS warning notification from
an MME, it uses SIB10 or SIB11 to notify UEs in the notification areas which has specified
by the warning notification provider.
Benefits
Operator can provide public warning notifications to its subscribers while they are staying
in E-UTRAN.
Users can be notified for public warning messages from network, and then they can avoid
some disasters or accidents.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 Require ETWS capable device
Limitation:
Reference

Feature Description
Feature Scope
R1 The eNB supports the ETWS based public warning system.
R2 The eNB supports the S1 warning-replace warning procedure with MME for ETWS
warning.
R3 Upon receiving an ETWS warning request from MME, the eNB broadcasts the
primary notification to a specified domain using SIB10.
 Primary notification: It is a warning that notifies of emergency disaster such as
earthquake and tsunami, and must be transmitted within 4 seconds.
R4 Upon receiving an ETWS warning request from MME, the eNB broadcasts the
secondary notification to a specified domain using SIB11.
 Secondary notification: It is the detailed information of what to do in case of the
emergency disaster situation and contains the information such as the evacuation
path and relevant agencies.
R5 The eNB performs the ETWS notification through RRC paging in case of ETWS
warning.
R6 When receiving the duplicated warning notifications, the eNB detects it by the
message ID and serial number and does not transmit the duplicated warning
notification.
R7 The eNB transmits the ETWS warning according to the specified ETWS warning
schedule.
R8 The eNB supports segmentation of the ETWS warning according to the data volume.

Feature Description
Feature Description
The following figure represents overall operation of the ETWS public alarm system.

Feature Description
The ETWS warning notification transmission procedures are shown as follows.
1) The CBE (e.g. Information Source such as PSAP or Regulator) sends emergency
information (e.g. ‘warning type’, ‘warning message’, ‘impacted area’, ‘time period’) to
the CBC.
2) Using the ‘impacted area’ information, the CBC identifies which MMEs need to be
contacted and determines the information to be place into the Warning Area
Information Element. Then CBC sends a Write-Replace Warning Request message
containing the warning message to be broadcast and the delivery attributes to MMEs,
i.e. Message identifier, Serial number, Tracking Area list, Warning Area, etc.
3) The MME sends a Write-Replace Warning Response message that indicates to the
CBC that the MME has started to distribute the warning message to eNodeBs.
Then, the CBC may confirm to the CBE.
4) The MME forwards Write-Replace Warning Request message to eNBs. The MME
shall use the Tracking Area list to determine the eNBs in the delivery area. If the
Tracking Area list is empty the message is forwarded to all eNBs that are connected to
the MME.
5) When reception of the Write-Replace Warning Request message from the MMEs, eNB
checks the Message identifier and Serial number fields within the warning message for
duplicate detection. If any redundant messages are detected only the first one received
will be broadcasted by the cells. The eNBs return a Write-Replace Warning Response
message to the MME, even if it was a duplicate.

Feature Description
6) The eNB shall use the Warning Area information to determine the cell(s) in which the
message is to be broadcast. The eNB broadcasts the message frequently according to
the attributes set by the CBC that originated the Warning Message distribution.
During ETWS warning notification, eNB also indicates ETWS warning notification
via Paging.

Feature Description
System operation
CHG-SIB-INF cellNum This is the number of cells to which ETWS is transmitted.

RTRV-SIB-INF sib10Period This is the transmission period to ETWS Primary Notification
SIB10 of a cell.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
sib11Period This is the transmission period to ETWS Secondary Notification
SIB11 of a cell.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
CHG-SIB-IDLE cellNum This is the number of cells to which ETWS is transmitted.
RTRV-SIB- maxPackedSi This is the maximum size of a warning message segment.
IDLE Size The value is set by considering the number of DL RB for each
bandwidth, the maximum number of RBs assigned to one SI
message, the number of PDSCH RE for each RB, the payload
size of DCI format 1A, maximum aggregation level and PDCCH
code rate.
For 1.4M, 9 bytes, for 3M, 26 bytes, for 5M, 49 bytes, for 10M,
97 bytes, for 15M, 141 bytes, and for 20M, 217 bytes are
recommended.
range:0~217 init:217
Related Counters
N/A
Related KPI/PI
N/A

Feature Description
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SV0301 A-GNSS (LPP)

Overview
A-GNSS (Assisted Global Navigation Satellite Systems) is to improve the performance of
standalone GNSS by assistance from the network.
Introduction
GNSS refers to various satellite systems such as GPS (Global Positioning System) and
GLONASS (Global Orbiting Navigation Satellite System). The traditional standalone
GNSS receiver in the mobile device is solely responsible for receiving GNSS signals and
estimating its position. The receiver needs to acquire GNSS signals through a search
process which can take up to several minutes. For example, if the UE is in an indoor area or
surrounded by tall buildings, it takes long time to search satellites (usually need to find 3 or
4 satellites) or even fails to detect the satellite signal.
The E-SMLC provides ‘Assistance Data’ (which names this feature as ‘A’-GNSS) to the
UE so that the GNSS receiver can expedite the GNSS signal acquisition process.
A-GNSS speeds up positioning performance and helps to save battery power.
The protocol for the delivery of Assistance Data between E-SMLC and UE is called LPP
(LTE Positioning Protocol).
Benefits
Operator Benefits:
 Provides location based services to their subscribers with a faster positioning feature.
End User Benefits:

 Faster positioning and battery power saving.
Release History
SLR2.2

Dependency:
 Supported by Release9 UE.
 Supported by UE with the GNSS receiver.
Limitation:
 None

Feature Description
Reference
2) 3GPP TS36.305 Evolved Universal Terrestrial Radio Access (E-UTRA); LTE
Positioning Protocol (LPP)

Feature Description
Feature Description
The E-SMLC sends ‘Assistance Data’ to the UE by LPP messages so that the GNSS
receiver can acquire the GNSS signal fast. These LPP messages are carried as transparent
PDUs across intermediate network interfaces using the appropriate protocols (e.g. S1-AP
over the S1-MME interface, NAS/RRC over the Uu interface).
The Assistance Data can be one or more of the followings:

 Acquisition Assistance Data
 Sensitivity Assistance Data
 Difference Correction

Feature Description
System Operation
How to Enable/Disable or Configure
N/A
Counter and KPI

N/A
Related Alarm
N/A
Related Status
N/A
Related Call Fault

N/A

Feature Description
LTE-SV0302, Enhanced Cell ID

Overview
Enhanced Cell ID (shortly E-CID) provides more accurate estimation of UE position
through the use of Cell ID and radio parameters such as RSRP (Reference Signal Received
Power) and TA (Timing Advance).
Introduction
This feature improves the accuracy in location estimation compared to the traditional Cell
ID method in 3G networks.
The Enhanced Cell ID (E-CID) method utilizes the following information:
UE Measurements
 RSRP: Reference Signal Received Power
 RSRQ: Reference Signal Received Quality
 UE Rx-Tx time difference
eNB Measurements
 eNB Rx-Tx time difference
 Timing Advance
 Angle of Arrival
Benefits
Operator Benefits:
 Operator can improve the accuracy of location based services.
End User Benefits:

 End users can enjoy more accurate location based services such as maps and
navigations.
Release History
SLR2.2

Feature Description

Dependency:
 Supported by Release-9 UE
 The interaction between eNB and E-SMLC is based on LPPa protocol
Limitation:
 Release-9 UE
 Triggered by the E-SMLC
Feature Scope
It provides the LPPa signaling function by receiving the request message related to location
positioning from the E-SMLC server and transmitting the response message to the E-
SMLC including information about the UE or eNB that the E-SMLC needs.

Feature Description
Feature Description
E-CID consists of the following messages.
E-CID Measurement Initiation Request/Response/Failure
E-CID Measurement Report
E-CID Measurement Failure Indication/Termination
The E-CID measurement initiation function is a procedure that the E-SMLC requests the E-
CID measurement result from the eNB to calculate the position of the UE.
The eNB operates as follows depending on the contents of the E-CID measurement
initiation request message transmitted by the E-SMLC.
1) If the value of the report characteristics is on demand: Transmits the E-CID

MEASUREMENT INITIATION RESPONSE message (and the measurement result)
including the requested value.
2) If the value of the report characteristics is periodic: Starts the periodic report timer and
transmits the E-CID MEASUREMENT INITIATION RESPONSE message (excluding
the measurement result).
Then transmits the periodic E-CID measurement report to the E-SMLC.
The E-CID measurement results include the following information.

 E-UTRAN Access Point Position (O)
 Measured Result (M)
− Angle of Arrival: INTEGER (0..719)
− Timing Advance Type 1, 2: INTEGER (0..7690)
− RSRP: PCI, EARFCN, ECGI
− RSRQ: PCI, EARFCN, ECGI

Feature Description
System operation
Related Commands
Command Description
RTRV-POS-CONF - Retrieves parameters required for UE positioning.

- UE positioning has two ways: E-CID and OTDOA.
- Both of methods can view the current parameter among
information included in the UE positioning
measurement.
CHG-POS-CONF - Changes parameters required for UE positioning.
- Both of methods can change the current parameter
among information included in the UE positioning
measurement.
Related System Parameters

Command Parameter Default value Description
RTRV-POS- cellNum 0 The cell number for which the
CONF command was executed.
CHG-POS- autoGpsSetFlag 0 - If this flag value is 1, latitude,
CONF longitude, height value updated by
using GPS.
- If this flag value is 0, latitude,
longitude, height value defiined by
operator.
latitude[20] ‘N 000:00:00.000’ - The latitude of the cell for providing
the OTDOA function.
- The UE location information
included in the cell can be
calculated using the latitude value.
longitude[20] ‘E 000:00:00.000’ - The longitude of the cell for
providing the OTDOA function.
calculated using the longitude
value.
height[20] ‘0000.00m’ - The altitude of the cell for providing
the OTDOA function.
calculated using the altitude value.

Feature Description
(Continued)

CHG-POS- uncertaintySemiMajor 0 - The uncertainty of semi major.
CONF - The uncertainty, which the user enters
directly.
- It can be calculated by a formula of r =
10 * (1.1k-1).
uncertaintySemiMinor 0 The uncertainty of semi minor.
The uncertainty, which the user enters
directly.
It can be calculated by a formula of
r = 10 * (1.1k-1).
orientationOfMajorAxis 0 The orientation of the major axis, which
the user directly enters the value chosen
from 0 to 179.
uncertaintyAltitude 0 The uncertainty of altitude tolerance,
which the user enters directly. It can be
calculated by using a formula of
h = 45 * (1.025k-1).
confidence 0 The confidence (%) of location service.
measurementInterval 0 - The value used when the measured
periodicity included in E-CID
measurement initiation request is
periodic.
- The interval at which MRs are received
when eNB receives MR from the UE
periodically.
- This value can be changed by the user,
which is a different value from the
interval used in eNB.
prsConfigIndex 1131 - PRS configuration index.
- If the user enters a value, eNB sends
the value to MAC layer.
numOfDlFrame 0 - The number of downlink frames.
prsMutingConfigSize 2 - PRS muting configuration size.
prsMutingConfigValue 255 - PRS muting configuration.
prsBandwidth 3 - PRS Bandwidth.
otdoaEnable 0 - OTDOA function On/Off.
- If this parameter set 0, OTDOA service
is off and also PRS signaling is off.

Feature Description

N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SV0303, OTDOA
Overview
OTDOA (Observed Time Difference of Arrival) is to estimate UE position by the time
difference of arrival of PRS (Positioning Reference Signal) from two or more base stations.
Introduction
In the OTDOA positioning method, UE makes an observation of the time difference of
arrival of RS (reference signal) from two or more eNBs. Then, the position of UE can be
calculated based on known position of eNBs and time differences.
In LTE, the time difference between RS from serving cell and neighbor cells is called
RSTD (Reference Signal Time Difference). In order to measure RS from (probably far
away) neighbor cells, special positioning signal is defined in Release 9 and called PRS
(Positioning Reference Signal).
Benefits
Operator Benefits:
 Operator can improve the accuracy of location based services.
End User Benefits:

 End users can enjoy more accurate location based services such as maps and
navigations.
Release History
SLR2.2

Dependency:
 Supported by Release-9 UE
 The interaction between eNB and E-SMLC is based on LPPa protocol.
Limitation:
 Release-9 UE
 Triggered by E-SMLC

Feature Description
Reference
2) 3GPP TS36.455 Evolved Universal Terrestrial Radio Access (E-UTRA); LTE
Positioning Protocol A (LPPa)
Feature Scope
After receiving the request message related to location positioning from the E-SMLC
server and it provides the LPPa Signaling function by transmitting response message
(containing the UE or eNB information that E-SMLC needs) to E-SMLC.

Feature Description
Feature Description
The OTDOA information transfer function is a procedure that the E-SMLC requests and
receives the OTDOA information from the eNB.
The procedure consists of the following messages.

OTDOA Information Request/Response/Failure
After the eNB receives the OTDOA information request message from the E-SMLC, the
OTDOA information transfer function performs according to reception of the requested
information and it performs as follows.
1) If it received OTDOA cell information: It transmits the OTDOA INFORMATION

RESPONSE message including the ODTOA cell information.
2) If it fails to receive OTDOA cell information: It transmits OTDOA INFORMATION
FAILURE message including the cause (value) of the failure.
OTDOA Cell Information

 EARFCN (M)
 PRS Bandwidth (M)
 PRS Configuration Index (M)
 CP Length (M)
 # of DL Frames (M)
 # of Antenna Ports (M)
 SFN Initialization Time (M)
 E-UTRAN Access Point Position (M)
− Direction of Altitude
− Altitude
− Uncertainty semi-major
− Uncertainty semi-minor
− Orientation of major axis
− Uncertainty Altitude
− Confidence
 PRS Muting Configuration (M)

Feature Description
System Operation
Related Commands
Command Description
RTRV-POS-CONF - Retrieves parameters required for UE positioning.

- Both of methods can view the current parameter among information
included in the UE positioning measurement.
CHG-POS-CONF - Changes parameters required for UE positioning.
- Both of methods can change the current parameter among information
included in the UE positioning measurement.

RTRV-POS-CONF cellNum 0 The cell number for which the

CHG-POS-CONF command was executed.
autoGpsSetFlag 0 - If this flag value is 1, latitude,
longitude, height value updated
by using GPS.
- If this flag value is 0, latitude,
longitude, height value defiined
by operator.
latitude[20] ‘N 000:00:00.000’ - The latitude of the cell for
calculated using the latitude value.
longitude[20] ‘E 000:00:00.000’ - The longitude of the cell for
calculated using the longitude
value.
height[20] ‘0000.00m’ - The altitude of the cell for
calculated using the altitude value.

Feature Description
(Continued)
RTRV-POS-CONF uncertaintySemiM 0 - The uncertainty of semi major.

CHG-POS-CONF ajor - The uncertainty, which the user
enters directly.
- It can be calculated by a formula
of r = 10 * (1.1k-1).
uncertaintySemiMi 0 - The uncertainty of semi minor.
nor - The uncertainty, which the user
enters directly.
- It can be calculated by a formula
of r = 10 * (1.1k-1).
orientationOfMajor 0 The orientation of the major axis,
Axis which the user directly enters the
value chosen from 0 to 179.
uncertaintyAltitude 0 The uncertainty of altitude tolerance,
which the user enters directly. It can
be calculated by using a formula of
h = 45 * (1.025k-1).
confidence 0 The confidence (%) of location
service.
measurementInter 0 - The value used when the
val measured periodicity included in
E-CID measurement initiation
request is periodic.
- The interval at which MRs are
received when eNB receives MR
from the UE periodically.
- This value can be changed by the
user, which is a different value
from the interval used in eNB.
prsConfigIndex 1131 - PRS configuration index.
- If the user enters a value, eNB
sends the value to MAC layer.
numOfDlFrame 0 - The number of downlink frames.
- If the user enters a value, eNB
prsMutingConfigSi 2 - PRS muting configuration size.
ze - If the user enters a value, eNB
prsMutingConfigV 255 - PRS muting configuration.
alue - If the user enters a value, eNB

Feature Description
(Continued)
RTRV-POS-CONF prsBandwidth 3 - PRS Bandwidth.

CHG-POS-CONF - If the user enters a value, eNB
otdoaEnable 0 - OTDOA function On/Off.
- If this parameter set 0, OTDOA
service is off and also PRS
signaling is off.

N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW0101, Support for UE Category 1, 2, 3, and

4
Overview
Introduction
eNB supports UE Category 1, 2, 3, and 4, which are defined in 3GPP TS33.306.
Different UE categories define different UE capability in terms on throughput. eNB has no
limitation on supporting UE category 1, 2, 3, and 4, which have up to two layers downlink
and do not support uplink 64QAM. UE Category 1 supports SISO and UE Category 2, 3,
and 4 supports 2x2 MIMO.
Benefits
 eNB supports different device types that are capable of DL 2x2 MIMO, 2RX diversity,
or SISO.
 UE can improve downlink throughput if it supports DL 2x2 MIMO.
Release History
SLR2.2

Dependency
 No dependency
Limitation
 No limitation
Reference
1) 3GPP TS36.306 Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) radio access capabilities
Feature Scope
R1 eNB allows the access of UE Category 1, 2, 3, and 4.
R2 eNB supports SISO for UE Category1.
R3 eNB supports DL 2x2 MIMO for UE Category 2, 3, and 4

Feature Description
Feature Description
Following table explains DL throughput and the number of downlink layers per UE
Category, which are defined in 3GPP TS36.306 Rel9 version.
Maximum number Maximum number

Total Maximum number
of DL-SCH of bits of a DL-SCH
UE number of of supported
transport block bits transport block
Category soft layers for spatial
received within a received within a
channel bits multiplexing in DL
TTI TTI
Category 1 10296 10296 250368 1
Category 2 51024 51024 1237248 2
Category 3 102048 75376 1237248 2
Category 4 150752 75376 1827072 2
Category 5 299552 149776 3667200 4
Following table explains UL throughput and 64QAM support per UE Category, which are
defined in 3GPP TS36.306 Rel9 version.
UE Maximum number of bits of an UL-SCH transport block Support for

Category transmitted within a TTI 64QAM in UL
Category 1 5160 No
Category 2 25456 No
Category 3 51024 No
Category 4 51024 No
Category 5 75376 Yes

Feature Description
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW0111, UE Counting per Category

Overview
Introduction
The eNB performs counting for each category of RRC_Connected UE and collects the
statistics per eNB.
Benefits
 Operator Benefits
− UE Counting per category helps to analysis connected UEs' status per category.
 End User Benefits
− None
Release History
SLR2.4

Dependency
 No dependency
Limitation
 This statistics collection is impossible if the eNB cannot acquire UE category
information from the MME during idle to active transition.
 If a time-out occurs because the UE does not transmit ATTACH COMPLETE, the
statistics is counted but the UE context release may be performed in the MME.
Reference
1) The Vendor’s LTE solution shall support functionality to enquire UE capability and
record number of UEs per eNodeB and per cell for each UE category.
Equipment (UE) radio access capabilities(Release 9)
4) 3GPP TS36.331 Evolved Universal Terrestrial Radio Access (E-UTRA);Radio
Resource Control (RRC);Protocol specification(Release 9)
Feature Scope
R1 During ATTACH procedure, the call processing block must perform UE category

Feature Description
decoding (Event-driven collection) after receiving the UE Capability Information

message from the UE.
R2 During Idle to Active procedure, the call processing block must perform UE category
decoding (Event-driven collection) after receiving the Initial Context Setup Response
message from the MME.
R3 Performs accumulated count per category.
R4 Creates 15 min. statistics based on the accumulated count (5 min. for domestic service
providers or specific service providers).
R5 The PM block transmits the created statistics to the LSM.

Feature Description
Feature Description
As shown below, the eNB can obtain the UE category information during attachment or
idle to active transition.
During ATTACH procedure

Saves UE category during UE Capability Enquiry / UE Capability Information procedure
and counts the statistics after ATTACH procedure is finished.
eNB MME
Attach Procedure
UE Capability Enquiry
UE Capability Information
UE Category
Save
Attach Complete
Statistics Count

Feature Description
During Idle to Active procedure,

Saves UE category during Initial Context Setup Request / Initial Context Setup Response
procedure and counts the statistics after ATTACH is finished.
eNB MME
Idle to Active Procedure
Initial UE Message
Initial Context Setup Request
UE Category
Save
Initial Context Setup Response
Idle to Active Complete
Statistics Count

Feature Description
System operation
N/A
Related Counters
Counter Description How to Check
UE_Category_1 Number of UEs in the UE Category 1 -

- In the 3GPP Release9, UE Category has the range from 1 to 5 (SLR2.4).

- In the 3GPP Release10, UE Category has the range from 1 to 8 (SLR3.x).
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW0301, MIB & SIB Broadcast (SIB1-4)

Overview
Introduction
eNB broadcasts MIB and SIB type 1, type 2, type 3 and type 4 for PLMN selection, cell
selection and intra-frequency cell reselection.
Benefits
User can perform PLMN selection and cell selection, then access to a cell within E-
UTRAN. Also they can perform intra-frequency cell reselection.
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference
3) 3GPP TS36. 304 Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) procedures in idle mode

Feature Description
Feature Scope
[MIB]
R1 The eNB transmits the downlink bandwidth, PHICH configuration and system frame
number (upper 8 bits) via the MIB.
R2 The eNB allows the operator to configure, modify, and retrieve the MIB.
R3 The eNB transmit the MIB according to the MIB scheduling cycle.
[SIB1]
R1 The eNB transmits information necessary for the PLMN and cell selection of the
idling UE via the SIB1.
R2 The eNB allows the operator to configure, modify, and retrieve the SIB1.
R3 The eNB transmits the SIB1 according to the SIB1 scheduling cycle.
[SIB2]
R1 The eNB transmits the information necessary for resource configuration and access
barring control of the idling UE via the SIB2.
R3 The eNB transmits the SIB2 according to the predetermined cycle.
[SIB3]
R1 The eNB transmits information necessary for the cell reselection operation of the UE
via the SIB3.
[SIB4]
R1 The eNB transmits the intra-frequency neighboring cell information of the UE via the
SIB4.

Feature Description
Feature Description
In idle mode, the UE receives the system information broadcast by the cell it has camped
onto. The system information is used for UE performing idle mode procedure.
System information is divided into the Master Information Block (MIB) and a number of
System Information Blocks (SIBs).
Idle UE shall receive MIB, SIB1 and SIB2 in LTE area and SIB3 and SIB4 are required for
intra-frequency cell reselection.
The parameters broadcasted in MIB, SIB1, SIB2, SIB3 and SIB4 are as follows.
MIB conveys downlink bandwidth, PHICH configuration and the eight most significant
bits of system frame number. UE uses these to acquire other information from the cell.
SIB1 conveys information that is needed when evaluating if a UE is allowed to access a

cell. UE uses this for PLMN selection and cell selection. Also SIB1 defines the scheduling
of other system information. UE acquires other SIBs of the cell using this information.
 Cell Access related information (supported PLMN IDs, cell identity, TAC, …)
 Threshold values for cell reselection
 Frequency band indicator
 Scheduling information for other SIs
 SI change indicator
SIB2 conveys radio resource configuration information that is common for all UEs and
access barring information.
 AC-barring information for emergency/mo-signaling/mo-data
 Service specific AC-barring information
 Common radio resource configuration for all UEs
 Timers and constants which shall be used by UE
 Uplink frequency information
SIB3 conveys the common information for intra-frequency, inter-frequency and/ or inter-
RAT cell reselection. SIB3 also conveys the specific information for intra-frequency cell
reselection.
 Hysteresis
 Hysteresis for speed dependant cell reselection
 Common threshold values for cell reselection
 Mobility state parameters for spee
 Cell reselection priority for serving carrier frequency

Feature Description
 Threshold values for intra-frequency cell reselection

 Cell reselection timer for intra-frequency cell reselection
 Cell reselection timer for speed dependant intra-frequency cell reselection
SIB4 conveys the intra-frequency neighbouring cell related information, i.e. intra-
frequency neighbour cell list and blacklisted cells.
 Intra-frequency neighbour cell list
 Intra-frequency blacklisted cells
 Set of physical cell identities reserved for CSG cells on the serving carrier frequency

Feature Description
System operation
CHG-CELL-IDLE cellNum The cell number to be changed or retrieved.

RTRV-CELL-IDLE dlBandwidth Downlink bandwidth used by the active cell.
- ci_SystemBandwidth_n6: 1.4 MHz bandwidth that uses
6 physical resource blocks.
- ci_SystemBandwidth_n15: 3 MHz bandwidth that uses
15 physical resource blocks.
- ci_SystemBandwidth_n25: 5 MHz bandwidth using 25
physical RBs.
physical RBs.
physical RBs.
- ci_SystemBandwidth_n100: 20 MHz bandwidth using
100 physical RBs.
CHG-PHICH-IDLE cellNum The cell number to be changed or retrieved.
RTRV-PHICH-IDLE phichDuration The PHICH duration set in accordance of TS 36.211.
It sets the lower limit of a control region size that is
passed to PCFICH.
- ci_normal
- ci_extended
phichResource The parameter used to calculate the number of PHICH
groups.
- ci_oneSixth
- ci_half
- ci_one
- ci_two
CHG-SIB-INF cellNum The cell number to be changed or retrieved.
RTRV-SIB-INF sib2Period The transmission period for the system information block
type 2 of the cell in the eNB.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.

Feature Description
(Continued)
CHG-SIB-INF Sib3Period The transmission period for the system information block
RTRV-SIB-INF type 3 of the cell in the eNB.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
Sib4Period The transmission period for the system information block
type 4 of the cell in the eNB.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
siWindow The system information window size of the cell in the
eNB.
Each SI message is related with one SI window, and
does not overlap with SI windows of other SI messages.
I.e. one SI is sent in each SI window. All SI messages
have the same window size. Corresponding SI messages
within the SI window are sent repeatedly.
The range is as follows:
Related Counters
N/A
Related KPI/PI
N/A

Feature Description
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW0305, SIB Broadcast (SIB5)

Overview
Introduction
eNB broadcasts SIB type 5 for inter-frequency cell reselection.
Benefits
User can perform inter-frequency cell reselection.
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference
Feature Scope
R1 The eNB transmits the information required for the inter-frequency cell reselection
operation via the SIB5.

Feature Description
Feature Description
In idle mode, the UE receives the SIB5 (System Information Block type 5) broadcast by the
cell it has camped onto. SIB5 is used for UE performing idle mode procedure for inter-
frequency cell reselection. SIB5 includes the neighbouring carrier frequencies and the
related thresholds for cell reselection towards inter-frequency cells. SIB5 also includes the
inter-frequency neighbouring cell related information, i.e. inter-frequency neighbour cell
list and blacklisted cells.
SIB5 conveys the information for inter-frequency cell reselection.

 Neighbouring downlink carrier frequency
 Cell reselection priority per carrier frequency
 Threshold values per carrier frequency
− q-OffsetFreq
− threshX-High (R8, RSRP)
− threshX-HighQ (R9, RSRQ)
− threshX-Low (R8, RSRP)
− threshX-LowQ (R9, RSRQ)
− q-RxLevMin (R8, RSRP)
− q-QualMin (R9, RSRQ)
− p-Max
 allowedMeasBandwidth
 presenceAntennaPort1
 neighCellConfig
 Inter-frequency neighbour cell list per carrier frequency
 Inter-frequency blacklisted cells per carrier frequency
 Cell reselection timer per carrier frequency
 Cell reselection timer for speed dependant inter-frequency cell reselection

Feature Description
System operation
Command Description
RTRV-EUTRA- Retrieves parameters required to operate priority information on EUTRA FA.

FA If the Cell Num parameter is entered, the EUTRA FA registered to the
corresponding cell is retrieved. If not, the EUTRA FA information registered to
all cells is retrieved.
CHG-EUTRA- Changes the parameter values required to operate the EUTRA FA Priority
FA Information. When the Cell Num and fa Index parameter values are set as input
values, the EUTRA FA information registered to the specified cell in the eNB
can be changed.

PLDEutraFaPrio cellNum 0 The cell number to be changed.

rInfoFunc faIndex 0 EUTRA frequency index. Up to 8 FAs can be
assigned per cell.
status 1 Whether the EUTRA FA is valid.
- N_EQUIP: Invalid.
- EQUIP: Valid.
earfcnUl EARFCN_UL Uplink E-UTRA Absolute Radio Frequency
Channel Number.
earfcnDl EARFCN_DL Downlink E-UTRA Absolute Radio Frequency
Channel Number.
priority 7 Priority of EUTRA FA.
qRxLevMin qRxLevMin_ The minimum RX level required in a cell in
DEFAULT_ dBm units.
EUTRA_FA_
Q_RX_LEV_
MIN
pMaxUsage 1 Whether to use pMax.
- CI_no_use: pMax value is not used.
pMax 0 The maximum TX power level in the UE.
tReselection 1 Reselection timer value.

Feature Description
(Continued)
PLDEutraFaPrio sfUsage 0 Whether to use scaling factors.

rInfoFunc - CI_no_use: T_RESELECTION_SF_
MEDIUM and T_RESELECTION_SF_HIGH
values are not used.
- CI_use: T_RESELECTION_SF_MEDIUM
and T_RESELECTION_SF_HIGH values
are used.
tReselection enumSpeedSc The medium timer value of the reselection
SfMedium aling_type_DE scaling factors.
FAULT_TRES
ELECT_SF_M
EDIUM
tReselection enumSpeedSc The high timer value of the reselection scaling
SfHigh aling_type_DE factors.
FAULT_TRES
ELECT_SF_HI
GH
sIntraSearch 1 Whether to use sIntraSearch.
Usage - CI_no_use: sIntraSearch is not used.
sIntraSearch sIntraSearch_ The threshold for intra-frequency
DEFAULT_EU measurement.
TRA_FA_S_IN
TRA_SEARCH
sNonIntraSe 1 Whether to use sNonIntraSearch.
archUsage - CI_no_use: sNonIntraSearch is not used.
sNonIntraSe sNonIntraSear The threshold for inter-RAT and intra-
arch ch_DEFAULT_ frequency measurement.
EUTRA_FA_S
_NON_INTRA
_SEARCH
threshServin threshServingL The low threshold for serving frequency
gLow ow_DEFAULT during reselection evaluation.
_EUTRA_FA_
THRESH_SER
VING_LOW
threshXhigh 31 The threshold used in the UE to reselect a
frequency whose priority is higher than the
current camped frequency.
threshXLow 31 The threshold used to reselect low-priority
frequency from high-priority frequency.

Feature Description
(Continued)
PLDEutraFaP mesaBandwidth 1 Whether to use measurementBandwidth.

riorInfoFunc Usage - CI_no_use: measurementBandwidth is not
used.
measurementB measBandwidt The maximum measurement bandwidth
andwidth h_type_DEFA allowed for carrier frequency.
ULT_EUTRA_
FA_MEASURE
MENT_BAND
WIDTH
presenceAntPor BOOL_DEFAU Whether Antenna Port1 exists.
t1 LT_EUTRA_F - False: Antenna Port1 does not exist.
A_PRESENCE - True: Antenna Port1 exists.
_ANT_PORT1
neighCellConfig 1 The neighboring cell settings.
qOffsetFreq 15 Frequency offset value applied to q-
OffsetFreq in SIB5.
offsetFreq 15 Frequency offset value applied to offsetFreq
in RRC Connection Reconfiguration.
sIntraSearchRel 0 Whether to use the sIntraSearch for Rel-9.
9Usage - CI_no_use: sIntraSearch is not used.
sIntraSearchP 31 The threshold P for an intra-frequency
measurement in Rel-9.
sIntraSearchQ 31 The threshold Q for an intra-frequency
measurement in Rel-9.
sNonIntraSearc 0 Whether to use sNonIntraSearch for Rel-9.
hRel9Usage - CI_no_use: sNonIntraSearch is not used.
sNonIntraSearc 31 The threshold P for inter-RAT and an intra-
hP frequency measurement.
sNonIntraSearc 31 The threshold Q for inter-RAT and an intra-
hQ frequency measurement.
qQualMinRel9U 0 Whether to use the qQualMin for Rel-9.
sage - CI_no_use: SqQualMin is not used.
qQualMinRel9 -3 qQualMin value for Rel-9.

Feature Description
(Continued)
PLDEutraFaPrio threshServin 0 Whether to use the threshServingLowQ for

rInfoFunc gLowQRel9 Rel-9.
Usage - CI_no_use: threshServingLowQ is not used.
threshServin 31 threshServingLowQ value for Rel-9.
gLowQRel9
QRel9 frequency whose priority is higher than the
current camped frequency in Rel-9.
QRel9 frequency from high-priority frequency in Rel-9.
mcc0[4] ‘DIGIT_MCC’ Mobile Country Code (MCC) that comprises
Public Land Mobile Network (PLMN). FA have
the Preference of Preference0 for PLMN #0
mnc0[4] ‘DIGIT_MNC’ MNC that comprises PLMN.FA have the
preference0 preferred_pref Preference of PLMN #0 for FA.
er
mcc1[4] ‘FFF’ Mobile Country Code (MCC) that comprises
mnc1[4] ‘FFF’ MNC that comprises PLMN.FA have the
preference1 not_allowed_p Preference of PLMN #1 for FA.
refer
refer
refer

Feature Description
(Continued)
PLDEutraFaPrio mcc4[4] ‘FFF’ Mobile Country Code (MCC) that comprises

rInfoFunc Public Land Mobile Network (PLMN). FA have
refer
refer
anrUeSearch 100.0 The Searching Rate of UE which performs the
Rate ANR measurement for the corresponding
carrier index.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description

Overview
Introduction
eNB broadcasts SIB type 6 for cell reselection to UTRAN.
Benefits
User can perform cell reselection from E-UTRAN to UTRAN.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 None
Limitation:
 None
Reference
Feature Scope
R1 The eNB transmits the information required for the UTRANS cell reselection
operation via the SIB6.

Feature Description
Feature Description
cell it has camped onto. SIB6 is used for UE performing idle mode procedure for inter-RAT
cell reselection to UTRAN. SIB6 includes the neighbouring carrier frequencies (FDD or
TDD) and the related thresholds for cell reselection towards UTRA cells
UTRAN cell reselection parameters

 UTRA (FDD or TDD) carrier frequency list
 Cell reselection priority per UTRA (FDD or TDD) carrier frequency
 Cell reselection thresholds per UTRA (FDD or TDD) carrier frequency
 Cell reselection timer for UTRAN cell reselection
 Cell reselection timer for speed dependant UTRAN cell reselection

Feature Description
System operation
Command Description
RTRV-UTRA-FA Retrieves priority of UTRA FA. If the CELL_NUM and FA_INDEX parameters
are entered, the information only for the UTRAN FA object registered to the
corresponding E-UTRAN served cell is retrieved. If not, the information for all
UTRAN FA objects is retrieved.
CHG-UTRA-FA Changes the UTRA FA priority information. When the Cell Num and fa Index
parameter values are set as input values, the UTRAN FA information registered
to the specified cell in the eNB can be changed.

PLDUtraFaPrior cellNum 0 The cell number to be changed.

InfoFunc faIndex 0 The cell number to be changed.
status ConfStatus_DEFAULT_ Whether the EUTRA FA is valid.
UTRA_FA_STATUS - N_EQUIP: Invalid.
- EQUIP: Valid.
duplexType 0 The duplex mode information on a
cell. Enter either FDD or TDD.
- ci_FDD: Frequency division duplex.
- ci_TDD: Time division duplex.
uarfcnUl uarfcnUl_DEFAULT_U Uplink UTRA Absolute Radio
TRA_FA_UARFCN_UL Frequency Channel Number.
uarfcnDl uarfcnDl_DEFAULT_U Downlink UTRA Absolute Radio
TRA_FA_UARFCN_DL Frequency Channel Number.
priority 4 Priority information on the UTRA FA.
threshXhigh 0 The threshold used in the UE to
reselect a frequency whose priority is
higher than the current camped
frequency.
threshXLow 0 The threshold used to reselect low-
priority frequency from high-priority
frequency.
qRxLevMin qRxLevMin_DEFAULT The minimum RX level required in a
_UTRA_FA_Q_RX_LE cell in dBm units.
V_MIN
pMaxUtra 0 The maximum RF output power in the
UE.

Feature Description
(Continued)
PLDUtraFaPrior qQualMin qQualMin_DEFAULT_ The minimum quality level required in

InfoFunc UTRA_FA_Q_QUAL_M UTRA FDD cells.
IN
offsetFreq 0 The offset applied to UTRA carrier
frequency.
threshXhigh 0 The threshold used in the UE to
QRel9 reselect a frequency whose priority is
higher than the current camped
frequency in Rel-9.
threshXlow 0 The threshold used to reselect low-
QRel9 priority frequency from high-priority
frequency in Rel-9.
anrUeSearc 100.0 The Searching Rate of UE which
hRate performs the ANR measurement for
the corresponding carrier index.
purpose 0 The usage of UTRAN carrier
Information
- BOTH (0): use for CS and PS HO.
- CS_ONLY (1): use for CS HO
(CSFB, SRVCC)
- PS_ONLY (2): use for PS HO.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description

Overview
Introduction
eNB broadcasts SIB type 6 for cell reselection to GERAN.
Benefits
User can perform cell reselection from E-UTRAN to GERAN.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 None
Limitation:
 None
Reference

Feature Description
Feature Description
cell it has camped onto. SIB7 is used for UE performing idle mode procedure for inter-RAT
cell reselection to GERAN. SIB7 includes the neighbouring carrier frequency group list
and the related thresholds for cell reselection towards GERAN cells.
GERAN cell reselection parameters

 GERAN carrier frequencies per GERAN carrier frequency group
 Cell reselection priority per GERAN carrier frequency group
 Cell reselection thresholds per GERAN carrier frequency group
 Cell reselection timer for GERAN cell reselection
 Cell reselection timer for speed dependant GERAN cell reselection

Feature Description
System operation
Command Description
RTRV- Retrieves the GERAN FA object information. If the CELL_NUM and FA_INDEX
GERAN-FA parameters are entered, the information only for the GERAN FA object registered
to the corresponding E-UTRAN served cell is retrieved. If not, the information for
all GERAN FA objects is retrieved.
CHG-GERAN- Changes the GERAN FA object information. When the CELL_NUM and
FA PURPOSE parameter values are set as input values, the GERAN FA object
information can be changed.

PLDGeranFaP cellNum 0 The cell number to be changed.

riorInfoFunc faIndex 0 GERAN frequency index. Up to 6 FAs can be
assigned per cell.
status 0 Whether the GERAN FA object is valid.
- N_EQUIP: Invalid.
- EQUIP: Valid.
Reserved 0 Reserved
geranArfcn0 0 Absolute Radio Frequency Channel Number
(ARFCN) of the GERAN FA object.
geranArfcn1 -1 Absolute Radio Frequency Channel Number

Feature Description
(Continued)
PLDGeranFaP geranArfcn9 -1 Absolute Radio Frequency Channel Number

riorInfoFunc (ARFCN) of the GERAN FA object.

Feature Description
(Continued)
PLDGeranFaP geranArfcn29 -1 Absolute Radio Frequency Channel Number

riorInfoFunc (ARFCN) of the GERAN FA object.
offsetFreq 0 The offset for carrier frequency of the GERAN
FA object.
bandIndicator 0 The band indicator of the GERAN FA object.
- dcs1800: Indicates DCS 1800 band.
- pcs1900: Indicates PCS 1900 band.
priority 4 Priority of the GERAN FA object.
nccPermitted 1 The 1st bit of nccPermitted in the GERAN FA
Bit1 object.
- False: Indicates 0.
- True: Indicates 1.
nccPermitted 1 The 2nd bit of nccPermitted in the GERAN FA
Bit2 object.
nccPermitted 1 The 3rd bit of nccPermitted in the GERAN FA
Bit3 object.
nccPermitted 1 The 4th bit of nccPermitted in the GERAN FA
Bit4 object.
Bit5 object.
Bit6 object.
Bit7 object.

Feature Description
(Continued)
PLDGeranFaP nccPermitted 1 The 8th bit of nccPermitted in the GERAN FA

riorInfoFunc Bit8 object.
qRxLevMin 0 The minimum RX level required by the GERAN
FA object.
pMaxGeran 0 The maximum RF output of the UE in the
GERAN FA object.
threshXhigh 0 The threshXhigh information used for cell
reselection in the GERAN FA object.
threshXLow 0 The threshXLow information used for cell
reselection in the GERAN FA object.
anrUeSearch 100.0 The Searching Rate of UE which performs the
Rate ANR measurement for the corresponding
carrier index.
purpose 0 The usage of GERAN carrier Information
- CS_ONLY (1): use for CS HO (CSFB, SRVCC)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW0310, SIB Broadcast (SIB10, SIB11)

Overview
Introduction
eNB broadcasts SIB type 10 and type 11 for ETWS primary and secondary notification
respectively.
Benefits
User can receive ETWS warning notification within E-UTRAN.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 ETWS capable device
Limitation:
 None
Reference
Feature Scope
R1 The eNB transmits via the SIB10 when the primary notification of the ETWS warning
message is received.
R2 The eNB transmits via SIB11 when the secondary notification of the ETWS warning
R3 The eNB allows the operator to configure, modify, and retrieve the maximum size of
the SIB10/SIB11 transmission cycle and warning message segment (SIB11).
R4 The eNB transmits the SIB10/SIB11 according to the predetermined cycle.

Feature Description
Feature Description
SIB10 and SIB11 are used for ETWS primary notification and ETWS secondary
notification, respectively. These can occur at any time, and the presence of an ETWS
warning notification is informed via paging message. If the UE receives a paging message
including the etws-Indication, it shall start receiving the ETWS primary notification and/or
ETWS secondary notification.
SIB10 is used to transmit ETWS primary notification. The ETWS primary notification has
message identifier, serial number, warning type, and warning security info which are
received to the S1 Write-Replace Warning message.
SIB11 is used to transmit ETWS secondary notification. The ETWS secondary notification
has message identifier, serial number, warning type, warning message contents (warning
message segment), and data coding scheme received to the S1 Write-Replace Warning
message. The ETWS secondary notification can be transmitted in partition and the warning
message segment type and warning message segment number are included in the SIB11 as
the information indicating partitioned transmission.

Feature Description
System operation
CHG-SIB-INF cellNum This is the number of

RTRV-SIB-INF cells to which ETWS
is transmitted.
sib10Period This is the transmission period to ETWS Primary -
Notification SIB10 of a cell.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
sib11Period This is the transmission period to ETWS Secondary -
Notification SIB11 of a cell.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
CHG-SIB-IDLE cellNum This is the number of
RTRV-SIB-IDLE cells to which ETWS
is transmitted.
maxPackedSiSize This is the maximum size of a warning message -
segment.
The value is set by considering the number of DL
RB for each bandwidth, the maximum number of
RBs assigned to one SI message, the number of
PDSCH RE for each RB, the payload size of DCI
format 1A, maximum aggregation level and PDCCH
code rate.
For 1.4M, 9 bytes, for 3M, 26 bytes, for 5M, 49
bytes, for 10M, 97 bytes, for 15M, 141 bytes, and
for 20M, 217 bytes are recommended.
range: 0~217 init:217

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description

Overview
Introduction
eNB broadcasts SIB type 12 for CMAS notification.
Benefits
User can receive CMAS warning notification within E-UTRAN.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 CMAS capable device
Limitation:
Reference
3) 3GPP TS36. 413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Feature Scope
R1 The eNB transmits via the SIB12 when the CMAS warning notification is received.
R2 The eNB allows the operator to configure, modify, and retrieve the maximum size of
the SIB12 transmission cycle and warning message segment.

Feature Description
Feature Description
SIB12 is used for CMAS warning notification. It can occur at any time, and the presence of
a CMAS warning notification is informed via paging message. If the UE receives a paging
message including the cmas-Indication, it shall start receiving the CMAS warning
notification.
SIB12 is used to transmit CMAS warning notification. The CMAS warning notification has
message identifier, serial number, warning type, warning message contents (warning
message segment), and data coding scheme received to the S1 Write-Replace Warning
message. The CMAS warning notification can be transmitted in partition and the warning
message segment type and warning message segment number are included in the SIB12 as
the information indicating partitioned transmission.

Feature Description
System operation
CHG-SIB-INF cellNum This is the number

RTRV-SIB-INF of cells to which
CMAS is
transmitted.
sib10Period This is the transmission period to CMAS SIB12 of a -
cell.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
CHG-SIB-IDLE cellNum This is the number
RTRV-SIB-IDLE of cells to which
ETWS is
transmitted.
maxPackedSiSize This is the maximum size of a warning message -
segment.
The value is set by considering the number of DL RB
for each bandwidth, the maximum number of RBs
assigned to one SI message, the number of PDSCH
RE for each RB, the payload size of DCI format 1A,
maximum aggregation level and PDCCH code rate.
For 1.4M, 9 bytes, for 3M, 26 bytes, for 5M, 49 bytes,
for 10M, 97 bytes, for 15M, 141 bytes, and for 20M, 217
bytes are recommended.
range: 0~217 init:217
Related Counters
N/A
Related KPI/PI
N/A

Feature Description
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW0320, RRC Connection Management_6UK

Overview
Introduction
RRC connection management stands for following four RRC procedures.
 RRC connection establishment: RRC Connection Establishment is used to establish a
RRC connection between UE and eNB.
 RRC connection reconfiguration: RRC Connection Reconfiguration is used to setup,
modify or delete radio configuration of a RRC connection.
 RRC connection release: RRC Connection Release is used to release a RRC
connection.
 RRC connection re-establishment: RRC Connection Reestablishment is used to
reestablish a RRC connection between UE and eNB.
Benefits
Operator can provide radio connectivity to its subscribers within E-UTRAN.
Users can have a radio connection with an eNB for LTE service.
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference

Feature Description
Feature Description
RRC Connection Establishment
WesternThe eNB performs the RRC connection establishment procedure upon the UE’s
request. The RRC connection establishment procedure is used for RRC connection setup,
and the eNB establishes signaling connection with the UE through this procedure.
When receiving the RRC connection request from the UE, the eNB considers the current
RRC connection configuration status to determine whether RRC connection can be
established. If it is possible, it allocates resources for SRB1 and sends them to the UE with
the RRC Connection Setup message. The UE responds to this message. When receiving the
RRC Connection Setup Complete message, it completes the RRC connection establishment
procedure and then performs subsequent procedures.
The RRC connection establishment procedure is as follows.
0) The UE performs the random access procedure with the eNB.

1) The UE transmits the RRC Connection Request message to the eNB.
2) The eNB determines whether RRC connection can be established. If RRC connection
can be established, the eNB transmit the RRC Connection Setup message to the UE.
Information required for SRB1 setup is included in this message. If RRC connection
cannot be established, the eNB transmit the RRC Connection Reject message to the
UE.

Feature Description
3) After setting up SRB1 according to the RRC Connection Setup message received from
the eNB, the UE responds with the RRC Connection Setup Complete message.
The NAS message is included in this message.
4) The eNB transmits the Initial UE message including the NAS message received from
the UE to the MME. The following procedures are processed depending on the
MME’s operation.
RRC connection reconfiguration

The eNB performs the RRC connection reconfiguration procedure to set up/change/release
the radio configuration for controlling the connected UE. The RRC connection
reconfiguration procedure is used in various situations to set up the call, to add the DRB, to
change the radio resource configuration, to change the measurement configuration, to
change the security context, etc.
The RRC connection reconfiguration procedure is as follows. (E-RAB setup case)
0) The eNB receives E-RAB Setup Request from the MME. The QoS information of the
E-RAB(s) to be added, a NAS message to be sent to the UE and ACTIVATE
DEDICATED EPS BEARER CONTEXT REQUEST are included in the E-RAB
Setup Request.
1) When receiving the E-RAB Setup Request from the MME, the eNB determines
whether new E-RAB(s) can be added. If it is possible, it reallocates internal resources
and transmits the RRC Connection Reconfiguration to the UE.
2) The UE sets up the additional DRB(s) specified by the RRC Connection
Reconfiguration and responds to the eNB with the RRC Connection Reconfiguration
Complete.
3) The eNB responds to the MME with the E-RAB Setup response. The E-RAB Setup
response includes setup success/failure results for each E-RAB.

Feature Description
RRC connection release

The eNB performs the RRC connection release procedure when releasing the RRC
connection with the UE. The RRC connection release procedure is used to release a call of
the connected UE, to redirect, or to process the CSFB. When releasing the RRC connection
with the UE, the eNB transmits the RRC Connection Release message to the UE.
Then it releases the entire UE context.
The RRC connection release procedure is as follows. (UE context release case)
0) (If it is the eNB initiated UE context release procedure,)The eNB transmits UE

Context Release request to the MME to request for call release.
1) The MME transmits UE Context Release command to the eNB for S1 release.
2) The eNB transmits RRC Connection Release to the UE.
3) After performing the RRC Connection Release procedure with the UE, the eNB
responds to the MME with UE Context Release Complete.

Feature Description
RRC connection reestablishment

The eNB performs the RRC connection reestablishment procedure upon the UE’s request.
The RRC connection reestablishment procedure is used for RRC connection re-setup, and
the eNB restores signaling connection and security context with the UE through this
procedure. When receiving the RRC connection reestablishment request from the UE, the
eNB checks if it has the UE’s UE context. If it has the UE’s UE context, the eNB allocates
resources for SRB1 and configures the AS security context, and then sends it to the UE
with the RRC Connection Reestablishment message. The UE responds to this message.
When receiving the RRC Connection Reestablishment Complete message, it completes the
RRC connection establishment procedure and then performs subsequent procedures.
The RRC connection reestablishment procedure is as follows.
0) The UE performs the Random access procedure with the eNB for RRC connection
reestablishment.
1) The UE transmits the RRC Connection Reestablishment Request message to the eNB.
2) The eNB checks whether the UE has the UE context. If it has the UE context, the eNB
transmits the RRC Connection Reestablishment message to the UE. The information
required for SRB1 setup and AS security context restoration is included in this
message. If RRC connection re-establishment is not possible, the eNB transmit the
RRC Connection Reestablishment Reject message to the UE.

Feature Description
3) The UE restores the SRB1 setup and AS security context according to the RRC
Connection Reestablishment message received from the eNB and responds with the
RRC Connection Reestablishment Complete message.
4) The eNB performs the RRC connection reconfiguration procedure with the UE to set
up the SRB2 and DRB. If the handover procedure was being performed, it processes
subsequent procedures with the EPC.

Feature Description
System operation
 Commands and Parameters
CHG-TIMER-INF dbIndex Index to change the timer information. The default is 0.

RTRV-TIMER-INF rrcConnection The time to wait for reception of the RrcConnection
Setup SetupComplete message after sending the
RrcConnectionSetup message from the eNB to the UE.
rrcConnection The time to wait for reception of the RrcConnection
Reconfig RecofigurationComplete message after sending the
RrcConnectionRecofig message from the eNB to the UE.
rrcConnection The time to wait for reception of the RrcConnection
ReEstablish ReestablishmentComplete message after sending the
RrcConnectionReestablishment message from the eNB to
the UE.
rrcSecurityMo The time to wait for reception of the SecurityModeComplete
deCommand message after sending the SecurityModeCommand
message from the eNB to the UE.
rrcUeCapabilit The time to wait for reception of the UeCapability
yEnquiry Information message after sending the UeCapabilityEnquiry
message from the eNB to the UE.
rrcConnection The time to wait for reception of the message from the
Release PDCB block confirming that the RrcConnectionRelease
message was successfully sent after sending it from the
eNB to the UE.
rrcUeInformati The time to wait for reception of the InformationResponse
onRequest message after sending the InformationRequest message
from the eNB to the UE.
s1InitialContex The time to wait for reception of the InitialContextSetup
tSetup Request message after sending the InitilUE from the eNB
to the MME.
s1UeContextR The time to wait for reception of the UEContextRelease
elease Command message after sending the
UEContextReleaseRequest from the eNB to the MME.
internalResour The time to wait for a response after sending the setup
ceSetup message to internal entities (PDCB, MACB, RLCB) for
setting up resources inside the eNB.
internalResour The time to wait for a response after sending the release
ceRelease message to internal entities (PDCB, MACB, RLCB) for
releasing resources inside the eNB.

Feature Description
(Continued)
CHG-TIMER-INF internalSecurityC The time to wait for a response after sending the control
RTRV-TIMER-INF ontrol message to the PDCP entity for security control inside
the eNB.
internalReestalis The time to wait for a response after sending the control
hControl message for controlling the entities inside the eNB at
reestablish.
internalReestabls The time to wait for reception of RrcReestablishRequest
hTimeToWait from the UE after RLF is received from MACB or Max
Retransmission Ind is received from RLCB.
internalRrcReset The time to wait for multiple UEs to be released after
sending the RrcConnectionRelease to the UEs at eNB
reset.
All the parameters for RRC Connection management are provided according to 3GPP
standards.

Feature Description
Related Counters
Category Family Name Type Name Type Description
RRC RRC_ESTAB ConnEstabAtt RRC CONNECTION REQUEST count

ConnEstabSucc RRC CONNECTION SETUP COMPLETE count
ConnEstabFail_ RRC connection Establishment fails due to call
CP_CC_TO control timeout in the protocol blocks (MAC,
RLC, PDCP, GTP)
ConnEstabFail_ RRC connection Establishment fails due to reset
CP_CC_FAIL notification (eNB failure or block restart) from
ECMB or by the ECCB block
ConnEstabFail_ RRC connection Establishment fails due to the
UP_MAC_FAIL failure in the MAC block
UP_PDCP_FAIL failure in the PDCP block
UP_RLC_FAIL failure in the RLC block
ConnEstabFail_ RRC connection Establishment fails due to RRC
RRC_SIG_TO signaling timeout (not received)
ConnEstabFail_S RRC connection Establishment fails due to the
1AP_LINK_FAIL S1 SCTP link failure
ConnEstabFail_ RRC connection Establishment fails due to
S1AP_SIG_FAIL receiving S1AP signaling
ConnEstabReject A call is rejected due to cell status (e.g. barred)
_CP_CC_FAIL or MME status (e.g. no available MMEs) during
the RRC connection establishment
ConnEstabReject A call is rejected due to CAC during the RRC
_CP_CAPA_CAC connection establishment
_FAIL
ConnEstabReject A call is rejected due to MME overload during the
_S1AP_MME_O RRC connection establishment
VLD
RRC_RECO ConnReconfigAtt RRC CONNECTION RECONFIGURATION
NFIG count
ConnReconfigSu RRC CONNECTION RECONFIGURATION
cc COMPLETE count
RRC_REEST ConnReEstabAtt RRC CONNECTION REESTABLISHMENT
AB REQUEST count
ConnReEstabSu RRC CONNECTION REESTABLISHMENT
cc COMPLETE count
ConnReEstabFa RRC connection Re-establishment fails due to
il_CP_CC_FAIL reset notification (eNB failure or block restart)
from ECMB or by the ECCB block

Feature Description
(Continued)
RRC RRC_REEST ConnReEstabFail_ RRC connection Re-establishment fails due to

AB UP_MAC_FAIL the failure in the MAC block
ConnReEstabFail_ RRC connection Re-establishment fails due to
UP_PDCP_FAIL the failure in the PDCP block
UP_RLC_FAIL the failure in the RLC block
RRC_SIG_TO RRC signaling timeout (not received)
S1AP_LINK_FAIL the S1 SCTP link failure
S1AP_SIG_FAIL receiving S1AP signaling
ConnReEstabReje A call is rejected due to cell status (e.g. barred)
ct_CP_CC_FAIL or MME status (e.g. no available MMEs)
during the RRC connection reestablishment
ConnReEstabReje A call is rejected due to Capacity based CAC
ct_CP_CAPA_CA during the RRC connection reestablishment
C_FAIL
ConnReEstabReje A call is rejected due to Air QoS based CAC
ct_CP_QOS_CAC during the RRC connection reestablishment
_FAIL
RRC_RELEA ConnRelease_CP_ Normal release
SE CC_NORMAL
ConnRelease_CP_ A call is released due to call control timeout in
CC_TO the protocol blocks (MAC, RLC, PDCP, GTP)
ConnRelease_CP_ A call is released due to reset notification (eNB
CC_FAIL failure or block restart) from ECMB or by the
ECCB block
ConnRelease_UP_ A call is released due to the failure in the GTP
GTP_FAIL block
ConnRelease_UP_ A call is released due to the failure in the MAC
MAC_FAIL block
ConnRelease_UP_ A call is released due to user inactivity
MAC_UE_INACT
ConnRelease_UP_ A call is released due to the failure in the
PDCP_FAIL PDCP block
ConnRelease_UP_ A call is released due to the failure in the RLC
RLC_FAIL block
ConnRelease_RR A call is released due to HO preparation
C_HC_TO timeout (not received HO command)

Feature Description
(Continued)
RRC RRC_RELEA ConnRelease_RR A call is released due to receiving RRC

SE C_SIG_FAIL signaling
ConnRelease_RR A call is released due to RRC signaling
C_SIG_TO timeout (not received)
ConnRelease_CP_ A call is released due to Backhaul QoS based
BH_CAC_FAIL CAC
ConnRelease_CP_ A call is released due to Capacity based CAC
CAPA_CAC_FAIL
ConnRelease_CP_ A call is released due to Air QoS based CAC
QOS_CAC_FAIL
ConnRelease_S1A A call is released due to the S1AP
P_CU_FAIL specification cause
ConnRelease_S1A A call is released due to the S1 SCTP link
P_LINK_FAIL failure
ConnRelease_S1A A call is released due to the S1AP relocoverall
P_RO_TO timeout (not received)
ConnRelease_S1A A call is released due to receiving S1AP
P_SIG_FAIL signaling
ConnRelease_S1A A call is released due to S1AP signaling
P_SIG_TO timeout (not received)
ConnRelease_X2A A call is released due to the X2AP
ConnRelease_X2A A call is released due to the X2 SCTP link
P_LINK_FAIL failure
ConnRelease_X2A A call is released due to the X2AP relocoverall
P_RO_TO timeout (not received)
ConnRelease_X2A A call is released due to receiving X2AP
P_SIG_FAIL signaling
RRC_CONN ConnNo Average number of RRC connections during a
time period
ConnMax Maximum number of RRC connections during
a time period
ConnTot Summation of the collected ConnNo
ConnCnt Count of the collected ConnNo
ReleaseCallHoldin Average holding time of RRC connection.
gTime This is collected when a call is released.
ReleaseCallHoldin Summation of the collected
gTimeTot ReleaseCallHoldingTime
ReleaseCallCnt Call Release Count

Feature Description
(Continued)
RRC RRC_CONN_ ConnNo_PLMN Average number of RRC connections per

PLMN PLMN during a time period
ConnMax_PLMN Maximum number of RRC connections per
PLMN during a time period
ConnTot_PLMN Summation of the collected ConnNo_PLMN
ConnCnt_PLMN Count of the collected ConnNo_PLMN
RRC_TIME ConnEstabTime Average RRC Connection setup time
ConnEstabTimeMax Maximum RRC Connection setup time
ConnEstabTimeTot Summation of the collected ConnEstabTime
ConnEstabTimeCnt Count of the collected ConnEstabTime
RRC_RESET ConnReEstabTime Average RRC Connection reestablishment
UP_TIME time
ConnReEstabTime Maximum RRC Connection reestablishment
Max time
ConnReEstabTime Summation of the collected ConnReEstabTime
Tot
ConnReEstabTime Count of the collected ConnReEstabTime
Cnt
CALL_DROP CallDrop_ECCB_D Call drop (abnormal release) count due to no
SP_AUDIT_RLC_ call in RLC and MAC block
MAC_CALL_RELE
ASE
CallDrop_ECCB_R Call drop (abnormal release) count due to
CV_RESET_REQ reset request from ECMB
UEST_FROM_EC
MB
CallDrop_ECCB_R Call drop (abnormal release) count due to cell
CV_CELL_RELEA release indication from ECMB
SE_IND_FROM_E
CMB
CallDrop_ECCB_R Call drop (abnormal release) count due to
ADIO_LINK_FAILU radio link failure
RE
CallDrop_ECCB_D Call drop (abnormal release) count due to no
SP_AUDIT_MAC_ call in MAC block
CALL_RELEASE
CallDrop_ECCB_A Call drop (abnormal release) count due to
RQ_MAX_RE_TR ARQ failure (no ACK is received after
ANSMISSION maximum retransmission)

Feature Description
(Continued)
RRC CALL_DROP CallDrop_ECCB_D Call drop (abnormal release) count due to no

SP_AUDIT_RLC_ call in RLC block
CALL_RELEASE
CallDrop_ECCB_T Call drop (abnormal release) count due to
MOUT_rrcConnect RRC signaling timeout (not received) during
ionReconfig the RRC Connection Reconfiguration
CallDrop_ECCB_T Call drop (abnormal release) count due to
MOUT_rrcConnect RRC signaling timeout (not received) during
ionReEstablish the RRC Connection Reestablishment
CallDrop_ECCB_S Call drop (abnormal release) count due to S1
1_SCTP_OUT_OF failure
_SERVICE
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW0321, UE Context Management

Overview
Introduction
eNB maintains UE contexts while the UEs are in RRC_CONNECTED state, and supports
Initial Context Setup, UE Context Release and Modification according to requests from
MME.
Benefits
Operator can maintain UE context for its subscribers in RRC_CONNECTED state.
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 Need UE IOT for security context modification
Reference

Feature Description
Feature Scope
[Initial Context Setup]
R1 The eNB processes the initial context setup procedure upon a request by the MME.
R2 Using the Call Admission Control (CAC) function, the eNB determines if the E-
RAB(s) configuration request can be accepted according to the QoS information of
each E-RAB specified in the initial context setup request.
R3 The eNB reconfigures the internal resources (MAC/RLC/PDCP) of the selected
DRB(s) according to the QoS information of each E-RAB specified in the initial
context setup request.
R4 The eNB processes the RRC connection reconfiguration procedure with the UE for
DRB(s) setup.
R5 The eNB replies the E-RAB setup result-E-RAB Setup List IE/E-RAB Failed to Setup
List IE-to the MME as a part of the initial context setup response.
R6 The eNB collects the statistics of the initial context setup procedure.
 Initial Context Setup Attempt/Success/Failure (Collection unit: Cell, RRC
establishment cause, reason for failure)
 RRC Connection Reconfiguration Attempt/Success/Failure (Collection unit: Cell,
RRC establishment cause, reason for failure)
[UE Context Modification]

R1 The eNB processes the UE context modification procedure upon a request by the
MME.
R2 The eNB modifies the UE context using the value specified in the UE context
modification request.
R3 The eNB processes the RRC connection reconfiguration procedure to the UE when
the security context is modified.
R4 The eNB replies the UE context modification result to the MME as a part of the UE
context modification response.
R5 The eNB collects the statistics of the UE context modification procedure.
 UE Context Modification Attempt/Success/Failure (Collection unit: Cell, RRC
[UE Context Release]

R1 The eNB detects the situation in which a call release is needed.
 In case of radio link failure
 In case of user inactivity
 In case of Intra-LTE and inter-RAT redirection generation
 In case of CSFB with redirection occurring
R2 When detecting a situation in which a call release is needed, the eNB processes the
UE context release request procedure in order to request the call release to the MME.
R3 The eNB processes the UE context release procedure upon a request by the MME.

Feature Description
R4 The eNB processes the RRC connection release procedure to a terminal.

R5 The eNB replies the UE context release result to the MME as a part of the UE context
release complete.
R6 The eNB collects the statistics of the UE context release procedure.
 UE Context Release Attempt/Success/Failure (Collection unit: Cell, RRC

Feature Description
Feature Description
Initial Context Setup
WesternThe eNB performs the initial context setup procedure upon the MME’s request.
The initial context setup procedure is used for call setup, and the eNB creates the UE
context for the connected UE and then processes UE associated signaling and data
transmission/reception. When receiving the Initial Context Setup request from the MME,
the eNB considers the current resource usage status and determines whether call setup is
possible. If the call setup is possible, it performs the RRC Connection Reconfiguration
procedure with the UE for resource reconfiguration and transmits the Initial Context Setup
Response message to the MME.
The initial context setup procedure is used for call setup (idle-to-active transition).
The eNB creates the UE context required for controlling the connected UE through the
initial context setup procedure, and performs the E-RAB setup procedure for data
transmission. The UE context and bearer information included in the Initial Context Setup
Request message are as follows.
 MME UE S1AP ID
 UE Aggregate Maximum Bit Rate (UE AMBR)
 E-RAB to Be Setup List
 UE Security Capabilities
 Security Key
 Trace Activation
 Handover Restriction List
 UE Radio Capability
 Subscriber Profile ID for RAT/Frequency priority (SPID)
 SRVCC operation possible
 CSG Membership Status
 Registered LAI
The initial context setup procedure is as follows. (UE initiated Service Request case)

Feature Description
0) The UE performs the random access and the RRC connection establishment
procedures with the eNB for call setup.
1) The eNB transmits the Initial UE message to the MME. The NAS message received
from the UE and SERVICE REQUEST are included in this message.
2) If necessary, the NAS security setup or authentication procedures are performed.
3) The MME transmits the Initial Context Setup request to the eNB. Information required
for E-RAB(s) setup, UE contexts required by the eNB to control the UE, the NAS
message to be sent to the UE and SERVICE ACCEPT are included in the Initial
Context Setup request.
4) The eNB determines whether call setup is possible based on the information received
from the MME. If possible, it performs the AS security activation procedure with the
UE.
5) The eNB reallocates internal resources for DRB(s) setup and transmits RRC
Connection Reconfiguration to the UE.
6) The UE sets up the additional DRB(s) specified by RRC Connection Reconfiguration
and responds to the eNB with RRC Connection Reconfiguration Complete.
7) The eNB responds to the MME with the Initial Context Setup response. Setup success/
failure results for each E-RAB are included in the Initial Context Setup response.
8) The MME performs the Modify Bearer procedure with the S-GW/P-GW.

Feature Description
UE Context Modification
The eNB performs the UE context modification procedure upon the MME’s request.
It can change the security context, UE AMBR and SPID through the UE context
modification procedure. When receiving the UE Context Modification request from the
MME, the eNB changes the UE context using the value included in the message and
transmits the UE Context Modification response to the MME. If the security context was
changed, it performs the RRC Connection Reconfiguration procedure with the UE and then
responds to the MME.
It uses the UE context modification procedure to change the UE context of the connected
UE. The following UE contexts can be changed through the UE context modification
procedure.
 UE Aggregate Maximum Bit Rate (UE AMBR)
 UE Security Capabilities
 Security Key
 Subscriber Profile ID for RAT/Frequency priority (SPID)
 CSG Membership Status
 Registered LAI
The UE context modification procedure is as follows.
0) (If it is the HSS initiated UE context modification procedure,) The HSS performs the
subscriber data modification procedure with the MME.
1) If UE context modification is required, the MME transmits the Context Modification
request to the eNB.
2) The eNB changes the UE context based on the information included in the UE Context
Modification Request message and transmits the UE Context Modification Response
message to the MME. If the security context was changed, it performs the RRC
Connection Reconfiguration procedure with the UE and then responds to the MME.

Feature Description
UE Context Release
The eNB performs the UE context release procedure upon the MME’s request. The UE
context release procedure is used for releasing a call from the connected UE. The MME
initiated UE context release is performed based on MME’s decision or the eNB initiated
UE context release is performed upon the request from the eNB. When receiving the UE
Context Release Command message from the MME, the eNB performs the RRC
Connection Release procedure with the UE and then transmits the UE Context Release
Complete message to the MME.
The UE context release procedure is used for call release (active-to-idle transition).
The UE context release procedure is as follows.
0) (If it is the eNB initiated UE context release procedure,) The eNB transmits the UE
Context Release request to the MME to request for call release.
1) If S1 release is necessary, the MME performs the Release Access Bearer procedure
with the S-GW.
2) The MME transmits the UE Context Release command to the eNB for S1 release.
3) The eNB transmits RRC Connection Release to the UE.
4) The eNB performs the RRC Connection Release procedure with the UE and then
responds to the MME with the UE Context Release Complete.

Feature Description
System operation
Command Description
RTRV- Retrieves the current preferred integrity protection and the ciphering algorithm of
SECU-INF the eNB.
CHG-SECU- Changes the preferred integrity protection algorithm and ciphering algorithm of the
INF eNB. When the DB Index parameter value is set as an input value, the preferred
integrity protection algorithm and ciphering algorithm can be changed.

PLDSecurityI dbIndex 0 Tuple index.

nfoFunc integrityEaPrior enumIntegrityAlgo_ The integrity protection algorithm
type_DEFAULT supported by the eNB.
- EIA0: NULL.
- EIA1: SNOW 3G.
- EIA2: AES.
cipherEaPrior enumCipherAlgo_ The ciphering algorithm supported by the
type_DEFAULT eNB.
- EEA0: NULL.
- EEA1: SNOW 3G.
- EEA2: AES.
Related Counters
Category Family Type Description
ERAB ERAB_ESTAB EstabInitAttNbr INITIAL CONTEXT SETUP REQUEST

count
EstabInitSuccNbr INITIAL CONTEXT SETUP RESPONSE
count
ErabInitFailNbr_CP_ Initial E-RAB setup fails due to call
CC_TO control timeout in the protocol blocks
(MAC, RLC, PDCP, GTP)
ErabInitFailNbr_CP_ Initial E-RAB setup fails due to reset
CC_FAIL notification (eNB failure or block restart)
ErabInitFailNbr_UP_ Initial E-RAB setup fails due to the failure
GTP_FAIL in the GTP block
ErabInitFailNbr_UP_ Initial E-RAB setup fails due to the failure
MAC_FAIL in the MAC block

Feature Description
(Continued)
ERAB ERAB_ESTAB ErabInitFailNbr_UP_ Initial E-RAB setup fails due to the

PDCP_FAIL failure in the PDCP block
ErabInitFailNbr_UP_RLC Initial E-RAB setup fails due to the
_FAIL failure in the RLC block
ErabInitFailNbr_RRC_ Initial E-RAB setup fails due to
SIG_FAIL receiving RRC signaling
ErabInitFailNbr_RRC_ Initial E-RAB setup fails due to RRC
SIG_TO signaling timeout (not received)
ErabInitFailNbr_CP_BH_ Initial E-RAB setup fails due to
CAC_FAIL Backhaul QoS based CAC
ErabInitFailNbr_CP_ Initial E-RAB setup fails due to
CAPA_CAC_FAIL Capacity based CAC
ErabInitFailNbr_CP_QOS Initial E-RAB setup fails due to Air
_CAC_FAIL QoS based CAC
ErabInitFailNbr_S1AP_ Initial E-RAB setup fails due to the
CU_FAIL S1AP specification cause
ErabInitFailNbr_S1AP_ Initial E-RAB setup fails due to the
LINK_FAIL S1 SCTP link failure
ErabInitFailNbr_S1AP_ Initial E-RAB setup fails due to
SIG_FAIL receiving S1AP signaling
ERAB_ERASE EraseAttbyEnb_CP_CC_ eNB initiated UE Context Release
_ENB TO fails due to call control timeout in
the protocol blocks (MAC, RLC,
PDCP, GTP)
EraseAttbyEnb_CP_CC_ eNB initiated UE Context Release
FAIL fails due to reset notification (eNB
failure or block restart) from ECMB
or by the ECCB block
EraseAttbyEnb_UP_GTP eNB initiated UE Context Release
_FAIL fails due to the failure in the GTP
block
EraseAttbyEnb_UP_MAC eNB initiated UE Context Release
_FAIL fails due to the failure in the MAC
block
EraseAttbyEnb_UP_MAC eNB initiated UE Context Release
_UE_INACT fails due to user inactivity

Feature Description
(Continued)
ERAB ERAB_ERASE EraseAttbyEnb_UP_ eNB initiated UE Context Release

_ENB PDCP_FAIL fails due to the failure in the PDCP
block
EraseAttbyEnb_UP_RLC eNB initiated UE Context Release
_FAIL fails due to the failure in the RLC
block
EraseAttbyEnb_RRC_ eNB initiated UE Context Release
HC_TO fails due to HO preparation timeout
(not received HO command)
SIG_FAIL fails due to receiving RRC signaling
SIG_TO fails due to RRC signaling timeout
(not received)
EraseAttbyEnb_S1AP_ eNB initiated UE Context Release
CU_FAIL fails due to the S1AP specification
cause
RO_TO fails due to the S1AP relocoverall
timeout (not received)
SIG_TO fails due to S1AP signaling timeout
(not received)
EraseAttbyEnb_X2AP_ eNB initiated UE Context Release
RO_TO fails due to the X2AP relocoverall
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW0322, LTE-SW0324, E-RAB Setup and

Release_7UK
Overview
Introduction
eNB supports handling of E-RAB allocation, configuration, maintenance and release.
Benefits
Operator can provide EPS bearer service to its subscribers and manage E-RAB resources
for user data transport.
Users can obtain EPS bearer service within E-UTRAN
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference

Feature Description
Feature Scope
[E-RAB Setup]
R1 The eNB processes the E-RAB setup procedure upon the request by the MME.
R2 The eNB determines whether the E-RAB(s) configuration request can be accepted
according to the QoS information specified by the E-RAB setup request using the Call
Admission Control (CAC) function.
R3 The eNB configures the internal resources (MAC/RLD/PDCP) for the selected
DRB(s) according to the QoS information specified in the E-RAB setup request.
R4 The eNB processes the RRC connection reconfiguration procedure to the UE to setup
the DRB(s).
R5 The eNB replies the E-RAB setup process result (E-RAB Setup List IE/E-RAB Failed
to Setup List IE) to the MME as a part of the E-RAB setup response.
R6 The eNB collects the statistics of the E-RAB setup procedure.
 E-RAB Setup Attempt/Success/Failure (Collection unit: Cell, QCI, and reason for
failure)
QCI, and reason for failure)
[E-RAB Release]
R1 The eNB detects a problem of a specific E-RAB.
 In the case of S1-U path failure of a specific bearer
R2 After detecting problems of a specific E-RNB, the eNB processes the E-RAB release
indication procedure to notify the MME.
R3 The eNB processes the E-RAB release procedure upon the request by MME.
R4 The eNB processes the RRC connection reconfiguration procedure to the UE to
release the DRB(s).
R5 The eNB replies the E-RAB release process result (E-RAB Release List IE/E-RAB
Failed to Release List IE) to the MME as a part of the E-RAB release response.
R6 The eNB collects the statistics of the E-RAB release procedure.
 E-RAB Release Attempt/Success/Failure (Collection unit: Cell, QCI, and reason
for failure)
QCI, and reason for failure)

Feature Description
Feature Description
E-RAB Setup
The E-RAB setup procedure is used to add an E-RAB for a new service to the connected
UE.
An E-RAB for a new service can be added to the connected UE through the E-RAB setup
procedure. When receiving the E-RAB Setup Request message from the MME, the eNB
considers the current resource usage status and determines whether a new bearer can be
added. If a new E-RAB can be added, the eNB performs the RRC Connection
Reconfiguration procedure with the UE for resource reconfiguration of the new DRB and
transmits the E-RAB Setup Response message to the MME.
The E-RAB setup procedure is as follows.
1) The P-GW transmits the Create Bearer request to the S-GW to add the new E-RAB.
2) The S-GW transmits the Create Bearer request to add the new E-RAB.
3) The MME transmit the E-RAB Setup request to start the E-RAB setup procedure.
QoS information of the E-RAB(s) to be added, the NAS message to be sent to the UE,
and ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST are included in
the E-RAB Setup request.
4) When receiving the E-RAB Setup request from the MME, the eNB determines
whether a new E-RAB(s) can be added. If possible, the eNB reallocates internal
resources and transmits RRC Connection Reconfiguration to the UE.

Feature Description
5) The UE adds the new DRB(s) specified by RRC Connection Reconfiguration and then
replies to the eNB with RRC Connection Reconfiguration Complete.
6) The eNB responds to the MME with the E-RAB Setup response. Setup success/failure
results for each E-RAB are included in the E-RAB Setup response.
7) The UE transmits the NAS message and ACTIVATE DEDICATED EPS BEARER
CONTEXT RESPONSE.
8) The eNB transmits the NAS received from the UE to the MME.
9) The MME transmits the Create Bearer response to the S-GW.
10) The S-GW transmits the Create Bearer response to the P-GW.
E-RAB Release
E-RAB release procedure is used to release specific bearer service of a connected UE.
This procedure is performed by request from MME, and MME requests E-RAB release based
on its own decision (MME initiated E-RAB release) or as following action after an indication
from eNB (eNB initiated E-RAB release).
When E-RAB RELEASE REQUEST message is received from MME, eNB performs RRC
connection reconfiguration procedure with UE to release the corresponding DRB (data radio
bearer). When the DRB is released successfully, eNB returns E-RAB RELEASE
RESPONSE message to MME.
0) (If it is the eNB initiated E-RAB release procedure,) The eNB transmits the E-RAB
Release indication to the MME to notify the release of a specific E-RAB. The MME
transmits the Delete Bearer command to the S-GW for E-RAB release. The S-GW
transmits the Delete Bearer command for E-RAB release.
1) The P-GW transmits the Delete Bearer request to the S-GW for E-RAB release.
2) The S-GW transmits the Delete Bearer request to the MME for E-RAB release.
3) The MME initiates the E-RAB release procedure by transmitting the E-RAB Release
command. ID(s) of the E-RAB(s) to be released, the NAS message to be sent to the
UE and DEACTIVATE EPS BEARER CONTEXT REQUEST are included in the E-
RAB Release command.

Feature Description
4) When receiving the E-RAB Release command from the MME, the eNB transmits
RRC Connection Reconfiguration to the UE.
5) The UE releases the DRB(s) specified by RRC Connection Reconfiguration and then
replies to the eNB with RRC Connection Reconfiguration Complete.
6) The eNB responds to the MME with the E-RAB Release response.
7) The UE transmits the NAS message and DEACTIVATE EPS BEARER CONTEXT
RESPONSE.
8) The eNB transmits the NAS received from the UE to the MME.
9) The MME transmits the Delete Bearer response to the S-GW.
10) The S-GW transmits the Delete Bearer response to the P-GW.

Feature Description
System operation
To successfully setup E-RAB bearers, QCI value should be setup in the eNB in advance.
An operator can make the Qci status to be according to the following Command and
Parameters:
Command Description
RTRV-QCI-VAL Retrieves the configuration of QoS Class Identifier (QCI). The information is
used by the Evolved Universal Terrestrial Radio Access Network (EUTRAN) in
the eNB. The configuration parameters of each QCI consist of Status, Resource
Type, Priority, Packet Delay Budget (PDB), Packet Error Loss Rate (PELR), and
Backhaul Service Group.
CHG-QCI-VAL Changes the configuration information per QoS Class Identifier (QCI).
The information is used by the Evolved Universal Terrestrial Radio Access
Network (EUTRAN) in the eNB. The status, resource type, priority, Packet Delay
Budget (PDB), Packet Error Loss Rate (PLER) Backhaul Service Group
parameter values per QCI can be changed.

PLD qci 0 QCI index. The range is from 0 to 255.

QciValueInfo The standard QCIs defined in the standard
Func documents is 1 to 9. The user can use QCI
values 0 and 10-255.
Status qci 1~9: Whether the QoS Class Identifier (QCI) is
EQUIP used.
qci 0, 10~255: - EQUIP: The QCI is used in the eNB.
N_EQUIP - N_EQUIP: The QCI is not used in the eNB.
resourceType Ci_NonGBR The resource type of the QoS Class Identifier
(QCI).
- Ci_NonGBR: The resource type of the QCI
is set to non-GBR (Guaranteed Bit Rate).
- Ci_GBR: The resource type of the QCI is set
to GBR (Guaranteed Bit Rate).
priority 9 The priority of the QoS Class Identifier (QCI).
The range is between 1 and 16. 1 indicates
the highest priority.

Feature Description
(Continued)
Default
Relation Parameter Description
value
PLD pdb ci_pdb300 Packet Delay Budget (PDB) of the QoS Class
QciValueInfo msec Identifier (QCI).
Func - ci_pdb50 msec: PDB of the QCI to 50 msec.
- ci_pdb100 msec: PDB of the QCI to 100
msec.
msec.
msec.
msec.
msec.
msec.
msec.
msec.
msec.
bhServiceGroup voipService The service group of the QoS Class Identifier
(QCI). The entered parameter values is used
in the backhaul Call Admission Control (CAC).
- voipService: The QCI uses the Voice of
Internet Protocol (VoIP) service.
- videoService: The QCI uses the video
service.
schedulingType Dynamic_sc The schedulin type of the QoS Class Identifier
heduling (QCI). The entered parameter values is used
in scheduling by MAC Layer.
- Dynamic_scheduling: The QCI uses the
Dynamic scheduling.
- SPS_scheduling: The QCI uses SPS
scheduling.

Feature Description
Related Counters
Collected per cell, per QCI
Family
Category TypeName Type Description
Name
ERAB ERAB_ - E-RAB Setup related counters.
ESTAB These are collected per cell and per QCI.
_ADD EstabAddAttNbr ERAB SETUP REQUEST count
EstabAddSuccNbr ERAB SETUP RESPONSE count
ErabAddFailNbr_CP_ E-RAB setup fails due to call control timeout in the
CC_TO protocol blocks (MAC, RLC, PDCP, GTP)
ErabAddFailNbr_CP_ E-RAB setup fails due to reset notification (eNB
CC_FAIL failure or block restart) from ECMB or by the
ECCB block
ErabAddFailNbr_UP_ E-RAB setup fails due to the failure in the GTP
GTP_FAIL block
ErabAddFailNbr_UP_ E-RAB setup fails due to the failure in the MAC
MAC_FAIL block
ErabAddFailNbr_UP_ E-RAB setup fails due to the failure in the PDCP
PDCP_FAIL block
ErabAddFailNbr_UP_ E-RAB setup fails due to the failure in the RLC
RLC_FAIL block
ErabAddFailNbr_RRC E-RAB setup fails due to receiving RRC signaling
_SIG_FAIL
ErabAddFailNbr_RRC E-RAB setup fails due to RRC signaling timeout
_SIG_TO (not received)
ErabAddFailNbr_CP_ E-RAB setup fails due to Backhaul QoS based
BH_CAC_FAIL CAC
ErabAddFailNbr_CP_ E-RAB setup fails due to Capacity based CAC
CAPA_CAC_FAIL
ErabAddFailNbr_CP_ E-RAB setup fails due to Air QoS based CAC
QOS_CAC_FAIL
ErabAddFailNbr_S1A E-RAB setup fails due to the S1AP specification
P_CU_FAIL cause
ErabAddFailNbr_S1A E-RAB setup fails due to the S1 SCTP link failure
P_LINK_FAIL
ErabAddFailNbr_S1A E-RAB setup fails due to receiving S1AP signaling
P_SIG_FAIL

Feature Description
(Continued)
Family
Category TypeName Type Description
Name
ERAB ERAB_ ErabAddFailNbr_CP_ E-RAB setup fails due to ongoing inter-eNB
ESTAB CC_INTERACTION handover
_ADD
ERAB_ - eNB initiated E-RAB Release related counters.
REL_E These are collected per cell.
NB RelAttbyEnbNbr_CP_ eNB initiated E-RAB Release fails due to call
CC_TO control timeout in the protocol blocks (MAC, RLC,
PDCP, GTP)
RelAttbyEnbNbr_S1A eNB initiated E-RAB Release fails due to the S1AP
ERAB_ - MME initiated E-RAB Release related counters.
REL These are collected per cell.
RelAttNbr ERAB RELEASE COMMAND count
RelSuccNbr ERAB RELEASE RESPONSE count
RelFailNbr_CP_CC_F MME initiated E-RAB Release fails due to reset
AIL notification (eNB failure or block restart) from
RelFailNbr_S1AP_SI MME initiated E-RAB Release fails due to
G_FAIL receiving S1AP signaling
RelFailNbr_S1AP_CU MME initiated E-RAB Release fails due to the
_FAIL S1AP specification cause
RelActive Number of active E-RABs abnormally released by
eNB
RelFailNbr_CP_CC_I MME initiated E-RAB Release fails due to ongoing
NTERACTION inter-eNB handover
ERAB_ - Number of E-RABs related counters. These are
NUM collected per cell.
UsageNbr Average number of E-RABs during a time period
UsageNbrMax Maximum number of E-RABs during a time period
Related KPI/PI
N/A
Related Alarms
N/A

Feature Description
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW0323, RAB modification

Overview
Introduction
eNB supports handling of E-RAB modification. This is used for QoS modification of one
or several E-RABs.
Benefits
Operator can modify E-RAB QoS of ongoing session.
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference

Feature Description
Feature Scope
R1 The eNB processes the E-RAB modification procedure upon the request by the MME.
R2 Using the Call Admission Control (CAC) function, the eNB determines whether the
QoS configuration of the E-RAB(s) can be changed according to the QoS information
specified in the E-RAB modify request.
R3 The eNB reconfigures the internal resources (MAC/RLC/PDCP) of the DRB(s)
according to the QoS information specified in the E-RAB modify request.
R4 The eNB processes the procedure of the RRC connection reconfiguration to the UE to
change the QoS configuration.
R5 The eNB replies the E-RAB modification result (E-RAB Modify List IE/E-RAB
Failed to Modify List IE) to the MME as a part of the E-RAB modify response.
R6 The eNB collects the statistics of the E-RAB modification procedure.
 E-RAB Modify Attempt/Success/Failure (Collection unit: Cell, QCI, reason for
failure)
QCI, reason for failure)

Feature Description
Feature Description
E-RAB Setup
Use the E-RAB modification procedure to change the QoS setting of a bearer (E-RAB)
already in service. Using the E-RAB modification procedure, you can change UE AMBR
for non-GBR bearer and E-RAB Level QoS Parameters (QCI, ARP and GBR QoS
Information) for GBR bearer.
The E-RAB modification procedure is as follows:
1) The P-GW transmits Update Bearer Request to S-GW to change QoS setting.
2) The S-GW transmits Update Bearer Request to MME to change QoS setting.
3) The MME starts the E-RAB modification procedure by transmitting E-RAB Modify
Request to the eNB. The E-RAB Modify Request has the QoS information of E-
RAB(s) to change, NAS message to send to a MS, and MODIFY EPS BEARER
CONTEXT REQUEST.
4) When the eNB receives E-RAB Modify Request from the MME, it judges if it is
possible to change the QoS setting of the E-RAB(s). If possible, it re-allocates internal
resources and transmits RRC Connection Reconfiguration to the MS.
5) The MS changes the QoS setting of DRB(s) that is specified in RRC Connection
Reconfiguration and replies RRC Connection Reconfiguration Complete to the eNB.
6) The eNB replies E-RAB Modify Response to the MME. The E-RAB Modify
Response has the success or failure of QoS setting change per E-RAB.
7) The MS transmits NAS message, MODIFY EPS BEARER CONTEXT RESPONSE.

Feature Description
8) The eNB transmits the NAS message received from the MS to the MME.
9) The MME transmits Update Bearer Response to the S-GW.
10) The S-GW transmits Update Bearer Response to the P-GW.

Feature Description
System operation
N/A
Related Counters
E-RAB Modify count is as follows:
LSM
TypeName Type Description
display format
ModQoSAttNbr The number of ERAB Modify attempts. int
ModQoSSuccNbr The number of ERAB Modify successes. int
ModQoSFailNbr_CP_CC_TO A call is released due to call control int
timeout in the protocol blocks (MAC, RLC,
PDCP, GTP) during ERAB Modify.
ModQoSFailNbr_CP_CC_FAIL A call is released due to reset notification int
(eNB failure or block restart) from ECMB or
by the ECCB block during ERAB Modify.
ModQoSFailNbr_UP_GTP_FAIL A call is released due to the failure in the int
GTP block during ERAB Modify.
ModQoSFailNbr_UP_MAC_FAIL A call is released due to the failure in the int
MAC block during ERAB Modify.
ModQoSFailNbr_UP_PDCP_FAIL A call is released due to the failure in the int
PDCP block during ERAB Modify.
ModQoSFailNbr_UP_RLC_FAIL A call is released due to the failure in the int
RLC block during ERAB Modify.
ModQoSFailNbr_RRC_SIG_FAIL A call is released due to receiving RRC int
signaling during ERAB Modify.
ModQoSFailNbr_RRC_SIG_TO A call is released due to ERAB uplink int
message timeout (not received) during
RRC Modify procedure
ModQoSFailNbr_CP_BH_CAC_ A call is released due to insufficient int
FAIL backhaul-based eNB resources during
ERAB Modify.
ModQoSFailNbr_CP_CAPA_CAC A call is released due to insufficient int
_FAIL capacity-based eNB resources during
ERAB Modify.
ModQoSFailNbr_CP_QOS_CAC_ A call is released due to insufficient QoS- int
FAIL based eNB resources during ERAB Modify.

Feature Description
(Continued)
LSM
TypeName Type Description
display format
ModQoSFailNbr_S1AP_CU_FAIL A call is released due to the S1AP int
specification cause during ERAB Modify.
ModQoSFailNbr_S1AP_LINK_FAIL A call is released due to S1 SCTP link int
failure during ERAB Modify.
ModQoSFailNbr_S1AP_SIG_FAIL A call is released due to receiving S1AP int
signaling during ERAB Modify.
ModQoSFailNbr_CP_CC_INTERA The ERAB Modify procedure is requested int
CTION by the MME but it is failed during inter eNB
handover
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW0501, S1 Interface Management

Overview
S1 interface management procedure is to manage the signaling associations between eNB
and MME, surveying S1 interface and recovering from errors, i.e. Error indication and
Reset procedures.
Introduction
S1 Connection with the MME is made by default when the eNB performs boot-up.
Connection target MMEs must be set in advance through LSM. S1 Connection is the
connection among SCTP based NEs. Only one connection between eNB and MME can be
established. The connection set the S1-AP Connection at UE-associated level to the number
of active UEs.
S1 interface management includes S1 setup, reset, error indication, and keep alive
procedure. The S1 Setup procedure is the first S1AP procedure after a TNL association has
been made.
When this procedure is performed, the application level configuration data between eNB
and MME, if there was, is removed and replaced with the newly received data. The eNB
and the MME exchanges application level data such as TAC, PLMN Identity, and CSG Id
data on the S1 interface via S1 Setup procedure. When an abnormal situation occurs, S1
interface of all or some UEs can be initialized through reset procedure. It provides the
function of reducing the signaling load.after receiving overload status from the MME.
In addition, Error Indication procedure can report the fact that the received message can bot
be handled properly.
The Echo Request between the eNB and the S-GW and the Keep alive function by GTP
tunnel using the Echo Response message are performed. The Keep alive function by SCTP
connection using the HEARTBEAT ACK message and the SCTP HEARTBEAT are
performed between the eNB and the MME.
Benefits
This function manages the signaling associations between eNBs, surveying S1 interface
and recovering from errors.
Release History
SLR2.2

Feature Description

Dependency:
 None
Limitation:
 Up to 16 MMEs can be connected.
Reference
1) 3GPP TS36.300, Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network(E-UTRAN); Overall description; Stage 2
2) 3GPP TS36.412, Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
S1 signalling transport
S1 Application Protocol (S1AP)
4) 3GPP TS29.281, General Packet Radio System (GPRS) Tunnelling Protocol User
Plane (GTPv1-U)
5) IETF RFC4960, Stream Control Transmission Protocol
Feature Scope
R1 The operator can configure S1 application level configuration data using the LSM.
R2 The eNB transmits the S1 SETUP REQUEST message that includes the S1
application level configuration data to the MME.
R3 The eNB performs the reset procedure to all or part of UE context over S1 interface.
R4 The eNB rejects RRC Connection Establishment depending on Overload Action IE
when the MME receives the OVERLOAD START message.
R5 The eNB transmits the ERROR INDICATION message if it cannot process the
received message properly and cannot respond with a proper failure message.
R6 The eNB transmits/receives the GTP Echo Request/Echo Response message and
provides the keep alive function.
R7 The eNB transmits/receives the SCTP HEARTBEAT/HEARTBEAT ACK message
and provides the keep alive function.

Feature Description
Feature Description
S1 Interface Management Procedure includes S1 Setup, Reset, Error Indication, Keep Alive
(eNB-to-SGW, eNB-to-MME).
S1 Setup
The eNB initiate the S1 Setup procedure by sending S1 Setup Request message such as
TAC list, PLMN ID list CSG ID List, DRX, eNBName. When the procedure is executed
the existing application level configuration data on eNB, MME is to be deleted and
replaced by the newly received data. The eNB receives the S1 Setup Response messages
including MME Name, GUMMEI, Relative MME Capacity from the MME and stores
them in the internal memory of eNB.
If the eNB receives the S1Setup Failure message, it waits for the Time to Wait value
contained in that failure message, and then resumes the S1Setup procedure. If the eNB fails
to receive the S1 Setup Response message, after a certain amount of time (range: 10~65535
ms, default: 5000 ms), it resumes the S1 Setup procedure.

Feature Description
Reset
The Reset procedure is performed to initialize the entire or some of the UE related contexts
of S1 interface and can be triggered by the eNB or the MME. However, the application
level configuration data, which was exchanged by S1 Setup procedure, is not changed.
If, for some reason, the MME lose the UE related data, it sends the Rest message to the
eNB. The eNB which receives the Reset message release the resource in the S1 and the Uu
interface. The list of UEs, whose resources should be released, can be specified by MME-
UE S1AP ID IE or eNB UE S1AP ID IE on the UE-Associated logical S1-connection list
IE. The eNB sends the Rest Acknowledge message to the MMEs after receiving the Rest
message and then sends the RRC Connection Release message to the target UEs. After that,
the UE related resources, which are controlled by the eNB, are released.

Feature Description
The eNB send the RESET ACKNOWLEDGE message after setting the UE related data to
UE-associated logical S1-connection item IE. The UE-associated logical S1-connection
item IE send the reset message in sequential order. Refer to 3GPP TS 36.413 9.1.8 for
specific details about the message format.
When the eNB decides a specific S/W module is in an abnormal state and unable to provide
the normal service it sends the Reset message to the MME.
Error Indicatoin
When the received message cannot be processed normally and cannot be responded with
the appropriate failure message the Error Indication message is sent. When sending the
Error Indication message which is related to a specific UE the message should include the
MME UE S1AP ID IE and eNB UE S1AP ID IE. When the Error Indication message either
Cause IE or Criticality Diagnostics IE must be included.

Feature Description
Keep Alive between eNB and SGW

When the S1 bearer setting is complete, the keep alive procedure is performed using the
message (Echo Request, Echo Response) defined by GTP-U protocol. The eNB sends the
Echo Request message to S-GW at minimum 60 seconds interval and waits for the Echo
Response message. When the Echo Response is received normally, the eNB sends the Echo
Request message after 60 seconds.
If the eNB fails to receive the Echo Response message, it resends the Echo Request
message up to 5 times. When the eNB fails to receive the Echo Response message even
after resending, the related call is released. Although GTP keep alive targets all GTP
tunnels, the operations are not made at the same time. For example, when there are two
GTP tunnels, keep alive is performed for each of the GTP tunnels sequentially.

Feature Description
When the Echo Request message is received from the S-GW, the Echo Response message
is transmitted. Echo Request message should be sent to UDP port 2152. GTP Keep alive
related parameters can be checked or changed using the RTRV-GTP-INF/CHG-GTP-INF
command. Refer to the 3GPP TS 29.281 for the specific message format.
Keep Alive between eNB and MME

The SCTP interface status can be controlled by the Heartbeat chunk, which is defined by
SCTP protocol (RFC4960), when the MME and the eNB exchanges the Signaling message
via SCTP interface. The target which receives and sends HEARTBEAT chunk is the one
which receives and sends Signaling messages via the TP interface, thus it is multiple
MMEs and neighbor eNBs. keep alive which uses HEARTBEAT performs per SCTP
connection. When it establish SCTP connection with MME (or other eNB), it receives and
sends HEARTBEAT chunk to monitor the reachability of the peer.
Heartbeat transmission interval is 1.5 seconds by default and can be changed using CHG-
SCTP-PARA. When HEARTBEAT ACK is not received, Retransmission is attempted five
times at the four seconds interval by default setting value. If the ACK is not received after 1
second of the retransmission request, one retransmission occurs at the kernel.
When HEARTBEAT ACK is not received after the retransmission, the link status is
considered abnormal. If the MME SCTP connection is considered abnormal the
MME_FAILOVER_TIMER (10 seconds by default) starts operating. The call is not
released when the SCTP connection is restored before the timer expiry. However, when the
MME_FAILOVER_TIMER expires, all calls on the SCTP Connection are released and
‘MME commfail’ for the connection is generated.
However, when the MME_FAILOVER_TIMER expires, all calls on the SCTP Connection
are released and ‘MME commfail’ alarm for the connection is generated. ‘MME commfail’
alarm is generated.

Feature Description
When transmitting heartbeat, the eNB delivers the current time in the Heartbeat
Information field, which is also included in the HEARTBEAT ACK message so that the
heartbeat sender can calculate the Round Trip Time (RTT). The heartbeat receiver also can
calculate it.

Feature Description
System operation
RTRV-S1-STS MmeIndex Index of MME

Range: 0~15
Default: 0
MmeId Id of MME
Range: 0~15
Default: 0
SctpState SCTP state

Range: 0~1
Default: 0
IfState Interface state

Range: 0~1
Default: 0
MmeName[20] MME Name

Range: Char[20]
Default: 0
IPVer The IP address version of the MME

Range: IPv4 or IPv6
Default: IPv4
MmeIpV4 Information on the IPV4 address of the MME.

parameter is set to IPv4. It is not used if the IP_VER
parameter is set to IPv6
Range: 0~255
Default: 0.0.0.0
MmeIpV6[16] Information on the IPV6 address of the eNB.

parameter is set to IPv6. It is not used if the IP_VER
Range: 0~255
Default: 0:0:0:0:0:0:0:0
RTRV/CHG- cellNum The cell number to be changed or retrieved
CELL-INF Range: 0~MAX_CELL_PER_SYS_CDD
Default: 0

Feature Description
(Continued)
RTRV/CHG- trackingAreaCode TAC (Tracking Area Code) used by the active cell.
CELL-INF It is used for warning message transmission and
interruption when paging the UE. This information is
Range: 0x0~0xFF (OCTET STRING (SIZE(2))
Default: 0
RTRV/CHG- CellNum The cell number to be changed or retrieved
CAS-IDLE Range: 0~MAX_CELL_PER_SYS_CDD
Default: 0
csgIdentity The ID of the cell. This is available only if it is a Closed
Subscriber Group (CSG) cell.
Range: 0x0~0x07FFFFFF (BIT STRING (SIZE(27))
Default: 0
forcedMode This parameter defines forced mode for changed value.
(Warning: all of the cell service will be stopped and
restarted, ongoing calls will be disconnected.)
Range: BOOL
Default: 0
RTRV/CHG- defaultPagingCycle When DRX is used, UE monitors a single paging
PCCH-CONF occasion per DRX cycle. If UE-specific DRX is not set
by the upper layer, defaultPagingCycle is applied as the
default DRX cycle
Range: ci_defaultPagingCycle_rf32,
ci_defaultPagingCycle_rf64,
ci_defaultPagingCycle_rf128,
ci_defaultPagingCycle_rf256
Default: ci_defaultPagingCycle_rf256
nB The parameter required to calculate the paging frame
and paging occasion using the TS 36.304 method,
which is a multiple of defaultPagingCycle.
Range: ci_fourT = 0, ci_twoT = 1, ci_oneT = 2, ci_halfT=
3, ci_quarterT = 4, ci_oneEightT= 5, ci_onSixteenthT=
6, ci_oneThirtySecondT= 7
Default: ci_oneEightT
 Related System Parameters: See the related commands.

Feature Description
Counter and KPI

N/A

Status or
Description How to Check
Alarm
RTRV-S1-STS Retrieves the connection status In the LSM CLI, check using RTRV-S1-STS.
of SCTP and S1AP to each
MME.
MME_COMM Generated when: the eNB fails In the LSM CLI, check the alarm status.
UNICATION_F to receive a response to SCTP
AIL heartbeat from all MMEs in
(A3199600) Equip state.
Released when: the eNB
receives a response to SCTP
heartbeat from one MME with
Equip state or more.
Related Call Faults

Call Faults Description How to Check
ECCB_ERRM A call is rejected because there When there is no MME currently in

_ALL_MME_N exists no MME currently in connection even after the RRC Connection
OT_SERVICE connection. Request message is received from RRC_
ESTAB_REJECT
ECCB_ERRM A call is not admitted because When the MME overload occurs and a call is
_MME_OVER overloadAction and connected to establishmetCause to be
LOAD establishmetCause does not rejected even after the RRC Connection
match when the MME is in Request is received from RRC_ESTAB_
Overload state. REJECT
ECCB_ERRM The MME with the PLMN value When MME with the selected PLMN value
_AVAILABLE_ informed by the UE does not informed by the UE exists even after the
MME_NOT_E exist in the RRC Connection RRC Connection Setup Complete message
XIST Setup Complete message. is received from RRC_ESTAB

Feature Description
LTE-SW0502, NAS Signaling Transport

Overview
The NAS Signalling Transport function provides means to transport a NAS message (e.g.
for NAS mobility management) for a specific UE on the S1 interface.
Introduction
The NAS Signalling Transport function provides means to transport a NAS message (e.g.
for NAS mobility management) for a specific UE on the S1 interface.
The signaling procedure of sending/receiving a NAS message is required to exchange NAS
related information between UE and MME. The eNB plays the role of transmitting a NAS
message transparently between UE and MME. For the objective, the eNB creates UE-
associated logical S1 connection in the S1 interface. The creation of UE-associated logical
S1 connection means that the eNB allocates eNB UE S1AP ID and the MME allocates
MME UE S1AP ID to a specific UE.
A NAS message can be transmitted through a message such as INITIAL UE MESSAGE,
DOWNLINK NAS TRANSPORT, UPLINK NAS TRANSPORT, E-RAB SETUP
REQUEST, E-RAB MODIFY REQUEST, or E-RAB RELEASE COMMAND, etc. that is
defined in the S1AP layer.
Benefits
This feature allows eNB to transfer NAS signaling messages between MME and UE.
Release History
SLR2.2 and Later | New Entry | Basic Feature

Dependency:
 None
Limitation:
 None

Feature Description
Reference
[1] 3GPP TS36.300, Evolved Universal Terrestrial Radio Access(E-UTRA) and Evolved
Universal Terrestrial Radio Access Network(E-UTRAN); Overall description; Stage 2
[2] 3GPP TS36.412, Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
S1 signalling transport
[3] 3GPP TS36.413, Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
Feature Scope
The R1. eNB adds the NAS information of RRC Connection Setup Complete message to
the INITIAL UE MESSAGE and then sends it to the MME.
The R2. eNB adds the NAS information of RRC UL INFORMATION TRANSFER
message to the UPLINK NAS TRANSPORT and then sends it to the MME.
The R3. eNB adds the NAS information of DOWNLINK NAS TRANSPORT message to
the RRC DL INFORMATION TRANSFER and then sends it to the UE.
The R4. eNB adds the NAS information in the E-RAB SETUP RQUEST/MODIFY
REQUEST/RELEASE COMMAND to the RRC CONNECTION RECONFIGURATION
message and then sends it to the UE.
When the R5. eNB cannot process a message received from the MME, it transmits the
NAS NON DELIVERY INDICATION message that has an appropriate cause value to the
MME.

Feature Description
Feature Description
A NAS message is transmitted through a S1AP message such as INITIAL UE MESSAGE,
DOWNLINK NAS TRANSPORT, UPLINK NAS TRANSPORT, or NAS NON
DELIVERY INDICATION, etc. in the S1-MME interface. In addition, when a message
such as E-RAB SETUP REQUEST, E-RAB MODIFY REQUEST, or E-RAB RELEASE
COMMAND, etc. is received from the MME, the content of NAS PDU IE is added to the
DedicatedInfoNAS IE of RRC CONNECTION RECONFIGURATION message and
transmitted to the UE.
INITIAL UE MESSAGE
If a UL NAS message that must be transmitted to the MMM is received when there is no
UE related logical S1 connection (for example, the ATTACH REQUEST message is
received after it is added to the RRC CONNECTION SETUP COMPLETE message), the
eNB transmits INITIAL UE MESSAGE to the MME. The INITIAL UE MESSAGE
includes the following information.
 NAS message to NAS PDU IE
 UE S1AP ID allocated by the eNB
 TAI
 S-TMSI IE (if available)
 CSG ID IE (connected from a CSG cell)
 CSG ID and Cell Access Mode IE (connected from a hybrid cell)
DOWNLINK NAS TRANSPORT

When the MME receives INITIAL UE MESSAGE, the MME UE S1AP ID, that can be
used as an identifier for a specific UE in the S1AP layer, is allocated and then the
DOWNLINK NAS TRANSPORT message is transmitted. In this message, MME UE
S1AP ID, eNB UE S1AP ID, and NAD PDU are always included and Handover Restriction
List may be included.
 The NAS PDU IE transmits to the UE transparently.
 If the Handover Restriction List IE is included, the information is reflected and
handover related target information is provided.
 The eNB adds the NAS message and RRC DL INFORMATION TRANSFER message
in the DOWNLINK NAS TRANSPORT to the DedicatedInfoNAS IE and transmits to
the UE.

Feature Description

This is a message that is used to transmit a NAS message to the MME when the UE
associated logical S1 connection is created. This message always has MME UE S1AP ID,
eNB UE S1AP ID, NAD PDU, E-UTRAN CGI, or TAI and it is transmitted to the MME
transparently. Therefore, the MME can know the TAI and ECGI information maintained by
the current UE.
The UE adds the NAS message to the DedicateInfoNAS IE of RRC UL INFORMATION
TRANSFER and the eNB transmits it to the MME through the NAS PDU IE of UPLINK
NAS TRANSPORT message.

When the eNB cannot process a message received from the MME, it adds the received
NAS message to the NAS PDU IE and also an appropriate cause value and then transmits
the NAS NON DELIVERY INDICATION message to the MME.

Feature Description
System operation
The NAS signaling message is transparent to the eNB and the detail parameters are
working based on the NAS protocol between UE and MME.
The IEs in other NAS signaling messages are configured as follows:
 The eNB-UE-S1AP ID is allocated depending on the allocation of internal resources.
 The TAI consists of the serving PLMN of a UE and the tracking area code of a
connection area.
 The E-UTRAN CGI is dependent on the ECGI value of a connected cell. (Here, the
PLMN ID of ECGI is set to the primary PLMN of a specific eNB and it cannot be
changed arbitrarily. The configuration of eNB ID or Cell ID varies depending on a
service provider’s request.)
 The CSG ID is working based on the CSG ID of a specific cell.
Parameters Description Remark
cellNum The cell number to be changed or retrieved. Use the RTRV-

Range: 0~MAX_CELL_PER_SYS_CDD CELL-INF or
Default: 0 CHG-CELL-INF
command for
retrieval or
change.
mcc0~mcc5 Mobile Country Code (MCC) 0~5 which is broadcasted -
in the cell. Here, mcc0 should be the primary PLMN ID’s
mcc.
Range: 0x0~0xFFF
Default: 0xFFF
mnc0~mnc5 Mobile Network Code (MNC) 0~5 which is broadcasted -
in the cell. Here, mnc0 should be the primary PLMN ID’s
mnc.
Range: 0x0~0xFFF
Default: 0xFFF
trackingAreaCode TAC (Tracking Area Code) used by the active cell. It is -
used for warning message transmission and interruption
when paging the UE. This information is broadcast to
UE via SIB 1.
Range: 0x0~0xFF (OCTET STRING (SIZE(2))
Default: 0

Feature Description
(Continued)
Parameters Description Remark
CellNum The cell number to be changed or retrieved. Use the RTRV-CAS-

Range: 0~MAX_CELL_PER_SYS_CDD IDLE or CHG-CAS-
Default: 0 IDLE command for
retrieval or change.
csgIdentity The ID of the cell. This is available only if it is a Closed -
Subscriber Group (CSG) cell.
Range: 0x0~0x07FFFFFF (BIT STRING (SIZE(27))
Default: 0
forcedMode This parameter defines forced mode for changed -
value. (Warning: all of the cell service will be stopped
and restarted, ongoing calls will be disconnected.)
Range: BOOL
Default: 0

N/A

S1MsgSnd Number of times the eNB transmits S1AP Protocol Replace S1 Message
Msg (But, collected for all the messages as well as
management purpose S1 message)
S1MsgRcv Number of times the eNB receives S1AP Protocol Msg Replace S1 Message
(But, collected for all the messages as well as
management purpose S1 message)
Related Call Faults

N/A

Feature Description
LTE-SW0503, MME Overload Control

Overview
The MME overload control function is carried out to reduce the signalling traffic of the
MME in the overload status.
Introduction
eNB cooperates with MME to handle the overload situation of the MME. Overloaded
MME sends Overload Start message to eNB with ‘Overload Action’ IE, then eNB restricts
RRC connection requests towards the overloaded MME. The MME can control overload
by adjusting the number of eNBs that will request overload start based on overload level.
However, this kind of function may be different depending on MME algorithm.
Benefits
Signalling load reduction toward overloaded MME.
Release History

Dependency:
 MME
Limitation:
 None
Reference
[1] 3GPP TS36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
[2] 3GPP TS36.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
Feature Scope
When the OVERLOAD START message is received from the R1. MME, the eNB rejects
or admits a call depending on the overload action requested by the MME. This overload
action is continued until the Overload Stop message is received from the MME.
The R2. eNB applies load balancing between MMEs by considering overload action for a
new call that does not has a registered MME.

Feature Description
Feature Description
The MME executes the MME Overload Control function to reduce the signaling load of a
specific MME if there occurs overload. The MME Overload Control function of eNB is
applied to a MME when the OVERLOAD START message is received from the MME.
This operation is continued until the OVERLOAD STOP message is received from the
MME.
The overload actions directed by the MME are as follows: (Refer to 3GPP TS36.413
Section 9.2.3.20.)
 Reject all RRC connection establishments for non-emergency MO DT
 Reject all RRC connection establishments for Signalling
 Permit Emergency Sessions and mobile terminated services only
 Permit High Priority Sessions abd mobile terminated services only
 Reject delay tolerant traffic
In case of ‘reject all RRC connection establishments for non-emergency MO DT’, the eNB
rejects RRC connection establishment if the EstablishmentCause is ‘mo-data.’ In case of
‘reject all RRC connection establishments for Signaling’, the eNB rejects RRC connection
establishment if the EstablishmentCause is ‘mo-signaling.’ In case of ‘Permit Emergency
Sessions and mobile terminated services only’, the eNB accepts RRC connection
establishment only if the EstablishmentCause is ‘emergency’ or ‘mt-Access.’
The processing procedure of eNB is shown below when the RRCConnectionRequest

Feature Description
1) After the ‘RRCConnectionRequest’ message is received from the UE, whether the s-
TMSI (in InitialUE-Identity) exists is determined. If the s-TMSI value exists, step 2 is
performed. Otherwise, step 3 is performed.
2) If the s-TMSI exists, the MME can be ascertained. Hence, whether to perform
overload control for the MME is determined using the overloadStatus value in the
mmeDBinfo of the MME.
− If the MME is not in the overload status, step 4 is performed.
− If the MME is in the overload status, call admission is determined by comparing
the overloadAction value in mmeDBinfo with the EstablishmentCause value (in
RRCConnectionRequest). If the call is admitted, step 4 is performed. Otherwise,
step 5 is performed.
3) If the s-TMSI does not exist, and the randomValue exists, the overloadStatus value is
checked from all mmeDBInfo. If all MMEs are in the overload status, whether to
admit the call is determined by comparing the overloadAction value of each MME
with the EstablishmentCause value of the UE. If the call is admitted, step 4 is
performed. Otherwise, step 5 is performed.
4) ‘Success’ is returned for the MME overload control.
5) ‘Fail’ is returned for the MME overload control.

Feature Description
The processing procedure of eNB is shown below when the RRCConnectionSetup

Complete message is received.
1) After receiving the ‘RRCConnectionSetupComplete’ message from the UE, the eNB
determines whether the ‘RegisteredMME’ value exists. If the RegisteredMME value
exists, step 2 is performed. Otherwise, the MME Load Balancing function is carried
out.
2) If RegisteredMME exists, it is compared with the MMEC of the s-TMSI which is in
mmeDBinfo of the UE. If the MMEC is the same, step 3 is performed. Otherwise, the
MME load balancing function is carried out.
3) If RegisteredMME exists in the mmeDBinfo of the eNB, step 4 is performed.
Otherwise, the MME load balancing function is carried out.

Feature Description
4) If RegisteredMME exists, whether to perform overload control is determined from the

overloadStatus value in mmeDBinfo of the MME.
5) If the MME is not in the overload status, step 6 is performed. If the MME is in the
overload status, whether to admit the call is determined by comparing the
overloadAction value in mmeDBinfo with the EstablishmentCause value in the
RRCConnectionRequest message. If the call is admitted, step 6 is performed.
Otherwise, step 7 is performed.
6) The eNB increases the numAllocUe value in the mmeDBInfo and returns ‘Success’ for
the MME overload control.
7) The eNB returns ‘Fail’ for the MME overload control.

Feature Description
System operation
CHG-MME-CONF mmeIndex Changes MME related

status parameter information.
administrativeState
mmeMcc
mmeMnc
RTRV-MME-CONF mmeIndex Retrieves MME related
status parameter.
administrativeState
mmeMcc
mmeMnc
mmeIndex Because the total number of MMEs that can be Use the RTRV-MME-
connected to the eNB is 16, the index range is CONF or CHG-MME-
0-15. CONF command for
Range: 0~15 retrieval or change.
Default: 0
status EQUIP status information of MME. Use the RTRV-MME-
- N_EQUIP: When there is no MME to connect CONF or CHG-MME-
(default). CONF command for
- EQUIP: When there is a MME to connect retrieval or change.
Range: 0~1
Default: 0
administrativeState Status value of a MME link. Use the RTRV-MME-
- locked: The active calls connected to the CONF or CHG-MME-
MME are all dropped and no new call is CONF command for
allowed to be connected to the MME. retrieval or change.
- shuttingDown: The active calls connected to
the MME are maintained, but no new call is
allowed to be connected to the MME.
Range: 0~2
Default: 1

Feature Description
(Continued)
mmeMcc PLMN information (MCC) that represents a MME. Use the RTRV-MME-
Enter 3-digit whose each digit is 0-9. CONF or CHG-MME-
CONF command for
mmeMnc PLMN information (MNC) that represents a MME. Use the RTRV-MME-
Enter 3-digit or 2-digit whose each digit is 0-9. CONF or CHG-MME-
CONF command for

N/A

N/A
Related Call Faults

RRM_MME_ When the MME is in Overload status, cannot Necessary to check the
OVERLOAD accommodate the calls because overloadAction and status of resources in the
establishmetCause does not match. eNB.

N/A

N/A

Feature Description
Related Call Faults

RRM_MME_OV When the MME is in Overload status, it cannot Necessary to check

ERLOAD accommodate the calls because overloadAction and the status of
establishmetCause does not match. resources in the eNB.
RRM_AVAILABL There is no MME that has a plmn value that is Necessary to check
E_MME_NOT_E uploaded by a UE to the RRC Connection Setup the status of
XIST Complete. resources in the eNB.

Feature Description
LTE-SW0504, SW0505, MME Selection and Load

Balancing
Overview
When eNB receives a RRC connection request message from a UE, eNB searches and
selects a MME that has served the UE before. The selection is based on registered MME
information in the message. Otherwise, eNB performs load-based MME selection function
for a new call that has registered MME information in the message.
Introduction
MME selection function is a procedure to assign a new call to a MME, considering load
balancing among MMEs in the same pool. The UE that has registered to a MME will be
assigned the same MME for mobility control, which makes the UE use the same IP address
that PGW assigned. If the UE has never been assigned a MME, eNB will assign the UE to
one of MMEs considering load among MMEs.
eNB performs MME selection when it receives RRCConnectionSetupComplete message
from UE. Registered MME information in the RRC Connection Setup Complete message
will determine whether the eNB assigns a new MME or looks for an old MME.
Load balancing among MMEs will be based on Relative MME Capacity Information that
MME provides in S1 SETUP RESPONSE or MME CONFIGURATION UPDATE
message.
MME has responsibility in deciding its capacity relative to other MMEs.
Benefits
 UE can keep the same MME while it moves around even in idle mode, so that the UE
can use the same IP address.
 Load is distributed over multiple MMEs. Operator can control relative load of a
specific MME by adjusting Relative MME Capacity at each MME.
Release History

Dependency:
 Load balancing between MMEs is based on relative capacity information that the
MMEs provide.
Limitation:
 eNB supports up to 16 MMEs.

Feature Description
Reference
[2] 3GPP TS36.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
Feature Scope
R1 If the RRC Connection Request message of a UE has S-TMSI, the eNB finds and
allocates an old MME that has the context of the UE.
R2 The eNB must allocates a new UE in proportion to the capacity between MMEs based
on the RelativeMMECapacity that is sent through the S1 SETUP RESPONSE or
MME CONFIGURATION UPDATE message between MMEs.
Feature Description
The UE transmits the registered MME information during eNB and RRC connection setup
procedure (When you look at the below call flow, you can see the registered MME
information can be added to the RRC Connection Setup Complete message that is sent by
the UE.) Based on this information, the eNB determines whether to allocate a new MME to
the UE or find and allocate a MME where the UE had been allocated.
The UE does not provide the registered MME information when it does Power On or it
wants to change. For the Idle to Activation, the registered MME information is provided.

Feature Description
If it is necessary to allocate a new MME because there is no registered MME information

provided by the UE. And the eNB allocates MMEs in proportion to the MME capacity to
distribute loads. The Relative MME Capacity information is sent to the eNB by the MMM
through S1 setup response or MME Configuration Update message. If the Relative MME
Capacity is 0, a new UE will not be allocated to the MME.
The algorithm of MME selection is as follows:

Feature Description

Feature Description
1) When the Relative MME Capacity IE is received using the S1 SETUP RESPONSE
and MME CONFIGURATION UPDATE messages, it is saved in the mmeLBportion
(= RelativeMMECapacity) parameter in the mmeDBInfo.
2) When the MME selection & load balancing procedure starts, If Registered MME
exists, step 3 is performed. Otherwise, step 4 is performed.
3) If RegisteredMME is identical to the MMEC of the s-TMSI, the following step is
performed. Otherwise, step 4 is performed. It is checked whether the MMEC owned
by the s-TMSI exists in the mmeDBInfo. If it exists, step 6 below is performed.
Otherwise, step 5 below is performed.
4) If s-TMSI exists in callInfo, the following step is performed. Otherwise, step 5 is
performed. It is checked whether the MMEC owned by the s-TMSI exists in the
mmeDBInfo.
 If the MMEC exists, the overloadStatus of the corresponding MME(s) is checked in
the mmeDBInfo. If ‘overloadStatus==ON’, the local variable ‘sTmsiMmeOverStat’
is set to 1 and then step 5 is performed. Otherwise, step 6 is performed.
 If MMEC does not exist, step 5 is performed.
5) The MME that has the selected PLMN ID is selected from the mmeDBInfo. If all
MMEs selected in step 5 are in the overload status, the available MMEs are selected
by comparing the overloadAction value of each MME with the EstablishmentCause
value of the UE. If there is no MME that can be admitted, step 7 is performed.
 If the local variable ‘sTmsiMmeOverStat’ is set to 1 and if the MMECs with s-
TMSI exist among the MMEs selected in step 5, step 6 is performed. Otherwise, the
MME with the highest mmeCapacityFactor value is allocated and then step 6 is
performed. [mmeCapacityFactor = mmeLbPortion/(1 + mmeLbAllocUE)]
 When the local variable ‘sTmsiMmeOverStat’ is not set to 1, the MME with the
highest mmeCapacityFactor value is allocated and then step 6 is performed.
 If all MMEs selected in step 5 are not in the overload status, the MME which has
the highest mmeCapacityFactor value and whose overloadStatus is set to OFF in
mmeDBInfo is allocated, and then step 6 is performed.
6) The mmeLBallocUe value of the selected MME is increased or decreased, and then
‘MME Selection & Load Balancing Success’ is returned.
7) ‘MME Selection & Load Balancing Fail’ is returned.

Feature Description
System operation
CHG-MME-CONF mmeIndex Changes MME related

status parameter information.
administrativeState
mmeMcc
mmeMnc
RTRV-MME-CONF mmeIndex Retrieves the MME
status related parameters.
administrativeState
mmeMcc
mmeMnc
mmeIndex Because total 16 MMEs can be connected to an Retrieves or changes

eNB, the index has 0-15. using the RTRV-MME-
Range: 0~15 CONF or CHG-MME-
Default: 0 CONF command.
status EQUIP status information of the MME. Retrieves or changes
- N_EQUIP: There is no MME to connect (default). using the RTRV-MME-
- EQUIP: There is a MME to connect. CONF or CHG-MME-
Range: 0~1 CONF command.
Default: 0
administrativeState Status of MME link. Retrieves or changes
- locked: The active calls connected to the MME using the RTRV-MME-
are all dropped and no new call is allowed to be CONF or CHG-MME-
connected to the MME. CONF command.
- unlocked: Normal connection to the MME.
- shuttingDown: The active calls connected to the
MME are maintained, but no new call is allowed
to be connected to the MME.
Range: 0~2
Default: 1

Feature Description
(Continued)
mmeMcc PLMN information (MCC) that represents the Retrieves or changes

MME. Enter 3-digit number whose each digit range using the RTRV-MME-
is 0-9. CONF or CHG-MME-
CONF command.
mmeMnc PLMN information (MNC) that represents the Retrieves or changes
MME. Enter 3-digit or 2-digit number whose each using the RTRV-MME-
digit range is 0-9. CONF or CHG-MME-
CONF command.

N/A

N/A
Related Call Faults

RRM_MME_OVER When the MME is in Overload status, it cannot Necessary to check

LOAD accommodate the calls because overloadAction the status of
and establishmetCause does not match. resources in the eNB.
RRM_AVAILABLE_ There is no MME that has a plmn value that is Necessary to check
MME_NOT_EXIST uploaded by a UE to the RRC Connection Setup the status of
Complete. resources in the eNB.

Feature Description
LTE-SW0506, eNB Configuration Update

Overview
The eNB Configuration Update procedure is used to provide updated configured data in
eNB.
Introduction
The eNB Configuration Update procedure is used to provide updated configured data in
eNB.
Benefits
Operator Benefits:
 Update application level configuration data needed for two eNBs to interoperate
correctly over the X2 interface.
End User Benefits:

 None
Release History
SLR2.2

Dependency:
 None
Limitation:
 None
Reference
application protocol (S1AP)
3) 3GPP TS36.423 Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
X2 application protocol (X2AP)

Feature Description
Feature Scope
S1 AP eNB Configuration Update
1) When TAC, CSGID, eNBName, DefaultPagingDRX values are changed during
operation, eNB transmits eNB Configuration Update message to MME including with
parameters that not changed.
2) When it sends eNB Configuration Update message, timer starts.
3) If it didn’t receive eNB Configuration Update Acknowledge before timer expires, eNB
retransmits eNB Configuration Update message and timer restart.
4) When it receives eNB Configuration Update Failure message or timer expires, eNB re-
send eNB Configuration Update message.
At this time, retransmission time is configurable by CHG-TIMER-INF command.
Default value is 3.
X2 AP eNB Configuration Update

1) When eNB #1 recognizes the application level data has been changed and needs to be
updated, it sends the X2AP eNB Configuration Update Acknowledge message to eNB #2.
2) When it receives the X2AP eNB Configuration Update message, eNB #2 stores the
related information in the DB and then sends the X2AP eNB Configuration Update
Acknowledge message to eNB #1.

Feature Description
Feature Description
S1 AP eNB Configuration Update
When the eNB wants to update the application level data that has an effect to the UE-
related context, the eNB can send the eNB Configuration Update message to the MME
with which the eNB has an established S1 connection currently.
If the current TAC, CSGID, eNBName, or DefaultPagingDRX value set in the PLD is
changed during system operation, the eNB includes not only the changed parameter
values but also the unchanged parameter values in the eNB Configuration Update
message, and sends it to the MMEs.
At this time, the eNB must send the message to all MMEs with S1 Setup established.
When the eNB Configuration Update message is sent, a timer starts.
The eNB expects an eNB Configuration Update Acknowledge message to be received

before the timer expires.
If the eNB configuration update acknowledge message is not received before the timer
expires, the eNB kills the timer, resends the eNB configuration update message, and
restarts the timer.
The eNB retransmits the eNB configuration update message when the eNB
configuration update failure message is received or the timer expires. This
retransmission count can be changed using the CHG-TIMER-INF command.
The default is 3 times.
X2 AP eNB Configuration Update

This function is used when application level data needs to be updated between two
eNBs interacting over the X2 interface. (Application level data includes served cell
information, neighbor information, GU group ID list, etc.)
If the eNB recognizes the PLD has been changed in the LSM, it checks whether the
changed PLD requires an update of the application level data. If necessary, it performs
the X2 AP eNB Configuration Update procedure.

Feature Description
System operation
The commands related to S1 AP Related Control are as follows.
CHG-ENB-INF enbName Range: -128~127, Default: ‘ENB0’

RTRV-ENB-
INF
CHG-CELL- trackingAreaC TAC (Tracking Area Code)
INFO ode Range: 0x0~0xFFFF, Default: 0
RTRV-CELL- mcc0~5 MCC (Mobile Country Code) of configuring PLMN (Public Land
INFO Mobile Network)
mnc0~5 MNC fo configuring PLMN
CHG-CAS- csgIdentity CSG (Closed Subscriber Group) Cell ID
IDLE Range: 0x0~0x07FFFFFF, Default: 0
RTRV-CAS-
IDLE
CHG-PCCH- defaultPaging ci_defaultPagingCycle_rf32 = 0,
CONF Cycle ci_defaultPagingCycle_rf64 = 1,
RTRV-PCCH- ci_defaultPagingCycle_rf128 = 2,
CONF ci_defaultPagingCycle_rf256 = 3
Range: 0~3, Default: 3

N/A

N/A
Related Call Faults

N/A

Feature Description
LTE-SW0507, RIM Procedure

Overview
RAN Information Management (RIM) procedures exchange the arbitrary RAN information
(e.g. SIB) between RAN nodes belonging to different RATs. The RAN information is
transparently transferred via core network nodes (MME and SGSN).
Introduction
If a UE already knows the radio access information of a target system when it moves from
LTE to 3G or vice versa, the time required to connect to the target system can be reduced.
The RIM procedure is a standard procedure that allows RAN information exchange
between Inter-RAT. The RIM information usually has system information block messages.
When a 3G neighbor is added to the eNB, the eNB acquires the system information of the
cell from the 3G network and saves it into the eNB. This 3G system information is
provided to a UE when the UE moves from LTE to 3G (Enhanced Redirection or CSFB,
etc.) to reduce the connection time to the 3G network.
A target RAN system (e.g. 3G) must also support the RIM procedure to use the RIM
procedure. The MME plays the role of a router that sends a RIM message to an appropriate
target system.
Benefits
eNB can provide 3G system information for UEs so that they can attach to 3G network
quickly. This will help UEs reduce connection setup time during CSFB or handover.
Release History

Dependency:
 3G network should support the RIM procedure.
 MME should support the routing of RAN message
Limitation:
 None

Feature Description
Reference
Overall description; S1 Application Protocol (S1AP)
Feature Scope
R1 When a 3G neighbor cell is added to an eNB, the eNB requests RAN information to
the 3G network using the eNB DIRECT INFORMATION TRANSFER message.
R2 If the system information of a target cell is stored in the eNB, the eNB provides the
system information of the target cell to the UE during enhanced redirection, CSFB, or
PS handover.
Feature Description
System Information (SI) of UTRAN is helpful for UE to shorten the 3G access time when
UE moves from LTE to 3G network during PS handover or CSFB procedure. By RIM
procedure, eNB can obtain System Information of UTRAN neighboring cells.
Below is the call flow that eNB obtains system Information from 3G network.
The procedure is triggered when eNB adds an UTRAN neighbor cell by initial build of 3G
neighbors or change of 3G neighbor list or addition of a new 3G neighbor by inter-RAT
ANR procedure. eNB sends an eNB DIRECT INFORMATION TRANSFER message to
MME, which route the message to an appropriate 3G RNC. The RIM Transfer IE within
the Inter-system Information Transfer Type IE shall contain the RIM Routing Address IE
that identifies the final RAN destination node where the RIM information needs to be
transferred to by the core network. In case of transfer to UTRAN the source eNB shall
include the RAC IE in the Target RNC-ID IE within the RIM Routing Address IE. In case
of successful procedure, the eNB receives MME DIRECT INFORMAITON TRANSFER
message from MME. Those messages are defined in 3GPP TS 36.413.

Feature Description

Feature Description
System operation
RTRV-HO-OPT See the following subsection. Retrieves the handover-related information.

CHG-HO-OPT See the following subsection. Changes the handover-related information.
It can change the E-RAB interaction
method configured for the eNB, the
neighbour cell list (NCL) inclusion status, or
the uplink data forwarding status at the
target eNB.
RTRV-NBR- See the following subsection. Retrieves the UTRAN neighbouring cell
UTRAN information near the eNB. It uses the
CELL_NUM and RELATION_IDX
parameter values to retrieve only the
specified UTRAN neighboring cell
information. If no CELL_NUM or
RELATION_IDX parameter values are
entered, all UTRAN neighboring cell
information is retrieved.
CHG-NBR- See the following subsection. Changes the UTRAN neighboring cell
parameter values to change the UTRAN
neighboring cell information.
CRTE-NBR- See the following subsection. Creates the UTRAN neighboring cell
parameter values to create the UTRAN
neighboring cell information. Any
parameters not entered are set to the
default values.
DLT-NBR-UTRAN See the following subsection. Deletes the UTRAN neighboring cell
information near the eNB. It uses the
parameter values to delete the UTRAN

Feature Description
dbIndex Tuple index. Retrieves or changes

Range: using the RTRV-HO-
Default: 0 OPT or CHG-HO-OPT
erabInteraction Whether to process which procedure if E-RAB command.
procedure and handover procedure compete with
each other.
0: The handover is prioritized (Handover Prior).
1: The E-RAB procedure is prioritized (ERAB Prior).
Range: 0 or 1
Default: 1
usedNbrList Indicates the method of providing the neighbor cell
list contained in the MeasObjectEUTRA of the RRC
Connection Reconfiguration message.
0: Only the neighbor cells where CIO value is not
dB0 are contained in the list (By Algorithm).
1: The neighbor cells where CIO value is dB0 are
also contained in the list (Force Used).
Range: 0 or 1
Default: 0
numOfeNB Number of target eNBs to perform multi-target
preparation during handover. You can enter to make
max. 4 eNBs perform preparation. If ‘1’ is entered,
the multi-target preparation is not executed.
Range: 1~4
Default: NUM_OF_ENB
rimEnable Indicates whether to enable the RIM procedure.
Range: True or False
Default: False
mmeSelectFactor Weight to select MME to perform RIM procedure.
ForRim Range: 0~15
Default: 0

Feature Description
(Continued)
cellNum No. of a cell to change Retrieves, changes

Default: 0 creates, or deletes
relationIdx The DB index of the UTRAN neighbor cell. using the RTRV-NBR-
Range: 0~255 UTRAN, CHG-NBR-
Default: 0 UTRAN, CRTE-NBR-
UTRAN, or DLT-NBR-
status Indicates whether the information on the UTRAN
UTRA command.
neighbor cell located near the eNB is valid.
N_EQUIP: The UTRAN neighbor cell information is
not valid.
EQUIP: The UTRAN neighbor cell information is valid.
Range: N_EQUIP or EQUIP
Default: N_EQUIP
rncId Indicates the RNC ID of the UTRAN neighbor cell
located near the eNB.
Range: 0x00~0xFFF
Default: 0
cId CID of a UTRAN neighbor cell located near the eNB.
Range: 0x00~0xFFFF
Default: 0
lac Location Area Code of a UTRAN neighbor cell that
is located near the eNB
Range: 0x00~0xFFFF
Default: 0
rac Routing Area Code of a UTRAN neighbor cell that is
located near the eNB
Range: 0x00~0xFF
Default: 0
reserved2 Reserved field

Feature Description
(Continued)
mcc0[4] Broadcast PLMN list information (MCC) of a UTRAN Retrieves, changes

neighbor cell located near the eNB. Enter 3-digit creates, or deletes
number whose each digit range is 0-9. using the RTRV-NBR-
Range: -128~127 UTRAN, CHG-NBR-
Default: ‘DIGIT_MCC’ UTRAN, CRTE-NBR-
mnc0[4] Broadcast PLMN list information (MNC) of a UTRAN UTRAN, or DLT-NBR-
neighbor cell located near the eNB. Enter 3-digit or UTRA command.
2-digit number whose each digit range is 0-9.
Range: -128~127
Default: ‘DIGIT_MNC’
mcc1[4] Broadcast PLMN list information (MCC) of a UTRAN
neighbor cell located near the eNB. Enter 3-digit
number whose each digit range is 0-9.
Range: -128~127
Default: ‘FFF’
mnc1[4] Broadcast PLMN list information (MNC) of a UTRAN
neighbor cell located near the eNB. Enter 3-digit or
Range: -128~127
Default: ‘FFF’
Range: -128~127
Default: ‘FFF’
Range: -128~127
Default: ‘FFF’
Range: -128~127
Default: ‘FFF’
Range: -128~127
Default: ‘FFF’

Feature Description
(Continued)
mnc4[4] Broadcast PLMN list information (MNC) of a UTRAN Retrieves, changes

neighbor cell located near the eNB. Enter 3-digit or creates, or deletes
2-digit number whose each digit range is 0-9. using the RTRV-NBR-
Range: -128~127 UTRAN, CHG-NBR-
Default: ‘FFF’ UTRAN, CRTE-NBR-
mcc5[4] Broadcast PLMN list information (MCC) of a UTRAN UTRAN, or DLT-NBR-
neighbor cell located near the eNB. Enter 3-digit UTRA command.
Range: -128~127
Default: ‘FFF’
Range: -128~127
Default: ‘FFF’
duplexType Duplex type information of a UTRAN neighbor cell
- ci_FDD: Frequency Division Duplex.
- ci_TDD: Time Division Duplex.
Range: enumDuplexMode_type
Default: 0
pScmCode The primary scramble code of the UTRAN neighbor
cell located near the eNB (for FDD)
Range: 0~511
Default: 0
cellParaId Cell parameter ID information of a UTRAN neighbor
cell near the eNB.(TDD)
Range: 0~127
Default: 0
arfcnUl Uplink ARFCN (Absolute Radio Frequency Channel
Number) of a UTRAN neighbor cell located near the
eNB.
Range: 0~16383
Default: 0
arfcnDl Downlink ARFCN (Absolute Radio Frequency
Channel Number) of a UTRAN neighbor cell located
near the eNB.
Range: 0~16383
Default: 0

Feature Description
(Continued)
isRemoveAllowed Whether to be able to delete a neighbor cell in an Retrieves, changes

eNB using the Automatic Neighbor Relation (ANR) creates, or deletes
function. using the RTRV-NBR-
- True: Can delete a neighbor cell. UTRAN, CHG-NBR-
- False: Cannot delete a neighbor cell. UTRAN, CRTE-NBR-
Range: True or False UTRAN, or DLT-NBR-
Default: True UTRA command.
isHOAllowed Whether to perform handover to the UTRAN
neighbor cell.
- True: Handover is allowed.
- False: Handover is not allowed.
Default: True
rimStatus Indicates the RIM connection status.
Range: enumRimStatus_type
Default: 0
voipIncapable Indicates whether the relevant UTRAN neighbor
cell supports the VoIP.
Range: True or False (True: VoIP supported, False:
VoIP not supported)
Default: True
rimSupport Indicates whether the UTRAN neighbor cell
supports the RIM.
Range: True or False (True: RIM supported,
False:RIM not supported)
Default: False
ownerType Indicates the procedure where the neighbor is
allocated.
Range: Initial NRT, ANR by Server, ANR by UE,
Created by User Command,
CreatedByUserUI
Default: CreatedByUserCommand
highPriorityForCsfb Decide whether to apply CSFB_Hysteresis when
performing CSFB with PS HO to a neighboring cell.
Default: False

N/A

Feature Description

N/A
Related Call Faults

N/A

Feature Description
LTE-SW0521, X2 Interface Management

Overview
X2 interface management procedure is to manage the signalling associations between eNBs,
surveying X2 interface and recovering from errors, i.e. Error indication and Reset
procedures.
Introduction
X2 interface is a means for direct communication of neighbor eNBs, and it makes LTE
system different from 3G system with regard to the network structure. The X2 interface is
used for the handover between eNBs. The X2 handover omits the steps comparing to S1
handover and reduces the total handover time. And it may reduce the HO time exchanging
the HO messages instead of exchanging the handover messages between eNBs through the
MME depending on backhaul network structure. Also, the X2 interface is a means for
exchanging load information and interference information between neighbor eNBs.
Based on it, Inter-Cell Interference Coordination (ICIC) and Inter-Cell Load Balancing can
be used.
The X2 interface has control plane and user plane. The control plane connect X2 and AP
via the SCTP protocol and make it possible to exchange signaling messages such as X2
handover, load information, and interference information. The user plane uses the GTP
tunnels to forward the user data from the source eNB to the target eNB at handover.
When a neighbor cell is added to the eNB, the eNB automatically sets up X2 connection
with the eNB which includes the target cell. The IP address of target eNB is required to set
up X2 connection, use the Automatic Neighbor Relation (ANR) function to learn the steps
for getting the IP address.
The X2 connection is a connection SCTP-based between eNBs in the X2 application layer.
The X2 interface management function includes all procedure such as setup and monitoring
the X2 connection, processing errors, and resetting to manage the X2 connection.
Benefits
 This feature enables operator to manage the signalling associations between eNBs,
surveying X2 interface and recovering from errors.
 Efficient usage of the radio resources with the help of X2 interface management.
Release History
SLR2.2

Feature Description

Dependency:
 None
Limitation:
 upto 256 X2 connections according the 3GPP Standard.
Reference
X2 application protocol (X2AP)
3) IETF RFC4960, Stream Control Transmission Protocol
Feature Scope
R1 The eNB sets the X2 connection with a neighbor cell.
R2 The eNB monitors the X2 connection periodically through the keep alive message,
and inform errors to the operator when an error is generated.
R3 If an abnormal failure occurs with the X2 connection, reset the X2 connection.
R4 The eNB supports up to 256 X2 interfaces.

Feature Description
Feature Description
X2 AP Setup
This function is used when the X2 interface is set up between two eNBs for the first time.
The following figure shows the X2 AP setup procedure.
Below figure is X2 AP Setup Procedure 1.
1) eNB #1 sends its global eNB ID, served cell information, neighbor information, and
GU group ID list information to eNB #2 using the X2 Setup Request message.
2) eNB #2 receives the X2 Setup Request message and stores the information contained
in it in appropriate locations. Then eNB #2 sends its global eNB ID, served cell
information, neighbor information, and GU group ID list information to eNB #1 using
the X2 Setup Response message.
Below figure is X2 AP Setup Procedure 2.
1) eNB #1 receives the X2 setup failure message from eNB #2.

2) eNB #1 waits as long as Time To Wait as included in the X2 setup failure message and
then resends the X2 setup request message to eNB #2.

Feature Description
X2 AP Reset
If an abnormal failure occurs with the X2 interface between two interacting eNBs, this
function reconciles the resources between the two eNBs. The following figure shows the
X2 AP reset procedure.
Below figure is X2 AP Reset Procedure 1.
1) eNB #1sends the X2 Reset Request message to eNB #2.

2) eNB #2 sends the X2 Reset Response message to eNB #1. If there are any procedures
which eNB #1 is carrying out via the X2 Interface, eNB #2 stops all of them and
performs the Call Release procedure for the call.
Below figure is X2 AP Reset Procedure 2.
1) When receiving the msgCeccbCellReleaseInd message from the ECMB, the ECCB of
eNB #1 lists the reset target calls.
2) eNB #1 sends the X2 Reset Request message to every eNB #2 which owns a target call.
3) eNB #2 sends the X2 Reset Response message to eNB #1, and then performs the Call
Release procedure for the call.

Feature Description
Keep Alive between eNBs

The X2 connection between neighbor eNBs can be managed using the heartbeat chunk of
SCTP protocol (RFC4960). Keep alive using heartbeat is by SCTP connection.
It exchanges the heartbeat chunk to monitor the peer reachability when a SCTP connection
is made with another eNB.
The transmission interval of the heartbeat is basically set to 1.5 seconds on the LSM, and it
is changeable using the CHG-SCTP-PARA. If the heartbeat ACK message cannot be
received, try to retransmit it five times in every four seconds based on the settings.
If the ACK message is not received in one second after retransmission request from the
application, the kernel retransmit it once. If the ACK message is not received after the
kernel retransmitted it, consider the link status is abnormal.

Feature Description
Enter the current time in the heartbeat information field when the heartbeat is transmitted,
and it is included in the heartbeat ACK message. The heartbeat sender can use the current
time to calculate the Round Trip Time (RTT). The receiver also can calculate it.
The direct X2 interface between Macro and HeNB is studied as a 3GPP release 11 study
item for standardization (3GPP TR 37.803 V11.0.0). There is a problem that the X2
connection capacity of Macro eNB, neighbor cell manageable capacity of eNB, statistics
capacity of MRO function, insufficient capacity and complexity of software embodiment
may be increased as the number of Home eNB included in the Macro eNB coverage is
increased. The X2 interface between HeNBs is supported in the 3GPP Release 10.
Therefore, X2-based HO between HeNBs is allowed if no access control at the MME is
needed.

Feature Description
System operation
RTRV-NBR-EUTRAN This command retrieves information on E-UTRAN neighboring cell to

the eNB. If the CELL_NUM and RELATION_INDEX parameters are
entered, the information for a certain E-UTRAN neighboring cell is
retrieved. If not, the information for all E-UTRAN neighboring cells is
retrieved.
CHG-NBR-EUTRAN This command changes information on E-UTRAN neighboring cell to
the eNB. This command can change information on E-UTRAN
neighboring cell by entering the CELL_NUM and RELATION_IDX
parameter values.
CRTE-NBR-EUTRAN This command creates information on E-UTRAN neighboring cell to
the eNB. The user can create information on E-UTRAN neighboring
cell by entering the CELL_NUM and RELATION_
IDX parameter values. If parameters are not specified, they are set to
the defaults.
DLT-NBR-EUTRAN This command deletes information on E-UTRAN neighboring cell to
the eNB. The user can delete information on E-UTRAN neighboring
cell by entering the CELL_NUM and RELATION_
IDX parameter values.
RTRV-X2-STS This command retrieves the state information of the X2 interface. X2
interface is responsible for providing a direct path of communication
with eNBs of other cells in the system.
X2 interface facilitates exchange of signals and the load indicator
information between eNBs for fast handover and the information
required for self-optimization. This command retrieves the neighbor
eNB ID, SCTP (Stream Control Transmission Protocol) state
(SCTP_STATE), and X2 interface state (IF_STATE).

Feature Description
Default
Value
cellNum The cell number to be changed. - -
relationIdx Database index of E-UTRAN neighboring cell. - -
status The validity of the E-UTRAN neighboring cell information. - -
- N_EQUIP: The E-UTRAN neighboring cell information is
invalid.
- EQUIP: The E-UTRAN neighboring cell information is
valid.
enbId The eNB ID of the eNB to which E-UTRAN neighboring cell - -
to the eNB belongs.
If the enbType value is macro eNB, 20 bit of the value is
eNB ID.
If the enbType value is home eNB, 28 bit of the value is
eNB ID.
It is used when creating a cell identifier.
femtoIndicator The femto indicator of E-UTRAN neighbor cell. - -
- True: Femto cell.
- False: Marco cell.
virtualIndicator The cloud indicator of E-UTRAN neighbor cell. - -
- True: Cloud macro cell.
- False: General macro cell.
targetCellNum The local cell ID of E-UTRAN neighboring cell to the eNB. - -
It is used when creating a cell identifier.
enbType The type of the eNB to which E-UTRAN neighboring cell to - -
the eNB belongs.
- ci_Macro_eNB: Indicates the macro eNB.
enbMcc[4] The PLMN information (MCC) of the eNB to which E- - -
UTRAN neighboring cell to the eNB belongs.
It is a three-digit number with each digit being from 0 to 9.
enbMnc[4] The PLMN information (MNC) of the eNB to which E- - -
UTRAN neighboring cell to the eNB belongs.
It is a three-digit or two-digit number with each digit being
from 0 to 9.
phyCellId The physical cell ID of E-UTRAN neighboring cell to the - -
eNB.
tac The tracking area code of E-UTRAN neighboring cell to the - -
eNB.
mcc0[4] The broadcast PLMN list information (MCC) of E-UTRAN - -

Feature Description
(Continued)
Default
Value
mnc0[4] The broadcast PLMN list information (MNC) of E-UTRAN - -
from 0 to 9.
from 0 to 9.
from 0 to 9.
from 0 to 9.
from 0 to 9.
from 0 to 9.
earfcnUl The uplink EARFCN (E-UTRAN Absolute Radio Frequency - -
Channel Number) of E-UTRAN neighboring cell to the eNB.

Feature Description
(Continued)
Default
Value
earfcnDl The uplink EARFCN (E-UTRAN Absolute Radio Frequency - -
Channel Number) of E-UTRAN neighboring cell to the eNB.
bandwidthUl The uplink bandwidth of E-UTRAN neighboring cell to the - -
eNB.
bandwidthDl The downlink bandwidth of E-UTRAN neighboring cell to - -
the eNB.
indOffset The cell individual offset to be applied to E-UTRAN - -
It is used for UE measurement in RRC Connected mode.
qoffsetCell The cell quality offset to be applied to E-UTRAN - -
It is used for UE cell re-selection in RRC Idle mode.
isRemoveAllo Whether to delete a certain neighboring cell to the eNB - -
wed using the ANR (Automatic Neighbor Relation) function.
isHOAllowed Whether to perform handover to E-UTRAN neighboring - -
cell.
NbrEnbIndex It is index of neighbor eNB. - -
NbrEnbId It is id of neighbor eNB. - -
SctpState It is operational state. - -
IfState It is interface state. - -
ValidFlag It is valid flag of tuple. - -
Counter and KPI

N/A

Feature Description

Status or
Description How to Check
Alarm
SCTP_STATE It is SCTP operational state. Run the CLI, RTRV-X2-STS, and check the
- enabled result
- disabled
X2AP_STATE It is X2AP interface state. Run the CLI, RTRV-X2-STS, and check the
- enabled result
- disabled
Related Call Faults

Feature Description
LTE-SW1001, Paging
Overview
Introduction
When eNB receives a paging message from MME, the eNB transmits the paging message
to the UE in RRC_IDLE state based on the idle mode DRX configuration cycle.
Benefits
Operator can provide mobile terminating service to its subscribers.
Users in idle state can receive a notification for mobile terminating call.
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference
3) 3GPP TS36. 413 Evolved Universal Terrestrial Radio Access (E-UTRA); S1
4) 3GPP TS23.401 Technical Specification Group Services and System Aspects; GPRS
enhancements for E-UTRAN access

Feature Description
Feature Description
If the MME needs to signal with an idle UE, it starts paging procedure by sending paging
request to the eNBs in the paging area. When a paging request (S1 Paging message) is
received from MME, eNB will page to the UE at the timing of the UE’s paging occasion.
Paging procedure is as follows. (Network triggered Service Request case)
1) When the S-GW receives a downlink data packet for a UE, it buffers the downlink
data packet and identifies which MME is serving that UE.
2) The MME responds to the S-GW with a Downlink Data Notification Ack message.
3) The MME sends a Paging message to eNBs belonging to the tracking area(s) in which
the UE is registered.
4) The eNB calculates the paging occasion for the paged UE, and the paging will be
transmitted at the time of the UE’s paging occasion.
5) When UE receives a paging indication, the UE initiates the UE triggered Service
Request procedure.

Feature Description
System operation
Default
Value
RTRV-PCCH- dbIndex - Index
CONF defaultPagin - When DRX is used, UE monitors a single
CHG-PCCH-CONF gCycle paging occasion per DRX cycle. If UE-specific
DRX is not set by the upper layer,
defaultPagingCycle is applied as the default
DRX cycle.
nB - The parameter required to calculate the paging
frame and paging occasion using the TS 36.304
method, which is a multiple of defaultPagingCycle.
RTRV-DRX-INF QCI - -
CHG-DRX-INF DRX_CONFI - DRX usage.
G_SETUP - ci_Config_Release: DRX not used.
- ci_Config_Setup: In the normal state, DRX
profile is not used and, in the reportCGI state,
DRX profile for reportCGI is used
- ci_Config_reportCGI: In the normal state, DRX
is not used and, in the reportCGI state, DRX
profile for reportCGI is used.
ON_DURATI - Timer for monitoring PDCCH In the normal-
ON_TIMER_ state DRX mode. (TS 36.321’s 5.7) For values,
NORMAL the number of PDCCH sub-frames: psf1 for 1
PDCCH subframe and psf2 for 2 PDCCH sub-
frame. (TS 36.331’s 6.3.2)
{psf1, psf2, psf3, psf4, psf5, psf6, psf8, psf10,
psf20, psf30, psf40, psf50, psf60, psf80, psf100,
psf200} The usable value is equal to or larger
than 10ms.

Feature Description
(Continued)
Commands Parameters Default Value Description
RTRV-DRX- DRX_INACTIVIT - Timer for monitoring PDCCH in the normal-

INF Y_TIMER_NOR state DRX mode. (TS 36.321’s 5.7) For
CHG-DRX- MAL values, number of PDCCH sub-frames:,
INF psf1,for 1PDCCH subframe, psf2 for 2
PDCCH sub-frame (TS 36.331’s 6.3.2)
Defined values: {psf1, psf2, psf3, psf4, psf5,
psf60, psf80, psf100, psf200, psf300, psf500,
psf750, psf1280, psf1920, psf2560, spare10,
spare9, spare8, spare7, spare6, spare5,
spare4, spare3, spare2, spare1}
The usable value is equal to or larger than
10ms.
DRX_RETRANS - Timer for monitoring PDCCH in the normal-
MISSION_TIME state DRX mode.
R_NORMAL {psf1, psf2, psf4, psf6, psf8, psf16, psf24,
psf33}
LONG_DRXCY - long DRX Cycle and drx Start Offset values
CLE_START_O for operating onDurationTimer in the normal
FFSET_TYPE_ DRX mode. Long DRX Cycle’s unit is the
NORMAL number of sub-frames. If short DRX-Cycle is
chosen, this values is set to the multiple of
short DRX-Cycle. The value of DRX Start
Offset is an integer. For TDD, you can
designate DL sub-frame or UL sub-frame.
{sf10, sf20, sf32, sf40, sf64, sf80, sf128,
sf160, sf256, sf320, sf512, sf640, sf1024,
sf1280, sf2048, sf2560}
The usable value: multiple of 10ms
SHORT_DRXC - Short DRX mode.
ONFIG_SETUP - ci_Config_Release: Short DRX not used.
- ci_Config_Setup: Short DRX used.
SHORT_DRXCY - Short DRX cycle for operating
CLE_NORMAL onDurationTimer in the normal-state DRX
mode.
{sf2, sf5, sf8, sf10, sf16, sf20, sf32, sf40,
sf64, sf80, sf128, sf160, sf256, sf320, sf512,
sf640}
The usable value: multiple of 10ms
DRX_SHORT_C - Timer for entering the normal-state Long
YCLE_TIMER_N DRX mode.
ORMAL
DRX_SELECTI - Selection order per QCI for selecting DRX
ON_ORDER profile.

Feature Description
(Continued)
Commands Parameters Default Value Description
RTRV-DRX- ON_DURATION_ - Timer for monitoring PDCCH in the

INF TIMER_REPORT reportCGI-state DRX mode timer.
CHG-DRX- _CGI (TS 36.321’s 5.7) For the values, number of
INF PDCCH sub-frames: psf1 for 1 PDCCH
subframe, and psf2 for 2 PDCCH sub-frame
(TS 36.331’s 6.3.2)
{psf1, psf2, psf3, psf4, psf5, psf6, psf8, psf10,
psf100, psf200}
10 ms.
DRX_INACTIVIT - Timer for monitoring PDCCH in the
Y_TIMER_REPO reportCGI-state DRX mode. (TS 36.321’s
RT_CGI 5.7) For the values, the number of PDCCH
sub-frames: psf1 for 1 PDCCH subframe and
psf2 for 2 PDCCH sub-frame (TS 36.331’s
6.3.2)
Defined values: {psf1, psf2, psf3, psf4, psf5,
psf750, psf1280, psf1920, psf2560, spare10,
spare9, spare8, spare7, spare6, spare5,
spare4, spare3, spare2, spare1}
10 ms.
DRX_RETRANS - Timer for monitoring PDCCH in the
MISSION_TIMER reportCGI-state DRX mode.
_REPORT_CGI {psf1, psf2, psf4, psf6, psf8, psf16, psf24,
psf33}
LONG_DRXCYC - long DRX Cycle and drx Start Offset values
LE_START_OFF for operating onDurationTimer in the
SET_TYPE_REP reportCGI-state DRX mode. The unit for Long
ORT_CGI DRX Cycle is the number of sub-frames.
if short DRX-Cycle is set, this value is set to
the multiple of short DRX-Cycle. The value if
DRX Start Offset is an integer. For TDD, you
can designate DL sub-frame or UL sub-
frame.
{sf10, sf20, sf32, sf40, sf64, sf80, sf128,
sf160, sf256, sf320, sf512, sf640, sf1024,
sf1280, sf2048, sf2560}
The usable value: multiple of 10 ms

Feature Description
(Continued)
Commands Parameters Default Description

Value
RTRV-DRX-INF SHORT_DRXCYC - Short DRX cycle for monitoring
CHG-DRX-INF LE_REPORT_CGI onDurationTimer in the reportCGI-state
DRX mode.
{sf2, sf5, sf8, sf10, sf16, sf20, sf32,
sf40, sf64, sf80, sf128, sf160, sf256,
sf320, sf512, sf640}
The usable value: multiple of 10 ms
DRX_SHORT_CY - timer for entering in reportCGI-state
CLE_TIMER_REP Long DRX mode.
ORT_CGI

Category Family FamilyName TypeName Description
PAG Pasing Paging PAGING Collects statistic date on paging. eNB

Performance collects statistic data Paging Attempt
per base station cell made by paging
request from MME. The number of
paging messages that eNB failed to
handle and were discarded are
collected per cell.
Paging for System Information Update
and Paging for ETWA Indication are
included. Statistic data on Paging
Response made available by NAS
Signaling is not collected by eNB, an
Access network.
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1002, Idle Mobility Support

Overview
Introduction
To support UE’s idle mobility in E-UTRAN, eNB broadcasts relevant cell reselection
information in SIB messages so that the UE can perform intra-LTE cell reselection when
needed.
Benefits
Operator can provide idle mobility to its subscribers within E-UTRAN.
Users in idle state can be moving within E-UTRAN.
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference

Feature Description
Feature Scope
[SIB3]
R1 eNB can transmit the information necessary for the cell reselection of the terminal via
SIB3.
R2 eNB can support the SIB3 setting/change and display by the operator.
R3 eNB can transmit SIB3 according the defined cycle.
[SIB4]
R1 eNB can transmit the information on the intra-frequency-adjacent cell of the terminal
via SIB4.
[SIB5]
R1 eNB can transmit inter-frequency cell reselection of the terminal via SIB5.

Feature Description
Feature Description
To support intra-LTE cell reselection, eNB broadcasts the SIB3 (System Information Block
type 3), SIB4 (System Information Block type 4) and SIB5 (System Information Block
type 5). The UE shall monitor the E-UTRAN BCCH during idle mode to retrieve these
SIBs for the preparation of intra-LTE cell reselection. Then UE makes measurements on
neighbouring cells based on the criteria and performs cell reselection to intra-/inter-
frequency neighbouring cells when needed.
The parameters for intra-LTE cell reselection broadcasted in SIB3, SIB4 and SIB5 are as
follows.
SIB3 conveys the common information for intra-frequency, inter-frequency and/or inter-
RAT cell reselection. SIB3 also conveys the specific information for intra-frequency cell
reselection.
 Hysteresis
 Hysteresis for speed dependant cell reselection
 Common threshold values for cell reselection
 Mobility state parameters for spee
 Cell reselection priority for serving carrier frequency
 Threshold values for intra-frequency cell reselection
 Cell reselection timer for intra-frequency cell reselection
 Cell reselection timer for speed dependant intra-frequency cell reselection
SIB4 conveys the intra-frequency neighbouring cell related information, i.e. intra-
frequency neighbour cell list and blacklisted cells.
 Intra-frequency neighbour cell list
 Intra-frequency blacklisted cells
 Set of physical cell identities reserved for CSG cells on the serving carrier frequency
SIB5 conveys the information for inter-frequency cell reselection.

 Neighbouring downlink carrier frequency
 Threshold values per carrier frequency
− q-OffsetFreq
− threshX-High (R8, RSRP)
− threshX-HighQ (R9, RSRQ)
− threshX-Low (R8, RSRP)
− threshX-LowQ (R9, RSRQ)
− q-RxLevMin (R8, RSRP)

Feature Description
− q-QualMin (R9, RSRQ)

− p-Max
 allowedMeasBandwidth
 presenceAntennaPort1
 neighCellConfig
 Inter-frequency neighbour cell list per carrier frequency
 Inter-frequency blacklisted cells per carrier frequency
 Cell reselection timer per carrier frequency
 Cell reselection timer for speed dependant inter-frequency cell reselection

Feature Description
System operation
CHG-SIB-INF cellNum The cell number to be changed or retrieved.

RTRV-SIB-INF sib2Period The transmission period for the system information
block type 2 of the cell in the eNB.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
Sib3Period The transmission period for the system information
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.
- ci_rf8: 80 ms.
- ci_rf16: 160 ms.
- ci_rf32: 320 ms.
- ci_rf64: 640 ms.
- ci_rf128: 1280 ms.
- ci_rf256: 2560 ms.
- ci_rf512: 5120 ms.

Feature Description
(Continued)
CHG-SIB-INF siWindow The system information window size of the cell in the
RTRV-SIB-INF eNB.
Each SI message is related with one SI window, and
does not overlap with SI windows of other SI messages.
I.e, one SI is sent in each SI window. All SI messages
have the same window size. Corresponding SI
messages within the SI window are sent repeatedly.
The range is as follows:
RTRV-CELL-RSEL cellNum The cell number to be changed or retrieved.
CHG-CELL-RSEL qHyst Offset value added to the current serving cell from the cell
reselection reference. ci_q_Hyst_dB1 indicates 1 dB, and
ci_q_Hyst_dB2 2 dB.
qHystSFMedium The value added if the UE speed in Qhyst added to the
current serving cell is Medium in the cell reselection
condition.
This parameter, in order to apply to change,
SPEED_STATE_RESEL_PARAMS_USAGE of CHG-
MOBIL-STA is set to CI_use.
qHystSFHigh The value added if the UE speed in Qhyst added to the
current serving cell is High in the cell reselection
condition.
ci_Q_HystSF_dB_6 indicates -6 dB, and
ci_Q_HystSF_dB_4 -4 dB.
This parameter, in order to apply to change,
SPEED_STATE_RESEL_PARAMS_USAGE of CHG-
MOBIL-STA is set to CI_use.
RTRV-MOBIL-STA cellNum The cell number to be changed or retrieved.
CHG- MOBIL-STA
speedStateReSe Whether to use the speedStateReselectonPars field of
lParsUsage the cell in the eNB.
- CI_no_use: The speedStateReselectonPars field is not
used.
- CI_use: The speedStateReselectonPars field is used.
tEvalulation The evaluation time of the cell in the eNB.
tHystNormal The hyst normal time of the cell in the eNB.
nCellChangeMe The number of cell change in medium mobility state of
dium the cell in the eNB.
nCellChangeHigh The number of cell change in high mobility state of the
cell in the eNB.

Feature Description
(Continued)
RTRV-EUTRA-FA cellNum The cell number to be changed.

CHG-EUTRA-FA faIndex EUTRA frequency index. Up to 8 FAs can be assigned
per cell.
status Whether the EUTRA FA is valid.
- N_EQUIP: Invalid.
- EQUIP: Valid.
earfcnUl Uplink E-UTRA Absolute Radio Frequency Channel
Number.
earfcnDl Downlink E-UTRA Absolute Radio Frequency Channel
Number.
priority Priority of EUTRA FA.
qRxLevMin The minimum RX level required in a cell in dBm units.
pMaxUsage Whether to use pMax.
- CI_no_use: pMax value is not used.
pMax The maximum TX power level in the UE.
tReselection Reselection timer value.
sfUsage Whether to use scaling factors.
- CI_no_use: T_RESELECTION_SF_MEDIUM and
T_RESELECTION_SF_HIGH values are not used.
- CI_use: T_RESELECTION_SF_MEDIUM and
T_RESELECTION_SF_HIGH values are used.
tReselectionSfM The medium timer value of the reselection scaling factors.
edium
tReselectionSfHi The high timer value of the reselection scaling factors.
gh
sIntraSearchUsa Whether to use sIntraSearch.
ge - CI_no_use: sIntraSearch is not used.
sIntraSearch The threshold for intra-frequency measurement.
sNonIntraSearch Whether to use sNonIntraSearch.
Usage - CI_no_use: sNonIntraSearch is not used.
sNonIntraSearch The threshold for inter-RAT and intra-frequency
measurement.
threshServingLow The low threshold for serving frequency during
reselection evaluation.
threshXhigh The threshold used in the UE to reselect a frequency
whose priority is higher than the current camped
frequency.

Feature Description
(Continued)
RTRV-EUTRA-FA threshXLow The threshold used to reselect low-priority frequency

CHG-EUTRA-FA from high-priority frequency.
mesaBandwidthU Whether to use measurementBandwidth.
sage - CI_no_use: measurementBandwidth is not used.
measurementBan The maximum measurement bandwidth allowed for
dwidth carrier frequency.
presenceAntPort1 Whether Antenna Port1 exists.
- False: Antenna Port1 does not exist.
- True: Antenna Port1 exists.
neighCellConfig The neighboring cell settings.
qOffsetFreq Frequency offset value applied to q-OffsetFreq in SIB5.
offsetFreq Frequency offset value applied to offsetFreq in RRC
Connection Reconfiguration.
sIntraSearchRel9 Whether to use the sIntraSearch for Rel-9.
Usage - CI_no_use: sIntraSearch is not used.
sIntraSearchP The threshold P for an intra-frequency measurement in
Rel-9.
sIntraSearchQ The threshold Q for an intra-frequency measurement in
Rel-9.
sNonIntraSearch Whether to use sNonIntraSearch for Rel-9.
Rel9Usage - CI_no_use: sNonIntraSearch is not used.
sNonIntraSearchP The threshold P for inter-RAT and an intra-frequency
measurement.
sNonIntraSearchQ The threshold Q for inter-RAT and an intra-frequency
measurement.
qQualMinRel9Usa Whether to use the qQualMin for Rel-9.
ge - CI_no_use: SqQualMin is not used.
qQualMinRel9 qQualMin value for Rel-9.
threshServingLow Whether to use the threshServingLowQ for Rel-9.
QRel9Usage - CI_no_use: threshServingLowQ is not used.
threshServingLow threshServingLowQ value for Rel-9.
QRel9
threshXhighQRel9 The threshold used in the UE to reselect a frequency
whose priority is higher than the current camped
frequency in Rel-9.

Feature Description
(Continued)
RTRV-EUTRA-FA threshXLowQRel9 The threshold used to reselect low-priority frequency

CHG-EUTRA-FA from high-priority frequency in Rel-9.
mcc0[4] Mobile Country Code (MCC) that comprises Public Land
Mobile Network (PLMN). FA have the Preference of
Preference0 for PLMN #0
mnc0[4] MNC that comprises PLMN.FA have the Preference of
preference0 Preference of PLMN #0 for FA.
anrUeSearchRate The Searching Rate of UE which performs the ANR
measurement for the corresponding carrier index.

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1003, Intra-eNB Handover

Overview
Introduction
Intra-eNB handover is mobility control functionality between cells that belong to the same
eNB. UEs can move between the cells without any message exchange with MME.
Benefits
Operator can provide connected mobility to its subscribers between cells in same eNB.
Users in connected state can be moving within E-UTRAN, with change of serving cell.
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference

Feature Description
Feature Scope
R1 eNB can determine on the intra-LTE handover depending the measurements of the
terminal.
R2 eNB can handle the measurement configuration of the terminal that supports intra-
LTE handover.
 Selects one from neighboring E-UTRA carriers based on E-UTRA supported band
(FDD or TDD) for which to request measurement.
 Reporting configuration that reflects measurement event (Event A3/A5) settings for
Intra-LTE handover
R3 eNB can choose the target cell for intra-LTE handover.
 Selects the best cell of the measured cells included in Measurement Report.
R4 eNB can determine on the intra-LTE handover process based on the handover target
cell.
 If the handover target cell is a neighboring one within the same eNB, carry out intra-
eNB handover.
R5 eNB can, if requested for intra-eNB handover, determine whether to accept the signal
in handover target cell.
R6 eNB can collect statistic information on the intra-eNB handover process.
 Intra-eNB handover attempt/success/failure (collection unit: source cell, target cell)

Feature Description
Feature Description
When a handover event of call (data only, VoIP only or both VoIP and data) to intra-/inter-
frequency neighbouring cell is occurred by UE measurement results, the source eNB
initiates intra-LTE handover procedures.
 Intra-LTE handover triggering and target cell decision
− When eNB receives a measurement report including Event A3 from UE, eNB
triggers intra-LTE handover to the best cell indicated in the measurement report.
− Because handover target cell is decided by UE’s measurement results for
neighbouring cells, Samsung doesn’t support blind handover.
Intra-eNB Handover procedure is used to handover a UE from source cell to target cell
(intra-/inter-frequency) within the same eNB. In this procedure the serving MME is
unchanged.
Following figure shows the intra-eNB handover procedure in E-UTRAN.
1) UE sends MEASUREMENT REPORT including E-UTRAN measurements to the

serving eNB.
2) The serving eNB makes decision based on the MEASUREMENT REPORT to
handover UE. Then serving eNB prepares the required resources for the UE to be used
in the target cell.
3) The RRC CONNECTION RECONFIGURATION for handover is constructed by the
serving eNB and is sent to the UE.
4) The UE hands over to the target cell. After the UE has successfully synchronized to the
target cell, it sends a RRC CONNECTION RECONFIGURATION COMPLETE
message to the target cell.

Feature Description
System operation
Parameters Descriptions
RTRV-NBR-EUTRAN Retrieves information on E-UTRAN neighboring cell to the eNB. If the

CELL_NUM and RELATION_INDEX parameters are entered, the
information for a certain E-UTRAN neighboring cell is retrieved. If not, the
information for all E-UTRAN neighboring cells is retrieved.
CHG-NBR-EUTRAN Changes information on E-UTRAN neighboring cell to the eNB. This
command can change information on E-UTRAN neighboring cell by
entering the CELL_NUM and RELATION_IDX parameter values.
CRTE- NBR- Creates information on E-UTRAN neighboring cell to the eNB. The user
EUTRAN can create information on E-UTRAN neighboring cell by entering the
CELL_NUM and RELATION_IDX parameter values. If parameters are not
specified, they are set to the defaults.
DLT-NBR-ETURAN Deletes information on E-UTRAN neighboring cell to the eNB. The user
can delete information on E-UTRAN neighboring cell by entering the
CELL_NUM and RELATION_IDX parameter values.
cellNum The cell number to be changed.

relationIdx Database index of E-UTRAN neighboring cell.
status The validity of the E-UTRAN neighboring cell information.
- N_EQUIP: The E-UTRAN neighboring cell information is invalid.
- EQUIP: The E-UTRAN neighboring cell information is valid.
enbId The eNB ID of the eNB to which E-UTRAN neighboring cell to the eNB belongs.
If the enbType value is macro eNB, 20 bit of the value is eNB ID. If the enbType
value is home eNB, 28 bit of the value is eNB ID. It is used when creating a cell
identifier.
targetCellNum The local cell ID of E-UTRAN neighboring cell to the eNB. It is used when
creating a cell identifier.
enbType The type of the eNB to which E-UTRAN neighboring cell to the eNB belongs.
enbMcc[4] The PLMN information (MCC) of the eNB to which E-UTRAN neighboring cell to
the eNB belongs. It is a three-digit number with each digit being from 0 to 9.

Feature Description
(Continued)
enbMnc[4] The PLMN information (MNC) of the eNB to which E-UTRAN neighboring cell to
the eNB belongs. It is a three-digit or two-digit number with each digit being from
0 to 9.
phyCellId The physical cell ID of E-UTRAN neighboring cell to the eNB.
tac The tracking area code of E-UTRAN neighboring cell to the eNB.
mcc0[4] The broadcast PLMN list information (MCC) of E-UTRAN neighboring cell to the
eNB. It is a three-digit number with each digit being from 0 to 9.
mnc0[4] The broadcast PLMN list information (MNC) of E-UTRAN neighboring cell to the
eNB. It is a three-digit or two-digit number with each digit being from 0 to 9.
earfcnUl The uplink EARFCN (E-UTRAN Absolute Radio Frequency Channel Number) of
E-UTRAN neighboring cell to the eNB.
earfcnDl The uplink EARFCN (E-UTRAN Absolute Radio Frequency Channel Number) of
E-UTRAN neighboring cell to the eNB.
bandwidthUl The uplink bandwidth of E-UTRAN neighboring cell to the eNB.
bandwidthDl The downlink bandwidth of E-UTRAN neighboring cell to the eNB.
indOffset The cell individual offset to be applied to E-UTRAN neighboring cell to the eNB.
qoffsetCell The cell quality offset to be applied to E-UTRAN neighboring cell to the eNB.

Feature Description
(Continued)
isRemoveAllowed Whether to delete a certain neighboring cell to the eNB using the ANR
(Automatic Neighbor Relation) function.
isHOAllowed Whether to perform handover to E-UTRAN neighboring cell.
ownerType This parameter defines how NRT is updated, This filed can be classfied
Initial NRT/ANR by Server/ANR by UE/Created by User Command/
CreatedByUserUI.
Related Counters
Category Family FamilyName TypeName Type Description
HO Intra-eNB HO_INTRA - Intra eNB handover related

EUTRAN handover counters. These are collected per
cell.
IntraEnbAtt Intra eNB handover attempt count
IntraEnbPrepSucc Intra eNB handover preparation
success count
IntraEnbSucc Intra eNB handover execution
success count
IntraEnbPrepFail_ Intra eNB handover preparation
CP_CC_TO fails due to due to call control
timeout in the protocol blocks
(MAC, RLC, PDCP, GTP)
CP_CC_FAIL fails due to reset notification (eNB
failure or block restart) from ECMB
or by the ECCB block
UP_MAC_FAIL fails due to the failure in the MAC
block
UP_RLC_FAIL fails due to the failure in the RLC
block
IntraEnbPrepFail_ Intra eNB handover preparation fails
RRC_SIG_FAIL due to receiving RRC signaling
CP_BH_CAC_ fails due to Backhaul QoS based
FAIL CAC

Feature Description
(Continued)
HO Intra-eNB HO_INTRA IntraEnbPrepFail_ Intra eNB handover preparation

EUTRAN handover CP_CAPA_CAC_ fails due to Capacity based CAC
FAIL
CP_QOS_CAC_F fails due to Air QoS based CAC
AIL
S1AP_CU_FAIL fails due to the S1AP specification
cause
S1AP_LINK_FAIL fails due to the S1 SCTP link failure
IntraEnbPrepFail_ Intra eNB handover preparation fails
S1AP_SIG_FAIL due to receiving S1AP signaling
IntraEnbFail_CP_ Intra eNB handover fails due to call
CC_TO control timeout in the protocol
blocks (MAC, RLC, PDCP, GTP)
IntraEnbFail_CP_ Intra eNB handover fails due to
CC_FAIL reset notification (eNB failure or
block restart) from ECMB or by the
ECCB block
IntraEnbFail_UP_ Intra eNB handover fails due to the
GTP_FAIL failure in the GTP block
MAC_FAIL failure in the MAC block
RLC_FAIL failure in the RLC block
IntraEnbFail_RR Intra eNB handover fails due to HO
C_HC_TO preparation timeout (not received
HO command)
IntraEnbFail_RR Intra eNB handover fails due to
C_SIG_FAIL receiving RRC signaling
IntraEnbFail_S1A Intra eNB handover fails due to the
P_CU_FAIL S1AP specification cause
IntraEnbFail_S1A Intra eNB handover fails due to the
P_LINK_FAIL S1 SCTP link failure
IntraEnbFail_S1A Intra eNB handover fails due to
P_SIG_FAIL receiving S1AP signaling
Handover HO_TIME - -
Time

Feature Description
(Continued)
HO Handover HO_TIME IntraHOTime Time taken from transmitting the

EUTRAN Time RRCConnectionReconfiguration
message to the UE until after
receiving the RRCConnection
Reconfiguration Complete message
from the UE.
IntraHOTimeMax Average maximum intra HO
interrupt time
IntraHOTimeTot Sum of intra HO interrupt time
IntraHOTimeCnt Count of IntraHOTime collected
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1004, S1 Handover
Overview
Introduction
S1 handover is mobility control functionality between two adjacent eNBs using the S1
interface with MME. S1 handover is used when there is no available direct interface with
target eNB, or target eNB belongs to other MME group.
Benefits
Operator can provide connected mobility to its subscribers between cells in different eNBs.
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference

Feature Description
Feature Scope
R1 eNB can determine on the intra-LTE handover based on the terminal measurement
results.
R2 eNB can handle the terminal measurement configuration that supports the intra-LTE
handover.
 Selects one from adjacent E-UTRA carriers based on E-UTRA supported band
(FDD or TDD) for which to request measurement
Intra-LTE handover
 Selects the best cell of the measured cells included in Measurement Report
cell.
 If Handover target cell is a cell in another eNB and MME group to which target
eNB belongs to is different from source eNB,
 Though MME group to which Target eNB belongs to is the same with source eNB,
if there is no X2 interface between source eNB and target eNB, carry out S1
handover.
R5 eNB can configure Source to Target Transparent Container to be transmitted to target
eNB.
 Source eNB to Target eNB Transparent Container [3GPP TS36.331]
R6 eNB can determine whether to accept the request of S1 handover.
R7 eNB can configure Target to Source Transparent Container to be transmitted to source
eNB.
 Target eNB to Source eNB Transparent Container [3GPP TS36.331]
R8 eNB can handle neighboring eNB and HO preparation according to S1 handover
procedures.
R9 eNB can handle data forwarding at the time of S1 handover.
R10 eNB can handle S1 handover cancel procedures.
R11 eNB can collect statistics on outgoing S1 handover procedures.
 Outgoing S1 handover attempt/success/failure (collection unit: source cell, target
cell)
R12 eNB can collect statistic data on the incoming S1 handover procedures.
 Incoming S1 handover attempt/success/failure (collection unit: target cell)

Feature Description
Feature Description
S1 handover is a handover between two adjacent eNBs using the S1 interface with MME
(inter eNB handover via S1 interface). S1 handover is used when there is no available
direct interface with the target eNB, or the target eNB belongs to other MME group.
Following figure shows the S1 handover procedure in E-UTRAN (S1 handover with MME
and Serving GW relocation case)

Feature Description

source eNB.
2) The source eNB makes decision based on the MEASUREMENT REPORT to
handover UE.
3) The source eNB sends HANDOVER REQUIRED to the source MME.
4)~10) S1 handover preparation is performed via MME. The target eNB performs
admission control for the incoming handover request. If accepted, the target eNB
prepares the required resources for the UE to be used in the target cell. Also the
resources for data forwarding is prepared if necessary.

Feature Description
11) The source eNB receives the HANDOVER COMMAND from the source MME.
14) The target eNB sends a HANDOVER NOTIFY message to MME to inform that the
UE has changed cell.
15)~19) The MME performs S1 handover completion procedure.
21)~24) The source MME releases the UE’s resources that was used in the source eNB and
the resources for data forwarding.

Feature Description
System operation

CRTE-NBR-EUTRAN Creates information on E-UTRAN neighboring cell to the eNB. The user
can create information on E-UTRAN neighboring cell by entering the
RTRV-NBR-ENB Retrieves information on the neighboring eNB to the eNB. If the index
parameter of the neighboring eNB is entered, the information for a certain
neighboring eNB is retrieved, If not, the information for all neighboring
eNBs is retrieved.
CHG-NBR-ENB Changes the neighboring eNB information required to operate a Neighbor
eNB. This command can change the neighboring eNB information by
entering the NBR_ENB_INDEX parameter.
CRTE-NBR-ENB Creates information on the neighboring eNB for operation. The user can
create information on the neighboring eNB by entering the
NBR_ENB_INDEX parameter value. If parameters are not specified, they
are set to the defaults.
DLT-NBR-ENB Deletes information on the neighboring eNB to the eNB. The user can
delete information on the neighboring eNB by entering the
NBR_ENB_INDEX parameter value.


Feature Description
(Continued)

enbId The eNB ID of the eNB to which E-UTRAN neighboring cell to the eNB
belongs. If the enbType value is macro eNB, 20 bit of the value is eNB ID.
If the enbType value is home eNB, 28 bit of the value is eNB ID. It is used when
enbMcc[4] The PLMN information (MCC) of the eNB to which E-UTRAN neighboring cell
to the eNB belongs. It is a three-digit number with each digit being from 0 to 9.
enbMnc[4] The PLMN information (MNC) of the eNB to which E-UTRAN neighboring cell
to the eNB belongs. It is a three-digit or two-digit number with each digit being
from 0 to 9.
mcc0[4] The broadcast PLMN list information (MCC) of E-UTRAN neighboring cell to
the eNB. It is a three-digit number with each digit being from 0 to 9.
mnc0[4] The broadcast PLMN list information (MNC) of E-UTRAN neighboring cell to
the eNB. It is a three-digit or two-digit number with each digit being from 0 to 9.

Feature Description
(Continued)
earfcnUl The uplink EARFCN (E-UTRAN Absolute Radio Frequency Channel Number)
of E-UTRAN neighboring cell to the eNB.
earfcnDl The uplink EARFCN (E-UTRAN Absolute Radio Frequency Channel Number)
isRemoveAllow Whether to delete a certain neighboring cell to the eNB using the ANR
ed (Automatic Neighbor Relation) function.
ownerType This parameter defines how NRT is updated, This filed can be classfied Initial
NRT/ANR by Server/ANR by UE/Created by User
nbrEnbIndex Index of the neighboring eNB. The value entered when registering the
neighboring eNB is used.
status The validity of the neighboring eNB information.
- N_EQUIP: Invalid.
- EQUIP: Valid.
noX2 Whether to make X2 connection to the neighboring eNB.
- False: X2 connection with the neighboring eNB is made.
- True: X2 connection to the neighboring eNB is not made.
noHO Whether to perform handover to the neighboring eNB.
- False: Handover to the neighboring eNB is performed.
- True: Handover to the neighboring eNB is not performed.
enbId The eNB ID represents the neighboring eNB. If the enbType value is macro
eNB, 20 bit of the value is eNB ID. If the enbType value is home eNB, 28 bit of
the value is eNB ID.

Feature Description
(Continued)
enbType eNB type of the neighboring eNB.

enbMcc[4] The PLMN information (MCC) that represents the neighboring eNB.
enbMnc[4] The PLMN information (MNC) that represents the neighboring eNB.
It is a three-digit or two-digit number with each digit being from 0 to 9.
ipVer The IP version, which is the IP address of the neighboring eNB.
nbrEnbIPv4 Enter the IP address of the neighboring eNB in the IP version 4 format.
nbrEnbIPv6[16] Enter the IP address of the neighboring eNB in the IP version 6 format.
secondaryNbrEnbIPv4 Enter the secondary IP address of the neighboring eNB in the IP version
4 format.
[16] 6 format.
administrativeState This parameter defines Neighbor eNB Link Status
CreatedByUserUI.
remoteFlag This parameter defines the target eNB is managed local EMS or other
EMS
Related Counters
HO Handover HO_TIME S1HOTime Time taken from

EUTRAN Time transmitting the S1
Handover Request
Acknowledge message
to the MME until after
receiving the
RRCConnectionRecon
figuration Complete
S1HOTimeMax Average maximum S1
HO interrupt time
S1HOTimeTot Sum of S1 HO interrupt
time
S1HOTimeCnt Count of S1HOTime
collected

Feature Description
(Continued)
HO S1 HO_S1_OUT InterS1OutAtt S1 handover attempt

EUTRAN Handover count in SeNB.
Out InterS1OutPrepSucc S1 handover
preparation success
count in SeNB.
InterS1OutSucc S1 handover execution
success count in SeNB.
InterS1OutPrepFail_CP_CC_ Preparation fails due to
FAIL reset notification (eNB
failure or block restart)
from ECMB or by ECCB
block during inter S1
handover preparation.
InterS1OutPrepFail_S1AP_ Preparation fails due to
CU_FAIL S1AP specification
cause during inter S1
during inter S1
RP_TO S1AP relocprep timeout
(not received) during the
inter S1 handover
preparation.
SIG_FAIL receiving S1AP
signaling during inter S1
InterS1OutFail_CP_CC_TO A call is released due to
call control timeout in
the protocol blocks
(MAC, RLC, PDCP,
GTP) during the inter S1
handover execution.
InterS1OutFail_CP_CC_FAIL A call is released due to
reset notification (eNB
block during the inter S1
handover execution.

Feature Description
(Continued)
HO S1 HO_S1_OUT InterS1OutFail_UP_GTP_ A call is released due to

EUTRAN Handover FAIL the failure in the GTP
Out block during the inter S1
handover execution.
InterS1OutFail_UP_MAC_ A call is released due to
FAIL the failure in the MAC
handover execution.
InterS1OutFail_UP_PDCP_ A call is released due to
FAIL the failure in the PDCP
handover execution.
InterS1OutFail_UP_RLC_ A call is released due to
FAIL the failure in the RLC
handover execution.
InterS1OutFail_RRC_SIG_ A call is released due to
FAIL receiving RRC signaling
during the inter S1
handover execution.
InterS1OutFail_S1AP_CU_ A call is released due to
FAIL the S1AP specification
cause during the inter
S1 handover execution.
InterS1OutFail_S1AP_LINK_ A call is released due to
FAIL the S1 SCTP link failure
during the inter S1
handover execution.
InterS1OutFail_S1AP_RO_ A call is released due to
TO S1AP relocoverall
during the inter S1
handover execution.
InterS1OutFail_S1AP_SIG_ A call is released due to
FAIL receiving S1AP
signaling during the inter
S1 HO_S1_IN - -
Handover InterS1InAtt S1 handover attempt
In count in TeNB.

Feature Description
(Continued)
HO S1 HO_S1_IN InterS1InPrepSucc S1 handover

EUTRAN Handover preparation success
In count in TeNB.
InterS1InSucc S1 handover execution
success count in TeNB.
InterS1InPrepFail_CP_CC_ Preparation fails due to
TO call control timeout in
the protocol blocks
(MAC, RLC, PDCP,
InterS1InPrepFail_CP_CC_ Preparation fails due to
FAIL reset notification (eNB
block during inter S1
InterS1InPrepFail_UP_GTP_ Preparation fails due to
FAIL internal failure in the
GTP block during the
inter S1 handover
preparation.
InterS1InPrepFail_UP_MAC_ Preparation fails due to
MAC block during the
inter S1 handover
preparation.
InterS1InPrepFail_UP_PDCP Preparation fails due to
_FAIL internal failure in the
PDCP block during the
inter S1 handover
preparation.
InterS1InPrepFail_UP_RLC_ Preparation fails due to
RLC block during the
inter S1 handover
preparation.
InterS1InPrepFail_CP_BH_C Preparation fails due to
AC_FAIL insufficient backhaul-
based eNB resources
during the inter S1

Feature Description
(Continued)
HO S1 HO_S1_IN InterS1InPrepFail_CP_CAPA Preparation fails due to

EUTRAN Handover _CAC_FAIL insufficient capacity-
In based eNB resources
during the inter S1
InterS1InPrepFail_CP_QOS_ Preparation fails due to
CAC_FAIL insufficient QoS-based
eNB resources during
the inter S1 handover
preparation.
InterS1InPrepFail_S1AP_CU Preparation fails due to
_FAIL S1AP specification
cause during inter S1
InterS1InPrepFail_S1AP_ Preparation fails due to
during inter S1
InterS1InPrepFail_S1AP_ Preparation fails due to
SIG_FAIL receiving S1AP
signaling during inter S1
InterS1InFail_CP_CC_TO A call is released due to
call control timeout in
the protocol blocks
(MAC, RLC, PDCP,
handover execution.
InterS1InFail_CP_CC_FAIL A call is released due to
reset notification (eNB
handover execution.
InterS1InFail_UP_GTP_FAIL A call is released due to
the failure in the GTP
handover execution.
InterS1InFail_UP_MAC_FAIL A call is released due to
the failure in the MAC
handover execution.

Feature Description
(Continued)
HO S1 HO_S1_IN InterS1InFail_UP_PDCP_ A call is released due to

EUTRAN Handover FAIL the failure in the PDCP
In block during the inter S1
handover execution.
InterS1InFail_UP_RLC_FAIL A call is released due to
the failure in the RLC
handover execution.
InterS1InFail_RRC_HC_TO A call is released due to
HO command timeout
inter S1 handover
execution.
InterS1InFail_RRC_SIG_ A call is released due to
FAIL receiving RRC signaling
during the inter S1
handover execution.
InterS1InFail_S1AP_CU_ A call is released due to
FAIL the S1AP specification
cause during the inter
InterS1InFail_S1AP_LINK_ A call is released due to
FAIL the S1 SCTP link failure
during the inter S1
handover execution.
InterS1InFail_S1AP_SIG_ A call is released due to
FAIL receiving S1AP
signaling during the inter
InterS1InFail_S1AP_SIG_TO A call is released due to
S1AP signaling timeout
inter S1 handover
execution.
Related KPI/PI
N/A
Related Alarms
N/A

Feature Description
Related Status
Check noX2 = True (RTRV-NBR-ENB)
Related Call Faults

N/A

Feature Description
LTE-SW1005, X2 Handover
Overview
Introduction
X2 handover is mobility control functionality between adjacent eNBs. X2 based handover
is used when there is no available direct interface with target eNB and target eNB belongs
to same MME group.
Benefits
Operator can provide connected mobility to its subscribers between cells in different eNBs.
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference

Feature Description
Feature Scope
R1 eNB can determine on intra-LTE handover on the terminal’s measurement results.
R2 eNB can handle measurement configuration of the terminal that supports intra-LTE
handover.
(FDD or TDD) for which to request measurement
Intra- LTE handover
 Selects the best cell of the measured cells included in Measurement Report
cell.
 If Handover target cell is a cell in another eNB and MME group to which target
eNB belongs to is different from source eNB, and if there is no X2 interface
between source eNB and target eNB, carry out X2 handover.
eNB.
R6 eNB can determine whether to accept the request of X2 handover.
R7 eNB can configure Target to Source Transparent Container to be transmitted to source
eNB.
R8 eNB can handle neighboring eNB and HO preparation according to X2 handover
procedures.
R9 eNB can handle data forwarding at the time of X2 handover.
R10 eNB can handle X2 handover cancel procedures.
R11 eNB can collect statistics on outgoing X2 handover procedures.
 Outgoing X2 handover attempt/success/failure (collection unit: source cell, target
cell)
R12 eNB can collect statistic data on the incoming X2 handover procedures.
 Incoming X2 handover attempt/success/failure (collection unit: target cell)

Feature Description
Feature Description
X2 handover is a handover between two adjacent eNBs using the X2 interface (inter eNB
handover via X2 interface). X2 handover is used when there is available direct interface
with the target eNB, or the target eNB belongs to the same MME group.
Following figure shows the X2 handover procedure in E-UTRAN (S1 handover with
Serving GW relocation case)

Feature Description

source eNB.
2) The source eNB makes decision based on the MEASUREMENT REPORT to
handover UE.
3) The source eNB sends HANDOVER REQUEST to the target eNB.
4) The target eNB performs admission control for the incoming handover request.
If accepted, the target eNB prepares the required resources for the UE to be used in the
target cell. Then it returns HANDOVER REQUEST ACKNOWLEDGE message to
the source eNB. The EPS Bearer Setup list includes a list of tunnel information for
receiving forwarded data if necessary.
7) The target eNB sends a PATH SWITCH REQUEST message to MME to inform that
the UE has changed cell.

Feature Description
8)~11) The MME performs S-GW relocation procedure if needed.

12) The MME returns the PATH SWITCH ACKNOWLEDGE message to the target eNB.
13) By sending UE CONTEXT RELEASE, the target eNB informs success of handover to
source eNB and triggers the release of resources by the source eNB.
14) If Serving GW is relocated, the MME releases the UE’s resources that was used in the
source Serving GW.

Feature Description
System operation

CRTE-NBR-EUTRAN Creates information on E-UTRAN neighboring cell to the eNB. The user
can create information on E-UTRAN neighboring cell by entering the
RTRV-NBR-ENB Retrieves information on the neighboring eNB to the eNB. If the index
parameter of the neighboring eNB is entered, the information for a certain
neighboring eNB is retrieved, If not, the information for all neighboring
eNBs is retrieved.
CHG-NBR-ENB Changes the neighboring eNB information required to operate a Neighbor
eNB. This command can change the neighboring eNB information by
entering the NBR_ENB_INDEX parameter.
CRTE-NBR-ENB Creates information on the neighboring eNB for operation. The user can
create information on the neighboring eNB by entering the
NBR_ENB_INDEX parameter value. If parameters are not specified, they
are set to the defaults.
DLT-NBR-ENB Deletes information on the neighboring eNB to the eNB. The user can
delete information on the neighboring eNB by entering the
NBR_ENB_INDEX parameter value.


Feature Description
(Continued)

enbId The eNB ID of the eNB to which E-UTRAN neighboring cell to the eNB
belongs. If the enbType value is macro eNB, 20 bit of the value is eNB ID.
If the enbType value is home eNB, 28 bit of the value is eNB ID. It is used when
enbMcc[4] The PLMN information (MCC) of the eNB to which E-UTRAN neighboring cell
to the eNB belongs. It is a three-digit number with each digit being from 0 to 9.
enbMnc[4] The PLMN information (MNC) of the eNB to which E-UTRAN neighboring cell
to the eNB belongs. It is a three-digit or two-digit number with each digit being
from 0 to 9.

Feature Description
(Continued)
earfcnUl The uplink EARFCN (E-UTRAN Absolute Radio Frequency Channel Number)
earfcnDl The uplink EARFCN (E-UTRAN Absolute Radio Frequency Channel Number)
isRemoveAllow Whether to delete a certain neighboring cell to the eNB using the ANR
ed (Automatic Neighbor Relation) function.
ownerType This parameter defines how NRT is updated, This filed can be classfied Initial
NRT/ANR by Server/ANR by UE/Created by User
nbrEnbIndex Index of the neighboring eNB. The value entered when registering the
neighboring eNB is used.
status The validity of the neighboring eNB information.
- N_EQUIP: Invalid.
- EQUIP: Valid.
noX2 Whether to make X2 connection to the neighboring eNB.
- False: X2 connection with the neighboring eNB is made.
- True: X2 connection to the neighboring eNB is not made.
noHO Whether to perform handover to the neighboring eNB.
- False: Handover to the neighboring eNB is performed.
- True: Handover to the neighboring eNB is not performed.
enbId The eNB ID represents the neighboring eNB. If the enbType value is macro
eNB, 20 bit of the value is eNB ID. If the enbType value is home eNB, 28 bit of
the value is eNB ID.

Feature Description
(Continued)

enbMcc[4] The PLMN information (MCC) that represents the neighboring eNB.
enbMnc[4] The PLMN information (MNC) that represents the neighboring eNB.
It is a three-digit or two-digit number with each digit being from 0 to 9.
ipVer The IP version, which is the IP address of the neighboring eNB.
nbrEnbIPv4 Enter the IP address of the neighboring eNB in the IP version 4 format.
nbrEnbIPv6[16] Enter the IP address of the neighboring eNB in the IP version 6 format.
4 format.
[16] 6 format.
CreatedByUserUI.
remoteFlag This parameter defines the target eNB is managed local EMS or other
EMS
Related Counters
Family
Category FamilyName TypeName Type Description
(KOR)
HO Handover HO_TIME X2HOTime Time taken from transmitting the X2
EUTRAN Time Handover Request Acknowledge
message to the source eNB until
after receiving the
RRCConnectionReconfigurationCo
mplete message from the UE.
X2HOTimeMax Average maximum X2 HO interrupt
time
X2HOTimeTot Sum of X2 HO interrupt time
X2HOTimeCnt Count of X2HOTime collected

Feature Description
(Continued)
Family
(KOR)
HO X2 HO_X2_OUT - -
EUTRAN Handover InterX2OutAtt Attempt count for X2 handover
Out from SeNB.
InterX2OutPrepSucc Success count for X2 handover
preparation from SeNB.
InterX2OutSucc Success count for X2 handover
execution from SeNB.
InterX2OutPrepFail_ Preparation fails due to reset
CP_CC_FAIL notification (eNB failure or block
restart) from ECMB or by ECCB
block during the inter X2
InterX2OutPrepFail_ Preparation fails due to S1
S1AP_LINK_FAIL SCTP link failure during the inter
X2 handover preparation.
InterX2OutPrepFail_ Preparation fails due to
S1AP_SIG_FAIL receiving S1AP signaling during
the inter X2 handover
preparation.
InterX2OutPrepFail_ Preparation fails due to X2AP
X2AP_CU_FAIL specification cause during the
inter X2 handover preparation.
InterX2OutPrepFail_ Preparation fails due to X2
X2AP_LINK_FAIL SCTP link failure during the inter
X2 handover preparation.
InterX2OutPrepFail_ Preparation fails due to X2AP
X2AP_RP_TO relocprep timeout (not received)
during the inter X2 handover
preparation.
InterX2OutPrepFail_ Preparation fails due to
X2AP_SIG_FAIL receiving X2AP signaling during
the inter X2 handover
preparation.
InterX2OutFail_CP_ A call is released due to call
CC_TO control timeout in the protocol
execution.

Feature Description
(Continued)
Family
(KOR)
HO X2 HO_X2_OUT InterX2OutFail_CP_ A call is released due to reset
EUTRAN Handover CC_FAIL notification (eNB failure or block
Out restart) from ECMB or by the
ECCB block during the inter X2
handover execution.
InterX2OutFail_UP_ A call is released due to the
GTP_FAIL failure in the GTP block during
the inter X2 handover execution.
MAC_FAIL internal failure in the MAC block
execution.
PDCP_FAIL internal failure in the PDCP
block during the inter X2
handover execution.
RLC_FAIL internal failure in the RLC block
execution.
InterX2OutFail_RRC A call is released due to
_SIG_FAIL receiving RRC signaling during
InterX2OutFail_ A call is released due to the
S1AP_CU_FAIL S1AP specification cause during
InterX2OutFail_ A call is released due to the S1
S1AP_LINK_FAIL SCTP link failure during the inter
X2 handover execution.
InterX2OutFail_ A call is released due to
S1AP_SIG_FAIL receiving S1AP signaling during
InterX2OutFail_ A call is released due to the
X2AP_CU_FAIL X2AP specification cause during
InterX2OutFail_ A call is released due to the X2
X2AP_LINK_FAIL SCTP link failure during the inter
X2 handover execution.

Feature Description
(Continued)
Family
(KOR)
HO X2 HO_X2_OUT InterX2OutFail_ A call is released due to X2AP
EUTRAN Handover X2AP_RO_TO RelocOverall timeout (not
Out received) during the inter X2
handover execution.
InterX2OutFail_ A call is released due to
X2AP_SIG_FAIL receiving the X2AP signaling
execution.
X2 HO_X2_IN - -
Handover InterX2InAtt Incoming X2 handover attempt
In count (TeNB)
InterX2InPrepSucc Incoming X2 handover
preparation success count
(TeNB)
InterX2InSucc Incoming X2 handover
execution success count
InterX2InPrepFail_ Incoming X2 handover
CP_CC_TO preparation fails due to due to
call control timeout in the
protocol blocks (MAC, RLC,
PDCP, GTP)
CP_CC_FAIL preparation fails due to reset
notification (eNB failure or block
restart) from ECMB or by the
ECCB block
UP_GTP_FAIL preparation fails due to internal
failure in the GTP block
UP_MAC_FAIL preparation fails due to the
failure in the MAC block
UP_PDCP_FAIL preparation fails due to internal
failure in the PDCP block
UP_RLC_FAIL preparation fails due to the
failure in the RLC block

Feature Description
(Continued)
Family
(KOR)
HO X2 HO_X2_IN InterX2InPrepFail_ Incoming X2 handover
EUTRAN Handover CP_BH_CAC_FAIL preparation fails due to
In Backhaul QoS based CAC
CP_CAPA_CAC_ preparation fails due to Capacity
FAIL based CAC
CP_QOS_CAC_ preparation fails due to Air QoS
FAIL based CAC
S1AP_LINK_FAIL preparation fails due to the S1
SCTP link failure
S1AP_SIG_FAIL preparation fails due to
receiving S1AP signaling
InterX2InPrepFail_X Incoming X2 handover
2AP_CU_FAIL preparation fails due to the
S1AP specification cause
X2AP_LINK_FAIL preparation fails due to the X2
SCTP link failure
X2AP_SIG_FAIL preparation fails due to
receiving X2AP signaling
InterX2InFail_CP_ Incoming X2 handover fails due
CC_TO to call control timeout in the
protocol blocks (MAC, RLC,
PDCP, GTP)
InterX2InFail_CP_ Incoming X2 handover fails due
CC_FAIL to reset notification (eNB failure
or block restart) from ECMB or
by the ECCB block
InterX2InFail_UP_ Incoming X2 handover fails due
GTP_FAIL to the failure in the GTP block
MAC_FAIL to the failure in the MAC block
PDCP_FAIL to to internal failure in the PDCP
block

Feature Description
(Continued)
Family
(KOR)
HO X2 HO_X2_IN InterX2InFail_UP_ Incoming X2 handover fails due
EUTRAN Handover RLC_FAIL to the failure in the RLC block
In InterX2InFail_RRC_ Incoming X2 handover fails due
HC_TO to HO preparation timeout (not
received HO command)
InterX2InFail_RRC_ Incoming X2 handover fails due
SIG_FAIL to receiving RRC signaling
InterX2InFail_S1AP_ Incoming X2 handover fails due
CU_FAIL to the S1AP specification cause
LINK_FAIL to the S1 SCTP link failure
PATH_TO to S1AP path switch timeout
(not received)
SIG_FAIL to receiving S1AP signaling
InterX2InFail_X2AP_ Incoming X2 handover fails due
CU_FAIL to the X2AP specification cause
LINK_FAIL to the X2 SCTP link failure
SIG_FAIL to receiving X2AP signaling
SIG_TO to X2AP signaling timeout (not
received)
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
 Check noX2 = False (RTRV-NBR-ENB)
 There should be valid information for the target eNB (RTRV-NBR-ENB)

Feature Description
Related Call Faults

N/A

Feature Description
LTE-SW1006, Data forwarding

Overview
Introduction
During handover, source eNB forwards PDCP SDUs in sequence to target eNB. Direct data
forwarding is used when a direct path between source eNB and target eNB is available.
Otherwise indirect data forwarding is used, where PDCP packets are delivered to target
eNB through S-GW.
Benefits
Users can obtain session continuity during handover within E-UTRAN, with almost no
interruption
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference

Feature Description
Feature Scope
R1 eNB can handle data forwarding of downlink packets at the time of inter-eNB
handover.
 Downlink packets that have not been acknowledged by the UE (RLC-AM)
 Downlink packets for which transmission have not been completed (RLC-UM)
 Fresh data arriving over S1 (RLC-AM/UM)
R2 eNB can handle data forwarding of uplink packets at the time of inter-eNB handover.
 Uplink data received out of sequence (RLC-AM)
R3 eNB can, when inter-eNB handover request has been accepted, determine whether to
carry out uplink data forwarding based on the system settings.
R4 eNB can, for S1 handover, include downlink path availability into S1 Handover
Required message dpending on X2 interface with target eNB.

Feature Description
Feature Description
The source eNB decides which of the EPS bearers are subject for forwarding of packets
from the source eNB to the target eNB. Samsung source eNB always requests downlink
forwarding to the target eNB and the bearers that have accepted by the target eNB will be
forwarded. Samsung target eNB always accepts downlink forwarding if handover
admission is success. If uplink forwarding, Samsung target eNB requests to the source eNB
according to system configuration by operator and the bearers that have accepted by the
source eNB will be forwarded. Samsung source eNB always accepts the uplink forwarding
request from the target eNB. Based on 3GPP standards, following packets can be
forwarded to the target eNB:
 Downlink packets that have not been acknowledged by the UE (RLC-AM)
 Downlink packets for which transmission have not been completed (RLC-UM)
 Fresh data arriving over S1 (RLC-AM/UM)
 Uplink data received out of sequence (RLC-AM)
In case of S1 handover, data forwarding can take place either directly from the source
eNodeB to the target eNodeB, or indirectly from the source eNodeB to the target eNodeB
via the Serving GW. If X2 connectivity is available between the source and target eNodeBs,
a direct forwarding is used. If a direct forwarding path is not available, indirect forwarding
may be used. The source eNodeB indicates the availability of a direct forwarding path to
the MME. The source MME uses the indication from the source eNodeB to determine
whether to apply indirect forwarding. In case of MME relocation case, the source MME
indicates to the target MME whether indirect forwarding should apply. Based on this
indication, the target MME determines whether it applies indirect forwarding.
In case of X2 handover, only direct data forwarding can be possible.

Feature Description
System operation
Commands and Parameter
RTRV-PDCP-INF Retrieves information of the PDCP. The PDCP information to be retrieved is

the UM SN size by QoS class, discard timer, and forward end timer. If a QoS
class is not specified, the entire information on 256 QoS classes is retrieved.
CHG-PDCP-INF Changes the parameter values of the PDCP protocol. This command can
change the UM SN size; discard timer value, forward end timer value for each
of 256 QoS classes. The changes do not affect the existing calls and are
applied only to the new calls.

Commands Parameter Default Value Description
RTRV-PDCP-INF QCI - The standard QCIs defined in the standard

CHG-PDCP-INF documents is 1 to 9.
The operator can use QCI values 128-254.
UM_SN_SIZE ci_len12bits The size of PDCP Sequence Number (SN)
in RLC UM mode.
- ci_len7bits: Uses the size of 7 bits (0 to
127).
- ci_len12bits: The size of 12 bits (0 to
4095) is used (Default).
DISCARD_TI ci_discardTimer The Discard timer value for a packet buffer
MER _infinity managed per RB in RLC AM mode. If ACK
is not received from the RLC within a
specified period of time, the packet is
discarded.
- ci_discardTimer_ms50: 50 msec.
- ci_discardTimer_infinity: The discard
timer is disabled. (default).
FWD_END_TI 200 A period of time when PDCP of target eNB
MER waits for end marker upon receiving a
HO_COMPLETE message. in milliseconds.
STATUS_REP True This value determines whether or not to
ORT_REQUI send SN Status Report.
RED

Feature Description
Related Counters
GTP GTP_FW_ CntGtpDlEnbS1Nor S1 downlink GTP packet counts

ENB CntGtpUlEnbS1Nor S1 uplink GTP packet counts
CntGtpDlEnbS1FW S1 downlink forwarding (received)
packet counts when S1 Handover
CntGtpUlEnbS1FW S1 uplink forwarding (transmitting)
packet counts when S1 Handover
CntGtpDlEnbX2FW X2 downlink forwarding (received)
packet counts when X2 Handover
CntGtpUlEnbX2FW X2 uplink forwarding (transmitting)
packet counts when X2 Handover
ByteGtpDlEnbS1Nor Bytes of S1 downlink GTP packet
ByteGtpUlEnbS1Nor Bytes of S1 uplink GTP packet
ByteGtpDlEnbS1FW Bytes of S1 downlink forwarding
(received) packet when S1 Handover
ByteGtpUlEnbS1FW Bytes of S1 uplink forwarding
(transmitting) packet when S1 Handover
ByteGtpDlEnbX2FW Bytes of X2 downlink forwarding
(received) packet when X2 Handover
ByteGtpUlEnbX2FW Bytes of X2 uplink forwarding
(transmitting) packet when X2 Handover
ThruGtpDlEnbS1Nor Throughput of S1 downlink GTP packet
ThruGtpDlEnbS1NorTot Summation of the collected
ThruGtpDlEnbS1Nor
ThruGtpDlEnbS1NorCnt Counts of the collected
ThruGtpDlEnbS1Nor
ThruGtpUlEnbS1Nor Throughput of S1 uplink GTP packet
ThruGtpUlEnbS1NorTot Summation of the collected
ThruGtpUlEnbS1Nor
ThruGtpUlEnbS1NorCnt Counts of the collected
ThruGtpUlEnbS1Nor
ThruGtpDlEnbS1FW Throughput of S1 downlink forwarding
(received) packet counts when S1
Handover
ThruGtpDlEnbS1FWTot Summation of the collected
ThruGtpDlEnbS1FW
ThruGtpDlEnbS1FWCnt Counts of the collected
ThruGtpDlEnbS1FW

Feature Description
(Continued)
GTP GTP_FW_ENB ThruGtpUlEnbS1FW Throughput of S1 uplink forwarding

(transmitting) packet counts when S1
Handover
ThruGtpUlEnbS1FWTot Summation of the collected
ThruGtpUlEnbS1FW
ThruGtpUlEnbS1FWCnt Counts of the collected
ThruGtpUlEnbS1FW
ThruGtpDlEnbX2FW Throughput of X2 downlink forwarding
(received) packet counts when X2
Handover
ThruGtpDlEnbX2FWTot Summation of the collected
ThruGtpDlEnbX2FW
ThruGtpDlEnbX2FWCnt Counts of the collected
ThruGtpDlEnbX2FW
ThruGtpUlEnbX2FW Throughput of X2 uplink forwarding
(transmitting) packet counts when X2
Handover
ThruGtpUlEnbX2FWTot Summation of the collected
ThruGtpUlEnbX2FW
ThruGtpUlEnbX2FWCnt Counts of the collected
ThruGtpUlEnbX2FW
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1007, Inter-Frequency Handover

Overview
Introduction
Inter-frequency handover is mobility control functionality between cells that use different
frequency band. eNB provides UEs with measurement gap information in order for the UEs
to perform inter frequency search. Measurement Gap avoids scheduling of data for the UE
during inter frequency scan periods.
Benefits
Operator can provide connected mobility to its subscribers between cells which have a
different center frequency.
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference
X2 Application Protocol (X2AP)

Feature Description
Feature Scope
R1 eNB can control the terminal’s inter-frequency measurement.
 Incorporate UE supported bands for E-UTRAN
 Incorporate UE Radio Access Capability for inter-frequency measurement (FGI bit
number 25)
 Incorporate the necessity of measurement gap per UE supported band
 Measurement gap activation/deactivation if needed
R2 eNB can determine on inter-frequency handover based on the terminal’s measurement.
R3 eNB can handle the measurement configuration of the terminal that supports the inter-
frequency handover.
(FDD or TDD) for which to request measurement.
Inter-frequency handover
R4 eNB can determine on target cell of inter-frequency handover.
 Selects the best cell of inter-frequency cells included in Measurement Report
eNB.
R6 eNB can determine whether to accept when requested of handover from a neighboring
inter-frequency cell.
R7 eNB can configureTarget to Source Transparent Container to be transmitted to source
eNB.
R8 eNB can handle the neighboring eNB and HO preparation according to S1/X2
handover prcecures.
R9 eNB can handle data forwarding at time of S1/X2 handover.
R10 eNB can handle S1/X2 handover cancel procedures.
R11 eNB can collect statistic data on the intra-eNB handover procedures.
 Intra-eNB handover attempt/success/failure (collection unit: source cell, target cell)
R12 eNB can collect statistic data on the outgoing intra-LTE handover procedures.
 Outgoing intra-LTE handover attempt/success/failure (collection unit: source cell,
target cell)
R13 eNB can collect statistic data on the incoming intra-LTE handover procedures.
 Incoming intra-LTE handover attempt/success/failure (collection unit: target cell)

Feature Description
Feature Description
If a user moves to a neighboring carrier while receiving a service, eNB provides the service
continuity in LTE through inter-frequency handover.
eNB determines whether to have UE to switch into the neighboring carrier coverage based
on the measurement report of UE. eNB receives the result of inter-frequency measurement
of UE, selects the handover target cell, and performs handover preparation with the target
cell/eNB. If the handover preparation with the target cell/eNB is performed successfully,
eNB commands UE to perform the inter-frequency handover. UE performs handover to the
target cell designated by eNB, continuing to receive the service.
When a handover is triggered, the source eNB decides an appropriate handover procedure
based on the target cell information. If the target cell has different downlink carrier
frequency from the serving cell, inter-frequency handover procedure is performed.
 Inter-frequency handover procedures:
− Intra-eNB handover (Refer to LTE-SW1003)
− S1 handover (Refer to LTE-SW1004)
− X2 handover (Refer to LTE-SW1005)

Feature Description
Inter-frequency X2 handover procedures:
1) UE transmits a measurement report including the inter-frequency measurement.

2) Source eNB decides inter-frequency X2 handover to the target eNB.
3) Source eNB transmits a handover request to the source MME, requesting X2 handover.
4) If call acceptance is possible, Target eNB allocates resources so that UE can maintain
the data service in the target cell after handover, and transmits the handover request
acknowledge to the source eNB. If data forwarding is possible, tunnel setup for data
forwarding is performed.
5) Source eNB transmits a RRC connection reconfiguration message including the HO
command from the target eNB to UE.
6) UE switches to the target cell designated by the source eNB, and transmits a RRC
connection reconfiguration complete message to the target eNB.
7) Target eNB transmits a path switch request to MME.
8)~11) MME performs the user plane path switch process with S-GW.
12) MME transmits a path switch request acknowledge to the target eNB.
13) Target eNB and releases resources used by source eNB after X2 handover.

Feature Description
If inter-frequency handover is not possible, the intra-LTE redirection (release with redirect
within E-UTRAN) is used.
 Intra-eNB redirection (Refer to LTE-SW1010)

Feature Description
System operation
Command Parameters/Description
CHG-EUTRA-FA Changes and retrieves parameters of measurement object in order to

RTRV-EUTRA-FA trigger inter frequency handover.
- EARFCN_DL: Carrier frequency of the measurement object required to
trigger inter frequency handover.
- MEASUREMENT_BANDWIDTH: Max. allowable measurement
bandwidth for EARFCN_DL.
- PRESENCE_ANT_PORT1: Commands whether all the neighboring
cells should use Antenna Port 1.
- NEIGH_CELL_CONFIG: Provides information related to MBSFN and
TDD UL/DL configuration of neighbour cells of this frequency
 00: Not all neighbour cells have the same MBSFN subframe allocation
as serving cell
 10: The MBSFN subframe allocations of all neighbour cells are
identical to or subsets of that in the serving cell
 01: No MBSFN subframes are present in all neighbour cells
 11: Different UL/DL allocation in neighbouring cells for TDD compared
to the serving cell
For TDD, 00, 10 and 01 are only used for same UL/DL allocation in
neighbouring cells compared to the serving cell
- OFFSET_FREQ: Indicate a cell or frequency specific offset to be
applied when evaluating triggering conditions for measurement
reporting.
CRTE-NBR-EUTRAN Creates/deletes/changes/retrieves information on the target neighbor cell
DLT-NBR-EUTRAN of inter frequency handover.
CHG-NBR-EUTRAN - PHY_CELL_ID: Physical cell ID of the neighbor cell transmitting the
RTRV-NBR-EUTRAN carrier frequency of the measurement object.
- IND_OFFSET: Offset value applied to the neighbor cell.
CRTE-BLACK-LIST Creates/deletes/changes/retrieves information on the black listed
DLT-BLACK-LIST neighbor cell which is not an object of inter frequency handover.
CHG-BLACK-LIST - START_PCI: Physical cell ID of the black listed neighbor cell
RTRV-BLACK-LIST transmitting the carrier frequency of the measurement object.
- PCI_RANGE: Range from the starting physical cell ID of the black listed
neighbor cell.

Feature Description
(Continued)
CHG-EUTRA-A1CNF Changes and retrieves the parameter values of reporting configuration for
RTRV-EUTRA-A1CNF Event A1 to perform inter frequency handover.
- A1_THRESHOLD_RSRP: RSRP threshold used in the Event A1
EUTRA measurement report triggering condition.
- A1_THRESHOLD_RSRQ: RSRQ threshold used in the Event A1
- HYSTERESIS: The entry and leave condition of an event triggered
reporting condition
- TIME_TO_TRIGGER: Time during which specific criteria for the event
needs to be met in order to trigger a measurement report.
- TRIGGER_QUANTITY: The quantities used to evaluate the triggering
condition for the event. The values rsrp and rsrq correspond to
Reference Signal Received
Power (RSRP) and Reference Signal Received Quality (RSRQ),
- REPORT_QUANTITY: The quantities to be included in the
measurement report. The value both means that both the rsrp and rsrq
quantities are to be included in the measurement report.
- MAX_REPORT_CELL: Max number of cells, excluding the serving cell,
to include in the measurement report.
- REPORT_INTERVAL: Interval of the measurement report for Event A1.
- REPORT_AMOUNT: The number of measurement reports for Event A1.
- A2_THRESHOLD_RSRP: RSRP threshold used in the Event A2
- A2_THRESHOLD_RSRQ: RSRQ threshold used in the Event A2
reporting condition

Feature Description
(Continued)
- A3_OFFSET: RSRP threshold used in the Event A3 EUTRA
measurement report triggering condition.
- A3_REPORT_ON_LEAVE: Indicates whether or not the UE shall initiate
the measurement reporting procedure when the leaving condition is met
for a cell in cellsTriggeredList.
reporting condition
- A5_THRESHOLD1_RSRP: RSRP threshold 1 used in the Event A5
- A5_THRESHOLD1_RSRQ: RSRQ threshold 1 used in the Event A5
- A5_THRESHOLD2_RSRP: RSRP threshold 2 used in the Event A5
- A5_THRESHOLD2_RSRQ: RSRQ threshold 2 used in the Event A5
reporting condition

Feature Description
(Continued)
CHG-EUTRA-A5CNF Power (RSRP) and Reference Signal Received Quality (RSRQ),

RTRV-EUTRA-A5CNF - REPORT_QUANTITY: The quantities to be included in the
CHG-QUANT-EUTRA Changes and retrieves the parameter values of quantity configuration to
RTRV-QUANT- trigger inter frequency handover.
EUTRA - RSRP_FILTER_COEFFICIENT: Specifies the filtering coefficient used
for RSRP.
- RSRQ_FILTER_COEFFICIENT: Specifies the filtering coefficient used
for RSRQ.
CHG-MSGAP-INF Changes and retrieves the parameter values of measurement gap
RTRV-MSGAP-INF configuration to trigger inter frequency handover.
- GAP_PATTERN_FOR_INTER_FA: The gapOffset value used for inter
frequency measurement.
Value gapOffset of gp0 corresponds to gap offset of Gap Pattern Id ‘0’
with MGRP = 40 ms, gapOffset of gp1 corresponds to
gap offset of Gap Pattern Id ‘1’ with MGRP = 80 ms.
CHG-MEAS-FUNC Changes and retrieves s-measure and timeToTrigger-SF value to trigger
RTRV-MEAS-FUNC inter frequency.
- S_MEASURE: Serving cell quality threshold controlling whether or not
the UE is required to perform measurements of inter-frequency
neighbouring cells. Value
‘0’ indicates to disable s-Measure.
- TIME_TO_TRIGGER_SF_MEDIUM: The concerned mobility control
related parameter is multiplied with this factor if the UE is in Medium
Mobility state.
- TIME_TO_TRIGGER_SF_HIGH: The concerned mobility control related
parameter is multiplied with this factor if the UE is in High Mobility state.
CHG-MOBIL-STA Changes and retrieves the mobility state parameter values to trigger inter
RTRV-MOBIL-STA frequency handover.
- SPEED_STATE_RE_SEL_PARS_USAGE: Decides whether to use the
speedStateReselectonPars field of the cell.
- T_EVALULATION: The duration for evaluating criteria to enter mobility
states.
- T_HYST_NORMAL: The additional duration for evaluating criteria to
enter normal mobility state
- N_CELL_CHANGE_MEDIUM: The number of cell changes to enter
medium mobility state.
- N_CELL_CHANGE_HIGH: The number of cell changes to enter high
mobility state.

Feature Description
(Continued)
CHG-HO-OPT Changes and retrieves optional action values for inter frequency
RTRV-HO-OPT handover.
- ERAB_INTERACTION: Decides which procedure should be handled
first if the E-RAB procedure and the handover procedure compete with
each other.
- USED_NBR_LIST: Method of providing the list of neighbor cells
included in MeasObjectEUTRA.
If this value is 0, the list only includes the neighbor cells of which CIO is
not dB0. If it is 1, the list also includes the neighbor cells of which CIO is
dB0.
- UPLINK_FORWARD: Decides if the target eNB should perform uplink
data forwarding for handover.
CRTE-NBR-ENB Creates/deletes/changes/retrieves eNB information required to perform
DLT-NBR-ENB x2 handover for inter frequency handover.
CHG-NBR-ENB - NO_X2: X2 connection setup with neighbor eNB.
RTRV-NBR-ENB - NO_HO: Decides whether to perform handover with a neighbor eNB.
- ENB_ID: eNB ID representing a neighbor eNB. If enbType is Macro
eNB, 20 bit of the value is eNB ID, and if it is Home eNB, 28 bit of the
value is eNB ID.
- ENB_TYPE: Decides if the neighbor eNB is Macro eNB or Home eNB.
- ENB_MCC: PLMN information (MCC) representing the neighbor eNB.
- ENB_MNC: PLMN information (MNC) representing the neighbor eNB.
- IP_VER: Version of the IP address of the neighbor eNB.
- NBR_ENB_IPV4: IP address of the neighbor eNB in the form of IP
version 4.
- NBR_ENB_IPV6: IP address of the neighbor eNB in the form of IP
version 6.

Feature Description
Related Counters
Counter Description
InterFreqMeasGapOutAtt Outgoing inter-frequency handover (measurement gap assisted)

attempt count
InterFreqMeasGapOutPr Outgoing inter-frequency handover (measurement gap assisted)
epSucc preparation success count
InterFreqMeasGapOutSu Outgoing inter-frequency handover (measurement gap assisted)
cc execution success count
InterFreqMeasGapOutPr Preparation fails due to reset notice from ECMB (node failure or block
epFail_CP_CC_FAIL restart) or ECCB block during the outgoing Inter-frequency handover
(no measurement gap assisted) preparation.
InterFreqMeasGapOutPr Preparation fails due to the S1AP specification cause during the
epFail_S1AP_CU_FAIL outgoing inter-frequency handover (measurement gap assisted)
preparation.
InterFreqMeasGapOutPr Preparation fails due to the S1 SCTP link failure during the outgoing
epFail_S1AP_LINK_FAIL inter-frequency handover (measurement gap assisted) preparation.
InterFreqMeasGapOutPr Preparation fails due to S1AP relocprep timeout (not received) during
epFail_S1AP_RP_TO the outgoing inter-frequency handover (measurement gap assisted)
preparation.
InterFreqMeasGapOutPr Preparation fails due to receiving S1AP signaling during the outgoing
epFail_S1AP_SIG_FAIL inter-frequency handover (measurement gap assisted) preparation.
InterFreqMeasGapOutPr Preparation fails due to the X2AP specification cause during the
epFail_X2AP_CU_FAIL outgoing inter-frequency handover (measurement gap assisted)
preparation.
InterFreqMeasGapOutPr Preparation fails due to the X2 SCTP link failure during the outgoing
epFail_X2AP_LINK_FAIL inter-frequency handover (measurement gap assisted) preparation.
InterFreqMeasGapOutPr Preparation fails due to X2AP relocprep timeout (not received) during
epFail_X2AP_RP_TO the outgoing inter-frequency handover (measurement gap assisted)
preparation.
InterFreqMeasGapOutPr Preparation fails due to receiving X2AP signaling during the outgoing
epFail_X2AP_SIG_FAIL inter-frequency handover (measurement gap assisted) preparation.
InterFreqMeasGapOutFa A call is released due to call control timeout in the protocol blocks
il_CP_CC_TO (MAC, RLC, PDCP, GTP) during the outgoing inter-frequency
handover (measurement gap assisted) execution.
InterFreqMeasGapOutFa A call is released due to reset notification (eNB failure or block restart)
il_CP_CC_FAIL from ECMB or by the ECCB block during the outgoing inter-frequency
handover (measurement gap assisted) execution.
InterFreqMeasGapOutFa A call is released due to the failure in the GTP block during the
il_UP_GTP_FAIL outgoing inter-frequency handover (measurement gap assisted)
execution.
InterFreqMeasGapOutFa A call is released due to the failure in the MAC block during the
il_UP_MAC_FAIL outgoing inter-frequency handover (measurement gap assisted)
execution.

Feature Description
(Continued)
Counter Description
InterFreqMeasGapOutFa A call is released due to the failure in the PDCP block during the
il_UP_PDCP_FAIL outgoing inter-frequency handover (measurement gap assisted)
execution.
InterFreqMeasGapOutFa A call is released due to the failure in the RLC block during the
il_UP_RLC_FAIL outgoing inter-frequency handover (measurement gap assisted)
execution.
InterFreqMeasGapOutFa A call is released due to receiving RRC signaling during the outgoing
il_RRC_SIG_FAIL inter-frequency handover (measurement gap assisted) execution.
InterFreqMeasGapOutFa A call is released due to the S1AP specification cause during the
il_S1AP_CU_FAIL outgoing inter-frequency handover (measurement gap assisted)
execution.
InterFreqMeasGapOutFa A call is released due to the S1 SCTP link failure during the outgoing
il_S1AP_LINK_FAIL inter-frequency handover (measurement gap assisted) execution.
InterFreqMeasGapOutFa A call is released due to the S1AP relocoverall timeout (not received)
il_S1AP_RO_TO during the outgoing inter-frequency handover (measurement gap
assisted) execution.
InterFreqMeasGapOutFa A call is released due to receiving S1AP signaling during the outgoing
il_S1AP_SIG_FAIL inter-frequency handover (measurement gap assisted) execution.
InterFreqMeasGapOutFa A call is released due to the X2AP specification cause during the
il_X2AP_CU_FAIL outgoing inter-frequency handover (measurement gap assisted)
execution.
InterFreqMeasGapOutFa A call is released due to the X2 SCTP link failure during the outgoing
il_X2AP_LINK_FAIL inter-frequency handover (measurement gap assisted) execution.
InterFreqMeasGapOutFa A call is released due to the X2AP relocoverall timeout (not received)
il_X2AP_RO_TO during the outgoing inter-frequency handover (measurement gap
InterFreqMeasGapOutFa A call is released due to receiving X2AP signaling during the outgoing
il_X2AP_SIG_FAIL inter-frequency handover (measurement gap assisted) execution.
InterFreqNoMeasGapOut Outgoing inter-frequency handover (no measurement gap assisted)
Att attempt count
PrepSucc preparation success count
Succ execution success count
InterFreqNoMeasGapOut Preparation fails due to reset notice from ECMB (node failure or block
PrepFail_CP_CC_FAIL restart) or ECCB block during the outgoing Inter-frequency handover
(no measurement gap assisted) preparation.
InterFreqNoMeasGapOut Preparation fails due to the S1AP specification cause during the
PrepFail_S1AP_CU_FAIL outgoing inter-frequency handover (no measurement gap assisted)
preparation.

Feature Description
(Continued)
Counter Description
InterFreqNoMeasGapOut Preparation fails due to the S1 SCTP link failure during the outgoing
PrepFail_S1AP_LINK_F inter-frequency handover (no measurement gap assisted) preparation.
AIL
InterFreqNoMeasGapOut Preparation fails due to S1AP relocprep timeout (not received) during
PrepFail_S1AP_RP_TO the outgoing inter-frequency handover (no measurement gap assisted)
preparation.
InterFreqNoMeasGapOut Preparation fails due to receiving S1AP signaling during the outgoing
PrepFail_S1AP_SIG_FAI inter-frequency handover (no measurement gap assisted) preparation.
L
InterFreqNoMeasGapOut Preparation fails due to the X2AP specification cause during the
PrepFail_X2AP_CU_FAIL outgoing inter-frequency handover (no measurement gap assisted)
preparation.
InterFreqNoMeasGapOut Preparation fails due to the X2 SCTP link failure during the outgoing
PrepFail_X2AP_LINK_F inter-frequency handover (no measurement gap assisted) preparation.
AIL
InterFreqNoMeasGapOut Preparation fails due to X2AP relocprep timeout (not received) during
PrepFail_X2AP_RP_TO the outgoing inter-frequency handover (no measurement gap assisted)
preparation.
InterFreqNoMeasGapOut Preparation fails due to receiving X2AP signaling during the outgoing
PrepFail_X2AP_SIG_FAIL inter-frequency handover (no measurement gap assisted) preparation.
InterFreqNoMeasGapOut A call is released due to call control timeout in the protocol blocks
Fail_CP_CC_TO (MAC, RLC, PDCP, GTP) during the outgoing inter-frequency
handover (no measurement gap assisted) execution.
InterFreqNoMeasGapOut A call is released due to reset notification (eNB failure or block restart)
Fail_CP_CC_FAIL from ECMB or by the ECCB block during the outgoing inter-frequency
handover (no measurement gap assisted) execution.
InterFreqNoMeasGapOut A call is released due to the failure in the GTP block during the
Fail_UP_GTP_FAIL outgoing inter-frequency handover (no measurement gap assisted)
execution.
InterFreqNoMeasGapOut A call is released due to the failure in the MAC block during the
Fail_UP_MAC_FAIL outgoing inter-frequency handover (no measurement gap assisted)
execution.
InterFreqNoMeasGapOut A call is released due to the failure in the PDCP block during the
Fail_UP_PDCP_FAIL outgoing inter-frequency handover (no measurement gap assisted)
execution.
InterFreqNoMeasGapOut A call is released due to the failure in the RLC block during the
Fail_UP_RLC_FAIL outgoing inter-frequency handover (no measurement gap assisted)
execution.
InterFreqNoMeasGapOut A call is released due to receiving RRC signaling during the outgoing
Fail_RRC_SIG_FAIL inter-frequency handover (no measurement gap assisted) execution.

Feature Description
(Continued)
Counter Description
InterFreqNoMeasGapOut A call is released due to the S1AP specification cause during the
Fail_S1AP_CU_FAIL outgoing inter-frequency handover (no measurement gap assisted)
execution.
InterFreqNoMeasGapOut A call is released due to the S1 SCTP link failure during the outgoing
Fail_S1AP_LINK_FAIL inter-frequency handover (no measurement gap assisted) execution.
InterFreqNoMeasGapOut A call is released due to the S1AP relocoverall timeout (not received)
Fail_S1AP_RO_TO during the outgoing inter-frequency handover (no measurement gap
InterFreqNoMeasGapOut A call is released due to receiving S1AP signaling during the outgoing
Fail_S1AP_SIG_FAIL inter-frequency handover (no measurement gap assisted) execution.
InterFreqNoMeasGapOut A call is released due to the X2AP specification cause during the
Fail_X2AP_CU_FAIL outgoing inter-frequency handover (no measurement gap assisted)
execution.
InterFreqNoMeasGapOut A call is released due to the X2 SCTP link failure during the outgoing
Fail_X2AP_LINK_FAIL inter-frequency handover (no measurement gap assisted) execution.
InterFreqNoMeasGapOut A call is released due to the X2AP relocoverall timeout (not received)
Fail_X2AP_RO_TO during the outgoing inter-frequency handover (no measurement gap
InterFreqNoMeasGapOut A call is released due to receiving X2AP signaling during the outgoing
Fail_X2AP_SIG_FAIL inter-frequency handover (no measurement gap assisted) execution.
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1009, Multi-target Preparation

Overview
Introduction
Multi Target preparation allows eNB to trigger handover procedure to more than one target
eNodeB for improving user experiences.
Benefits
Users can obtain session continuity with fast recovery of ongoing sessions though
handover failure has been experienced during handover.
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference
4) 3GPP TS36.423 Evolved Universal Terrestrial Access Network (E-UTRAN); X2
Application Protocol (X2AP)

Feature Description
Feature Description
Multiple target preparation allows eNB to trigger handover procedure to more than one
target eNB for improving user experiences. This is possible because there are other
prepared eNBs except the target eNB, and the handover is regarded as successful in case
the UE moves to one of the other prepared eNBs instead of the target eNB.
Handover preparation request is sent to multiple candidate target eNBs based on the
measurement report received from the UE. Only one target is chosen for the UE to
handover. If the UE fails handover to the above target, the UE can re-establish the
connection successfully with the source eNB or the other prepared eNBs that already have
the UE context.
To select the candidate target eNBs for multiple target preparation, eNB stores UE’s
measurement report whenever reported. If intra-LTE handover is triggered, the source eNB
determines the candidate target eNBs based on the recently stored information. The number
of the candidate target eNBs (max. four) is configured by system parameter.
Then the source eNB performs handover preparation with the target eNB corresponding to
the handover event and the selected candidate target eNBs. When handover preparation
with the target eNB is completed, the source eNB orders a handover to the target cell to UE.
At this time, if there are any candidate eNBs still during handover preparation, the source
eNB cancels each ongoing handover preparation(s).
If handover to the target cell is failed, the UE initiates RRC connection reestablishment
procedure. In case the eNB receiving RRC Connection Reestablishment Request from UE
has the UE’s context, i.e. the eNB is one of the source eNB, the target eNB or any prepared
eNBs, the following RRC connection reestablishment and RRC connection reconfiguration
procedures can be performed.
After the UE is connected successfully, the prepared eNB sends UE CONTEXT RELEASE
message (if X2 handover case) to the source eNB. The source eNB regards that the
handover is completed successfully and cancels remaining prepared handover.

Feature Description
System operation
RTRV-HO-OPT This command retrieve/change information of handover.

CHG-HO-OPT
RTRV-HO-OPT dbIndex Tuple index.

CHG-HO-OPT erabInteraction Prioritization information when contention occurs between E-
RAB and handover procedures.
- 0: Performs handover first (Handover Prior).
- 1: Performs E-RAB procedures (ERAB Prior).
usedNbrList The method for providing the neighboring cell list included in
MeasObjectEUTRA of the RRC Connection Reconfiguration
message.
- 0: Neighboring cells whose CIO value is not dB0 are only
included in the list (by algorithm).
- 1: Neighboring cells whose CIO value is dB0 are also
included in the list (force-used).
uplinkForward Whether to forward uplink data in the target base station
during handover.
- 0: Uplink data forwarding is disabled.
- 1: Uplink data forwarding is enabled.
numOfeNB The number of target base stations for multi-target
preparation during handover. The maximum of 4 eNBs can
be prepared. If the value entered is 1, the multi-target
preparation is not executed.
rimEnable Whether to RIM procedure decision.
mmeSelectFac This parameter is MME Selection Factor for RIM Procedure.
torForRim

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1010, Inter-Frequency Redirection

Overview
Introduction
This is intra-LTE mobility functionality towards different LTE carriers from serving carrier.
Benefits
Operator can provide connected mobility to its subscribers between LTE carriers, though
not inter-frequency handover
Release History
SLR2.2
Basic or Optional
Basic

Dependency:
 None
Limitation:
 None
Reference
X2 Application Protocol (X2AP)

Feature Description
Feature Scope
R1 eNB can control the inter-frequency measurement of the terminal.
 Incorporate UE supported bands for E-UTRAN
number 25)
R2 eNB can determine on inter-frequency redirection based on the UE measurement
results (intra-frequency or inter-frequency).
 Use Inter-frequency measurement if the terminal supports inter-frequency
measurement but with Blind option not activated
 Use Intra-frequency measurement if the terminal does not support inter-frequency
measurement or if Blind option is activated
R3 eNB can determine on inter-frequency redirection procedure based on UE Radio
Access Capability. If it is impossible to carry out Inter-frequency handover, carry out
inter-frequency redirection.
R4 eNB can select an E-UTRA carrier for redirection among the neighboring E-UTRA
carriers based on E-UTRA supported band (FDD or TDD) supported by the terminal.
 Using Inter-frequency measurement: select Measurement Report’s inter-frequency
carrier
 Using Intra-frequency measurement: select round robin if there are multiple
selectable inter-frequency carriers
R5 eNB can collect statistics on the inter-frequency redirection procedure.
 Inter-frequency redirection attempt/success/failure (collection unit: source cell)

Feature Description
Feature Description
When a mobility event is occurred by UE measurement results and redirection towards
inter-frequency is only possible, eNodeB initiates the redirection (release with redirect)
procedures. The redirected carrier information is indicated to UE and UE shall attempt to
camp on a suitable cell according to the redirected carrier information in the RRC
CONNECTION RELEASE message.
Followings are the cases that intra-LTE redirection is only possible because inter-frequency
handover cannot be possible:
 Neighbour cell list corresponding to the UE supported bands is empty; or
 Blind redirection within intra-LTE is activated; or
 Inter-frequency measurement isn’t support by UE based on FGI bit number 25; or
 Inter-frequency handover isn’t supported by UE:
− Based on FGI bit number 13 when inter-frequency handover within FDD or TDD;
− Based on FGI bit number 30 when inter-frequency handover between FDD and
TDD.
Following figure shows the intra-LTE redirection procedure.

Feature Description
1) The eNB receives a measurement report from the MS.

2) The eNB determines inter-frequency redirection.
3) The eNB transmits RRC Connection Release to the MS including the LTE (FDD or
TDD) carrier frequency to which the MS will be switched.
4) The eNB transmits the UE Context Release Request to the MME.
5) The MME sends the UE Context Release Command to the eNB.
6) The eNB transmits the UE Context Release Complete to the MME.
7) The MS is switched to the inter-frequency carrier (FDD or TDD) that is specified in
the RRC Connection Release by the eNB and provides continued service while
standing by.

Feature Description
System operation
Command Command Description
RTRV-INTWO-OPT This command is used to retrieve interworking option information.

CHG-INTWO-OPT You can retrieve/change the operation setting status of
interFreqRedirection by entering CELL_NUM.
RTRV-EUTRA- Retrieves the EUTRA A2 criteria information. It uses the CELL_NUM and
A2CNF PURPOSE parameter values to retrieve only the EUTRAN A2 event report
CHG-EUTRA-A2CNF registered with a specific E-UTRAN served cell. If no CELL_NUM or
PURPOSE parameter value is entered, all EUTRAN A2 event reports are
retrieved.
Note: For intra-LTE redirection, use-ci_A2PurposeLteBlind: Trigger for
LTE Blind Redirection as a purpose. (Measurement based
Redirection is to be determined.)
Command Parameters Range Description
RTRV-INTWO-OPT cellNum 0~MAC_CELL_PE No. of a cell to change

CHG-INTWO-OPT R_SYS_CDD
interFreqRedir BOOL Whether to perform redirection
ection during inter-frequency handover.
- 0: No redirection during handover
(Normal).
- 1: Performs redirection
unconditionally (Force Used).
RTRV-EUTRA- cellNum 0~MAC_CELL_PE No. of a cell to change
A2CNF R_SYS_CDD
CHG-EUTRA-A2CNF purpose enumA2Purpose_ Purpose of using Event A2. Used
LteHO for measurement gap activation
and redirection at this moment.
- ci_A2PurposeLteHo: Activates
gap for LTE HO.
- ci_A2PurposeLteBlind: Trigger
for LTE Blind Redirection.
- ci_A2PurposeIRatHo: Actives
gap for Inter-RAT HO.

Feature Description
(Continued)
Command Parameters Range Description
RTRV-EUTRA- purpose enumA2Purpose - ci_A2PurposeIRatBlind: Trigger for

A2CNF _ Inter-RAT Blind Redirection.
CHG-EUTRA-A2CNF LteHO - ci_A2PurposeSpare_1: Reserved.
- ci_A2PurposeSpare_2: Reserved.
* At this moment, if the blue colored
ci_A2PurposerLteBlind is configured
among the above purposes, the
intra-LTE Redirection is operating
based on blind measure.
(The measurement based redirection
function will be provided in the next
PKG (i.e. SLR300).)
activeState Inactive/Active Whether to use Event A2.
- Inactive: Event A2 is not used.
- Active: Event A2 is used.
a2Threshold 0-97 RSRP threshold used for the EUTRA
RSRP measurement report triggering
condition of Event A2.
a2Threshold 0-34 RSRQ threshold used for the EUTRA
RSRQ measurement report triggering
condition of Event A2.
hysteresis 0-30 Hysteresis value used in the entry or
leave condition for Event A2
triggerQuanti enumTimeToTrig timeToTrigger value for Event A2 The
ty ger_type timeToTrigger is the time that a MS
must satisfy to trigger a measurement
report.
reportQuantit eutraReportQua Quantity information included in a
y ntity_type measurement report for Event A2. Set
to a value the same as trigger quantity
or set to have both RSRP and RSRQ
values.
maxReportC 1-8 Max. number of cells included in the
ell measurement report for Event A2.
reportInterval enumReportInter The interval of measurement reports
val_type for the Event A2.
reportAmoun enumReportAmo The number of measurement reports
t unt_type for the Event A2.

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1201, Idle Mobility to UTRAN

Overview
Introduction
To support UE’s idle mobility to UTRAN, eNB broadcasts relevant cell reselection
information in SIB6 message so that the UE perform cell reselection towards UTRAN
when needed.
Benefits
Operator can provide idle mobility to its subscribers to UTRAN.
Users in idle state can move to UTRAN.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 UTRAN supported Device, EPC and UTRAN shall support this feature
Limitation:
 None
Reference

Feature Description
Feature Scope
eNB uses SIB6 to send the following parameters as information required for an idle-state
terminal to move to UTRAN.
 UTRAN cell reselection parameters
 UTRA (FDD or TDD) carrier frequency list
 Cell reselection priority per UTRA (FDD or TDD) carrier frequency
 Cell reselection thresholds per UTRA (FDD or TDD) carrier frequency
 Cell reselection timer for UTRAN cell reselection
 Cell reselection timer for speed dependant UTRAN cell reselection

Feature Description
Feature Description
To support from E-UTRAN to UTRAN cell reselection, eNB broadcasts the SIB6 (System
Information Block type 6). The UE shall monitor the E-UTRAN BCCH during idle mode
to retrieve the SIB6 for the preparation of cell reselection to UTRAN. Then UE makes
measurements on neighbouring UTRAN cells based on the criteria and performs cell
reselection to UTRAN when needed.
The parameters for cell reselection to UTRAN broadcasted in SIB6 are as follows:
 UTRAN (FDD or TDD) carrier frequency list
 UTRAN (FDD or TDD) neighbouring cell information
 Threshold values for cell reselection criteria
 Cell reselection timer
 Parameters for speed dependant cell reselection

Feature Description
System operation
RTRV-UTRA-FA Retrieves priority of UTRA FA. If the CELL_NUM and FA_INDEX parameters
are entered, the information only for the UTRAN FA object registered to the
corresponding E-UTRAN served cell is retrieved. If not, the information for all
UTRAN FA objects is retrieved.
CHG-UTRA-FA Changes the UTRA FA priority information. When the Cell Num and fa Index
parameter values are set as input values, the UTRAN FA information registered
to the specified cell in the eNB can be changed.
RTRV-UTRA- Retrieves the UTRAN FA reselection information. If the CELL_NUM and
RESEL PURPOSE parameters are entered, the information only for the UTRAN FA
reselection registered to the corresponding E-UTRAN served cell is retrieved.
If not, the information for all UTRAN FA reselections is retrieved.
CHG-UTRA- Changes the UTRAN FA Reselection information. When the CELL_NUM
RESEL parameter value is set as an input value, the UTRAN Reselection information
registered to the specified E-UTRAN served cell can be changed.
RTRV-UTRA-FA cellNum 0 The cell number to be changed.

CHG-UTRA-FA faIndex 0 The cell number to be changed.
status ConfStatus_DEFA Whether the EUTRA FA is valid.
ULT_UTRA_FA_S - N_EQUIP: Invalid.
TATUS - EQUIP: Valid.
duplexType 0 The duplex mode information on a cell.
Enter either FDD or TDD.
- ci_FDD: Frequency division duplex.
uarfcnUl uarfcnUl_DEFAUL Uplink UTRA Absolute Radio Frequency
T_UTRA_FA_UA Channel Number.
RFCN_UL
uarfcnDl uarfcnDl_DEFAUL Downlink UTRA Absolute Radio Frequency
T_UTRA_FA_UA Channel Number.
RFCN_DL
priority 4 Priority information on the UTRA FA.

Feature Description
(Continued)
RTRV-UTRA-FA threshXhigh 0 The threshold used in the UE to reselect a

CHG-UTRA-FA frequency whose priority is higher than the
current camped frequency.
frequency from high-priority frequency.
qRxLevMin qRxLevMin_DEF The minimum RX level required in a cell in
AULT_UTRA_FA_ dBm units.
Q_RX_LEV_MIN
pMaxUtra 0 The maximum RF output power in the UE.
qQualMin qQualMin_DEFA The minimum quality level required in
ULT_UTRA_FA_ UTRA FDD cells.
Q_QUAL_MIN
offsetFreq 0 The offset applied to UTRA carrier
frequency.
QRel9 frequency whose priority is higher than the
current camped frequency in Rel-9.
threshXlowQ 0 The threshold used to reselect low-priority
Rel9 frequency from high-priority frequency in
Rel-9.
anrUeSearch 100.0 The Searching Rate of UE which performs
Rate the ANR measurement for the
corresponding carrier index.
purpose 0 The usage of UTRAN carrier Information
- CS_ONLY (1): use for CS HO (CSFB,
SRVCC)
RTRV-UTRA- CELL_NUM - The cell number to be changed or
RESEL retrieved.
CHG-UTRA- T_RESELEC 1 UTRAN FA Reselection timer value.
RESEL TION The duration is in seconds.
SF_USAGE CI_no_use Whether to use the scaling factors related
to UTRAN FA reselection.
- CI_no_use: Scaling factor is not used.
- CI_use: Scaling factor is used.

Feature Description
(Continued)
RTRV-UTRA- T_RESELEC ci_1Dot0 The medium timer value of the scaling

RESEL TION_SF_M factors related to UTRAN FA reselection.
CHG-UTRA- EDIUM - ci_oDot25: 0.25 is used for the medium
RESEL timer.
- ci_oDot5: 0.5 is used for the medium
timer.
- ci_oDot75: 0.75 is used for the medium
timer.
- ci_1Dot0: 1.0 is used for the medium
timer.
T_RESELEC ci_1Dot0 The high timer value of the scaling factors
TION_SF_HI related to UTRAN FA reselection.
GH - ci_oDot25: 0.25 is used for the high timer.
- ci_oDot5: 0.5 is used for the high timer.
- ci_oDot75: 0.75 is used for the high timer.
- ci_1Dot0: 1.0 is used for the high timer.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1202, PS Handover to UTRAN

Overview
Introduction
PS handover to UTRAN provides the data mobility to UTRAN to an UE leaving
E-UTRAN.
Benefits
Operator can provide connected mobility to its subscribers from E-UTRAN to UTRAN
Users in connected state can move from E-UTRAN to UTRAN, remaining in the connected
state.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 UTRAN supported Device, EPC and UTRAN shall support PS handover from
E-UTRAN to UTRAN.
Limitation:
 None
Reference

Feature Description
Feature Scope
R1 eNB can control the UTRAN measurement of the terminal.
 Incorporate UE supported bands for UTRAN
number 22)
R2 eNB can determine on PS handover to UTRAN depending on the UTRAN
measurement of the terminal.
R3 eNB can handle the measurement configuration of ther terminal that supports
UTRAN PS handover.
 Selects one from adjacent UTRA carriers based on UTRA supported band (FDD or
TDD) for which to request measurement
 Reporting configuration that reflects measurement event settings for UTRAN PS
handover
R4 eNB can choose the target cell for UTRAN PS handover.
 Selects the best cell of UTRAN cells included in Measurement Report
R5 eNB can configure Source to Target Transparent Container to be sent to target
UTRAN.
 Source RNC to Target RNC Transparent Container [3GPP TS25.413]
R6 eNB can control target UTRAN and HO preparation to PS handover to UTRAN
procedures.
R7 eNB can handle data forwarding to target UTRAN.
R8 eNB can control target UTRAN and handover cancel procedures.
R9 eNB can collect statistic data on outgoing UTRAN PS handover procedures.
 Outgoing UTRAN PS handover attempt/success/failure (collection unit: source cell,
target cell)

Feature Description
Feature Description
When a handover event of data call (data only) to UTRAN is occurred by UE measurement
results and PS handover towards UTRAN is possible, the source eNB initiates the inter-
RAT PS handover procedures by sending a handover request to the serving MME.
According to the handover request from eNB, MME performs inter-RAT packet handover
preparation procedures with UTRAN. In case the handover succeeded, the ‘handover
command’ provided by UTRAN will be sent to the UE by the source eNB. After this
message is received by the UE, UE moves on the UTRAN target cell.
PS handover to UTRAN can be triggered by Event B2 (Inter RAT neighbour becomes

better than threshold) as coverage based trigger. In case of coverage based handover, UE
measurement based method is only used, i.e. if there is no UE measurement for UTRAN
target carrier/cell, PS handover isn’t triggered.
Following figure shows the PS handover from E-UTRAN to UTRAN procedure

Feature Description
1) The MS transmits a measurement report that includes UTRAN measurement.

2) The source eNB determines the PS handover to the UTRAN.
3) The source eNB requests PS handover to the UTRAN by transmitting Handover
Required to the source MME.
4)~10) The handover preparation procedure is processed between the source E-UTRAN
and the target UTRAN. Through this procedure, resources are allocated to help the
MS maintain data service in the target UTRAN after PS handover. If data
forwarding is possible, a tunnel for data forwarding is set up.
11) The source eNB receives Handover Command from the source MME.
12) The source eNB transmits the Mobility from EUTRA command to the MS as well as
the HO command received from the target UTRAN.
13) The MS is switched to the UTRAN target cell specified by the eNB and transmits HO
to UTRAN Complete to the UTRAN.
14) The Target RNC notifies handover is completed by transmitting Relocation Complete
to the target SGSN.
15)~19) The Target SGSN processes the handover completion procedure with the source
MME.
20) The MS performs the UTRAN location registration procedure. Thereafter, the MS
continues data service in the UTRAN.
21)~24) The source MME releases the resources used in the E-UTRAN after completing
PS handover with the UTRAN. If a tunnel for data forwarding was set up, the
source MME and target SGSN release the data forwarding tunnel.

Feature Description
System operation
UTRAN neighbour related Commands
Command Description
RTRV-NBR- Retrieves the UTRAN neighboring cell information near the eNB. Enter the
UTRAN CELL_NUM and RELATION_IDX parameter values to retrieve only the specified
UTRAN neighboring cell information. If no CELL_NUM or RELATION_IDX
parameter values are entered, all UTRAN cell information is retrieved.
CHG-NBR- Changes the UTRAN neighboring cell information near the eNB. Enter the
UTRAN CELL_NUM and RELATION_IDX parameter values to change the UTRAN
neighbor cell information.
CRTE-NBR- This command is used to create the UTRAN neighbor cell information near the
UTRAN eNB. It uses the CELL_NUM and RELATION_IDX parameter values to create the
UTRAN neighboring cell information. Any parameters not entered are set to the
default values.
DLT-NBR- Deletes the UTRAN neighboring cell information near the eNB. Enter the CELL_
UTRAN NUM and RELATION_IDX parameter values to delete the UTRAN neighbor cell
information.
UTRAN neighbour related Parameters

Parameter Range Description
cellNum 0~MAC_CELL_ No. of a cell to change

PER_SYS_CDD
relationIdx 0~255 The DB index of the UTRAN neighbor cell.
status EQUIP/N_EQUIP Indicates whether the information on the UTRAN neighbor
cell located near the eNB is valid.
rncId 0x00~0xFF RNC ID of the UTRAN neighbor cell located near the eNB.
cId 0x00~0xFF ID of the UTRAN neighbor cell located near the eNB.
lac 0x00~0XFF Location Area Code of a UTRAN neighbor cell that is located
around a base station
rac 0X00~0xFF The routing area code of the UTRAN neighbor cell located
near the eNB.
reserved2 0x00~0xFF reserved field
mcc0[4] ‘DIGIT_MCC’ PLMN information (MCC) of the UTRAN neighbor cell
located near the eNB. Enter a 3-digit number whose each
digit is between 0 and 9.
mnc0[4] ‘DIGIT_MNC’ PLMN information (MNC) of the UTRAN neighbor cell
located near the eNB. Enter a 3-digit or 2-digit number
whose each digit is between 0 and 9.

Feature Description
(Continued)

duplexType ci_FDD, ci_TDD Duplex type information of the UTRAN neighbor cell located
near the eNB.
- ci_FDD: Frequency Division Duplex
- ci_TDD: Time Division Duplex
pScmCode 0~511 The primary scramble code of the UTRAN neighbor cell
located near the eNB (for FDD)
cellParaId 0~127 Cell parameter ID information of the UTRAN neighbor cell
located near the eNB. (for TDD)
arfcnUl 0~16383 Uplink ARFCN (Absolute Radio Frequency Channel
Number) of the UTRAN neighbor cell located near the
eNB.(for FDD)

Feature Description
(Continued)
arfcnDl 0~16383 Downlink ARFCN (Absolute Radio Frequency Channel

Number) of the UTRAN neighbor cell located near the eNB.
isRemoveAllo True/False Whether to be able to delete a neighbor cell in a base station
wed using the Automatic Neighbor Relation (ANR) function.
- True: Can delete.
- False: Cannot delete.
isHOAllowed True/False Whether to perform handover to a specific UTRAN neighbor
cell.
rimStatus enumRimStatusTy Indicates the RIM connection status.
pe
voipIncapable True/False Indicates whether the relevant UTRAN neighbor cell
supports the VoIP.
- True: VoIP is supported.
rimSupport True/False Indicates whether the relevant GERAN neighbor cell
supports the RIM.
- False: RIM is not supported.
- True: RIM is supported.
ownerType InitialNRT/ANR by Field that indicates a specific neighbor is allocated through
Server/ANR by which procedure.
UE/Created by
User Command/
Created by User
UI
UTRAN carrier related Commands

Command Description
RTRV-UTRA- Retrieves the UTRA FA priority information.

FA It can retrieve only the UTRAN FA object registered with a specific E-UTRAN
served cell.
If no CELL_NUM or FA_INDEX parameter value is entered, all UTRAN FA
objects are retrieved.
CHG-UTRA- Changes the UTRA FA priority information.
FA It uses the Cell Num and fa Index parameter values to change the UTRAN FA
information registered with a specific cell within the eNB.

Feature Description
UTRAN carrier related Commands and Parameters

Parameter Default values Description
CELL_NUM 0 No. of a cell to change

FA_INDEX 0 UTRA frequency index. Can set up max. 6 FAs for each
cell.
STATUS EQUIP Validity of UTRA FA.
- N_EQUIP: Not valid.
- EQUIP: Valid.
DUPLEX_TYPE ci_FDD Duplex mode information of a cell. The duplex modes of a
cell are FDD and TDD.
UARFCN_UL Value per The Uplink UTRA Absolute Radio Frequency Channel
service provider Number
UARFCN_DL Value per The Downlink UTRA Absolute Radio Frequency Channel
service provider Number
PRIORITY 4 Priority information for the UTRA FA.
THRESH_XHIGH 0 The threshold used by the UE when reselecting the
frequency with priority higher than the currently camped
frequency
THRESH_XLOW 0 The threshold used to reselect the low-priority frequency
from the high-priority frequency
Q_RX_LEV_MIN -54 Min. RX level required in a cell. The unit is dBm.
P_MAX_UTRA 0 Maximum RF output power of the UE.
Q_QUAL_MIN -20 The minimum quality level required by the UTRA FDD cell.
OFFSET_FREQ 0 The offset value applied to the UTRA carrier frequency.
THRESH_XHIGH_ 0 The threshold used by the UE when reselecting the
QREL9 frequency with priority higher than the currently camped
frequency, in the Rel-9.
THRESH_XLOW_ 0 In the Rel-9, the threshold used to reselect the low-priority
QREL9 frequency from the high-priority frequency
(Checkpoints for Enable)

Check if the connection to the UTRAN neighbor is normal.
Check if the connection to the MME is normal.
Check if the MS supports the UTRAN.

Feature Description
Related Counters
Family Data
Category Type Name Family/Type Description
Name type
HO_UTR HO_INTE - Collects the statistics data for outgoing -
AN R_RAT_U handover between the LTE system and
TRAN_OU UTRAN system for each cell. The collection
T time for HO attempt, HO preparation and
HO success statistics is the same as that for
S1 handover out statistics.
RatOutAttUTRA LTE to inter-RAT UTRAN handover attempt count
N count.
RatOutPrepSucc LTE to inter-RAT UTRAN handover count
UTRAN preparation success count.
RatOutSuccUTR LTE to inter-RAT UTRAN handover count
AN execution success count.
RatOutPrepFail Preparation fails due to eNB or block fault count
UTRAN_CP_CC during the UTRAN handover preparation.
_FAIL
RatOutPrepFail Preparation fails due to S1AP specification count
UTRAN_S1AP_ cause during the UTRAN handover
CU_FAIL preparation.
RatOutPrepFail Preparation fails due to S1 SCTP link count
UTRAN_S1AP_ failure during the UTRAN handover
LINK_FAIL preparation.
RatOutPrepFail Preparation fails due to S1AP relocprep count
UTRAN_S1AP_ timeout (not received) during the UTRAN
RP_TO handover preparation.
RatOutPrepFail Preparation fails due to receiving S1AP count
UTRAN_S1AP_ signaling during the UTRAN handover
SIG_FAIL preparation.
RatOutFailUTRA A call is released due to Call Control count
N_CP_CC_TO Timeout of a protocol block during UTRAN
handover execution.
RatOutFailUTRA A call is released due to eNB or block fault count
N_CP_CC_FAIL during the UTRAN handover execution.
RatOutFailUTRA A call is released due to the failure in the count
N_UP_GTP_FAI GTP block during the UTRAN handover
L execution.
RatOutFailUTRA A call is released due to the failure in the count
N_UP_MAC_FAI MAC block during the UTRAN handover
L execution.

Feature Description
(Continued)
Family Data
Name type
HO_UTRA HO_INTE RatOutFailUTRA A call is released due to the failure in the count
N R_RAT_ N_UP_PDCP_F PDCP block during the UTRAN handover
UTRAN_ AIL execution.
OUT RatOutFailUTRA A call is released due to the failure in the count
N_UP_RLC_FAI RLC block during the UTRAN handover
L execution.
RatOutFailUTRA A call is released due to receiving RRC count
N_RRC_SIG_FA signaling during the UTRAN handover
IL execution.
RatOutFailUTRA A call is released due to the S1AP count
N_S1AP_CU_F specification cause during the UTRAN
AIL handover execution.
RatOutFailUTRA A call is released due to the S1 SCTP link count
N_S1AP_LINK_ failure during the UTRAN handover
FAIL execution.
RatOutFailUTRA A call is released due to S1AP relocoverall count
N_S1AP_RP_T timeout (not received) during the UTRAN
O handover execution.
RatOutFailUTRA A call is released due to receiving S1AP count
N_S1AP_SIG_F signaling during the UTRAN handover
AIL execution.
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1203, PS Handover from UTRAN

Overview
Introduction
PS handover from UTRAN provides the data mobility from UTRAN to an UE entering E-
UTRAN.
Benefits
Operator can provide connected mobility to its subscribers from UTRAN to E-UTRAN.
Users in connected state can move from UTRAN to E-UTRAN, remaining in the connected
state.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 UTRAN supported Device, EPC and UTRAN shall support PS handover from
UTRAN to E-UTRAN.
Limitation:
 None
Reference

Feature Description
Feature Scope
R1 eNB can determine whether to accept the handover request from UTRAN.
R2 eNB can configure Target to Source Transparent Container to be sent to source
UTRAN.
R3 eNB can handle source UTRAN and HO preparation based on the procedures of PS
handover from UTRAN.
R4 eNB can handle data forwarding from source UTRAN.
R5 eNB can handle source UTRAN and handover cancel procedures.
R6 eNB can collect statistic data on the incoming UTRAN PS handover procedures.
 Incoming UTRAN PS handover attempt/success/failure (collection unit: target cell)

Feature Description
Feature Description
PS handover to E-UTRAN is initiated by the source UTRAN according to the inter-RAT
handover control mechanism of the source UTRAN.
When PS handover from UTRAN is requested, the target eNB performs admission control
based on the received E-RAB QoS information. In case the handover request is allowed,
the target eNB allocates the required resources according to the received E-RAB QoS
information and reserves a C-RNTI and optionally a RACH preamble.
Following figure shows the PS handover from UTRAN to E-UTRAN procedure.
1) The source RNC determines the PS handover to the E-UTRAN.

2) The source RNC requests the PS handover by transmitting Relocation Required to the
source SGSN.
3)~9) The handover preparation procedure is processed between the source UTRAN and
the target E-UTRAN. Through this procedure, resources are allocated to help the
MS maintain data service in the target E-UTRAN after PS handover. If data
forwarding is possible, a tunnel for data forwarding is set up.

Feature Description
10) The source RNC receives Relocation Command from the source SGSN.
11) The source RNC transmits the HO from UTRAN Command to the MS as well as the
HO command received from the target E-UTRAN.
12) The MS is switched to the E-UTRAN target cell specified by the source RNC and
transmits the RRC Connection Reconfiguration Complete to the E-UTRAN.
13) The target eNB notifies that handover is completed by transmitting Handover Notify to
the target MME.
14)~18) The target MME processes the handover completion procedure with the source
SGSN.
19) The MS performs the Tracking Area Update procedure. Thereafter, the MS continues
data service in the E-UTRAN.
20)~23) The source SGSN releases the resources used in the UTRAN after completing PS
handover with the E-UTRAN. If a tunnel for data forwarding was set up, the
source SGSN and target MME release the data forwarding tunnel.

Feature Description
System operation
UTRAN neighbour related Commands
Command Description
RTRV-NBR- Retrieves the UTRAN neighboring cell information near the eNB. Enter the
UTRAN CELL_NUM and RELATION_IDX parameter values to retrieve only the
specified UTRAN neighboring cell information. If no CELL_NUM or
RELATION_IDX parameter values are entered, all UTRAN cell information is
retrieved.
CHG-NBR-UTRAN Changes the UTRAN neighboring cell information near the eNB.
Enter the CELL_NUM and RELATION_IDX parameter values to change the
UTRAN neighbor cell information.
CRTE-NBR- This command is used to create the UTRAN neighbor cell information near
UTRAN the eNB. It uses the CELL_NUM and RELATION_IDX parameter values to
create the UTRAN neighboring cell information. Any parameters not entered
are set to the default values.
DLT-NBR-UTRAN Deletes the UTRAN neighboring cell information near the eNB. Enter the
CELL_NUM and RELATION_IDX parameter values to delete the UTRAN
UTRAN neighbour related Parameters

cellNum 0~MAC_CELL_P No. of a cell to change

ER_SYS_CDD
relationIdx 0~255 The DB index of the UTRAN neighbor cell.
status EQUIP/N_EQUIP Indicates whether the information on the UTRAN
rncId 0x00~0xFF RNC ID of the UTRAN neighbor cell located near the
eNB.
cId 0x00~0xFF ID of the UTRAN neighbor cell located near the eNB.
lac 0x00~0XFF Location Area Code of a UTRAN neighbor cell that is
located around a base station
rac 0X00~0xFF The routing area code of the UTRAN neighbor cell
reserved2 0x00~0xFF reserved field
located near the eNB. Enter a 3-digit number whose
each digit is between 0 and 9.

Feature Description
(Continued)

duplexType ci_FDD, ci_TDD Duplex type information of the UTRAN neighbor cell
pScmCode 0~511 The primary scramble code of the UTRAN neighbor cell

Feature Description
(Continued)
cellParaId 0~127 Cell parameter ID information of the UTRAN neighbor

cell located near the eNB. (for TDD)
arfcnUl 0~16383 Uplink ARFCN (Absolute Radio Frequency Channel
eNB. (for FDD)
arfcnDl 0~16383 Downlink ARFCN (Absolute Radio Frequency Channel
eNB.
isRemoveAllowed True/False Whether to be able to delete a neighbor cell in a base
station using the Automatic Neighbor Relation (ANR)
function.
- True: Can delete.
isHOAllowed True/False Whether to perform handover to a specific UTRAN
neighbor cell.
rimStatus enumRimStatusT Indicates the RIM connection status.
ype
voipIncapable True/False Indicates whether the relevant UTRAN neighbor cell
supports the VoIP.
- True: VoIP is supported.
rimSupport True/False Indicates whether the relevant GERAN neighbor cell
supports the RIM.
ownerType InitialNRT/ Field that indicates a specific neighbor is allocated
ANR by Server/ through which procedure.
ANR by UE/
Created by User
Command/
Created by User
UI

Feature Description
UTRAN carrier related Commands

Command Description
RTRV-UTRA-FA Retrieves the UTRA FA priority information.

It can retrieve only the UTRAN FA object registered with a specific E-UTRAN
served cell.
CHG-UTRA-FA Changes the UTRA FA priority information.
It uses the Cell Num and fa Index parameter values to change the UTRAN
FA information registered with a specific cell within the eNB.
UTRAN carrier related Parameters

CELL_NUM 0 No. of a cell to change

FA_INDEX 0 UTRA frequency index. Can set up max. 6 FAs for
each cell.
STATUS EQUIP Validity of UTRA FA.
- EQUIP: Valid.
DUPLEX_TYPE ci_FDD Duplex mode information of a cell. The duplex
modes of a cell are FDD and TDD.
UARFCN_UL Value per service The Uplink UTRA Absolute Radio Frequency
provider Channel Number
UARFCN_DL Value per service The Downlink UTRA Absolute Radio Frequency
provider Channel Number
THRESH_XHIGH 0 The threshold used by the UE when reselecting the
frequency with priority higher than the currently
camped frequency
THRESH_XLOW 0 The threshold used to reselect the low-priority
frequency from the high-priority frequency
Q_RX_LEV_MIN -54 Min. RX level required in a cell. The unit is dBm.
Q_QUAL_MIN -20 The minimum quality level required by the UTRA
FDD cell.
OFFSET_FREQ 0 The offset value applied to the UTRA carrier
frequency.

Feature Description
(Continued)
THRESH_XHIGH_ 0 The threshold used by the UE when reselecting the

QREL9 frequency with priority higher than the currently
camped frequency, in the Rel-9.
THRESH_XLOW_ 0 In the Rel-9, the threshold used to reselect the low-
QREL9 priority frequency from the high-priority frequency
Checkpoints for Enable

 Check if the connection to the UTRAN neighbor is normal.
 Check if the connection to the MME is normal.
 Check if the MS supports the UTRAN.
Related Counters
Family Data
Name type
HO_UTRA HO_INTE - Collects the statistics data for incoming -
N R_RAT_U handover between the LTE system and
TRAN_IN UTRAN system for each cell.
RatInAttUT Inter-RAT UTRAN to LTE handover attempt count
RAN count.
RatInPrepS Inter-RAT UTRAN to LTE handover count
uccUTRAN preparation success count.
RatInSuccU Inter-RAT UTRAN to LTE handover execution count
TRAN success count.
RatInPrepF Preparation fails due to Call Control Timeout count
ailUTRAN_ (not received) of a protocol block during
CP_CC_TO UTRAN handover execution.
RatInPrepF Preparation fails due to eNB or block fault count
ailUTRAN_ during the UTRAN handover preparation.
CP_CC_FA
IL
RatInPrepF Preparation fails due to internal failure in the count
ailUTRAN_ GTP block during the UTRAN handover
UP_GTP_F preparation.
AIL
RatInPrepF Preparation fails due to internal failure in the count
ailUTRAN_ MAC block during the UTRAN handover
UP_MAC_F preparation.
AIL

Feature Description
(Continued)
Family Data
Name type
HO_UTRA HO_IN RatInPrepFail Preparation fails due to internal failure in the count
N TER_R UTRAN_UP_ PDCP block during the UTRAN handover
AT_UT PDCP_FAIL preparation.
RAN_I RatInPrepFail Preparation fails due to internal failure in the count
N UTRAN_UP_ RLC block during the UTRAN handover
RLC_FAIL preparation.
RatInPrepFail Preparation fails due to insufficient backhaul- count
UTRAN_CP_ based eNB resources during the UTRAN
BH_CAC_FAI handover preparation.
L
RatInPrepFail Preparation fails due to insufficient capacity- count
CAPA_CAC_F handover preparation.
AIL
RatInPrepFail Preparation fails due to insufficient QoS- count
QOS_CAC_F handover preparation.
AIL
RatInPrepFail Preparation fails due to S1AP specification count
UTRAN_S1A cause during the UTRAN handover
P_CU_FAIL preparation.
RatInPrepFail Preparation fails due to S1 SCTP link failure count
UTRAN_S1A during the UTRAN handover preparation.
P_LINK_FAIL
RatInPrepFail Preparation fails due to S1AP relocprep count
UTRAN_S1A timeout (not received) during the UTRAN
P_RP_TO handover preparation.
RatInPrepFail Preparation fails due to receiving S1AP count
UTRAN_S1A signaling during the UTRAN handover
P_SIG_FAIL preparation.
RatOutFailUT A call is released due to Call Control Timeout count
RAN_CP_CC of a protocol block during UTRAN handover
_TO execution.
RatInFailUTR A call is released due to eNB or block fault count
AN_CP_CC_ during the UTRAN handover execution.
FAIL

Feature Description
(Continued)
Family Data
Name type
HO_UTRA HO_INTE RatInFailUT A call is released due to the failure in the GTP count
N R_RAT_U RAN_UP_ block during the UTRAN handover execution.
TRAN_IN GTP_FAIL
RatInFailUT A call is released due to the failure in the MAC count
RAN_UP_ block during the UTRAN handover execution.
MAC_FAIL
RatInFailUT A call is released due to the failure in the PDCP count
RAN_UP_P block during the UTRAN handover execution.
DCP_FAIL
RatInFailUT A call is released due to the failure in the RLC count
RAN_UP_R block during the UTRAN handover execution.
LC_FAIL
RatInFailUT A call is released due to HO command timeout count
RAN_RRC_ (not received) during the UTRAN handover
HC_FAIL execution.
RatInFailUT A call is released due to receiving RRC count
RAN_RRC_ signaling during the UTRAN handover
SIG_FAIL execution.
RatInFailUT A call is released due to the S1AP specification count
RAN_S1AP cause during the UTRAN handover execution.
_CU_FAIL
RatInFailUT A call is released due to the S1 SCTP link count
RAN_S1AP failure during the UTRAN handover execution.
_LINK_FAI
L
RatInFailUT A call is released due to receiving S1AP Count
RAN_S1AP signaling during the UTRAN handover
_SIG_FAIL execution.
RatInFailUT A call is released due to S1AP signaling timeout count
RAN_S1AP (not received) during the UTRAN handover
_SIG_TO execution.
Related KPI/PI
N/A
Related Alarms
N/A

Feature Description
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1204, Redirection to UTRAN without SI

Overview
Introduction
This is outbound mobility control functionality to UTRAN. When mobility event to
UTRAN is occurred, eNB redirects the UE towards UTRAN.
Benefits
Users in connected state can move from E-UTRAN to UTRAN.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 UTRAN UTRAN supported Device, EPC and UTRAN shall support this feature.
Limitation:
 None
Reference

Feature Description
Feature Scope
R1 eNB can determine on Redirection to UTRAN depending on the UE measurement (E-
UTRAN or UTRAN) results.
 UseUTRAN measurement if the terminal supports UTRAN measurement, but
Blind option is not activated
 Use E-UTRANmeasurement if the terminal does not support UTRAN
measurement of if Blind option is activated.
R2 eNB can determine on Redirection to UTRAN based on UE Radio Access Capability.
If the terminal does not support the enhanced redirection to UTRAN, carry out
Redirection without SI.
R3 eNB can select a UTRA carrier for redirection among the neighboring UTRA carriers
based on the UTRA supported band (FDD or TDD) supported by the terminal.
 Using UTRAN measurement: select Measurement Report’s UTRA carrier
 Using E-UTRAN measurement: select round robin, if there are multiple selectable
UTRA carriers
R4 eNB can collect statistic data on Redirection without SI to UTRAN.
 Redirection to UTRAN attempt/success/failure (collection unit: source cell)

Feature Description
Feature Description
When a mobility event to UTRAN is occurred by UE measurement results and redirection
towards UTRAN is only possible, eNB initiates the redirection (release with redirect)
procedures. This is indicated by the redirect carrier information in the RRC
CONNECTION RELEASE message. If without SI (system information) case, carrier
frequency of target UTRAN is only included in the redirect carrier information.
In case of redirection, triggering due to UE’s mobility is supported even if no prior UE
measurements have been performed on the target UTRAN cell and/or frequency.
To do this, Samsung eNB uses UE’s serving cell measurement results (i.e. Event A2).
Following figure shows the redirection to UTRAN procedure.
1) The eNB determines redirection to the UTRAN.

2) The eNB transmits RRC Connection Release to the MS including the UTRA (FDD or
6) The MS is switched to the UTRA carrier (FDD or TDD) that is specified by the eNB
in the RRC Connection Release and connects to the UTRAN. The MS performs the
UTRAN location registration procedure. Thereafter, the MS provides continued
service while standing by.

Feature Description
System operation
Command Description
RTRV-TIMER-INF Retrieves the timer values used by the ECCB within the eNB. It can
retrieve the timer value used for message transmission/reception with the
UE when a call is setup; the timer value used for message
transmission/reception with the MME; the timer value used for message
transmission/reception with the neighbor eNB; or other timer values used
by the ECCBs.
CHG-TIMER-INF This command changes the timer values used by the ECCB within the
eNB. It can change the timer value used for message
transmission/reception with the UE when a call is setup; the timer value
used for message transmission/reception with the MME; the timer value
used for message transmission/reception with the neighbor eNB; or the
timer value used by other ECCBs.
RTRV-NBR-UTRAN Retrieves the UTRAN neighboring cell information near the eNB. It uses
the CELL_NUM and RELATION_IDX parameter values to retrieve only the
specified UTRAN neighboring cell information. If no CELL_NUM or
RELATION_IDX parameter values are entered, all UTRAN neighboring cell
CHG-NBR-UTRAN Changes the UTRAN neighboring cell information near the eNB. It uses the
CELL_NUM and RELATION_IDX parameter values to change the UTRAN
CRTE-NBR-UTRAN Creates the UTRAN neighboring cell information near the eNB. It uses the
CELL_NUM and RELATION_IDX parameter values to create the UTRAN
neighboring cell information. Any parameters not entered are set to the
default values.
DLT-NBR-UTRAN Deletes the UTRAN neighboring cell information near the eNB. It uses the
cellNum No. of a cell to change

relationIdx The DB index of the UTRAN neighbor cell.

Feature Description
(Continued)
status Indicates whether the information on the UTRAN neighbor cell located near
the eNB is valid.
- N_EQUIP: UTRAN neighbor cell information is not valid.
- EQUIP: UTRAN neighbor cell information is valid.
rnc id Indicates the RNC ID of the UTRAN neighbor cell located near the eNB.
c_id CID of a UTRAN neighbor cell around a base station
lac Location Area Code of a UTRAN neighbor cell that is located near the eNB.
rac The routing area code of the UTRAN neighbor cell located near the eNB.
duplex type Duplex type information of the UTRAN neighbor cell located near the eNB.
p scm code The primary scramble code of the UTRAN neighbor cell located near the
eNB (for FDD)
mcc[] Broadcast PLMN list information (MCC) of the UTRAN neighbor cell
located near the eNB. Enter a 3-digit number whose each digit is between
0 and 9.
mnc[] Broadcast PLMN list information (MNC) of the UTRAN neighbor cell
located near the eNB. Enter a 3-digit or 2-digit number whose each digit is
between 0 and 9.
cell para id Cell parameter ID information of a UTRAN neighbor cell around a base
station. (TDD)
arfcn ul Uplink ARFCN (Absolute Radio Frequency Channel Number) of a UTRAN
neighbor cell located around a base station.
arfcn dl Downlink ARFCN (Absolute Radio Frequency Channel Number) of a
UTRAN neighbor cell located around a base station.
isRemoveAllowed Whether to be able to delete a neighbor cell in a base station using the
Automatic Neighbor Relation (ANR) function.
- True: Can delete a neighbor cell.
- False: Cannot delete a neighbor cell.
isHOAllowed Whether to perform handover to a specific UTRAN neighbor cell.
voipIncapable VoIP support of a specific UTRAN neighbor cell.
- True: VoIP support.
- False: No VoIP support.
remote type The field indicating if the neighbor eNB is managed by the same EMS or
different EMS.
rimSupport RIM support of a UTRAN neighbor cell.
- True: RIM support
- False: No RIM support

Feature Description
(Continued)
rimStatus Indicates the RIM connection status.

ownerType Field that indicates a specific neighbor is allocated through which
procedure. Specifically displayed as Initial NRT/ANR by Server/ANR by
UE/Created by User Command/CreatedByUserUI.

Check if the value of RIM Support is False.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1205, Redirection to UTRAN with SI

Overview
Introduction
This is outbound mobility control functionality to UTRAN. When mobility event to
UTRAN is occurred, eNB redirects the UE towards UTRAN.
Benefits
Users in connected state can move from E-UTRAN to UTRAN.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 UTRAN UTRAN supported Device, EPC and UTRAN shall support this feature.
Limitation:
 None
Reference

Feature Description
Feature Scope
R1 eNB can determine on Redirection to UTRAN based on the UE measurement (E-
UTRAN or UTRAN) results.
 Use UTRAN measurement if the terminal supports UTRAN measurement, but
Blind option is not activated.
 Use E-UTRAN measurement if the terminal does not support UTRAN
measurement or if Blind option is activated.
R2 eNB can determine on Redirection procedures based on UE Radio Access Capability.
If the terminal supports the enhanced redirection to UTRAN, carry out Redirection
with SI.
 If e-RedirectionUTRA-r9=supported in UE-EUTRA-Capability
based on UTRA supported band (FDD or TDD) supported by the terminal.
 Using UTRAN measurement: select UTRA carrier of Measurement Report
 Using E-UTRAN measurement: if there are multiple selectable UTRA carriers,
select round robin.
R4 eNB can select a UTRAN cell list to be sent to the terminal to handle Redirection
with SI and include the SI list of UTRAN cells to create a RRC Connection Release.
 Using UTRAN measurement: includes the SI list of UTRAN cell(s) included in
Measurement Report
 Using E-UTRAN measurement: selects the UTRAN cell(s) that have obtained the
SI list among the neighboring cells of PLD sequentially to include SI list
R5 eNB can, based on UTRAN SI RIM application with UTRAN, obtains and stores SI
list per cell from the neighboring UTRANs and use it in handling Redirection with SI.
R6 eNB can select statistic data on Redirection with SI to UTRAN procedures.
 Redirection to UTRAN attempt/success/failure (collection unit: source cell)

Feature Description
Feature Description
When a mobility event to UTRAN is occurred by UE measurement results and redirection
towards UTRAN is only possible, eNB initiates the redirection (release with redirect)
procedures. This is indicated by the redirect carrier information in the RRC
CONNECTION RELEASE message. If without SI (system information) case, carrier
frequency of target UTRAN is only included in the redirect carrier information.
In case of redirection, triggering due to UE’s mobility is supported even if no prior UE
measurements have been performed on the target UTRAN cell and/or frequency. To do this,
Samsung eNB uses UE’s serving cell measurement results (i.e. Event A2).
Following figure shows the redirection to UTRAN procedure.
1) The eNB determines redirection to the UTRAN.

UTRAN location registration procedure. Thereafter, the MS provides continued
service while standing by.

Feature Description
System operation
Related Commands
Command Description
RTRV-NBR-UTRA - Retrieves the UTRAN neighboring cell information near the eNB.
- Enter the CELL_NUM and RELATION_IDX parameter values to retrieve
only the specified UTRAN neighbor cell information.
If no CELL_NUM or RELATION_IDX parameter values are entered, all
UTRAN neighbor cell information is retrieved.
CHG-NBR-UTRA - Changes the UTRAN neighbor cell information near the eNB.
- It uses the CELL_NUM and RELATION_IDX parameter values to change
the UTRAN neighboring cell information.
CRTE-NBR-UTRA - Creates the UTRAN neighbor cell information near the eNB.
- It uses the CELL_NUM and RELATION_IDX parameter values to create
the UTRAN neighboring cell information. Any parameters not entered are
set to the default values.
DLT-NBR-UTRA - Deletes the UTRAN neighbor cell information near the eNB.
- It uses the CELL_NUM and RELATION_IDX parameter values to delete
RTRV-UTRA-FA - Retrieves the UTRA FA priority information.
- It can retrieve only the UTRAN FA object registered with a specific E-
UTRAN served cell.
CHG-UTRA-FA - Changes the UTRA FA priority information.
- It uses the Cell Num and fa Index parameter values to change the UTRAN
RTRV-HO-OPT - Retrieves the information related to handover.
- It can retrieve the E-RAB interaction method configured for the eNB, the
neighbor cell list (NCL) inclusion status, or the uplink data forwarding
status at the target eNB.
CHG-HO-OPT - Changes the information related to handover.
- It can change the E-RAB interaction method configured for the eNB, the
neighbor cell list (NCL) inclusion status, or the uplink data forwarding
status at the target eNB.
RTRV-INTWO-OPT Retrieves interworking option information.
CHG-INTWO-OPT Changes interworking option information.

Feature Description
(Continued)
Command Description
RTRV-TIMER-INF - Retrieves the timer values used by the ECCB within the eNB.
- It can retrieve the timer value used for message transmission/reception
with the UE when a call is setup; the timer value used for message
transmission/reception with the MME;
the timer value used for message transmission/reception with the neighbor
eNB; or other timer values used by the ECCBs.
CHG-TIMER-INF - Changes the timer values used by the ECCB within the eNB.
- It can change the timer value used for message transmission/reception
eNB; or the timer value used by other ECCBs.

RTRV-NBR-UTRA CELL_NUM 0 No. of a cell to

CHG-NBR-UTRA retrieve/change/create/delete
CRTE-NBR-UTRA RELATION_IDX 0 The DB index of the UTRAN neighbor
DLT-NBR-UTRA cell.
STATUS N_EQUIP Information validity of the UTRAN
neighbor cell located near the eNB.
- N_EQUIP: UTRAN neighbor cell
information is not valid.
- EQUIP: UTRAN neighbor cell
RNC_ID 0 Indicates the RNC ID of the UTRAN
C_ID 0 CID of a UTRAN neighbor cell around
a base station
LAC 0 Location Area Code of a UTRAN
neighbor cell that is located around a
base station
RAC 0 The routing area code of the UTRAN

Feature Description
(Continued)
RTRV-NBR-UTRA MCC0 Service Broadcast PLMN list information

CHG-NBR-UTRA provider’s MCC (MCC) of the UTRAN neighbor cell
CRTE-NBR-UTRA located near the eNB.
DLT-NBR-UTRA Enter a 3-digit number whose each
MNC0 Service Broadcast PLMN list information
provider’s MNC (MNC) of the UTRAN neighbor cell
Enter a 3-digit or 2-digit number
MCC1 FFF Broadcast PLMN list information
(MCC) of the UTRAN neighbor cell
Enter a 3-digit number whose each
MNC1 FFF Broadcast PLMN list information
(MNC) of the UTRAN neighbor cell

Feature Description
(Continued)
RTRV-NBR-UTRA MCC4 FFF Broadcast PLMN list information

CHG-NBR-UTRA (MCC) of the UTRAN neighbor cell
DUPLEX_TYPE ci_FDD Duplex type information of the UTRAN
P_SCM_CODE 0 The primary scramble code of the
UTRAN neighbor cell located near the
eNB (for FDD)
CELL_PARA_ID 0 Cell parameter ID information of a
UTRAN neighbor cell around a base
station. (TDD)
ARFCN_UL 0 Uplink ARFCN (Absolute Radio
Frequency Channel Number) of a
UTRAN neighbor cell located around
a base station.
ARFCN_DL 0 Downlink ARFCN (Absolute Radio
UTRAN neighbor cell located around
a base station.

Feature Description
(Continued)
RTRV-NBR-UTRA IS_REMOVE_A True Whether to be able to delete a

CHG-NBR-UTRA LLOWED neighbor cell in a base station using
CRTE-NBR-UTRA the Automatic Neighbor Relation
DLT-NBR-UTRA (ANR) function.
IS_HOALLOWE True Whether to perform handover to a
D specific UTRAN neighbor cell.
RIM_STATUS - Indicates the RIM connection status.
VOIP_INCAPAB True VoIP support of a specific UTRAN
LE neighbor cell.
RIM_SUPPORT False RIM support of a UTRAN neighbor
cell.
- True: RIM support
OWNER_TYPE False Field that indicates a specific neighbor
is allocated through which procedure.
Specifically displayed as Initial NRT/
ANR by Server/ANR by UE/Created
by User Command/CreatedByUserUI.
RTRV-UTRA-FA CELL_NUM 0 No. of a cell to change
CHG-UTRA-FA FA_INDEX 0 UTRA frequency index. Can set up
max. 6 FAs for each cell.
STATUS EQUIP Validity of EUTRA FA.
- EQUIP: Valid.
DUPLEX_TYPE ci_FDD Duplex mode information of a cell.
The duplex modes of a cell are FDD
and TDD.
UARFCN_UL Value per The Uplink UTRA Absolute Radio
service Frequency Channel Number
provider

Feature Description
(Continued)
RTRV-UTRA-FA UARFCN_DL Value per The Downlink UTRA Absolute Radio

CHG-UTRA-FA service Frequency Channel Number
provider
THRESH_XHIGH 0 The threshold used by the UE when
reselecting the frequency with priority
higher than the currently camped
frequency
THRESH_XLOW 0 The threshold used to reselect the
low-priority frequency from the high-
priority frequency
Q_RX_LEV_MIN -54 Min. RX level required in a cell.
The unit is dBm.
Q_QUAL_MIN -20 The minimum quality level required by
the UTRA FDD cell.
OFFSET_FREQ 0 The offset value applied to the UTRA
carrier frequency.
THRESH_XHIGH_ 0 The threshold used by the UE when
QREL9 reselecting the frequency with priority
THRESH_XLOW_ 0 In the Rel-9, the threshold used to
QREL9 reselect the low-priority frequency
RTRV-HO-OPT RIM_ENABLE False Indicates whether to enable the RIM
CHG-HO-OPT procedure.
MME_SELECT_FA 0 Weight to select MME to perform RIM
CTOR_FOR_RIM procedure.

Feature Description
(Continued)
RTRV-INTWO-OPT INTER_RAT_PS_ True Whether to perform forced redirection

CHG-NTWO-OPT REDIRECTION during inter-frequency handover.
(Normal).
INTER_RAT_PS_ 0 Whether to perform forced redirection
REDIRECTION during inter RAT handover.
(Normal).
RTRV-TIMER-INF RIM_RIR 5000 The time waiting for response after
CHG-TMER-INF sending the MME Direct Information
Transfer (RAN-INFORMATION-
REQUEST) to the MINE.
RIM_RIAE 5000 The time waiting for response after
sending the MME Direct Information
Transfer (RAN-INFORMATION-
APPLICATION-ERROR) to the MINE.

Feature Description
Related Counters
Counter: procedure the redirection with SI to UTRAN
CsfbRedirAttUTRAN CSFB with Redirection to inter-RAT Checking in the LSM: Performance >
UTRAN attempt count Performance Statistics > HO UTRAN
> CSFB Redirection OUT > CSFB_
REDIR_UTRAN_OUT >
CsfbRedirAttUTRAN
CsfbRedirPrepSucc CSFB with Redirection to inter-RAT Checking in the LSM: Performance >
UTRAN UTRAN preparation success Performance Statistics > HO UTRAN
count. > CSFB Redirection OUT > CSFB_
REDIR_UTRAN_OUT >
CsfbRedirPrepSuccUTRAN
CsfbRedirSuccUTR CSFB with Redirection to inter-RAT Checking in the LSM: Performance >
AN UTRAN execution success count. Performance Statistics > HO UTRAN
> CSFB Redirection OUT > CSFB_
REDIR_UTRAN_OUT >
CsfbRedirSuccUTRAN
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
Connection State of RIM is retrieved at RIM_STATUS of RTRV-NBR-UTRA command
result.
Related Call Faults

S1AP_interrat_redir A call is released due to the inter- Checking in the LSM: Performance >
ection RAT redirection. Performance Statistics > CSL > Call
It occurs when redirection is Fail > CSL > S1AP_interrat_redirection
processed normally due to the
inter-RAT redirection.

Feature Description
LTE-SW1206, SRVCC to UTRAN

Overview
Introduction
The eNB provides continuous voice service using the SRVCC handover procedure by
switching a user to the UTRAN CS domain when the Voice over LTE (VoLTE) service user
moves out of LTE area and into a UTRAN where the PS-based voice service is not
available.
The eNB determines SRVCC handover to UTRAN based on UTRAN measurement report.
When the eNB receives the UTRAN measurement result from the UE, it selects a handover
target cell and processes the handover preparation procedure. When the handover
preparation procedure with the UTRAN is successful, the eNB orders "SRVCC handover to
UTRAN" to the UE. The UE is handed over to the target cell of UTRAN that is specified
by the eNB and receives CS voice service from the UTRAN.
Benefits
 Operator can provide voice continuity (VoLTE) to its subscribers from E-UTRAN to
UTRAN.
 Users during VoIP call (VoLTE) can move from E-UTRAN to UTRAN, remaining the
connected state.
Release History
SLR2.4

Dependency:
 UTRAN supported Device, EPC and UTRAN shall support this feature
Limitation:
 Need IOT with SRVCC capable terminal and the related network entities, i.e. EPC,
UTRAN and IMS.
Reference
Resource Control (RRC) protocol specification

Feature Description
4) 3GPP TS23.216 Single Radio Voice Call Continuity (SRVCC); Stage 2
Feature Scope
R1 The eNB can control the UTRAN measurement of the UE.
− Reflects UE supported bands for UTRAN
− Reflects UE Radio Access Capability for inter-frequency measurement (FGI bit
number 22)
− Reflects the necessity of measurement gap per UE supported band
− Measurement gap activation/deactivation if needed
R2 The eNB can determine SRVCC handover to the UTRAN according to the UTRAN
measurement result of the UE.
R3 The eNB can process the measurement configuration of the UE that supports UTRAN
SRVCC handover.
− Selects a UTRA carriers to which measurement will be ordered based on the
UTRA supported band (FDD or TDD) that is supported by the UE among the
neighbor UTRA carriers.
− Reporting configuration by reflecting measurement event setup for UTRAN
SRVCC handover
− UTRAN neighbor cell list configuration by reflecting whether VoIP is supported
per UTRAN neighbor cell
R4 The eNB can determine the target cell of UTRAN SRVCC handover.
− Selects the best cell of UTRAN cell(s) included in the measurement report
R5 The eNB can configure Source to Target Transparent Container that will be
transmitted to the target UTRAN.
− Source RNC to Target RNC Transparent Container [3GPP TS25.413]
R6 The eNB can process HO preparation with a target UTRAN according to the SRVCC
handover procedure to UTRAN.
R7 The eNB can collect the statistics for the outgoing UTRAN SRVCC handover
procedure.
− Outgoing UTRAN SRVCC handover attempt/success/failure (collection unit:
source cell, target cell)

Feature Description
Feature Description
The SRVCC procedures to UTRAN are as follows: (SRVCC from E-UTRAN to UTRAN
with PS HO)
1) The VoLTE UE transmits a measurement report that contains UTRAN measurement to

the source eNB. The source eNB determines the SRVCC handover to the UTRAN.
2) The source eNB requests SRVCC handover to UTRAN by transmitting Handover
Required message to the source MME.
3) The source MME processes bearer splitting based on QCI per bearer.
4)-8) The handover preparation procedure between the source E-UTRAN and target
UTRAN CS/PS domain is processed. Through this procedure, a resource is allocated
to enable the UE to maintain voice/data service in the target UTRAN after SRVCC
handover.
9) The source eNB receives the handover command from the source MME.
10) The source eNB transmits the Mobility from EUTRA Command to the UE, as well as
the HO command received from the target UTRAN.
11) The UE switches to a UTRAN target cell specified by the eNB and transmits "HO to

Feature Description
UTRAN Complete" to the UTRAN.

12)-14) The target RNC transmits Relocation Complete message to the target MSC/SGSN
to notify that handover has completed. The target MSC/SGSN processes the handover
completion procedure with the source MME.
15) The source MME releases the resource that has been used in the E-UTRAN after the
SRVCC handover with the UTRAN has completed .

Feature Description
System operation
RTRV-NBR- cellNum The cell number to be changed.

UTRAN relationIdx Database index of UTRAN neighboring cell.
CHG-NBR-
The validity of the UTRAN neighboring cell information.
UTRAN
status - N_EQUIP: UTRAN neighboring cell information is invalid.
CRTE-NBR-
- EQUIP: UTRAN neighboring cell information is valid.
UTRAN
DLT-NBR- rncId RNC ID of UTRAN neighboring cell to the eNB.
UTRAN cId CID of UTRAN neighboring cell to the eNB.
The location area code of UTRAN neighboring cell to the
lac
eNB.
rac The routing area code of UTRAN neighboring cell to the eNB.
The broadcast PLMN list information (MCC) of UTRAN
mcc0[4] neighboring cell to the eNB. It is a three-digit number with
each digit being from 0 to 9.
The broadcast PLMN list information (MNC) of UTRAN
mnc0[4] neighboring cell to the eNB. It is a three-digit or two-digit
number with each digit being from 0 to 9.

Feature Description
(Continued)
RTRV-NBR- The broadcast PLMN list information (MNC) of UTRAN

UTRAN mnc4[4] neighboring cell to the eNB. It is a three-digit or two-digit
CHG-NBR- number with each digit being from 0 to 9.
UTRAN The broadcast PLMN list information (MCC) of UTRAN
CRTE-NBR- mcc5[4] neighboring cell to the eNB. It is a three-digit number with
UTRAN each digit being from 0 to 9.
DLT-NBR-
UTRAN
The duplex type of UTRAN neighboring cell to the eNB.
duplexType - ci_FDD: Frequency division duplex.
The primary scramble code of UTRAN neighboring cell to the
pScmCode
eNB, which needs only for FDD.
The cell parameter ID of UTRAN neighboring cell to the eNB,
cellParaId
which needs only for TDD.
The uplink absolute radio frequency channel number
arfcnUl
(ARFCN) of UTRAN neighboring cell to the eNB.
The downlink absolute radio frequency channel number
arfcnDl
(ARFCN) of UTRAN neighboring cell to the eNB.
Whether to delete a certain neighboring cell to the eNB using
isRemoveAllow the ANR (Automatic Neighbor Relation) function.
ed - True: The neighboring cell can be deleted.
Whether to perform handover to UTRAN neighboring cell.
isHOAllowed - True: Handover is allowed.
Whether to support VoIp of UTRAN neighboring cell.
voipIncapable - True: VoIP is support.
Related Counters
UtranSrvccOutAtt Number of UTRAN SRVCC handover attempts -

Number of successful UTRAN SRVCC handover
UtranSrvccOutPrepSucc -
preparations
Number of successful UTRAN SRVCC handover
UtranSrvccOutSucc -
executions

Feature Description
(Continued)
Preparation fails due to reset notification (eNB

UtranSrvccOutPrepFail_C failure or block restart) from ECMB or by the
-
P_CC_FAIL ECCB block during the UTRAN SRVCC
preparation.
UtranSrvccOutPrepFail_S1 Preparation fails due to S1AP specification
-
AP_CU_FAIL cause during the UTRAN SRVCC preparation.
UtranSrvccOutPrepFail_S1 Preparation fails due to S1 SCTP link failure
-
AP_LINK_FAIL during the UTRAN SRVCC preparation.
Preparation fails due to S1AP relocprep timeout
UtranSrvccOutPrepFail_S1
(not received) during the UTRAN SRVCC -
AP_RP_TO
preparation.
UtranSrvccOutPrepFail_S1 Preparation fails due to receiving S1AP signaling
-
AP_SIG_FAIL during the UTRAN SRVCC preparation.
A call is released due to call control timeout in
UtranSrvccOutFail_CP_C
the protocol blocks (MAC, RLC, PDCP, GTP) -
C_TO
during the UTRAN SRVCC execution.
A call is released due to reset notification (eNB
UtranSrvccOutFail_CP_C failure or block restart) from ECMB or by the
-
C_FAIL ECCB block during the UTRAN SRVCC
execution.
UtranSrvccOutFail_UP_GT A call is released due to the failure in the GTP
-
P_FAIL block during the UTRAN SRVCC execution.
UtranSrvccOutFail_UP_M A call is released due to the failure in the MAC
-
AC_FAIL block during the UTRAN SRVCC execution.
UtranSrvccOutFail_UP_PD A call is released due to the failure in the PDCP
-
CP_FAIL block during the UTRAN SRVCC execution.
UtranSrvccOutFail_UP_RL A call is released due to the failure in the RLC
-
C_FAIL block during the UTRAN SRVCC execution.
UtranSrvccOutFail_RRC_ A call is released due to receiving RRC signaling
-
SIG_FAIL during the UTRAN SRVCC execution.
UtranSrvccOutFail_S1AP_ A call is released due to the S1AP specification
-
CU_FAIL cause during the UTRAN SRVCC execution.
UtranSrvccOutFail_S1AP_ A call is released due to the S1 SCTP link failure
-
LINK_FAIL during the UTRAN SRVCC execution.
A call is released due to S1AP relocoverall
UtranSrvccOutFail_S1AP_
timeout (not received) during the UTRAN -
RO_TO
SRVCC execution.
UtranSrvccOutFail_S1AP_ A call is released due to receiving S1AP
-
SIG_FAIL signaling during the UTRAN SRVCC execution.

Feature Description
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1207, CSFB to_UTRAN with_Redirection

without SI
Overview
Introduction
CS fallback to UTRAN enables the delivery of CS domain services when a UE in being
served by the E-UTRAN. When eNB receives CSFB indicator from MME, then performs a
procedure of redirection without system information.
Benefits
Operator can provide CS service to its subscribers by using legacy CS network (UTRAN).
Users can do a CS call while staying in E-UTRAN, by transition to legacy CS network
(UTRAN).
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 UTRAN supported Device, EPC and UTRAN shall support this feature.
Limitation:
 None
Reference
4) 3GPP TS23.272 Circuit Switched Fallback in Evolved Packet System; Stage 2

Feature Description
Feature Scope
R1 eNB can determine UTRAN target that can transit the terminal state at the time of
CSFB triggering.
 UTRAN measurement report solicitation: if the terminal supports UTRAN
measurement, but Blind option is not activated
 Select NB: if the terminal does not support UTRAN measurement or if Blind
option is activated
R2 eNB can, based on the UE Radio Access Capability, determine the procedures of
CSFB with Redirection to UTRAN. If the terminal does not support enhanced
redirection to UTRAN, carry out CSFB with Redirection without SI procedures.
 Selecting eNB: if there is multiple selectable UTRA carrier, select round robin
R4 eNB can collect statistic data on the procedures of CSFB with Redirection without SI
to UTRAN.
 CSFB with Redirection to UTRAN attempt/success/failure (collection unit: source
cell)

Feature Description
Feature Description
If an UE decides to perform a mobile originated CS call, or receives paging from UTRAN,
CSFB to UTRAN procedure is initiated by the UE by sending NAS EXTENDED
SERVICE REQUEST message with CSFB indicator to the MME. After that, if eNB
receives a S1AP message (Initial Context Setup Request or UE Context Modification
Request) including CSFB indicator from MME, eNB initiates an appropriate inter-RAT
mobility procedure for CSFB. If PS handover to UTRAN isn’t available; release with
redirect to UTRAN procedure is used.
Following figure shows the CSFB to UTRAN based on redirection procedure.
1) The MS starts the CSFB procedure. An idle MS starts the RRC connection
establishment procedure with the eNB to switch to the connected status.
2) The MS transmits NAS EXTENDED SERVICE REQEUST.
3) The MME transmits the S1 request message that has CSFB indicator to the eNB.
For the CSFB of an idle status MS, the eNB processes the AS security activation and
default bearer setup procedure.

Feature Description
5) The eNB requests UTRAN measurement to the MS. (if possible)

7) The eNB transmits the UE Context Release Request to the MME. The MME processes
the S1 release procedure with the eNB.
UTRAN location registration procedure. Thereafter, the MS provides continued CS
service after CS call setup in the UTRAN.

Feature Description
System operation
Related Commands
Command Description
CRTE-NBR-UTRAN - Creates the UTRAN neighboring cell information near the eNB.
- Any parameters not entered are set to the default values.
RTRV-NBR-UTRAN - Retrieves the UTRAN neighboring cell information near the eNB.
If no CELL_NUM or RELATION_IDX parameter values are entered, all
CHG-NBR-UTRAN - Changes the UTRAN neighboring cell information near the eNB.
- Enter the CELL_NUM and RELATION_IDX parameter values to change
the UTRAN neighbor cell information.
DLT-NBR-UTRAN - Deletes the UTRAN neighboring cell information near the eNB.
UTRAN served cell.
If no CELL_NUM or FA_INDEX parameter value is entered, all UTRAN
FA objects are retrieved.
- It uses the Cell Num and fa Index parameter values to change the
UTRAN FA information registered with a specific cell within the eNB.

Feature Description

RTRV-NBR-UTRA CELL_NUM 0 No. of a cell to

CHG-NBR-UTRA retrieve/change/create/delete
DLT-NBR-UTRA cell.
a base station
base station
MCC0 Service Broadcast PLMN list information
provider’ MCC (MCC) of the UTRAN neighbor cell
MNC0 Service Broadcast PLMN list information
provider’ MNC (MNC) of the UTRAN neighbor cell

Feature Description
(Continued)


Feature Description
(Continued)
RTRV-NBR-UTRA DUPLEX_TYPE ci_FDD Duplex type information of the UTRAN

CHG-NBR-UTRA neighbor cell located near the eNB.
CRTE-NBR-UTRA - ci_FDD: Frequency Division Duplex.
DLT-NBR-UTRA - ci_TDD: Time Division Duplex.
eNB (for FDD)
station. (TDD)
UTRAN neighbor cell located around a
base station.
base station.
IS_REMOVE_ALL True Whether to be able to delete a
OWED neighbor cell in a base station using
the Automatic Neighbor Relation
(ANR) function.
IS_HOALLOWED True Whether to perform handover to a
specific UTRAN neighbor cell.
VOIP_INCAPABLE True VoIP support of a specific UTRAN
neighbor cell.
RIM_SUPPORT False RIM support of a UTRAN neighbor
cell.
- True: RIM support

Feature Description
(Continued)
RTRV-NBR-UTRA OWNER_TYPE False Field that indicates a specific neighbor

CHG-NBR-UTRA is allocated through which procedure.
CRTE-NBR-UTRA Specifically displayed as Initial
DLT-NBR-UTRA NRT/ANR by Server/ANR by UE/
Created by User Command/
CreatedByUserUI.
HIGH_PRIORITY_ False Decide whether to apply CSFB_
FOR_CSFB Hysteresis when performing CSFB
with PS HO to a neighboring cell.
CHG-UTRA-FA FA_INDEX 0 UTRA frequency index. Can set up
max. 6 FAs for each cell.
- EQUIP: Valid.
The duplex modes of a cell are FDD
and TDD.
UARFCN_UL Value per The Uplink UTRA Absolute Radio
provider
UARFCN_DL Value per The Downlink UTRA Absolute Radio
provider
frequency
THRESH_XLOW 0 The threshold used to reselect the
low-priority frequency from the high-
priority frequency
Q_RX_LEV_MIN -54 Min. RX level required in a cell.
The unit is dBm.

Feature Description
(Continued)
RTRV-UTRA-FA Q_QUAL_MIN -20 The minimum quality level required by

CHG-UTRA-FA the UTRA FDD cell.
carrier frequency.
THRESH_XHIGH_ 0 The threshold used by the UE when
QREL9 reselecting the frequency with priority
QREL9 reselect the low-priority frequency

Among the registered UTRAN neighbor parameters, the RIM_SUPPORT value must be set
to False for the operation of CSFB to UTRAN with Redirection without SI.
If the RIM_SUPPORT is set to TRUE, the operation will be CSFB to UTRAN with
Redirection with SI.

Feature Description
Related Counters
Statistics date of CSFB redirection number between LTE system and UTRAN system
collects with cell unit
HO UTRAN CSFB Redirection CsfbRedirAtt CSFB with Redirection to inter-RAT UTRAN

OUT UTRAN attempt count
CsfbRedirPre CSFB with Redirection to inter-RAT UTRAN
pSuccUTRAN preparation success count.
CsfbRedirSuc CSFB with Redirection to inter-RAT UTRAN
cUTRAN execution success count.
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1208, CSFB to_UTRAN with_Redirection

with SI
Overview
Introduction
Benefits
(UTRAN).
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 RIM for SI tunneling shall be support EPC and UTRAN
Limitation:
 RIM based SI tunneling is only possible for eNB to acquire UTRAN SI
Reference

Feature Description
Feature Scope
R1 eNB can determine on UTRAN target that will transit the terminal state at the time of
CSFB triggering.
measurement, but Blind option is not activated
 Select eNB: if the terminal does not support UTRAN measurement, or if Blind
option is activated
R2 eNB can determine on the procedures of CSFB with Redirection to UTRAN based on
UE Radio Access Capability. If the terminal supports the enhanced redirection to
UTRAN, carry out CSFB with Redirection with SI procedures.
 If e-RedirectionUTRA-r9=supported in UE-EUTRA-Capability,
 Selecting eNB: if there is multiple selectable UTRA carriers, select round robin
R4 eNB can select UTRAN cell list to be sent to the terminal to handle CSFB with
Redirection with SI and include the SI list of the UTRAN cells to create a RRC
Connection Release message.
 Using UTRAN measurement: include the SI list of UTRAN cell(s) included in
Measurement Report
 Selecting eNB: selects the UTRAN cell(s) that have obtained the SI list among the
neighboring cells of UTRAN of PLD sequentially to include the SI list
R5 eNB can obtain and store the SI list per cell from UTRAN based on UTRAN SI RIM
application with UTRAN and then use it when handling CSFB with Redirection with
SI.
R6 eNB can collect statistic data on the procedure of CSFB with Redirection with SI to
UTRAN.
 CSFB with Redirection attempt/success/failure (collection unit: source cell)

Feature Description
Feature Description
mobility procedure for CSFB. If PS handover to UTRAN isn’t available; release with
redirect to UTRAN procedure is used.
Following figure shows the CSFB to UTRAN based on enhanced redirection procedure.
5) The eNB requests UTRAN measurement to the MS. (if possible)

Feature Description
6) The eNB transmits RRC Connection Release that has the UTRA (FDD or TDD)
carrier frequency to which the MS will be switched, UTRAN cell list, and SI list per
cell to the MS.
7) The eNB transmits the UE Context Release Request to the MME. The MME processes
the S1 release procedure with the eNB.
UTRAN location registration procedure. Thereafter, the MS provides continued CS
service after CS call setup in the UTRAN.

Feature Description
System operation
Related Commands
Command Description
CRTE-NBR-UTRAN - Creates the UTRAN neighboring cell information near the eNB.
- Any parameters not entered are set to the default values.
RTRV-NBR-UTRAN - Retrieves the UTRAN neighboring cell information near the eNB.
- If no CELL_NUM or RELATION_IDX parameter values are entered, all
CHG-NBR-UTRAN - Changes the UTRAN neighboring cell information near the eNB.
- Enter the CELL_NUM and RELATION_IDX parameter values to change
the UTRAN neighbor cell information.
DLT-NBR-UTRAN - Deletes the UTRAN neighboring cell information near the eNB.
UTRAN served cell.
- If no CELL_NUM or FA_INDEX parameter value is entered, all UTRAN FA
- It uses the Cell Num and fa Index parameter values to change the UTRAN
RTRV-TIMER-INF - Retrieves the timer values used by the ECCB within the eNB.
- It can retrieve the timer value used for message transmission/reception
eNB; or other timer values used by the ECCBs.
CHG-TIMER-INF - Changes the timer values used by the ECCB within the eNB.
- It can change the timer value used for message transmission/reception
eNB; or the timer value used by other ECCBs.

Feature Description

RTRV-NBR-UTRA CELL_NUM 0 No. of a cell to retrieve/change/

CHG-NBR-UTRA create/delete
DLT-NBR-UTRA cell.
a base station
base station
MCC0 Provider MCC Broadcast PLMN list information
MNC0 Provider MNC Broadcast PLMN list information

Feature Description
(Continued)


Feature Description
(Continued)
RTRV-NBR-UTRA DUPLEX_TYPE ci_FDD Duplex type information of the UTRAN

CHG-NBR-UTRA neighbor cell located near the eNB.
CRTE-NBR-UTRA - ci_FDD: Frequency Division Duplex.
DLT-NBR-UTRA - ci_TDD: Time Division Duplex.
eNB (for FDD)
station. (TDD)
base station.
base station.
IS_REMOVE_A True Whether to be able to delete a neighbor
LLOWED cell in a base station using the
Automatic Neighbor Relation (ANR)
function.
IS_HOALLOWED True Whether to perform handover to a
specific UTRAN neighbor cell.
VOIP_INCAPAB True VoIP support of a specific UTRAN
LE neighbor cell.
RIM_SUPPORT False RIM support of a UTRAN neighbor cell.
- True: RIM support
OWNER_TYPE False Field that indicates a specific neighbor is
allocated through which procedure.
Specifically displayed as Initial
NRT/ANR by Server/ANR by UE/
Created by User Command/
CreatedByUserUI.

Feature Description
(Continued)

CHG-UTRA-FA FA_INDEX 0 UTRA frequency index. Can set up max.
6 FAs for each cell.
- EQUIP: Valid.
The duplex modes of a cell are FDD and
TDD.
UARFCN_UL Provider The Uplink UTRA Absolute Radio
defined value Frequency Channel Number
UARFCN_DL Provider The Downlink UTRA Absolute Radio
defined value Frequency Channel Number
frequency
THRESH_XLOW 0 The threshold used to reselect the low-
priority frequency from the high-priority
frequency
Q_RX_LEV_MIN -54 Min. RX level required in a cell. The unit is
dBm.
Q_QUAL_MIN -20 The minimum quality level required by the
UTRA FDD cell.
carrier frequency.
_QREL9 reselecting the frequency with priority
QREL9 reselect the low-priority frequency from
the high-priority frequency

Feature Description
(Continued)
RTRV-TIMER-INF RIM_RIR 5000 The time waiting for response after sending
CHG-TMER-INF the MME Direct Information Transfer (RAN-
INFORMATION-REQUEST) to the MINE.
RIM_RIAE 5000 The time waiting for response after sending
the MME Direct Information Transfer (RAN-
INFORMATION-APPLICATION-ERROR) to
the MINE.

Among the registered UTRAN neighbor parameters, the RIM_SUPPORT value must be set
to True for the operation of CSFB to UTRAN with Redirection with SI.
If the RIM_SUPPORT is set to False, the operation will be CSFB to UTRAN with
Redirection without SI.
Related Counters
Statistics date of CSFB redirection number between LTE system and UTRAN system
Family
Category Type Name Description
Name
HO UTRAN CSFB CsfbRedirAttU CSFB with Redirection to inter-RAT UTRAN
Redirection TRAN attempt count
OUT CsfbRedirPre CSFB with Redirection to inter-RAT UTRAN
pSuccUTRAN preparation success count.
CsfbRedirSuc CSFB with Redirection to inter-RAT UTRAN
cUTRAN execution success count.
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW1209, CSFB to_UTRAN with_PS Handover

Overview
Introduction
Benefits
(UTRAN).
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
Limitation:
 None
Reference

Feature Description
Feature Scope
R1 eNB can determine on UTRAN target than can transit the terminal state at the time of
CSFB triggering.
measurement but Blind option is not activated.
R2 eNB can carry out the procedures of CSFB with PS handover if the terminal supports
PS handover to UTRAN measurement and UTRAN.
R4 eNB can select a target UTRAN cell to handle CSFB with PS handover.
 Using UTRAN measurement: select the best cell of UTRAN cell(s) included
Measurement Report
R5 eNB can collect the statistic data on the procedures of CSFB with PS handover to
UTRAN.
 CSFB with PS handover to UTRAN attempt/success/failure (collection unit: source
cell, target cell)

Feature Description
Feature Description
mobility procedure for CSFB. If PS handover to UTRAN is available, CSFB procedure is
performed with PS handover procedure concurrently.
Following figure shows the CSFB to UTRAN based on PS handover procedure.

Feature Description
5) The eNB requests UTRAN measurement to the MS.

6) The handover preparation procedure is processed between the source E-UTRAN and
the target UTRAN.
7) The eNB transmits the Mobility from EUTRA command to the MS as well as the HO
command received from the CSFB indicator and target UTRAN.
8) The MS is switched to the UTRAN target cell specified by the eNB and transmits HO
to UTRAN Complete to the UTRAN.
9) The MS performs the UTRAN location registration procedure. Thereafter, the MS
provides continued CS service after CS call setup in the UTRAN.
10) The handover completion procedure is processed between the source E-UTRAN and
the target UTRAN.
11) The source MME releases the resources used in the E-UTRAN after completing PS
handover with the UTRAN.

Feature Description
System operation
Related Commands
Related Command Command Description
CRTE-NBR-UTRAN Creates the UTRAN neighboring cell information near the eNB.
It uses the CELL_NUM and RELATION_IDX parameter values to create the
UTRAN neighboring cell information. Any parameters not entered are set to
the default values.
RTRV-NBR-UTRAN Retrieves the UTRAN neighboring cell information near the eNB.
It uses the CELL_NUM and RELATION_IDX parameter values to retrieve
only the specified UTRAN neighboring cell information. If no CELL_NUM or
RELATION_IDX parameter values are entered, all UTRAN neighboring cell
CHG-NBR-UTRAN Changes the UTRAN neighboring cell information near the eNB.
Enter the CELL_NUM and RELATION_IDX parameter values to change the
UTRAN neighbor cell information.
DLT-NBR-UTRAN Deletes the UTRAN neighboring cell information near the eNB.
It uses the CELL_NUM and RELATION_IDX parameter values to delete the
UTRAN neighboring cell information.

Related Command Parameter Description
CRTE-NBR-UTRAN - CELL_NUM: No. of a cell to change.

RTRV-NBR-UTRAN - RELATION_IDX: DB index of UTRAN neighbor cell.
CHG-NBR-UTRAN - STATUS: Indicates whether the information on the UTRAN neighbor cell
DLT-NBR-UTRAN located near the eNB is valid.
 N_EQUIP: UTRAN neighbor cell information is not valid.
 EQUIP: UTRAN neighbor cell information is valid.
- RNC_ID: RNC ID of the UTRAN neighbor cell located near the eNB.
- C_ID: CID of the UTRAN neighbor cell located near the eNB.
- LAC: Location Area Code of the UTRAN neighbor cell located near the
eNB.
- RAC: Routing Area Code of the UTRAN neighbor cell located near the
eNB.
- MCC0: Broadcast PLMN list information (MCC) of the UTRAN neighbor
cell located near the eNB. Enter a 3-digit number whose each digit is
between 0 and 9.
- MNC0: Broadcast PLMN list information (MNC) of the UTRAN neighbor
cell located near the eNB. Enter a 3-digit or 2-digit number whose each

Feature Description
(Continued)
CRTE-NBR-UTRAN - MCC1: Broadcast PLMN list information (MCC) of the UTRAN neighbor
RTRV-NBR-UTRAN cell located near the eNB. Enter a 3-digit number whose each digit is
CHG-NBR-UTRAN between 0 and 9.
DLT-NBR-UTRAN - MNC1: Broadcast PLMN list information (MNC) of the UTRAN neighbor
between 0 and 9.
between 0 and 9.
between 0 and 9.
between 0 and 9.
- DUPLEX_TYPE: Duplex type information of the UTRAN neighbor cell
 ci_FDD: Frequency Division Duplex
 ci_TDD: Time Division Duplex
- P_SCM_CODE: The primary scramble code of the UTRAN neighbor cell
- CELL_PARA_ID: Cell parameter ID information of the UTRAN neighbor
cell located near the eNB (TDD)
- ARFCN_UL: Uplink ARFCN (Absolute Radio Frequency Channel Number)
of the UTRAN neighbor cell located near the eNB.
- ARFCN_DL: Downlink ARFCN (Absolute Radio Frequency Channel
Number) of the UTRAN neighbor cell located near the eNB.

Feature Description
(Continued)
CRTE-NBR-UTRAN - IS_REMOVE_ALLOWED: Whether to be able to delete a neighbor

RTRV-NBR-UTRAN cell in a base station using the ANR (Automatic Neighbor Relation)
CHG-NBR-UTRAN function.
DLT-NBR-UTRAN  True: A neighbor cell can be deleted.
 False: A neighbor cell cannot be deleted.
- IS_HOALLOWED: Whether to perform handover to the UTRAN
neighbor cell.
 True: Handover is allowed.
 False: Handover is not allowed.
- RIM_STATUS: Shows the connection status of RIM.
- VOIP_INCAPABLE: Indicates whether the relevant UTRAN neighbor
cell supports the VoIP.
 True: VoIP support.
 False: No VoIP support.
- RIM_SUPPORT: Indicates whether the UTRAN neighbor cell
supports the RIM.
 False: No RIM support
 True: RIM support
- OWNER_TYPE: Indicates whether the UTRAN neighbor cell
supports the RIM. Specifically displayed as Initial NRT/ANR by
Server/ANR by UE/Created by User Command/CreatedByUserUI.
Related Counters
Statistics date of CSFB PS Handover number between LTE system and UTRAN system
Family
Name
HO UTRAN CSFB PS CsfbPsHoAttUTRAN Attempt count for CSFB with inter-RAT
Handover UTRAN PS handover.
OUT CsfbPsHoPrepSuccUTRAN Success count for CSFB with inter-RAT
UTRAN PS handover preparation.
CsfbPsHoSuccUTRAN Success count for CSFB with inter-RAT
CsfbPsHoPrepFailUTRAN_ Preparation fails due to reset
CP_CC_FAIL notification (eNB failure or block restart)
during the CSFB PS handover
preparation.
CsfbPsHoPrepFailUTRAN_ Preparation fails due to S1AP
S1AP_CU_FAIL specification cause during the CSFB PS

Feature Description
(Continued)
Family
Name
HO UTRAN CSFB PS CsfbPsHoPrepFailUTRAN_ Preparation fails due to S1 SCTP link
Handover S1AP_LINK_FAIL failure during the CSFB PS handover
OUT preparation.
CsfbPsHoPrepFailUTRAN_S Preparation fails due to S1AP relocprep
1AP_RP_TO timeout (not received) during the CSFB
PS handover preparation.
CsfbPsHoPrepFailUTRAN_ Preparation fails due to receiving S1AP
S1AP_SIG_FAIL signaling during the CSFB PS handover
preparation.
CsfbPsHoFailUTRAN_CP_ A call is released due to call control
CC_TO timeout in the protocol blocks (MAC,
RLC, PDCP, GTP) during the CSFB PS
handover execution.
CsfbPsHoFailUTRAN_CP_ A call is released due to reset notification
CC_FAIL (eNB failure or block restart) from ECMB
or by the ECCB block during the CSFB
CsfbPsHoFailUTRAN_UP_ A call is released due to the failure in the
GTP_FAIL GTP block during the CSFB PS
handover execution.
MAC_FAIL MAC block during the CSFB PS
handover execution.
PDCP_FAIL PDCP block during the CSFB PS
handover execution.
RLC_FAIL RLC block during the CSFB PS
handover execution.
CsfbPsHoFailUTRAN_RRC A call is released due to receiving RRC
_SIG_FAIL signaling during the CSFB PS handover
execution.
CsfbPsHoFailUTRAN_S1A A call is released due to the S1AP
P_CU_FAIL specification cause during the CSFB PS
handover execution.
CsfbPsHoFailUTRAN_S1A A call is released due to the S1 SCTP
P_LINK_FAIL link failure during the CSFB PS
handover execution.
CsfbPsHoFailUTRAN_S1A A call is released due to S1AP
P_RO_TO relocoverall timeout (not received) during
the CSFB PS handover execution.
CsfbPsHoFailUTRAN_S1A A call is released due to receiving S1AP
P_SIG_FAIL signaling during the CSFB PS handover
execution.

Feature Description
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW2001, SW2002, SW5006: Intra-LTE Load

Balancing
Overview
Samsung intra-LTE LB (load balancing) function supports ‘load balancing between carriers
(SW2001)’ (=inter-frequency LB), ‘load balancing between sectors (SW2002)’ (= intra-
frequency LB), ‘load balancing between multi-operator frequencies (SW5006)’.
The load balancing between carriers feature is to release the overload of the cell or
maintain the difference of cell loads between the co-located inter-frequency cells within the
range set by an operator through inter-frequency HO based on the cell loads on an LTE
network where multiple carriers are operating. (The SW5006 feature is supported by
setting carrier groups properly in SW2001 feature.)
The load balancing between sectors feature is to release the overload of the cell through
intra-frequency HO based on cell loads.
Introduction
Intra-LTE LB uses the X2 interface to periodically exchange the cell load information
between neighbor cells and handovers a UE from a high-loaded cell to a low-loaded cell, so
that parts of traffic can be transferred.
As shown in below figure, intra-LTE LB supports the three types of load balancing
depending on the serving cell load.
k)
d(
ol
ld
sh
ho
re
es
Th
hr
ng
AT
dT
)
di
R
(0
(3
oa
oa
I
ld
ld
ld to
ffl
ffl
ho
ho
ho ad
O
O
es
es
es flo
up
up
hr
hr
hr Of
...
ro
ro
lT
lT
_T lind
G
rG
ua
ua
tra
te
B
eq
eq
in
in
Cell Load
Load equalization
Offloading to intra-group carriers
Offloading to inter-group(k)
carriers
Blind
offloading to
inter-RAT

Feature Description
1) Load equalization
The cell load balance between a serving cell and a co-located inter-frequency neighbor
cell is maintained within the range of cell load difference set by an operator.
2) Offloading to intra-group carriers
If a serving cell’s cell load exceeds intraGroupOffloadThreshold, to resolve the
overload status, offloading is performed to low-loaded intra-frequency & inter-
frequency neighbor cells that belong to the same carrier group.
3) Offloading to inter-group carriers
If a serving cell’s cell load exceeds interGroupOffloadingThreshold (k), to resolve the
overload status, offloading is performed to low-loaded inter-frequency neighbor cells
that belong to carrier group (k).
Below figure is Concept of load equalization & offloading to intra-/inter-group carriers.
Benefits
Using the intra-LTE LB feature, the following advantages are available.
1) Operator side: By distributing traffic over multiple carriers, good QoS can be provided
for each carrier.
2) End user side: The Quality of Experience (QoE) felt by the user can be improved.
Release History
SLR2.3 (New Entry)
SLR2.4 (Revised)

Feature Description
Basic or Optional
Optional Feature: Three intra-LTE LB features can be activated or deactivated.

The load balancing between carriers feature has the following dependencies and limitations.
1) Dependency
 Neighbor cell condition: Load balancing is performed to neighbor cells where the
same DU or X2 interface exists.
 UE capability: UEs support target carriers.
2) Limitation
 Conditions for load equalization: Load equalization can be performed only when an
inter-frequency co-located neighbor cell supports a carrier of the same carrier group
and is set as a co-located cell in NRT.
Reference
1) 3GPP 36.300: E-UTRA and E-UTRAN; overall description Stage 2
3) 3GPP 36.423: E-UTRAN; X2 application protocol (X2AP)
cases and solutions

Feature Description
Feature Description
Samsung intra-LTE LB operates according to the following procedures.
1) Cell load monitoring is performed to serving cells and neighbor cells.

2) During LB-triggering, the target cell and target UE are selected.
3) HO is performed for the combination of the target cell and the target UE.
Below figure is Flow of intra-LTE LB operation.

Feature Description
Cell load monitoring

1) Cell load information exchange over X2 interface
When an intra-LTE LB is activated, Samsung eNB transmits the resource status
request message to neighbor eNBs to which neighbor cells of the serving cell belong
for resource status reporting initiation.
According to the 3GPP X2AP standard, an X2 resource status update message includes
the following load information.
Below table is Load information in X2 Resource Status Update message.
IE Name IE Name IE type Mandatory/Optional
Hardware Load DL/UL HW load ENUM{LowLoad, Optional

Indicator indicator Medium, High,
Overload}
S1 TNL Load Indicator DL/UL S1 TNL load ENUM{LowLoad, Optional
indicator Medium, High,
Overload}
Radio Resource DL/UL GBR PRB INTEGER (0, .., 100) Optional
Status usage
DL/UL non-GBR PRB
usag
DL/UL total PRB usag
Composite Available DL/UL cell capacity INTEGER (0, .., 100) Optional
Capacity Group class value
DL/UL capacity value
2) Definition of cell load

The capacity value represents the amount of available resources, so Samsung intra-
LTE LB defines the cell load as ‘100-min{DL cell capacity, UL cell capacity}’.
3) Carrier group configuration

According to the operator’s policy, multiple carriers are divided into several groups.
Up to 4 carrier groups can be configured using PLD_LbGroup. Each group can have
four FAs.

Feature Description
4) LB-triggering condition
There are three conditions for Samsung intra-LTE LB-triggering depending on the
features illustrated in below figure.
 Load equalization
− Pre-requiste:
Considering a network deployment, the operator needs to set co-located
inter-frequency cells in NRT (PLD name: ExternalEutranCellFDDLogic) to
‘isColocated=True’.
As shown in below figure, maximum four levels of multi-level load
equalization are allowed, so parameters to perform multi-level load
equalization should be properly set.
Below figure is Multi-level load equalization threshold.
Load
Difference
equalDelta(0)
equalDelta(1)
equalDelta(2)
equalDelta(3)
Cell Load
in
eq
eq
eq
eq
tra
ua
ua
ua
ua
G
lT
lT
lT
lT
ro
hr
hr
hr
hr
up
es
es
es
es
O
ho
ho
ho
ho
ffl
ld
ld
ld
ld
oa
(0
(1
(2
(3
dT
)
hr
es
ho
ld
−Triggering condition: Load equalization can be set in four levels depending on the
cell load, and when a serving cell load exceeds equalThreshold (k) in Figure 4
and the cell load difference between two inter-frequency cells exceeds equalDelta
(k), load equalization is triggered.
 Offloading to intra-group carriers
− Triggering condition: When a serving cell load exceeds
intraGroupOffloadThreshold, offloading is triggered.
 Offloading to inter-group carriers
− Triggering condition: When a serving cell’s load exceeds
interGroupOffloadingThreshold (k), offloading to low-loaded inter-frequency
neighbor cells that support carriers of groupdId=k is triggered.

Feature Description
Target Cell & Target UE Configuration

Samsung intra-LTE LB selects the combination of target cell and target UE, and performs
forced HO rather than changing the HO parameters to reduce the serving cell’s load.
The benefit of this scheme is that after LB-triggering, a serving cell’s load can be reduced
significantly within a certain period of time.
The target cell and target UE selection procedure is described below.
 Candidate UE selection and measurement configuration:
The number of UEs (candidate UE) set in the numLbCandidate parameter are
randomly selected for periodic measurement.
 Target UE & target cell selection:
In an inter-frequency neighbor cell, it has to meet the condition that RSRP exceeds the
threshold (lbThresholdRSRP), and in an intra-frequency neighbor cell, candidate cells’
RSRP which are greater than a serving cell’s are sorted by cell loads.
The combinations of the target cell and target UEs set in the numLbTarget parameter
are selected for forced HO.

Feature Description
System operation
 Related commands
RTRV-TM-CNTR RETRIEVE TRAFFIC MANAGEMENT FUNCTION CONTROL

CHG-TM-CNTR CHANGE TRAFFIC MANAGEMENT FUNCTION CONTROL
RTRV-ACTIVE-LB RETRIEVE ACTIVE LOAD BALANCING CONFIGURATION
CHG-ACTIVE-LB CHANGE ACTIVE LOAD BALANCING CONFIGURATION
RTRV-LBGRP-CONF RETRIEVE MOBILITY LOAD BALANCING GROUP
INFORMATION
CHG-LBGRP-CONF CHANGE MOBILITY LOAD BALANCING GROUP INFORMATION
RTRV-NBR-EUTRAN RETRIEVE EXTERNAL EUTRAN CELL FDD INFORMATION
CHG-NBR-EUTRAN CHANGE EXTERNAL EUTRAN CELL FDD INFORMATION
 Related system parameters
Intra-LTE LB related parameters are as below:

Paramter Range Default Value Description
loadEqualizationEnable enumDiagCallEnble_ ci_OFF On/off status of load

type equalization function
intraGroupOffloadEnable enumDiagCallEnble_ ci_OFF On/off status of intra
type group traffic offload
function.
interGroupOffloadingEnable enumDiagCallEnble_ ci_OFF On/off status of inter
type group traffic offload
function.

Feature Description
PLD_LbGroup is as below:
groupId 0~3 0 Mobility Load Balancing Group ID to

configure
grpFA0 0~65535 0 Downlink-E-UTRA absolute radio
frequency channel number (earfcn_dl)
of the FA in the mobility load balancing
group
of configured for the mobility load
balancing group
balancing group
balancing group
offloadingToThisInter enumDiagCall ci_OFF Whether inter-group traffic offloading
GroupEnable Enble_type function is possible or not for the Group
ID.
interGroupOffloading 0.0~100.0 80.0 Threshold of the source cell load to
Threshold trigger inter-group traffic offloading
PLD_ActiveModeLbConf is as below:
numEqualStep 1~4 1 Number of steps for load equalization

equalThreshold0 0.0~100.0 50.0 Serving cell load condition for entering
step_0 load equalization
equalDelta0 0.0~100.0 20.0 Load difference condition between
serving cell and co-located
interfrequency neighbor cell for entering

Feature Description
(Continued)
equalDelta1 0.0~100.0 20.0 Load difference condition for entering

intraGroupOffloadThr 0.0~100.0 70.0 Serving cell load condition to trigger
eshold offloading to intra-group carriers
lbExitDeltaThreshold 0.0~100.0 5.0 This parameter is for Load Balancing
operation exit hysteresis.
targetCellLoadThres 0.0~100.0 50.0 Threshold of inter-sector load
hold distribution. Only when the radio
resource load of target cell is smaller
than this threshold, inter-sector load
distribution can be triggered.
tLoadDecisionLb 0~1440 5 Period of cell load calculation
tResourceStatusRep enumLbmcPe ci_lbPeriod1_ Period of cell load status reporting to X2
orting riod1_type 10000 ms connected neighbor cells
tMeasurementCollect enumLbmcPe ci_lbPeriod2_ Period of measurement report collection
ionLb riod2_type 1 min
tMeasurementReport enumLbmcPe ci_lbPeriod3_ Interval of periodic measurement report
IntervalLb riod3_type 480 ms
lbTriggeringDuration 0~300 5 Active LB is triggered when the cell load
condition is satisfied during this interval.
nrRankingPeriod 1~168 24 This parameter is the period for ranking
neighbor cells to select
numOfNrForActiveLb neighbor cells per
FA which exchange cell load over X2.
numOfNrForActiveLb 0~256 32 Number of neighbor cells per FA to
exchange cell load with serving cell
numLbCandidate 0~600 20 Number of UEs which perform
measurement for load balancing.
numLbTarget 0~600 1 Number of UEs which perform
handover for load balancing
movingAvWeightFor 0.0~1.0 0.5 This parameter is used for calculating
CellLoad cell load in moving average.
capacityLbAlphaFact 0.0~1.0 0.8 Coefficient of numLbmcMaxUe defined
or for capacity value
capacityLbBetaFactor 0.0~1.0 1.0 Coefficient of non-GBR PRB usage
defined for capacity value

Feature Description
(Continued)

cpuThreshold 0.0~100.0 70.0 Maximum CPU load defined for
capacity value
minBackHaulCapacity 0.0~100.0 3.0 Minimum backhaul capacity per UE
defined for capacity value
lbRadioCondition triggerQuantit ci_rsrp Wheter to select RSRP or RSRQ as a
y_type radio condition for mlb.
- ‘0’: select RSRP.
- ‘1’: select RSRQ.
lbThresholdRSRP 0~97 55 RSRQ threshold of inter-frequency
neighbor cell used in selecting mLb
candidate UEs
lbThresholdRSRQ 0~34 33 RSRP threshold of inter-frequency
neighbor cell used in selecting mLb
candidate UEs
hwLoadLowThreshold 0.0~100.0 30.0 If CPU usage is lower than this
threshold, the cell is determined to have
low HW load.
hwLoadMediumThre 0.0~100.0 50.0 If CPU usage is lower than this threshold
shold and higher than
HW_LOAD_LOW_THRESHOLD, the cell
is determined to have medium HW load.
hwLoadHighThreshold 0.0~100.0 70.0 If CPU usage is lower than this
threshold and higher than
HW_LOAD_MEDIUM_THRESHOLD,
the cell is determined to have high HW
load. If CPU usage is higher than this
threshold, the cell is determined to have
HW overload.
s1TnlLoadLowThres 0.0~100.0 30.0 If TNL usage is lower than this
hold threshold, the cell is determined to have
low S1 TNL load.
s1TnlLoadMediumTh 0.0~100.0 50.0 If TNL usage is lower than this
reshold threshold and higher than
S1_TNLLOAD_LOW_THRESHOLD,
the cell is determined to have medium
S1 TNL load.
s1TnlLoadHighThres 0.0~100.0 70.0 If TNL usage is lower than this
hold threshold and higher than S1_
TNLLOAD_MEDIUM_THRESHOLD,
the cell is determined to have high S1
TNL load. If TNL usage is higher than
this threshold, the cell is determined to
have S1 TNL overload.
s1TnlMaxCapacity 0~2000000 1000000 This is the maximum S1 TNL capacity in
the unit of kbps.

Feature Description
PLD_ExternalEutranCellFDDLogic is as below
isColocat BOOL False This parameter defines whether this neighbor cell
ed is co-located with the serving cell or not.
- True: The neighboring cell is co-located.
- False: The neighboring cell is NOT co-located
Related Counters
Family
Name
MLBO LBHO - Step 1: Load equalization
Step 2: Offloading to intra-/inter-group carriers
MlbNotTrigg Counted when a handover cannot be performed because the
eredByLoad following condition is not met when making a decision based
Condition on load balancing handover condition after receiving the
Measurement Report message from the UE. (Condition)
neighbor cell’s load < overloadThresholdTarget
MlbNotTrigg When load balancing is not performed because the target
eredByRadi cell does not have an UE whose RSRP/RSRQ meets the
oCondition LBHO channel condition, the number of such events is
counted.
MlbHOAtt Counted when a load balancing handover is attempted.
MlbHOSucc Counted when a load balancing handover is success.

Feature Description
Related KPI/PI
Family Type Check
Category Description
Name Name method
MLBO LBHO MlbNotTri Receives Measurement Report messages from the LBHO
ggeredBy terminal and if the following conditions are not satisfied, triggering
LoadCon when determining on the load balancing handover and refer to
dition conditions, and the handover is not carried out, counting Description
is started. (conditions) neighbor cell’s load <
overloadThresholdTarget
MlbNotTri If the RSRP/RSRQ value of the serving cell that is LBHO
ggeredBy received to Measurement Report message from the triggering
RadioCo terminal and the RSRP/RSRQ value of the target cell fail and refer to
ndition to satisfy the following conditions and load balancing Description
handover is not carried out, counting is started.
(condtions) targetCellRSRP > servingCellRSRP &
targetCellRSRQ > servingCellRSRQ
MlbHOAtt Counting is started at the time when Load balancing LBHO
handover is attempted. triggering
and refer to
Description
MlbHOSu Counting is started at the time when Load balancing LBHO
cc handover make a success. triggering
and refer to
Description
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW2003, Idle UE Distribution

Overview
The idle UE distribution feature is to distribute active-to-idle transiting UEs according to
the UE rate for each carrier set by an operator, so that UEs are not concentrated on a
specific carrier in an LTE network in which multiple carriers are operating.
Introduction
The cell reselection priority for carriers delivered by the SIB information is commonly
applied to all UEs in a serving cell. (The cell reselection priority for serving carriers is
contained SIB3 IE for transmission and the cell reselection priority for inter-carriers is
contained in SIB5 IE for transmission.) In this case, it is highly likely that most of idle UEs
will camp on the carrier with the highest priority, and when idle UEs in the carrier achieve
RRC connections, loads are concentrated to the carrier. In an LTE network where multiple
carriers are operating, to prevent UEs from being densely located in a specific carrier, an
operator can set the UE rate for each carrier to distribute UEs considering the network
deployment.
Below figure is Concept of idle UE distribution.
Benefits
The idle UE distribution feature provides the following benefits.
Operator side: According to the UE rate for each carrier set by an operator’s policy, the
operator can distribute the traffics.
Release History
SLR2.3

Feature Description
Basic or Optional
Optional Feature: The idle UE distribution feature can be activated or deactivated.

None
Reference
cases and solutions

Feature Description
Feature Description
According to the UE rate for each carrier set by an operator’s policy, Samsung eNB transmits
the carrier’s cell reselection priority to active-to-idle transiting UEs by using the
IdleModeMobilityControlInfo IE within an RRCConnectionRelease message. (See Below
Figure)
Below figure is Example of idle UE distribution in 2-carrier LTE network.
As shown in below figure, the cell reselection priority by carrier transmitted to the
IdleModeMobilityControlInfo IE is valid only for T320, and when the timer expires, the
cell reselection priority transmitted to SIB3 & SIB5 is used.

Feature Description
Below figure is Valid duration of cell reselection priority in IdleModeMobilityControlInfo

IE.

Feature Description
System operation
Command Description
CHG-TM-CNTR Changes whether to enable the idle mode load balancing feature
RTRV-TM-CNTR Retrieve whether to enable the idle mode load balancing feature
CHG-IDLELB-INFO Changes the information of the idle mode load balancing feature
RTRV-IDLELB-INFO Retrieve the information of the idle mode load balancing feature
PLD_TrafficManageFuncCellControl is as below:
idleModeLbEnable Whether to enable the idle mode load Set and retrieve the parameter
balancing feature value using the RTRV-TM-
- Range: enumSonCtrlType CNTR and CHG-TM-CNTR
- Default: sonManualApply commands.
PLD_IdleModeLbInfoConf is as below:
dleModeLoadBalanc Implementation of Idle Mode Load Use CHG-SONFN-CELL, RTRV-

eEnable Balance. SONFN-CELL Command to set or
Range: 0~2 display the parameters.
Default: 0
faIndex Index for a FA subject to idle mode Retrieve the faIndex parameter
load balancing. using the RTRV-IDLELB-INFO
- Range: 0~7 command.
- Default: 0
status Whether the faIndex settings are Set and retrieve the parameter
valid values using the CHG-IDLELB-INFO
- Range: 0~1 and RTRV-IDLELB-INFO command.
- Default: 0
bandIndicator Band indicator for faIndex Set and retrieve the parameter
- Range: 1~64 values using the CHG-IDLELB-INFO
- Default: 2 and RTRV-IDLELB-INFO command.
earfcnDL Donwlink ARFCN of faIndex Set and retrieve the parameter
- Range: 0~65535 values using the CHG-IDLELB-INFO
- Default: 0 and RTRV-IDLELB-INFO command.

Feature Description
(Continued)
searchRate Rate of frequency selection for faIndex Set and retrieve the parameter
- Range: 0~65535 values using the CHG-IDLELB-
- Default: 0 INFO and RTRV-IDLELB-INFO
command.
priority cellReselectionPriority value for faIndex Set and retrieve the parameter
- Range: 0~7 values using the CHG-IDLELB-
- Default: 0 INFO and RTRV-IDLELB-INFO
command.
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE- SW2004, Blind Offloading to WCDMA

Overview
Introduction
Below figure shows the load balancing functions as the serving cell load increases.
Depending on a service provider's network environment, the intra-LTE load balancing
functions such as load equalization, offloading to intra-group carriers, or offloading to
inter-group carriers are initiated first of all and then the blind offloading to inter-RAT
(WCDMA) function is initiated if cell overload cannot be removed in the LTE network.
Benefits
The Intra-LTE LB function provides the following benefits.
 Operator's benefit: Using the WCDMA network, the operator can alleviate the
overload status of the LTE network.
Release History
SLR 2.4

The Blind Offloading to WCDMA has the following dependency and limitation.
 Dependency

Feature Description
− Dependency: To enable the blind offloading to WCDMA function, the operator

must set the FA information of WCDMA.
 Limitation
− Threshold condition: The BlindOffloadtoIRAT_Threshold (Parameter name:
iratOffloadThreshold) in Fig.1 should be set higher than
intraGroupOffloadThreshold or interGroupOffloadingThreshold(k).
Feature Scope
None
Reference
3) 3GPP 36.423: E-UTRAN; X2 application protocol (X2AP)
cases and solutions

Feature Description
Feature Description
The Samsung intra-LTE LB is operating in the following procedure.
1) Cell load monitoring for a serving cell
− For cell load definition, refer to the SW2001 Feature Description (FD).
− If cell load exceeds the ‘parameter name: iratOffloadThreshold’, the blind
offloading to WCDMA operation is triggered.
2) UE selection and redirection execution
− After checking UE capability, select the UEs that support N_LBMC_TARGET
WCDMAs and perform redirection.

Feature Description
System operation
Command Description
CHG-TM-CNTR Changes whether to enable the Blind Offloading to WCDMA function.

RTRV-TM-CNTR Retrieves whether to enable the Blind Offloading to WCDMA function.
CHG-ACTIVE-LB Changes the information in the PLDActiveModeLbInfoFunc related to
the Active Mode Load Balancing function.
RTRV- ACTIVE-LB Retrieves the information in the PLDActiveModeLbInfoFunc related to
the Active Mode Load Balancing function.
Parameter Range Default Value Description
enumDiagCall On/off status of inter-RAT blind

blindOffloadTo3GEnable ci_OFF
Enble_type offloading to 3G.
Serving cell load condition for
iratOffloadThreshold 0.0 - 100.0 99.0 entering blind offloading to inter-
RAT
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE- SW2006, Load-based Idle UE Distribution

Overview
Introduction
The cell reselection priority for a carriers delivered by the SIB information is commonly
applied to all UEs in a serving cell. (The cell reselection priority for serving carriers is
contained in SIB3 IE for transmission and the cell reselection priority for inter-carriers is
contained in SIB5 IE for transmission.) In this case, it is highly likely that most of idle UEs
will be camped to the carrier with the highest priority, and when idle UEs in the carrier
achieve RRC connections, loads are concentrated to the carrier. In an LTE network where
multiple carriers are operating, to prevent UEs from being densely located in a specific
carrier, an operator can distribute the UEs by considering average cell load per carrier in a
specific area (determined by the number of cells per carrier set by an operator).
Benefits
The idle UE distribution feature provides the following benefits.
 Operator side: The operator can distribute the traffic according to the average cell load
for each carrier.
Release History
SLR 2.4

The Blind Offloading to WCDMA has the following dependency and limitation.
 Dependency
− The load-based idle UE distribution feature can work normally when the cell
capacity values are obtained by exchanging the resource status update message
with neighbors cells via X2.

Feature Description
Feature Scope
None
Reference
cases and solutions

Feature Description
Feature Description
Calculation of the Average Cell Capacity of a Carrier
The function calculates the average cell capacity value for numOfNrForIdleLB cells (set by
the operator) of a carrier during periodForIdleLB period (cell capacity value: information
included in the Composite Available Capacity Group IE).
It calculates the average cell capacity for the serving cell of the carrier and
‘numOfNrForIdleLB – 1’ neighbor cells with high HO attempts. For other carriers, the co-
located cell is included with the highest priority. And the average cell capacity is calculated
for numOfNrForIdleLB cells with high HO attempts.
The number of UEs per carrier is calculated in proportion to the average cell capacity of
each carrier calculated above and it is updated at every periodForIdleLb.
Idle UE Distribution according to Auto-configured UE Rate

If the serving cell load exceeds idleLbEnterThreshold, the Samsung eNB transmits the cell
reselection priority of each carrier to each active-to-idle transition UE using
IdleModeMobilityControlInfo IE in the RRCConnectionRelease message according to the
UE ratio per carrier automatically calculated in the above procedure (see below figure).

Feature Description
Below figure is example of idle UE distribution in 2-carrier LTE network.
As shown in below figure, the cell reselection priority per carrier that is transmitted to
IdleModeMobilityControlInfo IE is valid only during T320. When the timer is expired, the
cell reselection priority is used that is transmitted to SIB3 or SIB5.
Below figure is valid duration of cell reselection priority in IdleModeMobilityControlInfo

IE.

Feature Description
System operation
Command Description
CHG-TM-CNTR Changes whether to enable the idle mode load balancing feature.
RTRV-TM-CNTR Retrieves whether to enable the idle mode load balancing feature.
CHG-IDLELB-INFO Changes the information related to the idle mode load balancing feature
in PLDIdleModeLbInfoFunc.
RTRV-IDLELB-INFO Retrieves the information related to the idle mode load balancing feature
in PLDIdleModeLbInfoFunc.
CHG-IDLE-LB Changes the information related to the idle mode load balancing feature
in PLDIdleModeLbConf.
RTRV-IDLELB Retrieves the information related to the idle mode load balancing feature
in PLDIdleModeLbConf.
 Related System Parameter List(TrafficManageFuncCellControl)
Parameter Description How to Check
idleModeLbEnable Whether to enable the idle mode load The RTRV-TM-CNTR command
balancing feature. and CHG-TM-CNTR command
Range: enumSonCtrlType retrieves and changes this
Default: sonManualApply parameter respectively.
 Related System Parameter List(IdleModeLbInfoFunc)
faIndex Index of the FA when the idle mode The RTRV-IDLELB-INFO command
load balancing feature is used. retrieves this parameter.
Range: 0~7
Default: 0
status Whether the setting value of the The CHG-IDLELB-INFO command and
faIndex is valid. RTRV-IDLELB-INFO command
Range: 0~1 changes and retrieves this parameter
Default: 0 respectively.
bandIndicator Band indicator of faIndex. The CHG-IDLELB-INFO command and
Range: 1~64 RTRV-IDLELB-INFO command
Default: 2 changes and retrieves this parameter
respectively.

Feature Description
(Continued)
earfcnDL Downlink ARFCN of faIndex. The CHG-IDLELB-INFO command and

Range: 0~65535 RTRV-IDLELB-INFO command
Default: 0 changes and retrieves this parameter
respectively.
searchRate Rate that the eNB selects the The CHG-IDLELB-INFO command and
frequency of faIndex. RTRV-IDLELB-INFO command
Range: 0~65535 changes and retrieves this parameter
Default: 0 respectively.
 Related System Parameter List(PLD_IdleModeLbConf)
numOfNrForIdleLB Number of neighbor cells for calculating The CHG-IDLE-LB command

the load of each FA for the cell where and RTRV-IDLE-LB command
the idle mode LB feature is used. changes and retrieves this
Range: 0~32 parameter respectively.
Default: 16
idleLbEnterThresho Minimum load of the serving cell to use The CHG-IDLE-LB command
ld the idle mode LB feature (auto-apply and RTRV-IDLE-LB command
mode). changes and retrieves this
Range: 0.0~100.0 (%) parameter respectively.
Default: 20.0
periodForIdleLb Period for calculating the load of each The CHG-IDLE-LB command
FA for the cell where the idle mode LB and RTRV-IDLE-LB command
feature is used. changes and retrieves this
Range: 0~60 (min) parameter respectively.
Default: 5
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A

Feature Description
Related Call Faults

N/A

Feature Description
LTE-SW2011, Service based Intra-LTE Handover

Overview
Introduction
The UE can use a variety of services such as Voice over LTE, Web, or FTP in the LTE
network. Because each service has different characteristics, it is necessary to use a different
handover policy for each service. For example, in case of Vo LTE in a multi-carrier
environment, it is necessary to enable the UE to handover to the carrier with good coverage.
Services with a different QoS use a different QCI. For handover control for each service,
the eNB applies the handover policy set for each QCI.
The service based intra-LTE handover function can be used in the multi-carrier
environment. The eNB uses this function only to the UE that supports multi-carrier.
Benefits
 Using a handover policy set for each QCI, a different handover policy can be applied
for a different service.
 The mobility quality of VoLTE can be improved.
Release History
SLR 2.4

 Dependency:
− This function can be enabled in the multi-carrier environment.
− The UE should support multi-carrier.
 Limitation:
− Up to 5 mobility profiles are allowed.
− QCI 5 is determined according to the default mobility profile.
Feature Scope
R1 The eNB should provide a mobility profile containing handover related policy.
− Preferred target carrier frequencies for E-UTRAN (FDD or TDD)
− Handover triggering event
− Measurement configuration
− Blind redirection option
R2 The eNB should provide up to 5 mobility profiles of R1.
R3 The operator should be able to set up QCI per mobility profile.
R4 The operator should be able to set up priority per QCI to select a mobility profile.
R5 The eNB should be able to process the intra-LTE handover to a preferred target carrier

Feature Description
that is specified according to the QCI mobility profile.

R6 The eNB should be able to process intra-LTE measurement configuration according to
the QCI mobility profile of a moving UE.
Reference
None

Feature Description
Feature Description
Operation Scenario
The operator sets the parameters required for service based intra-LTE handover.
Provisioning/Parameter Settings for service based Intra-LTE
Appropriate mobility profile is allocated to each QCI. Below table shows an example of
mobility profile allocation according to QCI. Mobility Profile 0 is the default configuration,
which is allocated to the QCI that does not belong to Mobility Profiles 1-4. For QCI 5,
Mobility Profile 0 is allocated instead of Mobility Profiles 1-4.
Below table is example of mobility profile allocation for each QCI.
Mobility Profile Mobility Pr Mobility Pr Mobility Mobility

Mobility Profile 0
# ofile 1 ofile 2 Profile 3 Profile 4
Default
QCIs allocated
configuration No allocated
to each mobility QCI 1 QCI 2,3,4 QCI 7,8,9
(Default value per QCI
group
QCI)
Mobility control related items are set for each mobility profile as shown below.
 Preferred target carrier frequencies for E-UTRAN (FDD or TDD)
 Handover triggering event
 Measurement configuration
 Blind redirection option
If the UE has several QCIs, a mobility profile is allocated to the QCI with the highest
priority. For this, the operator can set priority per QCI as shown in below table.
Below table is example of Priority Allocation per QCI.

QCI# 0 1 2 3 4 5 6 7 8 9
Priority 9 2 4 3 5 1 6 7 8 9
The mobility profile for a UE is determined based on the QCI of a bearer that is used by the
UE. Therefore, a different handover policy can be used per QCI. The operational scenario
is described below.
For example, UE A and UE B have QCI 1 and QCI 9 respectively and mobility profile per
QCI is set as shown in below table. That is, Mobility Profile 1 is allocated to UE A and
Mobility Profile 2 is allocated to UE B. In this case, if a preferred carrier is set to Carrier A
for Mobility Profile 1 and Carrier B for Mobility Profile 2, UE A handovers to Carrier A
and UE B handovers to Carrier B as shown in below figure.
Below table is example of Mobility Profile Allocation per QCI that is Set in the UE.

Feature Description
UE A B
QCI 1 9
Mobility Profile Mobility Profile 1 Mobility Profile 2
Below figure is example of service based intra-LTE handover.

Feature Description
System operation
Command Description
Retrieves information on E-UTRAN neighboring cell to the eNB. If the

RTRV-NBR- CELL_NUM and RELATION_INDEX parameters are entered, the information for
EUTRAN a certain E-UTRAN neighboring cell is retrieved. If not, the information for all E-
UTRAN neighboring cells is retrieved.
Changes information on E-UTRAN neighboring cell to the eNB. This command
CHG-NBR-
can change information on E-UTRAN neighboring cell by entering the
EUTRAN
CELL_NUM and RELATION_IDX parameter values
Creates information on E-UTRAN neighboring cell to the eNB. The user can
CRTE- NBR- create information on E-UTRAN neighboring cell by entering the CELL_NUM and
EUTRAN RELATION_IDX parameter values. If parameters are not specified, they are set
to the defaults
Deletes information on E-UTRAN neighboring cell to the eNB. The user can
DLT-NBR-
delete information on E-UTRAN neighboring cell by entering the CELL_NUM and
EUTRAN
RELATION_IDX parameter values.
Default
Value
cellNum The cell number to be changed. - -
relationIdx Database index of E-UTRAN neighboring cell. - -
The validity of the E-UTRAN neighboring cell information. - -
- N_EQUIP: The E-UTRAN neighboring cell information is
Status invalid.
- EQUIP: The E-UTRAN neighboring cell information is
valid.
The eNB ID of the eNB to which E-UTRAN neighboring cell - -
to the eNB belongs. If the enbType value is macro eNB, 20
EnbId bit of the value is eNB ID. If the enbType value is home
eNB, 28 bit of the value is eNB ID. It is used when creating
a cell identifier.

Feature Description
(Continued)
Default
Value
The local cell ID of E-UTRAN neighboring cell to the - -
targetCellNum
eNB. It is used when creating a cell identifier.
The type of the eNB to which E-UTRAN neighboring - -
cell to the eNB belongs.
EnbType
The PLMN information (MCC) of the eNB to which E- - -
enbMcc[4] UTRAN neighboring cell to the eNB belongs. It is a
three-digit number with each digit being from 0 to 9.
The PLMN information (MNC) of the eNB to which E- - -
UTRAN neighboring cell to the eNB belongs. It is a
enbMnc[4]
three-digit or two-digit number with each digit being from
0 to 9.
The physical cell ID of E-UTRAN neighboring cell to the - -
PhyCellId
eNB
The tracking area code of E-UTRAN neighboring cell to - -
Tac
the eNB.
The broadcast PLMN list information (MCC) of E- - -
mcc0[4] UTRAN neighboring cell to the eNB. It is a three-digit
The broadcast PLMN list information (MNC) of E- - -
mnc0[4] UTRAN neighboring cell to the eNB. It is a three-digit or
two-digit number with each digit being from 0 to 9.

Feature Description
(Continued)
Default
Value
The uplink EARFCN (E-UTRAN Absolute Radio - -
EarfcnUl Frequency Channel Number) of E-UTRAN neighboring
cell to the eNB.
The uplink EARFCN (E-UTRAN Absolute Radio - -
EarfcnDl Frequency Channel Number) of E-UTRAN neighboring
cell to the eNB.
The uplink bandwidth of E-UTRAN neighboring cell to - -
bandwidthUl
the eNB.
The downlink bandwidth of E-UTRAN neighboring cell - -
bandwidthDl
to the eNB.
The cell individual offset to be applied to E-UTRAN - -
IndOffset neighboring cell to the eNB.It is used for UE
measurement in RRC Connected mode.
The cell quality offset to be applied to E-UTRAN - -
QoffsetCell neighboring cell to the eNB.It is used for UE cell re-
selection in RRC Idle mode.
Whether to delete a certain neighboring cell to the eNB - -
IsRemoveAll using the ANR (Automatic Neighbor Relation) function.
owed - True: The neighboring cell can be deleted.
Whether to perform handover to E-UTRAN neighboring - -
cell.
isHOAllowed
This parameter defines how NRT is updated, This filed - -
can be classfied Initial NRT/ANR by Server/ANR by
ownerType
UE/Created by User Command/
CreatedByUserUI.

Feature Description
Related Counters
Default
Counter Description Range
Value
IntraEnbAtt Intra eNB handover attempt count - -
IntraEnbPrepSucc Intra eNB handover preparation success count - -
IntraEnbSucc Intra eNB handover execution success count - -
Intra eNB handover preparation fails due to - -
IntraEnbPrepFail_CP_
due to call control timeout in the protocol
CC_TO
Intra eNB handover preparation fails due to - -
IntraEnbPrepFail_CP_
reset notification (eNB failure or block restart)
CC_FAIL
IntraEnbPrepFail_UP_ Intra eNB handover preparation fails due to - -
MAC_FAIL the failure in the MAC block
IntraEnbPrepFail_UP_ Intra eNB handover preparation fails due to the - -
RLC_FAIL failure in the RLC block
IntraEnbPrepFail_RR Intra eNB handover preparation fails due to - -
C_SIG_FAIL receiving RRC signaling
IntraEnbPrepFail_CP_ - -
Intra eNB handover preparation fails due to
BH_CAC_
Backhaul QoS based CAC
FAIL
IntraEnbPrepFail_CP_ Intra eNB handover preparation fails due to - -
CAPA_CAC_FAIL Capacity based CAC
IntraEnbPrepFail_CP_ Intra eNB handover preparation fails due to Air - -
QOS_CAC_FAIL QoS based CAC
IntraEnbPrepFail_S1A Intra eNB handover preparation fails due to - -
P_CU_FAIL the S1AP specification cause
P_LINK_FAIL the S1 SCTP link failure
P_SIG_FAIL receiving S1AP signaling
Intra eNB handover fails due to call control - -
IntraEnbFail_CP_CC_
timeout in the protocol blocks (MAC, RLC,
TO
PDCP, GTP)
Intra eNB handover fails due to reset - -
IntraEnbFail_CP_CC_
notification (eNB failure or block restart) from
FAIL
IntraEnbFail_UP_GTP Intra eNB handover fails due to the failure in - -
_FAIL the GTP block
IntraEnbFail_UP_MAC Intra eNB handover fails due to the failure in - -
_FAIL the MAC block

Feature Description
(Continued)
Default
Counter Description Range
Value
IntraEnbFail_UP_RLC Intra eNB handover fails due to the failure in - -
_FAIL the RLC block
Intra eNB handover fails due to HO - -
IntraEnbFail_RRC_HC
preparation timeout (not received HO
_TO
command)
IntraEnbFail_RRC_SI Intra eNB handover fails due to receiving - -
G_FAIL RRC signaling
IntraEnbFail_S1AP_C Intra eNB handover fails due to the S1AP - -
U_FAIL specification cause
IntraEnbFail_S1AP_LI Intra eNB handover fails due to the S1 SCTP - -
NK_FAIL link failure
IntraEnbFail_S1AP_SI Intra eNB handover fails due to receiving - -
G_FAIL S1AP signaling
Time taken from transmitting the - -
RRCConnectionReconfiguration message to
IntraHOTime the UE until after receiving the
RRCConnectionReconfiguration Complete
IntraHOTimeMax Average maximum intra HO interrupt time - -
IntraHOTimeTot Sum of intra HO interrupt time - -
IntraHOTimeCnt Count of IntraHOTime collected - -
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW2012, Service based Handover from LTE to

UTRAN
Overview
Introduction
The UE can use a variety of services such as Voice over LTE, Web, or FTP in the LTE
network. Because each service has a different feature, it is necessary to use a different
UTRAN inter-RAT handover policy depending on the service.
Benefits
 Operator can differentiate LTE to UTRAN mobility control policy for each service.
Release History
SLR 2.4

 Dependency:
− UE, EPC, UTRAN
 Limitation:
− Up to 5 mobility profiles are allowed.
− The QCI 5 is the default mobility profile.
Feature Scope
R1 The eNB should provide a mobility profile that has inter-RAT handover related policy
to the UTRAN in the following LTE.
− Preferred target carrier frequencies for UTRAN (FDD or TDD)
− Handover triggering event
− Measurement configuration
− Blind redirection option
R2 The eNB should provide up to 5 mobility profiles of R1. (Group #0: General calls,
Group #1-4: Specific QCI calls)
R3 The eNB should be able to set up QCI for each QCI or mobility profile.
R4 The priority for each QCI can be set by operator to select a mobility profile.
R6 The eNB should be able to process UTRAN mobility according to the QCI mobility
profile of a moving UE.
R5 The eNB should be able to process UTRAN measurement configuration according to
the QCI mobility profile of a moving UE.

Feature Description
Reference
None

Feature Description
Feature Description
Operation Scenario
The operator sets the parameters required for inter-RAT handover to the UTRAN in the
service based LTE.
Provisioning/Parameter Settings for Service based Handover from LTE to UTRAN
Appropriate mobility profile is allocated to each QCI. Below table shows an example of
mobility profile allocation according to QCI. The Mobility Profile 0 is the default
configuration, which is allocated to the QCI that does not belong to Mobility Profile 1-4.
For QCI 5, Mobility Profile 0 is allocated instead of Mobility Profile 1-4.
Below table is example of Mobility Profile Allocation for each QCI.
Mobility Profile Mobility Pr Mobility Pr Mobility Mobility

Mobility Profile 0
# ofile 1 ofile 2 Profile 3 Profile 4
Default
QCIs allocated
configuration No allocated
to each mobility QCI 1 QCI 2,3,4 QCI 7,8,9
(Default value per QCI
group
QCI)
Mobility control related items are set for each mobility profile as shown below.
 Preferred target carrier frequencies for E-UTRAN (FDD or TDD)
 Handover triggering event
 Measurement configuration
 Blind redirection option
If the UE has several QCIs, a mobility profile is allocated to the QCI with the highest
priority. For this, the operator can set priority per QCI as shown in below table.
Below table is example of Priority Allocation per QCI.

QCI# 0 1 2 3 4 5 6 7 8 9
Priority 9 2 4 3 5 1 6 7 8 9
Determine a mobility profile that will be applied to a UE based on the QCI of a bearer that
is used by the UE. Therefore, a different handover policy can be applied per QCI. The
operational scenario is described below.
For example, UE A and UE B have QCI 1 and QCI 9 respectively and mobility profile per
QCI is set as shown in below table. That is, Mobility Profile 1 is allocated to UE A and
Mobility Profile 2 is allocated to UE B. In this case, if a handover to the UTRAN is not set
for Mobility Profile 1 and a preferred carrier is set to the UTRAN for Mobility Profile 2,
UE A does not handovers to the UTRAN and UEB handovers to the UTRAN as shown in
below figure.
Below table is example of Mobility Profile Allocation for each QCI that is Set in the UE.

Feature Description
UE A B
QCI 1 9
Mobility Profile Mobility Profile 1 Mobility Profile 2
Below figure is example of service based intra-LTE handover.

Feature Description
System operation
Command Description
Retrieves the UTRAN neighboring cell information near the eNB. Enter the
RTRV-NBR- CELL_NUM and RELATION_IDX parameter values to retrieve only the specified
UTRAN UTRAN neighboring cell information. If no CELL_NUM or RELATION_IDX
parameter values are entered, all UTRAN cell information is retrieved
Changes the UTRAN neighboring cell information near the eNB. Enter the
CHG-NBR-
CELL_NUM and RELATION_IDX parameter values to change the UTRAN
UTRAN
This command is used to create the UTRAN neighbor cell information near the
CRTE-NBR- eNB. It uses the CELL_NUM and RELATION_IDX parameter values to create
UTRAN the UTRAN neighboring cell information. Any parameters not entered are set to
the default values.
Deletes the UTRAN neighboring cell information near the eNB. Enter the
DLT-NBR-
UTRAN
Retrieves the UTRA FA priority information.It can retrieve only the UTRAN FA
RTRV-UTRA- object registered with a specific E-UTRAN served cell.
FA If no CELL_NUM or FA_INDEX parameter value is entered, all UTRAN FA
Changes the UTRA FA priority information.It uses the Cell Num and fa Index
CHG-UTRA-
parameter values to change the UTRAN FA information registered with a specific
FA
cell within the eNB.
Default
Value
cellNum No. of a cell to change - -
relationIdx The DB index of the UTRAN neighbor cell. - -
Indicates whether the information on the UTRAN - -
status
RNC ID of the UTRAN neighbor cell located near - -
rncId
the eNB.

Feature Description
(Continued)
Default
Value
cId ID of the UTRAN neighbor cell located near the eNB - -
Location Area Code of a UTRAN neighbor cell that is - -
lac
located around a base station
The routing area code of the UTRAN neighbor cell - -
rac
PLMN information (MCC) of the UTRAN neighbor - -
mcc0[4] cell located near the eNB. Enter a 3-digit number
PLMN information (MNC) of the UTRAN neighbor - -
mnc0[4] cell located near the eNB. Enter a 3-digit or 2-digit
number whose each digit is between 0 and 9.

Feature Description
(Continued)
Default
Value
PLMN information (MNC) of the UTRAN neighbor cell - -
mnc5[4] located near the eNB. Enter a 3-digit or 2-digit number
Duplex type information of the UTRAN neighbor cell - -
duplexType
The primary scramble code of the UTRAN neighbor cell - -
pScmCode
Cell parameter ID information of the UTRAN neighbor cell - -
cellParaId
located near the eNB. (for TDD)
Uplink ARFCN (Absolute Radio Frequency Channel - -
arfcnUl Number) of the UTRAN neighbor cell located near the
eNB.(for FDD)
Downlink ARFCN (Absolute Radio Frequency Channel - -
arfcnDl
Number) of the UTRAN neighbor cell located near the eNB
Whether to be able to delete a neighbor cell in a base - -
station using the Automatic Neighbor Relation (ANR)
isRemoveAllo
function.
wed
- True: Can delete.
Whether to perform handover to a specific UTRAN - -
neighbor cell.
isHOAllowed
rimStatus Indicates the RIM connection status. - -
Indicates whether the relevant UTRAN neighbor cell - -
supports the VoIP.
voipIncapable
- True: VoIP is supported
Indicates whether the relevant GERAN neighbor cell - -
supports the RIM.
rimSupport
Field that indicates a specific neighbor is allocated - -
ownerType
through which procedure.
UTRA frequency index. Can set up max. 6 FAs for each - -
FA_INDEX
cell.
Validity of UTRA FA. - -
STATUS - N_EQUIP: Not valid.
- EQUIP: Valid.

Feature Description
(Continued)
Default
Value
Duplex mode information of a cell. The duplex modes of a - -
DUPLEX_TYP cell are FDD and TDD.
E - ci_FDD: Frequency Division Duplex.
The Uplink UTRA Absolute Radio Frequency Channel - -
UARFCN_UL
Number
The Downlink UTRA Absolute Radio Frequency Channel - -
UARFCN_DL
Number
PRIORITY Priority information for the UTRA FA. - -
The threshold used by the UE when reselecting the - -
THRESH_XHI
GH
frequency
THRESH_XLO The threshold used to reselect the low-priority frequency - -
W from the high-priority frequency
Q_RX_LEV_M - -
Min. RX level required in a cell. The unit is dBm.
IN
P_MAX_UTRA Maximum RF output power of the UE. - -
The minimum quality level required by the UTRA FDD - -
Q_QUAL_MIN
cell.
OFFSET_FRE - -
The offset value applied to the UTRA carrier frequency.
Q
The threshold used by the UE when reselecting the - -
THRESH_XHI
GH_QREL9
THRESH_XLO In the Rel-9, the threshold used to reselect the low-priority - -
W_QREL9 frequency from the high-priority frequency

Feature Description
Related Counters
Use LSM
RatOutAttUTRAN LTE to inter-RAT UTRAN handover attempt count.
statistics
RatOutPrepSuccUTR LTE to inter-RAT UTRAN handover preparation Use LSM
AN success count. statistics
LTE to inter-RAT UTRAN handover execution Use LSM
RatOutSuccUTRAN
success count. statistics
RatOutPrepFailUTRA Preparation fails due to eNB or block fault during Use LSM
N_CP_CC_FAIL the UTRAN handover preparation. statistics
RatOutPrepFailUTRA Preparation fails due to S1AP specification cause Use LSM
N_S1AP_CU_FAIL during the UTRAN handover preparation. statistics
RatOutPrepFailUTRA Preparation fails due to S1 SCTP link failure during Use LSM
N_S1AP_LINK_FAIL the UTRAN handover preparation. statistics
Preparation fails due to S1AP relocprep timeout
RatOutPrepFailUTRA Use LSM
(not received) during the UTRAN handover
N_S1AP_RP_TO statistics
preparation.
RatOutPrepFailUTRA Preparation fails due to receiving S1AP signaling Use LSM
N_S1AP_SIG_FAIL during the UTRAN handover preparation. statistics
RatOutFailUTRAN_CP A call is released due to Call Control Timeout of a Use LSM
_CC_TO protocol block during UTRAN handover execution. statistics
RatOutFailUTRAN_CP A call is released due to eNB or block fault during Use LSM
_CC_FAIL the UTRAN handover execution. statistics
RatOutFailUTRAN_UP A call is released due to the failure in the GTP block Use LSM
_GTP_FAIL during the UTRAN handover execution. statistics
RatOutFailUTRAN_UP A call is released due to the failure in the MAC block Use LSM
_MAC_FAIL during the UTRAN handover execution. statistics
RatOutFailUTRAN_UP A call is released due to the failure in the PDCP Use LSM
_PDCP_FAIL block during the UTRAN handover execution. statistics
RatOutFailUTRAN_UP A call is released due to the failure in the RLC block Use LSM
_RLC_FAIL during the UTRAN handover execution. statistics
RatOutFailUTRAN_R A call is released due to receiving RRC signaling Use LSM
RC_SIG_FAIL during the UTRAN handover execution. statistics
RatOutFailUTRAN_S1 A call is released due to the S1AP specification Use LSM
AP_CU_FAIL cause during the UTRAN handover execution. statistics
RatOutFailUTRAN_S1 A call is released due to the S1 SCTP link failure Use LSM
AP_LINK_FAIL during the UTRAN handover execution. statistics
A call is released due to S1AP relocoverall timeout
RatOutFailUTRAN_S1 Use LSM
(not received) during the UTRAN handover
AP_RP_TO statistics
execution.

Feature Description
(Continued)
RatOutFailUTRAN_S1 A call is released due to receiving S1AP signaling Use LSM

AP_SIG_FAIL during the UTRAN handover execution. statistics
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW2102, eNB Overload control (Adaptive

Access Barring)
Overview
Introduction
The two main factors to increase the load of the eNB are the increase of the user traffic and
the increase of the number of signaling messages. If the user traffic is increased, the pack
drop occurs by the buffer overflow and the quality of service experience of the users goes
down drastically. If the number of signaling messages is increased, the CPU load of eNB
main board is on rise and therefore the service quality may be deteriorated by increasing
the call setup time, etc. In the worst case, the system may be shut down. The eNB overload
control function prevents the system from being shut down by reducing the number of
signaling messages occurring from the phone if the CPU load is increased.
Samsung eNB uses the access barring function defined in the standard to reduce the
amount of signaling messages flowing in from the phone. The 3GPP standard (TS36.331)
defines to set access probability and access limit time information for MO-signaling and
MO-data to a SIB Type 2 message broadcast by cell. As such, the phone stochastically
decides whether it will attempt the current call or a call after a certain period of time based
on AC-BarringInfor of SIB Type 2. The operator may reduce the amount of call attempts
flowing in at the overload in a method for setting the access probability lower and the
access limit time longer. The operator may set the access probability and the access limit
time corresponding to each CPU load state including Minor, Major, Critical, etc. When the
load level becomes minor, major or critical by monitoring the CPU load periodically, eNB
broadcasts AC-BarringInfo to all cells managed thereby. When the load of the CPU returns
to be normal, the AC-Barring information is restored to the default value and broadcast.
If the overload control function is enabled due to the occurrence of the eNB overload
situation, some users experience the increase of call setup time. Some phones may transfer
to other cells where congestion does not occur.
Another method for dealing with the call congestion situation of the eNB is to limit the
maximum number of UEs that are accommodated by the eNB. The function works
regardless of the CPU load and if the number of RRC connected users reaches the
threshold, the calls entered later are rejected. For this function, refer to LTE-SW4101
Capacity based Call Admission Control.

Feature Description
Benefits
Operator Benefits:
 Operator can reduce the number of call attempts to an overloaded eNB, which can
prevent the eNB from shutting down due to overload.
End User Benefits:

 LTE users can avoid access to an eNB under congestion.
Release History
SLR 2.2
Basic or Optional
Optional

N/A
Reference

Resource Control (RRC) protocol specification Section 6.3.1

Feature Description
Feature Description
Overview of Functions
The eNB overload control function is to reduce the amount of call attempts from the phone
by broadcasting AC-Barring information if it reaches the load level set by the operator due
to the increase of the CPU load of the main board. For this, the eNB monitors the CPU load
periodically and confirms that the load level as the result of monitoring reaches that
including minor, major or critical set by the operator. If the CPU load level is changed, the
AC-Barring information corresponding to the load level is reflected to the SIB Type2
message to broadcast the information to each cell managed by the eNB.
Standard for Deciding and Changing Loads

The eNB measures the CPU load every 3 seconds and checks whether the mean value
recently measured 5 times exceeds the load level threshold set by the operator.
The operator may set each threshold to three load levels including minor, major, and
critical. If the mean value recently measured five times is kept to less than the threshold for
one minute, it releases the alarm of the current level and goes off the alarm of the lower
level.

Feature Description
Load Level and AC-Barring Information Setting

As shown in the following table, the operator may set each access level for emergency call,
signaling call and data call by CPU load level. To set the access level for the emergency
call, ac-BarringForEmergency may select either value: Barred or Not_Barred.
Ac-BarringForMO-Signaling and ac-BarringForMO-Data may set ac-BarringFactor and
ac-BarringTime, respectively. Ac-BarringFactor decides which percentage of the phones
will be statistically allowed, and ac-BarringTime decides after which seconds the phone
can attempt a call. For example, this is a concept that if ac-BarringFactor is set to be 90 %,
and ac-BarringTime to be 16 seconds, 90 out of 100 phones in the coverage are allowed to
immediately attempt calls and the other 10 % attempt calls after 16 seconds.
The example of setting AC Barring parameter by overload level is as follows:
CPU Load Level

AC Barring Parameters (SIB Type2)
Critical Major Minor Normal
ac-BarringForEmergency Barred Not Barred Not Barred Not Barred
ac-BarringForMO- ac-BarringFactor 0% 90 % 95 % -
Signalling
ac-BarringTime 128s 32s 16s -
ac-BarringForMO- ac-BarringFactor 0% 70 % 80 % -
Data
ac-BarringTime 128s 32s 16s -
If the phone generates a random number between 0 and 1 at the time that the phone
attempts a call and the number is smaller than ac-BarringFactor, the phone attempts the call
immediately and if the random number is larger than ac-BarringFactor, the phone waits for
as long as ac-BarringTime and then attempts a call.
ac-BarringForMO-Signalling corresponds to Attach, Tracking Area Update, or Detach
messages and acBarringForMO-Data is a parameter applied to the Service Request
message or the Extended Service Request message.

Feature Description
Feature Scope
 The eNB monitors CPU loads periodically and decides them into three levels: minor,
major and critical. The load level must be as same as the CPU alarm generating level
of OAM.
 The operator must set and change the load thresholds corresponding to minor, major,
and critical.
 If the CPU load level is changed, the eNB automatically changes each parameter value
of ac-BarringForEmergency, ac-BarringForMO-Signalling, and ac-BarringForMO-
Data corresponding to the level, and the changed value must be broadcast to all cells
managed by the eNB.
 The operator must set and change the values of ac-BarringForEmergency, ac-
BarringForMO-Signalling, and ac-BarringForMO-Data.
 The eNB overload control function must allow the operator to enable or disable.

Feature Description
System Operation
After the setting command relating to the eNB overload control selects Target in the CLI of
the LSM, it may be selected in Command Tab. or search a corresponding command in
Search Tab. to use. The commands used for eNB overload control-related setting are as
follows:
CHG-BAR- CELL_NUM Changes the access barring

PARA BARRING_STATUS_TYPE parameter information according
BARRING_SIGNAL_USAGE to the CPU status within the
ACC_PROB_FAC_SIGNAL base station Possible to set ac-
ACC_CLASS_BAR_TIME_ BarringforMO-Signaling, ac-
SIGNAL BarringforMO-Data, ac-
BARRING_DATA_USAGE BarringForEmergency, etc.
ACC_PROB_FAC_DATA
ACC_CLASS_BAR_TIME_
DATA
ACCESS_BARRING_EMERGENCY_CALL
RTRV-BAR- - This command retrieves the
PARA access barring parameter
information according to the
CPU status within the base
station.
CHG-ALM-THR - UNIT_TYPE: Unit type where the alarm is This command changes the
generated threshold of the overload alarm
- ALARM_TYPE: Alarm type of the eNB. The operator can
- THR_CRI_DEC: Critical level triggering change alarm thresholds using
threshold this command.
- THR_MAJ_DEC: Major level triggering If the eNB exceeds the changed
threshold threshold, it displays an alarm
- THR_MIN_DEC: Minor level triggering with the relevant severity on the
threshold operator screen. Use the RTRV-
- THR_CRI_CLR: Critical level clearing ALM-THR command to check
threshold the changed alarm threshold.
- THR_MAJ_CLR: Major level clearing The input information to execute
threshold the command is as follows:
- THR_MIN_CLR: Minor level clearing
threshold

Feature Description
(Continued)
RTRV-ALM- - UNIT_TYPE: Unit type where the alarm is This command retrieves
THR generated the threshold of the
- ALARM_TYPE: Alarm type overload alarm set in
- ALARM_CODE: Unique code allocated to each the eNB. When this
alarm command is executed,
- THR_CRI_DEC: Critical level triggering threshold the following
- THR_MAJ_DEC: Major level triggering threshold information is displayed:
- THR_MIN_DEC: Minor level triggering threshold
- THR_CRI_CLR: Critical level clearing threshold
- THR_MAJ_CLR: Major level clearing threshold
- THR_MIN_CLR: Minor level clearing threshold
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW3001, SW3002, SW3003, AM, UM and TM

Data Transfer at RLC Layer
Overview
eNB supports three different data transfer modes at RLC layer; Acknowledged Mode(AM),
Unacknowledged Mode(UM) and Transparent Mode(TM). TM is used to transfer RRC
signaling messages without RLC overhead. AM, which allows retransmission, is used for
reliable data transfer and UM is used for delay sensitive data transfer. Operator can
configure a transfer mode AM or UM per QCI.
Introduction
The eNB uses the Radio Link Control (RLC) protocol in the radio link section according to
the 3GPP TS36.322 specification to transmit data to a UE. The Samsung eNB support 3
data transmission mode of RLC, i.e. Acknowledged Mode (AM), Unacknowledged Mode
(UM), and Transparent Mode (TM).The TM does not attach a RLC header to reduce
overload in the radio section and this is used to send the signaling message of RRC.
The UM mode is a simple transmission method that does not receive acknowledge from a
UE. This is used to support delay sensitive service such as voice packet rather than
reliability sensitive. The AM mode is a packet transmission method that checks the
reception of a packet that is sent to a UE by the eNB and supports re-transmission for a lost
packet. The same method is used when the UE sends data to the eNB.
Usually, the AM mode is used for Internet connection service or file transmission service
and the UM mode is used for voice packet or eMBMS packet. The operator can set up
whether to use the AM mode or UM mode for each QCI.
The RLC connection is disconnected when a UE goes through handover when it moves
between cells or eNBs. It must be set up again once the UE moves to a target cell.
In the AM mode, there is no packet loss during transmission because the packet is
forwarded from a source cell to a target cell. However, in the UM mode, there may be
packet loss because there is no forwarding to a target cell.
Benefits
 RLC AM provides a reliable data transfer between eNB and UE.
 RLC UM allows a simple data transfer for delay sensitive packets.
 RLC TM removes RLC overhead to save radio resources.
Release History

Feature Description

Dependency:
 None
Limitation:
 None
Reference
2) 3GPP TS36.322 Evolved Universal Terrestrial Radio Access (E-UTRA): Radio Link
Control(RLC) protocol specification
Feature Scope
R1 The eNB supports the data transmission in the RLC AM, UM, or TM mode according
to 3GPP TS36.322.
R2 For a RLC AM mode bearer, its forwards a packet being transmitted to a target cell or
a packet not transmitted to a target cell if a UE moves between cells or eNBs to
prevent packet loss.
R2 The operator can configure which mode (AM mode or UM mode) to apply for each
QCI.

Feature Description
Feature Description
The RLC is a link layer protocol that is located between the PDCP layer and MAC layer
and it is applied to the radio link section between UE and eNB. The RLC is working in
Acknowledged Mode (AM), Unacknowledged Mode (UM), or Transparent Mode (TM)
depending on service property.
 The AM supports the ARQ function that checks the reception of a packet and also the
packet re-transmission function to guarantee reliability. It is used for a service where
delay-robustness and data reliability are important such as FTP or Internet connection.
 The UM has no data re-transmission function and it is used to quickly send delay
sensitive packets in real-time. The most common application is VoLTE.
 The TM sends the SDU received from its upper layer without a RLC header to reduce
the overload of radio section. The RLC element sends a reliable data through data
error correction and flow control by interoperating with an upper PDCP element and a
lower MAC/PHY.
The signalling message sent to the UE from the RRC is transmitted through Signaling
Radio Bearer (SRB) in the TM mode. And the user data sent to the DRB through the PDCP
is transmitted in the AM or UM mode. The operator can configure which mode will be
used for each QCI through the LSM. Usually, the default bearer is set to the AM mode and
the bearer that sends a VoLTE packet is set to the UM mode.
Below are the functions the RLC provides.
 AM, UM, TM data transfer
 Error correction through ARQ (AM)
 Segmentation of RLC SDU according to the size of TB
 Resegmentation when necessary (AM): Refragmentation if the TB size is changed in
according to retransmission or change of wireless environment
 Concatenation and reassembly of RLC SDUs (UM and AM)
 Concatenation of SDUs for the same radio bearer
 In-sequence delivery of upper layer PDUs except uplink PDUs during handover. (UM
and AM)
 Duplicate detection (UM and AM)
 RLC SDU discard (UM and AM)
 RLC re-establishment
 Protocol error detection (AM)
Also, the RLC provides the packet buffer function. For a UE, if the speed at which the eNB
receives from the SGW is higher than the speed at which the eNB transmits through the
radio link, packets will be buffered in the RLC of eNB.
The RLC configuration information including transmission mode per bearer is transmitted

Feature Description
through the signaling message between UE and eNB.
The most outstanding features of RLC AM mode for reliable data transmission are the
ARQ and re-transmission functions. An AM RLC entity can poll its peer AM RLC entity in
order to trigger STATUS reporting at the peer AM RLC entity, which is done by including
the poll fag in RLC data PDU. The RLC transmitting entity will include the poll flag when
there is no data to transmit or when t-PollRetransmit timer expires or when no new RLC
data PDU can be transmitted e.g. due to widow stalling. The STATUS reporting includes
positive and/or negative acknowledgemetns of RLC PDUs or portions of them.

Feature Description
System operation
RTRV-HO-OPT See the following subsection. Retrieves the handover-related

information.
RTRV-RLC-INF QCI Retrieves information required to
operate the RLC protocol. The RLC
mode per QCI, number of the AMD
PDU retransmission in the eNB and
UE, the PollByte and PollPDU settings
for poll triggering, the poll
retransmission timer, the loss
detection timer, and the STATUS_
PDU prohibit timer settings can be
retrieved.
CHG-RLC-INF QCI, RLC_MODE, Changes the parameter values
ENB_TIMER_POLL_RETRANSMIT, required to operate the RLC protocol.
ENB_POLL_PDU, The RLC mode per QCI, AMD PDU
ENB_POLL_BYTE, retransmission count in the eNB and
ENB_MAX_RETX_THRESHOLD, UE, Poll Byte and Poll PDU settings
ENB_TIMER_REORDERING, for poll triggering, Poll Retransmission
ENB_TIMER_STATUS_PROHIBIT, timer value, Loss Detection timer
UE_TIMER_POLL_RETRANSMIT, value, and STATUS_PDU Prohibit
UE_POLL_PDU, UE_POLL_BYTE, timer value can be changed.
UE_MAX_RETX_THRESHOLD,
UE_TIMER_REORDERING,
UE_TIMER_STATUS_PROHIBIT,
SN_FIELD_LENGTH
RTRV-SRB-RLC SRB_ID Retrieves the parameters required to
operate the RLC protocol.
The number of AMD PDU
retransmissions per SRB ID. PollByte
and PollPDU for poll triggering, the
poll retransmission timer, the loss
detection timer, and the STATUS_
PDU prohibit timer can be retrieved.

Feature Description
(Continued)
CHG-SRB-RLC SRB_ID, TIMER_POLL_RETRANSMIT, Changes the parameter values

POLL_PDU, POLL_BYTE, MAX_ required to operate the RLC
RETRANSMISSION_THRESHOLD, protocol. The AMD PDU
TIMER_REORDERING, TIMER_ retransmission count per SRB ID,
STATUS_PROHIBIT Poll Byte and Poll PDU settings for
poll triggering, Poll Retransmission
timer value, Loss Detection timer
value, and STATUS_PDU Prohibit
timer value can be changed.
QCI QCI (QoS Class Identifier) index. See Related Commands

Range: 0~9 (for Standard QCI), 10~255
(Others)
Default: -
RLC_MODE The mode information (AM/UM) on RLC -
Range: AM_RLC, UM_BI_RLC,
UM_UNI_DL_RLC, UM_UNI_UL_RLC
Default: (QCI: Default Value)
0:AM_RLC, 1:UM_BI_RLC,
2:UM_BI_RLC, 3:UM_BI_RLC,
4:AM_RLC, 5:AM_RLC, 6:AM_RLC,
7:UM_BI_RLC, Others:AM_RLC
ENB_TIMER_ The timer to retransmit poll in a -
POLL_RETRANS transmitting AM RLC entity.
MIT Range: ci_T_PollRetransmit_ms
(5,10,15, ...., 240, 245, 250, 300, 350,
400, 450, 500)
Default: ci_T_PollRetransmit_ms50
ENB_POLL_PDU The threshold to trigger poll for pollPDU -
PDUs in an AM_RLC entity.
Range: ci_p4, ci_p8, ci_p16, ci_p32,
ci_p64, ci_p128, ci_p256, ci_pInfinity
Default: ci_p16

Feature Description
ENB_POLL_ The threshold used to trigger poll for pollByte bytes -

BYTE in an AM_RLC entity.
Range: ci_kB25, ci_kB50, ci_kB75, ci_kB100,
ci_kB125, ci_kB250, ci_kB375, ci_kB500, ci_kB750,
ci_kB1000, ci_kB1250, ci_kB1500, ci_kB2000,
ci_kB3000, ci_kBinfinity
Default: ci_kB50
ENB_MAX_RETX The threshold used to limit the number of the AMD -

_THRESHOLD PDU retransmission in a transmitting AM_RLC
entity.
Range: ci_t1, ci_t2, ci_t3, ci_t4, ci_t6, ci_t8, ci_t16,
ci_t32
Default: ci_t32
ENB_TIMER_RE The timer to detect the losses of RLC PDUs in a -

ORDERING receiving RLC entity.
Range: ci_T_Reordering_ms(0, 5, 10, 15, ...95, 100,
110, 120, ...190, 200)
Default: ci_T_Reordering_ms40
ENB_TIMER_STA The timer to prohibit the transmission of -

TUS_PROHIBIT STATUS_PDU in a receiving AM_RLC entity.
Range: ci_T_StatusProhibit_ms(0, 5, 10, 15, ... ,
245, 250, 300, 350, 400, 450, 500)
Default: ci_T_StatusProhibit_ms50
UE_TIMER_POL The timer to retransmit poll in a transmitting AM RLC -

L_RETRANSMIT entity.
Range: ci_T_PollRetransmit_ms(5, 10, 15, ..., 245,
250, 300, 350, 400, 450, 500)
Default: ci_T_PollRetransmit_ms50
UE_POLL_PDU The threshold to trigger poll for pollPDU PDUs in an -

AM_RLC entity.
Range: ci_p4, ci_p8, ci_p16, ci_p32, ci_p64,
ci_p128, ci_p256, ci_pInfinity
Default: ci_p16
UE_POLL_BYTE The threshold used to trigger poll for pollByte bytes -

in an AM_RLC entity.
Default: ci_kB50

Feature Description
(Continued)
UE_MAX_RETX_ The threshold used to limit the number of the AMD -

THRESHOLD PDU retransmission in a transmitting AM_RLC
entity.
ci_t32
Default: ci_t8
UE_TIMER_REO The timer to detect the losses of RLC PDUs in a -
RDERING receiving RLC entity.
Range: ci_T_Reordering_ms (0, 5, 10, 15, ...90, 95,
100, 110, 120, ..., 190, 200)
Default: ci_T_Reordering_ms40
UE_TIMER_STAT The timer to prohibit the transmission of -
US_PROHIBIT STATUS_PDU in a receiving AM_RLC entity.
Range: ci_T_StatusProhibit_ms (0, 5, 10, 15, ...240,
245, 250, 300, 350, 400, 450, 500)
SN_FIELD_LENG The field size of UM sequence number. -
TH Range: ci_size5, ci_size10
Default: ci_size10
SRB_ID The ID of SRB to retrieve. -
1: Information on SRB1.
2: Information on SRB2.
Range: 1~2
Default: -
TIMER_POLL_R The timer to retransmit poll in a transmitting AM RLC -
ETRANSMIT entity.
Range: ci_T_PollRetransmit_ms (5, 10, 15, ..., 240,
245, 250, 300, 350, 400, 450, 500)
Defualt: ci_T_PollRetransmit_ms45
POLL_PDU The threshold to trigger poll for pollPDU PDUs in an -
AM_RLC entity.
Range: ci_p4, ci_p8, ci_p16, ci_p32, ci_p64,
ci_p128, ci_p256, ci_pInfinity
Default: ci_pInfinity
POLL_BYTE The threshold used to trigger poll for pollByte bytes -
in an AM_RLC entity.
Default: ci_kBinfinity

Feature Description
(Continued)
MAX_RETRANS The threshold used to limit the number of the AMD -

MISSION_THRE PDU retransmission in a transmitting AM_RLC
SHOLD entity.
ci_t32
Default: ci_t32
TIMER_REORDE The timer to detect the losses of RLC PDUs in a -
RING receiving RLC entity.
Range: ci_T_Reordering_ms(0, 5, 10, 15, ... 90, 95,
100, 110, 120, ..., 190, 200)
Defualt: ci_T_Reordering_ms35
TIMER_STATUS_ The timer to prohibit the transmission of -
PROHIBIT STATUS_PDU in a receiving AM_RLC entity.
Range: ci_T_StatusProhibit_ms(0, 5, 10, 15, ....,
240, 245, 250, 300, 350, 400, 450, 500)

N/A

N/A
Related Call Faults

N/A

Feature Description
LTE-SW3011, Header Compression RoHCv1 (RTP,

UDP, IP)
Overview
Introduction
Each packet transported from EPC to UE through EUTRAN is an IP packet. Each IP packet
header contains routing related information such as a IP source address, a IP destination
address, a port number and so on. However, the IP header is not needed for several
transmission sections between UE and EPC. This is because the most of the transmission
section is a layer 2 logical link connection. Thus, even transport layer information such as
UDP, RTP header is not needed in EUTRAN. There are several non-lossy compression
algorithms available in IETF. Samsung eNB system supports 3GPP and IETF specified
RoHC (Robust Header Compression) algorithm. ROHC compresses these typical 40 bytes
overhead into only 1 or 3 bytes by placing a compressor before the L2 link, and placing a
decompressor after that link. The opposite side decompress, making a new IP/UDP/RTP
header just before being delivered to IP layer. The main application for RoHC algorithm is
VoLTE, which is a typical RTP/UDP/IP packet.
RoHC algorithm is provided by PDCP layer between eNB and UE. Upon connecting to
eNB. UE shall be able to negotiate with eNB, RoHC profile information over UE-EUTRA-
CAPABILITY message. Each RoHC profile is bearer specific, therefore the operator may
set RoHC profile for each QCI through LSM interface. We support following RoHC
profiles in this release, 0x0000 (No Compression), 0x0001 (RTP/UDP/IP), 0x0002
(UDP/IP), 0x0004 (IP) with compliant of IETF RFC 4995, RFC3095, RFC4815.
Benefits
 eNB increases user data throughput by applying RoHC to user data transmitted over
the radio link.
 When this feature is enabled for VoLTE, eNB can accommodate more VoLTE users at
the same time.
 UE can enhance throughput.
Release History
SLR 2.2
Basic or Optional
Optional

Feature Description

Dependency
 UE needs to support RoHC for header compression over the radio link.
Limitation
 This feature supports IPv4 only
Reference
1) 3GPP TS36.323 Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data
Convergence Protocol (PDCP) specification
2) IETF RFC3095 RObust Header Compression (ROHC): Framework and four profiles:
RTP, UDP, ESP, and umcompressed
3) IETF RFC3759 RObust Header Compression (ROHC): Terminology and Channel
Mapping Examples
4) IETF RFC3843-RObust Header Compression (ROHC): A Compression Profile for IP
5) IETF RFC4815-RObust Header Compression (ROHC): Corrections and Clarifications
to RFC 3095
6) IETF RFC4995 The RObust Header Compression (ROHC) Framework
7) IETF RFC4996 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-
TCP)
8) IETF RFC5225 RObust Header Compression Version 2 (ROHCv2): Profiles for RTP,
UDP, IP, ESP and UDP-Lite
Feature Scope
R1 eNB supports the header compression and decompression of IP, RTP and UDP for
IPv4 packets, which are done in PDCP layer. eNB supports RoHCv1 Profile #0, 1, 2,
and 4.
R2 eNB decides RoHC profile(s) that will be applied to a specific UE. The decision is
based on the UE-EUTRA-Capability of the UE and RoHC profiles configured per
QCI by operator.
R3 Opeartor can enable and disable RoHC feature and can configure RoHC profile(s)
that will be applied to a specific QCI if this feature is enabled.

Feature Description
Feature Description
RoHC Architecture and Configuration
PDCP is responsible for RoHC compression, and integrity protection and ciphering.
The RoHC compression is only applied to the user plane, and should not be applied to the
control plane.
User-plane protocol stack
PDCP layer functional architecture

Feature Description
In 3GPP specification following ROHC profiles are defined. Each profile can be applied to
each IPv4 and IPv6. In this release we only support following IPv4 profiles, 0x0000 (No
Compression), 0x0001 (RTP/UDP/IP), 0x0002 (UDP/IP), and 0x0004 (IP) with compliant
of IETF RFC 4995, RFC3095, RFC4815
The following table shows Header Compression protocol and Profiles
Profile Identifier Usage: Reference
0x0000 No compression RFC 4995

0x0001 RTP/UDP/IP RFC 3095, RFC 4815
0x0002 UDP/IP RFC 3095, RFC 4815
0x0003 ESP/IP RFC 3095, RFC 4815
0x0004 IP RFC 3843, RFC 4815
0x0006 TCP/IP RFC 4996
0x0101 RTP/UDP/IP RFC 5225
0x0102 UDP/IP RFC 5225
0x0103 ESP/IP RFC 5225
0x0104 IP RFC 5225
Upon connecting to eNB, UE shall be able to negotiate with eNB, RoHC profile
information over UE-EUTRA-CAPABILITY message. Each RoHC profile is bearer
specific, therefore the operator may set RoHC profile for each QCI through LSM interface.
For each bearer, maximum 16383 RoHC context sessions are supported. One thing to
worth noting is ROHC context is never transferred during handover. An operator can set
Enable/Disable RoHC for each QCI, profile list, and max RoHC Context sessions
One thing to worth noting is ROHC context is never transferred during handover.
A operator can set Enable/Disable RoHC for each QCI, profile list, and max RoHC Context
sessions.

Feature Description
RoHC Operation
RoHC is made of the two sides and two functions. The transmission side supports
Compressor function and the reception side supports Decompressor function.
The compression consists of the three states, initialization and refresh state, First order state,
and Second order state. In the beginning of the packet transmission, it starts with the
Initialization and Refresh state. The full packet is sent several times during this state, and
then state transits to First Order state followed by Second order state accordingly.
In the case of the mismatch of the state happen, due to the change of the header information,
the compressor in the eNB side begins to transmit full header to synchronize the context
state. There are currently three mode of the operations are defined, Unidirectional mode,
Bidirectional optimistic mode, Bidirectional Reliable mode. Detailed RoHC operation is
described in following specifications, RFC4995, RFC3095, and RFC4815.
Compressor and Decompressor for RoHC
Compressor States of Unidirectional Mode Compressor States of Bidirectional Reliable Mode

Feature Description
According to RFC 3095 the ROHC scheme has three modes of operation: the
Unidirectional, the Bidirectional Optimistic, and the Bidirectional Reliable mode.
In the Unidirectional mode of operation, packets are only sent in one direction: from
compressor to decompressor. This mode therefore makes ROHC usable over links where a
return path from decompressor to compressor is unavailable or undesirable.
The Bidirectional Optimistic mode is similar to the Unidirectional mode, except that a
feedback channel is used to send error recovery requests and (optionally) acknowledgments
of significant context updates from the decompressor to compressor. The O-mode aims to
maximize compression efficiency and sparse usage of the feedback channel.
The Bidirectional Reliable mode differs in many ways from the previous two. The most
important differences are a more intensive usage of the feedback channel and a stricter
logic at both the compressor and the decompressor that prevents loss of context
synchronization between compressor and decompressor except for very high residual bit
error rates.

Feature Description
The ROHC algorithm is similar to video compression, in that a base frame and then several
difference frames are sent to represent an IP packet flow. This has the advantage of
allowing ROHC to survive many packet losses in its highest compression state, as long as
the base frames are not lost. Above figures depicit a ROHC compressor and a ROHC
zqnffdecompressor. A ROHC compressor is in one of 3 main states. In Initialization and
Refresh (IR) state, the compressor has just been created or reset, and full packet headers are
sent. In First-Order (FO) state, the compressor has detected and stored the static fields
(such as IP addresses and port numbers) on both sides of the connection. The compressor is
also sending dynamic packet field differences in FO state. Thus, FO state is essentially
static and pseudo-dynamic compression. In Second-Order (SO) state, the compressor is
suppressing all dynamic fields such as RTP sequence numbers, and sending only a logical
sequence number and partial checksum to cause the other side to predictively generate and
verify the headers of the next expected packet. In general, FO state compresses all static
fields and most dynamic fields. SO state is compressing all dynamic fields predictively
using a sequence number and checksum.
For detail ROHC, please refer to RFC4995, RFC3095, RFC4815.

Feature Description
System Operation
CHG-ROHC- QCI RoHC is configured in the unit of QCI.

INF ROHC_SUPPORT This command enables operator to enable or
MAX_CONTEXT_SESSION disable RoHC, to configure the maximum
PROFILE0001 number of RoHC context session, and to set
PROFILE0002 ROHC profiles supported.
PROFILE0003 QCI Range: 0~255 (Standard QCI: 1~9)
PROFILE0004 ROHC Support: True or False
PROFILE0006 MAX_CONTEXT_SESSION: from cs2 to cs
PROFILE0101 16384 (default: ci_maxROHC_Sessions_cs16,
PROFILE0102 refer to 3GPP TS36.331)
PROFILE0103 PROFILE0001: True or False (Default: True)
PROFILE0104 PROFILE0002: True or False (Default: True)
PROFILE0003: True or False (Default: False)
PROFILE0004: True or False (Default: True)
RTRV-ROHC- QCI This command retrieves the RoHC configuration
INF of a QCI.
QCI Range: 0~255 (Standard QCI: 1~9)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW3051, Integrity Protection:

Null/SNOW3G/AES
Overview
In general, Integrity protection means protection of data against creation, alteration,
deletion, duplication, re-ordering by unauthorized entities. LTE provides Integrity
protection, and replay protection to NAS and RRC-signalling. UEs and eNBs shall
implement only, EIA0, 128-EIA1 and 128-EIA2.
Introduction
LTE provides the integrity protection, and replay protection to NAS and RRC-signalling.
TS 33.401 defines three EPS integrity algorithms, EIA0 Null Integrity Protection, 128-
EIA1 SNOW 3G, and 128-EIA2 AES. All RRC signalling messages except those explicitly
listed in TS 36.331 as exceptions shall be integrity-protected. UEs and eNBs shall
implement 128-EIA1 and 128-EIA2. UEs shall implement EIA0 for integrity protection of
RRC signalling integrity protection. EIA0 is only allowed for unauthenticated emergency
calls. Implementation of EIA0 in MMEs and eNBs is optional, EIA0, if implemented, shall
be disabled in MMEs and eNBs in the deployments where support of unauthenticated
emergency calling is not a regulatory requirement.
Benefits
 Per compliance of the data integrity discipline of communication, eNB shall ensure the
data is not modified during the transmission.
 Integrity protection, and replay protection, shall be provided to RRC-signalling.
Release History

Dependency:
 For 128-EIA2 H/W acceleration is required
Limitation:
 The integrity protection shall be provided only to NAS and RRC-signalling

Feature Description
Reference
2) TS 33401 3GPP System Architecture Evolution (SAE): Security Architecture
Feature Scope
R1 The eNB must support the Integrity Protection function by using SNOW 3G or AES
algorithm for a control plane message.
R2 The operator should be able to enable/disable the Integrity Protection function.

Feature Description
Feature Description
Each eNB shall be configured via network management with lists of algorithms as below
table (See below table) which are allowed for usage. There shall be a list for three
ciphering algorithms, Null integrity, SNOW 3G, and AES.
These lists shall be ordered according to a priority decided by the operator.
EIA Identifier EIA code Algorithm Name
0000 2 EIA0 Null Integrity Algorithm

0001 2 128-EIA1 SNOW 3G
0010 2 128-EIA2 AES
1. 128-EIA1 is based on SNOW 3G and is identical to UIA2.
2. 128-EIA2 is based on AES in CMAC mode
The agreed integrity algorithm shall provide integrity of the RRC messages at PDCP layer
as it is depicted below figure.

Feature Description
When AS security context is established in the eNB, the MME shall send the UE EPS
security capabilities to the eNB (See below call flow). The eNB shall choose the ciphering
algorithm which has the highest priority from its configured list and its also presented in
the UE EPS security capabilities. The ciphering algorithm is used for integrity of the user
plane and RRC traffic.
All algorithms specified in this subclause are algorithms with a 128-bit input key.
The input parameters to the integrity algorithm are a 128-bit integrity key named KEY, a
32-bit COUNT, a 5-bit bearer identity called BEARER, the 1-bit direction of the
transmission i.e. DIRECTION, and the message itself i.e MESSAGE. The DIRECTION bit
shall be 0 for uplink and 1 for downlink. The bit length of the MESSAGE is LENGTH.
Based on these input parameters the sender computes a 32-bit message authentication code
(MAC-I/NAS-MAC) using the integrity algorithm EIA. The message authentication code
is then appended to the message when sent. For integrity protection algorithms other than
EIA0 the receiver computes the expected message authentication code (XMAC-I/XNAS-
MAC) on the message received in the same way as the sender computed its message
authentication code on the message sent and verifies the data integrity of the message by
comparing it to the received message authentication code, i.e. MAC-I/NAS-MAC.

Feature Description
System operation
Command Description
RTRV-SECU-INF Retrieves the current preferred integrity protection and the ciphering
algorithm of the eNB.
CHG-SECU-INF Changes the preferred integrity protection algorithm and ciphering algorithm
of the eNB.
When the DB Index parameter value is set as an input value, the preferred
INTEGRITY_EA_ EIA0, EIA1, EIA1 The integrity protection algorithm

PRIOR EIA2 supported by the eNB.
- EIA0: NULL.
- EIA1: SNOW 3G.
- EIA2: AES.
CIPHER_EA_ EEA0, EEA1, EEA1 The ciphering algorithm supported by
PRIOR EEA2 the eNB.
- EEA0: NULL.
- EEA1: SNOW 3G.
- EEA2: AES.

N/A

N/A
Related Call Faults

N/A

Feature Description
LTE-SW3052, SW3053, SW3056,

Ciphering:Null/SNOW 3G/AES
Overview
Ciphering may be provided to RRC-signalling to prevent UE tracking based on cell level
measurement reports, handover message mapping, or cell level identity chaining.
RRC signalling confidentiality is an operator option. Each eNB shall be configured via
network management with lists of algorithms wich are allowed for ciphering. The eNB
shall choose the ciphering algorithm which has the highest priority from its configured list
and is also present in the UE EPS security capabilities. Confidentiality protection is subject
to national regulation. If S1 and X2 messages are not confidentiality-protected there is the
risk of exposing cryptographic keys carried in these messages. User plane confidentiality
protection shall be done at PDCP layer and is an operator option.
Introduction
An active UE and a serving network shall agree upon algorithms for RRC ciphering and
RRC integrity protection, UP ciphering, and NAS ciphering and NAS integrity protection.
The serving network shall select the algorithms to use dependent on, the UE security
capabilities of the UE, and the configured allowed list of security capabilities of the
currently serving network entity. The same set of ciphering algorithm shall be supported by
the UE both for AS and NAS level. Within the security architecture of the 3GPP system
there are standarized algorithms, EEA for the confidentiality. The SNOW 3G and AES are
two of three cipher engine for aforementioned algorithms, however in case of the
emergency case, null ciphering is also allowed by operator configuration. The default
ciphering algorithm is SNOW 3G, 128-EEA1. It provides a stream ciphering service to
control plane and bearer plane at PDCP layer.
Benefits
 Confidentiality of software transfer towards the eNB shall be ensured
 Sensitive parts of the boot-up process shall be executed with the help of the secure
environment.
 Prevent UE tracking based on cell level measurement reports
 Support privacy protection for user information
Release History
SLR 2.2

Feature Description

Dependency:
 UE shall support either SNOW 3G or AES
Limitation:
 None
Reference
2) 3GPP TS33.401 3GPP System Architecture Evolution (SAE); Security architecure
Feature Scope
R1 The eNB supports SNOW 3G ciphering function.
R2 The eNB supports the AES ciphering function.
R3 The eNB supports the null ciphering function for an emergency call or test.
R4 The operator should be able to enable/disable the functions such as Null, SNOW 3G,
or AES, etc.
Feature Description
Each eNB shall be configured via network management with lists of algorithms as below
table (See below table) which are allowed for usage. There shall be a list for three
ciphering algorithms, Null ciphering, SNOW 3G, and AES.
These lists shall be ordered according to a priority decided by the operator.
EIA Identifier EIA code Algorithm Name
0000 2 EIA0 Null Integrity Algorithm

0001 2 128-EEA1 SNOW 3G
0010 2 128-EEA2 AES
1. 128-EEA1 is based on SNOW 3G and is identical to UEA2.
2. 128-EEA2 is based on AES in CTR mode
When AS security context is established in the eNB, the MME shall send the UE EPS
security capabilities to the eNB (See below call flow). The eNB shall choose the ciphering
algorithm which has the highest priority from its configured list and its also presented in
the UE EPS security capabilities. The ciphering algorithm is used for ciphering of the user
plane and RRC traffic.

Feature Description
The agreed ciphering algorithm optionally protects RRC messages and UP traffic at PDCP
layer as it is depicted below figure.

Feature Description
The input parameters to the ciphering algorithm are a 128-bit cipher key named KEY, a 32-
bit COUNT, a 5-bit bearer identity BEARER, the 1-bit direction of the transmission i.e.
DIRECTION, and the length of the keystream required i.e. LENGTH. The DIRECTION
bit shall be 0 for uplink and 1 for downlink.
The below figure illustrates the use of the ciphering algorithm EEA with SNOW 3G/AES
cipher engine to encrypt plaintext by applying a keystream using a bit per bit binary
addition of the plaintext and the keystream. The plaintext may be recovered by generating
the same keystream using the same input parameters and applying a bit per bit binary
addition with the ciphertext.

Feature Description
System operation
Command Description
RTRV-SECU-INF Retrieves the current preferred integrity protection and the ciphering
algorithm of the eNB.
CHG-SECU-INF Changes the preferred integrity protection algorithm and ciphering algorithm
of the eNB.
When the DB Index parameter value is set as an input value, the preferred
INTEGRITY_EA_ EIA0, EIA1, EIA1 The integrity protection algorithm

PRIOR EIA2 supported by the eNB.
- EIA0: NULL.
- EIA1: SNOW 3G.
- EIA2: AES.
CIPHER_EA_PRI EEA0, EEA1, EEA1 The ciphering algorithm supported by
OR EEA2 the eNB.
- EEA0: NULL.
- EEA1: SNOW 3G.
- EEA2: AES.

N/A

N/A
Related Call Faults

N/A

Feature Description
LTE-SW4101, Capacity based Call Admission

Control
Overview
Introduction
CAC function is basically enabled.
 To efficiently use the limited radio resources.
 To guarantee the quality of user service even in case of congestion.
 To protect eNB system from being overloaded.
There are three call admission control functionalities; Capacity-based Call Admission
Control, QoS-based Call Admission Control, and Pre-emption. Capacity-based CAC makes
a decision based on the capacity that operator configures in advance, QoS based CAC
makes a decision based on the required QoS level and available radio resources of that time.
Pre-emption allows a priority call. These three functionalities work at the same time.
QoS based CAC has an effect only when MME requests GBR bearers.
Operator can configure the capacity per cell and per eNB. In order to sustain a certain level
of QoS for non-GBR services, operator can limit the maximum number of users allowed
per cell. In addition, operator can configure the amount of resources that are reserved for
incoming handover calls. In this case, the call admission algorithms make a decision based
on the capacity that reflects the reserved resources. In case of no resources, emergency
calls are allowed by preempting existing calls.
Benefits
 By limiting the maximum number UEs or bearers per cell and per eNB, considering
radio and backhaul bandwidth, operator can control the minimum QoS level provided
for UEs.
 Operator can protect the system from being shutdown due to overload or congestion.
Release History
SLR 2.2
Basic or Optional
Basic

Feature Description

N/A
Reference
1) 3GPP TS36.300, Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
2) 3GPP TS23.203, Technical Specification Group Services and System Aspects; Policy
and charging control architecture
Feature Scope
 Operator can configure the maximum number of UEs per cell and per eNB, the
number of data radio bearers per cell via LSM.
 Operator can reserve radio resources (UEs, Bearers) for handover calls.
 eNB does not allow a RRC connection or a bearer if it results in excess of a pre-
configured capacity per cell or per eNB.
 If some resources are reserved for handover calls, Capacity based CAC will make a
decision of admission within the remained resource, which excludes the reserved
resource for handover calls.

Feature Description
Feature Description
Functional Architecture for CAC
Following table shows the function architecture for call admission control. Capacity based
CAC has impact on the RRC connection establishment and E-RAB bearer establishment
while QoS based CAC and Pre-emption has impact on E-RAB bearer establishment only.
This section covers Capacity based CAC. For other two CAC features, refer to LTE-
SW4102 and LTE-SW4103.
Capacity based CAC allows an incoming call or bearer as long as the total number of
calls/bearers does not exceed the pre-configured maximum capacity per cell and eNB.
Operator can configure the system capacity for CAC via LSM. For the capacity, operator
should consider the hardware platform and radio resources, eg. radio bandwidth, the
number of channel card, QoS level. The following table shows an example in case of 10
MHz bandwidth.

Feature Description
System
Criteria (10 MHz BW) Decision
Parameters
MaxUeCELL 600 Current # of UEs of the cell < MaxUeCELL
MaxUeENB 1800 Current # of UEs of the eNB < MaxUeENB
MaxRbUE 8 Current # of bearers of the UE < MaxRbUE
MaxRbCELL 1200 Current # of bearers of the cell < MacRbCELL
For the number of UEs, eNB counts RRC connections that it keeps their context. For the
number of bearers, GBR bearers and Non-GBR bearers are counted all together. Maximum
number of radio bearers per UE, which counts only data radio bearers excluding signaling
radio bearers, is limited by MAC layer protocol specification (3GPP TS 36.321) and it is
not configurable by operator.
Operator can configure the amount of resources that are reserved for incoming handover
calls. In this case, the call admission algorithms make a decision based on the capacity that
reflects the reserved resources.
CAC and Call Procedures

RRC Connection Setup
1) During the RRC connection establishment, the eNB capacity-based CAC operates per
call. The procedure starts when the RRC connection request message is received from
the UE.
2) The eNB capacity-based CAC procedure is initiated. If the current number of UEs in
the eNB is less than MaxUeENB, the call is admitted. Otherwise, the call is rejected.
If the current number of UEs in the cell is less than MaxUeCELL, the call is admitted.
Otherwise, the call is rejected.

Feature Description
3) If the call is admitted, RRC connection establishment is initiated by transmitting the

RRC connection setup message to the UE. If the call is rejected and the call type is
emergency call, the longest call among active calls in the cell is released. For a normal
call, the RRC connection release message is transmitted to the UE and the call is
released.
4) The UE transmits the RRC Connection Setup Complete message.
E-RAB Setup
1) After the RRC establishment, the eNB capacity-based CAC operates by receiving the
initial context setup request or E-RAB setup/modify request message from the MME
for the default radio bearer and dedicated radio bearer (DRB) setup.
2) The eNB capacity-based CAC runs per E-RAB. If the current number of bearers in the
cell is less than MaxRbCELL, the call is admitted. Otherwise, the call is rejected.
3) N/A
4) If the E-RAB is successfully admitted, the RRC connection reconfiguration message is
transmitted to the UE to initiate an E-RAB (DRB) establishment. If the call is rejected,
whether to admit the E-RAB is determined in interoperation with the preemption
function per E-RAB (DRB) to control the call flow (a partial success per E-RAB is
ignored).

Feature Description
Intra-eNB Handover
1) When cell change take places within the same eNB, the eNB capacity-based CAC
operates to control intra-eNB handover call admission.
2) The eNB capacity-based CAC is initiated based on a call. If the current number of UEs
in the cell is less than MaxUeCELL, the call is admitted. Otherwise, the call is rejected.
If the current number of bearers in the cell is less than MaxRbCELL, the call is
admitted. Otherwise, the call is rejected.
3) N/A
4) If the call is admitted, the RRC connection reconfiguration message is transmitted to
the UE to initiate the intra-eNB handover. If the call is rejected, whether to admit the
E-RAB is determined in interoperation with the preemption function per E-RAB
(DRB) to control the call flow (a partial success per E-RAB is ignored).
5) The UE transmits RRC connection reconfiguration complete message.

Feature Description
Inter-eNB Handover
1) To control inter-eNB handover call admission, the eNB capacity-based CAC operates
by using the E-RAB Level QoS parameter included in the Handover Request message
received.
2) The eNB capacity-based CAC is initiated based on a call. If the current number of UEs
in the eNB is less than MaxUeENB, the call is admitted. Otherwise, the call is rejected.
If the current number of UEs in the cell is less than MaxUeCELL, the call is admitted.
Otherwise, the call is rejected. If the current number of bearers in the cell is less than
MaxRbCELL, the call is admitted. Otherwise, the call is rejected.
3) N/A
4) If the call is admitted, the Handover Request Acknowledge message is transmitted to
the source eNB to initiate the inter-eNB handover. If the call is rejected, whether to
admit the E-RAB is determined in interoperation with the preemption function per E-
RAB (DRB) to control the call flow (a partial success per E-RAB is ignored)
5) The source eNB transmits the RRC connection reconfiguration message to the UE
6) The UE transmits RRC connection reconfiguration complete message.

Feature Description
System Operation
Command Description
CHG-ENB- CHG-ENB-CAS is used to change UE (Call) Capacity of eNB, and RTRV-ENB-

CAC CAC is used to retrieve the current UE (Call) Capacity of eNB.
RTRV-ENB- In addition, Operator can change or retrieve the threshold for both normal call
CAC and handover/emergency call. The threshold is represented as a percentage of
the entire UE capacity.
CHG-CELL- CHG-CELL-CAC is used to change UE (Call) and bearer (DRB) capacity of a
CAC cell, and RTRV-CELL-CAC is used to retrieve the current capacity and threshold
RTRV-CELL- about UE (Call) and bearer (DBR) capacity of a cell. The threshold is
CAC represented as a percentage of the entire capacity that is set as maxCallCount
and maxDrbCount.
Default
Parameters Description Range
Value
callCountCacU This parameter is used to enable or disable Capacity - -
sage based CAC (Call Admission Control) functionality at
the eNB.
Range: 0 or 1
Default: 1
0: CI_no_use: disable Capacity based CAC at eNB
1: CI_use: enable Capacity based CAC at eNB
maxEnbCallCo Maximum number of calls that eNB allows. - -
unt Range: 0~MAX_CALL_COUNT_PER_SYS
Default: MAX_CALL_COUNT_PER_SYS
callCacThreshF Threshold for the maximum number of normal calls - -
orNormal that eNB allows. eNB causes ‘Capacity based CAC
Fail’ when the requested normal call exceeds
‘MAX_ENB_CALL_COUNT x CALL_CAC_THRESH_
FOR_NORMAL (%)’.
Range: 0~100 (%)
Default: 90 (%)

Feature Description
(Continued)
Default
Value
callCacThreshF Threshold for the maximum number of handover and - -
orEmerHo emergency calls that eNB allows. eNB decides
‘Capacity based CAC Fail’ when the requested
emergency call or handover call exceeds
‘MAX_ENB_CALL_COUNT x CALL_CAC_THRESH_
FOR_EMER_HO (%)’.
Range: 0~100 (%)
Default: 100
cellCountCacU This parameter enables or disables the use of call - -
sage count based CAC per cell function
Range: 0 or 1
Default: 1
0: CI_no_use: disable ‘call count based CAC per cell’
function.
1: CI_use: enable ‘call count based CAC per cell’
function.
maxCallCount The maximum number of call counts that the cell - -
allows.
Range: 0~MAX_CALL_COUNT_PER_CELL
Default: MAX_CALL_COUNT_PER_CELL
callCacThreshF Threshold for the maximum number of normal calls - -
orNormal that the cell allows. eNB decides ‘Capacity based
CAC Fail’ when the requested normal call exceeds
‘MAX_CALL_COUNT x CALL_CAC_THRESH_
FOR_NORMAL (%).’
Range: 0~100 (%)
Default: 90 (%)
callCacThreshF Threshold for the maximum number of emergency - -
orEmerHo and handover calls that the cell allows. eNB decides
emergency or handover call exceeds MAX_CALL_
COUNT x CALL_CAC_THRESH_FOR_EMER_HO
(%)’.
Range: 0~100 (%)
Default: 100 (%)

Feature Description
(Continued)
Default
Value
drbCountCacU This parameter enables or disables CAC function of - -
sage the cell which is based on the number of E-RAB.
Range: 0 or 1
Default: 1
0: CI_no_use: disable the CAC function which is
based on the number of bearers.
1: CI_use: enable the CAC function which is based
on the number of bearers.
maxDrbCount The maximum number of data radio bearers that the - -
cell allows.
Range: 0~MAX_DRB_COUNT_PER_CELL
Default: MAX_DRB_COUNT_PER_CELL
drbCacThreshF Threshold for the maximum number of normal data - -
orNormal ratio bearers that the cell allows. eNB decides
normal bearer exceeds ‘MAX_DRB_COUNT x
DRB_CAC_THRESH_FOR_NORMAL (%)’.
Range: 0~100 (%)
Default: 90 (%)
drbCacThreshF Threshold for the maximum number of emergency or - -
orEmerHo handover bearers that the cell allows. eNB decides
emergency or handover bearer exceeds MAX_DRB_
COUNT x DRB_CAC_THRESH_FOR_EMER_HO
(%)’.
Range: 0~100 (%)
Default: 100 (%)

N/A
Related Alarms
N/A
Related Status
N/A

Feature Description
Related Call Faults

RRM_MAX_CALL_ This call fault occurs when the number of calls Check resource status of
COUNT_OVER exceeds the configured capacity or threshold. eNB.
RRM_MAX_DRB_ This call fault occurs when the number of Check resource status of
COUNT_OVER bearers exceeds the configured capacity or eNB.
threshold.

Feature Description
LTE-SW4102, QoS based Call Admission Control

Overview
QoS-based CAC determines whether the eNB accepts a new bearer or not, based on the
current resource utilization and the QoS requirements of the new bearer. QoS based CAC
allows a new bearer only when the eNB can support the required QoS level without
degradation of existing GBR bearers.
Introduction
CAC function is basically enabled
 to efficiently use the limited radio resources.
 to guarantee the quality of user service even in case of congestion
 to protect eNB system from being overloaded
There are three call admission control functionalities; Capacity-based Call Admission
Control, QoS-based Call Admission Control, and Pre-emption. Capacity-based CAC makes
a decision based on the capacity that operator configures in advance, QoS based CAC
makes a decision based on the required QoS level and available radio resources of that time.
Pre-emption allows a priority call. These three functionalities work at the same time.
QoS based CAC has an effect only when MME requests a GBR bearer.
QoS based CAC admits a new GBR bearer only when the eNB can support the new GBR
bearer so that it can achieve the required bit rate. For this, QoS based CAC algorithm
considers the radio resource utilization and backhaul resource utilization of that time, and
the required bit rate of the GBR bearer as well. Introducing a new GBR bearer must not
degrade the QoS of existing GBR bearers. In order to prevent GBR bearers from over-
consuming radio resources, operator can limit the maximum amount of resources that can
be allocated to GBR bearers.
To allow new UEs to access the network, non-GBR bearers are always allowed as long as
the total number of bearers per cell does not exceed the maximum limit.
Benefits
 Operator can provide QoS guaranteed service to UEs.
 Operator can configure how much resources (PRB, backhaul bandwidth, number of
GBR bearers) can be used for GBR services.

Feature Description
Release History
SLR 2.2
SLR 3.0
Operator is enabled to configure the maximum number of GBR bearers per cell.

Dependency:
 This feature has effect when MME requests GBR bearers.
Limitation:
 None
Reference
2) 3GPP TS36.203 Policy and charging control architecture
3) 3GPP TS23.401 General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access, Section 4.7
4) 3GPP TS24.301 Non-Access-Stratum (NAS) protocol for Evolved Packet System
(EPS); Stage 3, Section 9.9.4.3
Feature Scope
R1 eNB allows a E-RAB bearer only when it can support the required QoS in terms of
PRB usage, without QoS degradation of existing GBR bearers.
R2 Operator can configure the amount of PRBs per cell that can be allocated to GBR
bearers.
R3 Operator can configure the amount of backhaul bandwidth that can be used by GBR
bearers.
R4 Operator can configure the number of bearers per cell that can be used for the purpose
of GBR services. (SLR3.0)
R5 eNB allows a GBR bearer within the resources pre-configured by operator.

Feature Description
Feature Description
Following table shows a function architecture for call admission control. Capacity based
This section covers QoS based CAC. For other two CAC features, refer to LTE-SW4101
and LTE-SW4103.
QoS based CAC admits a new GBR bearer ony when it is expected to achieve its
guaranteed bit rate requirement under the radio condition of that time. Additional
admission of a new GBR bearer must not degrade the QoS level of existing GBR bearers.
For this, eNB monitors the PRB usage and backhaul bandwidth utilization that exsiting
GBR bearers are consuming. eNB makes an admission decision based on these resources
utilizations of that time and the QoS level required by the new GBR bearer.
Practically, GBR bearers are not liley to consume all the reserved resource as much as the
guaranteed bit rate they require. Therefore, the estimation of expected throughput is
computed based on the actual average throughput of the existing GBR bearers with the
same QCI that the new GBR bearer requires. This allows eNB to accommodate more GBR
bearers. Note that GBR bearers with the same QCI are assumed to use the same service and
to consume the similar level of throughput.
QoS based CAC algorithm applies only to GBR bearers. Non-GBR bearers are always
allowed as long as the total number bearers per UE and per Cell do not exceed the
maximum limit, which is not to hinder a UE’s access to the network because it must
establish at least one default non-GBR bearer to attach to the network.

Feature Description
As eNB allows more GBR bearers, less resources can be allocated to non-GBR bearers.
It will degrade quality of user experience of UEs who have non-GBR bearers. In order to
sustain a certain level of service quality for non-GBR services, operator can limit the
amount of resources that can be allocated to GBR bearers or the total number of UEs.
For this, operator can configure following system parameters. eNB allows GBR bearers
within the amount of resources configured by operator.
 The amount of PRBs that can be allocated to GBR bearers
 The amount of backhaul bandwidth that can be allocated to GBR bearers
 The maximum number of GBR bearers (SLR3.0)
CAC and Call Procedures

A. RRC Connection Setup
QoS based CAC is not used in RRC Connection Setup procedures but Capacity based CAC
is used.
B. E-RAB Setup
1) After the RRC Establishment procedure, the Initial Context Setup Request message or
the E-RAB Setup/Modify Request message is received from the MME to set up the
default radio bearer and the dedicated radio bearer (hereafter, DRB). Then, the eNB
capacity-based CAC and the QoS-based CAC are performed sequentially to determine
whether to admit the call.
2) The eNB capacity-based CAC is initiated per E-RAB. If ‘Current # of bearers of the
cell < MaxRbCELL’ is satisfied, the call is admitted. If not, the call is rejected.
3) When the E-RAB has the GBR, the QoS-based CAC is initiated. If the PRB usage of
the cell satisfies ‘CurrentGbrPrbUsage + ExpectedPrbUsage < MaxGbrPrbUsage’, the
call is admitted. If not, the call is rejected. If the Backhaul BW satisfies
‘CurrentGbrBwUsage + ExpectedBw < MaxGbrBw’, the call is admitted. If not, the
call is rejected.

Feature Description
If the E-RAB is admitted, the RRC Connection Reconfiguration message is

transmitted to the UE to perform the E-RAB (DRB) Establishment procedure. If a call
is rejected, the CAC function determines whether to admit E-RAB by interworking
with the preemption function per E-RAB (DRB) to control the flow of each call.
(Partial success per E-RAB is not considered.)
C. Intra-eNB Handover
1) When a cell change occurs in the same eNB, the intra-eNB handover CAC is initiated
using the eNB capacity-based CAC and the QoS-based CAC.
2) The call-based eNB capacity-based CAC is initiated. If ‘Current # of UEs of the cell <
MaxUeCELL’ is satisfied, the call is admitted. If not, the call is rejected. If ‘Current #
of bearers of the cell < MaxRbCELL’ is satisfied, the call is admitted. If not, the call is
rejected.
3) When the E-RAB has the GBR, the QoS-based CAC is initiated. If the PRB usage of
the target cell satisfies ‘CurrentGbrPrbUsage + ExpectedPrbUsage <
MaxGbrPrbUsage’, the call is admitted. If not, the call is rejected.
4) If the call is admitted, the RRC Connection Reconfiguration message is transmitted to
the UE to perform the Intra-eNB Handover procedure. If the call is rejected, the CAC
function controls the flow of each call by interworking with the preemption function
per E-RAB (DRB) determining whether to admit E-RAB. (Partial success per E-RAB
is not considered.)
5) The RRC Connection Reconfiguration Complete message is received from the UE.

Feature Description
D. Inter-eNB Handover
1) The Inter-eNB Handover CAC is initiated when the handover request message is
received. The eNB capacity-based CAC and the QoS-based CAC are initiated by
referring to the E-RAB Level QoS parameter included in the handover request
message.
2) The call-based eNB capacity-based CAC is initiated. If ‘Current # of UEs of the eNB
< MaxUeENB’ is satisfied, the call is admitted. If not, the call is rejected. If ‘Current #
of UEs of the cell < MaxUeCELL’ is satisfied, the call is admitted. If not, the call is
rejected.If ‘Current # of bearers of the cell < MaxRbCELL’ is satisfied, the call is
admitted. If not, the call is rejected.
3) When the E-RAB has the GBR, the QoS-based CAC is initiated. If the backhaul BW
satisfies ‘CurrentGbrBwUsage + ExpectedBw < MaxGbrBw’, the call is admitted.
If not, the call is rejected. If the PRB usage of the target cell satisfies
‘CurrentGbrPrbUsage + ExpectedPrbUsage < MaxGbrPrbUsage’, the call is admitted.
If not, the call is rejected.
4) If the call is admitted, the Handover Request Acknowledge message is transmitted to
the system to perform the Inter-eNB Handover procedure. If the call is rejected, the
CAC function controls the flow of each call by interworking with the preemption
function per E-RAB and determining whether to admit E-RAB. (Partial success per E-
RAB is not considered.)
5) The RRC Connection Reconfiguration message is transmitted to the UE.
6) The RRC Connection Reconfiguration Complete message is received from the UE.

Feature Description
SYSTEM OPERATION
Commands and Paramters
Command Description
RTRV-QCAC-PARA Retrieves/Changes the active QoS (Quality of Service) CAC (call

CHG-QCAC-PARA admission control) parameter in the eNB. QoS CAC is performed at the
cell level, for QCI of each GBR bearer. Retrieves the threshold by QCI for
performing QoS CAC and retrieves the threshold for determining
congestion state of the active cell.
RTRV-QCACQ-PARA Retrieves/Changes the active QoS (Quality of Service) CAC (call
CHG-QCACQ-PARA admission control) parameter in the eNB. QoS CAC is performed at the
cell level, for QCI of each GBR bearer. Changes the threshold by QCI for
performing QoS CAC and retrieves the threshold for determining
congestion state of the active cell. (by QCI)
RTRV-CELL-PARA Retrieves the CAC (call admission control) parameter information of the
cells operating within the eNB.
As cell-level CACs, backhaul based CAC, call count based CAC, DRB
count based CAC, and QoS based CAC are performed.
Command Parameter Range Description
CHG-QCAC- DL_GBRUSAGE_ 0~100 The threshold of downlink calls that can be

PARA THRESH_NORM assigned per cell. It is used when a new call is
AL requested. It is calculated as ‘PRB percentage’.
When a new call is requested, if the downlink GBR
PRB usage exceeds this parameter value, the QoS
CAC Fail is generated.
DL_GBRUSAGE_ 0~100 The threshold of downlink Handover calls that can
THRESH_HO be assigned per cell. It is used when a Handover
call is requested. It is calculated as ‘PRB
percentage. When a Handover call is requested, if
the downlink GBR PRB usage exceeds this
parameter value, the QoS CAC Fail is generated.
UL_GBRUSAGE_ 0~100 The threshold of uplink calls that can be assigned
THRESH_NORM per cell. It is used when a new call is requested.
AL It is calculated as ‘PRB percentage’. When a new
call is requested, if the uplink GBR PRB usage
exceeds this parameter value, the QoS CAC Fail is
generated.

Feature Description
(Continued)
CHG-QCAC- UL_GBRUSAGE 0~100 The threshold of uplink Handover calls that can
PARA _THRESH_HO be assigned per cell. It is used when a Handover
call is requested. It is calculated as ‘PRB
percentage’. When a Handover call is requested,
if the uplink GBR PRB usage exceeds this
CHG- qci 0~225 QCI index. The standard QCIs defined in the
QCACQ- standard documents is 1 to 9. The user can use
PARA QCI values 0 and 10-255.
DL_QCIUSAGE 0~100 The threshold of Downlink calls that can be
_THRESH_NOR assigned per QoS Class Identifier (QCI). It is
MAL used when a new call is requested. It is
calculated as PRB percentage. When a new call
is requested, if the downlink GBR PRB usage
exceeds this parameter value, the QoS CAC Fail
is generated.
DL_QCIUSAGE 0~100 The threshold of Downlink Handover calls that
_THRESH_HO can be assigned per QoS Class Identifier (QCI).
It is used when a Handover call is requested.
It is calculated as PRB percentage.
When a Handover call is requested, if the
downlink GBR PRB usage exceeds this
CHG- UL_QCIUSAGE 0~100 The threshold of Uplink calls that can be
QCACQ- _THRESH_NOR assigned per QoS Class Identifier (QCI).
PARA MAL It is used when a new call is requested.
It is calculated as PRB percentage. When a new
call is requested, if the uplink GBR PRB usage
exceeds this parameter value, the QoS CAC Fail
is generated.
UL_QCIUSAGE 0~100 The threshold of Uplink Handover calls that can
_THRESH_HO be assigned per QoS Class Identifier (QCI).
It is used when a Handover call is requested.
It is calculated as PRB percentage.
When a Handover call is requested, if the uplink
GBR PRB usage exceeds this parameter value,
the QoS CAC Fail is generated.
UNIT_USAGE_ 0.000000~ The value of PRB usage that can be caltuated
MANUAL 100.00000 manually.
0
RTRV- CELL_NUM - The cell number to be changed or retrieved.
CELL-PARA

Feature Description
(Continued)
RTRV- CELL_COUNT_ CI_no_use Whether to execute the E-UTRAN Radio Access

CELL-PARA CAC_USAGE CI_use Bearer (E-RAB)-based CAC function, which is
one of the capacity-based Call Admission Control
(CAC) functions per cell.
- CI_no_use: The E-RAB count-based CAC
function per cell is not executed.
- CI_use: The E-RAB count-based CAC function
per cell is executed.
MAX_CALL_CO - The call count limit in the capacity based CAC
UNT (call admission control) at the cell level.
The number of calls that can be allowed by the
cell.
QOS_CAC_OPT QoSCAC_o The policy of the QoS (Quality of Service) based
ION ption0 CAC (call admission control) at the cell level.
QoSCAC_o - QoSCAC_option0: The QoS based CAC
ption1 function at the cell level is not used.
- QoSCAC_option1: The QoS-based CAC
RTRV- QOS_POLICY_ QoSPolicy_ The policy used when executing the Quality of
CELL-PARA OPTION option0 Service (QoS)-based Call Admission Control
QoSPolicy_ (CAC) function per cell.
option1 - QoSPolicy_option0: For a GBR bearer newly
requested, the PRB usage is calculated based
on the resource type (GBR or non-GBR) of the
QCI. Then CAC is executed based on the
calculated PRB usage. Non-GBRs are always
allowed.
- QoSPolicy_option1: For a GBR bearer newly
requested, the PRB usage is calculated based
on the priority of the QCI. Then CAC is
executed based on the calculated PRB usage.
PRB_REPORT_ PRB (Physical Resource Block) report period for
PERIOD QoS CAC at the cell level.
ESTIMATION_O Estimation The policy of the Expected PRB usage
PT Option_aut calculation. (0: auto, 1:manual)
o (0) - EstimationOption_auto (0): The PRB Usage is
Estimation automatically calculated.
Option_ma - EstimationOption_manual (1): The PRB Usage
nual (1) is manually calculated.

Feature Description
(Continued)
RTRV- PREEMPTION CI_no_use Whether to use preemption at the cell level.

CELL-PARA _FLAG CI_use - CI_no_use: The Preemption function per cell
is disabled.
- CI_use: The Preemption function per cell is
enabled.
BH_BW_CAC_ CI_no_use Whether to use backhaul bandwidth based
USAGE CI_use CAC at the cell level.
- CI_no_use: Backhaul Bandwidth-based CAC
function per cell is not used.
- CI_use: Backhaul Bandwidth-based CAC
BH_BW_CAC_ bhBwCac_QCI The policy used when executing the Backhaul-
OPTION _only based Call Admission Control (CAC) function
bhBwCac_Ser per cell.
viceGroup_onl - bhBwCac_QCI_only: QoS-based CAC.
y - bhBwCac_ServiceGroup_only: Service group-
bhBwCac_Bot based CAC.
h_QCI_Service - bhBwCac_Both_QCI_ServiceGroup: QoS
Group amp; Service group-based CAC.
 Other system parameters
Related Parameter Default Description
PRB Configurable QoSCacOption 1 Disable or enable of PRB uage based

uasge per cell CAC
based 0: Disabled
CAC 1: Enabled
QoSPolicyOpti 0 0: Admission decision made
on considering all the bearers of all GBR
QCIs. Non-GBR always accepted.
1: Admission decision made
considering the GBR bearers of the
same QCI. Non-GBR bearers always
accepted.
reportPeriodNo 5 Period of reporting in non-congestion
rmal (sec)
reportPeriodCo 2 Period of reporting in congestion
ngest (sec)

Feature Description
(Continued)
Related Parameter Default Description
PRB Configurabl QoSCACUsage 10000 Limit of PRB usage for a new bearer
uasge e per cell, Thresh admission decision (1/1000 %)
based per UL, per CongestUsageT DL:10000/ Limit of PRB usage to determine a
CAC DL hresh UL: 40000 congestion state (1/1000 %)
Configurabl QoSUsageMargi setting per Threshold for normal call
e per eNB, nForNormal GBR QCI
per GBR QoSUsageMargi setting per Threshold for handover or
QCI, per nForEmerHo GBR QCI emergency call
UL, per DL
Backhaul Configurabl bhBwCacUsage 1 Disable or enable of backhaul
Bandwidth e per cell bandwidth uage based CAC
based 0: Disabled
1: Enabled
bhBwCacOption 1 0: admission decision per a specific
GBR QCI
1: admission decision per Service
Group
2: admission decision per GBR QCI
and Service Group
Configurabl bhBwCacThresh Setting per Threshold for normal call when
e per eNB, ForNormal GBR QCI bhBwCacOption=0 or 2
per GBR bhBwCacThresh Setting per Threshold for handover or
QCI, per ForEmerHo GBR QCI emergency call when
UL, per DL bhBwCacOption=0 or 2
overBookingRati 1 Overbooking ratio of Backhaul QoS
o CAC threshold
Backhaul Configurabl bhBwCacThresh Threshold for normal call when
Bandwidth e per eNB, ForNormal bhBwCacOption=1 or 2
based per Service bhBwCacThresh Setting per Threshold for handover or
Group, per ForEmerHo Service emergency call when
UL, per DL Group bhBwCacOption=1 or 2
overBookingRati 1 Overbooking ratio of Backhaul QoS
o CAC threshold

Feature Description

RRC RRC_ESTAB ConnEstabReject_CP_CAP RRC connection request is

A_CAC_FAIL rejected by call admission failure
RRC_REESTAB ConnReEstabReject_CP_Q RRC connection request is
OS_CAC_FAIL rejected by QoS based CAC due
to the lack of radio resources
ConnReEstabReject_CP_C RRC connection request is
APA_CAC_FAIL rejected by Capacity based CAC
RRC_RELEASE ConnRelease_CP_QOS_CA RRC connection is released due to
C_FAIL the lack of radio resources (QoS
based CAC)

N/A
Related Call Faults

N/A

Feature Description
LTE-SW4103, Preemption
Overview
In case of no resource available, eNB admits a new bearer by preempting existing bearers.
The decision is based on ARP (Allocation and Retention Priority) information of new
bearer(s) and existing bearer(s).
Introduction
In case of no resource available, eNB can admit a new bearer by preempting existing
bearers. This feature can be used to give admission to priority users even in congestion.
The decision is based on ARP (Allocation and Retention Priority) information of new
bearer(s) and existing bearer(s). ARP consists of priority level, preemption capability, and
preemption vulnerability, which are delivered from MME to eNB during E-RAB
establishment. When there are multiple preemptive candidate bearers, eNB selects a
longest call.
MME has responsibility to configure appropriate ARP per each bearer.
Benefits
 Operator can provide UEs with differentiated service based on service or based on UE
class.
 Operator can design a high-priority service which is always available even in network
congestion.
Release History
SLR2.2

Dependency:
 None
Limitation:
 None

Feature Description
Reference
Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol
(S1AP)
Feature Scope
R1 eNB preempts a existing UE or a bearer if there is no resource available due to the
lack of radio resources (Bearers, GBR resources) in case of congestion. The decision
follows the rules defined in 3GPP TS36.413 Section 9.2.1.60.
R2 If there are multiple candidates for preemption that have the same ARP, eNB select
the longest call.

Feature Description
Feature Description
Following table shows a function architecture for call admission control. Capacity based
This section covers preemption. For other two CAC features, refer to LTE-SW4101 and
LTE-SW4102.
Preemption function is applied to GBR and non-GBR bearers in case of no resource

available. Related resources are the number of bearers defined per cell. If operator provides
QoS service and has limited resources that can be allocated to GBR bearers, the lack of
GBR bearers and PRBs and backhaul bandwidth can trigger preemption function.
In this case, an existing GBR bearer will be preempted.
eNB follows the preemption rules defined in 3GPP TS36.413. If there are multiple
preemption candidates that have the same ARP, eNB will select a candidate bearer that has
been connected for the longest time period.

Feature Description
IE/Group IE type and

Presence Range Semantics description
Name reference
ARP - - - -
>Priority M - INTEGER Desc.: This IE should be understood as
Level (0..15) ‘priority of allocation and retention’ (see
[11]).
Usage: Value 15 means ‘no priority’.
Values between 1 and 14 are ordered in
decreasing order of priority, i.e. 1 is the
highest and 14 the lowest. Value 0 shall
be treated as a logical error if received.
>Pre-emption M - ENUMERATED Desc.: This IE indicates the pre-emption
Capability (shall not trigger capability of the request on other E-RABs
pre-emption, Usage: The E-RAB shall not pre-empt
may trigger pre- other E-RABs or, the E-RAB may pre-
emption) empt other E-RABs. The Pre-emption
Capability indicator applies to the
allocation of resources for an E-RAB and
as such it provides the trigger to the pre-
emption procedures/processes of the eNB.
>Pre-emption M - ENUMERATED Desc.: This IE indicates the vulnerability
Vulnerability (not pre- of the E-RAB to preemption of other E-
emptable, pre- RABs.
emptable) Usage: The E-RAB shall not be pre-
empted by other E-RABs or the E-RAB
may be pre-empted by other RABs.
Pre-emption Vulnerability indicator
applies for the entire duration of the E-
RAB, unless modified and as such
indicates whether the E-RAB is a target
of the pre-emption procedures/processes
of the eNB

Feature Description
System operation
Command Description
RTRV-CELL-CAC Retrieves/Changes the CAC (call admission control) parameter information of

CHG-CELL-CAC the cells operating within the eNB. As cell-level CACs, backhaul based CAC,
call count based CAC, DRB count based CAC, and QoS based CAC are
performed.
Changes threshold, CAC option, and preemption status for performing CAC
at the cell level.
RTRV-BHBW- Retrieves/Changes parameter information for backhaul Call Admission
SVCGR Control (CAC) per service group enabled in the eNB. Backhaul-based CAC is
CHG-BHBW- enabled per QCI or service group on GBR bearers. Retrieves thresholds to
SVCGR enable backhaul-based CAC per service group.
RTRV-BHBW-QCI Retrieves/Changes parameter information for backhaul Call Admission
CHG-BHBW-QCI Control (CAC) per QoS Class Identifier (QCI) enabled in the eNB.Backhaul-
based CAC is enabled per QCI or service group on GBR bearers. Retrieves
thresholds to enable backhaul-based CAC per QCI.
RTRV-QCAC- Retrieves/Changes the active QoS (Quality of Service) CAC (call admission
PARA control) parameter in the eNB. QoS CAC is performed at the cell level, for
CHG-QCAC- QCI of each GBR bearer. Retrieves the threshold by QCI for performing QoS
PARA CAC and retrieves the threshold for determining congestion state of the
active cell.
RTRV-ENB-CAC Retrieves/Changes the capacity based CAC (call admission control)
CHG-ENB-CAC parameter information of the eNBs in the BS.
This command performs call count based CAC at the eNB level. It also
retrieves the threshold information and the MAX call count information

Feature Description

Command Parameters Range Default Description
RTRV- CELL_NUM 0~MAX_CE 0 The cell number to be changed or

CELL-CAC LL_PER_SY retrieved.
CHG- S_CDD
CELL-CAC CELL_COUNT enumUsage 1 Whether to execute the call count-
_CAC_USAGE _type based CAC function, which is one
of the capacity-based Call
Admission Control (CAC) functions
per cell.
- CI_no_use: The capacity-based
CAC function per cell is not
performed.
- CI_use: The capacity-based CAC
function per cell is performed.
MAX_CALL_C 0~MAX_CA MAX_CALL The call count limit in the capacity
OUNT LL_COUNT _COUNT_ based CAC (call admission control)
_PER_CELL PER_CELL at the cell level. The number of calls
that can be allowed by the cell
CALL_CAC_TH 0~100 90 The percentage of the allowable
RESH_FOR_N calls to the total normal calls.
ORMAL When a normal call is requested, if
the number of connected calls
exceeds MAX_CALL_COUNT *
CALL_CAC_THRESH_FOR_NOR
MAL, the Capacity-based CAC Fail is
generated.
CALL_CAC_TH 0~100 100 Emergency call availability of total
RESH_FOR_E handover calls in percentage.
MER_HO When a normal call is requested, if
exceeds MAX_CALL_COUNT *
CALL_CAC_THRESH_FOR_EMER
_HO, the Capacity-based CAC Fail is
generated.
DRB_COUNT_ enumUsage 1 Whether to execute the E-UTRAN
CAC_USAGE _type Radio Access Bearer (E-RAB)-
based CAC function, which is one
of the capacity-based Call
Admission Control (CAC) functions
per cell.
- CI_use: The E-RAB count-based
CAC function per cell is executed.
- CI_no_use: The E-RAB count-
based CAC function per cell is not
executed.

Feature Description
(Continued)
RTRV- MAX_DRB_CO 0~MAX_DR MAX_DRB The limit for the E-RAB (E-UTRAN
CELL-CAC UNT B_COUNT_ _COUNT_ Radio Access Bearer) count in
CHG- PER_CELL PER_CELL capacity based CAC (call admission
CELL-CAC control) at the cell level.
The number of E-RABs (E-UTRAN
Radio Access Bearers) allowed in
the cell.
DRB_CAC_TH 0~100 90 The percentage of the allowable
RESH_FOR_N calls to the total normal calls.
ORMAL When a normal call is requested, if
exceeds ‘MAX_DRB_COUNT *
DRB_CAC_THRESH_FOR_NORM
AL’, the Capacity-based CAC Fail is
generated.
DRB_CAC_TH 0~100 100 Emergency call availability of total
exceeds ‘MAX_DRB_COUNT *
DRB_CAC_THRESH_FOR_EMER
_HO’, the Capacity-based CAC Fail
is generated
QOS_CAC_OP enumQoSC 1 The policy of the QoS (Quality of
TION ACOption_ty Service) based CAC (call admission
pe control) at the cell level.
- QoSCAC_option0: The QoS
based CAC function at the cell
level is not used.
- QoSCAC_option1: The QoS-based
CAC function per cell is used.
QOS_POLICY_ enumQoSP 1 The policy used when executing the
OPTION olicyOption_ Quality of Service (QoS)-based Call
type Admission Control (CAC) function
per cell.
- QoSPolicy_option0: For a GBR
bearer newly requested, the PRB
usage is calculated based on the
resource type (GBR or non-GBR)
of the QCI. Then CAC is executed
based on the calculated PRB usage.

Feature Description
(Continued)
RTRV- QOS_POLICY_ enumQoSP 1 - QoSPolicy_option1: For a GBR

CELL-CAC OPTION olicyOption_ bearer newly requested, the PRB
CHG- type usage is calculated based on the
CELL-CAC priority of the QCI. Then CAC is
executed based on the calculated
PRB usage. Non-GBRs are
always allowed.
PRB_REPORT 1~5 2 PRB (Physical Resource Block)
_PERIOD report period for QoS CAC at the
cell level.
ESTIMATION_ enumEstima 0 The policy of the Expected PRB
OPT tionOption_t usage calculation. (0: auto,
ype 1:manual)
- EstimationOption_auto(0): The
PRB Usage is automatically
calculated.
- EstimationOption_manual(1): The
PRB Usage is manually calculated.
PREEMPTION enumUsage 1 Whether to use preemption at the
_FLAG _type cell level.
- CI_no_use: The Preemption
function per cell is disabled.
- CI_use: The Preemption function
per cell is enabled.
BH_BW_CAC_ enumUsage 1 Whether to use backhaul bandwidth
USAGE _type based CAC at the cell level.
- CI_no_use: Backhaul Bandwidth-
based CAC function per cell is not
used.
- CI_use: Backhaul Bandwidth-
based CAC function per cell is used.
BH_BW_CAC_ enumBhBw 1 The policy used when executing the
OPTION CacOption_t Backhaul-based Call Admission
ype Control (CAC) function per cell.
- bhBwCac_QCI_only: QoS-based
CAC.
- bhBwCac_ServiceGroup_only:
Service group-based CAC.
- bhBwCac_Both_QCI_
ServiceGroup: QoS amp; Service
group-based CAC.
plmnCellCacUs enumUsage CI_no_use -
age _type

Feature Description
(Continued)
RTRV- SERVICE_GR enumServic 0 Service group.

BHBW- OUP eGroup_ - voipService: Service group that
SVCGR type uses the Voice over Internet
CHG- Protocol (VoIP) service.
BHBW- - videoService: Service group that
SVCGR uses the video service.
BH_BW_CAC_ 0~100 30 The total backhaul bandwidth in
DL_THRESH_ percent that can be assigned to the
FOR_NORMAL downlink per service group for
normal calls. When a normal call is
requested, if the downlink usage
exceeds the input parameter value,
the Backhaul Bandwidth CAC Fail is
generated.
FOR_EMER_ downlink per service group for
HO urgent and handover calls.
When emergency and handover
calls are requested, if the downlink
usage exceeds the input parameter
value, the Backhaul Bandwidth
CAC Fail is generated.
UL_THRESH_ percent that can be assigned to the
FOR_NORMAL uplink per service group for normal
calls. When a normal call is requested,
if the uplink usage exceeds the
input parameter value, the Backhaul
Bandwidth CAC Fail is generated.
FOR_EMER_ uplink per service group for urgent
HO and handover calls. When emergency
and handover calls are requested, if
the uplink usage exceeds the input
parameter value, the Backhaul
Bandwidth CAC Fail is generated.
OVER_BOOKI 1.0~10.0 1.0 The ratio of over-booking with
NG_RATIO downlink and uplink thresholds
when operating backhaul-based
CAC per service group.

Feature Description
(Continued)
RTRV- QCI 0~255 0 QCI index. The range is from 0 to 255.

BHBW-QCI The standard QCIs defined in the
CHG- standard documents is 1 to 9. The user
BHBW-QCI can use QCI values 0 and 10-255.
FOR_NORMAL downlink per QoS Class Identifier
(QCI) for normal calls. When a normal
call is requested, if the downlink usage
exceeds the input parameter value, the
Backhaul Bandwidth CAC Fail is
generated.
FOR_EMER_ downlink per QoS Class Identifier
HO (QCI) for urgent and handover calls.
When emergency and handover calls
are requested, if the downlink usage
generated.
FOR_NORMAL uplink per QoS Class Identifier (QCI)
for normal calls. When a normal call is
requested, if the uplink usage exceeds
the input parameter value, the
generated.
FOR_EMER_ uplink per QoS Class Identifier (QCI)
HO for urgent and handover calls.
When emergency and handover calls
are requested, if the uplink usage
generated
OVER_BOOKI 1.0~10.0 1.0 The ratio of over-booking with downlink
NG_RATIO and uplink thresholds when executing
backhaul-based CAC per QoS Class
Identifier (QCI).

Feature Description
(Continued)
RTRV- CELL_NUM 0~MAX_CE 0 The cell number to be changed or

QCAC- LL_PER_SY retrieved.
PARA S_CDD
CHG- DL_GBRUSAG 0~100 80 The threshold of downlink calls that
QCAC- E_THRESH_N can be assigned per cell. It is used
PARA ORMAL when a new call is requested.
It is calculated as ‘PRB percentage’.
When a new call is requested, if the
downlink GBR PRB usage exceeds
this parameter value, the QoS CAC
Fail is generated.
DL_GBRUSAG 0~100 100 The threshold of downlink Handover
E_THRESH_ calls that can be assigned per cell.
HO It is used when a Handover call is
requested. It is calculated as ‘PRB
percentage. When a Handover call is
requested, if the downlink GBR PRB
usage exceeds this parameter value,
UL_GBRUSAG 0~100 80 The threshold of uplink calls that can
E_THRESH_N be assigned per cell. It is used when a
ORMAL new call is requested. It is calculated
as ‘PRB percentage’. When a new call
is requested, if the uplink GBR PRB
usage exceeds this parameter value,
UL_GBRUSAG 0~100 100 The threshold of uplink Handover calls
E_THRESH_ that can be assigned per cell. It is used
HO when a Handover call is requested.
It is calculated as ‘PRB percentage’.
When a Handover call is requested, if
the uplink GBR PRB usage exceeds
this parameter value, the QoS CAC
Fail is generated
BundlingUsage 0~100 80 -
ThreshNormal
BundlingUsage 0~100 100 -
ThreshHO
reserved 0~65535 0 -

Feature Description
(Continued)
RTRV- dbIndex 0~0 0 -

ENB-CAC CALL_COUNT enumUsage 1 Whether to execute the Capacity-
CHG-ENB- _CAC_USAGE _type based Call Admission Control
CAC (CAC) function per cell.
- CI_no_use: The capacity-based
CAC function per base station is
not performed.
- CI_use: The capacity-based CAC
function per base station is
performed.
MAX_ENB_CA 0~MAX_CA MAX_CALL The limit for capacity based CAC
LL_COUNT LL_COUNT _COUNT_P (call admission control) at the eNB
_PER_SYS ER_SYS level. The number of calls that can
be allowed by the eNB.
CALL_CAC_TH 0~100 90 The percentage of the allowable
RESH_FOR_N calls to the total normal calls. When
ORMAL a normal call is requested, if the
number of connected calls exceeds
MAX_ENB_CALL_COUNT *
CALL_CAC_THRESH_FOR_NOR
MAL, the Capacity-based CAC Fail
is generated.
CALL_CAC_TH 0~100 100 Emergency call availability of total
exceeds MAX_ENB_CALL_
COUNT * CALL_CAC_THRESH_
FOR_EMER_HO, the Capacity-
CHECK_UE_ID enumUsage 1 Whether to execute the SAE
_USAGE _type Temporary Mobile Station Identifier
(S-TMSI) Duplication Check
function for a new call.
- CI_no_use: The S-TMSI
Duplication Check function is not
performed.
- CI_use: The S-TMSI Duplication
Check function is performed.
If a call is found as a duplicate, the
existing call is released and the
new call is accommodated.
reserved 0~0 0 -
plmnEnbCacUs enumUsage CI_no_use -
age _type

Feature Description

N/A

N/A
Related Call Faults

N/A
TEST PROCEDURES
1) Change MAX_CALL_COUNT, MAX_DRB_COUNT, Threshold value to use CHG-
CELLCAC-INF command at LSM
2) Attach first UE (Accept first UE)
3) Attach second UE
4) Reject second UE

Feature Description
LTE-SW4104, Cell Barring

Overview
When eNB is overloaded or a cell is used for testing, operator can configure eNB to
transmit a cell barring message via BCCH (SIB type1). In this way, operator can prevent
commercial UEs from camp in on the cell and allows test UEs to access the network.
Introduction
Cell barring is used to prohibit commercial UEs from accessing to the network during eNB
commissioning or performance testing but test UEs are allowed to camp on the cell.
Operator can configure related system parameters via LSM. Then, eNB broadcasts these
parameters in System Information Block Type 1 message.
Benefits
Operator can prohibit UEs from camping on a specific cell, which enables operator to test
the cell for the commissioning of base stations without any interference of commercial UEs.
Release History
SLR2.2
DEPENDENCY AND LIMITATION

Dependency
 None
Limitation
 None
Reference
Resource Control (RRC); Protocol Specification
Equipment (UE) procedures in idle mode, Section 5.3
Feature Scope
R1 Operator can configure cell-barring related system parameters via LSM.
R2 eNB broadcasts the cell barring information in SIB type 1 message.

Feature Description
Feature Description
Cell Reservations and Access Restrictions
There are two mechanisms which allow an operator to impose cell reservations or access
restrictions. The first mechanism uses indication of cell status and special reservations for
control of cell selection and reselection procedures. The second mechanism, referred to as
Access Control, shall allow preventing selected classes of users from sending initial access
messages for load control reasons. At subscription, one or more Access Classes are
allocated to the subscriber and stored in the USIM.
Cell status and cell reservations are indicated in the SIB Type1 message by means of two
fields:
 cellBarred (IE type: ‘barred’ or ‘not barred’): In case of multiple PLMNs indicated in
SIB1, this field is common for all PLMNs
 cellReservedForOperatorUse (IE type: ‘reserved’ or ‘not reserved’): In case of
multiple PLMNs indicated in SIB1, this field is specified per PLMN.
When cell status is indicated as ‘not barred’ and ‘not reserved’ for operator use, all UEs
shall treat this cell as a candidate cell during the cell selection and reselection procedures.
When cell status is indicated as ‘not barred’ and ‘reserved’ for operator use for any PLMN:
 UEs assigned to Access Class 11 or 15 operating in their HPLMN/EHPLMN shall
treat this cell as a candidate cell during the cell selection and reselection procedures if
the field cellReservedForOperatorUse for that PLMN set to ‘reserved’.
 UEs assigned to an Access Class in the range of 0 to 9, 12 to 14 shall behave as if the
cell status is ‘barred’ in case the cell is ‘reserved for operator use’ for the registered
PLMN or the selected PLMN.
NOTE 1: ACs 11, 15 are only valid for use in the HPLMN/EHPLMN; ACs 12, 13, 14 are
only valid for use in the home country.
When cell status ‘barred’ is indicated or to be treated as if the cell status is ‘barred’,
 The UE is not permitted to select/reselect this cell, not even for emergency calls.
 The UE shall select another cell
Refer to 3GPP TS36.304 Section 5.3 for more detail information on the cell selection and
reselection of UEs.

Feature Description
Indication of Cell Status

For cell barring, operator can change following system parameters in LSM.
 cellBarred (IE type: ‘barred’ or ‘not barred’): When the cell serves multiple PLMNs,
this cell barring parameter has effect on all the PLMNs.
 cellReservedForOperatorUse (IE type: ‘reserved’ or ‘not reserved’) Where the cell
serves multiple PLMNs, this parameter has effect only on the PLMN indicated by
PLMN-Identity.
 PLMN-Identity: A PLMN that cellReservedForOperatorUse will be applied to.

Feature Description
System operation
Command Description
RTRV- Retrieves/changes the parameters related to cell access within the eNB.
CELL-ACS
CHG-CELL- It changes the cell access information in the eNB, which is broadcasted to the UE
ACS through the SIB1.
RTRV-BAR- - Retrieves access barring parameters which are transmitted to the System
PARA Information Block2 (SIB2) according to the CPU overload status.
- The UE controls access for a cell according to the access barring parameter value
of SIB2 upon service request.
CHG-BAR- - Changes access barring parameters which are transmitted to the System
PARA Information Block2 (SIB2) according to the CPU overload status.
- The UE controls cell access according to the access barring parameter value of
SIB2 upon service request.
RTRV- Cell_NUM 0 The cell number to be changed.

CELL-ACS CELL_BARRED ci_notBarred Whether the cell is barred.
CHG-CELL- - ci_barred: The cell is barred.
ACS - ci_notBarred: The cell is not barred.
When the cell status turns to Shutdown,
or the operator sets this parameter value
to ci_barred, the cellBarred value of SIB1
is broadcast as ci_barred.
INTRA_FREQ_ ci_intraFreqRese The reselection status of the intra-
CELL_RESELECT lect_notAllowed frequency cell if the cell selected by the
UE is barred.
- ci_intraFreqReselect_allowed: An intra-
frequency cell is reselected.
- ci_intraFreqReselect_notAllowed: An
intra-frequency cell is considered barred.

Feature Description
(Continued)
RTRV- BARRING_CTR_ cpuStatusCtrl How to configure the ac-BarringInfo

CELL-ACS USAGE parameter of SIB2.
CHG-CELL- - barringOff: The barring control parameter
ACS is not used.
- manualCtrl: The barring control function is
used with manual control.
- cpuStatusCtrl: The barring control function
is used due to CPU overload.
RTRV-BAR- CELL_NUM 0 The cell number to be changed or retrieved.
PARA BARRING_ cpuNormal The barring status to be changed or
CHG-BAR- STATUS_TYPE retrieved.
PARA - cpuNormal: The main board CPU is in
Normal state.
- cpuMinor: The main board CPU is in Minor
state.
- cpuMajor: The main board CPU is in Major
state.
- cpuCritical: The main board CPU is in
Critical state.
- barManual: Manual Mode
BARRING_ CI_no_use Whether to use ac-BarringforMO-Signaling
SIGNAL_USAGE of the cell in the eNB.
- CI_no_use: ac-BarringforMO-Signaling is
not used. UE can access the cell when
attaching.
- CI_use: ac-BarringforMO-Signaling is
used. The UE controls cell access
according to the access barring signaling
parameter value.
ACC_PROB_FAC ci_p95 UE generates a random value (rand)
_SIGNAL between 0 and 1. If rand value less than
accessProbabilityFactor, UE can access the
cell; otherwise, access is not possible.
ACC_CLASS_ ci_s512 Access barring time of the cell in the eNB.
BAR_TIME_ UE generates a random value (rand)
SIGNAL between 0 and 1. If rand value less than
accessProbabilityFactor, UE determines
that the cell is barred, and does not
establish RRC connection until T305 timer
terminates. The expression used to
calculate T305 timer value is (0.7 + 0.6 *
rand) * acBarringTime.

Feature Description
(Continued)
RTRV-BAR- BAR_AC11_ False Whether AC 11 (Home PLMN only if the

PARA SIGNAL EHPLMN list is not present; otherwise, any
CHG-BAR- EHPLMN) in the eNB is barred.
PARA - False: Not barred.
- True: Barred.
BAR_AC12_ False Whether AC 12 (Home PLMN and visited
SIGNAL PLMNs of home country only. For this
purpose, the home country is defined as the
country of the MCC part of the IMSI) in the
eNB is barred.
- False: Not barred.
- True: Barred.
eNB is barred.
- True: Barred.
eNB is barred.
- True: Barred.
BAR_AC15_ False Whether AC15 in the eNB is barred.
SIGNAL - False: Not barred.
- True: Barred.
BARRING_DATA_ CI_no_use Whether to use ac-BarringforMO-Data of
USAGE the cell in the eNB.
- CI_no_use: ac-BarringforMO-Data is not
used. The UE can access the cell at
service request.
- CI_use: ac-BarringforMO-Data is used.
The UE controls cell access according to
the access barring data parameter value
at service request.

Feature Description
(Continued)
RTRV-BAR- ACC_PROB_FAC ci_p95 Access probability factor of the cell in the

PARA _DATA eNB.
CHG-BAR- UE generates a random value (rand)
PARA between 0 and 1. If rand less than 0,
BAR_TIME_DATA UE generates a random value (rand)
between 0 and 1. If rand value less than
BAR_AC11_DATA False Whether AC 11 (Home PLMN only if the
EHPLMN list is not present; otherwise, any
EHPLMN) in the eNB is barred at barring
data.
- True: Barred.
BAR_AC12_DATA False Whether AC 12 (Home PLMN and visited
PLMNs of home country only. For this
eNB is barred at barring data.
- True: Barred..
- True: Barred.
- True: Barred.

Feature Description
(Continued)
RTRV-BAR- BAR_AC15_DATA False Whether AC15 in the eNB is barred.

PARA - False: Not barred.
CHG-BAR- - True: Barred.
PARA ACCESS_ False Whether to use emergency call barring for
BARRING_ the cell in the eNB.
EMERGENCY_ - False: Not barred.
CALL - True: Barred.
BARRING_ CI_no_use Whether to use ssac-BarringForMMTEL-
MMTELVOICE_ Voice of the cell in the eNB.
USAGE - CI_no_use: ssac-BarringForMMTEL-Voice
is not used. The UE can access the cell at
service request.
- CI_use: ssac-BarringForMMTEL-Voice is
according to the access barring data
parameter value at service request.
ACC_PROB_FAC ci_p95 Access probability factor of the cell in the eNB.
_MMTELVOICE UE generates a random value (rand)
between 0 and 1. If rand less than 0,
MMTELVOICE between 0 and 1. If rand value less than
BAR_AC11_ False Whether AC 11 (Home PLMN only if the
MMTELVOICE EHPLMN list is not present; otherwise, any
EHPLMN) in the eNB is barred at barring
data.
- True: Barred.
MMTELVOICE PLMNs of home country only. For this
- True: Barred.

Feature Description
(Continued)
RTRV-BAR- BAR_AC13_ False Whether AC 13 (Home PLMN and visited

PARA MMTELVOICE PLMNs of home country only. For this
CHG-BAR- purpose, the home country is defined as the
PARA country of the MCC part of the IMSI) in the
- True: Barred.
MMTELVOICE PLMNs of home country only. For this
- True: Barred.
MMTELVOICE - False: Not barred.
- True: Barred.
BARRING_ CI_no_use Whether to use ssac-BarringForMMTEL-
MMTELVIDEO_ Voice of the cell in the eNB.
USAGE - CI_no_use: ssac-BarringForMMTEL-Voice
is not used. The UE can access the cell at
service request.
- CI_use: ssac-BarringForMMTEL-Voice is
according to the access barring data
parameter value at service request.
ACC_PROB_FAC ci_p95 Access probability factor of the cell in the
_MMTELVIDEO eNB. UE generates a random value (rand)
between 0 and 1. If rand less than 0,
MMTELVIDEO between 0 and 1. If rand value less than

Feature Description
(Continued)
RTRV-BAR- BAR_AC11_ False Whether AC 11 (Home PLMN only if the

PARA MMTELVIDEO EHPLMN list is not present; otherwise, any
CHG-BAR- EHPLMN) in the eNB is barred at barring
PARA data.
- True: Barred.
MMTELVIDEO PLMNs of home country only. For this
- True: Barred.
- True: Barred.
- True: Barred.
MMTELVIDEO - False: Not barred.
- True: Barred.

N/A

N/A
Related Call Faults

N/A

Feature Description
LTE-SW4201, Standard QCI Support

Overview
eNB supports standardized QCI (QoS Class Identifier) as defined in 3GPP TS 23.203,
which is characterized by priority, packet delay budget and packet error loss rate.
eNB handles scheduling of the bearer based on its QCI information.
Introduction
In the access network, it is the eNB’s responsibility to ensure that the necessary QoS for a
bearer over the radio interface is met. Each bearer has an associated Class identifier (QCI),
and an Allocation and Retention Priority (ARP). Each QCI is characterized by priority,
packet delay budget, and acceptable packet loss rate.
Each Service Data Flow (SDF) is associated with one and only one QoS Class Identifier
(QCI). The QCI is scalar that is used as a reference to node specific parameters that control
packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue
management thresholds, link layer protocol configuration, etc.) and that have been pre-
configured by the operator
Benefits
Operator Benefits:
 This feature enables operator to plan a variety of premium services; end-to-end QoS
differentiated services in 9 different levels as per defined in 3GPP standard.
 Operator can provide high-quality VoLTE service by using guaranteed bit rate bearers.
 Operator can provide different user classes for different quality of services.
End User Benefits: Users can use a premium service that provides better quality even in
congestion.
Release History
SLR2.2

Dependency
 N/A
Limitation:
 N/A

Feature Description
Reference

Feature Description
Feature Description
The standardized characteristics are not signalled on any interface. They should be
understood as guidelines for the pre-configuration of node specific parameters for each
QCI. The goal of standardizing a QCI with corresponding characteristics is to ensure that
applications/services mapped to that QCI receive the same minimum level of QoS in multi-
vendor network deployments and in case of roaming. A standardized QCI and
corresponding characteristics is independent of the UE’s current access (3GPP or Non-
3GPP).
Each Service Data Flow (SDF) is associated with one and only one QoS Class Identifier
(QCI). The QCI is scalar that is used as a reference to node specific parameters that control
packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue
management thresholds, link layer protocol configuration, etc.) and that have been pre-
configured by the operator
Below table shows 9 standard QCI defined in 3GPP LTE standard.
Packet Delay Packet Error

Resource
QCI Priority Budget Loss Rate Example Services
Type
(NOTE 1) (NOTE 2)
-2
1 - 2 100 ms 10 Conversational Voice
-3
2 GBR 4 150 ms 10 Conversational Video (Live
Streaming)
-3
3 - 3 50 ms 10 Real Time Gaming
-6
4 - 5 300 ms 10 Non-Conversational Video
(Buffered Streaming)
-6
5 - 1 100 ms 10 IMS Signalling
-6
6 - 6 300 ms 10 Video (Buffered Streaming)
TCP-based (e.g. www, e-mail,
chat, ftp, p2p file sharing,
progressive video, etc.)
7 Non-GBR 7 100 ms 10-3 Voice, Video (Live Streaming)
Interactive Gaming
8 - 8 300 ms 10-6 Video (Buffered Streaming)
TCP-based (e.g. www, e-mail,
chat, ftp, p2p file
9 - 9 - - sharing, progressive video,
etc.)

Feature Description
System operation
Command Description
RTRV-QCI- This command retrieves the configuration data of an extended QCI. The
VAL configuration parameters of each QCI consist of Status, Resource Type, Priority,
Packet Delay Budget (PDB), Packet Error Loss Rate (PELR), and Backhaul
Service Group.
QCI index. The range is from 1 to 9 for standardized QCIs and 128~254 for
extended QCIs.
CHG-QCI-VAL This command is used to define an extended QCI or to modify the configuration
data of a QCI.
Parameters Range Default Value Description
QCI 0~9 (for Standard QCI) - CHG-QCI-VAL is used to set

10~255 (Others) an extended QCI RTRV-QCI-
VAL is used to retrieve QoS
charateristics of a QCI.
STATUS N_EQUIP, EQUIP 0 N_EQUIP CHG-QCI-VAL is used to
1 EQUIP change STATUS of an
2 EQUIP extended QCI RTRV-QCI-VAL
3 EQUIP is used to read STATUS of a
4 EQUIP QCI N_EQUIP indicates that
5 EQUIP the QCI is disabled EQUIP
6 EQUIP indicates that the QCI is
7 EQUIP enabled.
8 EQUIP
9 EQUIP
RESOURCE_ ci_NonGBR, ci_GBR 0 ci_NonGBR CHG-QCI-VAL is used to
TYPE 1 ci_GBR change RESOURCE_TYPE of
2 ci_GBR an extended QCI RTRV-QCI-
3 ci_GBR VAL is used to read
4 ci_GBR RESOURCE_TYPE of a QCI
5 ci_NonGBR ci_NonGBR indicates Non-
6 ci_NonGBR GBR (Guaranteed Bit Rate)
7 ci_NonGBR resource type ci_GBR
8 ci_NonGBR indicates GBR (Guaranteed Bit
9 ci_NonGBR Rate) resource type

Feature Description
(Continued)
PRIORITY 1~16 09 ‘1’ indicates the highest priority.

12 CHG-QCI-VAL is used to
24 change PRIORITY of an
33 extended QCI RTRV-QCI-VAL
45 is used to read PRIORIY of a
51 QCI
66
77
88
99
PDB ci_pdb50 msec, 0 ci_pdb300 msec CHG-QCI-VAL is used to
ci_pdb100 msec, 1 ci_pdb100 msec change PDB of an extended
ci_pdb150 msec, 2 ci_pdb150 msec QCI RTRV-QCI-VAL is used to
ci_pdb200 msec, 3 ci_pdb50 msec read PDB of a QCI ci_pdb50
ci_pdb250 msec, 4 ci_pdb300 msec msec means 50msec of PDB
ci_pdb300 msec, 5 ci_pdb100 msec for the corresponding QCI.
ci_pdb350 msec, 6 ci_pdb300 msec PDB can be defined between
ci_pdb400 msec, 7 ci_pdb100 msec 50msec and 500msec
ci_pdb450 msec, 8 ci_pdb300 msec
ci_pdb500 msec 9 ci_pdb300 msec
PELR ci_pler10_2, 0 ci_pler10_6 CHG-QCI-VAL is used to
ci_pler10_3, 1 ci_pler10_2 change PELR of an extended
ci_pler10_4, 2 ci_pler10_3 QCI RTRV-QCI-VAL is used to
ci_pler10_5, 3 ci_pler10_3 read PELR of a QCI
ci_pler10_6, 4 ci_pler10_6 ci_pler10_2 means PELR of
ci_pler10_7, 5 ci_pler10_6 10-2 for the corresponding
ci_pler10_8, 6 ci_pler10_6 QCI.
ci_pler10_9 7 ci_pler10_3
8 ci_pler10_6
9 ci_pler10_6
BH_SERVICE voipService, 0 videoService This parameter is used in the
_GROUP videoService 1 voipService backhaul Call Admission
2 videoService Control (CAC) CHG-QCI-VAL
3 videoService is used to change PELR of an
4 videoService extended QCI RTRV-QCI-VAL
5 videoService is used to read PELR of a QCI
6 videoService voipService means that the
7 videoService corresponding QCI is used for
8 videoService VoIP service and videoService
9 videoService for video service.

Feature Description
(Continued)
SCHEDULING Scheduling type of 0 Dynamic_scheduling This parameter is used to

_TYPE QCI Range: 1 Dynamic_scheduling decide the scheduling type for
Dynamic_scheduli 2 Dynamic_scheduling bearers with the corresponding
ng or SPS_ 3 Dynamic_scheduling QCI. Dynamic_scheduling
scheduling 4 Dynamic_scheduling indicates that the MAC
5 Dynamic_scheduling scheduler applies dynamic
6 Dynamic_scheduling scheduling algorithm for the
7 Dynamic_scheduling bearers with the corresponding
8 Dynamic_scheduling QCI while SPS_scheduling
9 Dynamic_scheduling means using of semi-
psersistent scheduling
algorithm for bearers with the
corresponding QCI.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW4202, Operator Specific QCIs Support

Overview
Introduction
In addition to standard QCIs, Samsung eNB enables operator to define extended QCIs that
ranges from 128 to 254. Operator can determine the resource type, priority and packet
delay budget of the extended QCIs. These QoS characteristics have the same meaning that
3GPP defines for standard QCIs. eNB handles the extended QCIs based on those QoS
characteristics configured by operator. For the use of extended QCIs, UE and EPC shall
recognize the extended QCIs and support the QoS characteristics too.
Benefits
 Operator can define a customized QCI for a specific service, where QoS
characteristics of the extended QCIs may be different from those of standard QCIs in
terms of priority, resource type, and packet delay budget.
 UE can receive a customized network service that is suitable to a specific application.
Release History
SLR 2.2
Basic or Optional
Optional

Dependency
 For the use of operator-specific QCIs, EPC and UE must recognize the operator-
specific QCIs and they shall behave to support the QoS level.
Limitation
 According to 3GPP standard, operator-specific QCIs shall range between 128 and 254.
 In SLR2.2, operator can configure maximum 127 operator-specific QCIs but related
statistic information will be proved to only 7 operator-specific QCIs.

Feature Description
Reference
4) 3GPP TS24.301 Non-Access-Stratum (NAS) protocol for Evolved Packet System
(EPS); Stage 3, Section 9.9.4.3
Feature Scope
 Operator can configure operator-specific QCIs via LSM, where operator decides and
sets QCI number, Resource Type (GBR or Non-GBR), Priority (1~16), and Packet
Delay Budget (0~9).
 LSM provides rule check function. LSM does not allow a QCI Number, Resource
Type, Priority, or Packet Delay Budget that are not in the range of the parameters.
LSM does not allow a QCI number that has the same QoS attribute values.
 eNB supports max 15 operator specific QCIs among 127 extended QCIs between 128
and 254.
 When MME requests an operator-specific QCI not defined in eNB, the eNB rejects the
request.
 eNB must support the attributes of operator specific QCIs, which have the same
semantics as the attributes of standard QCI. For example, operator specific QCI’s
priority of ‘6’ has the same effect as the priority ‘6’ of the standard QCI.
 LSM must provide a way for operator to configure QCI to DSCP mapping and packet
classification rule for the extended operator specific QCI.

Feature Description
Feature Description
Operator can define Operator-Specific QCIs via LSM. Samsung eNB supports up to 32
Operator-Specific QCIs.
Parameters for Operator

Ranges Description
Specific QCI
QCI Index 128~254 The numbers 10~127 are reserved and cannot
be used for operator-specific QCIs.
Refer to 3GPP TS24.301 Table 9.9.4.3.1
Resource Type GBR or Operator can set GBR or Non-GBR for the
Non-GBR operator-specific QCI
Priority 1~16 Operator can select one among 16 different
priority levels.
Packet Delay Budget 0~9 Operate can choose one among 10 different
PDB indexes. Index 0 means 50 ms of PDB and
index 1 means 100 ms of PDB and so on.
Finally, index 9 means 500 ms.
LSM provides a rule check function to minimize human errors. The rule check function
prevents operator from putting a wrong value that is out of allowed range and it also
prevents from putting an overlapped QCI indexes.
The QoS characteristics such as Resource Type, Priority, and Packet Delay Budget have the
same semantics as the QoS factors of the standardized QCIs. Therefore, they have the same
impact on scheduling priority when eNB sends UEs packets from bearers with the operator
specific QCIs. Operator has to configure the QCI to DSCP mapping table to reflect a newly
defined operator-specific QCI, which is for DSCP marking on packets that flow through the
bearers with the operator-specific QCI. In addition, operator has to configure which
network queue can be used to buffer the packets with the operator-specific QCI. Depending
on the queues, different network scheduling algorithm is applied, such as Deficit Round
Robin or Strict Priority.
eNB supports both the standardized QCIs and operator-specific QCIs defined and enabled
by operator. eNB will reject ERAB setup request if it includes an unknown QCI.

Feature Description
System Operation
Related Commands
Command Description
RTRV-QCI-VAL This command retrieves the configuration data of an extended QCI. The
configuration parameters of each QCI consist of Status, Resource Type, Priority,
Packet Delay Budget (PDB), Packet Error Loss Rate (PELR), and Backhaul
Service Group.
QCI index. The range is from 1 to 9 for standardized QCIs and 128~254 for
extended QCIs.
CHG-QCI-VAL This command is used to define an extended QCI or to modify the configuration
data of a QCI.

Default
Value
QCI 128~254 - CHG-QCI-VAL is used to set an extended QCI
RTRV-QCI-VAL is used to retrieve QoS
characteristics of a QCI.
STATUS N_EQUIP N_EQUIP CHG-QCI-VAL is used to change STATUS of an
or EQUIP extended QCI
RTRV-QCI-VAL is used to read STATUS of a QCI
N_EQUIP indicates that the QCI is disabled
EQUIP indicates that the QCI is enabled.
RESOURCE_ ci_NonGBR ci_NonGBR CHG-QCI-VAL is used to change RESOURCE_
TYPE or ci_GBR TYPE of an extended QCI
RTRV-QCI-VAL is used to read RESOURCE_
TYPE of a QCI
ci_NonGBR indicates Non-GBR (Guaranteed Bit
Rate) resource type
ci_GBR indicates GBR (Guaranteed Bit Rate)
resource type
PRIORITY Priority of 9 ‘1’ indicates the highest priority.
QCI CHG-QCI-VAL is used to change PRIORITY of an
Range: extended QCI
1~16 RTRV-QCI-VAL is used to read PRIORIY of a QCI
Default: 9

Feature Description
(Continued)
Default
Value
PDB ci_pdb50 msec, ci_pdb300 CHG-QCI-VAL is used to change PDB of an
ci_pdb100 msec, msec extended QCI
ci_pdb150 msec, RTRV-QCI-VAL is used to read PDB of a
ci_pdb200 msec, QCI
ci_pdb250 msec, ci_pdb50 msec means 50 msec of PDB for
ci_pdb300 msec, the corresponding QCI. PDB can be
ci_pdb350 msec, defined between 50msec and 500 msec
ci_pdb400 msec,
ci_pdb450 msec,
ci_pdb500 msec
PELR ci_pler10_2, ci_pler10_6 CHG-QCI-VAL is used to change PELR of
ci_pler10_3, an extended QCI
ci_pler10_4, RTRV-QCI-VAL is used to read PELR of a
ci_pler10_5, QCI
ci_pler10_6, ci_pler10_2 means PELR of 10-2 for the
ci_pler10_7, corresponding QCI.
ci_pler10_8,
ci_pler10_9
BH_SERVIC voipService, voipService This parameter is used in the backhaul Call
E_GROUP videoService Admission Control (CAC)
CHG-QCI-VAL is used to change PELR of
an extended QCI
RTRV-QCI-VAL is used to read PELR of a
QCI
voipService means that the corresponding
QCI is used for VoIP service and
videoService for video service.
SCHEDULIN Dynamic_scheduling, Dynamic_ This parameter is used to decide the
G_TYPE SPS_scheduling scheduling scheduling type for bearers with the
corresponding QCI.
Dynamic_scheduling indicates that the
MAC scheduler applies dynamic scheduling
algorithm for the bearers with the
corresponding QCI while SPS_scheduling
means using of semi-psersistent scheduling
algorithm for bearers with the
corresponding QCI.

Feature Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

S1AP_not_supported This call fault occurs when either Check at LSM Performance >
_QCI_value Initial Context Setup Request Performance Statisics >
message or ERAB Setup Request CSL.CallFault
message includes a QCI value that
eNB does not support.

Feature Description
LTE-SW4203, QCI to DSCP Mapping

Overview
eNB marks uplink packets with a DSCP value so that intermediate nodes can support QoS
for packets heading to EPC. DSCP value is determined depending on QCI. For this,
operator can configure QCI to DSCP mapping table according to its service and QoS policy.
Introduction
The LTE system supports each different QoS for each different QCI. However, if a packet
passes through the backhaul section between eNB and EPC, QoS defined in the LTE is not
supported. In the backhaul IP network section where the LTE traffic is not recognized, the
IP network such as Diffserv must support QoS. Therefore, it is necessary to map LTE QoS
to IP network QoS to support the End-to-End QoS of LTE system.
For the objective, the eNB provides an appropriate marking for an uplink packet to
differentiate bearer QoS even in the backhaul IP network section. The operator can set up
each different DSCP per QCI for all the packets transmitted by the eNB. Also, the operator
can set up a separate DSCP for the signalling message transmitted to the MME or the OAM
traffic that is transmitted to the LSM.
For the DL packet, the SGW must support DSCP marking for each QCI.
To support QoS in the backhaul IP network, the switches or routers comprising the operator
IP network between eNB and SGW must be configured to support QoS based on DSCP.
For example, the buffer size per DSCP or scheduling priority, etc. must be set up
appropriately.
Benefits
 Operator can manage traffic from eNB to SGW for end-to-end QoS service.
 In addition to bearer traffic, operator can setup appropriate DSCP values to signaling
traffic and OAM traffic for system optimization. For example, setting a high priority
on signaling message will reduce call setup time while a DSCP value for regularly
generated OAM ftp traffic needs to set not to affect user traffic.
Release History

Feature Description

Dependency:
 None
Limitation:
 In the eNB, you can set up a DSCP value only for an uplink packet. For reference, a
downlink DSCP value is marked by the SGW.
 A DSCP value configured in the eNB is valid only until it is transmitted to the SGW.
The PGW section in SGW complies with the marking rule configured in the core
network.
Reference
[1] 3GPP TS23.203 Policy and charging control architecture
Feature Scope
R1 A DSCP value should be set up for each QCI.
R2 The operator should set up a DSCP value even for signaling, OAM (FTP), or OAM
(Alarm, etc.) as well as QCI.
R3 In the eNB, a DSCP value should be set up for all kinds of packets which are
transmitted to the uplink backhaul.
R4 The eNB should mark an appropriate DSCP value determined by the operator to each
packet.

Feature Description
Feature Description
As shown in the below table, the operator can set up each different DSCP value for each
traffic such as QCI 1~9, signaling (S1-MME, X2), management, OAM, or network control,
default, etc. The below table is an example of QCI to DSCP mapping. You can set up a
DSCP value appropriately according to the operator’s backhaul network operation policy
and service.
QCI DSCP Value Traffic Type Remarks
- 24 (CS3) Signaling S1/X2 signaling (including SCTP heart-beat), GTP

echo, GTP error indication
- 24 (CS3) Management SNMP messages (Alarm, Status, Command
Request/Response)
- 26 (AF31) OAM Traffic FTP, Logs (CSL, Trace), ICMP (between LSM and
eNBs)
- 48 (CS6) Network control IP control (DHCP), NTP (LSM and eNBs)
1 46 (EF) QCI-1 User Data Conversational Voice (RTP) (CDMA Voice)
2 34 (AF41) QCI-2 User Data Conversational Video (Live Streaming)
3 36 (AF42) QCI-3 User Data Real Time Gaming
4 38 (AF43) QCI-4 User Data Non-Conversational Video (Buffered Streaming)
5 24 (CS3) QCI-5 User Data IMS Signalling
6 16 (CS2) QCI-6 User Data Video (Buffered Streaming), TCP-based (e.g. www,
e-mail, chat, ftp, p2p)
7 18 (AF21) QCI-7 User Data Voice, Interactive Gaming, Video (Live Streaming)
8 20 (AF22) QCI-8 User Data Video (Buffered Streaming), TCP-based (e.g. www,
9 22 (AF23) QCI-9 User Data Video (Buffered Streaming), TCP-based (e.g. www,
- 0 (CS0) Remaining Traffic Best Effort
The backhaul network transmits and receives mixtures of various traffics such as signaling
traffic, OAM traffic, bearer traffic, and network control traffic, so the traffics should be
controlled according to the priority of each traffic. For instance, in case of losing signalling
traffic or network control traffic, the entire service can be affected, so it requires a higher
priority than a general user’s traffic. In addition, latency of voice traffic is important, so it
should have a higher priority than internet data traffic.

Feature Description
Likewise, the transport QoS function is required to control the priority of each traffic type.
In the Ethernet backhaul network, the IP layer and the Ethernet layer uses DSCP and CoS
respectively to provide the transport QoS function. The operator can control the priorities
by setting DSCP/CoS for each traffic type. Full conceptual diagram of transport QoS’s is as
follows.
As shown in the above figure, a different QCI can be mapped to the same DSCP value.
In the eNB, packets are classified into different network buffer (queue) according to the
DSCP value. A different queue may have different scheduling priority.

Feature Description
System operation
CHG-QCIDSCP-MAP QCI Changes the differentiated services code point

DSCP (DSCP) mapping information for each QCI.
CHG-SIGDSCP- CLASS_ID Changes the DSCP data of a signal in the eNB.
DATA DSCP
CHG-SYSDSCP- CLASS_ID Changes the control and management traffics and
DATA DSCP DSCP mapping information created in the system.
A specific system traffic type is selected using the
CLASS_ID parameter and the value entered to the
DSCP parameter is mapped to the traffic type.
CHG-QCIDSCP-MAP
QCI The QoS class identifier (QCI) value where the The CHG-QCIDSCP-
DSCP mapping information will be specified. MA command can be
Range: 0~255 used to change.
Default: 0
DSCP DSCP value to set up per traffic type (QCI). The CHG-QCIDSCP-
Range: 0~63 MA command can be
Default: 0 used to change.
CLASS_ID Signal Class Id in the eNB. Each Class Id is The CHG-SIGDSCP-
defined as follows: DATA command can
0: S1 Signaling be used to change.
1: X2 Signaling
2: S1/X2-U management
Range: 0~2
Default: 40

Feature Description
(Continued)
DSCP DSCP value that will be configured for each The CHG-SIGDSCP-
signaling traffic type created in the system. DATA command can
Range: 0~63 be used to change.
Default: 0
CLASS_ID Index defined to set up the control and The CHG-SYSDSCP-
management traffics and the mapping DATA command can
information of DSCP created in the system. be used to change.
7 traffic types are defined and the traffic type
corresponding to each index is as follows:
0: SNMP, 1: SSH, 2: sftp/ftp, 3: OAM traffic/CSL/
Trace, 4: ICMP (Ping), 5: Network control traffic,
6: IEEE 1588 traffic
Range: 0~6
Default: 26
DSCP DSCP value that will be configured for the The CHG-SYSDSCP-
control and management traffics created in the DATA command can
system. be used to change.
Range: 0~63
Default: 0

N/A

N/A
Related Call Faults

N/A

Feature Description
LTE-SW4204, SW4205, GBR and MBR Support

Overview
eNB reserves radio resource to support GBR (Guaranteed Bit Rate), and eNB limits the
throughput not to exceed MBR (Maximum Bit Rate). For this, QoS based call admission
control and QoS aware scheduling algorithm is used. GBR and MBR are bearer associated
parameters and MME sends eNB these parameters during E-RAB setup or modification
procedure.
Introduction
GBR (Guaranteed Bit Rate) and MBR (Maximum Bit Rate) are the key QoS features of
LTE. The two parameters can be set for each dedicated bearer together. eNB receives the
two parameters from MME but PCRF has responsibility in the decision of GBR and MBR
value. By means of GBR, operator can specify a minimum bit rate that LTE system
guarantees for a specific dedicated bearer, and by means of MBR, operator can constrain a
maximum bit rate that the dedicated bearer can achieve.
When a GBR bearer setup completes, it means that eNB reserves radio resources as much
as it can support the guaranteed bit rate. Since the radio resources are not enough, which
operator may allow a limited amount of resources for GBR uses, QoS based CAC has a
role to decide whether eNB can support the required GBR of a new bearer or not.
For the decision, the special CAC function takes into account of PRB usage, backhaul
bandwidth usage, and the amount of GBR resources that may be configured by operator.
In 3GPP Rel8 and Rel9 system, MBR is recommended to be set to the same level as GBR.
However, 3GPP Rel10 allows MBR greater than GBR. Samsung eNB supports MBR that
can be greater than GBR.
Benefits
 Operator can provide high-quality QoS services by using GBR bearers.
 UEs that connect a GBR bearer can achieve at least the guaranteed bit rate that system
allows even in cass of congestion.
 By configuring MBR, operator can prevent GBR UEs from overusing data and
monopolizing radio resources.
 Efficient usage of the radio resources
Release History

Feature Description

Dependency:
 MME should support MBR so that operator can configure MBR greater than GBR
Limitation:
 eNB can guarantee GBR for downlink only. For uplink, UE has some responsibility in
providing GBR because UE can control the priority of bearers when uplink bandwidth
is limited.
Reference
Feature Scope
R1 The eNB must support guaranteed bit rate for the GBR bearer even under congestion
situation.
R2 If the eNB cannot satisfy the QoS of a bearer, it provides the statistics collection
function that does counting per QCI.
R2 The eNB must not transmit data to the UE more than MBR.
R3 The MBR can be set higher than GBR.
Feature Description
In the 3GPP standard (TS23.203), the QoS classes are defined as shown in the below table.
The QCI is a simple index indicating each QoS class and total 9 each different QoS classes
are defined. The GBR and MBR are QoS attributes that can be used in QCI 1~4 whose
resource type is set to GBR. It is recommended to use the GBR resource type usually for
real-time voice, video, or service.
Packet
Resource Packet Error
QCI Priority Delay Example Services
Type Loss Rate
Budget
-2
1 GBR 2 100 ms 10 Conversational Voice
-3
2 GBR 4 150 ms 10 Conversational Video (Live Streaming)
-3
3 GBR 3 50 ms 10 Real Time Gaming
-6
4 GBR 5 300 ms 10 Non-Conversational Video (Buffered
Streaming)
-6
5 Non-GBR 1 100 ms 10 IMS Signalling

Feature Description
(Continued)
Packet
Resource Packet Error
QCI Priority Delay Example Services
Type Loss Rate
Budget
-6
6 Non-GBR 6 300 ms 10 Video (Buffered Streaming)
TCP-based (e.g. www, e-mail, chat,
ftp, p2p file sharing, progressive
video, etc.)
-3
7 Non-GBR 7 100 ms 10 Voice, Video (Live Streaming),
Interactive Gaming
-6
video, etc.)
-6
video, etc.)
As shown in the below call flow, a UE can use a specific service via user plane or request
QoS to a control plane. When using a specific service via user plane, the PCRF determines
dedicated barer setup and also determines appropriate QoS parameters such as GBR or
MBR, etc. according to service. When a UE requests QoS service via control plane, the
request is sent to the PCRF through the MME. The PCRF finally determines the
appropriate QoS parameters such as GBR or MBR, etc. according to service.
QoS bearer request by UE (Control Plane)

A UE can request QoS bearer to the MME through the Bearer Resource Allocation Request
message of NAS layer. Here, if the resource type of QCI is GBR, the UE can specify GBR
and MBR. However, the requested QoS information can be modified according to the
determination of PCRF. The final QoS parameters determined by the PCRF are sent to
PGW, SGW, or eNB and they support End-to-End QoS in the LTE system for a specific
bearer.

Feature Description
QoS request of UE (User Plane)

The below figure describes a case where a UE requests a specific service in the user plane.
For example, when a UE requests VoLTE service, the INVITE message is sent to the server
of the service and the server (For example, P-CSCF) requests appropriate QoS support to
the PCRF for a specific IP flow. When the PCRF finally approves the request, the QoS
information is sent to the QoS enforcement entity of user plane such as PGW, SGW, or
eNB, etc.

Feature Description
The MBR and GBR requests are occurred for a dedicated bearer whose resource type is
GBR. The eNB receives the MBR and GBR requests from the MME through the following
messages.
 Initial Context Setup Request
 E-RAB Setup Request
 E-RAB Modify Request
The eNB allocates wireless resources in highest priority for the GBR bearer to support
GBR.
The resources that the eNB can allocate for each cell are limited. Therefore, the eNB
cannot accommodate the QoS request of a UE without limit. It is necessary to judge if it is
possible to successfully support QoS for a new bearer by considering the wireless resource
amount available per cell and the QoS support status of existing UEs. Although a new GBR
bearer is allowed, the min. QoS quality request of existing GBR bearers must be satisfied.
The CAC function to guarantee QoS is supported by the QoS Based CAC function.
If the eNB cannot satisfy the minimum bit rate of GBR bearer, the eNB statistically collects
the information per QCI.

Feature Description
System operation
This function is working based on the value received through the S1AP. The eNB does
not have separate system operation related command or parameter.
N/A

N/A

N/A
Related Call Faults

N/A

Feature Description
LTE-SW4206, UE-AMBR Support

Overview
eNB limits the total bit rate (UE-AMBR) that a UE can achieve through its non-GBR
bearers. UE-AMBR parameter is delivered from MME to eNB during INITIAL CONTEXT
SETUP REQUEST or E-RAB SETUP REQEUST procedure.
Introduction
UE-AMBR parameters are set for each UE and used to limit the total data throughput used
by all non-GBR bearers of the UE. The operator can prevent a specific UE from
monopolizing the radio resource by properly setting the UE-AMBR parameters.
UE-AMBR is specified by MME and sent to eNB upon the request for INITIAL
CONTEXT SETUP. MME specifies the UE-AMBR to ensure that it does not exceed the
UE-AMBR parameter value set in the subscriber profile and a sum of all APN-AMBRs in
APNs accessible by the UE does not exceed UE-AMBR. However, MME may configure
the UE-AMBR differently according to the operator requirement. UE-AMBR is effective
until RRC connection is released, and MME can change it by sending a UE CONTEXT
MODIFICATION REQUEST or E-RAB MODIFY REQUEST message to eNB.
UE-AMBR is defined in UL or DL.
eNB limits the radio resource allocation so that the sum of throughput used by all Non-
GBR bearers in UE does not exceed the specified UE-AMBR. If a UE connects to multiple
non-GBR bearers, bearer to transfer the data is set according to priority of each non-GBR
bearer and throughput materialized by each non-BGR bearer up to now. If the radio
resources are sufficient, the needed radio resources are allocated regardless of UE-AMBR.
The data throughput of a GBR bearer is not limited by UE-AMBR.
Benefits
 By controlling UE-AMBR, operator can prevent a UE from overusing data over Non-
GBR bearers and monopolizing radio resources.
 Operator can differentiate subscribers by setting UE-AMBR differently per user
classes.
Release History
SLR2.2
Basic or Optional
Basic

Feature Description

Dependency:
 None
Limitation:
 None
Reference
Feature Scope
R1 If the radio resources are insufficient, eNB allocates the resources so that the total
throughput of the non-GBRl bearers to the UE does not exceed UE-AMBR.
R2 UE-AMBR is applied to UL and DL.
R3 If the resources are sufficient, they can be allocated in excess of UE-AMBR.
R4 Even when the non-BGR throughput of the UE is limited due to UE-AMBR, it should
not affect the resource allocation of GRR bearers in the same UE.
R5 If a UE has multiple non-GBR connections and limitation by UE-AMBR is needed,
the relative priorities of bearers are selected by the priority and throughput of bearer.
R5 eNB immediately applies the changed UE-AMBR when the UE-AMBR value in a
message received from MME after the INITIAL CONTEXT SETUP is changed.

Feature Description
Feature Description
UE-AMBR is specified by MME and sent to eNB. MME specifies UE-AMBR so that the
sum of all APN-AMBRs of APNs connectable by the UE does not exceed UE-AMBR.
Moreover, the MME ensures that it does not exceed UE-AMBR specified in the subscriber
profile. However, MME may configure the UE-AMBR differently according to the
operator requirement, and the eNB uses the received UE-AMBR.
UE-AMBR is defined in DL and UL in units of bps. (Refer to Section 9.2.1.20 of 3GPP
TS36.413.)
The UE-AMBR value is sent to the eNB through the following messages. The handover
request message can be received from a MME or source eNB. During an X2 handover, the
source eNB sends UE-AMBR to the target eNB. The eNB uses the final UE-AMBR
received in the following message.
 INITIAL CONTEXT SETUP REQUEST
 E-RAB SETUP REQUEST
 UE CONTEXT MODIFICATION REQUEST
 E-RAB MODIFY REQUEST
 E-RAB RELEASE COMMAND
 HANDOVER REQUEST
 PATH SWITCH REQUEST ACKNOWLEDGE
eNB’s radio scheduler schedules so that the total throughput of all non-GBR bearers in a
UE does not exceed UE-AMBR. Such operation is performed for UL and DL. Throughput
is the IIRFiltering average.

Feature Description
System operation
This function is executed on the basis of the value received through S1AP, and there is no
system operation related commands and parameters in eNB.

N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW4207, Max 8 Bearers per UE

Overview
Introduction
As the use of smart phones are increased, the environment under which users can perform
several tasks only with one UE has been created. For example, users can make a VoLTE
call at the same time while downloading a file by connecting to the Internet. At the time,
each application operated in the UE uses the network service requiring the different levels
of QoS. The user data for VoLTE is delay-sensitive and reliability is important for FTP
packets. The LTE transmits different packets with different QoS properties to different
bearers and the bearers provide the differentiated QoS services.
Samsung eNB supports up to 8 bearer connections in one UE. Up to 8 bearers are

supported per UE in 3GPP R8 and R9. Each bearer may be used as default bearer or
dedicated bearer. Each bearer provides QoS which has different QCI numbers and different
levels. The 3GPP standard supports up to 9 standard QCIs from 1 to 9. The eNB sets up a
bearer to UE at the request of INITIAL CONTEXT SETUP REQUEST, E-RAB SETUP
REQUEST, HANDOVER REQUEST, etc. from the MME.
Benefits
 Operator can provide a UE with 8 different kind of services at the same time, where
each service has different QoS characteristics such as QCI or ARP.
 A UE may have maximum 8 different kind of bearers at the same time. Each bearer
has different QoS characteristics such as QCI or ARP. This ensures better user
experience and fair allocation of radio resources to UE.
Release History
SLR 2.2
Basic or Optional
Basic

Feature Description

Dependency
 None
Limitation
 Maximum number of bearers is limited per cell or per eNB. The total number of
bearers that UEs connect cannot exceed the maximum number of bearers that eNB or a
cell allows.
Reference
2) 3GPP TS36.321 Evolved Universal Terrestrial Radio Access (E-UTRA); Medium
Access Control (MAC) protocol specification, Section 6.2.1
Feature Scope
 The eNB receives the INITIAL CONTEXT SETUP REQUEST message from the
MME and sets the default bearer. After that, the eNB sets up to 7 dedicated bearer
connections requested whenever it receives the E-RAB SETUP REQUEST message
from the MME.
 If the number of bearer connection connected by one UE exceeds 8, the eNB transmits
the REJECT message to the MME with appropriate cause values for the request.
 The eNB may set up to 8 bearer connections at a time at the same time through the
INITIAL CONTEXT SETUP REQUEST message or the E-RAB SETUP REQUEST
message.
 The eNB may set up to 8 bearer connections to one UE even though it is requested
through the HANDOVER REQEUST message.
 If the total number of bearer connections per cell or eNB exceeds the fixed limitation,
the eNB rejects the request of the bearer setup regardless of total number of bearer
connections of the UE. However, if the pre-emption function is operated, it is possible
to disconnect the bearer in a low priority.

Feature Description
Feature Description
The maximum number of data radio bearers allowed per UE is limited by the standard
3GPP TS36.321 MAC Protocol. For a logical chanel ID in the MAC layer, 1 to 10 may be
used but two among them are used for signaling radio bearers including SRB1, and SRB2.
For data bearers, the other 8 LCIDs may be used. Of course, to allocate up to 8 data radio
bearers to the UE, the UE must support these. The following table represents the
information on 3GPP TS36.321 Table 6.2.1-1 Values of LCID for DL-SCH:
Index LCID values
00000 CCCH
00001-01010 Identity of the logical channel
01011-11011 Reserved
11100 UE Contention Resolution Identity
11101 Timing Advance Command
11110 DRX Command
11111 Padding
The eNB based on Samsung SMBS Platform supports up to 10800 bearers per DU and up
to 1200 bearers per cell regardless of GBR/Non-GBR Bearer or Default Bearer/Dedicated
Bearer. In addition, the operator may limit the total number of UEs accessible per cell to
prevent call congestion. If the total number of bearer connections connected per cell
exceeds such limitation, even though there are less than 8 bearers of the UE, it is
impossible to set any bear connection.
The data radio bearer between the UE and the eNB is set by the request of the MME.
The MME triggers bearer connections through the messages such as INITIAL CONTEXT
SETUP REQUEST, E-RAB SETUP REQUEST, and HANDOVER REQUEST.
Through the X2 interface, the neighbor eNB may also transmit the HANDOVER
REQUEST message. Through each message, multiple radio bearers may be set at the same
time.

Feature Description
When the same UE sets up multiple bearer connection, the QCI number of each bearer is
different. If the QCI number is same, it is not necessary to set any separate bearer
connection because the same level of QoS service is provided.

Feature Description
System Operation
N/A

The statistics (counters) to confirm the number of connected bearers and the normal setup
of bearers are as follows:
ERABSetup If the Initial Context Setup Request Check at LSM Performance >
message is received, counts the statistics of Performance Statistics > ERAB
attempts by bearer and if the Initial Context > ERABSetup
Setup Response message is transmitted,
counts the statistics of successes by bearer.
ERABSetupAdd If the Initial Context Setup Request Check at LSM Performance >
message is received, counts the statistics of Performance Statistics > ERAB
attempts by bearer and if the Initial Context > ERABSetupAdd
Setup Response message is transmitted,
counts the statistics of successes by bearer.
Related Alarms
N/A
Related Status
N/A
Related Call Faults

ECC_TMOUT_ By sending the RRC Connection Check at LSM Performance >

rrcConnectionR Reconfiguration message to the UE, the Performance Statistics > CSL >
econfigurationC Bearer Setup request was performed but the CallFault
omplete RRC Connection Reconfiguration Complete
message from the UE could not be received.
ECC_TMOUT_ The Security Mode Command message was Check at LSM Performance >
rrcSecurityMod transmitted to the UE during the setup of the Performance Statistics > CSL >
eComplete bearer, but the response message Security CallFault
Mode Complete could not be received.

Feature Description
LTE-SW4208, QCI-based Throughput

Differentiation for Non-GBR Bearers
Overview
The weight factor is used by QCI to provide the service differentiated in terms of
throughput among the non-GBR bearers. The operator can use LSM to set the weight factor
of the standardized QCI and extended QCI whose resource type is defined as non-GBR.
Introduction
This function is used to differentiate throughput among the non-GBR bearers. The 3GPP
standard supports differentiating of the GBR resource type-bearers in terms of throughput
of each bearer such as GBR and MBR. However, the non-GBR resource type-bearers can
be differentiated only in terms of priority, packet delay budget, and packet loss error rate of
each QCI but not in terms of throughput. This function supports differentiating of non-
GBR bearers in terms of throughput also.
For that, eNB allows the operator to define and use the ‘weight factor’ for each QCI.
The wireless scheduler of eNB refers the weight factor defined for each QCI in order to
allocate more radio resources to the QCI bearers with higher weight factor than those with
lower weight factor. Thus a bearer having a weight factor of 2 can utilize twice throughput
than a bearer having a weight factor of 1 in the same wireless environment. The weight
factor value can be specified for not only the standard QCI but also the operator specific
QCI.
This function can be used for service based throughput differentiation. For example, if
QCI#8 allocated bearer is used when downloading from a specific server and the weight
factor of 2 is specified to the QCI#8, the download service using QCI#8 can offer twice
fast download service than a bearer with a weight factor of 1.
Benefits
Operator Benefits:
 Operator can support differentiated throughput for non-GBR OCI. In addition, it can
design various accounting plan according to QoS (even same service).
End User Benefits:

 User can enjoy premium service with fast speed in network congestion state
Release History
SLR 2.2
SLR 2.4

Feature Description
Basic or Optional
Basic

Dependency
 To use the operator specific QCI, UE and EPC must support the same QCI.
Limitation
 Up to 16 non-GBR QCIs including the standardized QCI are supported.
 Up to 16 from 1 to 16 incremented by 1 are supported for the weight factor.
Reference
Feature Scope
R1 The operator can set the weight factor of QCI whose resource type is non-GBR bearer
through the LSM.
R2 The operator must be able to set on or off the ‘QCI-based User Differentiation
between Non-GBR Bearers’ function.
R3 The weight factor should be specified between 1 and 16 in the unit of 1.
R4 UEs having the non-BGR bearers with the same weight factor must be able to realize
the same level throughput under the same radio condition.
R5 If non-GBR bearers having different weight factors exist in the same radio condition,
the throughput is differentiated according to the ratio of the weight factor.
(For example, an UE with a weight factor of 2 must be able to utilize twice
throughput than the one with a weight factor of 1.)

Feature Description
Feature Description
Wireless Resource Allocation with Consideration to Weight
The weight factor is the relative size of the amount of allocated resources. Under the same
wireless environment, the bearer with a weight factor of 2 is allocated twice wireless
resources than the bearer with a weight factor of 1. In result, if the wireless environment is
same and there are sufficient data to transmit, the throughput utilized by the each bearer is
the same as the ratio of the weight factor. If the wireless environment is different, the
throughput utilized by each bearer may not be proportional to the weight factor.
The wireless scheduler allocates wireless resources to the QCI#5 and GBR bearer first and
then allocates the remaining resources to the non-GBR bearers. The weight factors are
considered when allocating the wireless resources to the non-GBR bearers. The weight
factor is not used when allocating resources to GBR bearers. The default value ‘1’ is used
for the non-GBR QCI whose weight factor is specified. When a UE has multiple non-GBR
bear connections, the wireless scheduler allocates the resources after considering the
weight factor for each bearer.
When allocating the wireless resources, the weight factor is applied to both UL and DL.
If there are the sufficient resources, the weight factor does not limits the data transferred to
each bearer. However, the resource allocation by weight factor becomes effective when the
available resources are not insufficient compared to an amount of data. Therefore, bearers
with higher weight factor can particularly utilize relatively higher throughput under the
congested situation. Moreover, although the amount allocated at a specific moment may
not be proportional to the weight factor, the average amount of resource allocated to each
non-GBR bearer is proportional to the weight factor in the long term.

Feature Description
Weight Factor Range and Configuration

The operator specifies the weight factor of each non-GBR QCI through LSM. The operator
can also specify the weight factor of the specific QCI if the resource type is non-GBR.
The weight factor can be specified between 1 and 16 in the unit of 1. Therefore, up to 16
different weight factor levels can be specific for each QCI.
Consideration for Functional Optimization

As the number of non-GBR bearers increases, the throughput realized by each non-GBR
bearer decreases. In a congested situation particularly, throughput of the bearers with lower
weight factor can be seriously degraded by the bearers with higher weight factor.
Therefore, the maximum number of UEs allowed by a cell needs to be limited in order to
assure quality of the non-GBR bearers. Moreover, the effect on the bearers with lower
weight factor is bigger if the difference of weight factors among the non-GBR bearers is
greater.

Feature Description
System Operation
Command Description
CHG- Changes the parameter values needed to operate a logical channel. The bucket
LOCH-INF size duration, logical channel group ID, logical channel priority, non GBRPFWeight,
prioritized bit rate for each QCI can be changed.
QCI Range: 0~255 QCI (QoS Class Identifier) index.

Default: 0
PRIORITIZ Range: ci_kBps0,ci_kBps8, The parameter used for UE’s logical channel
ED_BIT_RA ci_kBps16, ci_kBps32, prioritization. It is a minimum transmission rate that
TE ci_kBps64, ci_kBps128, must be secured per logical channel.
ci_kBps256 The parameter by which UE increases the bucket
Default: ci_kBps8 for each logical channel.
- ci_kBps0: Prioritized Bit Rate of the QCI is 0
kBps.
kBps.
kBps.
kBps.
kBps.
kBps.
kBps.
- ci_prioritizedBitRate_infinity: Prioritized Bit Rate
of the QCI is infinity.

Feature Description
(Continued)
BUCKET_S Range: The parameter used for UE’s logical channel

IZE_DURA ci_bucketSizeDuration_ms50, prioritization. It determines the maximum length
TION ci_bucketSizeDuration_ms100, of a bucket per UE’s logical channel.
ci_bucketSizeDuration_ms150, - ci_bucketSizeDuration_ms50: Bucket Size
ci_bucketSizeDuration_ms300, Duration of the QCI is 50 ms.
ci_bucketSizeDuration_ms500, - ci_bucketSizeDuration_ms100: Bucket Size
ci_bucketSizeDuration_ms1000 Duration of the QCI is 100 ms.
Default: - ci_bucketSizeDuration_ms150: Bucket Size
ci_bucketSizeDuration_ms300 Duration of the QCI is 150 ms.
- ci_bucketSizeDuration_ms300: Bucket Size
Duration of the QCI is 300 ms.
LOGICAL_ Range: 1~16 The parameter used for UE’s logical channel
CHANNEL_ Default: 9 prioritization. It determines an allocation order
PRIORITY per logical channel. The range is from 1 to 16.
NON_GBR Range: 0~15 The non-GBR bearer’s proportional fairness
_WEIGHT Default: 1 weight per QCI. The threshold that is not applied
to a GBR bearer. The range is from 0 to 15.

N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW4210, SPID-based Throughput

Differentiation for Non-GBR UEs
Overview
Introduction
This function provides UE-based differentiated service. A relatively high throughput can be
allocated to the UE to which this function is used in the non-GBR bearer, compared to the
UE to which this function is not use. It gives no effect to the GBR bearer.
A UE to which this function is applied is determined in the MME (or HSS). The operator
can specify whether a subscriber is a gold user, silver user, or bronze user when the
operator registers the subscriber to the HSS. The MME notifies the eNB that the eNB that
the UE is a premium user through the SPID parameter during connection setup for the UE.
For this function, the eNB manages an internal mapping table between SPID and weight.
The operator can set and change the mapping table between SPID and weight through the
LSM. The operator can specify weights for up to 8SPID values. To a user for whom the
SPID is not set, the default weight value "1" is applied.
For more information about weight definition and service effect, refer to the feature
description in the LTE-SW4208.
This function can be enabled with the LTE-SW4208 feature. When the two features are
applied at the same time, theweight obtained by multiplying QCI-based weight value and
SPID-based weight value is applied to the UE. For example, when the weight is set to 2 for
QCI#8 bearer and a premium user of weight 3 uses QCI#8, the UE can get the effect of
weight 6.
Benefits
 Operator Benefits:
− Operator can support a differentiated service plan according to UE class such as
Gold User, Siver User, Bronze User. Thus, an operator can operate variously
charing plan according to UE class
 End User Benefits:
− User can enjoy a premium service even for non-GBR bearers.
Release History
SLR 2.4

 Dependency:
− The function can be enabled when interoperating with Samsung MME and HSS
 Limitation:

Feature Description
− The operator can define up to 8 user classes.
Feature Scope
R1 The operator can set or change the mapping table between SPID and weight value
through the LSM. The possible input range of SPID is 1-256.
R2 The operator can set and operate up to 8 user classes.
R3 When this function is enabled, the eNB determines a weight value according to the
SPID value provided by the MME. The eNB allocates resources to make the
throughput ratio between non-GBR UEs in the same wireless environment converged
into the average weight ratio as time passes.
R4 The weight value definition and usage are the same as those of LTE-SW4208.
R5 The LTE-SW4210 function must be able to be enabled with the LTE-SW4208
function simultaneously.
R6 When the LTE-SW4208 and LTE-SW4210 functions are used simultaneously in the
wireless scheduler, each weight value is multiplied for use and it should not exceed up
to 16.
R7 The function provides statistics on RRC_Connected users for each user class.
R8 This function (LTE-SW4210) can be turned on/off by the operator. When the function
is turned off, the eNB does not use the mapping table for SPID and weight values.
Reference
1) 3GPP TS36.413 Evolved Universal Terrestrial Radio Access (E-UTRAN) S1
Application Protocol(S1AP),
2) 3GPP TS36.300 Evolved Universal Terrestrial Radio Access (E-UTRAN); Overall
description; Stage 2

Feature Description
Feature Description
For more information about wireless resource allocation method considering weight,
weight value range, and configuration method, refer to the feature description explained in
the LTE-SW4208.
SPID and weight mapping table management through the LSM
To enable this function, the operator sets the mapping table between SPID and weight
through the LSM. The SPID value must be an effective value in the SPID value range, that
is transmitted by the MME to the eNB. If the MME does not specify a SPID value for the
UE or a SPID that is not set in the table is transmitted, the eNB applies the weight value
"1". This means that there is no special effect to the UE. The operator can define up to 8
user classes. The below table is an example of mapping table between SPID and weight.
Index SPID Weight
0 101 1
1 102 2
2 103 3
3 104 4
4 107 1
5 108 2
6 109 3
7 110 4
SPID transmission
The MME transmits a specific SPID value to the eNB through the S1 message (Initial
Context Setup or Context Modification Request) for a premium user.
Use of SPID value

The use of SPID value is defined in the 3GPP36.300 Annex I. The range of SPID value, i.e.
1-256, is defined in the standard. The SPID 129-256 is dedicated for a special purpose in
the standard and the SPID 1-128 is dedicated for operator specific purpose. However,
because the SPID values set in the above table are only used to determine weight values,
any SPID value within 1-256 can be used. In other words, although the SPID 254-256 is
used to determine the priority of a carrier between Inter-RAT in the standard, whether to
provide a certain weight to the UE can be defined in the mapping table between SPID and

Feature Description
weight. Although this function is enabled, the SPID 129-256 value is operating as defined
in the standard.
Simultaneous application of weight related functions
As well as this function, the LTE-SW4208 function provides the throughput differentiation
function that uses a weight. When the two functions are enabled simultaneously, the weight
for non-GBR bearer is calculated by multiplying the weight values of the two functions. If
the multiplied value is higher than 16, use the maximum vale 16.
Effective W = min(W1 x W2, 16)
The W1 is a SPID-based weight value used to the UE, and the W2 is a QCI-based weight
value used to the non-GBR QCI.
Consideration for function optimization

As the number of UEs is increases, the throughput realized by each UE decreases because
the limited wireless resource need to be shared. When the number of premium users with a
high weight value is increased under the congestion situation, a user with a low weight
value experiences extremely low level of throughput. Therefore, it is necessary to optimize
the number of users allowed for weight value level and cell by considering the QoS level of
the total UEs.
Because an effective weight value for a specific non-GBR bearer may be increased and
exceed maximum value when it is used with the LTE-SW4208 function, this must be
considered when designing the weight value.
The use of operator SPID value is varied depending on a service provider. Therefore, if the
operator SPID is used for another purpose, this function must be disabled.

Feature Description
System operation
Command Description
RTRV-
Retrieves the mapping table per cell to set non-GBR scheduling weight
SPIDPFWEIGHT-
per Subscriber Profile ID (SPID).
CONF
CHG-SPIDPFWEIGHT- Changes the mapping table per cell to set non-GBR scheduling weight
CONF per Subscriber Profile ID (SPID).
Default
Value
0~ 0
cellNum Cell Number
MAX_CELL_PER_SYS_CDD
SPID[8] Subscriber Profile ID[8] 0 ~ 256 100
non-GBR scheduling weight 0 ~ 16 1
PFWeightSPID[8]
per Subscriber Profile ID
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW5001, Multiple PLMN support

Overview
Introduction
Multiple-PLMN support allows provide LTE service to subscribers of multiple operators in
a cell concurrently.
For Multiple-PLMN support, eNB broadcasts multiple PLMN IDs which are sharing a cell
in system information and supports UE associated signaling with a UE and an appropriated
core network based on the PLMN which UE has selected.
Benefits
Operator can reduce CAPEX.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 None
Limitation:
 None
Reference
Resource Control (RRC) protocol specification
3) 3GPP TS23.251 Network Sharing; Architecture and functional description

Feature Description
Feature Scope
R1 eNB can support maximum 6 PLMNs per cell based on system configuration.
R2 eNB can broadcast the supporting PLMN ID list per cell via SIB1.
R3 eNB shall include the primary PLMN ID in the PLMN ID list per cell and it shall be
the first listed.
R4 eNB shall omit unavailable PLMN ID from the PLMN ID list per cell, except the
primary PLMN ID, when there is no connectivity with any MMEs which is serving
the PLMN.
R5 eNB shall use the selected PLMN ID by UE when MME selection and transfer it to
the selected MME.
R6 eNB shall use the serving PLMN and the equivalent PLMNs for a UE which are
received from MME for UE associated signaling.

Feature Description
Feature Description
eNB functions for Multiple-PLMN support are as follows:
 Broadcast multiple PLMN IDs (up to 6) in system information;
 Routing of signaling for call control based on the selected PLMN ID by UE;
 Inter-PLMN handover support in shared network; (Refer to LTE-SW5005)
 Radio resource sharing in shared cell. (Refer to LTE-SW5002)
In a shared cell, eNB broadcasts the supporting PLMN ID list up to 6 via SIB1.
The first listed PLMN shall be the same as the primary PLMN of eNB. The supporting
PLMN ID list per cell is configured by system parameter. UE shall be able to read up to 6
PLMN IDs, to select one of the PLMN IDs based on its selection process.
When UE is expected to make RRC connection with eNB, the selected PLMN ID by UE is
included in RRC Connection Setup Complete message. eNB uses this PLMN ID to select
the core network and, in turn MME, and to indicate towards appropriate core network
operator when transferring Initial UE Message.
Signaling procedures is as follows.

Feature Description
System operation
Related Commands
Command Description
RTRV-CELL-INFO This command is used to retrieve the information of a specific cell in an

eNB. Enter the CELL_NUM parameter value to retrieve the configuration
information of a specific cell.
CHG-CELL-INFO This command is used to change the information of a specific cell in an
eNB. Enter the CELL_NUM parameter value to specify a specific cell and
change its configuration information dynamically during its operation.
Related Parameters
The first PLMN ID broadcasted to SIB 1 must be set to the same as the PLMN ID of the
global eNB ID.
cellNum 0~MAC_CELL_ 0 Cell Number

PER_SYS_CDD
MCC0 DIGITSTR [3~3] (Usually the same Mobile Country Code (MCC) that
as the MCC of the comprises Public Land Mobile
Primary PLMN in Network (PLMN). It is broadcast to
Global eNB ID) UE via SIB 1 when cells are in
operation. Up to 6 PLMNs are sent
in PLMN list. MCC of PLMN #0,
one of the six lists, is entered.
MNC0 DIGITSTR [2~3] (Usually the same Mobile Network Code (MNC)
as the MNC of the
Primary PLMN in
Global eNB ID)
CELL_RESERVED_ ci_reserved ci_notReserved CellReservedOpUse of PLMN #0.
OP_USE0 ci_notReserved Broadcast to the UE through SIB.
- ci_reserved: Selection/re-
selection is reserved for UEs that
have a specific access class (AC)
to PLMN #0.
- ci_notReserved: Selection/re-
selection is available for UEs that
have all access class (AC) to
PLMN #0.

Feature Description
(Continued)
MCC1 DIGITSTR [3~3] FFF Mobile Country Code (MCC) that

comprises Public Land Mobile
Network (PLMN). It is broadcast to
UE via SIB 1 when cells are in
MNC1 DIGITSTR [2~3] FFF Mobile Network Code (MNC)
to PLMN #1.
PLMN #1.
to PLMN #0.
PLMN #0.

Feature Description
(Continued)

access class (AC) to PLMN#3.
PLMN#3.
Network (PLMN). It is broadcast to UE
via SIB 1 when cells are in operation.
Up to 6 PLMNs are sent in PLMN list.
MCC of PLMN #4, one of the six lists,
is entered.
have all access class (AC) to PLMN
#4.
Network (PLMN). It is broadcast to UE
via SIB 1 when cells are in operation.
Up to 6 PLMNs are sent in PLMN list.
MCC of PLMN #5, one of the six lists,
is entered.
CELL_RESERVED_ ci_reserved ci_notReserved CellReservedOpUse of PLMN #5
have all access class (AC) to PLMN
#5.

Feature Description

If the S1 backhaul of all MMEs that support a specific PLMN is disconnected, the PLMN
ID is not broadcasted to the SIB1 (The primary PLMN is always broadcasting).
Therefore, you must always check the S1 connection status.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW5002, Flexible Configuration for Radio

Resources Sharing
Overview
In MOCN architecture, eNB allocates radio resources (PRB, active UE capacity, bearer
capacity) to each PLMN id according to the radio sharing ratio configured by operator.
Operator can configure some portion of the resources dedicated to each operator and
remaining resources to be commonly shared between operators.
Introduction
In the Multiple Operator Core Network (MOCN) model where one radio spectrum is
shared by multiple operators, it is important to decide how the radio resources are shared.
Samsung eNB provides a highly flexible method of sharing and allocating radio resources
among operators. This makes it possible to employ various business models such as
integrated radio spectrum operation for operators, wholesaling of radio resources, and
usage-based pricing.
For sharing and distribution of radio resources, eNB supports three resource sharing
models: Full Common Sharing, Strict Separation, and Partial Common Sharing.
The Full Common Sharing method shares radio resources on a first-come-first-served basis
without differentiating operators. The Strict Separation method divides radio resources and
allocates certain parts to be used by specific operators only. The Partial Common Sharing
method is hybrid of the Full Common Sharing method and the Strict Separation method.
Some radio resources are shared among all operators while other radio resources are
allocated as dedicated resources to each operator. The operator can adjust the resource
allocation ratio for the operators and the MAC scheduler of the eNB uses this to adjust the
amount of resources allocated to each operator.
Such resource distribution is based on certain periods of time and peak throughput of the
UE is not restricted. Peak throughput of the UE depends on the air bandwidth allowed.
Radio resources can be shared among up to 6 operators.
Benefits
 Operator can wholesale a portion of spectrum by configuring some portion of radio
resources dedicated to a specific PLMN id.
 In MOCN, operator can highly utilize radio resources between different PLMNs by
configuring som portion of radio resources shared between them.
Release History
SLR2.2

Feature Description

Dependency:
 None
Limitation:
 Radio resources are shared among up to 6 operators.
Reference
1) 3GPP TS23.251, Network Sharing; Architecture and funtional description
2) 3GPP TS22.951, Service aspects and requirements for network sharing
Feature Scope
R1 The user must be able to use the LSM to set percentage of dedicated resources
allocated to each PLMN. The system allows settings for up to 6 PLMNs. Sum of all
resources allocated to all PLMNs must not exceed 100 %. If it is less than 100 %, the
remaining resources are allocated as common resources.
R2 The user can set Maximum Number of GBR Bearers and Maximum PRB Usage of
GBR Bearers for each PLMN.
R3 MAC scheduler of the eNB allocates resources for each operator based on the
dedicated resources set by the user. Dedicated resources allocated for a specific
PLMN are not allocated to other PLMN subscribers. However, common resources are
allocated on a first-come-first-served basis regardless of PLMNs.
R4 CAC of the eNB allocates and uses resources for each PLMN for maximum UEs and
bearer capacity supported by each cell based on the dedicated resource ratio set by the
user. Common resources are allocated on a first-come-first-served basis regardless of
PLMNs.
R5 In QoS based CAC, QoS support availability is determined based on the dedicated
resources set by the user for each PLMN.

Feature Description
Feature Description
Radio Resource Sharing Models
eNB supports the following three radio resource sharing models.
 Full Common Sharing of Resource: Dedicated resources are not allocated to each
operator and all resources are shared. Each operator uses resources on a first-come-
first-served basis as needed. The user enters 0 for resource sharing ratio for each
PLMN. This means that 100% of all resources within the system are used as common
resources.
 Strict Separation of Resource: All radio resources are divided and allocated to each
operator. Each operator can only use the portion of resources it is allocated.
Even when there are resources unused by other operators, these cannot be used.
 Partial Common Sharing of Resource: Some resources can be specified as a common
part to be shared among operators. The user can specify dedicated resources for each
PLMN and the remaining portion is allocated as common resources within the system.
Each operator can use common resources in addition to the dedicated resources it is
allocated. Common resources are allocated on a first-come-first-served basis.
The resource sharing ratio set by the user is applied when each scheduler allocates DL and
UL resources and when call admission control is performed for the UE or bearer.
For example, on a network with 20MHz of bandwidth, Operator A is allocated with 100
PRB x T x 40 %, accommodates 600UEs x 40 % per cell, and can use 1200 Bearers x 40 %
per cell.

Feature Description
QoS Issue
In case of congestion, contention over a resource occurs within the resource allocated to a
specific operator. In QoS based CAC, QoS support availability is determined based on the
dedicated resources allocated to each PLMN. For this, the user can set Maximum Number
of GBR Bearers and Maximum PRB Usage of GBR Bearers for each PLMN.

Feature Description
System operation
Command Description
CHG-NET-SHR Change/Retrieve Network sharing information

RTRV-NET-SHR
CHG-CELL-INFO Change/Retrieve Cell Info. Among various parameters, cell number and the
RTRV-CELL-INFO PLMN ID of the sharing networks are related to this feature.
Parameters Range Description
CellNum Cell Number Cell Number

PLMN0portion Range: 0~100 (%) 0~100 (%), DRC: sum (PLMN_i_portion) +
Default: CommonSharingPortion = 100
CHG-NET-SHR and RTRV-NET-SHR are used to
change and retrive the parameter.

Feature Description
(Continued)
CommonSh Range: 0~100 0~100 (%), DRC: sum (PLMN_i_portion) +

aring (%) CommonSharingPortion = 100
Portion Default: CHG-NET-SHR and RTRV-NET-SHR are used to change and
retrive the parameter.
mcc0 Mobile Country Mobile Country Code (MCC) that comprises Public Land Mobile
Code (MCC) Network (PLMN). It is broadcast to UE via SIB 1 when cells are in
Range: operation. A total of 6 PLMN lists are sent. MCC of PLMN #0, one
Default: of the six lists, is entered.
CHG-CELL-INFO and RTRV-CELL-INFO are used to change
and retrieve the parameter
mnc0 Mobie Network MNC that comprises PLMN. It is broadcast to UE via System
Code (MNC) Information Block (SIB) 1 when cells are in operation. A total of 6
Range: PLMN lists are sent. MNC of PLMN #0, one of the six lists, is
Default: entered.
mcc1 - Mobile Country Code (MCC) that comprises Public Land Mobile
Network (PLMN). It is broadcast to UE via SIB 1 when cells are in
operation. A total of 6 PLMN lists are sent. MCC of PLMN #1, one
mnc1 - MNC that comprises PLMN. It is broadcast to UE via System
Information Block (SIB) 1 when cells are in operation. A total of 6
PLMN lists are sent. MNC of PLMN #1, one of the six lists, is
entered.
entered.

Feature Description
(Continued)
CHG-CELL-INFO and RTRV-CELL-INFO are used to change and
retrieve the parameter
entered.
entered.
entered.

Feature Description

PRB_Usage (DL/UL) PRB usage (MAC) as PLMN Generate traffic by connecting UE

to each PLMN
Num_Active_UE_PLMN Number of active UEs per PLMN Connect UE to each PLMN
(average/Max) (average/maximum)
Num_Bearers_PLMN Number of ERABs per PLMN Set/release ERAB for each PLMN
(average/Max) (average/maximum)
CP_PACKET_PLMN Data traffic per PLMN (PDCP) Generate traffic by connecting UE
to each PLMN

N/A
Related Call Faults

N/A
Related Commands
CHG-NET-SHR CellNum Change/Retrieve Network sharing

RTRV-NET-SHR PLMN (0~5)portion information
CommonSharingPortion
CHG-CELL-INFO CellNum Change/Retrieve Cell Info. Among
RTRV-CELL-INFO mcc0~mcc5 various parameters, cell number
mnc0~mnc5 and the PLMN ID of the sharing
networks are related to this feature.

Feature Description
LTE-SW5005, Inter-PLMN Handover

Overview
Introduction
Inter-PLMN handover is mobility control functionality between cells that served PLMN is
different from each other.
Benefits
Operator can provide connected mobility to its subscribers within a shared network.
Users can obtain LTE service in other network operators’ area which is not the subscribed
network operator.
Release History
SLR2.2
Basic or Optional
Optional

Dependency:
 None
Limitation:
 None
Reference
3) 3GPP TS23.251 Network Sharing; Architecture and functional description

Feature Description
Feature Description
Inter-PLMN handover means that UE’s serving PLMN is changed before and after
handover.
The eNB uses the selected PLMN ID of UE (provided by the UE at RRC establishment, or,
provided by the MME/source eNB at S1/X2 handover) to select target cells for future
handovers appropriately.
When handover event is occurred, the source eNB determines a PLMN to be used in the
target cell based on current PLMN in use, or other information present in the eNB.
The selected target PLMN should be the same as the one in use. This is accomplished by
not changing the serving PLMN if the PLMN in use is supported in the target cell.
If the PLMN in use is not supported in the target cell the eNB selects the target PLMN
based on the Equivalent PLMNs list provided by the MME.
If current serving PLMN is available in the target cell the target PLMN shall be the same as
current serving PLMN. But if not, the source eNB checks whether inter-PLMN handover
can be possible based on the UE’s equivalent PLMNs.
The source eNB shall at handover indicate that selected target PLMN ID to the MME as
part of the selected TAI sent in the Handover Required message.
In case of inter-PLMN X2 handover, the source eNB shall replace the serving PLMN with
the identity of the selected target PLMN and move the current serving PLMN to the
equivalent PLMN list, before propagating the UE area restriction information.

Feature Description
Following figures show inter-PLMN X2 handover procedures.

Feature Description
Below figure is inter-PLMN S1 handover procedure.

Feature Description
System operation
RTRV-CELL-INFO cellNum The cell number to be changed or retrieved.

CHG-CELL-INFO cellSize The is cell size.
- ci_cellsize_verysmall: Very Small size cell
- ci_cellsize_small: Small size cell
- ci_cellsize_medium: Medium size cell
- ci_cellsize_large: Large size cell
hnbName[48] The name of the home eNB. Broadcast to the UE
through SIB (System Information Block) 9 when
the cell is operated as a CSG cell or as a hybrid
cell in bytes.
mcc0[4] Mobile Country Code (MCC) that comprises Public
Land Mobile Network (PLMN). It is broadcast to
UE via SIB 1 when cells are in operation. A total of
6 PLMN lists are sent. MCC of PLMN #0, one of
the six lists, is entered.
mnc0[4] MNC that comprises PLMN. It is broadcast to UE
via System Information Block (SIB) 1 when cells
are in operation. A total of 6 PLMN lists are sent.
MNC of PLMN #0, one of the six lists, is entered.
cellReservedOpUse0 CellReservedOpUse of PLMN #0. Broadcast to
the UE through SIB (System Information Block) 1.
for UEs that have a specific access class (AC) to
PLMN #0.
(AC) to PLMN #0.
mcc1[4] MCC that comprises PLMN. It is broadcast to UE
via SIB 1 when cells are in operation. A total of 6
PLMN lists are sent. MCC of PLMN #1, one of the
six lists, is entered.
PLMN lists are sent. MNC of PLMN #1, one of the

Feature Description
(Continued)
RTRV-CELL-INFO cellReservedOpUse1 cellReservedOpUse of PLMN #1. It is broadcast to

CHG-CELL-INFO UE via SIB 1.
(AC) to PLMN #1.
cellReservedOpUse2 cellReservedOpUse of PLMN #2. It is broadcast to
UE via SIB 1.
(AC) to PLMN #2.
UE via SIB 1.
(AC) to PLMN #3.

Feature Description
(Continued)
RTRV-CELL-INFO mnc4[4] MNC that comprises PLMN. It is broadcast to UE

CHG-CELL-INFO via SIB 1 when cells are in operation. A total of 6
UE via SIB 1.
(AC) to PLMN #4.
mcc5[4] Mobile Country Code (MCC) that comprises
PLMN.
It is broadcast to UE via SIB 1 when cells are in
operation. A total of 6 PLMN lists are sent. MCC of
PLMN #5, one of the six lists, is entered.
UE via SIB 1.
for UEs that have a specific access class (AC) to
PLMN #5.
(AC) to PLMN #5.
addSpectrumEmission Additional spectrum emission used by the active
cell. At max power, UE can additionally reduce
power. See 6.2.4 in 3GPP TS 36.101.
This information is broadcast to UE via SIB 2.
trackingAreaCode TAC (Tracking Area Code) used by the active cell.
It is used for warning message transmission and
interruption when paging the UE. This information
is broadcast to UE via SIB 1.
imsEmergencySupport supports IMS (IP Multimedia Subsystem)
emergency calls. This information is broadcast to
UE via SIB 1.
- False: The cell in operation does not support IMS
Emergency.
- True: The cell in operation supports IMS
Emergency.

Feature Description
(Continued)
RTRV-NBR-ENB nbrEnbIndex Index of the neighboring eNB. The value entered

CHG-NBR-ENB when registering the neighboring eNB is used.
CRTE-NBR-ENB status The validity of the neighboring eNB information.
DLT-NBR-ENB - N_EQUIP: Invalid.
- EQUIP: Valid.
noX2 Whether to make X2 connection to the
neighboring eNB.
- False: X2 connection with the neighboring eNB is
made.
- True: X2 connection to the neighboring eNB is
not made.
noHO Whether to perform handover to the neighboring
eNB.
- False: Handover to the neighboring eNB is
performed.
- True: Handover to the neighboring eNB is not
performed.
enbId The eNB ID represents the neighboring eNB. If the
enbType value is macro eNB, 20 bit of the value is
eNB ID. If the enbType value is home eNB, 28 bit
of the value is eNB ID.
enbMcc[4] The PLMN information (MCC) that represents the
neighboring eNB. It is a three-digit number with
enbMnc[4] The PLMN information (MNC) that represents the
neighboring eNB. It is a three-digit or two-digit
ipVer The IP version, which is the IP address of the
neighboring eNB.
nbrEnbIPv4 Enter the IP address of the neighboring eNB in the
IP version 4 format.
nbrEnbIPv6[16] Enter the IP address of the neighboring eNB in the
IP version 6 format.
secondaryNbrEnbIPv4 Enter the secondary IP address of the neighboring
eNB in the IP version 4 format.
secondaryNbrEnbIPv6 Enter the secondary IP address of the neighboring
[16] eNB in the IP version 6 format.

Feature Description
(Continued)
RTRV-NBR-ENB ownerType This parameter defines how NRT is updated, This

CHG-NBR-ENB filed can be classfied Initial NRT/ANR by
CRTE-NBR-ENB Server/ANR by UE/Created by User
DLT-NBR-ENB Command/CreatedByUserUI.
remoteFlag This parameter defines the target eNB is managed
local EMS or other EMS
RTRV-NBR-EUTRAN cellNum The cell number to be changed.
CHG-NBR-EUTRAN relationIdx Database index of E-UTRAN neighboring cell.
CRTE-NBR-EUTRAN
status The validity of the E-UTRAN neighboring cell
DLT-NBR-EUTRAN
information.
- N_EQUIP: The E-UTRAN neighboring cell
information is invalid.
- EQUIP: The E-UTRAN neighboring cell
enbId The eNB ID of the eNB to which E-UTRAN
neighboring cell to the eNB belongs. If the
enbType value is macro eNB, 20 bit of the value is
eNB ID. If the enbType value is home eNB, 28 bit
of the value is eNB ID. It is used when creating a
cell identifier.
femtoIndicator The femto indicator of E-UTRAN neighbor cell.
- True: Femto cell.
- False: Marco cell.
virtualIndicator The cloud indicator of E-UTRAN neighbor cell.
- True: Cloud macro cell.
- False: General macro cell.
targetCellNum The local cell ID of E-UTRAN neighboring cell to
the eNB. It is used when creating a cell identifier.
enbType The type of the eNB to which E-UTRAN
neighboring cell to the eNB belongs.
enbMcc[4] The PLMN information (MCC) of the eNB to which
E-UTRAN neighboring cell to the eNB belongs.
It is a three-digit number with each digit being from
0 to 9.
enbMnc[4] The PLMN information (MNC) of the eNB to which
E-UTRAN neighboring cell to the eNB belongs.
It is a three-digit or two-digit number with each
digit being from 0 to 9.
phyCellId The physical cell ID of E-UTRAN neighboring cell
to the eNB.

Feature Description
(Continued)
RTRV-NBR-EUTRAN tac The tracking area code of E-UTRAN neighboring

CHG-NBR-EUTRAN cell to the eNB.
CRTE-NBR-EUTRAN mcc0[4] The broadcast PLMN list information (MCC) of E-
DLT-NBR-EUTRAN UTRAN neighboring cell to the eNB. It is a three-
mnc0[4] The broadcast PLMN list information (MNC) of E-
digit or two-digit number with each digit being from
0 to 9.
mcc1[4] The broadcast PLMN list information (MCC) of E-
0 to 9.
0 to 9.
0 to 9.
0 to 9.

Feature Description
(Continued)
RTRV-NBR-EUTRAN mnc5[4] The broadcast PLMN list information (MNC) of

CHG-NBR-EUTRAN E-UTRAN neighboring cell to the eNB. It is a
CRTE-NBR-EUTRAN three-digit or two-digit number with each digit
DLT-NBR-EUTRAN being from 0 to 9.
earfcnUl The uplink EARFCN (E-UTRAN Absolute Radio
Frequency Channel Number) of E-UTRAN
earfcnDl The uplink EARFCN (E-UTRAN Absolute Radio
Frequency Channel Number) of E-UTRAN
bandwidthUl The uplink bandwidth of E-UTRAN neighboring
cell to the eNB.
bandwidthDl The downlink bandwidth of E-UTRAN
indOffset The cell individual offset to be applied to E-
UTRAN neighboring cell to the eNB. It is used
for UE measurement in RRC Connected mode.
qoffsetCell The cell quality offset to be applied to E-
UTRAN neighboring cell to the eNB. It is used
for UE cell re-selection in RRC Idle mode.
isRemoveAllowed Whether to delete a certain neighboring cell to
the eNB using the ANR (Automatic Neighbor
Relation) function.
isHOAllowed Whether to perform handover to E-UTRAN
neighboring cell.
ownerType This parameter defines how NRT is updated,
This filed can be classfied Initial NRT/ANR by
Server/ANR by UE/Created by User
RTRV-NET-SHR cellNum This parameter defines cell number.
CHG-NET-SHR PLMN0portion This parameter is portion of PLMN0.
PLMN1portion This parameter is portion of PLMN1.
CommonSharingPortion This parameter is portion of common

Feature Description
(Continued)
RTRV-ENB-INF dbIndex Index for retrieving the eNB information.

CHG-ENB-INF The default is 0.
enbType This parameter defines eNB Type (Macro eNB (0).
Home eNB (1))
enbName[150] This parameter defines the Representative ENB
Name
enbreserved[2] reserved parameter for byte align
enbMcc[4] This parameter defines the Representative
PMNN’s MCC information
enbMnc[4] This parameter defines the Representative
PMNN’s MNC information
enbId This parameter defines eNB ID (Macro eNB: BIT
STRING (20), Home eNB: BIT STRING (28))
ipVer The IP address version of the eNB.
enbIPv4 The IPv4 address of the eNB (Valid only if IP_VER
is IPv4. Not used if IP_VER is IPv6.).
enbIPv6[16] The IPv6 address of the eNB (Valid only if IP_VER
is IPv6. Not used if IP_VER is IPv4.).
sctpPortNumS1 The port number to be used in SCTP association
configuration for S1AP with the MME. (The port
number is fixed at 36412. SCTP association is
possible only when the port value is the same as
SCTP of the MME.)
sctpPortNumX2 The port number to be used in SCTP association
configuration for X2AP with the neighbor eNB.
(The port number is fixed at 36422. SCTP
association is possible only when the port value is
the same as SCTP of the neighbor eNB.)
bhLinkCapacity Total backhaul link capacity of the eNB (in Kbps, 0-
10G, default 1G).
dlCrsPortCount This Parameter decided by fourCrs Function is
applied.
RTRV-MME-CONF mmeIndex The index used to access the information. Since
CHG-MME-CONF there are a total of 16 MMEs that can be
connected to an eNB, the index range is 0 to 15.
status The EQUIP status information on the MME.
- N_EQUIP: The MME to connect does not exist
(default).
- EQUIP: The MME to connect exists.

Feature Description
(Continued)
RTRV-MME-CONF activeState The state information on the specified MME in

CHG-MME-CONF operation. Of the MMEs for which the S1 Setup is
established, if there is an undesired MME, this
parameter value must be changed to Inactive.
The default is active. If the STATUS parameter is
set to Equip, it is better not to change this
parameter value to inactive.
- Active: MME (S1 assigned) is used.
- Inactive: MME (S1 assigned) is not used.
ipVer The IP address version of the MME. Either IPv4
or IPv6 is assigned.
mmeIPv4 Information on the IPV4 address of the MME.
mmeIPv6[16] Information on the IPV6 address of the eNB.
administrativeState The status of the MME link.
- locked: A state where active calls connected to
the MME are all dropped, and new call
connections are not possible.
- shutting down: A state where active calls
connected to the MME are maintained, but new
call connections are not possible.
secondaryMmeIPv4 The secondary IP address of the IPv4 type set in
the MME node to support the SCTP Multi Homing
function. It is valid only if the IP_VER parameter
is set to IPv4.
secondaryMmeIPv6[16] The secondary IP address of the IPv6 type set in
the MME node to support the SCTP Multi Homing
function. It is valid only if the IP_VER parameter
is set to IPv6.
mmeMcc[4] The PLMN information (MCC) that represents the
MME. It is a three-digit number with each digit
being from 0 to 9.
mmeMnc[4] The PLMN information (MNC) that represents the
MME. It is a three-digit or two-digit number with

Feature Description
Related Counters
Refer to the intra-LTE handover related counters
 Intra-eNB handover (Refer to LTE-SW1003)
 S1 handover (Refer to LTE-SW1004)
 X2 handover (Refer to LTE-SW1005)
 Inter-frequency handover (Refer to LTE-SW1007)
Category Family TypeName Type Description
Packet Air Mac UL/DL AirMac_byteUI Total size of MAC PDU successfully received
Statistics byte (Kbytes) to PUSCH during the statistic cycle
(PLMN) AirMac_ByteUl Frequency of AirMacByteUl
Cnt
AirMac_TtiUl Total of zones that MAC PDU exist which
successfully received to to PUSCH during the
statistic cycle
AirMac_UlThru Average size per second of MAC PDU
successfully received to PUSCH
AirMac_UlEfcti Average size of MAC PDU in the zone where it
vThru is successfully received to PUSCH during the
statistic cycle
AirMac_ByteDl Total of DCCT/DTCH MAC PDU Size that
receives HARQ ACK among the MAC PDUs
sent to PUSCH during the statistic cycle
AirMac_ByteDl Frequency of collected AirMacByteDl
Cnt
AirMac_TtiDl Total of zones that MAC PDU exist which
successfully sent to to PUSCH during the
statistic cycle
AirMac_DlThru Average size per second of DCCT/DTCH MAC
PDU that receives HARQ ACK among the
MAC PDUs sent to PUSCH during the statistic
cycle
AirMac_DlEfcti Average size of MAC PDU in the zone where it
vThru is successfully sent to PUSCH during the
statistic cycle
AirMac_ByteUl Most recently collected AirMacByteUl value
Current
AirMac_ByteDl Most recently collected AirMacByteUl value
Current
AirMac_UlThru Min value of average size per second of MAC
Min PDUs successfully received to PUSCH

Feature Description
(Continued)
Packet Air Mac UL/DL AirMac_UlThru Max value of average size per second of MAC
Statistics byte (Kbytes) Max PDUs successfully received to PUSCH
(PLMN) AirMac_DlThru Min value of average size per second of
Min DCCT/DTCH MAC PDUs that receives HARQ
ACK among MAC PDUs sent to PDSCH
during the statistic cycle
AirMac_DlThru Max value of average size per second of
Max DCCT/DTCH MAC PDUs that receives HARQ
ACK among MAC PDUs sent to PDSCH
during the statistic cycle
Air RLC UL/DL AirRlcByteUl_ Bytes Air RLC uplink bytes
bytes (bytes) PLMN0 The uplink bytes by RLC. Collects per cell, QCI
(PLMN) and PLMN for the data byte received from the
terminal.
AirRlcByteUl_ Air RLC uplink bytes
PLMN1 The uplink bytes by RLC. Collects per cell, QCI
and PLMN for the data byte received from the
terminal.
terminal.
terminal.
terminal.
terminal.
AirRlcByteDl_ Air RLC downlink bytes
PLMN0 The downlink bytes by RLC. Collects per cell,
QCI and PLMN for the data byte received from
the terminal.
the terminal.

Feature Description
(Continued)
Packet Air RLC UL/DL AirRlcByteDl_ Air RLC downlink bytes

Statistics bytes (bytes) PLMN1 The downlink bytes by RLC. Collects per cell,
(PLMN) QCI and PLMN for the data byte received from
the terminal.
the terminal.
the terminal
the terminal.
AirRlcByteDlR Air RLC downlink ReTx bytes
e_PLMN0 The downlink bytes by RLC. Collects per cell,
the terminal
the terminal.
the terminal
the terminal.
the terminal.
the terminal.
AirUlThru_PL Air uplink throughput
MN0 Uplink throughput. Collects per cell, QCI and
PLMN for the data received from the terminal

Feature Description
(Continued)
Packet Air RLC UL/DL AirUlThru_PL Air uplink throughput

Statistics bytes (bytes) MN1 Uplink throughput. Collects per cell, QCI and
(PLMN) PLMN for the data received from the terminal.
PLMN for the data received from the terminal.
MN3 (Uplink) Uplink throughput. Collects per cell,
QCI and PLMN for the data received from the
terminal.
PLMN for the data received from the terminal
PLMN for the data received from the terminal.
AirDlThru_PL Air downlink throughput
MN0 Downlink throughput. Collects per cell, QCI
and PLMN for the data received from the
terminal
terminal.
terminal.
terminal.
terminal
terminal.

Feature Description
(Continued)
Packet Air RLC UL/DL AirRlcByteUlC Most recently collected AirRlcByteUl value
Statistics bytes (bytes) urrent_PLMN0
(PLMN) AirRlcByteUlC Most recently collected AirRlcByteUl value
urrent_PLMN1
AirRlcByteUlC Most recently collected AirRlcByteUl value
urrent_PLMN2
urrent_PLMN3
urrent_PLMN4
urrent_PLMN5
AirRlcByteDlC Most recently collected AirRlcByteUl value
urrent_PLMN0
urrent_PLMN1
urrent_PLMN2
urrent_PLMN3
urrent_PLMN4
urrent_PLMN5
AirRlcByteUlC AirRlcByteUl collection frequency
nt_PLMN0
nt_PLMN1
nt_PLMN2
nt_PLMN3

Feature Description
(Continued)
Packet Air RLC UL/DL bytes AirRlcByteUlCnt_ AirRlcByteUl collection frequency

Statistics (bytes) (PLMN) PLMN4
AirRlcByteUlCnt_ AirRlcByteUl collection frequency
PLMN5
AirRlcByteDlCnt_ AirRlcByteDl collection frequency
PLMN0
PLMN1
PLMN2
PLMN3
PLMN4
PLMN5
AirUlThruMin_PL Air uplink throughput Min
MN0
MN1
MN2
MN3
MN4
MN5
AirUlThruMax_PL Air uplink throughput Max
MN0
MN1
MN2
MN3
MN4
MN5
AirDlThruMin_PL Air downlink throughput Min
MN0

Feature Description
(Continued)
Packet Air RLC UL/DL AirDlThruMin_PLMN Air downlink throughput Min

Statistics bytes (bytes) 1
(PLMN) AirDlThruMin_PLMN Air downlink throughput Min
2
AirDlThruMin_PLMN Air downlink throughput Min
3
4
5
AirDlThruMax_PLM Air downlink throughput Max
N0
N1
N2
N3
N4
N5
RRU DL/UL Total PRB TotPrbDl_PLMN Resource amount used for PDSCH/
Usage (PLMN) PDCCH transmission of total downlink
resource amount per PLMN
TotPrbDlMin_PLMN TotPrbDl_PLMN min value
TotPrbDlMax_PLMN TotPrbDl_PLMN max value
TotPrbDlTot_PLMN TotPrbDl_PLMN total
TotPrbDlCnt_PLMN TotPrbDl_PLMN collection frequency
TotPrbUl_PLMN TotPrbDl_PLMN collection frequency
TotPrbUlMin_PLMN TotPrbUl_PLMN min value
TotPrbUlMax_PLMN TotPrbUl_PLMN max value
TotPrbUlTot_PLMN TotPrbUl_PLMN total
TotPrbUlCnt_PLMN TotPrbUl_PLMN collection frequency
TotPrbDlCurrent_PL DL Total Current PRB Usage per PLMN
MN
TotPrbUlCurrent_PL UL Total Current PRB Usage per PLMN
MN

Feature Description
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

Feature Description
LTE-SW5007, Usage Report per PLMN

Overview
Introduction
The MOCN (Multiple Operator Core Network) has the RAN structure where multiple
partner operators share one spectrum and the MORAN (Multiple Operator Radio Access
Network) has the RAN structure where each partner operator uses each dedicated
frequency but shares eNB. In general, one host operator manages the RAN in the MOCN
or MORAN structure, and other partner operators provides services for users simply
through the RAN. Accordingly, the host operator may check how many data are used by
how many users through the statistical information, but it is difficult for the partner
operators to check it without any help of the host operator.
This feature is a function to collect data usage by PLMN ID in the eNB to provide the data
usage information for each partner operator. The information collected by the eNB is
transmitted to the LSM, through which the provider can check the data usage information
used by the partner operators.
The method for providing data usage for each partner operator in the LSM is not described
in this feature.
Benefits
 Host operator can figure out how much data is consumed by each partner operator.
 The usage data can be utilized for the purpose of settlement among partner operators.
Release History
SLR 2.2
Basic or Optional
Basic

Dependency
 In addition to eNB, LSM should support this feature.
Limitation
 This feature is valid in MOCN or MORAN network architecture, where multiple
operators share single spectrum or a base station.

Feature Description
Reference
N/A

Feature Description
Feature Description
Network Management for RAN Sharing
In the RAN sharing structures such as MOCN or MORAN, the host operator is responsible
for RAN management. The host operator manages the fault, configuration, administration,
performance, statistics and others of the RAN shared with partner operators through the
LSM. The partner operators control the RAN through the host operator rather than
changing the system parameter by directly accessing to the RAN.
In the network structure, the statistical information that a partner operator is interested in is
connected by PLMN ID. The collected information is stored periodically in the LSM and
the LSM manages such usage data by PLMN ID.
If holding each EMS client, the partner operators may collect the information required by
accessing to the LSM of the host operator through the MS client. At the time, the access
level of the EMS client is decided through the discussion between the host operator and
partner operators. (This function is available through the discussion with the provider if the
LSM opens the interface.)
The information collected by PLMN ID in the eNB is as follows:

Feature Description
Feature Scope
 If the call setup procedure is completed, the call processing block informs the PLMN
information to the usage report block.
 At the handover procedure, as the serving eNB delivers the PLMN ID information of
the UE to the target eNB, the usage report blocks in the target eNB through the target
eNB call processing block come to identify PLMN information.
 The usage report by PLMN collects the following items:
− RRC Connection Number: The number of set RRC connections
− E-RAB Number: The number of set ERABs
− Packet statistics: The number of bytes in the PDCP packets transmitted and
received between eNB and SGW
− DL/UL Total PRB Usage: The usage of physical resource blocks allotting traffic
and control
− Protocol Message: The number of transmitted and received S1, X2, RRC messages
 The LSM separates and stores information by PLMN.

Feature Description
System Operation
N/A

OM Groups OM Registers OM Definition
RRC ConnNo_PLMN The average value of the number of RRC

Connection Connection periodically collected
number ConnMax_PLMN The maximum value of ConnNo_PLMN
(PLMN)
E-RAB UsageNbr_PLMN Average E-RAB count per unit time
Simultaneous UsageNbrMax_PLMN Maximum E-RAB count per unit time
Number
UsageNbr_QCI_x Average E-RAB count per unit time (QCIx)
(PLMN)
UsageNbrMax_QCI_x Maximum E-RAB count per unit time (QCIx)
S-GW UL/DL ByteUleNBQCI_QCIx Bytes of user of QCI (x) data sent from the eNB to
packets the S-GW
(PLMN) ByteDleNBQCI_QCIx Bytes of user of QCI (x) data sent from the S-GW to
the eNB
DL/UL Total TotPrbDl_PLMN Total PRB Usage for PDSCH/PDCCH transmission
PRB Usage per PLMN
(PLMN) TotPrbDlMin_PLMN TotPrbDl_PLMN Minimum
TotPrbDlMax_PLMN TotPrbDl_PLMN Maximum
TotGbrPrbDl_PLMN Total PRB Usage for Downlink GBR traffic
transmission per PLMN
TotGbrPrbDlMin_PLMN TotGbrPrbDl_PLMN Minimum
TotGbrPrbDlMax_PLMN TotGbrPrbDl_PLMN Maximum
TotNGbrPrbDl_PLMN Total PRB Usage for Downlink non-GBR traffic
TotNGbrPrbDlMin_PLMN TotNGbrPrbDl_PLMN Minimum
TotNGbrPrbDlMax_PLMN TotNGbrPrbDl_PLMN Maximum
TotPrbUl_PLMN Total PRB Usage for PUSCH transmission per
PLMN
TotPrbUlMin_PLMN TotPrbUl_PLMN Minimum
TotPrbUlMax_PLMN TotPrbUl_PLMN Maximum
TotGbrPrbUl_PLMN Total PRB Usage for Uplink GBR traffic transmission
per PLMN

Feature Description
(Continued)
OM Groups OM Registers OM Definition
DL/UL Total TotGbrPrbUlMin_PLMN TotGbrPrbUl_PLMN Minimum

PRB Usage TotGbrPrbUlMax_PLMN TotGbrPrbUl_PLMN Maximum
(PLMN)
TotNGbrPrbUl_PLMN Total PRB Usage for Uplink non-GBR traffic
TotNGbrPrbUlMin_PLMN TotNGbrPrbUl_PLMN Minimum
TotNGbrPrbUlMax_PLMN TotNGbrPrbUl_PLMN Maximum
PROTOCOL_ RrcMsgSnd sent the number of times in the RRC Protocol Msg
MSG eNB
RrcMsgRcv the number received in the RRC Protocol Msg eNB
S1MsgSnd sent the number of times in the S1AP Protocol Msg
eNB
S1MsgRcv the number received in the S1AP Protocol Msg eNB
X2MsgSnd sent the number of times in the X2AP Protocol Msg
eNB
X2MsgRcv the number received in the X2AP Protocol Msg eNB
Related Alarms
N/A
Related Status
N/A
Related Call Faults

N/A

ABBREVIATION
ABBREVIATION
A
A-GNSS Assisted Global Navigation Satellite Systems
ANR Automatic Neighbour Relation
APN-AMBR Access Point Name Aggregate Maximum Bit Rate
ARP Allocation and Retention Priority
C
CAC Call Admission Control
CC Counter Collected
CCE Control Channel Element
CDD Cyclic Delay Diversity
CFI Control Format Indicator
CGI Cell group Identifier
CIO Cell Individual Offset
CQI Channel Quality Indicator
CRC Cyclic Redunduncy Check
C-RNTI Cell Radio Network Temporary Identifier
CRS Cell-specific Reference Signal
CSG Closed Subscriber Group
D
DCI Downlink Control Information
DL Downlink
DRB Data Radio Bearer
DRX Discontinuous Reception
DRX Discrete Reception

ABBREVIATION
E
ECGI E-UTRAM Cell Global Identifier
EMM Evolved Mobility Management
eNB Evolved Node B
EPRE Energy Per Resource Element
EPS Evolved Packet System
E-RAB E-UTRAN Radio Access Bearer
ES Energy Saving
E-SMLC Enhanced Serving Mobile Location Centre
E-UTRAN Evolved UTRAN
F
FDD Frequency Division Duplexing
G
GBR Guaranteed Bit Rate
GLONASS Global Orbiting Navigation Satellite System
GPS Global Positioning System
GTP GPRS Tunneling Protocol
GTP-C GTP Control
GTP-U GTP User
GUI Graphical User Interface
GUMMEI Globally Unique MME Identifier
H
HARQ Hybrid Automatic Repeat reQuest
HO Handover
HRPD High Rate Packet Data
I
IE Information Element
IIR Infinite Impulse Response
IMS IP Multimedia Subsystem
IRC Interference Rejection Combining
K
KPI Key Performance Indicator

ABBREVIATION
L
LB Load Balancing
LPP LTE Positioning Protocol
LSM LTE System Manager
LSM-R LTE System Manager-Radio Access
M
MBMS Multimedia Broadcast Multicast Service
MBR Maximum Bit Rate
MBSFN Multicast Broadcast Single Frequency Network
MCS Modulation and Coding Scheme
MLB Mobility Load Balancing
MME Mobility Management Entity
MMSE Mimimum Mean Square Error
MR Measurement Report
MRO Mobility Robustness Optimization
N
NAS Non-Access Stratum
NBR Nominal Bit Rate
NCL Neighbouring Cell List
NDI New Data Indicator
NR Neighbor Relation
NRT Neighbor Relation Table
OFDMA Orthogonal Frequency Division Multiple Access
P
PBSH Physical Broadcast CHannel
PCFICH Physical Control Format Indicator Channel
PCID Physical Cell ID
PDCCH Physical Downlink Control CHannel
PDCP Packet Data Convergence Protocol
PDNGA Packet Data Network GateWay
PDSCH Physical Downlink Shared CHannel
PDU Protocol Data Unit
PF Paging Frame
PLMN Public Land Mobile Network
PMI Precode Matrix Indicator
PO Paging Occasion
PRACH Physical Random Access Channel
PRB Physical Resource Block
PRB Physical Resource Block
PUSCH Physical Uplink Shared CHannel

ABBREVIATION
Q
QCI QoS Class Indicator
QoS Quality of Service
R
RAR Random Access Response
RA-RNTI Random Access Radio Network Temporary Identifier
RAT Radio Access Technology
RB Resource Block
RBG Resource Block Group
REG Resource Element Group
RI Rank Indicator
RIV Resource Indication Value
RLC Radio Link Control
RLF Radio Link Failure
RRC Radio Resource Control
RS Reference Signal
RV Redunduncy Version
S
S1AP S1 Application Protocol
SC Selection Combining
SC-FDMA Single Carrier Frequency Division Multiple Access
SCTP Stream Control Transmission Protocol
SGW Serving GateWay
SIR Signal to Interference Ratio
SM Spatial Multiplexing
SON Self-Organizing Networks
SRS Sounding Reference Signal
S-TMSI S-Temporary Mobile Subscriber Identity
T
TAC Tracking Area Code
TAI Tracking Area Identity
TB Transport Block
TM Transmission Mode
TTI Transmission Time Interval
TTT Time-To-Trigger

ABBREVIATION
U
UE User Equipment
UE-AMBR UE Aggregate Maximum Bit Rate
UL Uplink
UTRA Universal Terrestrial Radio Access
UTRAN Universal Terrestrial Radio Access Network
VoIP Voice over Internet Protocol
X
X2 Control plane between eNBs in E-UTRAN

LTE eNB (SLR 2.4)

Feature Description
©2013 Samsung Electronics Co., Ltd.

All rights reserved.
Information in this manual is proprietary to SAMSUNG

Electronics Co., Ltd.
No information contained here may be copied, translated,
transcribed or duplicated by any form without the prior written
consent of SAMSUNG.
Information in this manual is subject to change without notice.

LTE ENB Feature Description SLR 2 4 V2 0 en PDF 1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

LTE ENB Feature Description SLR 2 4 V2 0 en PDF 1

Transféré par

Droits d'auteur :

Formats disponibles

2600-00FBQLGAP Ver. 2.

LTE eNB (SLR 2.4)

©2013 SAMSUNG Electronics Co., Ltd. All rights reserved.

Technology Software Release

LTE SLR 2.4

Feature Description features across a Samsung telecommunications

© SAMSUNG Electronics Co., Ltd. page 3 of 1021

System Parameter Description system parameters used in the product.

2.0 02. 2013. - Add SLR 2.4 features

© SAMSUNG Electronics Co., Ltd. page 4 of 1021

COM-ET0101, VLAN Tagging .............................................................................................................10

COM-ET0201, Ethernet CoS ..............................................................................................................14

COM-ET0301, Link Aggregation ........................................................................................................17

COM-ET0501, MTU Configuration .....................................................................................................23

COM-ET0601, ARP ..............................................................................................................................27

COM-ET0701, Ethernet OAM EFM (802 3ah) ....................................................................................30

COM-ET0901, Statistics per VLAN ....................................................................................................36

COM-IP0101, IPv4 support.................................................................................................................41

COM-IT0201, ICMP .............................................................................................................................45

COM-IP0401, SCTP .............................................................................................................................53

COM-IP0402, SCTP multi-homing .....................................................................................................57

COM-IP0501, COM-IP0601 .................................................................................................................63

COM-IP0701, Diffserv .........................................................................................................................69

COM-IP0801, Static IP configuration.................................................................................................77

COM-IP0802, DHCP for IPv4 ..............................................................................................................81

COM-IP1001, ECMP ............................................................................................................................84

COM-IP1101, IP address duplication detection ...............................................................................87

COM-IP1201, Static Routing ..............................................................................................................90

COM-IP1301, IP Fragmentation/Reassembly ...................................................................................94

COM-IP1601, ROHC for VoIP .............................................................................................................98

COM-SE0701, OS hardening ...........................................................................................................105

COM-SY0101, GPS ...........................................................................................................................108

COM-SY0601, Clock Holdover......................................................................................................... 114

© SAMSUNG Electronics Co., Ltd. page 5 of 1021

COM-TM0101, Traffic Scheduling ................................................................................................... 117

COM-TM0201, UL Traffic Shaping................................................................................................... 125

COM-TM0301, DSCP to Ethernet CoS mapping ............................................................................ 128

COM-TM0401, COM-TM0403, CAC Considering Transport Link .................................................. 131

COM-TM0402, Load sharing between multiple transport links .................................................... 137

COM-TM0601, Transport QoS ......................................................................................................... 140

LTE-ME0104, 10 MHz Bandwidth .................................................................................................... 144

LTE-ME0105, 15 MHz Bandwidth .................................................................................................... 149

LTE-ME0401, Downlink QSPK, 16QAM, 64QAM Support ............................................................. 154

LTE-ME0402, Uplink QPSK, 16QAM Support ................................................................................. 160

LTE-ME0501, Cell specific Reference Signal ................................................................................. 166

LTE-ME0504, Positioning Reference Signal .................................................................................. 172

LTE-ME0506, Synchronization Signal ............................................................................................ 177

LTE-ME0507, Demodulation Reference Signal .............................................................................. 183

LTE-ME0508, Sounding Reference Signal ..................................................................................... 189

LTE-ME0601, RACH Preamble Type for FDD ................................................................................. 195

LTE-ME0603, Random Access Procedure ..................................................................................... 199

LTE-ME1001, Variable Number of OFDM Symbols for PDCCH .................................................... 207

LTE-ME1002, ME1004, CCE Aggregation for PDCCH.................................................................... 212

LTE-ME1101, PDSCH Resource Allocation .................................................................................... 217

LTE-ME1503, PUSCH Frequency Hopping ..................................................................................... 223

LTE-ME1504, PUCCH Format .......................................................................................................... 230

LTE-ME2019, ME2030, DL SU 2x2 MIMO ........................................................................................ 234

LTE-ME2020, 4Rx Diversity ............................................................................................................. 242

LTE-ME3001, ME3003, ME3004, Power Control ............................................................................. 245

LTE-ME3005, DL Power Allocation ................................................................................................. 252

LTE-ME3101, HARQ in DL and UL .................................................................................................. 258

LTE-ME3201, Basic Link Adaption.................................................................................................. 265

LTE-ME3205, CQI Correction .......................................................................................................... 274