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
INTRODUCTION
Purpose
The feature description describes the feature of eNB system.
Relevance
This manual applies to the following Samsung network software releases:
Related Document
Listed below is the entire document set of the product:
Document Describes…
(Continued)
Document Describes…
Revision History
VERSION DATE OF ISSUE REMARKS
TABLE OF CONTENTS
INTRODUCTION 3
Feature Description 10
COM-IT0301, Ping...............................................................................................................................50
LTE-ME3202, ME3206, ME3207, ME3208, Periodic Channel Status Reporting ........................... 278
LTE-ME3301, ME3302, ME3303, ME3304, Scheduling with QoS Support ................................... 285
LTE-SW3001, SW3002, SW3003, AM, UM and TM Data Transfer at RLC Layer ...........................857
ABBREVIATION 1016
A ~ D ................................................................................................................................................1016
E ~ K ................................................................................................................................................1017
L ~ P ................................................................................................................................................1018
Q ~ T ................................................................................................................................................1019
U ~ X ................................................................................................................................................1020
Feature Description
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
Reference
IEEE 802.1p, IEEE 802.1q
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.
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.
4G eNB 16 8
System operation
Commands and Parameters
Related Command List
Command Description
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.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can manage QoS at the level of Ethernet.
Release History
SLR 2.3
Basic or Optional
Basic
Reference
IEEE 802.1p, IEEE 802.1q
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.
Operation Scenario
For Ethernet CoS marking, the following setup procedure is required.
System Specification
N/A
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Reference
IEEE 802.3ad
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.
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.
System Specification
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.
System operation
Commands and Parameters
Configure Link Aggregation Group Interface
Related Command List
Command Description
Command Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can configure MTU depending on transport network condition.
Release History
SLR 2.3
Basic or Optional
Basic
Reference
IETF RFC 791, RFC 894
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.
System Specification
MTU configuration range: 68-8270
System operation
Commands and Parameters
Related Command List
Command Description
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Reference
IETF RFC 826
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:
System Specification
The ARP aging time is set to 60 s by default.
The ARP table size is set to 512 by default.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can monitor the status of Ethernet link.
Release History
SLR 2.3
Basic or Optional
Optional
Reference
IEEE 802.3ah
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.
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)
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.
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 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.
System Specification
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.
System operation
Commands and Parameters
EFM parameter configuration
Related Command List
Command Description
(Continued)
Command Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can monitor the backhaul data usages per VLAN interface.
Release History
SLR 2.4
Basic or Optional
Optional
Reference
N/A
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
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.
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)
System Specification
N/A
System operation
Commands and Parameters
N/A
Related Counters
Related Counter List
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can have IPv4 transport option for all interfaces.
Release History
SLR2.3
Basic or Optional
Basic
Reference
RFC 791
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.
IP Address 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).
System Specification
N/A
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Reference
IETF RFC 792, RFC 950, RFC 1122
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.
(Continued)
(Continued)
Operation Scenario
No additional setting is required for the ICMP function.
System Specification
All the general ICMP functions are supported. But the destination unreachable function is
not supported due to the risk of hackings.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Reference
IETF RFC 792
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
System Specification
N/A
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Reference
RFC4960
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’.
System Specification
N/A
System operation
Commands and Parameters
Related Command List
Command Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can have network-level redundancy for signaling traffic.
Release History
SLR 2.3
Basic or Optional
Basic
Reference
RFC4960
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.
System Specification
N/A
System operation
Commands and Parameters
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
Related Command List
Command Description
(Continued)
Command Description
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Reference
N/A
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
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.
System Specification
N/A
System operation
Commands and Parameters
PLDSystemOamIp
Related Command List
Command Description
PLDSystemSigIp
Related Command List
Command Description
(Continued)
PLDIPAttrPriorityConf
Related Command List
Command Description
PLDEthInfo
Related Parameter List
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Reference
RFC2474, RFC2475
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
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
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.
0 SNMP
1 SSH
2 sftp/ftp
3 OAM traffic, CSL, Trace
4 ICMP (Ping)
5 Network control traffic
6 IEEE 1588 traffic
0 S1 Signaling
1 X2 Signaling
2 S1/X2-U Management
The bearer traffics of LTE are classified as below based on QoS Class Identifier (QCI).
LTE Bearer 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 -
System Specification
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
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
0 S1 Signaling 40
1 X2 Signaling 40
2 S1/X2-U Management 40
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
System operation
Commands and Parameters
DSCP configuration for Control and Management traffic
Related Command List
Command Description
Command Description
Command Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
N/A
Release History
SLR2.3
Basic or Optional
Basic
Reference
N/A
Feature Description
Operation Scenario
IP address can be set as follows.
System Specification
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
System Operation
Commands and Parameters
Related Command List
Command Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can configure BBU IP address dynamically.
Release History
SLR 2.3
Basic or Optional
Optional
Reference
IETF RFC2131
Feature Description
The BBU can obtain an IP address prior to the initial loading by using one of the following
two ways.
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.
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)
System Specification
N/A
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Reference
IETF RFC 2991, RFC 2992
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.
System Specification
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.
System operation
Commands and Parameters
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
This feature enables to avoid IP address duplication and data corruption.
Release History
SLR 2.3
Basic or Optional
Optional
Reference
IETF RFC5227
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
The IP address duplication detection function allows the operator to check an IP address
collision using the RTRV-SYSIP-INFO command.
System Specification
IP address duplication detection function operates only at the time of initial system loading.
System operation
Commands and Parameters
Related Command List
Command Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
There is no overhead on CPU and no bandwidth usage on transport links.
Release History
SLR 2.3
Basic or Optional
Basic
Reference
N/A
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.
System Specification
The max number of static routes supported by BBU is 128.
System operation
Commands and Parameters
Related Command List
Command Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Reference
IETF RFC 791, RFC 815
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)
IP header IP header
IP header Payload (offset field Payload ..... (offset field Payload
changed) changed)
IP header Payload
Original Packet
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).
System Specification
N/A
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Reference
RFC3095, RFC4815, RFC4995
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:
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.
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.
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.
System Specification
The eNB supports the following profile for IPv4 in the PDCP layer.
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.
System operation
Commands and Parameters
Related Command List
Command Description
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Reference
N/A
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.
System Specification
N/A
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Reference
N/A
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:
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.
System Specification
The GPS Receiver (GPSR) specifications are as follows:
System operation
Commands and Parameters
Retrieving GPS status information
Related Command List
Command Description
Command Description
GPS Reset
Related Command List
Command Description
Related Alarms
Related Alarm List
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
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
Reference
N/A
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
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
System Specification
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
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can schedule traffic based on CoS.
Release History
SLR 2.3
Basic or Optional
Basic
Reference
N/A
Feature Description
Two kinds of scheduling algorithms are supported, SPQ (Strict Priority Queuing) and DRR
(Deficit Round Robin).
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.
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.
To delete each traffic scheduling setting, execute the commands in reverse order to the
above.
System Specification
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.
System operation
Commands and Parameters
Setting the Class-map
Related Command List
Command Description
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.
(Continued)
Command Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can prevent backhaul congestion at Ethernet interface.
Release History
SLR2.3
Basic or Optional
Optional
Reference
N/A
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.
System Specification
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.
System operation
Commands and Parameters
Related Command List
Command Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
N/A
Release History
SLR 2.3
Basic or Optional
Basic
Reference
N/A
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.
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.
System Specification
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.
System operation
Commands and Parameters
Related Command List
Command Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can provide QoS guaranteed service to UEs considering the limitation of backhaul
resource.
Release History
SLR2.2
Basic or Optional
Optional
Reference
N/A
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.
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.
System Specification
N/A
System operation
Commands and Parameters
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.
Range: 0-100, Init: 35, Unit: %
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.
Range: 0-100, Init: 30, Unit: %
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.
Range: 0-100, Init: 35, Unit: %
overBookingRatio Over booking ratio to the downlink and uplink thresholds
Range: 1.0-10.0, Init: 1.0
(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
Related Status
N/A
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.
Benefits
Operator can maximize link efficiency by balancing load between multiple links.
Release History
SLR 2.3
Basic or Optional
Basic
Reference
N/A
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:
System Specification
N/A
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can manage QoS on the transport network.
Release History
SLR 2.3
Basic or Optional
Basic
Reference
N/A
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).
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)
System Specification
N/A
System operation
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
3GPP has specified a set of 6 channel bandwidths, ranging from 1.4 MHz to 20 MHz.
Below table is Channel bandwidth for LTE.
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.
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
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.
System operation
Commands and Parameters
Related Commands and Parameters
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
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 Scope
R1 LTE eNB supports 15 MHz.
R2 Operator can set the BW.
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.
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.
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
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.
System operation
Commands and Parameters
Related Commands and Parameters
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
Release History
SLR2.2 and Later|New Entry|Basic Feature
Reference
1) 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation
2) 3GPP TS36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 2
Feature Scope
R1 LTE eNB supports BPSK, QPSK, 16QAM, and 64QAM.
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.
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.
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.
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.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
Release History
SLR2.2
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
1) 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation
2) 3GPP TS36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 2
Feature Scope
R1 LTE eNB supports QPSK and 16QAM modulation scheme.
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.
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.
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.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
Release History
SLR2.2
Limitation:
None
Reference
1) 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation
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
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.
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.
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.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
Release History
SLR2.2
Limitation:
OTDOA is defined in the release 9 version of 3GPP specifications. Therefore, Rel.9
supportable UE is required.
Reference
1) 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation
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
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.
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.
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.
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.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Introduction
Both the FDD and TDD versions of LTE broadcast Synchronization Signals in the
downlink direction:
Primary Synchronization Signal (PSS)
Secondary Synchronization Signal (SSS)
Benefits
Operator Benefits:
Operator can make a time synchronization with LTE UE by using synchronization
signal.
Release History
SLR2.2
Limitation:
None
Reference
1) 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation
2) 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
Primary Synchronization Signal
The Primary Synchronization Signal (PSS) is broadcast twice during every radio frame and
both transmissions are identical.
The PSS cannot be used to achieve radio frame synchronization because both transmissions
within the radio frame are identical and equally spaced in time.
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 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).
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.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
Release History
SLR2.2
Reference
1) 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation
Feature Scope
R1 LTE eNB should supports the structure of the demodulation reference signal for
uplink channel estimation and coherent demodulation.
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.
Below figure is Resource mapping of DM-RS for PUSCH with the normal CP.
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.
Below figure is Resource mapping of DM-RS for PUCCH with normal CP.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
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
1) 3GPP TS36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 2
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
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.
(Continued)
System operation
SRS configuration can be specified by parameters in below:
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator Benefits:
Enabling this feature can support various cell sizes defined in 3GPP standard.
Release History
SLR2.2
Reference
1) 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation
2) 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 LTE eNB supports the RACH preamble format 0-3 in the FDD mode.
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.
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.
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.
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.
System operation
Commands and Parameters
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
Release History
SLR2.2
Reference
1) 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation
2) 3GPP TS 36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2
Reference
1) 3GPP TS 36.201 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer; General description’
2) 3GPP TS 36.211 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
Channels and Modulation’
3) 3GPP TS 36.212 ‘Evolved Universal Terrestrial Radio Access (E-UTRA);
Multiplexing and channel coding’
4) 3GPP TS 36.213 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures’
5) 3GPP TS 36.214 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
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
Contention-based Random Access Procedure
The contention-based procedure consists of four-steps as shown in below figure:
System operation
Commands and Parameters
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
Benefits
Operator Benefits:
Cell capacity is increased in cases where not all available PDCCH resource are needed.
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
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
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.
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.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
Benefits
Operator Benefits:
Cell capacity is increased in cases where not all available PDCCH resource are needed.
Release History
SLR2.2
Reference
1) 3GPP TS 36.201 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer; General description’
2) 3GPP TS 36.211 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
Channels and Modulation’
3) 3GPP TS 36.212 ‘Evolved Universal Terrestrial Radio Access (E-UTRA);
Multiplexing and channel coding’
4) 3GPP TS 36.213 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures’
5) 3GPP TS 36.214 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
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 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
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.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
Samsung eNB currently does not consider downlink resource allocation type 1.
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)
2) 3GPP TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
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
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 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.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Benefits
Operator Benefits:
Frequency diversity effects can be exploited and interference can be averaged.
Release History
SLR2.2
Reference
1) 3GPP TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
2) 3GPP TS 36.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
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.
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.
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.
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).
System operation
Commands and Parameters
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
1) 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation
2) 3GPP TS 36.212 Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing
and channel coding
3) 3GPP TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
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 Modulation scheme and number of Resource Elements for each PUCCH
format.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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).
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.
Release History
SLR2.2
Reference
1) 3GPP TS 36.201 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer; General description’
2) 3GPP TS 36.211 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
Channels and Modulation’
3) 3GPP TS 36.212 ‘Evolved Universal Terrestrial Radio Access (E-UTRA);
Multiplexing and channel coding’
4) 3GPP TS 36.213 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures’
5) 3GPP TS 36.214 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
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 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
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
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.
The general structure of layer mapping and precoding is illustrated in below figure.
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
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
Below figure is Flow of two example modulation symbols through processing for transmit
diversity.
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.
System operation
Commands and Parameters
Related Commands
Command Description
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
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
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
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).
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
1) 3GPP TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
2) 3GPP TS 36.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS 36.101 Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) radio transmission and reception
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
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.
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.
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.
System operation
Commands and Parameters
Related Commands and Parameters
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
1) 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation
2) 3GPP TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
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
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.
System operation
Commands and Parameters
Related Commands
Command Description
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
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
Reference
1) 3GPP TS 36.212 Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing
and channel coding
2) 3GPP TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
3) 3GPP TS 36.321 Evolved Universal Terrestrial Radio Access (E-UTRA); Medium
Access Control (MAC) protocol specification
4) 3GPP TS 36.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
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
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
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.
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.
System operation
Commands and Parameters
Related Commands
Command Description
How to
Parameter Description
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,
- ci_maxHARQ_Tx_n3: 3 transmissions,
- ci_maxHARQ_Tx_n4: 4 transmissions,
- ci_maxHARQ_Tx_n5: 5 transmissions,
- ci_maxHARQ_Tx_n6: 6 transmissions,
- ci_maxHARQ_Tx_n7: 7 transmissions,
- ci_maxHARQ_Tx_n8: 8 transmissions,
- ci_maxHARQ_Tx_n10: 10 transmissions,
- ci_maxHARQ_Tx_n12: 12 transmissions,
- ci_maxHARQ_Tx_n16: 16 transmissions,
- ci_maxHARQ_Tx_n20: 20 transmissions,
- ci_maxHARQ_Tx_n24: 24 transmissions,
- ci_maxHARQ_Tx_n28: 28 transmissions,
Default:
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
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 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.
Release History
SLR2.2
Limitation:
None
Reference
1) 3GPP TS 36.212 Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing
and channel coding
2) 3GPP TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
3) 3GPP TS 36.321 Evolved Universal Terrestrial Radio Access (E-UTRA); Medium
Access Control (MAC) protocol specification
Feature Scope
R1 The Adaptive Modulation and Coding (AMC) function using the CQI feedback
should be provided in LTE eNB.
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.
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.
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:
Below table is Sub-band size (k) versus system bandwidth for eNodeB-configured
aperiodic CQI reports
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.
Below table is Periodic CQI reporting with UE-selected sub-bands: sub-band size (k) and
bandwidth parts (J ) versus downlink system bandwidth.
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.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
Reference
1) 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
channels and modulation
2) 3GPP TS 36.212 Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing
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
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.
System operation
Commands and Parameters
Related Commands
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:
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
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 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
Release History
SLR2.2
Limitation:
None
Reference
1) 3GPP TS 36.212 Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing
and channel coding
2) 3GPP TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
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
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. 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.
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.
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.
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)
System operation
Commands and Parameters
Related Commands
Command Description
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
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
Limitation:
None
Reference
1) 3GPP TS 36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 2
2) 3GPP TS 36.321 Evolved Universal Terrestrial Radio Access (E-UTRA); Medium
Access Control (MAC) protocol specification
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
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.
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.
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)^(α)
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.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
For TDD, E-UTRAN does not simultaneously enable TTI bundling and semi-
persistent scheduling in this release of specification. (3GPP TS. 36.331)
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.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
3) 3GPP TS36.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
Feature Scope
Follwing is the feature scope of Semi-persistent scheduling
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.
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.
System Operation
Commands and Parameters
(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
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
Reference
1) 3GPP TS 36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 2
2) 3GPP TS 36.321 Evolved Universal Terrestrial Radio Access (E-UTRA); Medium
Access Control (MAC) protocol specification
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
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)
System operation
Commands and Parameters
Related Commands
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
subband CQI are operated simultaneously for each DL transmission mode.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Release History
SLR2.2
Limitation
None
Reference
1) 3GPP TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
2) 3GPP TS 36.321 Evolved Universal Terrestrial Radio Access (E-UTRA); Medium
Access Control (MAC) protocol specification
Feature Scope
R1 eNB provides the sub-frame bundling function.
R2 eNB maintains the sub-frame bundling function during HO.
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.
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.
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.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
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.
Benefits
End User Benefits
Enabling this feature results in longer battery life times.
Release History
SLR2.2
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 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
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.
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
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.
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
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation
None
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.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures
3) 3GPP TS36.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
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
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 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.
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.
System Operation
Commands and Parameters
Related Command List
Command Parameters
(Continued)
Parameter Description
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,
psf20, psf30, psf40, psf50, psf60, psf80, psf100, psf200
Inter-RAT reportCGI status onDurationTimer value.
drxInactivityTimerInterRat Range: psf1, psf2, psf3, psf4, psf5, psf6, psf8, psf10,
psf20, psf30, psf40, psf50, psf60, psf80, psf100, psf200,
psf300, psf500, psf750, psf1280, psf1920, psf2560
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
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
Limitation
None
Reference
1) 3GPP TS 36.201 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer; General description’
2) 3GPP TS 36.211 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
Channels and Modulation’
3) 3GPP TS 36.212 ‘Evolved Universal Terrestrial Radio Access (E-UTRA);
Multiplexing and channel coding’
4) 3GPP TS 36.213 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
layer procedures’
5) 3GPP TS 36.214 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Physical
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 eNB receiver utilizes IRC scheme based on MMSE criterion to support interference
cancellation function.
R2 eNB supports IRC function ON/OFF.
Feature Description
In uplink, the eNB receiver utilizes interference rejection combining (IRC) scheme which
is based on MMSE criterion to support interference cancellation function.
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).
In the figure, 25 RBs, QPSK 1/3 PUSCH is used at SIR of 5 dB. EPA 5 Hz channel is
assumed.
System Operation
IRC function is turned off or on by changing the following parameter in the register map.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
Reference
Standard or Technical Reports:
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
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.
System Operation
Commands and Parameters
Related Command List
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.
(Continued)
Default
Command Parameter Description
Value
TEST-RET 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-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.
RET_ID NONE ID of 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
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
Limitation:
The number of cells that can be traced simultaneously are limited by LSM capacity
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.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 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
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.
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.
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.
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
Default
Parameter Description Range
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. - -
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
Trace Trace
Data Name Message Name Description Depth Depth
(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
(Continued)
Trace Trace
Data Name Message Name Description Depth Depth
(Min) (Med)
CDMA2000 HO UPLINK S1 CDMA2000 TUNNELING Whether the UE M M
Required has to prepare
Indication handover to the
CDMA2000
Trace Trace
Data Name Message Name Description Depth Depth
(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
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
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.
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.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
4) 3GPP TS32.423 Telecommunication management; Subscriber and equepment trace;
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
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.
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.
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.
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
Parameter Description Range
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.
Trace Trace
Data Name Message Name Description Depth Depth
(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
(Continued)
Trace Trace
Data Name Message Name Description Depth Depth
(Min) (Med)
Target RAT Type MOBILITY FROM EUTRA COMMAND The RAT information M M
for the target
Trace Trace
Data Name Message Name Description Depth Depth
(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
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 the M M
PATH SWITCH REQUEST eNB (PLMN ID +
INITIAL UE MESSAGE cell ID)
UPLINK NAS TRANSPORT
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
(Continued)
Trace Trace
Data Name Message Name Description Depth Depth
(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
Trace Trace
Data Name Message Name Description Depth Depth
(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
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
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
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.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP)
3) 3GPP TS32.422 Telecommunication management; Subscriber and equepment trace;
Trace control and configuration management
4) 3GPP TS32.423 Telecommunication management; Subscriber and equepment trace;
Trace data definition and management
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
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:
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.
System Operation
Commands and Parameters
N/A
(Continued)
(Continued)
(Continued)
The RF information included in the result of the call detail trace is as follows:
(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
due to the performance issue. Interval of 2.56 seconds
UL MCS 0 - Possible to six counts per cell to the maximum by phone
due to the performance issue. Interval of 2.56 seconds
UL MCS 31 - Possible to six counts per cell to the maximum by phone
due to the performance issue. Interval of 2.56 seconds
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
(Accumulated value of the TPC (transmit power control)
command (0 dB) transmission count)
TPC for PUCCH[2] (1 dB) - Accumulated PUCCH power control statistics
(Accumulated value of the TPC (transmit power control)
command (1 dB) transmission count)
TPC for PUCCH[3] (3 dB) - Accumulated PUCCH power control statistics
(Accumulated value of the TPC (transmit power control)
command (1 dB) transmission count)
(Continued)
TPC for PUSCH[0] (-1 dB) - Accumulated PUCCH power control statistics
(Accumulated value of the TPC (transmit power control)
command (1 dB) transmission count)
TPC for PUSCH[1] (0 dB) - Accumulated PUCCH power control statistics
(Accumulated value of the TPC (transmit power control)
command (1 dB) transmission count)
TPC for PUSCH[2] (1 dB) - Accumulated PUCCH power control statistics
(Accumulated value of the TPC (transmit power control)
command (1 dB) transmission count)
TPC for PUSCH[3] (3 dB) - Accumulated PUCCH power control statistics
(Accumulated value of the TPC (transmit power control)
command (1 dB) transmission count)
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
UE eNB PMI 1 - Information informed by UE (Precoder Metric Indicator)
(UL PMI 1) index 1
UL PMI = PMI received from UE
UE eNB PMI 2 - Information informed by UE (Precoder Metric Indicator)
(UL PMI 2) index 2
UL PMI = PMI received from UE
UE eNB PMI 3 - Information informed by UE (Precoder Metric Indicator)
(UL PMI 3) index 3
UL PMI = PMI received from UE
eNB UE PMI 0 - Information given by the base station (Precoder Metric
(DL PMI 0) Indicator) index 0
PMI allocated to UE
eNB UE PMI 1 - Information given by the base station (Precoder Metric
(DL PMI 1) Indicator) index 1
PMI allocated to UE
eNB UE PMI 2 - Information given by the base station (Precoder Metric
(DL PMI 2) Indicator) index 2
PMI allocated to UE
eNB UE PMI 3 - Information given by the base station (Precoder Metric
(DL PMI 3) Indicator) index 3
PMI allocated to UE
eNB UE RI 0 - # of assignment on layer 0 (during 2.56 sec)
(UE DL RI 0)
(Continued)
Related Alarms
N/A
Related Status
N/A
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
Limitation
The number of CSL records that can be saved depends on the LSM capacity.
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
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
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.
System operation
Commands and Parameters
N/A
(Continued)
(Continued)
(Continued)
(Continued)
Related Alarms
N/A
Related Status
N/A
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
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
Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 2
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
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.
System operation
Commands and Parameters
N/A
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
Measured per measurement period.
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
Measured per measurement period.
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
(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
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
Limitation
N/A
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
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)
Below figure is eNB Self Establishment Process-Apply IPsec, Apply Self Configuration.
System Operation
Commands and Parameters
Commands Parameters Description
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.
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
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.
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 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
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
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.
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.
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.
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.
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.
The threshold that controls the NRT size can have a value between 1 and 256, which
can be set by the operator.
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.
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.
System operation
Commands and Parameters
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.
The operator can control the operations of the Samsung ANR functions with the following
commands and parameters.
(Continued)
Related Counters
The Samsung ANR function uses the following statistics information.
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
success to inter-eNB neighbor cell statistics in the LSM
InterS1OutPrepSucc The number of S1 HO preparation Operator can check this with PM
success to inter-eNB neighbor cell statistics in the LSM
InterS1OutSucc The number of S1 HO execution Operator can check this with PM
success to inter-eNB neighbor cell statistics in the LSM
Related KPI/PI
KPIs related to the Samsung ANR function are as follows:
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.
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
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
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
6) 3GPP 32.521: E-UTRAN; Self-Organizing Networks (SON) Policy Network Resource
Model (NRM) Integration Reference Point (IRP); Requirements
7) 3GPP 32.522: E-UTRAN; Self-Organizing Networks (SON) Policy Network Resource
Model (NRM) Integration Reference Point (IRP); Information Service (IS)
8) 3GPP 32.541: E-UTRAN; OAM Requirements for Self Healing Use Cases
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
Architecture
The Samsung PCI optimization operates in the eNB’s SON agent and EMS’s SON manager.
The overall structure is as follows.
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.
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 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.
SYSTEM OPERATION
Commands and Parameters
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.
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.
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.
References
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; Self-Organizing Networks (SON); Concepts and
requirements
5) 3GPP 32.501: E-UTRAN; Self-configuration of network elements; Concepts and
requirements
6) 3GPP 32.521: E-UTRAN; Self-Organizing Networks (SON) Policy Network Resource
Model (NRM) Integration Reference Point (IRP); Requirements
7) 3GPP 32.522: E-UTRAN; Self-Organizing Networks (SON) Policy Network Resource
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
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
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
RO Function Description
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.
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.
preambles.
TIME_CHANCE_MIN: A minimum value of the time chance index related to the PRACH
configuration index.
System Operation
Commands and Parameters
Commands Parameters Description
(Continued)
(Continued)
(Continued)
(Continued)
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
Release History
SLR2.2
Basic or Optional
Optional feature: Auto/Manual/Off modes are available for the MRO function operation.
1) Dependency
X2 interface setting: To activate the MRO function, X2 interface must be
established with neighbor eNBs.
2) Limitation
N/A
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 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
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.
MRO Function
Collection of handover-related problem statistics
The Samsung MRO function collects and categorizes the HO-related problems as
following:
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.
UE requests for RRC connection reestablishment to the serving cell.
4) TooLateHORLFAfterTriggering
UE transmits the MR message initiated by triggering HO.
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.)
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 transmits the MR message initiated by triggering HO.
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 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 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.)
6) HOtoWrongCellRLFAfterTriggering
UE transmits the MR message initiated by triggering HO.
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 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 transmits the MR message initiated by triggering HO.
UE receives the HO command from the serving cell.
UE fails HO with the target cell.
UE requests for RRC connection reestablishment to the serving cell.
8) TooEarlyHORLFAfterHO
UE transmits the MR message initiated by triggering HO.
UE receives the HO command from the serving cell.
UE fails HO with the target cell.
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 target cell transmits the RLF indication message to the serving cell through
the X2 interface.
9) HOtoWrongCellRLFAfterHO
UE transmits the MR message initiated by triggering HO.
UE receives the HO command from the serving cell.
UE fails HO with the target cell.
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.
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.
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:
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.
System operation
Commands and Parameters
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:
The operator can control Samsung MRO function operations with the following commands
and parameters:
(Continued)
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.
(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
success to inter-eNB neighbor cell PM statistics in the LSM
InterS1OutPrepSucc The number of S1 HO preparation Operator can check this with
success to inter-eNB neighbor cell PM statistics in the LSM
InterS1OutSucc The number of S1 HO execution Operator can check this with
success to inter-eNB neighbor cell PM statistics in the LSM
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
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
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
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.
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
(Continued)
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
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Feature Scope
R1 Statistics monitoring
R2 Sick cell detection
R3 Sick cell detection report
Reference
N/A
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).
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.
M 512 kbps
N 128 kpbs
A 70 %
B 70 %
Usage
Enter search conditions in the search window.
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.
(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.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
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.
System operation
Commands and Parameters
Related Commands
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
required for CAC at the eNB level.
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.
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator Benefits:
Operator can provide Emergency service to its subscribers by using legacy CS
network (UTRAN).
Release History
SLR2.2
Basic or Optional
Optional
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Radio Access (E-UTRA); S1
Application Protocol (S1AP)
4) 3GPP TS23.272 Circuit Switched (CS) fallback in Evolved Packet System (EPS);
Stage 2
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)
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.
System operation
Commands and Parameters
Related System Parameters
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
Related Counters
Category Family Name Type Name Description
(Continued)
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
Need verification test with the supported device, EPC and CBC
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36.413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
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
The following figure represents overall operation of the CMAS public alarm system.
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.
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).
System operation
Commands and Parameters
Related Commands
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.
(Continued)
(Continued)
(Continued)
(Continued)
Related Commands
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
Need verification test with the supported device, EPC and CBC
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36.413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
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
The following figure represents overall operation of the ETWS public alarm system.
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.
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.
System operation
Commands and Parameters
Command Parameter Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
Release History
SLR2.2
Reference
Standard or Technical Reports:
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.305 Evolved Universal Terrestrial Radio Access (E-UTRA); LTE
Positioning Protocol (LPP)
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).
System Operation
How to Enable/Disable or Configure
N/A
Related Alarm
N/A
Related Status
N/A
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.
Release History
SLR2.2
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
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.
System operation
Related Commands
Command Description
(Continued)
Related Alarms
N/A
Related Status
N/A
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.
Release History
SLR2.2
Limitation:
Release-9 UE
Triggered by E-SMLC
Reference
Standard or Technical Reports:
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.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
The OTDOA information transfer function is a procedure that the E-SMLC requests and
receives the OTDOA information from the eNB.
System Operation
Related Commands
Command Description
(Continued)
(Continued)
Related Alarms
N/A
Related Status
N/A
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
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
Following table explains DL throughput and the number of downlink layers per UE
Category, which are defined in 3GPP TS36.306 Rel9 version.
Following table explains UL throughput and 64QAM support per UE Category, which are
defined in 3GPP TS36.306 Rel9 version.
System operation
Commands and Parameters
N/A
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator Benefits
− UE Counting per category helps to analysis connected UEs' status per category.
End User Benefits
− None
Release History
SLR2.4
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.
2) 3GPP TS36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 2
3) 3GPP TS36.306 Evolved Universal Terrestrial Radio Access (E-UTRA); User
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
As shown below, the eNB can obtain the UE category information during attachment or
idle to active transition.
eNB MME
Attach Procedure
UE Capability Enquiry
UE Capability Information
UE Category
Save
Attach Complete
Statistics Count
eNB MME
Initial UE Message
UE Category
Save
Statistics Count
System operation
Commands and Parameters
N/A
Related Counters
Counter Description How to Check
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 304 Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) procedures in idle mode
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.
R2 The eNB allows the operator to configure, modify, and retrieve 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.
R2 The eNB allows the operator to configure, modify, and retrieve the SIB3.
R3 The eNB transmits the SIB3 according to the predetermined cycle.
[SIB4]
R1 The eNB transmits the intra-frequency neighboring cell information of the UE via the
SIB4.
R2 The eNB allows the operator to configure, modify, and retrieve the SIB4.
R3 The eNB transmits the SIB4 according to the predetermined cycle.
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.
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
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
System operation
Commands and Parameters
Command Parameter 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.
- ci_not_used: SIB3 is not sent.
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.
- ci_not_used: SIB4 is not sent.
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:
- ci_si_WindowLength_ms1: 1 ms.
- ci_si_WindowLength_ms2: 2 ms.
- ci_si_WindowLength_ms5: 5 ms.
- ci_si_WindowLength_ms10: 10 ms.
- ci_si_WindowLength_ms15: 15 ms.
- ci_si_WindowLength_ms20: 20 ms.
- ci_si_WindowLength_ms40: 40 ms.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
User can perform inter-frequency cell reselection.
Release History
SLR2.2
Basic or Optional
Basic
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 304 Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) procedures in idle mode
Feature Scope
R1 The eNB transmits the information required for the inter-frequency cell reselection
operation via the SIB5.
R2 The eNB allows the operator to configure, modify, and retrieve the SIB5.
R3 The eNB transmits the SIB5 according to the predetermined cycle.
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.
System operation
Commands and Parameters
Related Commands
Command Description
(Continued)
(Continued)
(Continued)
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
User can perform cell reselection from E-UTRAN to UTRAN.
Release History
SLR2.2
Basic or Optional
Optional
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 304 Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) procedures in idle mode
Feature Scope
R1 The eNB transmits the information required for the UTRANS cell reselection
operation via the SIB6.
R2 The eNB allows the operator to configure, modify, and retrieve the SIB6.
R3 The eNB transmits the SIB6 according to the predetermined cycle.
Feature Description
In idle mode, the UE receives the SIB6 (System Information Block type 6) broadcast by the
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
System operation
Commands and Parameters
Related Commands
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.
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
User can perform cell reselection from E-UTRAN to GERAN.
Release History
SLR2.2
Basic or Optional
Optional
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 304 Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) procedures in idle mode
Feature Description
In idle mode, the UE receives the SIB7 (System Information Block type 7) broadcast by the
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.
System operation
Commands and Parameters
Related Commands
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.
(Continued)
(Continued)
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
User can receive ETWS warning notification within E-UTRAN.
Release History
SLR2.2
Basic or Optional
Optional
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 304 Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) procedures in idle mode
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
message is received.
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
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.
System operation
Commands and Parameters
Command Parameter Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
User can receive CMAS warning notification within E-UTRAN.
Release History
SLR2.2
Basic or Optional
Optional
Limitation:
Need verification test with the supported device, EPC and CBC
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
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.
R3 The eNB transmits the SIB12 according to the predetermined cycle.
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.
System operation
Commands and Parameters
Command Parameter Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
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.
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.
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.
The RRC connection release procedure is as follows. (UE context release case)
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.
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.
System operation
Commands and Parameters
Commands and Parameters
(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.
Related Counters
Category Family Name Type Name Type Description
(Continued)
(Continued)
(Continued)
(Continued)
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can maintain UE context for its subscribers in RRC_CONNECTED state.
Release History
SLR2.2
Basic or Optional
Basic
Limitation:
Need UE IOT for security context modification
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
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)
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)
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.
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
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.
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).
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.
System operation
Commands and Parameters
Related Commands
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.
Related Counters
Category Family Type Description
(Continued)
(Continued)
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
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)
RRC Connection Reconfiguration Attempt/Success/Failure (Collection unit: Cell,
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)
RRC Connection Reconfiguration Attempt/Success/Failure (Collection unit: Cell,
QCI, and reason for failure)
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.
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.
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.
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.
System operation
Commands and Parameters
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:
Related Commands
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.
(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.
- ci_pdb150 msec: PDB of the QCI to 150
msec.
- ci_pdb200 msec: PDB of the QCI to 200
msec.
- ci_pdb250 msec: PDB of the QCI to 250
msec.
- ci_pdb300 msec: PDB of the QCI to 300
msec.
- ci_pdb350 msec: PDB of the QCI to 350
msec.
- ci_pdb400 msec: PDB of the QCI to 400
msec.
- ci_pdb450 msec: PDB of the QCI to 450
msec.
- ci_pdb500 msec: PDB of the QCI to 500
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.
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
(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
P_CU_FAIL specification cause
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
ECMB or by the ECCB block
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
Related Status
N/A
Benefits
Operator can modify E-RAB QoS of ongoing session.
Release History
SLR2.2
Basic or Optional
Basic
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
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)
RRC Connection Reconfiguration Attempt/Success/Failure (Collection unit: Cell,
QCI, reason for failure)
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.
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.
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.
System operation
Commands and Parameters
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.
(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
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
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
3) 3GPP TS36.413, Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
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
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.
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.
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.
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.
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.
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.
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.
System operation
Commands and Parameters
Related Commands
MmeId Id of MME
Range: 0~15
Default: 0
(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
broadcast to UE via SIB 1.
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
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
Limitation:
None
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);
S1 Application Protocol (S1AP)
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
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)
System operation
Commands and Parameters
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.
(Continued)
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)
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
SLR2.2 and Later | New Entry | Basic Feature
Limitation:
None
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.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
S1 Application Protocol (S1AP)
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
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
message is received.
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.
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.
System operation
Commands and Parameters
Related Commands
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.
- unlocked: Connection to the MME is normal.
- 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
(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
retrieval or change.
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
retrieval or change.
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.
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
SLR2.2 and Later | New Entry | Basic Feature
Limitation:
eNB supports up to 16 MMEs.
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.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
S1 Application Protocol (S1AP)
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.
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.
System operation
Commands and Parameters
Related Commands
(Continued)
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.
Release History
SLR2.2
Limitation:
None
Reference
Standard or Technical Reports:
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.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
application protocol (S1AP)
3) 3GPP TS36.423 Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
X2 application protocol (X2AP)
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.
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.
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.
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.
System operation
Commands and Parameters
The commands related to S1 AP Related Control are as follows.
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
SLR2.2 and Later | New Entry | Basic Feature
Limitation:
None
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.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
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.
System operation
Commands and Parameters
Related Commands
(Continued)
(Continued)
(Continued)
(Continued)
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
Limitation:
upto 256 X2 connections according the 3GPP Standard.
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.423 Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
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
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.
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.
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.
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.
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.
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.
System operation
Commands and Parameters
Related Commands
Commands Description
Default
Parameter Description Range
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.
- ci_Home_eNB: Indicates the home 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 - -
neighboring cell to the eNB.
It is a three-digit number with each digit being from 0 to 9.
(Continued)
Default
Parameter Description Range
Value
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.
mcc1[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.
mnc1[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.
mcc2[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.
mnc2[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.
mcc3[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.
mnc3[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.
mcc4[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.
mnc4[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.
mcc5[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.
mnc5[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.
(Continued)
Default
Parameter Description Range
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 - -
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.
isRemoveAllo Whether to delete a certain neighboring cell to the eNB - -
wed using the ANR (Automatic Neighbor Relation) function.
- True: The neighboring cell can be deleted.
- False: The neighboring cell cannot be deleted.
isHOAllowed Whether to perform handover to E-UTRAN neighboring - -
cell.
- True: Handover is allowed.
- False: Handover is not allowed.
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. - -
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Radio Access (E-UTRA); S1
Application Protocol (S1AP)
4) 3GPP TS23.401 Technical Specification Group Services and System Aspects; GPRS
enhancements for E-UTRAN access
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.
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.
System operation
Commands and Parameters
Default
Commands Parameters Description
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.
(Continued)
(Continued)
(Continued)
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
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.
R2 eNB can support the SIB4 setting/change and display by the operator.
R3 eNB can transmit SIB4 according the defined cycle.
[SIB5]
R1 eNB can transmit inter-frequency cell reselection of the terminal via SIB5.
R2 eNB can support the SIB5 setting/change and display by the operator.
R3 eNB can transmit SIB5 according the defined cycle.
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
System operation
Commands and Parameters
Command Parameter 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:
- ci_si_WindowLength_ms1: 1 ms.
- ci_si_WindowLength_ms2: 2 ms.
- ci_si_WindowLength_ms5: 5 ms.
- ci_si_WindowLength_ms10: 10 ms.
- ci_si_WindowLength_ms15: 15 ms.
- ci_si_WindowLength_ms20: 20 ms.
- ci_si_WindowLength_ms40: 40 ms.
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.
(Continued)
(Continued)
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
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
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.
System operation
Commands and Parameters
Related Commands
Parameters Descriptions
Parameters Descriptions
(Continued)
Parameters Descriptions
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.
mcc1[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.
mnc1[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.
mcc2[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.
mnc2[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.
mcc3[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.
mnc3[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.
mcc4[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.
mnc4[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.
mcc5[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.
mnc5[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.
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.
(Continued)
Parameters Descriptions
isRemoveAllowed Whether to delete a certain neighboring cell to the eNB using the ANR
(Automatic Neighbor Relation) function.
- True: The neighboring cell can be deleted.
- False: The neighboring cell cannot be deleted.
isHOAllowed Whether to perform handover to E-UTRAN neighboring cell.
- True: Handover is allowed.
- False: Handover is not allowed.
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
(Continued)
(Continued)
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
Users in connected state can be moving within E-UTRAN, with change of serving cell.
Release History
SLR2.2
Basic or Optional
Basic
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
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
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 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
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.
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)
11) The source eNB receives the HANDOVER COMMAND from the source MME.
12) The RRC CONNECTION RECONFIGURATION for handover is constructed by the
serving eNB and is sent to the UE.
13) 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.
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.
System operation
Commands and Parameters
Related Commands
Parameters Descriptions
Parameters Descriptions
(Continued)
Parameters Descriptions
(Continued)
Parameters Descriptions
mnc4[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.
mcc5[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.
mnc5[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.
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.
isRemoveAllow Whether to delete a certain neighboring cell to the eNB using the ANR
ed (Automatic Neighbor Relation) function.
- True: The neighboring cell can be deleted.
- False: The neighboring cell cannot be deleted.
isHOAllowed Whether to perform handover to E-UTRAN neighboring cell.
- True: Handover is allowed.
- False: Handover is not allowed.
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.
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.
(Continued)
Parameters Descriptions
Related Counters
Category Family FamilyName TypeName Type Description
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
Check noX2 = True (RTRV-NBR-ENB)
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.
Users in connected state can be moving within E-UTRAN, with change of serving cell.
Release History
SLR2.2
Basic or Optional
Basic
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
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.
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 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.
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 X2 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 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
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.
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)
System operation
Commands and Parameters
Related Commands
Parameters Descriptions
Parameters Descriptions
(Continued)
Parameters Descriptions
(Continued)
Parameters Descriptions
mnc4[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.
mcc5[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.
mnc5[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.
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.
isRemoveAllow Whether to delete a certain neighboring cell to the eNB using the ANR
ed (Automatic Neighbor Relation) function.
- True: The neighboring cell can be deleted.
- False: The neighboring cell cannot be deleted.
isHOAllowed Whether to perform handover to E-UTRAN neighboring cell.
- True: Handover is allowed.
- False: Handover is not allowed.
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.
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.
(Continued)
Parameters Descriptions
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
(Continued)
Family
Category FamilyName TypeName Type Description
(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
handover preparation.
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
blocks (MAC, RLC, PDCP, GTP)
during the inter X2 handover
execution.
(Continued)
Family
Category FamilyName TypeName Type Description
(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.
InterX2OutFail_UP_ A call is released due to the
MAC_FAIL internal failure in the MAC block
during the inter X2 handover
execution.
InterX2OutFail_UP_ A call is released due to the
PDCP_FAIL internal failure in the PDCP
block during the inter X2
handover execution.
InterX2OutFail_UP_ A call is released due to the
RLC_FAIL internal failure in the RLC block
during the inter X2 handover
execution.
InterX2OutFail_RRC A call is released due to
_SIG_FAIL receiving RRC signaling during
the inter X2 handover execution.
InterX2OutFail_ A call is released due to the
S1AP_CU_FAIL S1AP specification cause during
the inter X2 handover execution.
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
the inter X2 handover execution.
InterX2OutFail_ A call is released due to the
X2AP_CU_FAIL X2AP specification cause during
the inter X2 handover execution.
InterX2OutFail_ A call is released due to the X2
X2AP_LINK_FAIL SCTP link failure during the inter
X2 handover execution.
(Continued)
Family
Category FamilyName TypeName Type Description
(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
during the inter X2 handover
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)
InterX2InPrepFail_ Incoming X2 handover
CP_CC_FAIL preparation fails due to reset
notification (eNB failure or block
restart) from ECMB or by the
ECCB block
InterX2InPrepFail_ Incoming X2 handover
UP_GTP_FAIL preparation fails due to internal
failure in the GTP block
InterX2InPrepFail_ Incoming X2 handover
UP_MAC_FAIL preparation fails due to the
failure in the MAC block
InterX2InPrepFail_ Incoming X2 handover
UP_PDCP_FAIL preparation fails due to internal
failure in the PDCP block
InterX2InPrepFail_ Incoming X2 handover
UP_RLC_FAIL preparation fails due to the
failure in the RLC block
(Continued)
Family
Category FamilyName TypeName Type Description
(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
InterX2InPrepFail_ Incoming X2 handover
CP_CAPA_CAC_ preparation fails due to Capacity
FAIL based CAC
InterX2InPrepFail_ Incoming X2 handover
CP_QOS_CAC_ preparation fails due to Air QoS
FAIL based CAC
InterX2InPrepFail_ Incoming X2 handover
S1AP_LINK_FAIL preparation fails due to the S1
SCTP link failure
InterX2InPrepFail_ Incoming X2 handover
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
InterX2InPrepFail_ Incoming X2 handover
X2AP_LINK_FAIL preparation fails due to the X2
SCTP link failure
InterX2InPrepFail_ Incoming X2 handover
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
InterX2InFail_UP_ Incoming X2 handover fails due
MAC_FAIL to the failure in the MAC block
InterX2InFail_UP_ Incoming X2 handover fails due
PDCP_FAIL to to internal failure in the PDCP
block
(Continued)
Family
Category FamilyName TypeName Type Description
(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
InterX2InFail_S1AP_ Incoming X2 handover fails due
LINK_FAIL to the S1 SCTP link failure
InterX2InFail_S1AP_ Incoming X2 handover fails due
PATH_TO to S1AP path switch timeout
(not received)
InterX2InFail_S1AP_ Incoming X2 handover fails due
SIG_FAIL to receiving S1AP signaling
InterX2InFail_X2AP_ Incoming X2 handover fails due
CU_FAIL to the X2AP specification cause
InterX2InFail_X2AP_ Incoming X2 handover fails due
LINK_FAIL to the X2 SCTP link failure
InterX2InFail_X2AP_ Incoming X2 handover fails due
SIG_FAIL to receiving X2AP signaling
InterX2InFail_X2AP_ Incoming X2 handover fails due
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)
Benefits
Users can obtain session continuity during handover within E-UTRAN, with almost no
interruption
Release History
SLR2.2
Basic or Optional
Basic
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
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
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.
System operation
Commands and Parameter
Related Commands
Commands Description
Related Counters
Category Family Name Type Name Description
(Continued)
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
Benefits
Operator can provide connected mobility to its subscribers between cells which have a
different center frequency.
Users in connected state can be moving within E-UTRAN, with change of serving cell.
Release History
SLR2.2
Basic or Optional
Basic
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP)
4) 3GPP TS36.423 Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
X2 Application Protocol (X2AP)
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.
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
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
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 when requested of handover from a neighboring
inter-frequency cell.
R7 eNB can configureTarget to Source Transparent Container to be transmitted to source
eNB.
Target eNB to Source eNB Transparent Container [3GPP TS36.331]
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
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.
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.
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)
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)
System operation
Commands and Parameters
Command Parameters/Description
(Continued)
Command Parameters/Description
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
EUTRA measurement report triggering condition.
- 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.
CHG-EUTRA-A2CNF Changes and retrieves the parameter values of reporting configuration for
RTRV-EUTRA-A2CNF Event A2 to perform inter frequency handover.
- A2_THRESHOLD_RSRP: RSRP threshold used in the Event A2
EUTRA measurement report triggering condition.
- A2_THRESHOLD_RSRQ: RSRQ threshold used in the Event A2
EUTRA measurement report triggering condition.
- 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 A2.
- REPORT_AMOUNT: The number of measurement reports for Event A2.
(Continued)
Command Parameters/Description
CHG-EUTRA-A3CNF Changes and retrieves the parameter values of reporting configuration for
RTRV-EUTRA-A3CNF Event A3 to perform inter frequency handover.
- 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.
- 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 A3.
- REPORT_AMOUNT: The number of measurement reports for Event A3.
CHG-EUTRA-A5CNF Changes and retrieves the parameter values of reporting configuration for
RTRV-EUTRA-A5CNF Event A5 to perform inter frequency handover.
- A5_THRESHOLD1_RSRP: RSRP threshold 1 used in the Event A5
EUTRA measurement report triggering condition.
- A5_THRESHOLD1_RSRQ: RSRQ threshold 1 used in the Event A5
EUTRA measurement report triggering condition.
- A5_THRESHOLD2_RSRP: RSRP threshold 2 used in the Event A5
EUTRA measurement report triggering condition.
- A5_THRESHOLD2_RSRQ: RSRQ threshold 2 used in the Event A5
EUTRA measurement report triggering condition.
- 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
(Continued)
Command Parameters/Description
(Continued)
Command Parameters/Description
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.
Related Counters
Counter 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
assisted) execution.
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
InterFreqNoMeasGapOut Outgoing inter-frequency handover (no measurement gap assisted)
PrepSucc preparation success count
InterFreqNoMeasGapOut Outgoing inter-frequency handover (no measurement gap assisted)
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.
(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.
(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
assisted) execution.
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
assisted) execution.
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
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36.413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
4) 3GPP TS36.423 Evolved Universal Terrestrial Access Network (E-UTRAN); X2
Application Protocol (X2AP)
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.
System operation
Commands and Parameters
Related Commands
Commands Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP)
4) 3GPP TS36.423 Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
X2 Application Protocol (X2AP)
Feature Scope
R1 eNB can control the inter-frequency measurement of the terminal.
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 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
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.
System operation
Commands and Parameters
Command Command Description
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 304 Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) procedures in idle mode
4) 3GPP TS23.401 Technical Specification Group Services and System Aspects; GPRS
enhancements for E-UTRAN access
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
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
Cell reselection priority per carrier frequency
UTRAN (FDD or TDD) neighbouring cell information
Threshold values for cell reselection criteria
Cell reselection timer
Parameters for speed dependant cell reselection
System operation
Commands and Parameters
Related Commands
Commands 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.
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.
(Continued)
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
4) 3GPP TS23.401 Technical Specification Group Services and System Aspects; GPRS
enhancements for E-UTRAN access
Feature Scope
R1 eNB can control the UTRAN measurement of the terminal.
Incorporate UE supported bands for UTRAN
Incorporate UE Radio Access Capability for inter-frequency measurement (FGI bit
number 22)
Incorporate the necessity of measurement gap per UE supported band
Measurement gap activation/deactivation if needed
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
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.
System operation
Commands and Parameters
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.
(Continued)
(Continued)
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.
(Continued)
Family Data
Category Type Name Family/Type Description
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
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
4) 3GPP TS23.401 Technical Specification Group Services and System Aspects; GPRS
enhancements for E-UTRAN access
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.
Target eNB to Source eNB Transparent Container [3GPP TS36.413]
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
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.
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.
System operation
Commands and Parameters
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
neighbor cell information.
(Continued)
(Continued)
(Continued)
Related Counters
Family Data
Category Type Name Family/Type Description
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
(Continued)
Family Data
Category Type Name Family/Type Description
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
UTRAN_CP_ based eNB resources during the UTRAN
CAPA_CAC_F handover preparation.
AIL
RatInPrepFail Preparation fails due to insufficient QoS- count
UTRAN_CP_ based eNB resources during the UTRAN
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
(Continued)
Family Data
Category Type Name Family/Type Description
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
Related Status
N/A
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.
Release History
SLR2.2
Basic or Optional
Optional
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
4) 3GPP TS23.401 Technical Specification Group Services and System Aspects; GPRS
enhancements for E-UTRAN access
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
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).
System operation
Commands and Parameters
Related Commands
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
information is retrieved.
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
neighboring cell information.
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
CELL_NUM and RELATION_IDX parameter values to delete the UTRAN
neighboring cell information.
Parameter Description
(Continued)
Parameter Description
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.
- ci_FDD: Frequency Division Duplex.
- ci_TDD: Time Division Duplex
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.
- True: Handover is allowed.
- False: Handover is not allowed.
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
(Continued)
Parameter Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
Release History
SLR2.2
Basic or Optional
Optional
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
4) 3GPP TS23.401 Technical Specification Group Services and System Aspects; GPRS
enhancements for E-UTRAN access
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
R3 eNB can select a UTRA carrier for redirection among the neighboring UTRA carriers
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
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).
System operation
Commands and Parameters
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
the UTRAN neighboring cell information.
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.
If no CELL_NUM or FA_INDEX parameter value is entered, all UTRAN FA
objects are retrieved.
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.
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.
(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
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.
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
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.
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.
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
Limitation:
Need IOT with SRVCC capable terminal and the related network entities, i.e. EPC,
UTRAN and IMS.
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC) protocol specification
3) 3GPP TS36.413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
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
The SRVCC procedures to UTRAN are as follows: (SRVCC from E-UTRAN to UTRAN
with PS HO)
System operation
Commands and Parameters
(Continued)
Related Counters
Counter Description How to Check
(Continued)
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
4) 3GPP TS23.272 Circuit Switched Fallback in Evolved Packet System; Stage 2
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.
R3 eNB can select a UTRA carrier for redirection among the neighboring UTRA carriers
based on UTRA supported band (FDD or TDD) supported by the terminal.
Using UTRAN measurement: select Measurement Report’s UTRA carrier
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
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.
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.
4) The eNB transmits the S1 response message to the MME.
System operation
Commands and Parameters
Related Commands
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.
- 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-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.
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.
If no CELL_NUM or FA_INDEX parameter value is entered, all UTRAN
FA objects are retrieved.
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.
(Continued)
(Continued)
(Continued)
(Continued)
Related Counters
Statistics date of CSFB redirection number between LTE system and UTRAN system
collects with cell unit
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation:
RIM based SI tunneling is only possible for eNB to acquire UTRAN SI
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
4) 3GPP TS23.272 Circuit Switched Fallback in Evolved Packet System; Stage 2
Feature Scope
R1 eNB can determine on UTRAN target that will 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 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,
R3 eNB can select a UTRA carrier for redirection among the neighboring UTRA carriers
based on UTRA supported band (FDD or TDD) supported by the terminal.
Using UTRAN measurement: select Measurement Report’s UTRA carrier
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
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 enhanced 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.
4) The eNB transmits the S1 response message to the MME.
5) The eNB requests UTRAN measurement to the MS. (if possible)
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.
8) 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 CS
service after CS call setup in the UTRAN.
System operation
Commands and Parameters
Related Commands
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.
- 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-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.
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.
- If no CELL_NUM or FA_INDEX parameter value is entered, all UTRAN FA
objects are retrieved.
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.
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
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.
(Continued)
(Continued)
(Continued)
(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.
Related Counters
Statistics date of CSFB redirection number between LTE system and UTRAN system
collects with cell unit
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
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
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol specification
3) 3GPP TS36. 413 Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)
4) 3GPP TS23.272 Circuit Switched Fallback in Evolved Packet System; Stage 2
Feature Scope
R1 eNB can determine on UTRAN target than 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.
R2 eNB can carry out the procedures of CSFB with PS handover if the terminal supports
PS handover to UTRAN measurement and UTRAN.
R3 eNB can select a UTRA carrier for redirection among the neighboring UTRA carriers
based on UTRA supported band (FDD or TDD) supported by the terminal.
Using UTRAN measurement: select Measurement Report’s UTRA carrier
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
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 is available, CSFB procedure is
performed with PS handover procedure concurrently.
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.
4) The eNB transmits the S1 response message to the MME.
System operation
Commands and Parameters
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
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.
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.
(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
cell located near the eNB. Enter a 3-digit or 2-digit number whose each
digit is between 0 and 9.
- MCC2: 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.
- MNC2: 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.
- MCC3: 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.
- MNC3: 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.
- MCC4: 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.
- MNC4: 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.
- MCC5: 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.
- MNC5: 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.
- DUPLEX_TYPE: Duplex type information of the UTRAN neighbor cell
located near the eNB.
ci_FDD: Frequency Division Duplex
ci_TDD: Time Division Duplex
- P_SCM_CODE: The primary scramble code of the UTRAN neighbor cell
located near the eNB (for FDD)
- 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.
(Continued)
Related Counters
Statistics date of CSFB PS Handover number between LTE system and UTRAN system
collects with cell unit
Family
Category Type Name Description
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
UTRAN PS handover execution.
CsfbPsHoPrepFailUTRAN_ Preparation fails due to reset
CP_CC_FAIL notification (eNB failure or block restart)
from ECMB or by the ECCB block
during the CSFB PS handover
preparation.
CsfbPsHoPrepFailUTRAN_ Preparation fails due to S1AP
S1AP_CU_FAIL specification cause during the CSFB PS
handover preparation.
(Continued)
Family
Category Type Name Description
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
PS handover execution.
CsfbPsHoFailUTRAN_UP_ A call is released due to the failure in the
GTP_FAIL GTP block during the CSFB PS
handover execution.
CsfbPsHoFailUTRAN_UP_ A call is released due to the failure in the
MAC_FAIL MAC block during the CSFB PS
handover execution.
CsfbPsHoFailUTRAN_UP_ A call is released due to the failure in the
PDCP_FAIL PDCP block during the CSFB PS
handover execution.
CsfbPsHoFailUTRAN_UP_ A call is released due to the failure in the
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.
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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 inter-group(k)
carriers
Blind
offloading to
inter-RAT
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).
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)
Basic or Optional
Optional Feature: Three intra-LTE LB features can be activated or deactivated.
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
2) 3GPP 36.331: E-UTRAN; Radio Resource Control (RRC); Protocol specification
3) 3GPP 36.423: E-UTRAN; X2 application protocol (X2AP)
4) 3GPP 36.902: E-UTRAN; Self-configuring and self-optimizing network (SON) use
cases and solutions
Feature Description
Samsung intra-LTE LB operates according to the following procedures.
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.
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.
System operation
Commands and Parameters
Related commands
Commands Description
PLD_LbGroup is as below:
Paramter Range Default Value Description
PLD_ActiveModeLbConf is as below:
Paramter Range Default Value Description
(Continued)
(Continued)
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
Category Type Name Description
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.
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
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.
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
Basic or Optional
Optional Feature: The idle UE distribution feature can be activated or deactivated.
Reference
1) 3GPP 36.300: E-UTRA and E-UTRAN; overall description Stage 2
2) 3GPP 36.331: E-UTRAN; Radio Resource Control (RRC); Protocol specification
3) 3GPP 36.902: E-UTRAN; Self-configuring and self-optimizing network (SON) use
cases and solutions
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)
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.
System operation
Commands and Parameters
Related commands
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:
Parameter Description How to Set/Change
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:
Parameter Description How to Set/Change
(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
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
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
1) 3GPP 36.300: E-UTRA and E-UTRAN; overall description Stage 2
2) 3GPP 36.331: E-UTRAN; Radio Resource Control (RRC); Protocol specification
3) 3GPP 36.423: E-UTRAN; X2 application protocol (X2AP)
4) 3GPP 36.902: E-UTRAN; Self-configuring and self-optimizing network (SON) use
cases and solutions
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.
System operation
Commands and Parameters
Related Command List
Command Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Feature Scope
None
Reference
1) 3GPP 36.300: E-UTRA and E-UTRAN; overall description Stage 2
2) 3GPP 36.331: E-UTRAN; Radio Resource Control (RRC); Protocol specification
3) 3GPP 36.902: E-UTRAN; Self-configuring and self-optimizing network (SON) use
cases and solutions
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.
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.
System operation
Commands and Parameters
Related Command List
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.
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.
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.
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
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
Reference
None
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.
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.
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.
UE A B
QCI 1 9
Mobility Profile Mobility Profile 1 Mobility Profile 2
System operation
Commands and Parameters
Related Command List
Command Description
Default
Parameter Description Range
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.
(Continued)
Default
Parameter Description Range
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
- ci_Macro_eNB: Indicates the macro eNB.
- ci_Home_eNB: Indicates the home eNB.
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
number with each digit being from 0 to 9.
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.
The broadcast PLMN list information (MCC) of E- - -
mcc1[4] UTRAN 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 E- - -
mnc1[4] UTRAN neighboring cell to the eNB. It is a three-digit or
two-digit number with each digit being from 0 to 9.
The broadcast PLMN list information (MCC) of E- - -
mcc2[4] UTRAN 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 E- - -
mnc2[4] UTRAN neighboring cell to the eNB. It is a three-digit or
two-digit number with each digit being from 0 to 9.
The broadcast PLMN list information (MNC) of E- - -
mnc3[4] UTRAN neighboring cell to the eNB. It is a three-digit or
two-digit number with each digit being from 0 to 9.
The broadcast PLMN list information (MCC) of E- - -
mcc4[4] UTRAN neighboring cell to the eNB. It is a three-digit
number with each digit being from 0 to 9.
(Continued)
Default
Parameter Description Range
Value
The broadcast PLMN list information (MNC) of E- - -
mnc4[4] UTRAN neighboring cell to the eNB. It is a three-digit or
two-digit number with each digit being from 0 to 9.
The broadcast PLMN list information (MCC) of E- - -
mcc5[4] UTRAN 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 E- - -
mnc5[4] UTRAN neighboring cell to the eNB. It is a three-digit or
two-digit number with each digit being from 0 to 9.
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.
- False: The neighboring cell cannot be deleted.
Whether to perform handover to E-UTRAN neighboring - -
cell.
isHOAllowed
- True: Handover is allowed.
- False: Handover is not allowed.
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.
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
blocks (MAC, RLC, PDCP, GTP)
Intra eNB handover preparation fails due to - -
IntraEnbPrepFail_CP_
reset notification (eNB failure or block restart)
CC_FAIL
from ECMB or by the ECCB block
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
IntraEnbPrepFail_S1A Intra eNB handover preparation fails due to - -
P_LINK_FAIL the S1 SCTP link failure
IntraEnbPrepFail_S1A Intra eNB handover preparation fails due to - -
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
ECMB or by the ECCB block
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
(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
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
Benefits
Operator can differentiate LTE to UTRAN mobility control policy for each service.
Release History
SLR 2.4
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.
Reference
None
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.
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.
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.
UE A B
QCI 1 9
Mobility Profile Mobility Profile 1 Mobility Profile 2
System operation
Commands and Parameters
Related Command List
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
neighbor cell information.
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-
CELL_NUM and RELATION_IDX parameter values to delete the UTRAN
UTRAN
neighbor cell information.
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
objects are retrieved.
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
Parameter Description Range
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
neighbor cell located near the eNB is valid.
RNC ID of the UTRAN neighbor cell located near - -
rncId
the eNB.
(Continued)
Default
Parameter Description Range
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
located near the eNB.
PLMN information (MCC) of the UTRAN neighbor - -
mcc0[4] cell located near the eNB. Enter a 3-digit number
whose each digit is between 0 and 9.
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.
PLMN information (MCC) of the UTRAN neighbor - -
mcc1[4] cell located near the eNB. Enter a 3-digit number
whose each digit is between 0 and 9.
PLMN information (MNC) of the UTRAN neighbor - -
mnc1[4] cell located near the eNB. Enter a 3-digit or 2-digit
number whose each digit is between 0 and 9.
PLMN information (MCC) of the UTRAN neighbor - -
mcc2[4] cell located near the eNB. Enter a 3-digit number
whose each digit is between 0 and 9.
PLMN information (MNC) of the UTRAN neighbor - -
mnc2[4] cell located near the eNB. Enter a 3-digit or 2-digit
number whose each digit is between 0 and 9.
PLMN information (MCC) of the UTRAN neighbor - -
mcc3[4] cell located near the eNB. Enter a 3-digit number
whose each digit is between 0 and 9.
PLMN information (MNC) of the UTRAN neighbor - -
mnc3[4] cell located near the eNB. Enter a 3-digit or 2-digit
number whose each digit is between 0 and 9.
PLMN information (MCC) of the UTRAN neighbor - -
mcc4[4] cell located near the eNB. Enter a 3-digit number
whose each digit is between 0 and 9.
PLMN information (MNC) of the UTRAN neighbor - -
mnc4[4] cell located near the eNB. Enter a 3-digit or 2-digit
number whose each digit is between 0 and 9.
PLMN information (MCC) of the UTRAN neighbor - -
mcc5[4] cell located near the eNB. Enter a 3-digit number
whose each digit is between 0 and 9.
(Continued)
Default
Parameter Description Range
Value
PLMN information (MNC) of the UTRAN neighbor cell - -
mnc5[4] located near the eNB. Enter a 3-digit or 2-digit number
whose each digit is between 0 and 9.
Duplex type information of the UTRAN neighbor cell - -
located near the eNB.
duplexType
- ci_FDD: Frequency Division Duplex
- ci_TDD: Time Division Duplex
The primary scramble code of the UTRAN neighbor cell - -
pScmCode
located near the eNB (for FDD)
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.
- False: Cannot delete.
Whether to perform handover to a specific UTRAN - -
neighbor cell.
isHOAllowed
- True: Handover is allowed.
- False: Handover is not allowed.
rimStatus Indicates the RIM connection status. - -
Indicates whether the relevant UTRAN neighbor cell - -
supports the VoIP.
voipIncapable
- False: VoIP is not supported.
- True: VoIP is supported
Indicates whether the relevant GERAN neighbor cell - -
supports the RIM.
rimSupport
- False: RIM is not supported.
- True: RIM is supported.
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.
(Continued)
Default
Parameter Description Range
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.
- ci_TDD: Time 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
frequency with priority higher than the currently camped
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
frequency with priority higher than the currently camped
GH_QREL9
frequency, in the Rel-9.
THRESH_XLO In the Rel-9, the threshold used to reselect the low-priority - -
W_QREL9 frequency from the high-priority frequency
Related Counters
Counter Description How to Check
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.
(Continued)
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
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.
Release History
SLR 2.2
Basic or Optional
Optional
Reference
Standard or Technical Reports:
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.
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 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.
System Operation
Commands and Parameters
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:
(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
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
SLR2.2 and Later | New Entry | Basic Feature
Limitation:
None
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.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
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
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.
System operation
Commands and Parameters
Related Commands
(Continued)
(Continued)
(Continued)
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
Limitation
This feature supports IPv4 only
Reference
Standard or Technical Reports:
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
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.
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
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.
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.
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.
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.
System Operation
Commands and Parameters
Command Parameters Description
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
SLR2.2 and Later | New Entry | Basic Feature
Limitation:
The integrity protection shall be provided only to NAS and RRC-signalling
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) 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
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.
The agreed integrity algorithm shall provide integrity of the RRC messages at PDCP layer
as it is depicted below figure.
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.
System operation
Commands and Parameters
Related Commands
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 protection algorithm and ciphering algorithm can be changed.
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
Limitation:
None
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 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.
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.
The agreed ciphering algorithm optionally protects RRC messages and UP traffic at PDCP
layer as it is depicted below figure.
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.
System operation
Commands and Parameters
Related Commands
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 protection algorithm and ciphering algorithm can be changed.
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
Reference
Standard or Technical Reports:
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 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
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.
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.
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.
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).
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.
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.
System Operation
Commands and Parameters
Related commands
Command Description
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 (%)
(Continued)
Default
Parameters Description Range
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
‘Capacity based CAC Fail’ when the requested
emergency or handover call exceeds MAX_CALL_
COUNT x CALL_CAC_THRESH_FOR_EMER_HO
(%)’.
Range: 0~100 (%)
Default: 100 (%)
(Continued)
Default
Parameters Description Range
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
‘Capacity based CAC Fail’ when the requested
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
‘Capacity based CAC Fail’ when the requested
emergency or handover bearer exceeds MAX_DRB_
COUNT x DRB_CAC_THRESH_FOR_EMER_HO
(%)’.
Range: 0~100 (%)
Default: 100 (%)
Related Alarms
N/A
Related Status
N/A
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.
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.
Release History
SLR 2.2
SLR 3.0
Operator is enabled to configure the maximum number of GBR bearers per cell.
Limitation:
None
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.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
Functional Architecture for CAC
Following table shows a 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 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.
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)
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.
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.
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.
SYSTEM OPERATION
Commands and Paramters
Related commands
Command 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
parameter value, the QoS CAC Fail is generated.
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
parameter value, the QoS CAC Fail is generated.
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
(Continued)
(Continued)
(Continued)
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
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
Limitation:
None
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.413 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
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
Functional Architecture for CAC
Following table shows a 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 preemption. For other two CAC features, refer to LTE-SW4101 and
LTE-SW4102.
System operation
Commands and Parameters
Related commands
Command 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
the number of connected calls
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
RESH_FOR_E handover calls in percentage.
MER_HO When a normal call is requested, if
the number of connected calls
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.
Non-GBRs are always allowed.
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
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
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
Limitation
None
Reference
1) 3GPP TS36.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC); Protocol Specification
2) 3GPP TS36.304 Evolved Universal Terrestrial Radio Access (E-UTRA); User
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
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.
System operation
Commands and Parameters
Related commands
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.
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
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
Limitation:
N/A
Reference
Standard or Technical Reports:
1) 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
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
System operation
Commands and Parameters
Related Commands
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.
(Continued)
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
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.
Reference
Standard or Technical Reports:
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.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
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
Operator can define Operator-Specific QCIs via LSM. Samsung eNB supports up to 32
Operator-Specific QCIs.
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.
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.
(Continued)
Default
Parameter Range Description
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.
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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.
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
SLR2.2 and Later | New Entry | Basic Feature
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
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.
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.
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.
System operation
Commands and Parameters
Related Commands
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
(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
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
SLR2.2 and Later | New Entry | Basic Feature
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
[1] 3GPP TS36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 2
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
(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
8 Non-GBR 8 300 ms 10 Video (Buffered Streaming)
TCP-based (e.g. www, e-mail, chat,
ftp, p2p file sharing, progressive
video, etc.)
-6
9 Non-GBR 9 300 ms 10 Video (Buffered Streaming)
TCP-based (e.g. www, e-mail, chat,
ftp, p2p file sharing, progressive
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.
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.
System operation
Commands and Parameters
Related Commands
This function is working based on the value received through the S1AP. The eNB does
not have separate system operation related command or parameter.
Related System Parameters
N/A
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
Limitation:
None
Reference
1) 3GPP TS36.413, Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
S1 Application Protocol (S1AP)
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
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.
System operation
Commands and Parameters
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.
Related Alarms
N/A
Related Status
N/A
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
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
Standard or Technical Reports:
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.321 Evolved Universal Terrestrial Radio Access (E-UTRA); Medium
Access Control (MAC) protocol specification, Section 6.2.1
3) 3GPP TS36.203 Policy and charging control architecture
4) 3GPP TS23.401 General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access, Section 4.7
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
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:
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.
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.
System Operation
Commands and Parameters
N/A
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
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).
Release History
SLR 2.2
SLR 2.4
Basic or Optional
Basic
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
1) 3GPP TS36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 27
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
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.
System Operation
Commands and Parameters
Related Commands
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.
(Continued)
Related Alarms
N/A
Related Status
N/A
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
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
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.
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.
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.
System operation
Commands and Parameters
Related Command List
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
Parameter Description Range
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
Benefits
Operator can reduce CAPEX.
Release History
SLR2.2
Basic or Optional
Optional
Limitation:
None
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.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC) protocol specification
3) 3GPP TS23.251 Network Sharing; Architecture and functional 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
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.
System operation
Commands and Parameters
Related Commands
Command Description
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.
(Continued)
(Continued)
Related Counters
N/A
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
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
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.
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.
System operation
Commands and Parameters
Related commands
Command Description
(Continued)
(Continued)
mcc3 - 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 #3, one
of the six lists, is entered.
CHG-CELL-INFO and RTRV-CELL-INFO are used to change and
retrieve the parameter
mnc3 - 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 #3, one of the six lists, is
entered.
CHG-CELL-INFO and RTRV-CELL-INFO are used to change and
retrieve the parameter
mcc4 - 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 #4, one
of the six lists, is entered.
CHG-CELL-INFO and RTRV-CELL-INFO are used to change and
retrieve the parameter
mnc4 - 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 #4, one of the six lists, is
entered.
CHG-CELL-INFO and RTRV-CELL-INFO are used to change and
retrieve the parameter
mcc5 - 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 #5, one
of the six lists, is entered.
CHG-CELL-INFO and RTRV-CELL-INFO are used to change and
retrieve the parameter
mnc5 - 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 #5, one of the six lists, is
entered.
CHG-CELL-INFO and RTRV-CELL-INFO are used to change and
retrieve the parameter
Related Commands
Command Parameters Description
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
Limitation:
None
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.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP)
3) 3GPP TS23.251 Network Sharing; Architecture and functional 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.
System operation
Commands and Parameters
Command Parameter Description
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
(Continued)
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)
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
(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.
AirRlcByteUl_ Air RLC uplink bytes
PLMN2 The uplink bytes by RLC. Collects per cell, QCI
and PLMN for the data byte received from the
terminal.
AirRlcByteUl_ Air RLC uplink bytes
PLMN3 The uplink bytes by RLC. Collects per cell, QCI
and PLMN for the data byte received from the
terminal.
AirRlcByteUl_ Air RLC uplink bytes
PLMN4 The uplink bytes by RLC. Collects per cell, QCI
and PLMN for the data byte received from the
terminal.
AirRlcByteUl_ Air RLC uplink bytes
PLMN5 The uplink bytes by RLC. Collects per cell, QCI
and PLMN for the data byte received from the
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.
AirRlcByteDl_ Air RLC downlink bytes
PLMN1 The downlink bytes by RLC. Collects per cell,
QCI and PLMN for the data byte received from
the terminal.
(Continued)
(Continued)
(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
AirRlcByteUlC Most recently collected AirRlcByteUl value
urrent_PLMN3
AirRlcByteUlC Most recently collected AirRlcByteUl value
urrent_PLMN4
AirRlcByteUlC Most recently collected AirRlcByteUl value
urrent_PLMN5
AirRlcByteDlC Most recently collected AirRlcByteUl value
urrent_PLMN0
AirRlcByteDlC Most recently collected AirRlcByteUl value
urrent_PLMN1
AirRlcByteDlC Most recently collected AirRlcByteUl value
urrent_PLMN2
AirRlcByteDlC Most recently collected AirRlcByteUl value
urrent_PLMN3
AirRlcByteDlC Most recently collected AirRlcByteUl value
urrent_PLMN4
AirRlcByteDlC Most recently collected AirRlcByteUl value
urrent_PLMN5
AirRlcByteUlC AirRlcByteUl collection frequency
nt_PLMN0
AirRlcByteUlC AirRlcByteUl collection frequency
nt_PLMN1
AirRlcByteUlC AirRlcByteUl collection frequency
nt_PLMN2
AirRlcByteUlC AirRlcByteUl collection frequency
nt_PLMN3
(Continued)
(Continued)
Related KPI/PI
N/A
Related Alarms
N/A
Related Status
N/A
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
Limitation
This feature is valid in MOCN or MORAN network architecture, where multiple
operators share single spectrum or a base station.
Reference
N/A
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.)
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.
System Operation
Commands and Parameters
N/A
(Continued)
Related Alarms
N/A
Related Status
N/A
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
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
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
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
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