FO - SP2105 - E01 - 0 LTE Air Interface Protocols and Signaling Procedures

LTE Air Interface Protocols and
Signaling Procedures
Course objectives:
 Understand and master LTE interfaces and protocols.
 Understand and master RRC protocol state, bearer probability,
and common signaling of SM and MM protocols.
 Understand composition of a broadcast message, and signaling
of System Information Blocks (SIBs).
 Understand and master RRC layer signaling and signaling
analysis for RRC connection establishment, reestablishment,
release, and reconfiguration procedures.
 Understand and master common signaling procedures, such as
attach, detach, service request, and bearer setup.
Contents
Chapter 1 LTE Interfaces and Protocols.....................................................................................................1
1.1 E-UTRAN Interface Protocol Model...................................................................................................1
1.2 LTE Air Interface Protocols.................................................................................................................1
1.2.1 Control Plane Protocols.............................................................................................................1
1.2.2 User Plane Protocols..................................................................................................................2
1.3 LTE Interface Introduction...................................................................................................................3
1.3.1 S1 Interface................................................................................................................................3
1.3.2 X2 Interface...............................................................................................................................5
1.4 LTE Signaling Message Structures......................................................................................................7
1.4.1 LTE Signaling Flow and Service Flow......................................................................................7
1.4.2 NAS Signaling...........................................................................................................................9
1.4.3 RRC Signaling.........................................................................................................................10
1.5 Bearer-Related Concepts....................................................................................................................12
1.5.1 EPS Bear Architecture.............................................................................................................12
1.5.2 Bear Concepts..........................................................................................................................12
1.5.3 Bearer Classification................................................................................................................14
1.5.4 Connection Concepts...............................................................................................................15
Chapter 2 Signaling Message Analysis......................................................................................................17

2.1 Broadcast Message Analysis..............................................................................................................17
2.1.1 Master Information Block........................................................................................................19
2.1.2 System Information..................................................................................................................20
2.1.3 System Information Block Type1............................................................................................25
2.2 RRC Signaling Analysis....................................................................................................................26
2.2.1 RRC Connection Establishment Procedure..............................................................................26
2.2.2 RRC Connection Reestablishment Procedure..........................................................................41
2.2.3 RRC Connection Release Procedure........................................................................................44
2.2.4 RRC Connection Reconfiguration Procedure..........................................................................46
2.2.5 Security Mode Signaling Analysis...........................................................................................64
i
2.3 Common Signaling Procedures..........................................................................................................67
2.3.1 Attach and Detach Procedures.................................................................................................67
2.3.2 Service Request Procedure.......................................................................................................78
2.3.3 Dedicated Bearer Procedures...................................................................................................82
ii
Chapter 一 LTE Interfaces and Protocols
一.1 E-UTRAN Interface Protocol Model
The following figure shows an E-UTRAN interface protocol model. The protocol model is
applicable to all E-UTRAN interfaces, including S1 and X2 interfaces. It inherits the principles for
defining a UTRAN interface protocol model, meaning that the control plane is separated from the
user plane, and that the radio network layer is separated from the transport network layer. This
protocol model allows the control plane and user plane, and the radio network layer and transport
network layer technologies to evolve independently, thereby reducing the costs of LTE system
interface standardization.
Radio Control Plane User Plane

Network
Layer Application
Protocol
Transport Transport Network Transport Network

Network User Plane User Plane
Layer
Signalling Data
Bearer(s) Bearer(s)
Physical Layer
一.2 LTE Air Interface Protocols
一.2.1 Control Plane Protocols
The following figure shows the structure of the control plane protocol stack.
1
Figure 1.2-1 Air Interface Control Plane Protocol Stack
PDCP is terminated in the eNB on the network side, and performs the functions such as
ciphering and integrity protection for the control plane.
RLC and MAC are terminated in the eNB on the network side, and perform the same
functions as for the user plane.
RRC is terminated in the eNB on the network side, and performs the following functions:
- Broadcast
- Paging
- RRC connection management
- RB control
- Mobility functions
- UE measurement reporting and control
The NAS control protocol is terminated in the MME on the network side, and performs the
following functions:
- EPS bearer management

- Authentication
- ECM-IDLE mobility handling
- Paging origination in ECM-IDLE
- Security control
一.2.2 User Plane Protocols
The following figure shows the structure of the user plane protocol stack.
2
Chapter 2 Signaling Message Analysis
Figure 1.2-2 Air Interface User Plane Protocol Stack
User-plane PDCP, RLC, and MAC are all terminated in the eNB on the network side, and
perform the following functions for the user plane:
- Header compression
- Ciphering
- Scheduling
- ARQ and HARQ
一.3 LTE Interface Introduction

Compared to a 2G/3G system, an LTE system adds two new interfaces, meaning the S1
interface and X2 interface. The S1 interface is the interface between the eNB and the MME/S-
GW, and includes the S1 user plane interface and S1 control plane interface. The X2 interface is
the interface between eNBs, and also includes the X2 user plane interface and X2 control plane
interface.
一.3.1 S1 Interface
The S1 interface is the interface between the eNB and the MME/S-GW. The difference
between the S1 interface and the Iu interface in a 3G UMTS system is that the Iu interface is
connected to both the PS and CS domains of a 3G core network, while the S1 interface supports
only the PS domain.
1. S1 Control Plane
The S1 control plane interface is located between the eNodeB and the MME. The transport
network layer is built on IP transport, which is similar to the user plane. To ensure reliable
transport of signaling messages, SCTP is added on top of IP. The application layer signaling
protocol is referred to as S1-AP. For the control plane protocol stack of the S1 interface, see the
following figure.
3
LTE Air Interface Protocols and Signaling Procedures
The S1 control plane interface has the following functions:
 SAE bearer service management (including bearer setup, modification, and release)
 S1 UE context release
 Mobility management functions for UEs in LTE_ACTIVE state (including intra-LTE

handover and inter-3GPP-RAT handover)
 S1 paging
 NAS signaling transport
 S1 interface management (including reset, error indication, and overload indication)
 Network sharing
 Roaming and area restriction support
 NAS node selection
 Initial context setup
The radio network layer of the S1 interface does not provide traffic control and congestion
control functions.
Figure 1.3-3 S1 Interface Control Plane Protocol Stack
2. S1 User Plane
The S1 user plane interface (S1-UP) is located between the eNB and the S-GW. For the
protocol stack of the S1-UP, see the following figure. The transport network layer of the S1-UP is
built on IP transport. GTP-U is used on top of UDP/IP to carry the user plane PDUs between the
S-GW and the eNB.
4
GTP-U has the following features:
 GTP-U supports IPv4/UDP-based transport and also IPv6/UDP-based transport.
 Data between tunnel endpoints is routed based on IP address and UDP port number.
 The UDP header is independent from the used IP version.
The radio network layer protocols of the SI-UP provide the following functions:
 Indicating the SAE access bearer to which a data packet belongs at the S1 target node
 Avoiding data loss during mobility procedures
 Error handling mechanism
 MBMS support function
 Packet loss detection mechanism
Figure 1.3-4 S1 Interface User Plane Protocol Stack
一.3.2 X2 Interface
The X2 interface is the interface between eNBs. The principle used to define the X2 interface
is the same as that used to define the S1 interface, which is reflected by the similarity between
the user-plane and control-plane protocol stack structures of the X2 interface and those of the
S1 interface.
1. X2 User Plane
5
The X2 user plane interface (X2-UP) provides transport of user data between eNBs. For the
protocol stack of the X2-UP, see the following figure. The transport network layer of the X2-UP is
built on IP transport. GTP-U is used on top of UDP/IP to carry user plane PDUs between eNBs.
Figure 1.3-5 X2 Interface User Plane Protocol Stack
2. X2 Control Plane
For the protocol stack of the X2 control plane interface, see the following figure. The principle
that an LTE system uses to define the X2 interface is the same as that used to define the S1
interface. To ensure reliable transport of signaling messages, SCTP is used on top of IP. The
application layer signaling protocol is referred to as X2-AP.
Figure 1.3-6 X2 Interface Control Plane Protocol Stack
6
The X2 interface has the following functions:
 Mobility management, including handover resource allocation, SN status transfer, and

UE context release
 Load management, used to transfer load information and resource state between eNBs
 Error indication, used to indicate undefined error information that occurs during the
interaction between eNBs
 Reset, used to reset the X2 interface between eNBs
 X2 setup, used to exchange cell information between eNBs
 Sending the changed configuration information of one eNB to the other eNB, thereby
unifying information between eNBs
The X2 setup procedure allows eNBs to exchange cell information and to set up adjacent cell
adjacent relationship. The exchanged information is classified into the following two types:
- Load and interference-related information
This type of information is mainly used for inter-cell interference coordination, such as
High Interference Indication (HII) and Overload Indication (OI) for uplink ICIC, and
Relative Narrowband Tx Power (RNTP) for downlink ICIC.
- Handover-related information
The handover via the X2 interface is referred to as seamless handover or lossless

handover, because its purpose is to archieve fast handover. Compared to the handover
via the S1 interface, the handover via the X2 interference is preferentially supported.
一.4 LTE Signaling Message Structures
一.4.1 LTE Signaling Flow and Service Flow
There is only one NE type, eNodeB, on the LTE radio side. The control plane and user plane
of the EPC are separated as two NE types, MME and SGW. The protocol interfaces supported by
an eNodeB include Uu, S1, and X2 control plane and user plane interfaces.
7
Figure 1.4-7 X2 Interface Control Plane Protocol Stack
In terms of the signaling flow composition, signaling can be classified into three types: NAS
signaling, RRC signaling, and signaling transmitted on S1 and X2 interfaces. NAS signaling
focuses on two types of signaling: SM signaling and MM signaling. RRC signaling belongs to the
radio access network.
You can refer to the 3GPP TS 24.301 for NAS signaling details, the 3GPP TS36.331 for RRC
signaling details, and the 3GPP TS 36.413 and TS 36.423 for details about S1 and X2 interface-
related signaling.
U MME PDN/
E NAS 24.301 /
NAS S-GW
eN eNo
RRC 36.331 RRC od S1AP S1AP 29.274
36.413 deB GTP-C
eB X2AP X2AP
PDCP 36.323 PDCP 36.423
SCTP 36.412 SCTP UDP
RLC 36.322 RLC
IP 36.422 IP IP
MAC 36.321 MAC L2 L2 L2
PHY36.211~36.214PHY L1 L1 L1
LTE-Uu S1-MME/X2-C
8
一.4.2 NAS Signaling
NAS signaling includes MM signaling and SM signaling.
NAS EPS MM signaling message:
Common procedures
5.4.1 GUTI reallocation procedure
5.4.2 Authentication procedure
5.4.3 Security mode control procedure
5.4.4 Identification procedure
5.4.5 EMM information procedure
Specific procedures
5.5.1 Attach procedure
5.5.1.2 Attach procedure for EPS services
5.5.1.3 Combined attach procedure for EPS services and
non-EPS services
5.5.2 Detach procedure
5.5.2.2 UE initiated detach procedure
5.5.2.3 Network initiated detach procedure
5.5.3 Tracking area updating procedure
5.5.3.2 Normal and periodic tracking area updating
procedure
5.5.3.3 Combined tracking area updating procedure
Connection management (ECM) procedures
5.6.1 Service request procedure
5.6.2 Paging procedure
5.6.3 Transport of NAS messages procedure
5.6.4 Generic transport of NAS messages procedure
NAS EPS SM signaling message:
9
Network initiated ESM

procedures(Procedures related to EPS bearer
contexts)
6.4.1 Default EPS bearer context
activation procedure
6.4.2 Dedicated EPS bearer context
activation procedure
6.4.3 EPS bearer context modification
procedure
6.4.4 EPS bearer context deactivation
procedure
UE requested ESM procedures(Transaction
related procedures)
6.5.1 UE requested PDN connectivity
procedure
6.5.2 UE requested PDN disconnect
procedure
6.5.3 UE requested bearer resource
allocation procedure
6.5.4 UE requested bearer resource
modification procedure
Miscellaneous procedures
6.6.1.2 ESM information request procedure
6.6.1.3 Exchange of protocol configuration
options in other messages
10
6.6.2 Notification procedure
一.4.3 RRC Signaling
Functions of the RRC protocol can be classified into the following three types:
 Providing connection management and message transfer for the NAS layer
 Sending of paging and system information
 Setup, modification, and release of RRC connections and radio bearers
 Transfer of NAS messages between UEs and NAS
 Providing parameter configuration for lower-layer protocol entities
 Radio configurations control (physical layer and L2 configurations)
 Cell's public parameters and user-specific parameters
 QoS management (such as semi-persistent scheduling and rate control)
 In charge of measurement and control related to the UE mobility management
 IDLE state: cell selection and reselection
 CONNECTED state: handover
RRC signaling includes the following messages:
 System broadcast message
 Paging message
 RRC connection message (request, establishment, and release)
 RRC connection reestablishment message
 RRC connection reconfiguration message
 Inter-system mobility management message
 Measurement message
11
12
一.5 Bearer-Related Concepts
一.5.1 EPS Bear Architecture
Figure 1.5-8 EPS Bearer Architecture
The end-to-end service includes an EPS bearer and an external bearer. The EPS bearer
includes an E-RAB bear and an S5/S8 bear. The E-RAB bearer includes a radio bearer and an
S1 bearer.
一.5.2 Bear Concepts
The access network structure of the EPS is more flattened. The RNC and NodeB nodes in
the UMTS are simplified into one eNodeB node in the EPS, thereby changing the QoS structure.
The QoS structure of the EPS is simpler than that of the UMTS. By introducing new concepts
such as default bearer into the QoS, the EPS hopes to better realize "Always Online".
In the core network, the QoS of the EPS is used to map IP QoS to the QoS Class Identifier
(QCI) of a bearer. In the access network, the QoS of the EPS is used to correspond the QCI on
the S1 interface to the QCI characteristics to be performed by the eNodeB.
13
EPS bearers provide QoS guarantee for specific attributes between UEs and PDNs, and are
classified into default bearer and dedicated bearers.
Default bearer: A default bearer is a bearer for data and signaling that meets the default
QoS requirement. It can be simply regarded as a bearer trying to provide a UE with always-on IP
connectivity to a PDN. It is established when the UE connects to the PDN and released when the
PDN connection is released.
Dedicated bearer: A dedicated bearer is established based on a PDN connection to meet

specific QoS requirements (which the default bearer cannot meet). The QoS requirement of a
dedicated bearer is usually higher than that of the default bearer. A dedicated bearer is
associated with a UL Traffic Flow Template (TFT) at the UE, and a DL TFT at the PDN GW. The
TFT contains filters for service data flows, but these filters can only match packets meeting
specific rules.
GBR/Non-GBR bearer: Dedicated network resources related to the Guaranteed Bit Rate
(GBR) are permanently allocated to a bearer during the bearer setup or modification procedure
through functions of the eNodeB, such as admission control. The bit rate of the bearer is
guaranteed to stay the same. If the rate of a bearer cannot stay the same, the bearer is a non-
GBR bearer.
For a user and a connection, a dedicated bearer can be a GBR bearer or a non-GBR bearer.
However, a default bearer can only be a non-GBR bearer. The dedicated and default bearers
share one PDN connection (UE address and PDN address), which means that the dedicated
bearer must be established based on the default bearer, and bound to the default bearer.
An EPS bearer is a logical aggregation of one or multiple Service Data Flows (SDFs)
between a UE and the PDN GW. In the EPC/E-UTRAN, the bearer-level QoS control is carried
out by EPS bearers. This means that the SDFs mapped to the same EPS bearer will be under
the same bearer-level QoS control (such as scheduling strategy, queue management strategy,
rate adjustment strategy, and RLC configuration). To provide different bearer-level QoS for two
SDFs, different EPS bearers should be established for the two SDFs.
In a PDN connection, there is only one default bearer, but may be multiple dedicated
bearers. A user can establish up to 11 bearers. When a UE requests a new service, the S-
GW/PDN-GW receives a PCC rule from the PCRF, including the QoS required by the service. If
the default bearer cannot provide the required QoS, another bearer is needed, meaning that a
dedicated bearer is to be established to provide the QoS.
14
After receiving the end-to-end services to be transmitted from the PCEF, the MME/S-GW
combines the end-to-end services of one traffic class, and generates an aggregated QoS
description (including at least the bit rate) for the traffic class. Each SAE bearer will send such a
QoS description to the eNodeB. When an end-to-end service is started, terminated, or modified,
the MME/UPE receives the related information, updates the aggregated QoS description, and
then forwards the updated description to the eNodeB.
Like the MME/S-GW, the LTE system will also perform the mapping of end-to-end service IP
flows to SAE bearers.
To identify packets belonging to different SAE bearers, the eNodeB and the MME/S-GW
need to know the aggregated QoS description of an SAE bearer. The eNodeB uses this
aggregated QoS description for bearer scheduling in the downlink direction and bearer
management in the uplink direction. The MME/S-GW uses this QoS description for bearer
management in the uplink and downlink directions.
In the downlink direction, the eNodeB handles IP packets based on the aggregated QoS
description of the SAE bearer. In the uplink direction, the eNodeB manages IP packets based on
the aggregated QoS description of the bearer.
一.5.3 Bearer Classification
In terms of the carried contents, bearers are classified into the following two types:
 Data Radio Bearer (DRB), carrying data on the PDSCH allocated by the eNB
 Signaling Radio Bearer (SRB), including the following three types:
 SRB0: carrying RRC signaling on the CCCH
 SRB1: carrying RRC and NAS signaling on the DCCH
 SRB2: carrying NAS signaling on the DCCH
 When the RRC connection of a UE is not established, SRB0 is used to carry RRC
signaling. When SRB2 is not established, SRB1 is used to carry NAS signaling.
In terms of the carrying mode of NAS signaling, bearers are classified into the following types:
 Due to the increase of bandwidth and improvement of data transmission performance, the
data carrying ability of an RRC message in LTE is greatly improved. Therefore, all NAS
messages can be transmitted in RRC messages, thereby simplifying signaling
procedures.
15
 NAS signaling is transferred through the following four RRC messages:
 ULInformationTransfer and DLInformationTransfer (carried by SRB2, or SRB1 if

the SRB2 is not established)
 RRCConnectionSetupComplete and RRCConnectionReconfiguration (carried by

SRB1)
 RRCConnectionSetupComplete (only carrying the initial direct transfer of NAS)
一.5.4 Connection Concepts
UE-associated logical S1-connection: A UE-associated logical S1-connection is identified

by an MME UE S1AP ID at the MME side, and an eNB UE S1AP ID at the eNB side. This
connection may exist before the S1 UE context setup.
NAS signalling connection: A NAS signaling connection is an end-to-end connection

between a UE and the MME. This connection includes an "LTE-Uu" RRC connection and an S1
AP connection of the S1 interface.
16
Chapter 二 Signaling Message Analysis
二.1 Broadcast Message Analysis
A UE in IDLE or CONNECTED state needs to receive system information. In the following
scenarios, the UE needs to receive a broadcast:
The UE accesses a new cell:
 Selecting or reselecting to a cell
 Finishing a handover
 Entering the E-UTRAN from another system
 Backing to the coverage area
The system information changes:
 Receiving a system information change indication
 Receiving an ETWS or CMAS notification
 Exceeding the maximum validity time
A system information broadcast is classified into multiple System Information Blocks (SIBs),
one of which is referred to as the Master Information Block (MIB). Therefore, a system
information broadcast is classified into an MIB and several SIBs.
Figure 2.1-9 System Information Broadcast Structure
17
The scheduling periodicity of the MIB is 40 ms, and repetitions are transmitted in other
frames. In time-domain scheduling, the MIB is transmitted in slot 1 of subframe #0. In frequency-
domain scheduling, the MIB occupies the middle 6 RBs.
The scheduling periodicity of the SIB1 is 80 ms, and repetitions are transmitted in frames for
which SFN mod 2=0. In time-domain scheduling, the SIB1 is sent in subframe #5.
Figure 2.1-10 MIB and SIB1 Scheduling
The other SIBs (except the MIB and SIB1) before being sent should be mapped to serveral
SI. A System Information (SI) can be regarded as a group consisting of multiple SIBs. These
SIBs are mapped onto the same SI, which can be scheduled in a unified mode. The scheduling
periodicity of an SI is configurable, and Tn = 2^n*4. Therefore, the scheduling of an SIBn
message is as follows:
SIB1 80ms
SIB2 160ms
SIB3 320ms
SIB4/5 640ms
SIB6/7/8 1280ms
SIBn
Figure 2.1-11 SIBn Scheduling
The signaling of a front-end typical broadcast message is as follows:
18
Figure 2.1-12 Signaling of a Front-End Typical Broadcast
The above figure shows the signaling procedure of a UE receiving a broadcast after hangup.
First, the UE reads the MIB for the most basic information about a cell, including system
bandwidth, phich-Config, and System Frame Number. By using such information, the UE further
obtains other system information.
Secondly, the UE reads the System Information (SI) message for public configuration
information about radio resources, such as channel configuration information, and related timers
and counters at the UE side.
At last, the UE reads the SIBs for information such as PLMN identity, cell selection, and
reselection.
二.1.1 Master Information Block
Figure 2.1-13 MIB Structure
Masterinformationblok: basic information of a cell.
19
DL_Bandwidth: system bandwidth, enumerated type, options: (1.4M(6RB), 3M(15RB),

5M(25RB), 10M(50RB), 15M(75RB), and 20M(100RB)), which respectively correspond to values
0 to 5. If dl_Bandwidth is 3, the corresponding system bandwidth is 10 M (50 RB).
Phich_Duration: symbol length of the PHICH, enumerated type, options: normal and
extended, which respectively correspond to values 0 and 1.
SystemFrameNumber: System Frame Number.
二.1.2 System Information
A System Information message contains barring parameters related to cell selection and
access, common radio resource parameters, configuration information related to physical
channels and uplink power control, and timers and counters at the UE side.
20
Figure 2.1-14 System Information Structure
 Barring parameters related to cell selection and access
The barring parameters are used to identify signaling and data. For a description of the
parameters, refer to the following table.
Field Display Range Memory Range Meaning
Enumerated type, options: (0, Signaling
0.05, 0.1, 0.15, 0.2, 0.25, 0.3, 0.4, access
Ac_BarringFactor 0-15
0.5, 0.6, 0.7, 0.75, 0.8, 0.85, 0.9, probability
0.95). factor
21
Enumerated type, options: (4, 8, Signaling

Ac_BarringTime 16, 32, 64, 128, 256, 512) 0-7 access
seconds. restriction time
 RadioResourceConfigCommon parameters
For a description of the parameters, refer to the following table.

Memory
Field Display Range Meaning
Range
Enumerated type, options: (4, 8, 12,
NumberOfRA Number of non-dedicated
16, 20, 24, 28, 32, 36, 40, 44, 48, 0-15
_preambles random access preambles
52, 56, 60, 64).
SizeOfRA_pre Enumerated type, options: (4, 8, 12,
Number of preambles in
amblesGroup 16, 20, 24, 28, 32, 36, 40, 44, 48, 0-14
Group A
A 52, 56, 60).
powerRampin Enumerated type, options: (0, 2, 4, Power ramping step of the
0-3
gstep 6) dB PRACH
Maximum number of
preambleTran Enumerated type, options: (3, 4, 5,
0-10 preamble retransmissions
sMax 6, 7, 8, 10, 20, 50, 100, 200).
on the PRACH
Enumerated type, options: (-120, -
preambleInitia Target power of the initial
118, -116, -114, -112, -110, -108, -
lreceivedTarg 0-15 preamble received on the
106, -104, -102, -100, -98, -96, -94, -
etPower PRACH
92, -90) dBm
Threshold for power control
MessagePow Enumerated type, options:
configured for the eNodeB
erOffsetGroup (minusinfinity, 0, 5, 8, 10, 12, 15, 18) 0-7
during Message3
B dB
transmission
RA_Rsponse Enumerated type, options: (2, 3, 4, Duration of the RA
0-7
WinSize 5, 6, 7, 8, 10) ms response window
MAC_Connec
Enumerated type, options: (8, 16, Timer for MAC contention
tionResolution 0-7
24, 32, 40, 48, 56, 64) sf resolution
Timer
MaxHARQ_M Maximum number of
1-8 1-8
sg3Tx Message3 transmissions
 BCCH configuration information
The BCCH configuration information in the System Information contains a parameter

named BCCH modification periodCoeff, indicating the multiple of the BCCH update period.
The parameter is an enumerated type parameter with options (2, 4, 8, 16), which
respectively correspond to values 0 to 3.
 PCCH configuration information
The defaulpagingCycle parameter in the PCCH configuration information notifies the UE

of the cycle for listening to uncontinuous paging occasions. This parameter is an enumerated
22
type parameter with options (32, 64, 128, 256) RFs, which respectively correspond to values
0 to 3.
 NB configuration information
An NB is a factor for adjusting the paging time. It is an enumerated type parameter with
options (4T, 2T, T, 1/2T, 1/4T, 1/8T, 1/16T, 1/32T), which respectively correspond to values 0
to 7.
 PRACH configuration information
The PRACH configuration information provides the UE with information such as the root
sequence index for the 64 preamble sequences generated on the PRACH, configuration
index for random access preambles, and the start RB number of random access preambles.
23
 PDSCH configuration information
Referencesignalpower: reference signal power for a single RE (absolute value), D =

(P+60)*10, range: (-60…50), step: 0.1, unit: dBm. In the above figure, value 6 indicates that
the actual power is 6/10-60=-59.4dBm.
P_B: ratio of the EPRE of PDSCH with cell RS to the EPRE of PDSCH without cell RS,
enumerated type, range: (0, 1, 2, 3).
 PUSCH configuration information
N_SB: number of subbands to be allocated in case of PUSCH hopping, range: 0-4.

24
hoppingMode: PUSCH hopping mode, enumerated type, options: (Only inter-subframe,

both intra and inter-subframe), which respectively correspond to value 0 and 1.
hoppingOffset: PUSCH hopping offset, range: 0-98.
 PUCCH configuration information
DeltaPUCCH_Shift: cycle shift of PUCCH format 1/1a/1b in the cell, enumerated type,
options: (1, 2, 3), which respectively correspond to values 0 to 2.
nRB_CQI: number of RBs used by PUCCH format 2/2a/2b, range: 0-98.
nCS_AN: number of cycle shifts in a resource block shared by PUCCH format1/1a/1b

and 2/2a/2b.
n1PUCCH_AN: number of semi-static channels of PUCCH format 1, range: 0-2047.
 Uplink power control configuration information
P0_nominalPUSCH: nominal receiving power of the PUSCH, which is usually set to an

absolute value as required, for example, -81 dBm in the above figure.
PoNominalPucch: nominal receiving power of the PUCCH, which is usually set to an

absolute value as required, for example, -105 dBm in the above figure.
 Timers and counters at the UE side
T300: waiting time of the UE for an RRC connection response, enumerated type,
options: (100, 200,300, 400, 600, 1000, 1500, 2000) ms, which respectively correspond to
values 0 to 7.
T301: waiting time of the UE for an RRC connection reestablishment response,

enumerated type, options: (100, 200,300, 400, 600, 1000, 1500, 2000) ms, which
T310: waiting time of the UE for a radio link failure, enumerated type, options: (1, 2, 3, 4,
6, 8, 10, 20), which respectively correspond to values 0 to 7.
N310: maximum number of downlink out of syncronization indicators that the UE can
receive, enumerated type, options: (0, 50, 100, 200, 500, 1000, 2000) ms, which respectively
correspond to values 0 to 6.
T311: waiting time of the UE to enter IDLE state after detecting a radio link failure,
enumerated type, options: (1000, 3000, 5000, 10000, 15000, 20000, 30000) ms, which
25
N311: maximum number of downlink syncronization indicators that the UE can receive,
enumerated type, options: (1, 2, 3, 4, 5, 6, 8, 10), which respectively correspond to values 0
to 7.
TimeAlignmentTimer: waiting time of the UE for time alignment, enumerated type,

options: (500, 750, 1280, 1920, 2560, 5120, 10240, infinity) sfs, which respectively
correspond to values 0 to 7.
二.1.3 System Information Block Type1
The SIB1 carries information such as PLMN identity, cell on which the UE camps, cell
barred, and cell reselection.
MCC: mobile country code of the neighboring cell.
MNC: mobile network code of the neighboring cell.
CellIdentity: ID of the cell.
Cellbarred: whether the cell is barred for access, enumerated type, options: (Barred, Not
Barred), which respectively correspond to 0 and 1.
IntraFreqReseletion: whether intra-frequency cell reselection is allowed, enumerated

type, options: (allowed, notAllowed), which respectively correspond to 0 and 1.
q_RxlevMin: minimum receiving level required for eUTRAN cell selection, options: (-
140..-44) dBm, which respectively correspond to values 0 to 48, step: 2 dBm, calculation
formula: D = (P+140)/2.
26
q_RxlevMinOffset: minimum level offset required for cell selection, range: 2-16 dB,
which respectively correspond to values 1 to 8, step: 2 dB, calculation formula: D = P/2.
P_Max: maximum transmission power allowed by the UE, which is usually set to 23
dBm.
freqbandIndicator: indicator of the frequency band where the carrier frequency is in.
二.2 RRC Signaling Analysis
二.2.1 RRC Connection Establishment Procedure
 Trigger:
 When trying to enter CONNECTED state from IDLE state, the UE initiates this
procedure to establish the SRB1. For example, before making a call, and
responding to a Paging, TAU, or Attach request, the UE must transit from IDLE
state to CONNECTED state.
 RRC Connection Establishment Successful
 RRC Connection Request: This message is sent by the UE using SRB0 on the
UL_CCCH. It contains an initial (NAS) identity of the UE and an establishment
cause, and corresponds to the Msg3 message in the random access procedure.
 RRC Connection Setup: This message is sent by the eNB using SRB0 on the
DL_CCCH. It contains complete configuration information of SRB1, and
corresponds to the Msg4 message in the random access procedure.
 RRC Connection Setup Complete: This message is sent by the UE using SRB1
on the UL_DCCH. It contains NAS messages in the uplink direction, such as
Attach Request, TAU Request, Service Request, and Detach Request. The eNB
sets up the S1 interface based on these messages.
 RRC Connection Establishment Failed
 If the eNB rejects to establish an RRC connection for the UE, the eNB returns an
RRC Connection Reject message on the DL_CCCH.
27
Figure 2.2-15 System Information Broadcast Structure
二.2.1.1 RRC Connection Request
The following figure shows the structure of an RRC Connection Request message.
The RRC Connection Request message contains two parameters: ue_Identity and
establishmentCause.
28
>ue_Identity has two types: s-TMSI and randomValue. If a valid s-TMSI exists at the UE
side, the s-TMSI is used. Otherwise, a randomValue is used.
>establishmentCause has the following options: emergency (emergency call),

highPriorityAccess (access request of high priority), mt-Access (receiving an RRC establishment
request while receiving a paging message), mo-Signaling (RRC establishment request initiated
due to TAU), and mo-Data (data service request initiated by the terminal).
二.2.1.2 RRC Connection Setup
The following figure shows the structure of an RRC Connection Setup message.
>rrc_TransactionIdentifier: RRC signaling identifier, indicating an RRC signaling transaction

process, range: 0-3. The eNodeB sets this parameter to a value when sending an RRC request,
and the value is the same as that of the rrc_TransactionIdentifier parameter in the RRC response
returned by the UE.
>radioResourceConfigDedicated: dedicated resources configured for SRB1 setup.
>>srb_ToAddModList: The RRC Connection Setup message is used to set up the SRB1.
Therefore, this message should contain srb_ToAddModList, and srb_ToAddModListPresent is 1.
29
>>>srb_Identity in srb_ToAddModList is set to either of the two values: 1 and 2, in which 1

indicates that the configured SRB is SRB1, and 2 indicates SRB2.
>>>rlc_Config: configuration of RLC layer-related parameters.
The RLC configuration supports two modes: explicit configuration and default configuration.
>>>>t=1 explicitValue: indicates explicity RLC configuration.
The protocol specifies that the RLC_MODE of SRB1 and SRB2 must be AM mode.
>>>>>ul_AM_RLC: uplink RCL AM mode configuration.
>>>>>>t-PollRetransmit: RLC AM timer, unit: miliseconds, used by the transmission part of

the AM RLC entity, options: {ms5, ms10, ms15, ms20, ms25, ms30, ms35, ms40, ms45, ms50,
ms55, ms60, ms65, ms70, ms75, ms80, ms85, ms90, ms95, ms100, ms105, ms110, ms115,
ms120, ms125, ms130, ms135, ms140, ms145, ms150, ms155, ms160, ms165, ms170, ms175,
30
ms240, ms245, ms250, ms300, ms350, ms400, ms450, ms500, spare9, spare8, spare7, spare6,
spare5, spare4, spare3, spare2, spare1}, in which the value ms5 indicates 5 ms, and ms10
indicates 10 ms, and so on.
>>>>>>pollPDU: RLC AM parameter used by the transmission part of every AM RLC entity
to trigger the polling for PDUs. The value p4 indicates 4 PDUs, p8 indicates 8 PDUs, and pInfinity
corresponds to an infinite amount of PDUs. Discrete values {p4, p8, p16, p32, p64, p128, p256,
pInfinity} are used.
>>>>>>pollByte: RLC AM parameter used by the transmission part of every AM RLC entity to
trigger the polling for bytes. The value kB25 corresponds to 25 kBytes, kB50 corresponds to 50
kBytes, and kBInfinity corresponds to an infinite amount of kBytes. Discrete values {kB25, kB50,
kB75, kB100, kB125, kB250, kB375, kB500, kB750, kB1000, kB1250, kB1500, kB2000, kB3000,
kBinfinity, spare1} are used.
>>>>>>maxRetxThreshold: RLC AM parameter used by the transmission part of every AM

RLC entity to restrict the number of AMD PDU retransmissions. The value t1 corresponds to 1
retransmission, and t2 corresponds to 2 retransmissions, and so on. Discrete values {t1, t2, t3, t4,
t6, t8, t16, t32} are used.
>>>>>dl_AM_RLC: downlink RLC AM mode configuration.
>>>>>>t-Reordering: timer for reordering, unit: miliseconds, options: {ms0, ms5, ms10,
ms15, ms20, ms25, ms30, ms35, ms40, ms45, ms50, ms55, ms60, ms65, ms70, ms75, ms80,
ms190, ms200, spare1}. The value ms0 indicates 0 ms, and ms5 indicates 5 ms, and so on. This
timer is used by the reception part of the AM RLC entity and the UM RLC reception entity to
check whether there is any loss of RLC PDUs at the lower layer. If a t_Reordering is running,
another t_Reordering should not be started, meaning that every RLC entity should have only one
running t_Reordering timer.
>>>>>>StatusProhibit: timer for status report, unit: miliseconds, options: {ms0, ms5, ms10,
ms15, ms20, ms25, ms30, ms35, ms40, ms45, ms50, ms55, ms60, ms65, ms70, ms75, ms80,
ms400, ms450, ms500, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1}. The
value ms0 indicates 0 ms, and ms5 indicates 5 ms, and so on. This timer is used by the reception
part of the AM RLC entity to restrict the sending of STATUS PDUs.
31
>>>>t=2 defaultValue: indicates default RLC configuration.
>>>logicalChannelConfig: logical channel priority configuration.
The logical channel configuration supports two modes: explicit configuration and default
configuration.
>>>>t=1 explicitValue indicates explicit configuration, including the following information

elements:
>>>>>priority: priority of the logical channel, integer type, range: 1-16. The higher the value,
the lower the priority.
>>>>>prioritisedBitRate: Prioritized Bit Rate for logical channel prioritization, unit: kB/second,
options: {kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, infinity, spare8, spare7,
spare6, spare5, spare4, spare3, spare2, spare1}. The value kBps0 corresponds to 0 kB/second,
kBps8 corresponds to 8 kB/second, and kBps16 corresponds to 16 kB/second, and so on, and
infinity is applicable only to SRB1 and SRB2. Discrete values are used.
>>>>>bucketSizeDuration: Bucket Size Duration for logical channel prioritization, unit:

milliseconds, options: {ms50, ms100, ms150, ms300, ms500, ms1000, spare2, spare1}. The
value ms50 corresponds to 50 ms, and ms100 corresponds to 100 ms, and so on.
>>>>>logicalChannelGroup: integer type, range: 0-3. This IE affects buffer status report
handling.
>>>>t=2 indicates defaultValue (set to the default logical channel configuration for SRB1 as
specified in 9.2.1.1 or for SRB2 as specified in 9.2.1.2 TS36.331).
>>>mac_MainConfig MAC parameter configuration
32
mac_MainConfig supports two configuration modes: t=1 explicit configuration, and t=2
default configuration.
>>>>t=2 indicates defaultValue.
>>>>t=1 indicates explicitValue.
>>>>>ul_SCH_Config: uplink SCH configuration.
>>>>>>maxHARQ_Tx: maximum number of UL HARQs that can be transmitted, options:

{ n1, n2, n3, n4, n5, n6, n7, n8, n10, n12, n16, n20, n24, n28, spare2, spare1}, in which n1
indicates that there is one HARQ process.
>>>>>>periodicBSR_Timer: BSR timer, options: {sf5, sf10, sf16, sf20, sf32, sf40, sf64, sf80,
sf128, sf160, sf320, sf640, sf1280, sf2560, infinity, spare1}. (This value can use the number of
subframes, for example, value sf10 corresponds to 10 subframes, and sf20 corresponds to 20
subframes, and so on).
33
>>>>>>retxBSR_Timer: options: {sf320, sf640, sf1280, sf2560, sf5120, sf10240, spare2,

spare1}. (The value sf640 corresponds to 640 subframes, and sf1280 corresponds to 1280
subframes, and so on).
>>>>>>ttiBandling: TURE indicates that the TTI binding is valid, while FALSE indicates that
the TTI binding is invalid. TTI binding is valid for FDD, and valid for TDD only when the
configuration is 0, 1, or 6.
>>>>>timeAlignmentTimerDedicated: used to control the time length for uplink clock

synchronization at the UE side, options: {sf500, sf750, sf1280, sf1920, sf2560, sf5120, sf10240,
infinity}. This parameter value uses the number of subframes. The value sf500 corresponds to
500 subframes, and sf750 corresponds to 750 subframes, and so on.
>>>>>phr_Config
phr_Config supports two configuration modes: t=1 indicating the release of phr_Config, and
t=2 indicating the setting of phr_Config.
>>>>>>t=1 indicates to release previous PHR configuration.
>>>>>>t=2 indicates to configure PHR
>>>>>>>periodicPHR-Timer: PHR reporting timer, options: {sf10, sf20, sf50, sf100, sf200,
sf500, sf1000, infinity}. The parameter value uses the number of subframes. The value sf10
corresponds to 10 subframes, and sf20 corresponds to 20 subframes, and so on.
>>>>>>>prohibitPHR-Timer: PHR reporting timer, options: {sf0, sf10, sf20, sf50, sf100,
sf200, sf500, sf1000}. The parameter value uses the number of subframes. The value sf0
corresponds to 0 subframe, and sf100 corresponds to 100 subframes, and so on.
>>>>>>>dl-PathlossChange: downlink path loss change of PHR reporting, unit: dB, options:
{dB1, dB3, dB6, infinity}. The value dB1 corresponds to 1 dB, and dB3 corresponds to 3 dBs, and
so on.
>>>>>DRX-Config
DRX-Config supports two configuration modes: t=1 indicating the release of DRX_Config,
and t=2 indicating the setting of DRX_Config.
>>>>>>onDurationTimer: number of continuous PDCCH/downlink subframes since the DRX,

options: {psf1, psf2, psf3, psf4, psf5, psf6, psf8, psf10, psf20, psf30, psf40, psf50, psf60, psf80,
psf100, psf200}, in which psf indicates PDCCH subframe, meaning downlink subframes. If the UE
successfully decodes a PDCCH, the UE keeps awakened and starts the inactivity timer.
34
>>>>>>drx-InactivityTimer: number of continuous PDCCH subframes after specifying the

PDCCH for initial UL/DL user data transmission, options: {psf1, psf2, psf3, psf4, psf5, psf6, psf8,
psf10, psf20, psf30, psf40,psf50, psf60, psf80, psf100, psf200, psf300, psf500, psf750, psf1280,
psf1920, psf2560}.
>>>>>>drx-RetransmissionTimer: DRX retransmission timer, which defines the maximum

number of continuous PDCCH subframes since the UE starts DL retransmission, options: {psf1,
psf2, psf4, psf6, psf8, psf16, psf24, psf33}.
>>>>>>longDRX-Cycle and StartOffset: value range: {sf10,(0-9); sf20,(0-19); sf32,(0-31);

sf40,(0-39); sf64,(0-63); sf80,(0-79); sf128,(0-127); sf160,(0-59); sf256,(0-255); sf320,(0-319);
sf512,(0-511); sf640,(0-639); sf1024,(0-1023); sf1280,(0-1279); sf2048,(0-2047); sf2560,(0-
2559)}, in which sf indicates subframe, sf10 indicates 10 subframes, and the corresponding (0-9)
indicates the possible value of StartOffset.
>>>>>>shortDRX-Cycle: value range: {sf2, sf5, sf8, sf10, sf16, sf20, sf32, sf40, sf64, sf80,
sf128, sf160, sf256, sf320, sf512, sf640}.
>>>>>>drxShortCycleTimer: integer type, range: (1..16).
>>>physicalConfigDedicated: dedicated physical configuration.
physicalConfigDedicated includes the following subconfiguration: pdsch, pucch, pusch,

uplinkPowerControlDedicated, tpc_PDCCH_ConfigPUCCH, tpc_PDCCH_ConfigPUSCH,
cqi_ReportConfig, soundingRS_UL_ConfigDedicated, antennaInfo, and
schedulingRequestConfig.
35
>>>>pdsch_ConfigDedicated
>>>>>p_a: range: {dB-6, dB-4dot77, dB-3, dB-1dot77, dB0, dB1, dB2, dB3}, in which the
value dB-6 indicates -6 dB, and dB-4dot77 corresponds to -4dot77 dB, and so on.
>>>>pucch_ConfigDedicated
>>>>>ackNackRepetition
This parameter indicates the configuration of ACK/NACK repetition, which supporting two
modes: t=1 indicating the cancellation of this configuration item, and t=2 indicating the
configuration of this item.
>>>>>>repetitionFactor: range: {n2, n4, n6, spare1}, in which the value n2 corresponds to 2
repetition factors, and n4 corresponds to 4 repetition factors, and so on.
(1)
nPUCCH, ANRep
>>>>>>n1PUCCH-AN-Rep parameter: For details about , refer to the TS 36.213
[23, 10.1].
>>>>>tddAckNackFeedbackMode: TDD ACK/NACK feedback mode used. For details, refer

to the TS 36.213 [23, 7.3]. The value bunding corresponds to ACK/NACK binding, and
multiplexing corresponds to ACK/NACK multiplexing. On the PUCCH and PUSCH, two
ACK/NACK feedback modes can use the same value. For TDD 5, the E-UTRAN always sets this
domain to bunding.
>>>>pusch_ConfigDedicated
36
HARQ− ACK
I
>>>>>betaOffset-ACK-Index: integer type, range: (0-15). For details about offset , refer to
the TS 36.213 [Table 8.6.3-1].
RI
I
>>>>>betaOffset-RI-Index: For details about offset , refer to the TS 36.213 [Table 8.6.3-2].
CQI
I
>>>>>betaOffset-CQI-Index: For details about offset , refer to the TS 36.213 [Table 8.6.3-3].
>>>>uplinkPowerControlDedicated
P
>>>>>p0-UE-PUSCH: integer type, unit: dB, range: (-8...7). For details about O_UE_PUSCH
(1) ,
refer to the TS 36.213 [23.5.1.1.1]. This domain is only applicable to non-continuous scheduling.
>>>>>deltaMCS-Enabled: options: {en0, en1}. For details about the parameter Ks, refer to
the TS 36.213, [23, 5.1.1.1]. en0 corresponds to value 0, indicating the "Disabled" state. en1
corresponds to value 1.25, indicating the "Enabled" state.
>>>>>accumulationEnabled: BOOLEAN type. For details about the parameter Accumulation-

enabled, refer to the TS 36.213 [23, 5.1.1.1]. TRUE corresponds to "Enabled", and FALSE
corresponds to "Disabled".
P
>>>>>p0-uE-PUCCH: integer type, range: (-8...7), unit: dB. For details about O_UE_PUCCH ,
refer to the TS 36.213 [23.5.1.2.1].
>>>>>pSRS_Offset: integer type, range: (0...15). For details about the parameter
pSRS_Offset, refer to the TS 36.213 [23.5.1.3.1]. When Ks=1.25, the value of this parameter is
pSRS-Offset value – 3. When Ks=0, the value of this parameter is -10.5 + 1.5*pSRS-Offset.
>>>>>filterCoefficient: RSRP measurement filter coefficient for calculating path loss, as

described in the TS 36.213 [23.5.1.1.1]. The same filtering mechanism is used as quantityConfig,
which is described in 5.5.3.2.
>>>>tpc_PDCCH_ConfigPUCCH
37
tpc_PDCCH_ConfigPUCCH supports two configuration modes: t=1 indicating the release of

this configuration item, and t=2 indicating the setting of this item.
>>>>>tpc_RNTI is 16 bits, indicating the RNTI using DCI format 3/3A for power control.
>>>>tpc_Index
>>>>>indexOfFormat3: integer type, range: (1...15), indicating the index of N when DCI
format 3 is used.
>>>>>indexOfFormat3A: integer type, range: (1...31), indicating that the index of M when
DCI format 3 is used.
>>>>tpc_PDCCH_ConfigPUSCH uses the same configuration mode as

tpc_PDDCH_ConfigPUCCH does.
>>>>cqi_ReportConfig
>>>>>cqi_ReportModeAperiodic: options: {rm12, rm20, rm22, rm30, rm31, spare3, spare2,

spare1}, parameter: report mode. The value rm12 corresponds to mode 1-2, and rm20
corresponds to mode 2-0, rm22 corresponds to mode 2-2, and so on. The PUSCH report mode is
described in the TS 36.213 [23.7.2.1].
38
Δ
>>>>>nomPDSCH-RS-EPRE-Offset: integer type, range: (-1...6). For details about offset ,
refer to the TS 36.213 [23.7.2.3]. The actual value = IE value * 2 [dB].
>>>>>cqi_ReportPeriodic
cqi_ReportPeriodic has two configuration modes: t=1 indicating the release of this
configuration item, and t=2 indicating the setting of this item.
>>>>>>cqi_PUCCH-ResourceIndex: integer type, range: (0...1185). For details about

( 2)
parametern PUCCH , refer to the TS 36.213 [23.7.2].
>>>>>>cqi-pmi-ConfigIndex, integer type, range: (0...1023). For details about CQI/PMI

period and offset configuration sequence number, refer to the TS 36.213 [23 tables 7.2.2-1A and
7.2.2-1C].
>>>>>>cqi-FormatIndicatorPeriodic is not supported by some widebandCQI. The value of

the k parameter of subbandCQI is an integer ranging from 1 to 4. For details about the k
parameter, refer to the TS 36.213 [23.7.2.2].
>>>>>>ri-ConfigIndex: integer type, range: (0...1023). For details about the configuration
index of RI, refer to the TS 36.213 [23.7.2.2-1B].
>>>>>>simultaneousAckNackAndCQI: BOOLEAN type. For details about the parameter

Simultaneous-AN-and-CQI, refer to the TS 36.213 [23.10.1]. TRUE indicates that ACK/NACK and
CQI are allowed to be transmitted at the same time.
>>>>soundingRS_UL_ConfigDedicated
Two configuration modes are supported: t=1 indicating the release of this configuration item,
and t=2 indicating the setting of this item.
>>>>>srs-Bandwidth: SRS bandwidth configuration, options: {bw0, bw1, bw2, bw3}. For
details, refer to the TS 36.211 [21, tables 5.5.3.2-1, 5.5.3.2-2, 5.5.3.2-3 and 5.5.3.2-4]. The actual
configuration is subject to the uplink bandwidth. bw0 corresponds to 0, and bw1 corresponds to 1,
and so on.
b ∈{0,1,2,3} , options: {hbw0,
>>>>>srs-HoppingBandwidth: SRS hopping bandwidth hop
hbw1, hbw2, hbw3}, in which hbw0 corresponds to value 0, and hbw1 corresponds to value 1,
and so on. For details, refer to the TS 36.211 [21.5.5.3.2].
>>>>>freqDomainPosition: integer type, range: (0...23). For details about

n RRC , refer to the
TS 36.211 [21.5.5.3.2].
39
>>>>>duration: For details about the parameter Duration, refer to the TS 36.213, 8.2. FALSE
corresponds to "single", and TRUE corresponds to "indefinite".
>>>>>srs-ConfigIndex: integer type, range: (0...1023). For details about the parameter ISRS,
refer to the TS 36.213 [23, table 8.2-1].
k ∈ {0 , 1}, refer to
>>>>>transmissionComb: integer type, range: (0...1). For details about TC
the TS 36.211 [21, 5.5.3.2].
>>>>>cyclicShift: options: {cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7}, in which cs0 corresponds
to value 0. For details about the parameter n_SRS, refer to the TS 36.211, 5.5.3.1.
>>>>antennaInfo
Two configuration modes are supported: t=1 indicating explicit configuration and t=2
indicating default configuration.
>>>>>t=1
>>>>>>transmissionMode: transmission mode defined in the TS 36.213[23, 7.1], options:

{tm1, tm2, tm3, tm4, tm5, tm6, tm7, spare1}, in which tm1 corresponds to transmission mode 1,
and tm2 corresponds to transmission mode 2, and so on.
>>>>>>codebookSubsetRestriction: indicates that transmissionMode is set to tm3, tm4, tm5,

or tm6.
>>>>>>ue-TransmitAntennaSelection
Two configuration modes are supported: t=1 indicating the release of the configuration item,
>>>>>t=2 indicates the use of default value.
>>>>schedulingRequestConfig
Two configuration modes are supported: t=1 indicating the release of the configuration item,
( 1)
n
>>>>>sr-PUCCH-ResourceIndex: integer type, range: (0...2047). For details about PUCCH,SRI ,
refer to the TS 36.213 [23, 10.1].
>>>>>sr-ConfigIndex: integer type, range: (0...157).
40
>>>>>dsr-TransMax: SR transmission parameter, options: {n4, n8, n16, n32, n64, spare3,
spare2, spare1}, in which n4 corresponds to 4 transmissions, and n8 corresponds to 8
transmissions, and so on.
二.2.1.3 RRC Connection Setup Complete
>rrc_TransactionIdentifier: The value of rrc_TransactionIdentifier contained in the RRC

Connection Setup Complete message should be the same as that of rrc_TransactionIdentifier in
the RRC Connection Setup message. For the meaning of the information element, refer to the
RRC Connection Setup section.
>SelectedPLMN_Identity: index of plmn-IdentityList in SIB1. If SelectedPLMN_Identity is 1, it

is the first in the plmn-IdentityList of the SIB1.
>registerMME: MME that the UE already registers to.
>dedicatedInfoNAS: carries NAS messages, including ATTACH REQUEST, TAU REQUEST,

and SERVICE REQUEST.
二.2.2 RRC Connection Reestablishment Procedure
 Trigger:
 This procedure is trigged when a handover failure, radio link failure, integrity
protection failure, or RRC reconfiguration failure occurs.
 RRC Connection Reestablishment Successful
 RRC Connection Reestablishment Request: This message is sent by the UE

using SRB0 on the UL_CCCH. It contains the AS-layer initial identity information
41
of the UE and a reestablishment cause, and corresponds to the Msg3 message in

the random access procedure.
 RRC Connection Reestablishment: This message is sent by the eNB using SRB0
on the DL_CCCH. It contains complete configuration of SRB1, and corresponds
to the Msg4 message in the random access procedure.
 RRC Connection Reestablishment Complete: This message is sent by the UE

using SRB1 on the UL_DCCH. It does not contain any actual information, and
only serves as an RRC layer confirmation.
 RRC Connection Reestablishment Failed
 If the eNB rejects to reestablish an RRC connection because it does not have any
context information of the UE, the eNB returns an RRC Connection
Reestablishment Reject message by using SRB0 on the DL_CCCH.
Figure 2.2-16 RRC Connection Reestablishment Procedure
二.2.2.1 RRC Connection Reestablishment Request
The following figure shows the structure of an RRC Connection Reestablishment Request
message.
42
An RRC Connection Reestablishment Request message contains a ReestabUe_Identity and

a ReestablishmentCause.
The ReestabUe_Identity contains a C-RNTI, a PCI, and a ShortMAC-I.
The ReestablishmentCause can be set to any of the following cause values:
 reconfigurationFailure
 handoverFailure
 otherFailure
二.2.2.2 RRC Connection Reestablishment
The following figure shows the structure of an RRC Connection Reestablishment message.
Similar to an RRC Connection Setup message, an RRC Connection Restablishment

message contains an rrc_TransactionIdentifier, radioResourceConfigDedicated, and
nextHopChainingCount for updating KeNB key.
43
二.2.2.3 RRC Connection Reestablishment Complete
The following figure shows the structure of an RRC Connection Reestablishment Complete
message.
二.2.3 RRC Connection Release Procedure
 Trigger:
 This procedure is triggered when the network wants to release an RRC

connection to a UE.
 RRC Connection Release
44
 RRC Connection Release: This message is sent by the eNB using SRB1 on the
DL_DCCH. It can choose to carry the redirection information and dedicated
priority allocation information (to be used for the control of the UE's cell selection
and reselection).
 In some situations, the RRC layer of the UE releases an RRC connection based
on the NAS layer indication, for example, not pass the the NAS layer
authentication, and enters IDLE state without notifying the network side.
The following figure shows the structure of an RRC Connection Release message.
45
 RedirectedCarrierInfo contains the frequency information for redirection to the E-UTRAN,

UTRA-FDD, UTRA-TDD, and CDMA, and the frequency group information for redirection
to the GSM.
 idleModeMobilityControlInfo contains the frequency priority information for cell

reselection. The frequency priority information in the message is valid till the timeout of
T320.
 releaseCause contains a release cause, which may be loadBalancingTAUrequired or

other.
二.2.4 RRC Connection Reconfiguration Procedure
 Trigger:
 This procedure is triggered when SRB and DRB management, lower-layer

parameter configuration, handover, or measurement control is needed.
 RRC Connection Reconfiguration
 RRC Connection Reconfiguration: This message is sent by the eNB using SRB1
on the DL_DCCH. The configuration information contained in this message varies
with the actual function needed. One message can contain IEs for multiple
functions.
 RRC Connectin Reconfiguration Complete: This message is sent by the UE using

SRB1 on the UL_DCCH. It does not contain any actual information, and only
serves as an RRC-layer confirmation.
 RRC Connection Reconfiguration Abnormal
 If the UE cannot perform the contents in the RRC Connection Reconfiguration

message, the UE rolls back to the configuration before receiving this message
and initiates an RRC connection reestablishment procedure.
46
Figure 2.2-17 RRC Connection Reconfiguration Procedure
Compared to the signaling in a 3G system, the LTE system simplifies the RRC layer
signaling and the RRC connection reconfiguration function is enhanced.
The RRC Connection Reconfiguration signaling is analyzed as follows:
47
The RRC connection reconfiguration has the following configuration items: measConfig
indicating measurement-related configuration, mobilityControlInfo indicating mobility control-
related configuration, NAS message contained in dedicatedInfoNASList,
radioResourceConfigDedicated indicating dedicated radio resource configuration, and security
parameters configured during securityConfigHO handover (intra-E-UTRAN handover or inter-E-
UTRAN handover) procedure.
>rrc_TransactionIdentifier: For the meaning of the value, refer to the RRC Connection Setup
section. The value of rrc_TransactionIdentifie in the RRC Connection Reconfiguration
Complete message returned by the UE after receiving the RRC Connection Reconfiguration
message should be the same as this value.
>measConfig
>>measObjectToRemoveList: measId value list, in which the maximum value is 32.
48
>>measObjectToAddModList: list of measurement objects to be added or modified.
>>>measObjectId: selects one from the measObject field:
>>>>measObjectEUTRA
>>>>>carrierFreq: identifies a valid E_UTRA carrier frequency.
>>>>>allowedMeasBandwidth: maximum measurement bandwidth allowed on the carrier

frequency defined in TS 36.104 [47], options: mbw6, mbw15, mbw25, mbw50, mbw75, and
mbw100, which respectively indicate 6, 15, 25, 50, 75, and 100 resource blocks.
>>>>>presenceAntennaPort1: whether all neighboring cells use Antenna port 1. If this IE is

set to TRUE, the UE determines that at least two cell-specific antenna ports are used in all the
neighboring cells.
>>>>>neighCellConfig: provides MBSFN and UL/DL configuration information of the

neighboring cell. The hexadecimal numbers should be converted into binary numbers for
description. The value 2 in the above figure equals to 10.
00: indicates that not all neighboring cells have the same MBSFN allocation as the serving
cell does.
49
10: indicates that the MBSFN allocation of all neighboring cells is the same as that of the
serving cell.
01: indicates that no MBSFN exists in any neighboring cell.
11: indicates that TDD UL/DL allocation of some neighboring cells is different from that of the
serving cell.
For TDD, 00, 10, and 01 are used in neighboring cells only for UL/DL allocation, the same as
they are in the serving cell.
>>>>>offsetFreq: offset applicable to the carrier frequency.
>>>>measObjectUTRA: describes neighboring cell information of the local cell and other
systems.
>>reportConfigToRemoveList: list of measurement report configuration items to be removed,

contents: measObjectId, maximum value: 32.
50
>>reportConfigToAddModList
>>>reportConfigId: identifies a measurement report configuration item.
>>>reportConfig
>>>>reportConfigEUTRA: standard for triggering an E-UTRA measurement report event. An

E-UTRA measurement report is marked as AN, in which N equals to 1, 2, and so on.
>>>>> eventId: ID of the E-UTRA event triggering a report.
>>>>>Threshold_RSRP: RSRP threshold for event evaluation.
>>>>triggerQuantity: quantity for event triggering conditions evaluation. The values rsrp and
rsrq respectively correspond to the Reference Signal Receiving Power (RSRP) and Reference
Signal Receiving Quality (RSRQ).
>>>>reportQuantity: quantity contained in a measurement report. A measurement report

contains both RSRP and RSRQ quantity.
>>>>maxReportCells: maximum number of cells that can be reported in a measurement

report.
>>>>reportInterval: interval between periodic reports. If the UE performs a periodic report

(meaning when reportAmount is greater than 1), the reportInterval is applicable to situations
when triggerType is 'event' or 'periodic'. The value ms120 corresponds to 120 ms, and ms240
corresponds to 240 ms, and so on. Meanwhile, the value min1 corresponds to 1 minute, and
min6 corresponds to 6 minutes, and so on.
>>>>reportAmount: number of measurement reports applicable to the situations when

triggerType is 'event' or 'periodic'. This value is set to 1 only when the application purpose is set
to reportCGI.
>>>>reportConfigInterRAT
51
>>measIdToRemoveList array 1-maxMeasId (maximum value being 32).
>>measIdToAddModList: list of measurement IDs to be added or modified, in which every

item contains measID, related measObjectId, and reportConfigId.
>>>measId: identifies a measurement configuration item, meaning the configuration of the

measurement target report and connection.
>>>measObjectId: identifies a measurement object configuration item.
>>>reportConfigId: identifies a measurement report configuration item.
>>quantityConfig
>>>quantityConfigEUTRA: filter configuration for E-UTRA measurement.
>>>>filterCoefficientRSRP: filter coefficient for RSRP.
>>>>filterCoefficientRSRQ: filter coefficient for RSRQ.
>>s-Measure: quality threshold of the serving cell, integer type, range: (0...97), in which
value "0" indicates an invalid s-Measure. This IE controls whether the UE performs intra-
frequency, inter-frequency, or inter-RAT neighboring cell measurement.
52
>>speedStatePars
>>>t=1 release
>>>t=2 setup
>>>>mobilityStateParameters include parameters determining UE mobility state.
>>>>>t-Evalulation: length of time that the UE needs before entering mobility state, options:
{s30, s60, s120, s180, s240, spare3, spare2, spare1}, unit: seconds, in which s30
corresponds to 30 seconds. This parameter corresponds to TCRmax in the TS36.304 [4].
>>>>>t-HystNormal: length of time that the UE needs before entering normal mobility state,
options: {s30, s60, s120, s180, s240, spare3, spare2, spare1}, unit: seconds, in which s30
corresponds to 30 seconds. This parameter corresponds to TCRmaxHyst in the TS 36.304 [4].
>>>>>n-CellChangeMedium: number of cells entering medium-speed mobility state, integer

type, range: (1...16). This parameter corresponds to NCR_M in the TS 36.304 [4].
>>>>>n-CellChangeHigh: number of cells entering high-speed mobility state, integer type,

range: (1...16). This parameter corresponds to NCR_H in the TS 36.304 [4].
>>>>timeToTrigger-SF: factor used when the UE is in medium or high-speed mobility state,

to represent mobility control-related parameter.
>>>>>sf-Medium: options: {oDot25, oDot5, oDot75, lDot0}, factor by which the mobility
control-related parameter is multiplied for handover control conditions when the UE is in
medium-speed mobility state.
>>>>>sf-High: options: {oDot25, oDot5, oDot75, lDot0}, factor by which the mobility control-
related parameter is multiplied for handover control conditions when the UE is in high-speed
mobility state.
>mobilityControlInfo: This configuration is used during handover, and is not included in

initalaccess.
53
>>targetPhysCellId: physical layer ID of the cell, integer type, range: (0...503).
>>carrierFreq contains two parameters.
>>>dl-CarrierFreq: downlink carrier frequency, integer type, range: (0...maxEARFCN).
>>>ul-CarrierFreq : uplink carrier frequency, integer type, range: (0...maxEARFCN). For TDD,
the uplink center frequency does not exist.
>>carrierBandwidth is classified into uplink bandwidth configuration and downlink bandwidth

configuration.
>>>dl-Bandwidth: downlink bandwidth, options: {n6, n15, n25, n50, n75, n100, spare10,
spare9, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1}. The value n6
corresponds to 6 RBs and bandwidth of 1.4 MHz, n15 to 3 MHz, n25 to 5 MHz, n50 to 10 MHz,
n75 to 15 MHz, and n100 to 20 MHz. The value spare* indicates spare bytes for further
development. For details about the Downlink bandwidth parameter, refer to the TS 36.101.
>>>ul-Bandwidth: uplink bandwidth, options: {n6, n15, n25, n50, n75, n100, spare10, spare9,
spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1}.
>>additionalSpectrumEmission: integer type, range: (1...32). For related UE requirements,

refer to the TS 36.101 [42, table 6.2.4-1].
54
>>t304: timer T304 described in Section 7.3, options: {ms50, ms100, ms150, ms200, ms500,
ms1000, ms2000, spare1}, in which the value ms50 corresponds to 50 ms, and ms100
corresponds to 100 ms and so on.
>>newUE-Identity: new UE identity and C-RNTI, identifying information of UEs with RRC
connections within the cell.
>>radioResourceConfigCommon
This parameter mainly sets basic information of target cells.
>>>rach-ConfigCommon
55
>>>>preambleInfo
>>>>>numberOfRA-Preambles: number of non-dedicated random access preambles in the

TS 36.321 [6], integer type, options: { n4, n8, n12, n16 ,n20, n24, n28, n32, n36, n40, n44, n48,
n52, n56, n60, n64}, in which the value n4 corresponds to 4, and n8 corresponds to 8, and so
on.
>>>>>preamblesGroupAConfig: configuration of the preambles group A specified in the TS

36.321 [6]. If this parameter is not set, the size of the random access preambles group A is the
same as numberOfRA-Preambles.
>>>>>>sizeOfRA-PreamblesGroupA: size of the random access preambles group A

specified in the TS 36.321 [6], integer type, options: {n4, n8, n12, n16 ,n20, n24, n28, n32,
n36, n40, n44, n48, n52, n56, n60}, in which n4 corresponds to 4, and n8 corresponds to 8,
and so on.
>>>>>>messageSizeGroupA: maximum message size of the preambles group A specified in

the TS 36.321 [6], unit: bits, options: {b56, b144, b208, b256}, in which b56 corresponds to
56 bits, and b144 corresponds to 144 bits, and so on.
>>>>>>messagePowerOffsetGroupB: options: {minusinfinity, dB0, dB5, dB8, dB10, dB12,

dB15, dB18}.
>>>>powerRampingParameters
56
>>>>powerRampingStep: power ramping factor specified in the TS 36.321 [6], unit: dBs,
options: {dB0, dB2, dB4, dB6}, in which dB0 corresponds to 0 dB, and dB2 corresponds to 2
dBs, and so on.
>>>>preambleInitialReceivedTargetPower: initial preamble power specified in the TS 36.321

[6], unit: dBm, options: {dBm-120, dBm-118, dBm-116, dBm-114, dBm-112, dBm-110, dBm-
108, dBm-106, dBm-104, dBm-102, dBm-100, dBm-98, dBm-96, dBm-94, dBm-92, dBm-90}, in
which the value dBm-120 corresponds to -120 dBm, and dBm-118 corresponds to -118 dBm,
and so on.
>>>>ra-SupervisionInfo
>>>>>preambleTransMax: maximum number of transmitted preambles specified in the TS

36.321 [6], integer type, options: {n3, n4, n5, n6, n7, n8, n10, n20, n50, n100, n200}, in which
the value n3 corresponds to 3, and n4 corresponds to 4, and so on.
>>>>>ra-ResponseWindowSize: size of the RA response window specified in the TS 36.321

[6], options: {sf2, sf3, sf4, sf5, sf6, sf7, sf8, sf10}. The value of this parameter can be
represented by the number of subframes. For example, the value sf2 corresponds to 2
subframes, and sf3 corresponds to 3 subframes, and so on.
>>>>>mac-ContentionResolutionTime: timer for the contention resolution specified in the TS

36.321 [6], options: {sf8, sf16, sf24, sf32, sf40, sf48, sf56, sf64}. The value of this parameter
can be represented by the number of subframes. For example, the value sf8 corresponds to 8
subframes, and sf16 corresponds to 16 subframes, and so on.
>>>>maxHARQ-Msg3Tx: maximum number of Msg3 HARQs that can be transmitted, integer

type, range: (1...8). it is used for random access-based contention.
57
>>>prach-Config
>>>>rootSequenceIndex: integer type, range: (0...837). For details about the parameter
RACH_ROOT_SEQUENCE, refer to the TS 36.211 [21, 5.7.1].
>>>>prach-ConfigInfo
>>>>>prach-ConfigIndex: integer type, range: (0...63). For details about the parameter
prach-ConfigurationIndex, refer to the TS 36.211 [21, 5.7.1].
>>>>>highSpeedFlag: BOOLEAN type. For details about the parameter High-speed-flag,

refer to the TS 36.211, [21, 5.7.2]. TRUE corresponds to a constraint set.
>>>>>zeroCorrelationZoneConfig: integer type, range: (0...15). For details about the

parameter NCS configuration, refer to the preamble formats in the [21, 5.7.2: table 5.7.2-2].
>>>>>prach-FreqOffset: integer type, range: (0...94). For details about the parameter prach-
FrequencyOffset, refer to the TS 36.211, [21, 5.7.1]. For TDD, the value range depends on the
value of prach-ConfigurationIndex.
>>>pdsch-ConfigCommon
>>>>referenceSignalPower: integer type, unit: dBm, range: (-60...50). For details about the
parameter Reference-signal power, providing downlink reference signal EPRE, refer to the TS
36.213 [23, 5.2].
58
>>>>p-b: integer type, range: (0...3), in which pb0 corresponds to 0, and pb1 corresponds to
1, and so on. For details about parameter P B , refer to the TS 36.213 [23, table 5.2-1]. The value
of this parameter depends on the number of antennas used.
>>>pusch-ConfigCommon
This parameter contains pusch-ConfigBasic and ul-ReferenceSignalsPUSCH.
>>>>pusch-ConfigBasic
n-SB: integer type, range: (1...4). For details about the parameter Nsb, refer to the TS 36.211
[21, 5.3.4].
>>>>>hoppingMode: options: {interSubFrame, intraAndInterSubFrame}. For details about

the parameter Hopping-mode, refer to the TS 36.211 [21, 5.3.4].
>>>>>pusch-HoppingOffset: integer type, range: (0...98). For details about the parameter
N HO
RB , refer to the TS 36.211 [21, 5.3.4].
enable64QAM: BOOLEAN type. For details, refer to the TS 36.213 [23, 8.6.1]. TRUE
indicates that 64 QAM is allowed, while FALSE indicates that 64 QAM is not allowed.
>>>>ul-ReferenceSignalsPUSCH
>>>>>groupHoppingEnabled: BOOLEAN type. This parameter corresponds to the parameter

Group-hopping-enabled. For details, refer to the TS 36.211 [21, 5.5.1.3].
>>>>>groupAssignmentPUSCH: integer type, range: (0...29). for details about the parameter
DSS, refer to the TS 36.211 [21, 5.5.1.3].
>>>>>sequenceHoppingEnabled: BOOLEAN type. For details about the parameter

Sequence-hopping-enabled, refer to the TS 36.211 [21, 5.5.1.4].
>>>>>cyclicShift: integer type, range: (0...7). For details about the parameter cyclicShift,
refer to the TS 36.211 [21, Table 5.5.2.1.1-2].
59
>>>phich-Config
>>>>phich-Duration: options: {normal, extended}. For details about the parameter PHICH-
Duration, refer to the TS 36.211 [21, Table 6.9.3-1].
>>>phich-Resource: options: {oneSixth, half, one, two}, in which the value oneSixth
corresponds to 1/6, and half corresponds to 1/2, and so on. For details about the
corresponding parameter Ng, refer to the TS 36.211 [21, 6.9].
>>>pucch-ConfigCommon
>>>deltaPUCCH-Shift: options: {ds1, ds2, ds3}, in which ds1 corresponds to value 1, and
PUCCH
ds2 corresponds to value 2, and so on. For details about the parameter Δ shift , refer to the TS
36.211, 5.4.1.
(2 )
>>>nRB-CQI: integer type, range: (0...98). For details about the parameter N RB , refer to the
TS 36.211 [21, 5.4].
(1 )
>>>nCS-AN: integer type, range: (0...7). For details about the parameter N cs , refer to the TS
36.211 [21, 5.4].
(1 )
>>>n1PUCCH-AN: integer type, range: (0...2047). For details about the parameter N PUCCH ,
refer to the TS 36.213 [23, 10.1].
>>>soundingRS-UL-ConfigCommon
>>>>t=1 relase: releases this configuration item.
>>>>t=2 setup: sets this configuration item.
60
>>>>>srsBandwidthConfig: options: {bw0, bw1, bw2, bw3, bw4, bw5, bw6, bw7}, in which
bw0 corresponds to value 0, and bw1 corresponds to value 1, and so on. For details about the
parameter SRS bandwidth configuration, refer to the TS 36.211, [21, tables 5.5.3.2-1, 5.5.3.2-2,
5.5.3.2-3 and 5.5.3.2-4]. The actual configuration is subject to the uplink bandwidth.
>>>>>srsSubframeConfig: options: {sc0, sc1, sc2, sc3, sc4, sc5, sc6, sc7, sc8, sc9, sc10,
sc11, sc12, sc13, sc14, sc15}, in which sc0 corresponds to value 0, sc1 corresponds to value
1, and so on. For details about the parameter SRS subframe configuration, refer to the the TS
36.211, [21, table 5.5.3.3-1]. For FDD, Table 5.5.3.3-1 is applicable, while for TDD, the TS
36.211, [21, table 5.5.3.3-2] is applicable.
>>>>>ackNackSRS-SimultaneousTransmission: BOOLEAN type. For details about the

parameter Simultaneous-AN-and-SRS, refer to the TS 36.213 [23,, 8.2].
>>>>>srsMaxUpPts: option: {true}. For details about the parameter srsMaxUpPts, refer to
the TS 36.211 [21, 5.5.3.2]. If this field is displayed, reconfiguration is valid for UpPts.
Otherwise, the reconfiguration is not used. For TDD, this field is optional. However, for FDD,
this field is not displayed, and the UE deletes any existing value in the field.
>>>uplinkPowerControlCommon
>>>>p0-NominalPUSCH: integer type, range: (-126...24), unit: dBm. For details about the
parameter
PO_NOMINAL_ PUSCH (1) , refer to the TS 36.213, 5.1.1.1. This field is applicable only to
non-continuous scheduling.
>>>>alpha: options: {al0, al04, al05, al06, al07, al08, al09, al1}, in which al0 corresponds to
value value 0, aI04 to 0.4, al05 to 0.5, al06 to 0.6, aI07 to 0.7, aI09 to 0.9, and aI1 to 1. For
details about the parameter α, refer to the TS 36.213, 5.1.1.1.
61
>>>>p0-NominalPUCCH: integer type, range: (-127..-96), unit: dBm. For details about the
P
parameter O_NOMINAL_ PUCCH , refer to the TS 36.213, 5.1.2.1.
>>>>deltaFList-PUCCH: indicates information about corresponding PUCCH format 1, 1b, 2,

2a, and 2b, in which deltaF-2 corresponds to -2 dB, and deltaF0 to 0 dB, and so on. For details
about the parameter , refer to the TS 36.213 [23, 5.1.2].
>>>>>deltaF-PUCCH-Format1: options: {deltaF-2, deltaF0, deltaF2}.
>>>>>deltaF-PUCCH-Format1b: options: {deltaF1, deltaF3, deltaF5}.
>>>>>deltaF-PUCCH-Format2: options: {deltaF-2, deltaF0, deltaF1, deltaF2}.
>>>>>deltaF-PUCCH-Format2a: options: {deltaF-2, deltaF0, deltaF2}.
>>>>>deltaF-PUCCH-Format2b: options: {deltaF-2, deltaF0, deltaF2}.
>>>>deltaPreambleMsg3: integer type, range: (-1...6), in which the value = IE value * 2 [dB].
Δ
For details about the parameter PREAMBLE Msg 3 , refer to the TS 36.213 [23, 5.1.1.1].
>>>antennaInfoCommon: number of antenna ports in the cell, options: {an1, an2, an4,
spare1}, in which an1 corresponds to 1 antenna port, and an2 to 2 antenna ports, and so on.
>>>p-Max: UE power used in the target cell. If this parameter is left blank, the UE uses the
maximum power.
>>>tdd-Config
>>>>subframeAssignment: DL/UL subframe configuration, options: {a0, sa1, sa2, sa3, sa4,
sa5, sa6}, in which sa0 indicates configuration 0, and sa1 configuration 1, and so on.
>>>>specialSubframePatterns: configuration in the TS 36.211 [21, table 4.2.1], options:

{ssp0, ssp1, ssp2, ssp3, ssp4, ssp5, ssp6, ssp7, ssp8}, in which ssp0 indicates configuration 0
and ssp1 configuration 1, and so on.
>>>ul-CyclicPrefixLength: length of the UL cyclic prefix, options: {len1, len2}, in which len1
corresponds to a normal cyclic prefix, and len2 corresponds to an extended cyclic prefix. For
details about the parameter ul-CyclicPrefixLength, refer to the 36.211 [21, 5.2.1].
62
>dedicatedInfoNASList
A reconfiguration message contains a NAS response to the INITIAL UE MESSAGE message

for the initial access procedure.
>securityConfigHO
This field is carried during the handover procedure rather than the initial access procedure.
Two configuration values are supported: intraLTE and interRAT.
>>intraLTE handover security configuration:
>>>securityAlgorithmConfig
>>>>cipheringAlgorithm: ciphering algorithm used by SRB, options: {eea0, eea1, eea2,

spare5, spare4, spare3, spare2, spare1….}. For details about this parameter, refer to the TS
33.401 [32, 5.1.4.2].
>>>>integrityProtAlgorithm: integrity protection algorithm type used by SRB and DRB,

options: {eia0-v920, eia1, eia2, spare5, spare4, spare3, spare2, spare1...}.
>>>keyChangeIndicator: whether the UE obtains a KeNB key from a previous successful

NAS SMC procedure or from KASME keys related to the current KeNB, BOOLEAN type. This
field is set to TRUE only during intra-cell handover.
>>>nextHopChainingCount: For details about the corresponding parameter NCC, refer to the
TS 33.401 [32].
>>interRAT handover security configuration:

63
>>>securityAlgorithmConfig: refer to the intraLTE handover security configuration.
>>>nas-SecurityParamToEUTRA: This field is used between the network and the UE for the
transmission of UE-specific NAS-layer information.
二.2.5 Security Mode Signaling Analysis
The following figure shows a successful security mode procedure during UE initial context
establishment.
Figure 2.2-18 Successful Security Mode Procedure
The following figure shows a failed security mode procedure during UE initial context
establishment.
64
Figure 2.2-19 Failed Security Mode Procedure
The signaling messages are analyzed as follows:
二.2.5.1 Security Mode Command
This message is sent by the E-NodeB to the UE, containing negotiated security algorithm
information, including ciphering algorithm and integrity protection algorithm.
>cipheringAlgorithm = 0: ciphering algorithm (0: eea0; 1: eea1; 2: eea2).
>integrityProtAlgorithm = 0: integrity protection algorithm (0: served; 1: eia1; 2: eia1).
For details, refer to the TS 36.331 6.3.3.
65
二.2.5.2 Security Mode Complete
A Security Mode Complete message is a response to a Security Mode Command message,

but does not contain any actual configuration information.
二.2.5.3 Security Mode Failure
A Security Mode Failure message is a response to a Security Mode Command message, but
does not contain any actual configuration information.
66
二.3 Common Signaling Procedures
二.3.1 Attach and Detach Procedures
 The Attach procedure allows a UE to register to an EPC, and establishes a default bearer
from the EPC to the UE.
 The Detach procedure allows a UE to disconnect from a network, and deletes all EPS
bearers.
 Attach procedure description:
 In LTE, the Attach procedure is accompanied by the setup of a default bearer in

the core network.
 Detach procedure description:
 The Detach procedure can be initiated by a UE/MME/SGSN/HSS.
The following figure uses the Attach procedure initiated by a UE in IDLE state as an example to
describe the signaling flow.
67
UE eNB MME
MSG1
MSG2-Random Access Response
RRCConnectionRequest
RRCConnectionSetup
RRCConnectionSetupComplete
(Attach request) INITIAL UE MESSAGE
（Attach request）
Identity/Authentication/Security
INITIAL CONTEXT SETUP REQUEST

(Attach Accept）
UECapabilityEnquiry
UECapabilityInformation
UE CAPABILITY INFO INDICATION
SecurityModeCommand
SecurityModeComplete
RRCConnectionReconfiguration
(Attach accept)
RRCConnectionReconfigurationComplete
INITIAL CONTEXT SETUP RESPONSE

ULInformationTransfer
(Attach Complete)
UPLINK NAS TRANSPORT
(Attach Complete)
For details about RRC signaling between the UE and eNodeB, refer to Chapter 2. The following
description focuses on the three signaling messages marked with red ellipses.
When the UE is in IDLE state, the Detach procedure is similar to the Attach procedure.
68
UE eNB MME
MSG1
MSG2-Random Access Response
RRCConnectionRequest
RRCConnectionSetup
RRCConnectionSetupComplete
(Detach request)
INITIAL UE MESSAGE
（Detach request）
UE CONTEXT RELEASE COMMAND
UE CONTEXT RELEASE COMPLETE
RRCConnectionRelease
 The three signaling messages, INITIAL UE MESSAGE, UE CONTEXT RELEASE

COMMAND, and UE CONTEXT RELEASE COMPLETE, are similar to those in the Attach
procedure. The difference is that the carried information here is about detachment.
69
二.3.1.1 Initial UE Message
>eNB_UE_SAP_ID: UE context ID on the S1 interface in the eNodeB.
>NAS_PDU: NAS PDU information carried in the RRCConnectionSetupComplete message.
>TAI: ID of the tracking area where the UE is located, including PLMN Identity and TAC:
>>PLMN Identity: ID of the PLMN.
>>>MCC: Mobile Country Code.

70
>>>MNC: Mobile Network Code.
>>TAC: Tracking Area Code, which uniquely identifies a tracking area.
>EUTRAN_CGI: Cell Global Identity, which globally identifies a cell, including PLMN Identity and
CellID.
>>CellID: ID of a cell.
>RRC_ESTABLISHMENT_CAUSE: cause for RRC reestablishment, including emergency,

highPriorityAccess, mt-Access, mo-Signaling, and mo-Data.
二.3.1.2 Initial Context Setup Request
>MME_UE_S1AP_ID: UE context ID on the S1 interface in the MME, range: 0-232 -1.
>ENB_UE_S1AP_ID: UE context ID on the S1 interface in the eNB, range: 0-224 -1.
>UE Aggregate Maximum Bit Rate: applicable to all non-GBR E-RABs of the UE.
>>UE Aggregate Maximum Bit Rate Uplink: UE Aggregate Maximum Bit Rate in the
uplink direction.
>>UE Aggregate Maximum Bit Rate Downlink: UE Aggregate Maximum Bit Rate in the
downlink direction.
71
>E-RAB to Be Setup List: E-RAB list to be established for initial context setup.
>>E-RAB ID: uniquely identifies a radio access bearer for a specific UE, and generates
a unique E-RAB ID on the S1 connection. The E-RAB ID remains the same through
the lifetime of the E-RAB, even if the UE-related logical S1 connection is released or
removed. This ID ranges from 0 to 15. However, the ID of a default bearer starts from
5, and the first few numbers are reserved.
>>E-RAB Level QoS Parameters: QoS parameters of the E-RAB, including QCI, ARP,
and GBR QoS information.
>>>QCI: QoS Class Identifier, range: 1-9.
>>>ARP: Allocation and Retention Priority, including the following three parts:
>>>>Priority Level: priority of the allocation and retention, range: 0-15. The
value 15 indicates "no priority", 1 the highest priority, and 14 the lowest
priority.
72
>>>>Pre-emption Capability: capability of this E-RAB to preempt other E-

RABs, enumerated type (shall not trigger pre-emption or may trigger pre-
emption). The two options respectively indicate that this E-RAB will not
preempt other E-RABs, and that this E-RAB may preempt other E-RABs.
>>>>Pre-emption Vulnerability: difficulty of this E-RAB being preempted by

other E-RABs, enumerated type (not pre-emptable or pre-emptable). The
two options respectively indicate that this E-RAB will never be preempted
by other E-RABs, and that this E-RAB may be preempted by other E-
RABs.
>>>>E-RAB Maximum Bit Rate Downlink: maximum bit rate of this E-RAB
in the downlink direction (from the EPC to the E-UTRAN).
>>>>E-RAB Maximum Bit Rate Uplink: maximum bit rate of this E-RAB in
the uplink direction (from the E-UTRAN to the EPC).
>>>>E-RAB Guaranteed Bit Rate Downlink: guaranteed bit rate of this E-

RAB in the downlink direction (assuming that there is data transmission).
>>>>E-RAB Guaranteed Bit Rate Uplink: guaranteed bit rate of this E-

RABin the uplink direction (assuming that there is data transmission).
>>TransportLayerAddress: address information of the Radio Network Layer.
>>GTP_TEID: endpoint identifier of the GTP tunnel.
>>NAS_PDU: contents of the NAS message carried in the INITIAL UE MESSAGE

message.
73
>>UE Security Capabilities: encryption and integrity protection algorithms supported by

the UE.
>>>Encryption Algorithms: indicates an encryption algorithm.
>>>Integrity Protection Algorithms: indicates an integrity protection algorithm.
>>>Security Key: Key of the eNB.
二.3.1.3 Initial Context Setup Response
>MME_UE_S1AP_ID = 33554449: UE context ID on the S1 interface in the MME.
>ENB_UE_SAP_ID = 7: UE context ID on the S1 interface in the eNodeB.
>E-RAB Setup List: E-RAB list that is successfully created.
>>TransportLayerAddress: The radio network layer does not interpret address

information. It directly sends this address to the network layer, where the address is IP
address.
74
>>GTP_TEID: endpoint identifier of the GTP tunnel, which is used for user plane
transport between the eNodeB and the serving gateway.
二.3.1.4 Initial Context Setup Failure
>Cause .t = 1: indicates a Radio Network Layer release (1: Radio Network Layer; 2: Transport
Layer; 3: NAS layer; 4: protocol).
>>Cause.u = 32: indicates that the security algorithms are not supported.
75
二.3.1.5 UE Context Release Command
This message is sent by the MME to the eNodeB to release the UE context on the S1
interface. It carries the ID of the UE context to be released and the release cause.
>Cause.t = 3: indicates a NAS layer release (1: Radio Network Layer; 2: Transport Layer; 3:
NASlayer, and 4: protocol).
>>Cause.u = 2: indicates that the release cause is Detach.
76
二.3.1.6 UE Context Release Complete
二.3.2 Service Request Procedure
This procedure is similar to the Attach procedure. The difference is that the NAS message
carried in the INITIAL UE MESSAGE is different.
77
Figure 2.3-20 Service Request Procedure
The Service Request procedure is described as follows:
 To perform a Service Request procedure, a UE in RRC_IDLE initiates a random access

procedure, meaning an MSG1 message.
 After detecting the MSG1 message, the eNB sends a Random Access Response
message, meaning an MSG2 message.
 After receiving the random access response, the UE adjusts the uplink transmission time
based on the TA of the MSG2 message, and sends an RRC Connection Request
message to the eNB.
 The eNB sends an RRC Connection Setup message to the UE, containing SRB1 bearer
setup and radio resource configuration information.
 After completing the SRB1 bearer setup and radio resource configuration, the UE sends
an RRC Connection Setup Complete message to the eNB, containing a NAS Service
Request.
78
 The eNB selects an MME and sends an INITIAL UE MESSAGE message to the MME,
containing a NAS Service Request.
 The MME sends an INITIAL CONTEXT SETUP REQUEST message to the eNB, to
request setup of UE context.
 After receiving the INITIAL CONTEXT SETUP REQUEST message, if the message does
not contain any UE capability information, the eNB sends a UE Capability Enquiry
message to the UE, to query the UE's capability.
 The UE sends a UE Capability Information message to the eNB, to report the UE's
capability.
 The eNB sends a UE CAPABILITY INFO INDICATION message to the MME, to update
the UE capability information on the MME.
 Based on the security information supported by the UE in the INITIAL CONTEXT SETUP
REQUEST message, the eNB sends a Security Mode Command message to the UE, for
security activation.
 The UE sends a Security Mode Complete message to the UE, to confirm that the security
activation is completed.
 Based on the ERAB setup information in the INITIAL CONTEXT SETUP REQUEST
message, the eNB sends an RRC Connection Reconfiguration message to the UE for
UE resource reconfiguration, such as SRB1 and radio resource configuration, SRB2
signaling bearer setup, and DRB service bearer setup.
 The UE sends an RRC Connection Reconfiguration Complete message to the eNB,

indicating that the resource reconfiguration is completed.
 The eNB sends an INITIAL CONTEXT SETUP RESPONSE message to the MME,
indicating that the UE context setup is completed.
From the INITIAL UE MESSAGE message, you can identify that this procedure is a Service
Request procedure.
79
The MME sends a UE CONTEXT RELEASE COMPLETE message to the eNB, to release
the resources on the source side.
80
二.3.3 Dedicated Bearer Procedures
二.3.3.1 Dedicated Bearer Setup Procedure
Figure 2.3-21 Dedicated Bearer Setup Procedure
The dedicated bearer setup procedure is described as follows:
81
 A UE in Connected state transfers a Bearer Resource Allocation Request message (or a

Bearer Resource Modification Request message) in a UL Information Transfer message
to the eNB.
 The eNB sends the Bearer Resource Allocation Request message (or the Bearer
Resource Modification Request message) in an UPLINK NAS TRANSPORT message to
the EPC.
 The EPC handles the bearer resource request.
 The EPC sends an Activate Dedicated EPS Bearer Context Request message in an E-
RAB SETUP REQUEST message to the eNB.
 The eNB sends the Activate Dedicated EPS Bearer Context Request message in an
RRC Connection Reconfiguration message to the UE.
 When the dedicated bearer is successfully set up, the UE returns an RRC Connection
Reconfiguration Complete message, indicating that the bearer setup succeeds.
 The eNB sends an E-RAB SETUP RESPONSE message to the EPC, indicating that the
radio bearer setup succeeds.
 After sending the RRC Connection Reconfiguration Complete message, the UE sends an
Activate Dedicated EPS Bearer Context Accept message in a UL Information Transfer
message to the eNB.
 The eNB sends the Activate Dedicated EPS Bearer Context Accept message in a UL
NAS TRANSPORT message to the EPC.
 Then, the uplink and downlink data can be transmitted over the bearer.
 The EPC accepts the response to the bearer resource request.
82
二.3.3.2 Dedicated Bearer Modification Procedure
Figure 2.3-22 Dedicated Bearer Modification Procedure
83
The dedicated bearer modification procedure is described as follows:
 A UE in Connected state transfers a Bearer Resource Allocation Request message (or a

Bearer Resource Modification Request message) in a UL Information Transfer message
to the eNB.
 The eNB sends the Bearer Resource Allocation Request message (or the Bearer
Resource Modification Request message) in an UPLINK NAS TRANSPORT message to
the EPC.
 The EPC handles the bearer resource request.
 The EPC sends a Modify Dedicated EPS Bearer Context Request message in an E-RAB
MODIFY RESPONSE message to the eNB.
 The eNB sends the Modify Dedicated EPS Bearer Context Request message in an RRC
Connection Reconfiguration message to the UE.
 After successful dedicated bearer modification, the UE returns an RRC Connection

Reconfiguration Complete message, indicating that the bearer is successfully modified.
 The eNB sends an E-RAB MODIFY RESPONSE message to the EPC, indicating that the
radio bearer is successfully modified.
 After sending the RRC Connection Reconfiguration Complete message, the UE sends a
Modify Dedicated EPS Bearer Context Accept message in a UL Information Transfer
message to the eNB.
 The eNB sends the Modify Dedicated EPS Bearer Context Accept message in a UL NAS
TRANSPORT message to the EPC.
 Then, the uplink and downlink data can be transmitted over the bearer.
 The EPC accepts the response to the bearer resource request.
84
二.3.3.3 Dedicated Bearer Release Procedure
Figure 2.3-23 Dedicated Bearer Release Procedure
The dedicated bearer release procedure is described as follows:
 The EPC initiates a bearer release procedure. This procedure may be requested by the
UE or started at the EPC side.
 The EPC sends an E-RAB Release Command message to the eNB, containing a NAS
message (Deactive EPS Bearer Context Request).
85
 After receiving the E-RAB Release Command message, the eNB starts the bearer
release procedure, and sends an RRC Connection Reconfiguration message to the UE,
containing the NAS message (Deactive EPS Bearer Context Request).
 After receiving the NAS message (Deactive EPS Bearer Context Request) in the RRC
Connection Reconfiguration message, the UE releases related bearer resources.
 The UE returns an RRC Connection Reconfiguration Complete message, indicating that

the radio bearer is successfully released.
 After receiving the RRC Connection Reconfiguration Complete message, the eNB
returns an E-RAB Release Response message to the EPC.
 The eNB sends an E-RAB RELEASE RESPONSE message to the EPC, indicating that
the radio bearer is successfully released.
 After sending the RRC Connection Reconfiguration Complete message, the UE sends a
NAS message (Deactivate EPS Bearer Context Accept) in a UL Information Transfer
message to the eNB.
 The eNB sends the Deactivate EPS Bearer Context Accept message in a UL NAS
TRANSPORT message to the EPC, indicating that the EPS bearer release is completed.
86

FO - SP2105 - E01 - 0 LTE Air Interface Protocols and Signaling Procedures

Uploaded by

Copyright:

Available Formats

FO - SP2105 - E01 - 0 LTE Air Interface Protocols and Signaling Procedures

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FO - SP2105 - E01 - 0 LTE Air Interface Protocols and Signaling Procedures

Uploaded by

Copyright:

Available Formats

LTE Air Interface Protocols and

Chapter 2 Signaling Message Analysis......................................................................................................17

Radio Control Plane User Plane

Transport Transport Network Transport Network

一.2 LTE Air Interface Protocols

一.2.1 Control Plane Protocols

- EPS bearer management

一.2.2 User Plane Protocols

Figure 1.2-2 Air Interface User Plane Protocol Stack

一.3 LTE Interface Introduction

The S1 control plane interface has the following functions:

 Mobility management functions for UEs in LTE_ACTIVE state (including intra-LTE

 NAS signaling transport

 S1 interface management (including reset, error indication, and overload indication)

 Roaming and area restriction support

 NAS node selection

 Initial context setup

Figure 1.3-3 S1 Interface Control Plane Protocol Stack

GTP-U has the following features:

 GTP-U supports IPv4/UDP-based transport and also IPv6/UDP-based transport.

 The UDP header is independent from the used IP version.

 Avoiding data loss during mobility procedures

 Error handling mechanism

 MBMS support function

 Packet loss detection mechanism

Figure 1.3-4 S1 Interface User Plane Protocol Stack

Figure 1.3-5 X2 Interface User Plane Protocol Stack

Figure 1.3-6 X2 Interface Control Plane Protocol Stack

The X2 interface has the following functions:

 Mobility management, including handover resource allocation, SN status transfer, and

 Reset, used to reset the X2 interface between eNBs

 X2 setup, used to exchange cell information between eNBs

- Load and interference-related information

The handover via the X2 interface is referred to as seamless handover or lossless

一.4 LTE Signaling Message Structures

一.4.1 LTE Signaling Flow and Service Flow

Figure 1.4-7 X2 Interface Control Plane Protocol Stack

一.4.2 NAS Signaling

NAS signaling includes MM signaling and SM signaling.

NAS EPS MM signaling message:

NAS EPS SM signaling message:

Network initiated ESM

一.4.3 RRC Signaling

 Sending of paging and system information

 Setup, modification, and release of RRC connections and radio bearers

 Transfer of NAS messages between UEs and NAS

 Providing parameter configuration for lower-layer protocol entities

 Radio configurations control (physical layer and L2 configurations)

 Cell's public parameters and user-specific parameters

 QoS management (such as semi-persistent scheduling and rate control)

 In charge of measurement and control related to the UE mobility management

 IDLE state: cell selection and reselection

 CONNECTED state: handover

RRC signaling includes the following messages:

 System broadcast message

 RRC connection message (request, establishment, and release)

 RRC connection reestablishment message

 RRC connection reconfiguration message

 Inter-system mobility management message