LTE Initial Attach/ Detach Procedure & Timers(RRC, UE & NW side)

• Power ON Procedure(Detailed View):https://www.linkedin.com/posts/badal-mishra-282a7958_ue-power-onapm-mode-off-

procedure-activity-6697545414058614784-Jo2u
• RACH Procedure (Detailed View): https://www.linkedin.com/posts/badal-mishra-282a7958_lte-random-access-procedure-
activity-6705547165835644928-koik
• RRC Establishment, Re- Configuration and Re-Establishment (Detailed View):
https://www.linkedin.com/posts/badal-mishra-282a7958_lterrcestablishmentre-configuration-activity-6708077932839104512-CaUN

Now,

• UE is done with DL Synchronization eNodeB→UE (PSS, SSS, PCI, MIB, SIB & PLMN)
• Also, UL Synchronization UE→eNodeB (RACH procedure)
• RRC establishment is performed (RRC connection request, RRC connection setup, RRC connection complete)

Going further will discuss about the attach procedure takes place. Before that lets know a short definition of attach:

• UE needs to register with the network to receive services that require registration. This registration is called Network Attachment.

Let get started!!

Figure: Initial Attach Procedure
The attach procedure has four main objectives.
1. The UE uses the procedure to register its location with a serving MME.
2. The network configures signaling radio bearer 2(SRB2), which carries subsequent non-access stratum signaling messages across the air
interface.
3. The network also gives the UE an IPversion4 address /or an IPversion6 address.
4. Sets up a default EPS bearer, which provides the UE with always-on connectivity to a default PDN.

(i). This is the message that the UE sent the first time it connects to the network either by;

- UE Power On
- UE Idle to connected Mode

(ii). This message here, this is the initial message sent over the NAS layer and they are piggybacked, and, on this message, we also have the PDA
and connectivity request.
(iv)The UE starts by running the contention-based random-access procedure and the first two steps of RRC connection establishment.
(v). The UE then composes an EPS session management (ESM) message, PDN Connectivity Request, which asks the network to establish a default
EPS bearer. The message includes a PDN type, which indicates whether the UE supports IPv4, IPv6 or both. It can also include a set of protocol
configuration options, which list any parameters that relate to the external network, such as a preferred access point name or a request to
receive an IPv4address.
(vi). The UE embeds the PDN connectivity request into an EMM Attach Request, in which it asks for registration with a serving MME. The
message includes the Globally Unique Temporary Identity (GUTI)that the UE was using when last switched on and the identity of the tracking
area in which the UE was last located. It also includes the UE’s non-access stratum capabilities, primarily the security algorithms that it supports.
(vi). The UE embeds the Attach Request into the last message from the RRC connection establishment procedure, RRC Connection Setup
Complete. The RRC message also identifies the PLMN that the UE would like to register with and the identity of its last serving MME.
Step1: Initial UE Message (Attach Request + PDN Connectivity Request):
In step 1 of the attach procedure, the UE sends this message to the serving eNB.
The UE and MME can store their LTE security keys after the UE switches off. If the UE has a valid set of security keys, then it uses these to secure
the attach request using a process known as integrity protection. This assures the MME that the request is coming from a genuine UE and not
from an alien.
The eNodeB extracts the EMM and ESM messages and embeds them into an S1-AP Initial UE Message, which requests the establishment of an
S1 signaling connection for the UE.
As part of this message, the eNodeB specifies the RRC establishment cause and the requested PLMN, which it received from the UE during the
RRC procedure, as well as the tracking area in which it lies.

Step 2: Identification and Security Procedures:

In step 2 the eNodeB can now forward the message to a suitable MME. The chosen MME is the same one that the UE was previously registered
with. This can be done if two conditions are met:
- The eNodeB has to lie in one of the old MME’s pool areas and the old MME has to lie in the requested PLMN.
- If the UE has changed the pool area since it was last switched on or if it is asking to register with a different network, then the base
station selects another MME. It does so by choosing at random from the ones in its pool area, according to a load balancing algorithm.
The MME receives the messages from the eNodeB and can now run some procedures that relate to identification and security.
If the UE has moved to a new MME since it was last switched on, then the MME has to find out the UE’s identity. To do this, it extracts the
identity of the old MME from the UE’s GUTI and sends the GUTI to the old MME in a GTP-C Identification Request. The old MME’s response
includes the international Mobile subscriber identity (IMSI) and the UE’s security keys.
In exceptional cases, for example if the MME has removed its internal database, the UE may be unknown to the old MME. If this happens, then
the new MME asks the UE for its IMSI using an EMM Identity Request, a message that is transported using the NAS information transfer
procedure. The network can now run two security procedures:
- Authentication and key agreement, the UE and network confirm each other’s identities and set up a new set of security keys. In NAS
security activation, the MME activates those keys and initiates the secure protection of all subsequent EMM and ESM messages. These
steps are mandatory if there was any problem with the integrity protection of the attach request and are optional otherwise. If the
 integrity check succeeded, then the MME can implicitly re-activate the UE’s old keys by sending it a signaling message that it has secured
using those keys, thus skipping both of these procedures.
- The MME then retrieves the International Mobile Equipment Identity (IMEI). It can combine this message with NAS security activation to
reduce the amount of signaling, but it is mandatory for the MME to retrieve the IMEI somehow. As a protection against stolen UEs, the
MME can optionally send the IMEI to the equipment identity register, which responds by either accepting or rejecting the device. If the
UE sets the ESM information transfer flag in its PDN Connectivity Request, then the MME can now send it an ESM Information Request.
The UE sends its protocol configuration options in response; for example, any access point name that the UE would like to request. Now
that the network has activated NAS security, the UE can send the message securely.

Step 3: Location Update:

The MME can now update the network’s record of the UE’s location If the MME has changed, then the new MME sends the UE’s IMSI to the
home subscriber server (HSS), in a Diameter Update Location Request.
The HSS updates its record of the mobile’s location and tells the old MME to forget about the UE. If the old MME has any EPS bearers that are
associated with the mobile, then it deletes these as before.
The HSS sends an Update Location Answer to the new MME, which includes the user’s subscription data. The subscription data lists all the access
point names (APNs) that the user has subscribed to, define each one using an APN configuration and identify one of the APN configurations as
the default.
In turn, each APN configuration identifies the access point name, states whether the corresponding packet data network supports IPv4, IPv6 or
both, and defines the default EPS bearer’s quality of service using parameters. Optionally, it can also indicate a static IPv4 address or IPv6 prefix
for the UE to use when connecting to that APN.

Step 4: Default Bearer Creation:

The MME now has all the information that it needs to set up the default EPS bearer. It begins by selecting a suitable PDN gateway, using the UE’s
preferred APN if it supplied one and the subscription data support it, or the default APN otherwise.
It then selects a serving gateway and sends it a GTP-C Create Session Request. In this message, the MME includes the relevant subscription data
and identifies the UE’s IMSI and the destination PDN gateway.
The serving gateway receives the message and forwards it to the PDN gateway. In the message, the serving gateway includes a GTP-U tunnel
endpoint identifier (TEID), which the PDN gateway will eventually use to label the downlink packets that it sends across the S5/S8 interface. If
the message does not contain a static IP address, then the PDN gateway can allocate a dynamic IPv4 and / or IPv6 address for the UE.
Alternatively, it can defer the allocation of an IPv4 address until later, if the mobile requested that in its protocol configuration options.
The PDN gateway can also run a procedure known as IP connectivity access network (IP-CAN) session establishment, during which it receives
authorization for the default bearer’s quality of service.
The PDN gateway now acknowledges the serving gateway’s request by means of a GTP-C Create Session Response. In the message, it includes
any IP address that the mobile has been allocated, as well as the quality of service of the default EPS bearer.
The PDN gateway also includes a TEID of its own, which the serving gate way will eventually use to route uplink packets across S5/S8.
The serving gateway forwards the message to the MME, except that it replaces the PDN gateway’s tunnel endpoint identifier with an uplink TEID
for the base station to use across S1-U.

Step 5: Attach Accept:

The MME can now reply to the UE’s attach request.
- It first initiates an ESM procedure known as Default EPS bearer context activation, which is a response to the UE’s PDN Connectivity
Request, and which starts with a message known as Activate Default EPS Bearer Context Request.
- The message includes;
EPS bearer identity
Access point name
Quality of service and any IP address that the network has allocated to the UE.
- The MME embeds the ESM message into an EMM Attach Accept, which is a response to the UE’s original attach request.
- The message includes;
list of tracking areas in which the MME has registered the UE
A new Globally Unique Temporary Identity.
- The MME embeds both messages into an S1-AP Initial Context Setup Request. This is the start of a procedure known as Initial context
setup, which was triggered by the eNodeB Initial UE Message.
- The procedure tells the eNodeB to set up an S1 signaling connection for the UE, and S1 and radio bearers that correspond to the default
EPS bearer.
- The message includes;
Bearers’ Quality of Service
Uplink TEID that the MME received from the serving gateway
Key for the activation of access stratum security.
- The MME sends all three messages to the eNodeB
- On receiving the message, the eNodeB activates access stratum security using the secure key that the MME supplied. From this point, all
the data and RRC signaling messages on the air interface are secured. It also retrieves the UE’s radio access capabilities, so that it knows
how to configure the UE.
- The eNodeB can then compose an RRC Connection Reconfiguration message, in which it modifies the UE’s RRC connection so as to set
up two new radio bearers: a radio bearer that will carry the default EPS bearer and SRB 2. It sends this message to the mobile, along with
the EMM and ESM messages that it has just received from the MME.
- The UE reconfigures its RRC connection as instructed and sets up the default EPS bearer. It then sends its acknowledgements to the
network in two stages.
(a). Using SRB 1, the mobile first sends the eNodeB an acknowledgement known as RRC Connection Reconfiguration Complete. This
triggers an S1-AP Initial Context Setup Response to the MME, which includes a downlink TEID for the serving gateway to use across S1-U.
It also triggers an S1-AP UE Capability Info Indication, in which the eNodeB sends the UE’s capabilities back to the MME, where they are
stored until the UE detaches from the network.
(b). The UE then composes an ESM Activate Default EPS Bearer Context Accept and embeds it into an EMM Attach Complete, to
acknowledge the ESM and EMM message.
- It sends these messages to the eNodeB on SRB 2, using the NAS information transfer procedure, and the eNodeB forwards the messages
to the MME.
Step 6: Default Bearer Update:
The UE can now send uplink data as far as the PDN gateway. However, we still need to tell the serving gateway about the identity of the selected
eNodeB and send it the tunnel endpoint identifier that the eNodeB has just provided.
To do this the MME sends a GTP-C Modify Bearer Request to the serving gateway and the serving gateway responds. From this point, downlink
data packets can flow to the UE.
The MME can also notify the HSS about the chosen PDN gateway and APN. It does this if the chosen PDN gateway is different from the one in
the default APN configuration; for example, if the mobile requested an access point name of its own to connect to.
The HSS stores the chosen PDN gateway, for use in any future handovers to non-3GPP systems and responds.
Finally, the mobile may have to contact the PDN gateway across the user plane, to complete the allocation of its IP addresses.
The mobile is now in the states;
EMM-REGISTERED
ECM-CONNECTED
RRC_CONNECTED
**UE will stay in these states for as long as the user is actively communicating with the outside world. If the user does nothing, the network
can transfer the mobile into ECM-IDLE and RRC_IDLE using a procedure known as S1 release.
 Detach Procedure
The last process to consider is the Detach procedure.

This cancels the UE’s registration with the evolved packet core and is normally used when the mobile switches off.

We will assume that the UE starts in ECM-CONNECTED and RRC_CONNECTED, consistent with its state. The user triggers the procedure by telling
the UE to shut down.

In response, the UE composes an EMM Detach Request, in which it specifies its GUTI, and sends the message to the MME. After sending the
message, the UE can switch off without waiting for a reply.

The MME now has to tear down the UE’s EPS bearers. To do this, it looks up the UE’s serving gateway and sends it a GTP-C Delete Session
Request.

The serving gateway forwards the message to the PDN gateway, which can run a procedure known as IP-CAN session termination that undoes
the earlier effect of IP-CAN session establishment.

The PDN gateway then tears down all the UE’s bearers and replies to the serving gateway, which tears down its bearers in the same way and
replies to the MME. If necessary, these steps are repeated for any other network that the UE is connected to.

To finish the procedure, the MME tells the eNodeB to tear down all the resources that are related to the UE and indicates that the cause is a
detach request.

The eNodeB does so and responds. The MME can now delete most of the information that it associated with the UE. However, it keeps a record
of the UE’s;

IMSI, GUTI, & Security keys

**These will be needed next time the UE switches on. If the UE starts in ECM-IDLE and RRC_IDLE, then it cannot send the detach request right
away. Instead, it starts by running the contention-based random-access procedure, followed by RRC connection Request & RRC Connection
Setup. It then embeds the detach request into the message RRC Connection Setup Complete, and the detach procedure continues as before.
Figure: Detach Procedure
 Timers RRC, UE & Network Side
RRC Timers:
Timer Start Stop At expiry

T300 Transmission of RRCConnectionRequest Reception of RRCConnectionSetup or RRCConnectionReject Perform the actions as specified in 5.3.3.6
message, cell re-selection and upon abortion of connection
establishment by upper layers

T301 Transmission of RRCConnectionReestabilshmentRequest Reception of RRCConnectionReestablishment or Go to RRC_IDLE

RRCConnectionReestablishmentReject message as well as when the
selected cell becomes unsuitable

T302 Reception of RRCConnectionReject while performing RRC Upon entering RRC_CONNECTED and upon cell re-selection Inform upper layers about barring alleviation as specified in 5.3.3.7
connection establishment

T303 Access barred while performing RRC connection Upon entering RRC_CONNECTED and upon cell re-selection Inform upper layers about barring alleviation as specified in 5.3.3.7
establishment for mobile originating calls

T304 Reception of RRCConnectionReconfiguration message Criterion for successful completion of handover to EUTRA or cell In case of cell change order from E-UTRA or intra E-UTRA handover, initiate the RRCconnection re-establishment
including the MobilityControl Info or reception of change order is met (the criterion is specified in the target RAT in procedure; In case of handover to E-UTRA, perform the actions defined in the specifications applicable for the source
MobilityFromEUTRACommand message including case of inter-RAT) RAT.
CellChangeOrder

T305 Access barred while performing RRCconnection Upon entering RRC_CONNECTED and upon cell re-selection Inform upper layers about barring alleviation as specified in 5.3.3.7
establishment for mobile originating signalling

T310 Upon detecting physical layer problems i.e. upon receiving Upon receiving N311 consecutive in-sync indications from lower If security is not activated: go to RRC_IDLE
N310 consecutive out-of-sync indications from lower layers layers, upon triggering the handover procedure and upon initiating
the connection re-establishment procedure
else: initiate the connection re-establishment procedure

T311 Upon initiating the RRCconnection Selection of a suitable E-UTRA cell or a cell using another RAT. Enter RRC_IDLE
reestablishmentmprocedure

T320 Upon receiving t320 or upon cell (re)selection to E-UTRA Upon entering RRC_CONNECTED, when PLMN selection is Discard the cell reselection priority information provided by dedicated signalling.
from another RAT with validity time configured for performed on request by NAS, or upon cell (re)selection to another
dedicated priorities (in which case the remaining validity RAT (in which case the timer is carried on to the other RAT).
time is applied).

T321 Upon receiving measConfig including a reportConfig with Upon acquiring the information needed to set all fields of Initiate the measurement reporting procedure, stop performing the related measurements and remove the
the purpose set to reportCGI cellGlobalId for the requested cell, upon receiving measConfig that corresponding measId
includes removal of the reportConfig with the purpose set to
reportCGI
UE Side Timer:
TIMER TIMER ON
STATE CAUSE OF START NORMAL STOP
NUM. VALUE EXPIRY
T3402 Default 12 min. EMM DEREGISTERED At attach failure and the attempt counter is ATTACH REQUEST sent TRACKING Initiation of the attach procedure or TAU
NOTE 1 EMM REGISTERED equal to 5. AREA UPDATE REQUEST sent procedure
At tracking area updating failure
and the attempt counter is equal to 5.

T3410 15s EMMREGISTEREDINITIATED ATTACH REQUEST sent ATTACH ACCEPT received Start T3411 or T3402 as described in
ATTACH REJECT received subclause 5.5.1.2.6

T3411 10s EMM DEREGISTERED. At attach failure due to lower layer failure, ATTACH REQUEST sent Retransmission of the ATTACH
ATTEMPTING TO-ATTACH EMM REGISTERED. T3410 timeout or attach rejected with other TRACKING AREA UPDATE REQUEST REQUEST or TRACKING AREA
ATTEMPTING TO-UPDATE EMM cause values than those treated in sent UPDATE REQUEST
subclause 5.5.1.2.5.
At tracking area updating failure due to
lower layer failure, T3430 timeout or TAU
rejected with other EMM cause values than
those treated in subclause 5.5.3.2.5.

T3412 Default 54 min. EMM REGISTERED In EMM-REGISTERED, when When entering state EMM Initiation of the periodic TAU procedure
NOTE 2 EMM-CONNECTED mode is left. DEREGISTERED
NOTE 5 or
when entering EMM-CONNECTED mode.
T3416 30s EMM REGISTERED INITIATED RAND and RES stored as a result of a SECURITY MODE COMMAND received Delete the stored RAND and RES
UMTS authentication challenge SERVICE REJECT received
EMM REGISTERED
TRACKING AREA UPDATE ACCEPT
EMM DEREGISTERED INITIATED
received
EMM-TRACKINGAREA UPDATING INITIATED AUTHENTICATION REJECT received
EMM-SERVICE REQUEST INITIATED AUTHENTICATION FAILURE sent
EMM DEREGISTERED
or
EMM-NULL entered

T3417 5s EMM-SERVICEREQUESTINITIATED SERVICE REQUEST sent EXTENDED Bearers have been set up Abort the procedure
SERVICE SERVICE REJECT received
REQUEST sent in case f and g in subclause
5.6.1.1

T3417ext 10s EMM-SERVICEREQUESTINITIATED EXTENDED SERVICE REQUEST sent in Inter-system change from S1 mode to A/Gb Abort the procedure
case d in mode or Iu mode is completed
subclause 5.6.1.1 Inter-system change from S1 mode to A/Gb
EXTENDED SERVICE REQUEST sent in mode or Iu mode is failed
case e in SERVICE REJECT received
subclause 5.6.1.1 and the CSFB response
was set to "CS fallback
accepted by the UE"

T3418 20s EMM REGISTEREDINITIATED AUTHENTICATION FAILURE (EMM AUTHENTICATION REQUEST received On first expiry, the UE should consider
EMM REGISTERED cause = #20 "MAC failure" the network as false
EMM-TRACKINGARE AUPDATINGINITIATED or #26 "non-EPS authentication
EMM DEREGISTEREDINITIATED unacceptable") sent
EMM-SERVICEREQUESTINITIATED

T3420 15s EMM REGISTERED INITIATED AUTHENTICATION FAILURE (cause = AUTHENTICATION REQUEST received On first expiry, the UE should consider
EMM REGISTERED #21 "synch failure") sent the network as false
EMM DEREGISTERED INITIATED
EMM-TRACKINGAREA UPDATING INITIATED
EMM-SERVICE REQUEST INITIATED

T3421 15s EMM DEREGISTERED INITIATED DETACH REQUEST sent DETACH ACCEPT received Retransmission of DETACH REQUEST
T3423 NOTE 3 EMM REGISTERED T3412 expires while the UE is in EMM- When entering state EMM Set TIN to "P-TMSI"
REGISTERED.NO-CELLAVAILABLE DEREGISTERED
and ISR is activated. or
when entering EMM-CONNECTED mode.

T3430 15s EMM-TRACKING AREA UPDATING INITIATED TRACKING AREA UPDATE TRACKING AREA UPDATE ACCEPT Start T3411 or T3402 as described in
REQUEST sent received subclause 5.5.3.2.6
TRACKING AREA UPDATE REJECT
received

T3440 10s EMM REGISTERED INITIATED ATTACH REJECT, DETACH REQUEST, Signalling connection released Release the signalling connection and
EMM-TRACKING AREA UPDATING INITIATED TRACKING AREA Bearers have been set up proceed as described in subclause 5.3.1.2
EMM DEREGISTERED INITIATED UPDATE REJECT with any of the EMM
EMM-SERVICE REQUEST INITIATED cause #11, #12, #13, #14 or #15 SERVICE
EMM REGISTERED REJECT received with any of the EMM
cause #11,#12, #13 or #15
TRACKING AREA UPDATE ACCEPT
received after the UE
sent TRACKING AREA UPDATE
REQUEST in EMMIDLE mode with no
"active" flag

T3442 NOTE 4 EMM REGISTERED SERVICE REJECT received with EMM TRACKING AREA UPDATE REQUEST None
cause #39 "CS domain temporarily not sent
available"

Note 1 The default value of this timer is used if the network does not indicate another value in an EMM signaling procedure.

Note 2 The value of this timer is provided by the network operator during the attach and tracking area updating procedures. (This Timer value is set in Attach Accept message as well).

Note 3 The value of this timer may be provided by the network in the ATTACH ACCEPT message and TRACKING AREA UPDATE ACCEPT message. The default value of this timer is identical to the value of T3412.

Note 4 The value of this timer is provided by the network operator when a service request for CS fallback is rejected by the network with EMM cause #39 "CS domain temporarily not available".

Note 5 The default value of this timer is used if the network does not indicate a value in the TRACKING AREA UPDATE ACCEPT message and the UE does not have a stored value for this timer.
(This Timer value is set in Attach Accept message as well).
Network Side Timer:
ON THE
TIMER TIMER
STATE CAUSE OF START NORMAL STOP 1st, 2nd, 3rd, 4th
NUM. VALUE
EXPIRY (NOTE 1)

T3413 NOTE 2 EMM REGISTERED Paging procedure for EPS services initiated Paging procedure for EPS services completed Network dependent

T3422 6s EMM DEREGISTERED INITIATED DETACH REQUEST sent DETACH ACCEPT received Retransmission of DETACH REQUEST

T3450 6s EMM-COMMON PROC-INIT ATTACH ACCEPT sent ATTACH COMPLETE received Retransmission of the same message type, i.e.
TRACKING AREA UPDATE ACCEPT sent TRACKING AREA UPDATE COMPLETE ATTACH ACCEPT,TRACKING AREA
with GUTI received UPDATE ACCEPT or GUTI
TRACKING AREA UPDATE ACCEPT sent GUTI REALLOCATION COMPLETE REALLOCATION COMMAND
with TMSI received
GUTI REALLOCATION COMMAND sent

T3460 6s EMM-COMMON PROC-INIT AUTHENTICATION REQUEST sent AUTHENTICATION RESPONSE received Retransmission of the same message type,
SECURITY MODE COMMAND sent AUTHENTICATION FAILURE received i.e.AUTHENTICATION REQUEST or
SECURITY MODE COMPLETE received SECURITY MODE COMMAND
SECURITY MODE REJECT received

T3470 6s EMM-COMMON PROC-INIT IDENTITY REQUEST sent IDENTITY RESPONSE received Retransmission of IDENTITY REQUEST

Mobile Default 4 min greater All except EMM DEREGISTERED Entering EMM-IDLE mode NAS signalling connection established Network dependent, but typically paging is
reachable than T3412 halted on 1st expiry

Implicit NOTE 3 All except EMM DEREGISTERED The mobile reachable timer NAS signalling connection established Implicitly detach the UE on 1st expiry
detach expires while the network is in
timer EMM-IDLE mode

NOTE 1: Typically, the procedures are aborted on the fifth expiry of the relevant timer. Exceptions are described in the corresponding procedure description.

NOTE 2: The value of this timer is network dependent.

NOTE 3: The value of this timer is network dependent. If ISR is activated, the default value of this timer is 4 minutes greater than T3423.
 Here is the ref. of a real time UE log

Thank You!!
===============================================================