0% found this document useful (0 votes)
282 views

LTE Attach Procedure in 26 Steps!!!!

The document describes the 26 step attach procedure between a UE (user equipment), eNodeB, MME (mobility management entity), SGW (serving gateway) and PGW (packet data network gateway). Key steps include: 1) the UE sends an attach request to the eNodeB; 2) the MME is derived and an identity request is sent if needed; 3) authentication and security setup occurs if needed; 4) location updates are sent to the HSS (home subscriber server); 5) bearer contexts are established and messages sent to update the SGW and PGW.

Uploaded by

Sourub Kushwah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
282 views

LTE Attach Procedure in 26 Steps!!!!

The document describes the 26 step attach procedure between a UE (user equipment), eNodeB, MME (mobility management entity), SGW (serving gateway) and PGW (packet data network gateway). Key steps include: 1) the UE sends an attach request to the eNodeB; 2) the MME is derived and an identity request is sent if needed; 3) authentication and security setup occurs if needed; 4) location updates are sent to the HSS (home subscriber server); 5) bearer contexts are established and messages sent to update the SGW and PGW.

Uploaded by

Sourub Kushwah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Attach Procedure

Step 1. The UE initiates the attach procedure by transmitting an attach request to the eNodeB.
Step 2. The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI and the
indicated Selected Network.
Step 3. If the UE identifies itself with GUTI and the MME has changed since detach, the new MME
uses the GUTI received from the UE to derive the old MME/SGSN address, and send an
Identification Request to the old MME/SGSN to request the IMSI.
Step 4. If the UE is unknown in both the old MME/SGSN and new MME, the new MME sends an
Identity Request to the UE to request the IMSI. The UE responds with Identity Response (IMSI).
Step 5a. If no UE context for the UE exists anywhere in the network, if the Attach Request (sent in
step 1) was not integrity protected, or if the check of the integrity failed, then authentication and
NAS security setup to activate integrity protection and NAS ciphering are mandatory.
Step 5b. The ME Identity shall be retrieved from the UE.
Step 6. If the UE has set the Ciphered Options Transfer Flag in the Attach Request message, the
Ciphered Options i.e. PCO or APN or both, shall now be retrieved from the UE.
Step 7. If there are active bearer contexts in the new MME for this particular UE (i.e. the UE re-
attaches to the same MME without having properly detached before), the new MME deletes these
bearer contexts by sending Delete Session Request (LBI) messages to the GWs involved.
Step 8. If the MME has changed since the last detach, or if there is no valid subscription context for
the UE in the MME, the MME sends an Update Location Request message to the HSS.
Step 9. The HSS sends Cancel Location (IMSI, Cancellation Type) to the old MME.
Step 10. If there are active bearer contexts in the old MME/SGSN for this particular UE, the old
MME/SGSN deletes these bearer contexts by sending Delete Session Request (LBI) messages to the
GWs involved.
Step 11. The HSS acknowledges the Update Location message by sending an Update Location Ack
message to the new MME.
Step 12. For an Emergency Attach situation, the MME applies the parameters from MME
Emergency Configuration Data for the emergency bearer establishment performed in this step and
any potentially stored IMSI related subscription data are ignored by the MME.
Step 13. The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session
Request message to the PDN GW indicated by the PDN GW address received in the previous step.
Step 14. If dynamic PCC is deployed and the Handover Indication is not present, the PDN GW
performs an IP-CAN Session Establishment procedure.
Step 15. The PGW creates a new entry in its EPS bearer context table and generates a Charging Id.
Step 16. If the MS Info Change Reporting Action (Start) or the CSG Information Reporting Action
(Start) are received for this bearer context, then the SGW stores this for the bearer context and the
SGW reports to that PGW whenever a UE’s location and/or User CSG information change occurs
that meets the PGW request.
Step 17. If an APN Restriction is received, then the MME shall store this value for the Bearer
Context and the MME shall check this received value with the stored value for the Maximum APN
Restriction to ensure there are no conflicts between values.
Step 18. The eNodeB sends the RRC Connection Reconfiguration message including the EPS Radio
Bearer Identity to the UE, and the Attach Accept message will be sent along to the UE.
Step 19. The UE sends the RRC Connection Reconfiguration Complete message to the eNodeB.
Step 20. The eNodeB sends the Initial Context Response message to the new MME.
Step 21. The UE sends a Direct Transfer message to the eNodeB, which includes the Attach
Complete message.
Step 22. The eNodeB forwards the Attach Complete message to the new MME in an Uplink NAS
Transport message.
Step 23. Upon reception of both, the Initial Context Response message in step 20 and the Attach
Complete message in step 22, the new MME sends a Modify Bearer Request message to the Serving
GW.
Step 23a. If the Handover Indication is included in step 23, the Serving GW sends a Modify Bearer
Request (Handover Indication) message to the PDN GW to prompt the PDN GW to tunnel packets
from non 3GPP IP access to 3GPP access system and immediately start routing packets to the
Serving GW for the default and any dedicated EPS bearers established.
Step 23b. The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW.
Step 24. The Serving GW acknowledges by sending Update Bearer Response (EPS Bearer Identity)
message to the new MME.
Step 25. After the MME receives Modify Bearer Response (EPS Bearer Identity) message, if Request
Type does not indicate handover and an EPS bearer was established and the subscription data
indicates that the user is allowed to perform handover to non-3GPP accesses, and if the MME
selected a PDN GW that is different from the PDN GW identity which was indicated by the HSS in
the PDN subscription context, the MME shall send a Notify Request including the APN and PDN GW
identity to the HSS for mobility with non-3GPP accesses. The message shall include information that
identifies the PLMN in which the PDN GW is located.
Step 26. The HSS stores the APN and PDN GW identity pair and sends a Notify Response to the
MME.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy