3 Ltelayer3analysispart1 160408135823 PDF

3.
LTE Layer 3 Analysis (Part 1)
Author : Ray Khastur

Title : LTE Optimization Consultant MobileComm Professionals, Inc MobileComm Professionals, Inc
Consulting | Training | Research

Company Confidential - Pinnacle Learning Center
Call Processing Procedure
MobileComm Professionals, Inc

Cell Search & Detection
SIB Decoding
(Neighbor Cell Detection)
MIB Decoding
(PLMN Decoding)
SSS Detection
RSRE Decoding
(PCI Decoding)
Filter by RSRP Threshold

PSS Detection
PCI = 3*physical layer id group(from SSS)+phy layer cell id(from PSS).
RSSI Scan

PSS & SSS Location in LTE

Cell Selection Criteria
During cell selection, a UE selects an E-UTRAN cell that meets the cell selection criteria. The
UE can camp on a cell only when the RSRP and reference signal received quality (RSRQ) of the cell are greater than the
values of the CellSel.Qrxlevmin and CellSel.Qqualmin parameters, respectively.
A UE selects an E-UTRAN cell to camp on when the cell meets both of the following conditions:
Srxlev > 0
Squal > 0
where:
Srxlev = Qrxlevmeas - (Qrxlevmin + Qrxlevminoffset) - Pcompensation
Squal = Qqualmeas - (Qqualmin + Qqualminoffset)
The variables in the previous formulas are described as follows:
l Qrxlevmeas: measured received signal level (that is, measured RSRP), expressed in dBm.
l Qrxlevmin: minimum required received signal level configured on the eNodeB, expressed
in dBm.
l Qrxlevminoffset: offset to the value of Qrxlevmin. In cell selection, this offset is considered
when the UE in a VPLMN attempts to camp on a cell in a higher-priority PLMN.
l Pcompensation: max (PMax - UE Maximum Output Power, 0), expressed in dB.
PMax: maximum transmit power (expressed in dBm) of the UE during uplink
transmission.
UE Maximum Output Power: maximum output power (expressed in dBm) of the UE.
l Qqualmeas: measured received signal quality (that is, measured RSRQ), expressed in dB.
l Qqualmin: minimum required received signal quality configured on the eNodeB, expressed
in dB.
l QQualminoffset: offset to Qqualmin. In cell selection, this offset is considered when the
UE in a VPLMN attempts to camp on a cell in a higher-priority PLMN.

Cell Selection Criteria

RNTI
One of the other numbers which you would very frequently come across is RNTI.
RNTI stands for Radio Network Temporary Identifier.
As the name implies, it is a kind of Identification number. Normally we use identification number to differentiate one thing
from all other similar things. For example, your driver's license number let you identify yourself from all other drivers.
Social Security number do the same thing as well.
Getting more specifically into LTE, this RNTI is used to identify one specific radio channel from other radio channel and
one user from another user. As you may recall, in WCDMA is a RNTI concept which is carried as part of MAC header to
differentiate one user to another while in communication state. and in WCDMA case it used special channelization code
to differentiate one radio channel from the other.
Types of RNTI
P-RNTI : It stands for Paging RNTI. Used for Paging Message.
SI-RNTI : It stands for System Information RNTI. Used for transmission of SIB messages
RA-RNTI : It stands for Random Access RNTI. Used for PRACH Response.
C-RNTI : It stands for Cell RNTI. Used for the transmission to a specific UE after RACH.
T-CRNTI : It stands for Temporary C-RNTI. Mainly used during RACH
SPS-C-RNTI : It stands for Semi persistance Scheduling C-RNTI
TPC-PUCCH-RNTI : It stands for Transmit Power Control-Physical Uplink Control Channel-RNTI
TPC-PUSCH-RNTI : It stands for Transmit Power Control-Physical Uplink Shared Channel-RNTI
M-RNTI : It stands for MBMS RNTI

RNTI Mapping
When MAC uses the PDCCH to indicate radio resource
allocation, the RNTI that is mapped on the PDCCH
depends on the logical channel type:

3.1 EMM & ECM State

Types of EMM Procedure
1. EMM common procedure: Refers to one that can always

be initiated whilst a NAS signaling connection exists
between a UE and MME. This procedure can be divided
further into five procedures : globally unique temporary
identifier (GUTI) allocation, authentication, identification,
security mode control (SMC), and EMM information;
2. EMM specific procedure: Refers to one that is related to
user mobility (registration and location update). It can be
divided further into three procedures: attach, detach and
TA update (TAU). In an LTE network built with an existing
3GPP network, additional procedures (i.e. combined
attach, combined detach and combined tracking area
update) are also included in the procedure. However,
since this document discuss an LTE network only, these
procedures are excluded in Table 1 (See LTE
Interworking technical document (TBD)) for more
information about the procedures); and
3. EMM connection management procedure: Refers to one
related to establishing a NAS signaling connection. It can
be divided further into three procedures: service request,
paging and transport of NAS messages

EMM / ECM / RRC State
Beside picture illustrates EMM, ECM and RRC
states associated with the UE and MME. EMM can
be in either EMM-Registered or EMM-
Deregistered state depending on whether the UE
is attached to, or detached from, the network. ECM
can have either ECM-Connected or ECM-Idle
depending on whether a NAS signaling connection
(i.e. ECM connection) is established or not.
Likewise, RRC can be in either RRC-Connected or
RRC-Idle depending on whether an RRC
connection is established or not.

EMM State Transition

3.1.1 EMM Deregistered State
In both A and B, the states are EMM-Deregistered, While in state B, the network keeps the user While in EMM-Deregistered state (A or B), the UE
ECM-Idle and RRC-Idle, and the UE is detached from information required for authentication and security figures out with which cell in which network it can
the network. However, since the UE information that setup (GUTI, NAS security context) in case the UE communicate while selecting a Public Land Mobile
the network has in two cases is different, the two attaches to it again. Then it deletes them after a Network (PLMN) and cell. When the UE requests
cases are discussed separately. The network has no certain period of time, and transits to state A permission to attach to the network to use services,
UE information other than provisioning information in an initial attach procedure begins, making the UE
case of state A, whereas the network keeps the GUTI transit to state C (EMM-Registered, ECM-Connected
and NAS Security Context (See LTE Security and RRC-Connected).
technical document) obtained last time the UE
attached to it, if they are still valid in case of state B.
So, depending on whether a UE attaches to the
network in state A or in state B, the initial attach
procedure may vary

3.1.2 EMM Registered State
While in state C, radio and network resources are State transition from D to C occurs when i) there is
assigned to signalling connections in control plane new traffic (UL or DL), AND ii) the UE in Idle state
and EPS bearers in user plane. And a UE may perform makes a TAU request as its TA is changed or TAU
n both C and D, the states are EMM-Registered, and timer is expired. On the other hand, state transition
handover to a neighbor cell which turned out to have
the UE is attached to (or registered to) the network. from C to D occurs when i) UE inactivity is detected
better radio signal quality than its current cell even
However, ECM and RRC can be either in ECM- (there is no UE traffic (UL or DL) for a certain period of
while communicating with its serving cell. However,
Connected/RRC-Connected (C) or ECM-Idle/RRC-Idle time), AND ii) the UE returns to state D having
while in state D, a UE is deactivated and thus
(D) state depending on the activity status of the UE. resources released after the UE in state D makes a
ECM/RRC connection is released. Resources are
Once the UE is successfully attached to the network TAU request as its TAU timer is expired (state C).
assigned neither to ECM connection in control plane,
by transiting its state from EMM-Deregistered state
nor to EPS bearers (DRB and S1 bearer) except for S5
(state A or B) to state C, it stays in state Cwhile using While in EMM-Registered state (C or D), the UE is
bearer. In this state, no user traffic (UL/DL) can be
services, but transits to state D while not using detached from the network, transiting the state to
delivered by UE or the network. In order for user
services. state B (i.e. EMM-Deregistered state) if it is turned off
traffic to be delivered in state D, ECM connection
should be established again, having the state transit or if the radio link fails (if the packet error rate over
to state C, and then a new DRB and S1 bearer should the radio link exceeds the threshold value. In addition,
be established to activate EPS bearer. In state D, the state transition from EMM-Registered to EMM-
UE selects a cell to camp in according to the cell Deregistered (state B) occurs when the UE in
reselection criteria by measuring the strength of radio state C performs handover to a non-LTE network,
signals from its serving cell and neighboring cells MobileComm
when its request to attachProfessionals, Incis rejected
to the network
(Attach Reject), or its TA update request is rejected
(TAU Reject). Consulting | Training | Research
UE Location Information
EMM-Registered state (C and D) indicates that a UE is attached to a network and

the network knows the UEs current location. In this state, the network knows the
location of the UE at the granularity of cells if the UE is in active state (C), and at
the granularity of TAs if in idle state (D). To an HSS, unlike other EPS entities, a
UEs location is also known at MME level except while the UE is in state A.

EPS Bearer and NAS Signaling Connection
Above Table shows in which state an EPS bearer for delivering user traffic and a NAS signaling connection for delivering NAS signaling
messages are established and maintained. Once a UE successfully attaches to a network and becomes EMM-Registered state, it uses
services provided through EPS bearers. An EPS bearer consists of three bearers: Data Radio Bearer (DRB), S1 bearer and S5 bearer. As seen
in Figure 3, all these three bearers are established and stay activated (and thus radio and network resources are assigned) in ECM-
Connected/RRC-Connected state (state C) where user traffic is being delivered On the other hand, only S5 bearer is established and stays
activated and other bearers are deactivated (any assigned resources are released) in ECM-Idle/RRC-Idle state (state D) where there is no
user traffic.
NAS signaling connection (i.e. ECM connection), consisting of RRC connection and S1 signaling connection, is established only when user
traffic is being delivered, i.e. in ECM-Connected/RRC-Connected state (state C). When the user is detached from the network (state A or B),
or is attached to the network but in idle state (state D), ECM connection is released.

EPS Bearer and NAS Signaling Connection

Mobility
Tracking Area Update: A UE in EMM-Registered

Mobility: A turned-on UE in EMM-Deregistered state (state C or D), whether using services or not, Paging: When a UE is attached to the
state (state A or B) figures out in which cell and updates its TA whenever it is changed. However, network, but in idle state (state D), if
in which network it is located by selecting a while in ECM-Idle/RRC-Idle state (state D), the UE there is user traffic to deliver, the
PLMN and cell. A UE using services in EMM- updates its TA on a regular basis every time the network initiates paging to wake up
Registered state (state C) performs handover TAU timer is expired even when its TA is not the UE, consequently transiting the
from its current cell to another neighbor cell changed. TA update is initiated by a TAU UEs state to state C. The paging is
which turned out to have better radio signal Request message sent by the UE. conducted based on the Tracking Area
quality than its current cell. A UE currently not While the UE is in ECM-Idle/RRC-Idle state Identifier (TAI) information provided
(state D), ECM/RRC connection should be
using services, but in EMM-Registered state by the UE during its last TA update.
established first, and the state must be transited to
(stateD) performs cell reselection searching for ECM-Connected/RRC-Connected state (state C) in
another neighbor cell with better radio signal order for the UE to update its TA. Once the UE in
quality than its current cell, and camps in one state C sends TAU Request message and
with the best quality. receives TAU Accept message from an MME, the
TAU procedure is completed. Then, ECM/RRC
connection is released, and the UE turns back to
ECM-Idle/RRC-Idle state (state D). MobileComm Professionals, Inc

UE - ID
A UE IP address is assigned by a P-GW when the UE initially attaches to the network, causing a default bearer
to be established, and is released when the default bearer is deactivated. GUTI is assigned by an MME when a
UEs initial attach to the network is completed successfully and is used instead of International Mobile
Subscriber Identity (IMSI), a permanent ID. If the UE is detached from the network successfully, the UE and
the MME keep the UEs last GUTI and use it as a UE ID next time the UE attaches to the network, even after
detached. C-RNTI is assigned by an eNB to distinguish UEs in a cell in RRC-Connected state (state C), and is
valid only in the cell associated with the assigned C-RNTI. eNB UE S1AP ID and MME UE S1AP ID are used by
an eNB and MME to distinguish UEs over S1-MME interface. And, Old eNB UE X2AP ID and New eNB UE X2AP
ID are used by a serving eNB and target eNB to distinguish UEs over X2 interface when a UE performs
handover from the source eNB to the target eNB

3.2 SYSTEM INFORMATION BROADCAST
LTE

System Information Broadcast

MIB & SIB Information

Master Information Block
MIB in LTE has very minimal information. The only information it carries are
i) BandWidth
ii) PHICH
iii) SystemFrameNumber
Of course the most important information is "BandWidth".
According to 36.331 section 5.2.1.2, the MIB scheduling is as follows :

The MIB uses a fixed schedule with a periodicity of 40 ms and repetitions made within 40 ms.
The first transmission ofthe MIB is scheduled in subframe #0 of radio frames for which the
SFN mod 4 = 0, and repetitions are scheduled insubframe #0 of all other radio frames.

MIB from Drivetest Result

System Information Block Type 1
The important information on SIB 1 is
i) PLMN
ii) Tracking Area Code
iii) Cell Selection Info
iv) Frequency Band Indicator
v) Scheduling information (periodicity) of other SIBs
Especially at initial test case development, you have to be very careful about item v). If you set this value
incorrectly, all the other SIBs will not be decoded by UE. And as a result, UE would not recognize the cell
and show "No Service" message.

SIB1 from Drivetest Result

System Information Block Type 1 (contd)
According to 36.331 section 5.2.1.2, the SIB1 scheduling is as follows :
The SystemInformationBlockType1 uses a fixed schedule with a periodicity of 80 ms and repetitions made within 80 ms.The
first transmission of SystemInformationBlockType1 is scheduled in subframe #5 of radio frames for which the SFNmod 8 = 0,
and repetitions are scheduled in subframe #5 of all other radio frames for which SFN mod 2 = 0.
This means that even though SIB1 periodicity is 80 ms, different copies (Redudancy version : RV) of the SIB1 is transmitted
every 20ms. Meaning that at L3 you will see the SIB1 every 80 ms, but at PHY layer you will see it every 20ms. For the
detailed RV assignment for each transmission, refer to 36.321 section 5.3.1 (the last part of the section)

System Information Block Type 1 (L3)
RRC_LTE:BCCH-DL-SCH-Message
BCCH-DL-SCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [systemInformationBlockType1]
+-systemInformationBlockType1 ::= SEQUENCE [000]
+-cellAccessRelatedInfo ::= SEQUENCE [0]
| +-plmn-IdentityList ::= SEQUENCE OF SIZE(1..6) [1]
| | +-PLMN-IdentityInfo ::= SEQUENCE
| | +-plmn-Identity ::= SEQUENCE [1]
| | | +-mcc ::= SEQUENCE OF SIZE(3) OPTIONAL:Exist
| | | | +-MCC-MNC-Digit ::= INTEGER (0..9) [0]
| | | +-mnc ::= SEQUENCE OF SIZE(2..3) [2]
| | | +-MCC-MNC-Digit ::= INTEGER (0..9) [0]
| | | +-MCC-MNC-Digit ::= INTEGER (0..9) [1]
| | +-cellReservedForOperatorUse ::= ENUMERATED [notReserved]
| +-trackingAreaCode ::= BIT STRING SIZE(16) [0000000000000001]
| +-cellIdentity ::= BIT STRING SIZE(28) [0000000000000000000100000000]
| +-cellBarred ::= ENUMERATED [notBarred]
| +-intraFreqReselection ::= ENUMERATED [notAllowed]
| +-csg-Indication ::= BOOLEAN [FALSE]
| +-csg-Identity ::= BIT STRING OPTIONAL:Omit
+-cellSelectionInfo ::= SEQUENCE [0]
| +-q-RxLevMin ::= INTEGER (-70..-22) [-53]
| +-q-RxLevMinOffset ::= INTEGER OPTIONAL:Omit
+-p-Max ::= INTEGER OPTIONAL:Omit
+-freqBandIndicator ::= INTEGER (1..64) [7]
+-schedulingInfoList ::= SEQUENCE OF SIZE(1..maxSI-Message[32]) [2]
| +-SchedulingInfo ::= SEQUENCE
| | +-si-Periodicity ::= ENUMERATED [rf8]
| | +-sib-MappingInfo ::= SEQUENCE OF SIZE(0..maxSIB-1[31]) [0]
| +-SchedulingInfo ::= SEQUENCE
| +-si-Periodicity ::= ENUMERATED [rf8]
| +-sib-MappingInfo ::= SEQUENCE OF SIZE(0..maxSIB-1[31]) [1]
| +-SIB-Type ::= ENUMERATED [sibType3]
+-tdd-Config ::= SEQUENCE OPTIONAL:Omit
+-si-WindowLength ::= ENUMERATED [ms20] MobileComm Professionals, Inc
+-systemInfoValueTag ::= INTEGER (0..31) [0]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit Consulting | Training | Research
X-Feeder Troubleshoot with SIB Type 1
For LTE Network SON Feature (PCI Optimization), everyday PCI will be changing. So
during drivetest if not following daily Engineering Parameter from system. Common
people will see there is cross feeder issue. Actually on PCI Optimizer there is no exact
rule lower number of PCI should be correlated with lower number of Local Cell ID.
The general rule of PCI Optimizer one LTE Site should use same SSS ID, and PSS ID
can be randomly as long the system can arrange not facing with the same PSS ID from
the other site.
Whatever the PCI on the implementation, we should be able to analyze the cell
footprint from LTE Broadcast Channel on SIB Type 1. Which contains PLMN ID,
TAC, eNB ID and the Important thing is Cell ID. Cell ID should following rule
clockwise numbering, from the smaller to the higher.
How to breakdown CellIdentity into Cell ID:
= (28 . _) + _

Simply Android Tools to Check Cell_ID
In the Google Play Store we can download free application
to measurement RF Network including LTE Network. There
is exact information from SIB1 such as:
1) MCC
2) MNC
3) TAC
4) eNB ID
5) Cell ID
6) PCI
7) RSRP
8) RSRQ
9) SINR
10)RSSI
11)Neighbor List Detection

PCI vs Cell ID
Based on described Daily PCI Planning, Cell ID
Antenna will never change since Cell ID more correlated
with physical than PCI it self.
Cell_Id : 1
RRU
Day PCI Cell_Id eNB_ID
1 0 1 12001
CPRI 2 1 1 12001 UE
3 2 1 12001
4 6 1 12001
5 7 1 12001
BBU
6 8 1 12001
Cell ID related with Specific Hardware & Specific Frequency

PCI is Logic configuration, which may changing freely MobileComm Professionals, Inc




Mapping Problem & Troubleshoot
After we understand above description, left picture showing actual
condition of Cell ID placement, and we can assign related team to
swap CPRI/Feeder according to condition of cross feeder issue exist.

Nemo Analyze Limitation on SIB1
On Nemo Analyze the CELLIDENTITY information still in Decimal Value which is not yet breakdown into eNB ID and Cell ID
format. So we need to breakdown the value with Formula that we get from previous slide
= (28 . _) + _

Nemo Analyze Limitation on SIB1 (contd)
= (28 . _) + _
In this case at least we need to find out the eNB ID from the
Engineering Parameter.
From the EP, eNB ID for this site was 15211.

So, Cell_Id = 3894021 256x15211
Cell_Id = 3894021 3894016
Cell_Id = 5

System Information Block Type 2
The important information on SIB2 is
i) RACH Configuration
ii) bcch, pcch, pdsch, pusch, pucch configuration
iii) sounding RS Configuration
iv) UE Timers
SIB2 is the most important SIB in LTE and you will look into this SIB most frequently when you are implementing protocol
stack and troubleshooting, since it defines the characteristics of the most physical channels.
If we have some issues at registration process especially before 'RRC Connection Reconfiguration'. The first part we have to
check is SIB2 and check if UE properly decoded this and properly configure UE according to SIB2. Sometimes only one
parameter mismatch of SIB2 between Network and UE can make difference between success and failure of the whole
registration process.


SIB2 from Drivetest Result (contd)

RRC_LTE:BCCH-DL-SCH-Message
BCCH-DL-SCH-Message ::= SEQUENCE
+-c1 ::= CHOICE [systemInformation]
+-systemInformation ::= SEQUENCE
+-criticalExtensions ::= CHOICE [systemInformation-r8]
+-systemInformation-r8 ::= SEQUENCE [0]
+-sib-TypeAndInfo ::= SEQUENCE OF SIZE(1..maxSIB[32]) [1]
| +- ::= CHOICE [sib2]
| +-sib2 ::= SEQUENCE [00]
| +-ac-BarringInfo ::= SEQUENCE OPTIONAL:Omit
| +-radioResourceConfigCommon ::= SEQUENCE
| | +-rach-Config ::= SEQUENCE
| | | +-preambleInfo ::= SEQUENCE [0]
| | | | +-numberOfRA-Preambles ::= ENUMERATED [n52]
| | | | +-preamblesGroupAConfig ::= SEQUENCE OPTIONAL:Omit
| | | +-powerRampingParameters ::= SEQUENCE
| | | | +-powerRampingStep ::= ENUMERATED [dB2]
| | | | +-preambleInitialReceivedTargetPower ::= ENUMERATED [dBm-104]
| | | +-ra-SupervisionInfo ::= SEQUENCE
| | | | +-preambleTransMax ::= ENUMERATED [n6]
| | | | +-ra-ResponseWindowSize ::= ENUMERATED [sf10]
| | | | +-mac-ContentionResolutionTimer ::= ENUMERATED [sf48]
| | | +-maxHARQ-Msg3Tx ::= INTEGER (1..8) [4]
| | +-bcch-Config ::= SEQUENCE
| | | +-modificationPeriodCoeff ::= ENUMERATED [n4]
| | +-pcch-Config ::= SEQUENCE
| | | +-defaultPagingCycle ::= ENUMERATED [rf128]
| | | +-nB ::= ENUMERATED [oneT]
| | +-prach-Config ::= SEQUENCE
| | | +-rootSequenceIndex ::= INTEGER (0..837) [22]
| | | +-prach-ConfigInfo ::= SEQUENCE
| | | +-prach-ConfigIndex ::= INTEGER (0..63) [3]

| | | +-highSpeedFlag ::= BOOLEAN [FALSE]
| | | +-zeroCorrelationZoneConfig ::= INTEGER (0..15) [5]
| | | +-prach-FreqOffset ::= INTEGER (0..94) [2]
| | +-pdsch-Config ::= SEQUENCE
| | | +-referenceSignalPower ::= INTEGER (-60..50) [18]
| | | +-p-b ::= INTEGER (0..3) [0]
| | +-pusch-Config ::= SEQUENCE
| | | +-pusch-ConfigBasic ::= SEQUENCE
| | | | +-n-SB ::= INTEGER (1..4) [1]
| | | | +-hoppingMode ::= ENUMERATED [interSubFrame]
| | | | +-pusch-HoppingOffset ::= INTEGER (0..98) [4]
| | | | +-enable64QAM ::= BOOLEAN [FALSE]
| | | +-ul-ReferenceSignalsPUSCH ::= SEQUENCE
| | | +-groupHoppingEnabled ::= BOOLEAN [TRUE]
| | | +-groupAssignmentPUSCH ::= INTEGER (0..29) [0]
| | | +-sequenceHoppingEnabled ::= BOOLEAN [FALSE]
| | | +-cyclicShift ::= INTEGER (0..7) [0]
| | +-pucch-Config ::= SEQUENCE
| | | +-deltaPUCCH-Shift ::= ENUMERATED [ds2]
| | | +-nRB-CQI ::= INTEGER (0..98) [2]
| | | +-nCS-AN ::= INTEGER (0..7) [6]
| | | +-n1PUCCH-AN ::= INTEGER (0..2047) [0]
| | +-soundingRS-UL-Config ::= CHOICE [setup]
| | | +-setup ::= SEQUENCE [0]
| | | +-srs-BandwidthConfig ::= ENUMERATED [bw3]
| | | +-srs-SubframeConfig ::= ENUMERATED [sc0]
| | | +-ackNackSRS-SimultaneousTransmission ::= BOOLEAN [TRUE]
| | | +-srs-MaxUpPts ::= ENUMERATED OPTIONAL:Omit
| | +-uplinkPowerControl ::= SEQUENCE
| | | +-p0-NominalPUSCH ::= INTEGER (-126..24) [-85]
| | | +-alpha ::= ENUMERATED [al08]

| | | +-p0-NominalPUCCH ::= INTEGER (-127..-96) [-117]
| | | +-deltaFList-PUCCH ::= SEQUENCE
| | | | +-deltaF-PUCCH-Format1 ::= ENUMERATED [deltaF0]
| | | | +-deltaF-PUCCH-Format1b ::= ENUMERATED [deltaF3]
| | | | +-deltaF-PUCCH-Format2 ::= ENUMERATED [deltaF0]
| | | | +-deltaF-PUCCH-Format2a ::= ENUMERATED [deltaF0]
| | | | +-deltaF-PUCCH-Format2b ::= ENUMERATED [deltaF0]
| | | +-deltaPreambleMsg3 ::= INTEGER (-1..6) [4]
| | +-ul-CyclicPrefixLength ::= ENUMERATED [len1]
| +-ue-TimersAndConstants ::= SEQUENCE
| | +-t300 ::= ENUMERATED [ms1000]
| | +-t301 ::= ENUMERATED [ms1000]
| | +-t310 ::= ENUMERATED [ms1000]
| | +-n310 ::= ENUMERATED [n1]
| | +-t311 ::= ENUMERATED [ms1000]
| | +-n311 ::= ENUMERATED [n1]
| +-freqInfo ::= SEQUENCE [00]
| | +-ul-CarrierFreq ::= INTEGER OPTIONAL:Omit
| | +-ul-Bandwidth ::= ENUMERATED OPTIONAL:Omit
| | +-additionalSpectrumEmission ::= INTEGER (1..32) [1]
| +-mbsfn-SubframeConfigList ::= SEQUENCE OF OPTIONAL:Omit
| +-timeAlignmentTimerCommon ::= ENUMERATED [sf750]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit



3.3 LTE ATTACH PROCEDURE

Abbreviations
AKA (Authentication and Key Agreement)
AMBR (Aggregated Maximum Bit Rate)
ASME (Access Security Management Entity)
EMM (EPS Mobility Management)
ECM (EPS Connection Management)
ESM (EPS Session Management)
EPS (Evolved Packet System)
GUTI (Global Unique Temporary Identifier)
HSS (Home Subscriber Server)
IMSI (International Mobile Subscriber Identity)
MM (Mobility Management)
MME (Mobility Management Entity)
NAS (Non Access Stratum)
NAS-MAC (Message Authentication Code for NAS for Integrity)
TAI (Tracking Area Identity)
UE (User Equipment)

System Architecture Overview

Attach Procedure
RACH
RRC Setup
Authentication
E-RAB

Initial Attach Procedure

IMSI Acquisition
the MME obtains an IMSI from
the UE. The UE attempts to
initially attach to the network
by sending an Attach
Request message, with its IMSI
in it, and the MME obtains the
IMSI from the message. For
the purpose of explanation, this
step can be further divided into
two sub-steps:
1) the UE stays in the initial

state after radio link
synchronization, and
2) the UE establishes ECM

connection for delivering
an Attach Request message to
the MME. The ECM connection
establishment phase can be
further divided into two sub-
phases: (1) RRC connection
establishment, and (2) S1
signaling connection
establishment.

IMSI Acquisition (contd)
Initial State after Radio Link
Synchronization
In order for a UE to request initial
attach to a network, communication
with an eNB is essential. So, the UE
selects an eNB (cell) through PLMN
selection and cell search procedures,
and has the radio link synchronized
(PLMN selection and cell search
procedures are out of the scope of this
document, and thus will not be
covered here). Then, the user can
communicate with the eNB. At this
time, the UE is in EMM-Deregistered,
ECM-Idle, and RRC-Idle state.

ECM Connection Establishment
On NAS layer, the UE sends an Attach
Request (including IMSI and UE
Network Capability) message to
request initial attach to the NAS layer
of the MME.
In order for the Attach
Request message to be delivered, ECM
connection is required between the UE
and the MME. And for the ECM
connection, RRC connection between
the UE and the eNB, and S1 signaling
connection between the eNB and the
MME are required. NAS messages are
sent as RRC messages (RRC Connection
Setup Complete message) when
passing through the RRC connection,
and then as S1AP messages (Initial UE
Message) through the S1 signaling
connection.

(1) RRC Connection Establishment
An RRC connection is established between the RRC layers of the UE and the
eNB. Once established, the connection is used when delivering messages to
the RRC layers or their upper layers, NAS layers, in the control plane. The
procedure for establishing an RRC connection is as follows:
1) [UE eNB] RRC Connection Request

An UE requests an RRC connection by sending an RRC Connection
Request (Establishment Cause=Mobile Originating
Signaling) message to an eNB. The Mobile Originating Signaling is a
value used in the Establishment Cause field when a UE requests
Attach, Detach or TAU (Tracking Area Update). The message sent by
the UE is delivered to the eNB through SRB 0, the SRB (Signaling
Radio Bearer) used by all UEs in a cell, and CCCH (Common Control
Channel), a logical channel.
2) [UE eNB] RRC Connection Setup

The eNB allocates a SRB (SRB1) dedicated to the UE by sending the
UE an RRC Connection Setup message, which is delivered through
SRB 0 and CCCH. The uplink/downlink radio resources of the UE are
controlled by the eNB. So, after completing this step, the UE can use
the radio resources by using the SRB configuration allocated through
the RRC Connection Setup message. Then it transits to EMM-
Deregistered, ECM-Idle and RRC-Connected state.
3) [UE eNB] RRC Connection Setup Complete

The UE notifies the eNB that the RRC connection setup is completed by
sending it an RRC Connection Setup Complete message through
SRB 1 and DCCH (Dedicated Control Channel). For efficient delivery,
the Attach Request message1 that was delivered to the NAS layer is
sent to the eNB when delivering the RRC Connection Setup
Complete message, as embedded in the Dedicated NAS Information
field (DedicatedInfoNAS) of the RRC Connection Setup
Complete message.

Random Access Procedure
UE picks one of the 64 RACH

preambles available in an LTE cell. The
preambles are generated from Zadoff-
Chu sequences.
The terminal initiates a new
session with the randomly
selected
preamble. The message
identifies the UE with RA-
RNTI.
UE

Random Access Procedure
The eNodeB responds to the

preamble with the "Random
Access
Response" message on the DL-
SCH. The message addresses
the UE
with a RA-RNTI but the
message also assigns a
Temporary C-RNTI.
The message also sends a
timing adjustment to correct
the uplink timing
from the UE. Optionally, the
message may assign resources
to the
terminal for uplink
transmission.
UE

RRC Connection Establishment
The UE uses a UL-SCH

allocation to send the RRC
Connection Request
message. The UE is identified
by the C-RNTI that was
assigned in the
Random Access Response
message. The message
contains a UE
identity (typically S-TMSI:
MMEC+M-TMSI). The message
also includes
the establishment cause for the
RRC connection.
UE

eNodeB responds with an RRC

Connection Setup message on
the
DL-SCH. The message creates
the signaling radio bearer (SRB)
in
Acknowledged mode. The
message also contains
configuration
parameters for uplink RLC, UL-
SCH, Power Head Room (PHR)
and
Uplink Power Control.
UE

The UE signals the setup of the

RRC connection. The message
is also
used to initiate the Attach
procedure by sending the
Attach Request as
NAS Payload. The attach
message contains the old GUTI
(Globally
Unique Temporary Identifier).
UE

RRC Connection Request

RRC Connection Setup



RRC Connection Setup Complete

RRC Connection Setup Complete

(2) S1 Signaling Connection Establishment (3) ECM S1 Connection Establishment
Control messages between the eNB and the MME are sent over S1-MME Through Steps (1) and (2) above, the ECM connection between the
interface as embedded in S1AP messages. S1AP messages are delivered NAS layers of the UE and the MME is established. Then, the UE
through S1 signaling connections dedicatedly established for each user. The transits to EMM-Registered2, ECM-Connected and RRC-
S1 signaling connections are defined by an ID pair (eNB UE S1AP ID, MME Connected state.
UE S1AP ID) allocated by the eNB and the MME for identifying UEs.
In Figure on page 50, an Attach Request message, the first NAS message,
(4) IMSI Acquisition
arrives at the eNB before S1 signaling connection is established. The eNB
then allocates an eNB UE S1AP ID for establishment of S1 signaling The NAS layer of the MME acquires the IMSI of the UE from
connection, and sends the MME an Attach Request message, as embedded the Attach Request message sent from the NAS layer of the UE,
in an Initial UE Message. The Attach Request message is delivered as and finds out the UEs security capability by learning what security
embedded in the NAS-PDU field of the Initial UE Message. The Initial UE algorithms the UE can use from the UEs network capability
Message consists of the following information elements: information.
After collecting the UEs IMSI and security capability information

from the Attach Request (IMSI, UE Network Capability) message
received from the UE, the MME performs the authentication and
NAS security Setup procedures for secured delivery of NAS
messages, by using the collected information, and in accordance
with the EPS-AKA (Evolved Packet System-Authentication and Key
When the MME receives the Initial UE Message from the eNB over S1-MME, Agreement)
it allocates an MME S1AP UE ID for the UE. Now with this newly allocated ID
and the previously allocated eNB UE S1AP ID, S1 signaling connection
between the two entities are established. The MME UE S1AP ID is used later
when the MME identifies UEs over S1-MME interface (Downlink).

IMSI Acquisition Request

IMSI Acquisition Respond

Authentication
Procedure for Authentication

Authentication (Authentication Request)

Authentication (Authentication Respond)

NAS Security Setup
Procedure for NAS Security Setup

NAS (Security Mode Command)

NAS (Security Mode Complete)

Integrity Protected & Ciphered Message




UE capability report
UE EUTRAN
UECapabilityEnquiry
UECapabilityInformation

UE Capability Enquiry
As the diversity of mobile services gets wider, Network needs to know exact capability of a UE to provide proper services
for each UE. For example, what if network triggers an interRAT handover to a UE which does not support that capability ?
It would lead to communication drop.
In case of WCDMA, Network can figure out all the details of UE capability during RRC Connection Setup Complete
message since UE report all the details of its capability in RRC Connection Setup Complete message. However, LTE
RRC Connection Setup Complete message does not carry this kind of information. In stead, LTE designed a new
message dedicated for investigating UE capability. This is the role of UE Capability Enquiry and UE Capability
Information message.
Following is one example of ue-CapabilityRequest message and this is saying "Report all of your LTE capability and UTRA
capability".
DL-DCCH-Message ::= SEQUENCE

+-c1 ::= CHOICE [ueCapabilityEnquiry]
+-ueCapabilityEnquiry ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [c1]
+-c1 ::= CHOICE [ueCapabilityEnquiry-r8]
+-ueCapabilityEnquiry-r8 ::= SEQUENCE [0]
+-ue-CapabilityRequest ::= SEQUENCE OF SIZE(1..maxRAT-Capabilities[8]) [2]
| +-RAT-Type ::= ENUMERATED [eutra]
| +-RAT-Type ::= ENUMERATED [utra]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit

UE Capability Enquiry

UE Capability Information
UE Capability Information is an RRC message that UE sents to Network (in most case during initial registration process).
It informs on all the details of its capabilities. As LTE release goes higher and more features are added, UE Capability
Information has become the longest and most complicated Radio Message.
Since the message is too long and too complicated, it would be tricky to describe all of the contents in the single page.
So I would split the message into a couple of categories as shown below and post separate pages for each of the
categories. Try to get the high level understandings of UE capability information message and refer to following pages for
the details.
In some case, we spend pretty much time and effort to troubleshoot something which is not supported by UE. So I
recommend you to check before troubleshoot (especially for radio stack issue). Followings are some of the RRC
message and IEs you can get UE capability information.
Note 1 : Take this as a guideline but don't trust too much. Sometimes UE information says 'Supported' but in reality does not
working correct. Sometimes UE information does not mention something 'supported' but seems to work.
Release 8 FDD LTE, I see most of features are pretty mature and most of functions would work as expected, but Rel 8 TDD
LTE and Rel 9 or higher both FDD and TDD I strongly recommend you to check on all these information before you test. Also it
would be a good idea to check these information first before you test anything on Measurement, InterRAT.
Sample Complete UE Capability Information

UE Capability Information

UE Capability Information (contd)

UE Capability Information (contd)

Location Update
Once the procedures for authentication and NAS security setup are 1) [MME HSS] Notifying UE Location
completed, now the MME has to register the subscriber in the The MME sends an Update Location Request (IMSI, MME ID) message to
network, and find out what services the subscriber can use. To this the HSS in order to notify of the UEs registration and obtain the subscription
end, the MME notifies the HSS the subscriber is registered in the information of the UE.
network and located in its TAs, and then downloads information
about the subscriber from the HSS. All these are done through the
location update procedure, and by using Diameter protocol over the 2) [HSS] UE Location Update
S6a interface between the MME and the HSS. The HSS registers the MME ID to indicate in which MME the UE is located in.
3) [MME HSS] Delivering User Subscription Information

The HSS sends the MME subscription information of the subscriber as included
in an Update Location Answer message, so that the MME can create an EPS
session and a default EPS bearer for the subscriber. The subscription
4) [MME] Storing Subscription Information
information included in the Update Location Answer message is as follows:
The MME receives the Update Location Answer message from
the HSS, and stores the subscription information from the
message.
From the downloaded subscription information, the MME can check

what services the user is subscribing to, and to which APN and with
what QoS level the resources are to be allocated.

EPS Session Establishment
The MME, based on the subscription information,
establishes an EPS session and a default EPS bearer for
the user. By doing so, the MME allocates the
network/radio resources for providing each user with
satisfying QoS they are subscribing to.
1) [MME] Assigning EPS Bearer ID

The MME selects a value from 5~15, and allocates it as
an EPS Bearer ID (EBI) in order to establish a default
EPS bearer for the newly attached user.
2) [MME] Selecting P-GW

The MME checks the APN received from the HSS, and
decides to which P-GW to connect to access the APN.
This decision can be made based on the subscription
information received from the HSS (specifically, P-GW
ID). Or if there is no such information, the MME queries
the DNS server for APN FQDN (e.g.
internet.apn.epc.mnc05.mcc450.3gppnetwork.org), and
selects one from the returned P-GW IP address list in
accordance with its P-GW selection policies6. At this time,
it also chooses which S-GW to go through to get the
selected P-GW.
3) ~ 4) Request for EPS Session Creation

The MME requests creation of an EPS session and a
default EPS bearer by sending a Create Session
Request message to the P-GW selected in Step 2)
above. Here, the MME includes the subscription
information it received from the HSS in the message, so
that the P-GW can use it when requesting PCRF for EPS
session creation. At this time, UE-AMBR is not included
as it is to be determined by the MME.
Procedure for EPS Session Establishment (1)

EPS Session Establishment (contd)
3) [MME S-GW] Request for EPS Session Creation
The MME and the S-GW communicate over S11
interface in the control plane using GTP protocol (GTP-
C). The MME sends the S-GW selected in Step 2)
a Create Session Request message, with the following
parameters:
4) [S-GW P-GW] Request for EPS Session Creation

The S-GW and the P-GW communicate over S5 interface
in the user and control planes using GTP protocol (UP:
GTP-U, CP: GTP-C). The S-GW allocates a downlink S5
TEID (S5 S-GW TEID) to establish S5 GTP to the P-GW
indicated in the received Create Session
Request message. Then, it sends the ID along with other
parameters, as included in the Create Session
Request message, to the P-GW
5) [S5 Bearer: Downlink]

Once Step 4) is completed, the downlink S5 GTP-U
tunnel is created, allowing the P-GW to send downlink
traffic to the S-GW. In Figures 7 and 8, the entity that
allocates and sends a GTP tunnel TEID is marked as fill
(), and the one that receives it is marked as empty ().


6) [P-GW] Allocating User IP Address
The P-GW, upon receiving the Create Session
Request message, realizes the user is attempting to
access the network again with IMSI. So, it allocates an IP
address to the UE so that the UE can use it when using
APN.
7) [P-GW PCRF] Notifying of EPS Session Setup

The P-GW and the PCRF communicate over Gx interface
using Diameter protocol. When creating an EPS session
for a user, resources allocation and QoS control for the
user must be determined based on the services that the
user is subscribing to. It is PCRF that is in charge of
controlling policies concerning all the users who
accessed to the network. So, the P-GW provides the
PCRF with subscription information about the user, and
obtains the PCRFs authorization for resources allocation
in accordance with the network operators policies. From
the UEs subscription information received from the MME,
the P-GW gathers information required for the PCRFs
decision-making on the operators policies, and sends it
to the PCRF through a CCR (CC-Request) message. An
example of the message is as follows:


8) [PCRF SPR] Requesting Access Profiles
The PCRF requests the SPR for the users access profile to
determine PCC policies for the user.
9) [PCRF SPR] Returning Access Profiles

The SPR returns an access profile for the user. The profile
may include information such as SDF Filter, QCI, ARP,
APN-AMBR (UL/DL), Charging Method (e.g. Offline),
Changing Reporting Action (e.g. Start Reporting ECGI, TAI),
etc.
10) [PCRF] Determining Policies

The PCRF determines PCC policies for the EPS session to
be established based on the user access profile.
11) [P-GW PCRF] Acknowledging EPS Session

Establishment
The PCRF delivers the PCC policies determined in Step 10)
to the P-GW, as included in a CCA (CC-Answer) message.
An example of the message is as follows:
12) [P-GW] Policy Enforcement

The P-GW applies the PCC policies received from the
PCRF. As the PCC policies are applied to each SDF, the P-
GW sets up mapping between SDFs and the EPS bearer,
and prepares a QoS profile to be applied to the default EPS
bearer (see our technical document, LTE QoS: SDF and
EPS Bearer QoS[5] for more information).


13) ~ 15) EPS Session Creation Response
The P-GW informs the MME of the QoS information applied
to the established EPS sessions and default EPS bearer, by
sending it in a Create Session Response message. The
PCRF may decide to keep the value the MME received from
the HSS, or select a new value.
13) [S-GW P-GW] EPS Session Creation Response

The P-GW allocates an uplink S5 TEID (S5 P-GW TEID) for
establishing S5 GTP to the S-GW. It then includes the S5 P-
GW TEID and the QoS profile to be applied to the default
EPS bearer (S5 bearer) in the Create Session
Response message, and sends it to the S-GW as a
response to the Create Session Request message
received in Step 4).
14) [S5 Bearer: Uplink] S5 Bearer Established

Completing Step 13) establishes the uplink S5 GTP-U
tunnel, allowing the S-GW to exchange uplink/downlink
traffic with the P-GW.
15) [MME S-GW] EPS Session Creation Response

When receiving the Create Session Response message
from the P-GW, the S-GW keeps the uplink S5 TEID (S5 P-
GW TEID) to be used for uplink traffic, and allocates an
uplink S1 TEID (S1 S-GW TEID) of S1 GTP tunnel to be
used for S1 bearer. After processing the message, the S-
GW adds the newly allocated S1 S-GW TEID to the
processed message, and sends it to the MME as a
response to the Create Session Request message it
received in Step 3).

16) [MME] Why MME Keeps S5 P-GW TEID?
Once attached to a network, if a UE performs a TAU or
handover, its S-GW may be changed. For this reason, the
MME informs the UEs new S-GW of the uplink S5 TEID so
that the new S-GW can deliver uplink traffic to the P-GW.
17) [S1 Bearer: Uplink]

Completing Step 15) establishes the uplink S1 GTP-U
tunnel. However, since the eNB does not have this value
(S1 S-GW TEID) yet, it cannot deliver uplink traffic to the S-
GW at this time.
18) [MME] Calculating UE-AMBR

Now, the MME returns an Attach Accept message to the
UE as a response to the Attach Request message, and
prepares for E-RAB setup (i.e. for allocating resources to
radio link and S1 bearer) by controlling the eNB. For this,
the MME calculates the UE-AMBR value to send to the
eNB. The MME has already received the UE-AMBR value,
as included in subscription information, from the HSS in
Section 2.4 above. However, it can adjust the value to the
extent not exceeding the total APN-AMBR of each APN, and
allocates it instead.


19) Determining Information needed for E-RAB and NAS
Signaling
By receiving the Create Session Response message from
the P-GW, the MME learns resources have been approved
and allocated to the user. Then, it becomes in charge of E-
RAB (DRB+S1 bearer) setup, and controls the eNB and the
S-GW. To this end, it determines the resources required for
E-RAB setup and the information needed for NAS signaling
(Attach Accept) as follows:
Allocating a GUTI that the UE can use instead of the IMSI
Determining parameters related to controlling TAU (TAI list
allocation, TAU Timer value)
Determining UE-AMBR for the eNBs use
Allocating an E-RAB ID
20) [UE MME] Attach Accept
The MME includes information, such as the UE IP address
allocated by the P-GW, the GUTI, TAI list, EPS Bearer ID,
UE-AMBR values allocated by itself, and QoS parameters
received from the S-GW, in the Attach Accept message8,
and sends it to the UE as a response to the Attach
Request message received in Section 2.1.
This message is delivered as included in the Initial Context
Setup Request message through the S1 signaling
connection, and then in the RRC Connection
Reconfiguration message through the RRC connection.
21) [MME] Creating KeNB
The MME creates KeNB, the AS security base key, from
KASME. This is to ensure the eNB can generate AS security
keys to be used for secured communication between the
eNB and the UE over radio link (i.e. for AS security setup).

22) [eNB MME] Requesting E-RAB Setup
The MME sends an Initial Context Setup
Request message so that the eNB can establish S1 bearer
with the S-GW, and DRB with the UE. The Initial Context
Setup Request message consists of the following
information elements:
23) [S1 Bearer: Uplink]

Once Step 22) is completed, and the S1 S-GW TEID is
obtained, the eNB can deliver uplink traffic to the S-GW.
When the eNB receives the MMEs Initial Context Setup

Request message that requests E-RAB setup, it sets up
DRB by sending an Attach Accept message to the UE.
Then, it completes S1 bearer setup by including a downlink
S1 TEID in the Initial Context Setup Response message,
and sending the message as a response to the Initial
Context Setup Request message to the MME, so that the
MME can forward it to the S-GW.

24) ~ 27) AS Security Setup
Upon receiving the MMEs Initial Context Setup
Request message, the eNB attempts to communicate with
the UE to set up DRB. To ensure secured communication
over the radio link, the eNB performs the procedure for AS
security setup before sending messages to the UE (see our
technical document, LTE Security II: NAS and AS Security
[3] for more information).
24) [eNB] Generating AS Security Keys

The eNB generates AS security keys from KeNB received
from the MME for safe delivery of RRC messages and user
traffic to/from the UE. The eNB selects ciphering and
integrity algorithms for RRC messages from the security
algorithms that the MME forwarded for the UE, and
ciphering algorithms for user traffic. Next, from KeNB, it
derives KRRCint/KRRCenc, RRC integrity/ciphering keys, and
KUPenc, a key for ciphering user traffic.
25) [UE eNB] Helping UE to Generate AS Security Keys

The eNB helps the UE to generate AS security keys (KRRCint,
KRRCenc and KUPenc) by informing the UE of the AS security
algorithms it selected (i.e. control plane RRC
integrity/ciphering algorithm and user plane ciphering
algorithm) through a Security Mode Command (AS
Security Algorithm, MAC-I) message. The eNB sends this
RRC message with its integrity-protected (by including
MAC-I).

AS Setup (Security Mode Command)

AS Setup (Security Mode Complete)

26) [UE] Generating AS Security Keys
Upon receiving the Security Mode Command message
from the eNB, the UE generates AS security keys using the
AS security algorithm that the eNB selected, and performs
integrity check on the Security Mode Command message.
27) [UE eNB] AS Keys Generation Complete

Once the integrity check on the Security Mode
Command message is completed, AS security keys are
successfully set up and ready to work between the UE and
the eNB. The UE then indicates to the eNB that AS security
keys are generated by sending a Security Mode
Complete (MAC-I) message. The UE sends the message
with its integrity-protected by using the RRC integrity key.
As the AS security setup over the radio link is ended, RRC

messages exchanged over the radio link thereafter are sent
as encrypted and integrity-protected, and user traffic is
delivered as encrypted. Now, the eNB begins DRB
establishment.
28) ~ 29) DRB Establishment

28) [UE eNB] Reconfiguring RRC Connection
The eNB allocates uplink/downlink DRB IDs, and configures
DRB QoS parameters from E-RAB QoS in order to establish
DRB, an EPS bearer over the radio link. Thereafter, it sends
a RRC Connection Reconfiguration message to the UE
through the secured RRC connection. The RRC connection
was already established when the UE sent the Attach
Request message. However, it must be reconfigured now
that the UE needs to configure parameters according to the
resources allocated by the network as a result of permission
to access the network. The RRC layer of the UE allocates
radio resources based on the configuration parameters
gathered from the RRC Connection
Reconfiguration message. Next, it extracts an Attach
Accept message from the RRC Connection
Reconfiguration message, and sends it to the NAS layer.
When the NAS layer of the UE receives the message, it

obtains the UE IP address and GUTI from the message, and
uses them for future communication.
29) [DRB Establishment: Uplink and Downlink] DRB

Establishment Complete
Once Step 28) is completed, and the UE can deliver
uplink/downlink traffic from/to the eNB.
[eNB S-GW] E-RAB Setup Response

The eNB allocates a downlink S1 TEID (S1 eNB TEID) for
S1 bearer. Then it includes the allocated ID in an Initial
Context Setup Response message, and sends it to the
MME as a response to the Initial Context Setup
Request message received in Step 22), so that the MME
can forwards it to the S-GW.
31) [eNB] Allocating a Downlink TEID for S1 Bearer
Once Step 29) is completed, a downlink TEID is allocated by the eNB to
S1 bearer, establishing the downlink S1 GTP-U tunnel. However, since
the S-GW does not know about the establishment yet, it cannot delivery
downlink traffic to the eNB at this time.
32) [UE MME] Sending Attach Complete Message

The UE sends an Attach Complete message9 to the MME, as a
response to the message in Step 20). The Attach Complete message is
delivered through an UL Information Transfer message over the RRC
connection, and then through an Uplink NAS Transport message over
the S1 signaling connection.
33) [UE][MME] EMM State

Now the UE and the MME stay in EMM-Registered state. If an Attach
Reject message is sent from the MME to the UE in Step 20), the UE
must release the ECM/RRC connection and transit to EMM-Deregistered
state.
34) [MME S-GW] Requesting S1 Bearer Modification

The MME forwards the downlink S1 TEID (S1 eNB TEID) received from
the eNB to the S-GW through a Modify Bearer Request message.
35) [MME S-GW] Responding to S1 Bearer Modification Request

The S-GW sends the MME a Modify Bearer Response as a response
to the Modify Bearer Request message. Now, the S-GW is ready to
deliver downlink S1 traffic.
36) [S1 Bearer: Downlink] S1 Bearer Setup Complete

Step 35) completes the setup procedure for S1 bearer. With the
establishment of S1 bearer, the eNB and the S-GW can exchange traffic
with each other. Now, the default EPS bearer from the UE all the way to
MobileComm
the P-GW is finally established, allowing Professionals,
uplink/downlink EPSIncbearer
Procedure for EPS Session Establishment (2) communication between the UE and the P-GW.
RRC Connection Reconfiguration

RRC Connection Reconfiguration (contd)

RRC Connection Reconfiguration Complete
Attach
Complete

EPS Entity Information (Before Initial Attach)
UE ID information: A users IMSI is provisioned at UE, HSS and SPR.

UE Location information: No information about UE location is registered at UE or anywhere
in the network.
Security Context information: An LTE master key to be used for user authentication is
commissioned at UE and HSS.
EPS Session/Bearer information: User subscription information (Default APN, Subscribed
QCI, ARP, UE-AMBR, APN-AMBR, etc.) and user access profile (Subscribed QCI, ARP,
APN-AMBR, etc.) are provisioned at HSS and SPR, respectively.

EPS Entity Information (After Initial Attach)

Attach Fail Case
BOLT in Weak Coverage
Smartfren in Weak Coverage

PLMN List INDONESIA
Remarks:
1) Internux PLMN (510-88) and First Media PLMN (510-68)
2) During Drivetest Samsung Galazy Note 4 can get Radio Resource Connection to PLMN 51009
(Smartfren TD-LTE BC 40)

LTE Security Concept

Attach as Unknow User (MME View Point)
BOLT IMSI
UE BOLT eNB TSEL MME TSEL UE BOLT eNB SF MME SF

RRC CONN SETUP REQ RACH RRC CONN SETUP REQ
RACH
RRC CONN SETUP
RRC CONN SETUP REQ
RRC
RACH
RRC CONN SETUP COMP
INITIAL UE MESSAGE
RRC CONN SETUP REQ
RACH
Authetication
ATTACH RESPOND
ATTACH REJECT
RRC CONN RELEASE
Normal Release
RF Bolt Weak, RF TELKOMSEL Strong RF Bolt Weak, RF SMARTFREN Strong
Remarks:
1) Since QRxLevMin Smartfren (-130 dBm) lower than BOLT, BOLT User will be easily to enter RRC
Resource Smartfren when BOLT RSRP lower than -120 dBm
2) Since QRxLevMin Telkomsel (-128 dBm) lower than BOLT, BOLT User will be easily to enter RRC
Resource Telkomsel when BOLT RSRP lower than -120 dBm MobileComm Professionals, Inc

Case 1 (RF Bolt Weak, RF SMARTFREN Strong)
RF Condition
Smartfren
Remarks:
1) When BOLT Coverage bellow than -120 dBm,


Smart
Fren
CellSell Thd: -130 dBm





Case 2 (RF Bolt Weak, RF Telkomsel Strong)

Case 2 (RF Bolt Weak, RF Telkomsel Strong)
RRCConnectionRequest
RACH Fail

Attach Fail Case
BOLT in Weak Coverage
Smartfren in Weak Coverage

Signaling Flow Smartfren UE with no PLMN Black List
SMARTFREN
IMSI
UE SF eNB BOLT MME BOLT

RACH RRC CONN SETUP REQ
RRC CONN SETUP

RRC
RRC CONN SETUP COMP
INITIAL UE MESSAGE
Authetication
ATTACH RESPOND
ATTACH REJECT
RRC CONN RELEASE
Normal Release
Unlocked PLMN
Remarks:
1) Smartfren IMSI always retry to attach with BOLT Core Network every time there is no good LTE
Coverage on Smartfren Network.
2) This phenomena can causing RRC License Congestion on BOLT Network, when other LTE operators
consume Radio Resource of BOLT. MobileComm Professionals, Inc

DL EARFCN
Smartfren IMSI : 510098850797315

RSRP

SINR

L3 Message
Case 1
Case 2

RRCConnectionRequest [Case 1]
Note:
After Radio Condition of
Smartfren really drop, its
detect BOLT LTE Network
with New TAC Information.
UE will check the TAC under

last TAL Information which
is registered previous. After
UE read this new TAC is not
include on previous TAL, UE
initiate to do Tracking Area
Update together with RRC
Connection Process.

RRCConnectionSetupComplete [Case 1]
Note:
In this case, UE try to
Reporting its new BOLT TAC
which is not include in last
Smartfren TAL with RRC
Setup Complete Message

DLInformationTransfer (Attach Reject) [Case 1]
Note:
In this case, BOLT Network
Reject this specific IMSI due
to Tracking area update fail
(TUF)

RRCConnectionRelease [Case 1]
Note:
to Tracking area update fail
(TUF)

RRCConnectionRequest [Case 2]
Note:
After RRC Normal Release in
the first case UE in the idle
mode retry in the second
time to enter BOLT
Network.

RRCConnectionSetupComplete [Case 2]

DLInformationTransfer (EMM Identity Request) [Case 2]
Note:
BOLT Network Required
Identiy Information (IMSI)

ULInformationTransfer (EMM Identity Response) [Case 2]
Note:
UE Respond with IMSI
Number to the BOLT
Network

DLInformationTransfer (Attach Reject) [Case 2]
Note:
to No Suitable Cells In
Location/tracking Area

RRCConnectionRelease [Case 2]
Note:
to No Suitable Cells In
Location/tracking Area

Raw Data
LTE_RRCC LTE_RRCC LTE_RRCC

LTE_UE_E onnectio onnectio onnectio LTE_UE_P LTE_UE_P LTE_UE_P
Longitud ARFCN_D nAttemp nSetupO nSetupFa LTE_UE_P LTE_UE_R LTE_UE_P ower_Tx ower_Tx ower_Tx
Message Time Distance e Latitude L t K il CI SRP LTE_UE_CINR ower_Tx _PUCCH _PUSCH _PRACH
24076 Oct/21/15 19:42:21 106.8914 -6.11021 39475 1 1 0 206 -100.7 15.2 22
24156 Oct/21/15 19:42:24 106.8911 -6.1102 39475 1 1 0 206 -101.1 14.15 10.9 21.8 15
29353 Oct/21/15 19:48:46 791.6877 106.8809 -6.11587 39475 1 1 0 373 -113.9 8.4
29396 Oct/21/15 19:48:47 795.7872 106.8809 -6.1159 39475 1 1 0 373 -111.5 7 23 23 23
132560 Oct/21/15 22:05:31 1322.429 106.866 -6.13658 39475 1 1 0 460 -77.5 7.2 2.25 -3 7.5 -9
132651 Oct/21/15 22:05:34 1352.76 106.8659 -6.13622 39475 1 1 0 460 -79.15 7 -4.52 -11.8 5.5 -11
141066 Oct/21/15 22:22:31 151.2775 106.8578 -6.13908 39475 1 1 0 232 -87.4 20.1 0
141152 Oct/21/15 22:22:34 158.496 106.8578 -6.13901 39475 1 1 0 232 -85.35 19.55 0.25 0.5 -2

DL EARFCN (Black List PLMN in SF IMSI)

RSRP (Black List PLMN in SF IMSI)

RSRP (Black List PLMN in SF IMSI)

RRC Status

RRC Status

Summary
Test result showing BOLT Network always allowed another PLMN Sim Card to do
attach network with no limitation/penalty. This process will happen on RRC Attempt in
BOLT Network and also will make RRC Connected License Congestion Problem.
On Last status BOLT Device Team and BOLT Core Network Team already find the
solution to mitigate RRC Attempt from Illegal IMSI with change configuration of Attach
Reject Reason with PLMN Not Allowed. This Rejection will give penalty to this IMSI,
then with automatic process on the UE, this Sim Card will write this PLMN Identity as
Forbidden List.
Core Part HUAWEI License Required:
82203886 Regional Roaming Restriction OFF >> ON

Summary
No Suitable Cells in TA #15 as attached, Based on 3GPP TS22.011, sim card
automatically update EF-Forbid PLMN if UE receive PLMN Not Allowed.

3.4 LTE RANDOM ACCESS PROCEDURE

Random Access Preamble Format Decision
The random access procedure is used in various scenarios, including initial access, handover, or re-
establishment. Like other 3GPP systems the random access procedure provides a method for contention
and non-contention based access. The PRACH (Physical Random Access Channel) includes RA (Random
Access) preambles generated from ZC (Zadoff-Chu) sequences.
There are five preamble formats defined which four of them are for FDD

Random Access Preamble Format Decision (Contd)
Other preamble formats then Format 0 and Format 4 (TDD) are available only with the LOFD-001009 Extended
Cell Access Radius feature.

U2000 Parameter

Preamble Format & PRACH Configuration Index

SIB2 Information PRACH Config Idx

Config Index

Root Sequence Index Planning
* in fact, with the lowest configuration,

where we assume maximum cell radius of
790m we assign only one value per cell.
Further explanation on following slides.

PRACH Parameters
PRACH configuration is defined by the following parameters

Root sequence, setting in the eNodeB
Ncs: Automatically setting based on the cell radius configuration
PRACHfrequency offset: Scheduled by eNodeB
High speed flag: Indicate whether the cell is for high speed
All the parameters all carried by SIB Type 2

NCS Selection

Calculation Max Cell Radius for given Ncs

Table Calculation

Ncs Selection Example

Overview
Initial RRC connection setup
Random access preambles are generated by UEs, and conflicts may exist
among these preambles. The eNodeB uses a contention resolution mechanism
Contention Based to handle such a conflict. In addition, this type of access is also used in RRC connection reestablishment
Downlink Data Arrival and Handover Scenario when the dedicated
preambles allocated by the eNodeB are exhausted
Uplink data arrival
Downlink data arrival
Random access preambles are allocated by the eNodeB, and each preamble is
Non-Contention dedicated to only one UE. Therefore, there is no preamble conflict. Non- Handover
Based contention-based random access is invariably used in LCS scenario
location service (LCS)

Overview
Contention Based Non-Contention Based
eNodeB assigns UE dedicated preamble, signaled via HO command

Random Access Preamble on RACH in uplink, UE Select Preamble or PDCCH order
group based on size of Msg3 and pathloss
UE transmits the assigned non-contention Random Access
Random Access Response generated by MAC on DL-SCH, semi- Preamble
syncrounous, no HARQ, addressed to RA-RNTI with RA-preamble
identification, TA information, initial Uplink Grant, TC-RNTI Random Access Response on DL-SCH, addressed to RA-RNTI,
no HARQ with TA information, initial UL grant (for HO), RA
First scheduled UL transmission on UL-SCH for initial access (RRC
connection Request), RRC connection Re-establishment, RRC HO Preamble identifier
confirm (RRC connection Reconfiguration Complete)
Contention Resolution on DL

PRACH Overview
SIB2
Preamble Grouping
Preamble Generation
(Code Domain)
Time Domain Position
Frequency Domain Position

PRACH Overview
64 preamble (total preamble in cell)
Contention Based Preamble Dedicated Preamble
Group A Preamble Group B Preamble
Group B Preamble, is selected by UE if :

size of Msg3 > messageSizeGroupA, AND
Pathloss < Pcmax preambleInitialReceiveTargetPower
deltaPreambleMsg3 - messagePowerOffsetGroupB
SizeofRA-PreamblesGroupA numberofRA-Preambles
messageSizeGroupA

PRACH Overview
PRACH resource size in frequency domain is 6 RBs

prach-FreqOffset indicates the offset to the starting position of
PRACH in frequency domain
PUCCH Resource
FDD
PUSCH Resource
System
Bandwidth
PRACH Resource TDD
6 RB
Prach-FreqOffset

PRACH Overview
prach-ConfigIndex determine how often PRACH

opportunities occure and when UE can transmit PRACH
preamble
Preamble Format : 0
SFN : Any
Subframe number : 1

PRACH Overview
fRA tRA(0) tRA(1) tRA(2)

Uplink Subframe
where Preamble
0 = First Half
0 = Every Frame Starts From the
Frequency Frame
1 = Even Frame Closest UPLINK
Resource Index 1 = Second Half
2 = Odd Frames SWITCH POINT
Frame
(*) Designates
Special Subframe
RA f RA
nPRB offset 6 2 , if f RA mod 2 0

RA
nPRB
N RB f RA
UL
6 nPRB
RA
offset 6 , otherwise
2

PRACH Overview
Example
From table value of {fRA, tRA(0), tRA(1), tRA(2)} for prach-ConfigInde 3 is {0,0,0,0}
fRA tRA(0) tRA(1) tRA(2)
0 0 = Every Frame 0 = First Half Frame 0
RA f RA
nPRB offset 6 2 , if f RA mod 2 0

RA
nPRB
N RB f RA
UL
6 nPRB
RA
offset 6 , otherwise
2
= 7
163

PRACH Overview
Total Guard
Preamble T_CP T_CP T_SEQ T_SEQ Number of Cell
Length Time
Format Subframes Radius
(in Ts) (in ms) (in Ts) (in ms) (in ms) (in ms)
0 3168 0.103 24576 0.8 0.903 1 0.097 ~ 14 km
1 21024 0.684 24576 0.8 1.484 2 0.516 ~ 75 km
2x
2 6240 0.203 1.6 1.803 2 0.197 ~ 28 km
24576
2x
3 21024 0.684 1.6 2.284 3 0.716 ~ 108 km
24576
4 448 0.015 4096 0.133 0.148
Guard Time (TGT) give maximum cell radius for LTE cell

PRACH Overview
How to Generate 64 PRACH Preamble Sequences?
Maximum number of PRACH Sequence a UE can use in a cell is 64.
1. Generate a Zaddoff Chu sequence (preamble format 1-3, 839 sequence, preamble format 4, 139 sequence) using
rootSequenceIndex base sequence
rootSequenceIndex Physical root sequence index for RSI 184
168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188
7 832 8 831 16 823 47 792 64 775 57 782 104 735 101 738 108 731 208 631 184
189 190 191 192 193 194 195 196 197 198 199 200 201 202 203
655 197 642 191 648 121 718 141 698 149 690 216 623 218 621
Generate base sequence With u = 108, 0<=n<=838

PRACH Overview
2. Generate 64 different sequence by doing cyclic shift of the base sequence. The cyclic shift interval is determined by Ncs, and Ncs
value is determined by zeroCorrelationZoneConfig and highSpeedFlag
highSpeedFlag
Ncs value determine amount of cyclic shift sample apply to root

sequence from step 1
It also determine number of root sequence requires to generate 64
preamble signature
Example:
zeroCorrelationZoneConfig = 11
highSpeedFlag = 0
#signature per root sequence = rounddown(839/93) = 9
#root sequence required = roundup(64/9) = 8
zeroCorrelationZoneConfig

PRACH Overview
Ncs value vs Cell Radius
Ncs Shift
800 ms
Length of RACH preamble is 800 ms and 839 sequence

PRACH Configuration on U2000
MOD RACHCFG
prach-FreqOffset
prach-ConfigIndex
numberofRA-Preambles
SizeofRA-PreamblesGroupA

MOD CELL
prach-ConfigIndex
Calculate Ncs value based

on Cell Radius & High rootSequenceIndex
Speed Flag parameter
highSpeedFlag

RachAdjSwitch
MOD RACHCFG enable or disable random access channel (RACH) resource adjustment
HoRaSwitch
control the random access mode applied during handovers
UnsyncRaSwitch
control the random access mode applied when UEs are out of
synchronization in the uplink
MaksIdxSwitch
control reuse of dedicated preambles between UEs
BackOffSwitch
switch for backoff control

RACH related counter
Feature/Function Load or Performance Item Formula Expected Value Range
Random access Contention-based load (L.RA.GrpA.Att + L.RA.GrpB.Att)/CounterTime -
Random access Non-contention-based load L.RA.Dedicate.PreambleReq.Num/CounterTime -
Counter ID Counter Name

1526727215 L.RA.GrpA.Att
1526727218 L.RA.GrpB.Att

Example of RACH process
INITIAL ACCESS

HANDOVER Contention Based Non-Contention Based

DL DATA ARRIVAL Contention Based Non-Contention Based

UL DATA ARRIVAL Contention Based Non-Contention Based

3.5 LTE TRACKING AREA UPDATE
PROCEDURE

Tracking Area Update Concept
TAU Procedure
The tracking area update (TAU) procedure is triggered if one of the
following conditions is met:
The UE detects that the current TA does not exist in the TA list on Internet S-GW MME
the UE-registered network.
It is a periodic TAU.
The TAU procedure is triggered during a handover procedure. UE
Under
moveOne
to new
TAL
TAL
no need
needTAU
TAU
On an EPS network, the basic unit of location management is TA
List. A TA List consists of one or multiple TAs. A TA list prevents a UE
from initiating the TAU procedure frequently. In USN1.1, a TA is TAL 1
regarded as a TA List by default. TAC 2
S-GW MME TAC 1 TAC 4

Internet
TAC 3
TAU
TAC 2 Last TAC is 8 but

UE move to TAC
TAL 2 7, MME will try
TAC 6
TAC 1 TAC 4 paging another
TAC under TAL2
TAC 5 TAC 8
TAC 3
TAC 7

Periodic Tracking Area Update
A UE, while in Connected state, has an established end-to-end
EPS bearer connecting the UE to the network (P-GW). The
network (MME) keeps track of which cell the UE is located in. So,
if there is any traffic destined to the UE, the network can deliver it
immediately.
However, if a UE enters Idle state, the signaling connection and

bearers (E-RAB bearer) between the UE and the network (MME)
are all released. Then, the network (MME) loses track of the UEs
location. The network should always be aware of the current
location of all UEs, whether in Active or Idle state, in order to
deliver traffic to UEs that are in Idle state. So, those in Idle states
should report their current location, i.e. in which TA (Tracking
Area) they are located, to the network (MME) periodically even
when there is no data to deliver. A TA is a group of cells, and
managed by MME. The location of UEs in Idle state is recognized
at a TA level.
To this end, MME provides a UE with a TAI list and TAU timer
(T3412) as included in a Attach Accept message when the UE
initially attaches the network. Using them, the UE performs a TAU
procedure upon expiration of the TAU timer.
When MME receives TA information from a UE, it updates the

UEs current location information (TA, cell) to keep the latest
information. In case there is traffic destined to the UE while it is in
Idle state, the MME informs the UE about the new traffic by
sending a Paging Message to the cells in the TA that has been
reported by the UE as its current location1.

A UE, while in Connected state, has an established end-to-end
EPS bearer connecting the UE to the network (P-GW). The
network (MME) keeps track of which cell the UE is located in. So,
if there is any traffic destined to the UE, the network can deliver it
immediately.
However, if a UE enters Idle state, the signaling connection and

bearers (E-RAB bearer) between the UE and the network (MME)
are all released. Then, the network (MME) loses track of the UEs
location. The network should always be aware of the current
location of all UEs, whether in Active or Idle state, in order to
deliver traffic to UEs that are in Idle state. So, those in Idle states
should report their current location, i.e. in which TA (Tracking
Area) they are located, to the network (MME) periodically even
when there is no data to deliver. A TA is a group of cells, and
managed by MME. The location of UEs in Idle state is recognized
at a TA level.
To this end, MME provides a UE with a TAI list and TAU timer
(T3412) as included in a Attach Accept message when the UE
initially attaches the network. Using them, the UE performs a TAU
procedure upon expiration of the TAU timer.
When MME receives TA information from a UE, it updates the

UEs current location information (TA, cell) to keep the latest
information. In case there is traffic destined to the UE while it is in
Idle state, the MME informs the UE about the new traffic by
sending a Paging Message to the cells in the TA that has been
reported by the UE as its current location1.

Connections and States before/after
TAU
(i) Before the procedure, the UE stays

in EMM-Registered, ECM-Idle and RRC-
Idle state, and any resources allocated by
E-UTRAN, i.e. the E-RAB (except for the
uplink S1 bearer) and ECM signaling
connection between the UE and the
MME, are kept released.
(ii) During the procedure, the UE stays

in EMM-Registered, ECM-
Connected and RRC-Connected state.
The periodic TAU procedure is different
from procedures for initial attach or
service request in that no E-RAB
(between UE and MME) is set up, and
only the signaling connection (ECN
signaling connection) for delivering
periodic TAU-related NAS messages is
set up during this procedure.
(iii) After the procedure, the ECM

signaling connection set between the two
entities is released, releasing the E-
UTRAN resources. Then, the UE returns
to EMM-Registered, ECM-Idle and RRC-
Idle state again.


Procedure for Periodic TAU (1)
Periodic TAU Triggering

1) [UE] TAU Timer Expiry
The UE in Idle state triggers a periodic
TAU procedure to report its current
location to the MME upon expiration of
the TAU timer (T3412).
ECM Connection Establishment)

and TA Report
The NAS layer at the UE i) configures
a TAU Request message, and ii) sends it
with RRC parameters (e.g. old GUMMEI3)
down to the RRC layer at the UE.
2), 3) [UE eNB] RRC Connection

Establishment
Upon receiving the TAU
Request message, the RRC layer at the
UE sends the eNB an RRC Connection
Request message, requesting dedicated
signaling resources. The eNB establishes
an RRC connection by allocating an SRB
channel and sending the UE an RRC
Connection Setup .

4), 5), 6) [UE MME] ECM Connection

Establishment Request and TA Report
The TAU Request message is delivered
as included in an RRC Connection
Setup Complete message, an RRC
message, from the UE to the eNB, and
then in an Initial UE Message, an S1AP
message, from the eNB to the MME. As
the NAS security context has been kept
valid between the UE and the MME,
the TAU Request message is sent
integrity-protected with the NAS integrity
key (KNASint) and encrypted with the
encryption key (KNASenc). The TAU
Request message for the periodic TAU
procedure includes the following
information:

For faster delivery of the TAU

Request message received from the NAS
layer, the RRC layer at the UE sends the
eNB the message, as piggybacked on
an RRC Connection Setup
Complete message, the last step of the
RRC connection procedures. At this time,
the RRC Connection Setup
Complete message includes a GUMMEI.
This ID is derived from the GUTI that was
received from the NAS layer, and
indicates at which MME the UE is
registered. In general, an eNB can be
connected with more than one operator
network and MME. So, upon receiving
the RRC Connection Setup
Complete message, the eNB checks
whether the indicated MME is connected
with itself or not.4
Then, the eNB sends the TAU
Request message as included in
an Initial UE Message message to the
MME. At this time, the eNB allocates an
eNB S1AP UE ID to the Initial UE
Message message, and the MME, upon
receipt of the Initial UE
Message message, allocates an MME
S1AP UE ID, setting up an S1 signaling
connection between the two entities. This
completes an ECM signaling connection
between the UE and the MME, allowing
the UE to transit to Connected state.

UE Authentication and NAS

Security Setup (Optional)
7) [UE MME HSS] UE
Authentication
The MME, upon receiving the TAU
Request message from the UE, conducts
an integrity check on the NAS-MAC. If the
check passes, the MME can skip UE
authentication, and continue to use the
NAS security context it has kept in
delivering NAS messages. If the check
fails, it has to perform UE authentication
through EPS-AKA.5
8) [UE MME] NAS Security Setup

Once the UE is authenticated in Step 7),
NAS security keys (KNASenc, KNASint) to be
used in communicating NAS messages
are generated based on a new KASME and
through a NAS security setup procedure

TA Update
9) [MME S-GW] TA Update
When the MME receives the TAU
Request message from the UE, it resets the TAU
timer (T3412), and sends the S-GW a Modify
Bearer Request message, forwarding the UEs
location information (ECGI, TAI).
10) EPS Session Modification (Optional)

The S-GW that receives the UE location
information checks whether the UEs cell (ECGI)
or TA (TAI) is changed or not. If changed, it
sends a Modify Bearer Request to the P-GW to
inform such change. Then, the P-GW reports the
same to the PCRF through an EPS session
modification procedure.6
11) [MME S-GW] Responding to TA Update

Request
The S-GW sends the MME a Modify Bearer
Response message as a response to the Modify
Bearer Request message received in Step 9).
12) [MME] Preparing TAU Accept Message

The MME may configure a new TAI list to reflect
the current location of the UE, or allocate a new
GUTI, depending on implementation.

13) [UE MME] Sending TAU Accept

Message
The MME sends the UE a TAU Accept message,
as integrity-protected and encrypted. This
message is delivered through a Downlink NAS
Transport message, an S1AP message, from the
eNB to the MME, and then through a DL
Information Transfer message, an RRC
message, from the UE to the eNB.
14) [UE] Updating TIN and TAI List

When the UE receives the TAU Accept message
from the MME, it checks the GUTI and TAI list
values. If these values are changed, it updates
the TIN (Temporary Identifier used in Next
update) and the TAI list with these new values.
Here, the TIN is a user ID to be used next time
the UE sends a TAU Request message, and is
updated with the GUTI included in a TAU
Accept message every time the message is
received.
15) [UE] Acknowledging New GUTI

If a new GUTI is allocated by the MME, the UE
sends a TAU Complete message to the MME,
acknowledging receipt of the new GUTI.

ECM Connection Release

16) [eNB MME] Requiring E-UTRAN to
Release UE Context
After updating the UEs location information, the
MME sends a UE Context Release
Command message to the eNB in order to
release the ECM connection used for delivering
messages relating to periodic TAU, and also
release the UE context stored in E-UTRAN.
17) [UE eNB] Releasing RRC Connection

Upon receiving the UE Context Release
Command message from the MME, the eNB
deletes the UE context, and release all the E-
UTRAN resources that were allocated to the UE.
Then, to the UE, it sends an RRC Connection
Release message to release the RRC
connection, thereby releasing the SRB (Signaling
Radio Bearer) allocated to the UE as well.
18) [eNB MME] Announcing Release of UE

Context from E-UTRAN
Also, the eNB sends a UE Context Release
Complete message to the MME, indicating the
S1 signaling connection has been released.
Now, the ECM connection that was established

for TAU Request message delivery is released,
and the UE transits back to Idle state (ECM/RRC-
Idle). Consulting | Training | Research
Handover with Tracking Area Update
1) [UE MME] TAU Request
When being handed over to the target
eNB (eNB5), the UE knows eNB5 does
not belong to its assigned TAs. Thus,
as soon as the handover is completed,
it sends a TAU Request (Update
Type=TA Updating, GUTI, Last
Visited TAI, KSIASME, NAS-
MAC) message to MME, requesting TA
update. At this time, the message
includes the following information:
The TAU Request message is sent through an UL

Information Transfer message from UE to eNB (as
RRC message), and then through an Uplink NAS
Transport (NAS-PDU (TAU
Request), ECGI, TAI)message from eNB to MME (as
S1AP message). The Uplink NAS
Transport message, including theTAU
Request message and the current cells ECGI and
TAI, is forwarded to MME.
As the NAS security context has already been
established between the UE and MME, the TAU
Request message that the UE sends is integrity-
protected with the NAS integrity key (KNASint). If the
MMEs integrity check on the received TAU
Request message fails, the MME performs user
authentication and NAS security setup procedures
(see the previous document [6]). In this document, we
will only discuss cases where the MME succeeds the
integrity check.

Handover with Tracking Area Update
2) [MME] TA Update: Allocating New
TAs
Because the UE has moved to a TA that it is
not registered to, the MME selects a group of
TAs to allocate and configures a new TAI list
for the UE. At this time, a new Globally
Unique Temporary Identifier (GUTI) may also
be allocated.
3) [UE MME] TAU Accept

The MME sends the newly selected TAs (and
GUTI if applicable), as included in a TAU
Accept (GUTI,TAI List) message. This
message, after being encrypted and integrity-
protected, is sent through aDownlink NAS
Transport message from MME to eNB (as
S1AP message), and then through a DL
Information Transfer message from eNB to
UE (as RRC message).
4) [UE MME] TAU Complete

If a new GUTI was allocated, the UE sends
the MME a TAU Complete message to
acknowledge the receipt of the new GUTI.

Cell Reselection with Tracking Area Update
1) ~ 7) [UE] Cell Reselection
The UE moves toward eNB5, triggering a cell reselection.2 So,
it measures neighbor cells to rank them, and, based on the
result, selects Cell 13 (at eNB5) as the best cell that satisfies
the cell reselection criteria most.
Tracking Area Update (TAU)

When selecting Cell 13 (at eNB5) during the foregoing
procedure, the UE knows the cell does not belong to one of its
previously assigned TAs. So, it performs a TAU procedure as
soon as the reselection procedure is completed. The TAU
procedure here is the same as explained in the previous
document, Periodic TAU [7]. The only difference between two
cases is what initiates a TAU procedure. That is, in case of
periodic TAU, UE performs a TAU to report its current location
to the network due to the expiration of the TAU timer (T3412).
Whereas, in case of the above mentioned TAU, UE performs
one because it moves to a non-registered TA. So, the TA
update type in the TAU Requestmessage this time is set as
TA Updating, not as Periodic Updating. Below, the TAU
procedure is briefly described.

8) [UE MME] TAU Request
The UE requests TA update by sending a TAU
Request (Update Type=TA Updating, GUTI, Last Visited
TAI, KSIASME, NAS-MAC) message to the MME. The TAU
Request message includes the same information as listed in
Chapter II above. Then, it is sent integrity-protected with the
NAS integrity key (KNASint). The UE establishes an RRC
connection with the eNB, and sends the message, thereby
transiting from Idle state (EMM-Registered, ECM-Idle, RRC-
Idle) to Connected state (EMM-Registered,ECM-
Connected, RRC-Connected).
9) [MME] TA Update: Allocating a New TA

Upon receiving the TAU Request message conveyed through
the Uplink NAS Transport message, the MME identifies the
TA on which the UE is currently camping (i.e. TA3 in this case)
from the TAI included in the Uplink NAS Transport, and also
the last reported TA (i.e. TA1 in this case) from the Last Visited
TAI included in the TAU Request message.
Because the TA the UE is currently camping on (i.e. TA3) is not
one of its previously allocated TAs (TA1 and TA2), the MME,
by referring to the UEs Last Visited TAI value, allocates a new
set of TAs that best suit the UEs current location and speed.
To a fast-travelling UE, a wider range of TAs may be allocated
to reduce the signaling load caused by TAU. In such case,
however, the signaling load caused by paging may increase,
and the paging response may take longer when a call/packet is
arriving for the UE while it is in Idle state. In case different TAI
lists must be allocated per UE, the trade-off between TAU
signaling load and paging performance is taken into
account.3 The MME also updates the Last Visited TAI value
included in the UE context with the UEs current TAI value.

10) [MME, S-GW, P-GW, PCRF] EPS Bearer/Session
Modification
As the UEs location is changed, the MME informs the S-GW of
such change by sending a Modify Bearer Request message.
If MME is required to report any TA change to PCRF, as set in
the Change Report Action parameters received from PCRF
when the UE established the EPS session after initial attach, a
session modification procedure is performed, reporting the TA
change to PCRF accordingly.
11) [UE MME] TAU Accept

The MME sends the UE a new TAI list (and GUTI if applicable)
through a TAU Accept (GUTI, TAI List)message. At this time,
the message includes the same information as listed in
Chapter II above, and is sent integrity-protected and encrypted.
12) ~ 14) [UE, eNB, MME] Transiting to Idle State

After the TAU procedure is completed, the MME releases the
S1 connection (see the previous document [8]), thereby
releasing the S1 signaling connection between eNB5 and
MME. Then, eNB5 releases the RRC connection established
with the UE. Now, the ECM connection between the UE and
MME is removed, and the UE turns to Idle state (EMM-
Registered, ECM-Idle, RRC-Idle), back from Connected state
(EMM-Registered, ECM-Connected, RRC-Connected).
15) [UE] Camping on Cell 13

Once back to Idle state, the UE camps on Cell 13. Now with the
new TAI list, it wakes up at the end of every DRX cycle and
measures the signal of Cell 13 (RSRP, RSRQ)

3.6 LTE MOBILE ORIGINATED CSFB CALL

Mobile Originating CSFB -> GERAN
Based on the capabilities of UEs and networks, five fallback mechanisms are available for an eNodeB to perform CSFB to
GERAN:
R8 PS Redirection
R9 PS Redirection (Flash CSFB)
CCO
After receiving a CS Fallback Indicator, the eNodeB sends a MobilityFromEUTRACommand message containing information
about a target GERAN cell to the UE, and instructs the UE to access the target cell. The UE needs to be synchronized to the
specified cell, obtains system information about the target cell, and accesses the cell to initiate CS services.
CCO with NACC
When the LTE-to-GSM RIM procedure is enabled, which indicates that NACC is enabled, the eNodeB delivers system
information about the target cell when triggering CCO. The UE directly initiates access and a CS service to the target cell and
does not need to read system information about the target cell, shortening delays.
PS Handover

1. A UE sends an Extended Service Request message carrying the CS
Fallback Indicator information element (IE) to the mobility management
entity (MME), instructing the MME to initiate CSFB.
2. The MME sends an S1-AP Request message carrying the CS Fallback
Indicator IE to the eNodeB, instructing the eNodeB to migrate the UE to a
GSM cell.
3. The eNodeB selects a target GSM cell for the UE based on the
measurement result or LTE network configuration.For details, see CSFB
Feature Parameter Description.
4. (Optional) If GBFD-511308 eNACC Between GSM and LTE has been
enabled on a GSM network, and the LTE network and CN support the RAN
information management (RIM) procedure, the eNodeB starts the RIM
procedure.
4a to 4c. The eNodeB requests the GSM system information (SI) from the
BSS using the RIM procedure.
4d to 4f. The BSC sends the GSM SI to the eNodeB.
If CSFBIDENTIFYMOSW(BSC6900,BSC6910) has been set to ON(On),
the BSC changes the new establishment causes indication (NECI) and
sends SIB3 carrying the NECI to the eNodeB
5. The eNodeB instructs the UE to access the target GSM cell as follows:
5a. If both the UE and the network support PS handovers, the eNodeB
initiates an LTE-to-GSM PS handover.
5b. If both the UE and the network support LTE-to-GSM CCO instead of PS
handovers, the eNodeB sends a MobilityFromEUTRACommand message to
the UE. The MobilityFromEUTRACommand message indicates that the
purpose is cellChangeOrder. If the LTE-to-GSM eNACC procedure is used,
the MobilityFromEUTRACommand message carries the GSM cell ID and
the SI (including SIB1, SIB3, and SIB13). If this procedure is not used, the
message carries only the GSM cell ID.
5c. If redirection is allowed, the eNodeB sends an RRC connection release
message to redirect the UE to the target GSM cell.

6. The eNodeB releases the S1 UE Context.
7. The UE sends a Channel Request message to the BSC.
8. (Optional) If the CSFBIMMASSENSW parameter involved in the GBFD-
160203 CSFB QoS feature is set to ON(On), the BSC starts the TCH
immediate assignment procedure. For details about the CSFB QoS,
see CSFB QoS Feature Parameter Description.
9. (Optional) If the LA has changed, a local area update (LAU) procedure or
combined routing area update (RAU)/LAU procedure is performed.The BSC
determines whether the call is a CSFB call based on the value of CSMO in
the "Additional update parameters" IE contained in the RAU or LAU
message.
If the call is not a CSFB call, the BSC processes the call following the
common call access procedure.
If the call is a CSFB call
and SUPPORTCSFB(BSC6900,BSC6910) has been set
to SUPPORT(Support), the BSC proceeds with subsequent steps.
If the call is a CSFB call
but SUPPORTCSFB(BSC6900,BSC6910) has been set
to UNSUPPORT(Not Support), the BSC rejects the call.
10 to 13. (Optional) If the UE is processing PS services before initiating a call, and
neither the UE nor the network supports Dual Transfer Mode (DTM), the UE
suspends the PS services.
14 to 19. The UE initiates a CS call setup procedure.
The BSC determines whether the call is a CSFB call based on the value of CSMO
in the "Additional update parameters" IE contained in the CM Service Request
message.
If the call is not a CSFB call, the BSC processes the call following the common call
access procedure.
If the call is a CSFB call and SUPPORTCSFB(BSC6900,BSC6910) has been set
to SUPPORT(Support), the BSC proceeds with subsequent steps.
If the call is a CSFB call but SUPPORTCSFB(BSC6900,BSC6910) has been set
to UNSUPPORT(Not Support), the BSC rejects the call.

If the MSC that the UE was attached to in the LTE cell before CSFB is not the
MSC that the UE was attached to in the GSM cell after CSFB, and if the UE has
not performed any location updates, the MSC rejects the MOC. After receiving a
CM Service Reject message, the UE performs an LAU procedure and then
proceeds with the call procedure.
If a UMTS network is available,
set SendUtranECSCFlag(BSC6900,BSC6910) to YES(Yes) to allow UEs to
proactively report 3G classmarks to the BSC. However, Classmark reporting
increases the call setup delay. To shorten this delay,
set UTRANCMDELAYFORCSFBSW(BSC6900,BSC6910) to ON(On) for CSFB
calls. This setting prohibits UEs from reporting 3G classmarks to the BSC. If an
early assignment procedure is used, the BSC proactively queries 3G classmarks
after the alerting procedure. If a late assignment procedure is used, the BSC
proactively queries 3G classmarks after assignment is complete.
20. (Optional) After the CS call is complete:

If the GBFD-511312 Fast LTE Reselection at 2G CS Call Release feature is
enabled, the UE quickly returns to an LTE cell. If there are suspended PS
services, the UE restores the PS services in the LTE cell.
If the GBFD-511312 Fast LTE Reselection at 2G CS Call Release feature is
disabled, the UE continues to camp on the GSM cell. If there are suspended PS
services, the UE initiates an RAU in the GSM cell to restore the PS services.

EMM Extended Service Request

RRCConnectionReconfiguration

Offset Event A3
Hysterisis Event A3

A1 Thd
A2 Thd
B1 Thd

Current RSRP bigger

than A1 Thd
Measurement Report

List of Registered
GSM ARFCN
RRCConnectionRelease

U2000 Configuration to add GERAN BCCH target only

to DCS1800 or PCS1900

Channel Request

Location Update
Request

Immediate
Assignment

Location Update
Accept

Location Update
Accept

CM Service
Request

CM Service
Accept

Call Process
CS Call
Establishment
Procedure

CSFB to GERAN
has time stamp
from Extended
Service Request
on LTE Network
until CS Call of
target ringing
CSFB Call Setup

Complete

CSFB to GERAN Call

Setup Duration
Extended SR : 29:04.776
CC Alerting : 29.18.545
Duration = 13.769 ms

In this signaling flow explain detail MOC Ultra-
Flash CSFB 2G
1a to 3a. A UE initiates voice services in an LTE cell. The
eNodeB triggers an LTE-to-GSM SRVCC handover for the
UE.
NOTE:
In the MTC Ultra-Flash CSFB procedure, the MSC sends the
Paging request or CS Paging Notification message to the UE
before the UE sends the Extend Service Request message to the
MME.
3b. After receiving the SRVCC handover request from the
MSC, the BSC identifies the Ultra-Flash CSFB call and
prepares CS resources for the call.
The BSC checks whether the configurations of MCC, MNC,
LAC, and SAC in the service area identifier (SAI) for a call
are consistent with those configured on the MSC server. If
they are, the BSC determines the call is an Ultra Flash
CSFB call. If they are not, the BSC determines that the UE
performed a UMTS-to-GSM inter-RAT handover.
The MCC, MNC, LAC, and SAC can be configured using
parameters in
the GCELLCSFBPARA or GSAIFORLTE MO. The details
are as follows:
MCC: UltraFlashCSFBSAIMCC(BSC6900,BSC6910) (GCE
LLCSFBPARA MO)
or SAIMCC(BSC6900,BSC6910) (GSAIFORLTE MO)
MNC: UltraFlashCSFBSAIMNC(BSC6900,BSC6910) (GCE
LLCSFBPARA MO)
or SAIMNC(BSC6900,BSC6910) (GSAIFORLTE MO)
LAC: UltraFlashCSFBSAILAC(BSC6900,BSC6910) (GCEL
LCSFBPARA MO)
or SAILAC(BSC6900,BSC6910) (GSAIFORLTE MO)
MobileComm Professionals, Inc(GCE
SAC: UltraFlashCSFBSAISAC(BSC6900,BSC6910)
LLCSFBPARA MO)
or SAISAC(BSC6900,BSC6910)
Company Confidential - Pinnacle Learning Center (GSAIFORLTE MO)
In this signaling flow explain detail MTC Ultra-
Flash CSFB 2G
In the MME pool or MOCN scenarios, if a BSC is connected
to multiple MSC servers, which are configured with different
SAI values, the BSC also needs to be configured with
multiple SAI values. The GCELLCSFBPARAMO can only
be used to configure one set of SAI parameters. To add
more SAI values, the GSAIFORLTE MO can be used. The
MCC, MNC, LAC, and SAC on the BSC are the combination
of the GCELLCSFBPARA MO and GSAIFORLTE MO.
NOTE:
When no SAI parameter has been configured through
the GCELLCSFBPARA MO, the GSAIFORLTE MO can also be
used to configure multiple sets of SAI parameters
4. The CN sends the Handover Command message to the
eNodeB, and the eNodeB sends the message to the UE.
5. The UE is handed over to the GSM network.
6 to 9. The UE establishes CS services on the GSM
network.
Signaling is carried by traffic channels (TCHs), accelerating
signaling transmission.
In the MOC Ultra-Flash CSFB and MTC Ultra-Flash CSFB
procedures, before sending or receiving the Alerting
message, the MSC sends the UE a Disconnect message,
instructing the UE to release a default session generated
during the SRVCC handover. This mechanism helps prevent
interference on subsequent session establishment. After the
UE is handed over to a GSM cell, if the UE sends the
Disconnect message to the MSC to release the default
session, the MSC does not send the Disconnect message to
the UE before sending or receiving the Alerting message

In this signaling flow explain detail MTC Ultra-
Flash CSFB 2G
Ultra-Flash CSFB eliminates the dimmed signaling
procedures shown in Figure 3-3 and Figure 3-4. The
following details the reasons why these signaling procedures
are eliminated:
AuthenticationThe UE has been authenticated on the LTE
side before it is handed over from an LTE cell to a GSM cell.
EncryptionThe UE has performed encryption as instructed
during the SRVCC handover.
IMEI queryThe MME has sent the IMEI to the MSC during
the preparation for the SRVCC handover.
CS resource establishmentThe GSM network has prepared
CS resources during the SRVCC handover procedure and
the UE does not need to reestablish CS resources after the
SRVCC handover.

Mobile Originating CSFB -> UTRAN
Based on the capabilities of UEs and networks, three fallback mechanisms are available for an eNodeB to perform CSFB to
UTRAN:
R8 PS Redirection
After receiving a CS Fallback Indicator, the eNodeB sends an RRC Connection Release message containing frequency
information about the target UTRAN to the UE. Based on the received frequency information, the UE searches for a UTRAN cell,
obtains the system information of the UTRAN cell, and initiates initial access and CS services.
R9 PS Redirection (Flash CSFB)

After receiving a CS Fallback Indicator, the eNodeB sends an RRC Connection Release message containing information about a
target UTRAN frequency as well as system information about multiple target cells to the UE. Based on the received frequency
information, the UE searches for a UTRAN cell. As the UE obtains system information about the target cell, the UE initiates initial
access and CS services in the target cell, thereby reducing voice delay.
PS Handover
The UE is handed over to the UMTS network through the PS handover procedure between the eNodeB and the UMTS network.
After the handover, the UE initiates CS services in the target cell.

In this signaling flow

explain detail on LTE
side

EMM Extended Service Request


Target 3G Cell
Freq & SC
RRC Conn Rcfg (B1)


Target 3G Cell
RRC Conn Rcfg (B1)


RRC Conn Rcfg

CMP MobileComm Professionals, Inc

Measurement
Report MobileComm Professionals, Inc

In this information, UE was
redirection to 3G Network with
Scrambling Code 100 with 3G
Freq 10612
RRC Connection
Release MobileComm Professionals, Inc

Master
Information Block
3G

SIB Type 1 3G

SIB Type 3 3G

SIB Type 5 3G

SIB Type 5 3G

SIB Type 7 3G
The UL interference IE in SIB7 is one of the factors that determine the UE initial access level. The value of this IE
frequently changes with the network traffic conditions. To prevent a large amount of system information update
procedures caused by uplink interference, the RNC always sends the eNodeB the value of -105 dBm as the value of
the UL interference IE. It is worth noting that this may decrease the RRC connection setup success rate when the
UMTS uplink load is heavy.
For details about definition on the UMTS cell identity, see section 9.2.1.61 "Source Cell Identifier" in 3GPP TS 25.413
V10.3.0. For details about the types of RAN system information contained in the RIM Application Identity IE, see section MobileComm Professionals, Inc
10.2.48a "System Information Container" in 3GPP TS 25.331 V11.3.0.
RRC Connection Procedure



Authentication, Security,
LAU, RAU Procedure

Authentication, Security,
LAU, RAU Procedure

UL Direct Transfer (CM Service Request)

UL Direct Transfer (CC Setup)

DL Direct Transfer (CC Call Proceeding)

RAB Assignment
Procedure

CSFB to UTRAN
has time stamp
from Extended
Service Request
on LTE Network
until CS Call of
target ringing
DL Direct Transfer ( CC Alerting)

CSFB to UTRAN Call

Setup Duration
Extended SR : 31:57.482
CC Alerting : 32.06.572
Duration = 9045 ms

In this signaling flow explain detail on 3G side
(CSFB with R9 Ultra Flash CSFB)
Step 1 through step 4: A UE in the LTE network initiates or
receives a voice service request. Therefore, the eNodeB
initiates an LTE-to-UMTS handover of combined services
through SRVCC. Using a mechanism, the MME and MSC
ensure the successful LTE-to-UMTS handover.
Step 5: When ULTRA_FLASH_CSFB_SWITCH under
the PROCESSSWITCH2(BSC6900,BSC6910) parameter in
the MML command SET URRCTRLSWITCH is selected, the
RNC identifies the Ultra-Flash CSFB process based on the
CSFB information IE in the CS domain's relocation request
message that is sent as a response to the SRVCC-based
handover request. To ensure quick transfer of NAS
messages during admission after the UE is handed over to a
UMTS cell, the SRB rate of the UE can be specified by
the UltraFlashCSFBSRBRate(BSC6900,BSC6910) parame
ter in the MML command SET UFRC.
Step 6: The CN sends a handover command to the eNodeB,
and the eNodeB delivers the handover command to the UE.
Step 7: The UE is handed over to a UMTS cell.
Step 8 through step 9: The RNC and UE implement the
security mode and processes such as UTRAN mobility
information.
Step 10 through step 13: The UE and MSC exchanges NAS
messages with each other to set up a CS service.
Step 14: The SRB rate is reconfigured to 3.4 kbit/s after the
CS service is set up to save UMTS resources.

In this signaling flow explain detail on 3G side
(CSFB with R9 Ultra Flash CSFB)
AuthenticationThis procedure is not required because the
UE has been authenticated on the LTE side before it is
handed over from an LTE cell to a UMTS cell.
EncryptionThis procedure is not required after a CSFB
because the UE has implemented encryption according to
the handover command during the SRVCC handover.
IMEI queryThis procedure is not required after a handover is
complete because the MME has sent the IMEI to the MSC
during the SRVCC handover preparation.
CS resource establishmentThis procedure is not required
after a handover is complete because CS resources have
been prepared on the UMTS side during the SRVCC
procedure. This section only describes how Ultra-Flash
CSFB is implemented on the RAN side.

Thank You

Author
Ray Khastur, ST.
Educational Background :
Bachelor of Telecommunication Engineer, Telkom Institute of Technology (2006
2010) JPPA-N Acceleration
Professional Experience :
PI.Works, RAN Consultant (2014 ~ Present)
China JIESAI, LTE Optimization Consultant (2014)
Lintas Media Telekomunikasi, LTE RF Team Leader (2013 ~ 2014)
HUAWEI Tech Investment, CWiL RNP/O Engineer (2011 ~ 2013)
Transdata Global Network, CDMA RNO Engineer (2010 ~2011)
Achievements :
RF Network Design & Planning First Commercial LTE Network in Indonesia (BOLT!
Super 4G LTE)-2013 HUAWEI
NPI & Post Launch Optimization BOLT! Super 4G LTE - 2014 PI.Works
LTE Technical Expert for HUAWEI Environment
LTE Planning & Optimization Trainer Floatway Certified-2013
LTE HUAWEI Trainer for Subcont-2016


3 Ltelayer3analysispart1 160408135823 PDF

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

3 Ltelayer3analysispart1 160408135823 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

3.

LTE Layer 3 Analysis (Part 1)

Author : Ray Khastur

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

Filter by RSRP Threshold

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

Company Confidential - Pinnacle Learning Center

1. EMM common procedure: Refers to one that can always

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

EMM-Registered state (C and D) indicates that a UE is attached to a network and

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

Tracking Area Update: A UE in EMM-Registered

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

Company Confidential - Pinnacle Learning Center

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

Of course the most important information is "BandWidth".

According to 36.331 section 5.2.1.2, the MIB scheduling is as follows :

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

MobileComm Professionals, Inc

Consulting | Training | Research

Day PCI Cell_Id eNB_ID