LTE Attach (Ref: 23.401 V8.8.0 Dec 2009 Sec 5.3.2.1)
UE eNodeB New MME Old MME/SGSN SGW PGW PCRF HSS
Alcatel - Lucent Proprietary
(M23) Modify Bearer Request
(M24) Modify Bearer Request
(M25) Modify Bearer Response
(M26) Modify Bearer Response
(M27) Notify Request
(M28) Notify Response
5/3/2010
Page 3
LTE Attach (Ref: 23.401 V8.8.0 Dec 2009 Sec 5.3.2.1)
Alcatel - Lucent Proprietary
M1 The UE initiates the Attach procedure by the transmission, to the eNodeB, of an Attach Request (IMSI or old GUTI, last visited TAI (if available), UE Core Network Capability, UE Specific DRX parameters, Attach Type, ESM message container (Request Type, PDN Type, Protocol Configuration Options, Ciphered Options Transfer Flag), KSIASME, NAS sequence number, NAS-MAC, additional GUTI, P-TMSI signature) message together with RRC parameters indicating the Selected Network and the old GUMME.
M2 The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI and the indicated Selected Network. The eNodeB forwards the Attach Request message to the new MME contained in a S1-MME control message (Initial UE message) together with the Selected Network and TAI+ECGI of the cell from where it received the message to the new MME.
M3 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 (old GUTI, complete Attach Request message) to the old MME/SGSN to request the IMSI.
M4 If the request is sent to an old SGSN, the old SGSN first verifies the Attach Request message by the P-TMSI signature and then responds with Identification Response (IMSI, MM Context).
M5 If the UE is unknown in both the old SGSN and new MME, the new MME sends an Identity Request to the UE to request the IMSI.
M6 The UE responds with Identity Response (IMSI).
ME1 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.
M7 If the MME has changed since the last detach, or if there is no valid subscription context for the UE in the MME, or if the ME identity has changed, or if the UE provides an IMSI or the UE provides an old GUTI which doesn't refer to a valid context in the MME, the MME sends an Update Location Request (MME Identity, IMSI, ME Identity, MME Capabilities, Update Type) message to the HSS. The MME capabilities indicate the MME's support for regional access restrictions functionality. Update Type indicates this is Attach procedure.
M8 If the Update Type indicates Attach and the HSS has the SGSN registration, then the HSS sends Cancel Location (IMSI, Cancellation Type) to the old SGSN.
M9 The old SGSN acknowledges with Cancel Location Ack (IMSI) and removes the MM and bearer contexts.
M10 The HSS acknowledges the Update Location message by sending an Update Location Ack (IMSI, Subscription data) message to the new MME. The Subscription Data contain one or more PDN subscription contexts. Each PDN subscription context contains an 'EPS subscribed QoS profile' and the subscribed APN-AMBR (see clause 4.7.3).
M11 Then MME sends a Create Session Request (IMSI, MSISDN, MME TEID for control plane, PDN GW address, PDN Address, APN, RAT type, Default EPS Bearer QoS, PDN Type, APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information (ECGI), MS Info Change Reporting support indication, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag, the Protocol Type over S5/S8) message to the selected Serving GW.
M12 The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request (IMSI, MSISDN, APN, Serving GW Address for the user plane, Serving GW TEID of the user plane, Serving GW TEID of the control plane, RAT type, Default EPS Bearer QoS, PDN Type, PDN Address, subscribed APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information (ECGI), MS Info Change Reporting support indication, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag) message to the PDN GW indicated by the PDN GW address received in the previous step.
M13 PDN GW performs an IP-CAN Session Establishment procedure as defined in TS 23.203
5/3/2010
Page 4
LTE Attach (Ref: 23.401 V8.8.0 Dec 2009 Sec 5.3.2.1)
Alcatel - Lucent Proprietary
M15 The PDN GW returns a Create Session Response (PDN GW Address for the user plane, PDN GW TEID of the user plane, PDN GW TEID of the control plane, PDN Type, PDN Address, EPS Bearer Identity, EPS Bearer QoS, Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action (Start) (if the PDN GW decides to receive UE's location information during the session), APN-AMBR) message to the Serving GW.The PGW creates a new entry in its EPS bearer context table and generates a Charging Id. The new entry allows the PGW to route user plane PDUs between the SGW and the packet data network, and to start charging. The way the PGW handles Charging Characteristics that it may have received is defined in TS 32.251
M16 The Serving GW returns a Create Session Response (PDN Type, PDN Address, Serving GW address for User Plane, Serving GW TEID for User Plane, Serving GW TEID for control plane, EPS Bearer Identity, EPS Bearer QoS, PDN GW addresses and TEIDs (GTP-based S5/S8) or GRE keys (PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, Protocol Configuration Options, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action (Start), APN-AMBR) message to the new MME.
M17 The new MME sends an Attach Accept (APN, GUTI, PDN Type, PDN Address, TAI List, EPS Bearer Identity, Session Management Request, Protocol Configuration Options, NAS sequence number, NAS-MAC, IMS Voice over PS session supported Indication) message to the eNodeB.
M18 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. The UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id and TI, which it received in the Session Management Request, for use when accessing via GERAN or UTRAN. The APN is provided to the UE to notify it of the APN for which the activated default bearer is associated.
M19 The UE sends the RRC Connection Reconfiguration Complete message to the eNodeB.
M20 The eNodeB sends the Initial Context Response message to the new MME. This Initial Context Response message includes the TEID of the eNodeB and the address of the eNodeB used for downlink traffic on the S1_U reference point.
M21 The UE sends a Direct Transfer message to the eNodeB, which includes the Attach Complete (EPS Bearer Identity, NAS sequence number, NAS-MAC) message.
M22 The eNodeB forwards the Attach Complete message to the new MME in an Uplink NAS Transport message.
M23 Upon reception of both, the Initial Context Response message and the Attach Complete message, the new MME sends a Modify Bearer Request (EPS Bearer Identity, eNodeB address, eNodeB TEID, Handover Indication) message to the Serving GW.
M24 If the Handover Indication is included, 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.
M25 The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW.
M26 The Serving GW acknowledges by sending Modify Bearer Response (EPS Bearer Identity) message to the new MME. The Serving GW can then send its buffered downlink packets.
M27 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 also include information that identifies the PLMN in which the PDN GW is located.
M28 The HSS stores the APN and PDN GW identity pair and sends a Notify Response to the MME.
M1 The UE sends NAS message Detach Request (GUTI, Switch Off) to the MME.
M2 The active EPS Bearers in the Serving GW regarding this particular UE are deactivated by the MME sending Delete Session Request (TEID) per PDN connection to the Serving GW.
M3 The Serving GW sends Delete Session Request (TEID) per PDN connection to the PDN GW.
ME1 The PDN GW employs a PCEF initiated IPCAN Session Termination Procedure as defined in TS 23.203 [6] with the PCRF to indicate to the PCRF that EPS Bearer is released if PCRF is applied in the network.
M4 The PDN GW acknowledges with Delete Bearer Response
M5 When the SGW receives the Delete Session Request message from the MME or SGSN in ISR deactivated state, the Serving GW releases the related EPS Bearer context information
M6 The MME sends a Detach Accept to the UE.
ME2 The MME releases the S1-MME signalling connection for the UE by sending S1 Release Command to the eNodeB with Cause set to Detach.
M7 After the MME receives the Delete Session Response from Serving GW, if the subscription data indicates that the user is allowed to perform handover to non-3GPP access and the MME is configured to notify the HSS at detach, the MME shall send a Notify Request to indicate that the HSS shall remove the APN and PDN GW identity pairs for this UE. This message not needed for mobiles that do not perform HO to non-3GPP access.
M8 The HSS removes all APN and PDN GW identity pairs that were dynamically stored and sends a Notify Response to the MME. This message not needed for mobiles that do not perform HO to non-3GPP access.
5/3/2010
Page 7
UTRAN/GERAN Attach (Ref: 23.060 V8.7.0 Dec 2009 Sec 6.5.3)
UE RAN New SGSN Old MME PGW HSS
Alcatel - Lucent Proprietary
(M1) Attach request:
(M2) Identification Request:
(M3) Identification Response:
(M4) Identity Request:
(M5) Identity Response:
ME1: Authentication/Security:
(M6) Update Location Request:
(M7) Cancel Location:
(M8) Cancel Location Ack:
(M9) Insert Subscriber Data
(M10) Insert Subscriber Data Ack
(M11) Update Location Ack:
(M12) Attach Accept:
(M13) Attach Complete:
5/3/2010
Page 8
UTRAN/GERAN Attach (Ref: 23.060 V8.7.0 Dec 2009 Sec 6.5.3)
Alcatel - Lucent Proprietary
M1 The UE initiates the attach procedure by the transmission of an Attach Request (IMSI or PTMSI and old RAI, Core Network Classmark, KSI, Attach Type, old PTMSI Signature, Follow On Request, DRX Parameters, additional P-TMSI) message to the SGSN.
M2 If the UE identifies itself with PTMSI and the SGSN has changed since detach, the new SGSN sends an Identification Request (PTMSI, old RAI, old PTMSI Signature) to the old SGSN (this could be an old MME) to request the IMSI.
M3 The old MME responds with Identification Response (IMSI, Authentication Triplets or Authentication Quintets)
M4 If the UE is unknown in both the old and new SGSN, the SGSN sends an Identity Request (Identity Type = IMSI) to the UE.
M5 The UE responds with Identity Response (IMSI).
ME1 If no MM context for the UE exists anywhere in the network, then authentication is mandatory.
M6 The SGSN sends an Update Location (SGSN Number, SGSN Address, IMSI, IMEISV, Update Type) to the HSS. Update Type indicates this is Attach procedure is set to "SGSN only registration".
M7 If the Update Type indicates Attach and the HSS has the MME registration, then the HSS sends Cancel Location (IMSI, Cancellation Type) to the old MME. The Cancellation Type indicates the old MME to release the old Serving GW resource.
M8 The old SGSN acknowledges with Cancel Location Ack (IMSI). If there are any ongoing procedures for that UE, the old SGSN shall wait until these procedures are finished before removing the MM and PDP contexts.
M9 The HLR sends Insert Subscriber Data (IMSI, Subscription Data) to the new SGSN.
M10 The new SGSN validates the UE's presence in the (new) RA. If all checks are successful then the SGSN constructs an MM context for the UE and returns an Insert Subscriber Data Ack (IMSI) message to the HSS.
M11 The HLR acknowledges the Update Location message by sending an Update Location Ack to the SGSN after the cancelling of old MM context and insertion of new MM context are finished.
M12 The SGSN selects Radio Priority SMS, and sends an Attach Accept (PTMSI, VLR TMSI, PTMSI Signature, Radio Priority SMS, IMS voice over PS Session Supported Indication) message to the UE.
M13 If PTMSI or VLR TMSI was changed, the UE acknowledges the received TMSI(s) by returning an Attach Complete message to the SGSN.
M1 The MS detaches by sending Detach Request (Detach Type, PTMSI, PTMSI Signature, Switch Off) to the SGSN.
M2 If GPRS detach, the active PDP contexts in the PGW regarding this particular MS are deactivated by the SGSN sending Delete PDP Context Request (TEID) to the PGW.
M3 The PGW acknowledge with Delete PDP Context Response (TEID).
M4 The SGSN sends a Detach Accept to the UE.
ME1 The 3GSGSN releases the PS signalling connection.
M1 The MS sends a Routing Area Update Request (old PTMSI, old RAI, old PTMSI Signature, Update Type, follow on request, Classmark, MS Network Capability, additional PTMSI/RAI, KSI) to the new SGSN. Update Type shall indicate RA update, periodic RA update, Combined RA / LA Update or Combined RA / LA Update with IMSI attach requested.
M2 The new SGSN sends SGSN Context Request (old RAI, TLLI or old P-TMSI, old PTMSI Signature, New SGSN Address) to the old MME to get the MM and PDP contexts for the MS. The old MME starts a timer to release SGW resources.
M3 The old MME responds with an SGSN Context Response (MM Context, PDP Contexts) message.
ME1 Security functions may be executed. These procedures are defined in clause "Security Function" in TS 23.060 [7]. Ciphering mode shall be set if ciphering is supported. If the SGSN Context Response message did not include IMEISV and ADD is supported by the SGSN, the SGSN retrieves the IMEISV from the MS.
M4 The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. The old MME (which is the old SGSN from the new SGSN's point of view) marks in its context that the information in the GWs and the HSS are invalid. This triggers the GWs, and the HSS to be updated if the UE initiates a Tracking Area Update procedure back to the old MME before completing the ongoing Routing Area Update procedure.
M5 The new SGSN sends Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated, serving network identity, CGI/SAI, RAT type, CGI/SAI/RAI change support indication, NRSN) to the PGW concerned. The SGSN shall send the serving network identity to the PGW.
M6 The PGW sends a Update PDP Context Response to the New SGSN.
M7 The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN Address, IMSI, IMEISV, Update Type) to the HSS.
M8 The HSS sends Cancel Location (IMSI, Cancellation Type) to any old SGSN with Cancellation Type set to Update Procedure. The old SGSN removes the MM and EPS bearer contexts.
M9 The old SGSN acknowledges with Cancel Location Ack (IMSI)
M10 The HSS sends Insert Subscriber Data (IMSI, GPRS Subscription Data) to the new SGSN. The new SGSN validates the UE's presence in the (new) RA.
M11 The SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HSS
M12 The HSS acknowledges the Update Location by sending Update Location Ack (IMSI) to the new SGSN.
M13 The new SGSN responds to the MS with Routing Area Update Accept (P-TMSI, VLR TMSI, P-TMSI Signature).
M14 The MS confirms the reallocation of the TMSIs by returning a Routing Area Update Complete message to the SGSN.
M15 When the timer started in step 2) expires the old MME releases any RAN and Serving GW resources. The old MME deletes the EPS bearer resources by sending Delete Session Request (TEID, cause) messages to the Serving GW. Cause indicates to the old Serving GW that the old Serving GW shall not initiate a delete procedure towards the PDN GW.
M16 The SGW sends a Delete Session Response to the Old MME.
ME2 If the old MME has an S1-MME association for the UE, the source MME sends a S1-U Release Command to the source eNodeB when receiving the SGSN Context Acknowledge message from the new SGSN. The RRC connection is released by the source eNodeB. The source eNodeB confirms the release of the RRC connection and of the S1-U connection by sending a S1-U Release Complete message to the source MME.
5/3/2010
Page 12
UTRAN/GERAN -> LTE Cell Reselection/Tracking Area Update (TS 23.401 v 8.8.0 D.3.6-1)
(M8) PCEF Initiated CC Request IP-CAN Session Establishment
(M9) CC Answer IP-CAN Session Establishment
(M10) Modify Bearer Response
(M11) Create Session Response
(M12) Update Location Request
(M13) Cancel Location
(M14) Cancel Location Acknowledge
(M15) Cancel Location
(M16) Iu Release Command
(M17) Iu Release Complete
(M18) Cancel Location Acknowledge
(M19) Update Location Acknowledge
(M20) Tracking Area Update Accept
(M21) Tracking Area Update Complete
5/3/2010
Page 13
UTRAN/GERAN -> LTE Cell Reselection/Tracking Area Update (TS 23.401 v 8.8.0 D.3.6-1)
Alcatel – Lucent Proprietary
SP1 TS 23.401 5.3.3.0 - A standalone tracking area update occurs when a GPRS-attached or E UTRAN-attached UE experiences any of several conditions (e.g.,UE detects it has entered a new TA that is not in the list of TAIs that the UE registered with the network)The procedure is initiated by an UE in either ECM-IDLE state or ECM-CONNECTED state.
M1 The UE sends to the eNodeB a Tracking Area Update Request (last visited TAI, P TMSI Signature, old GUTI, UE Core Network Capability, active flag, EPS bearer status, additional GUTI, eKSI, NAS sequence number, NAS-MAC, KSI) message together with RRC parameters indicating the Selected Network and the old GUMMEI.
M2 The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI and the indicated Selected Network.The eNodeB forwards the TAU Request message together with the TAI+ECGI of the cell from where it received the message and with the Selected Network to the MME.
M3 The MME sends SGSN Context Request (old RAI, P TMSI, old P TMSI Signature, New SGSN Address) to the SGSN to get the MM and PDP contexts for the UE.The MME shall support functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, i.e. the MME derives the old SGSN from the old RAI and the old P-TMSI (or TLLI).
ME1 Security functions may be executed. Procedures are defined in clause 5.3.10 on Security Function. If the SGSN Context Response message from the old SGSN did not include IMEISV, the MME shall retrieve the ME Identity (the IMEISV) from the UE.
M5 The SGSN Context Acknowledge message informs the SGSN that the MME is ready to receive data packets belonging to the activated PDP contexts. The SGSN marks in its context that the MSC/VLR association and the information in the GGSNs and the HLR are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the UE initiates a routing area update procedure back to the SGSN before completing the ongoing routing area update procedure.If the security functions do not authenticate the UE correctly, then the Tracking area update shall be rejected, and the new MME shall send a reject indication to the SGSN. The SGSN shall continue as if the SGSN Context Request was never received.If there is no PDP context at all, the MME rejects the TAU Request.
M6 The MME adopts the bearer contexts received from the SGSN as the UE's EPS bearer contexts to be maintained by the MME. The MME maps the PDP contexts to the EPS bearers 1-to-1 and maps the pre-Rel-8 QoS parameter values of a PDP context to the EPS Bearer QoS parameter values of an EPS bearer. The MME establishes the EPS bearer(s) in the indicated order. The MME deactivates the EPS bearers which cannot be established.
M7 The SGW creates contexts and informs the PGW(s) about the change of the RAT type. The SGW sends a Modify Bearer Request (SGW Address and TEID, RAT type, ME Identity, User Location Information IE, MS Info Change Reporting support indication) message per PDN connection to the PGW(s) concerned.
M8 If dynamic PCC is deployed, and RAT type information needs to be conveyed from the PGW to the DSC, then the PGW shall send RAT type information to the DSC by performing an IP CAN Session Establishment procedure
M10 The PGW updates its context field and returns a Modify Bearer Response (PGW address and TEID, MSISDN, Default bearer id, Charging Id, MS Info Change Reporting Action (Start) (if the PGW decides to receive UE's location information during the session), APN Restriction) message to the SGW. When the UE moves from SGSN to the MME, the PGW shall send the APN restriction of each bearer context to the SGW.
M11 The SGW updates its context and returns Create Session Response (SGW address and TEID for user plane, PGW address and TEID, SGW Address and TEID for the control plane, Default bearer id, APN restriction) message to the MME. The SGW shall forward the received APN Restriction to the MME.
M12 To ensure the release of all UE resources in the SGSN the MME informs the HSS of the change of the serving core network node by sending an Update Location Request (MME Address, IMSI, ME Identity, Update Type, MME Capabilities) message to the HSS.
M13 If the MME changes, then the HSS cancels any MME as the Update Type indicates "MME only registration". The HSS sends a Cancel Location (IMSI, Cancellation type) message to the MME, with a Cancellation Type set to Update Procedure.
5/3/2010
Page 14
UTRAN/GERAN -> LTE Cell Reselection/Tracking Area Update (TS 23.401 v 8.8.0 D.3.6-1)
Alcatel – Lucent Proprietary
M14 The MME removes the MM context.The MME releases any local bearer resources and it deletes the EPS bearer resources by sending Delete Session Request (Cause, TEID) messages to the SGW. Cause indicates that the SGW shall not initiate a delete procedure towards the PGW.The MME acknowledges with a Cancel Location Ack (IMSI) message.
M15 The HSS cancels any SGSN node as the Update Type indicates "MME only registration". The HSS sends a Cancel Location (IMSI, Cancellation Type) message to the SGSN. The SGSN removes the contexts.If the timer started in step 5 is not running, the SGSN removes the MM context. Otherwise, the contexts are removed when the timer expires. It also ensures that the MM context is kept in the SGSN for the case the UE initiates another TAU procedure before completing the ongoing TAU procedure to the MME.
M16 On receipt of Cancel Location, if the UE is PMM CONNECTED in the SGSN, the SGSN sends an Iu Release Command message to the RNC/BSC.
M17 When the timer has expired, the SRNS responds with an Iu Release Complete message.
M18 The SGSN acknowledges with a Cancel Location Ack (IMSI) message.
M19 The MME validates the UE's presence in the (new) TA. If due to regional subscription restrictions or access restrictions the UE is not allowed to be attached in the TA, the MME rejects the Tracking Area Update Request with an appropriate cause and notifies the HSS of the rejection. If all checks are successful, the MME constructs an MM context for the UE, the HSS acknowledges the Update Location by sending Update Location Ack (IMSI, Subscription Data) message to the MME. If the Update Location is rejected by the HSS, the MME rejects the TAU Request from the UE with an appropriate cause sent in the TAU Reject message to the UE.
M20 The MME responds to the UE with a Tracking Area Update Accept (GUTI, TAI-list, EPS bearer status, NAS sequence number, NAS-MAC, ISR Activated) message. If the "active flag" is set in the TAU Request message, the user plane setup procedure can be activated in conjunction with the TAU Accept message.
M21 If the GUTI was included in the TAU Accept message, the UE acknowledges the message by returning a Tracking Area Update Complete message to the MME. When the "active flag" is not set in the TAU Request message and the Tracking Area Update was not initiated in ECM-CONNECTED state, the MME releases the signaling connection with UE.
CMT1 In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions, or access restrictions, the MME shall not construct a bearer context. A reject shall be returned to the UE with an appropriate cause, the S1 connection shall be released, and the UE returns to idle.If the MME is unable to update the bearer context in one or more PGWs, the MME shall deactivate the corresponding bearer contexts as described in clause "MME Initiated Dedicated Bearer Deactivation Procedure". This shall not cause the MME to reject the tracking area update.The PDP Contexts shall be sent from SGSN to MME in a prioritized order, i.e. the most important PDP Context first in the SGSN Context Response message. (The prioritization method is implementation dependent, but should be based on the current activity).The MME shall determine the Maximum APN restriction based on the received APN Restriction of each bearer context from the PGW and then store the new Maximum APN restriction value.If there are active EPS GBR bearers with maximum bitrate set to 0, the MME should initiate "MME Initiated Dedicated Bearer Deactivation" to deactivate the related EPS bearer Context.If the MME is unable to support the same number of active bearer contexts as received from SGSN, the MME should use the prioritisation sent by SGSN as input when deciding which bearer contexts to maintain active and which ones to delete. In any case, the MME shall first update all contexts in one or more PGWs and then deactivate the context(s) that it cannot maintain as described in clause "MME Initiated Dedicated Bearer Deactivation Procedure". This shall not cause the MME to reject the tracking area update.If the tracking area update procedure fails a maximum allowable number of times, or if the MME returns a Tracking Area Update Reject (Cause) message, the UE shall enter EMM DEREGISTERED state.If the Update Location Ack message indicates a reject, this should be indicated to the UE, and the UE shall not access non-PS services until a successful location update is performed.
5/3/2010
Page 15
Blind Release/Redirect to GERAN/UTRAN (FTS for FRS84807, 5.1.2.3)
UE eNodeB MME SGW SGSN GERAN UTRAN PGW
Alcatel – Lucent Proprietary
ME1: Uplink and Downlink User Plane
UE sends event A2_blind when radio conditions in service cell are very bad. Threshold for A2_blind is lower than threshold for A2_MG
(M1) RRC-MeasurementReport (event A2_blind)
eNodeB decides to redirect the UE to GERAN/UTRAN carrier without measurements on target cell
S1 connection released by MME and S1-U bearers removed in SGW
(M4) S1-AP-UE Context Release Command
(M5) S1-AP-UE Context Release Complete
ME2: Cell Selection
ME3: Routing Area Update
ME4: Uplink and Downlink User Plane
5/3/2010
Page 16
Blind Release/Redirect to GERAN/UTRAN (FTS for FRS84807, 5.1.2.3)
Alcatel – Lucent Proprietary
ME1 User plane traffic through eNodeB (Uu), through SGW (S1), PGW (S5gtp), to Internet (Sgi)
CMT1 PRECONDITIONS:- UE is in RRC-CONNECTED mode- UE is GERAN capable- eNB has sent a measurement configuration for serving cell to request the UE to trigger report for event A2_blind. Event A2_blind is triggered by the UE in case a very bad radio condition in the serving cell such that it would be better to move the UE to another cell.- eNB has not received a report event A3 indicating a better LTE neighbor cell.- eNB has not received a report for event B2. Event B2 may not have been configured within UE if bit 23=0
M1 TRIGGER:- reception of event A2_blind is a trigger for mobility decision- eNB decides to release the RRC connection with the UE and to redirect the UE to a GERAN/UTRAN cell without measurements report from the target cell.
CMT2 Could be that UE doesn’t support IRAT handovers or that the PS Handover capability is not available
M2 The source ENB gives a command to the UE to re-select a cell in the target accessnetwork (GERAN) via the RRC CONNECTION RELEASE. The eNodeB builds the RRCConnectionRelease message with theRedirectedCarrierInfo IE, so that the UE selects a suitable 2G/3G frequencyindicated in the RedirectedCarrierInfo in accordance with the usual cell selectionprocess. The eNodeB builds the RRCConnectionRelease message; with the idleModeMobilityControlInfo (optional) so that the UE stores the cell reselection priority information provided by the idleModeMobilityControlInfo; or without the idleModeMobilityControlInfo (optional) so that the UE applies the cell reselection priority information broadcast in the system information.
M3 The source ENB sends an S1AP UE CONTEXT RELEASE REQUEST message to the MME. This message is sent by the eNB to request the release of the UE-associated S1-logical connection over the S1 interface: with ‘Cause IE’ set to ‘Inter-RAT redirection’ to indicate the reason for triggering the UE Context Release Request procedure.Upon receipt of the Redirection Information received in the RRC Connection Release message, the UE leaves EUTRA-FDD cell and start accessing GERAN/UTRAN cell.
M4 S1 connection Released by MME and S1-U bearers remain in SGW
ME2 UE leaves the eUTRAN cell and accesses GERAN/UTRAN cell.The UE first selects a PLMN in which to operate.Normally the UE starts the cell selection with a stored information cell-selection procedure. The UE may have stored the necessary information of the cell it was previously camped on, such as frequency and scrambling code. The UE may first try to synchronize into that cell, and if it fails, it may trigger the initial cell selection.Most of the functionality for initial cell selection is in the physical layer, and the RRC layer has only a management role. The initial cell-selection procedure is performed on one carrier frequency at a time until a suitable cell is found. In principle the process includes the following: 1. Search for primary synchronization channels 2. Once such a channel is found, acquire time-slot synchronization from it; 3. Acquire frame synchronization from the corresponding S-SCH; 4. Acquire the primary scrambling code from the corresponding CPICH; 5. Decode system information from the cell to check whether it is a suitable cell for camping (i.e., it contains the right PLMN code and access to it is allowed). The UE uses this procedure to find a paging channel which contains the broadcast channel, which contains the system information the UE is seeking.
ME3 See existing Routing Area Update message flow
ME4 User plane traffic through GERAN/UTRAN RAN, through SGSN (Gb/IuPS), PGW (Gn-user), to Internet (Sgi)
5/3/2010
Page 17
LTE -> WCDMA Blind HO (Ref: 23.401 V8.8.0 Dec 2009 Sec D.3.3)
LTE -> WCDMA Blind HO (Ref: 23.401 V8.8.0 Dec 2009 Sec D.3.3)
Alcatel - Lucent Proprietary
M1 Source eNodeB decides to initiate LTE -> WCDMA handover. This involves UE sending Event A2 message to eNodeB indicating that UE is experiencing very bad radio condition.
M2 eNodeB sends the MME a “Handover Required Message”. This message contains a Cause Value and a Target RNC.
M3 The MME sees that the “Target RNC” IE and realizes the HO is to WCDMA so it sends a Forward Relocation request to SGSN. This message contains the IMSI and the PDN connections that exist along with the associated APN’s.
M4 The target SGSN maps each PDN context to a “WCDMA” context and then sends a Relocation Request to the target RNC which contains a “RAB to setup list”. It also contains integrity protection and encryption (ciphering) information.
M5 The RNC allocates resources for each RAB. The RNC then sends a Relocation Request Ack to the SGSN. This message will include a list of RABs that were setup or failed to set up. The target RNC is now ready to receive packets
M6 The SGSN then sends a Forward Relocation Response to the MME. This message contains RAB setup information, and information for traffic forwarding (destination tunneling endpoint (RNC)).
M7 MME sends a “Create Bearer Request” to the SGW containing the destination tunneling endpoint for the RNC.
M8 The SGW responds to the MME with a Create Bearer response. SGW now knows where to forward data.
M9 MME sends the eNodeB a “Handover Command” which contains a bearers subject to data forwarding list. This will initiate data forwarding in the eNodeB. Data will be forwarded to the RNC either directly, or indirectly via the SGW.
M10 The eNodeB sends a command to the UE directing it to handover to the WCDMA network. The UE shall associate its bearer ids with respective RABs. UE will suspend any uplink data traffic.
ME1 UE tunes to the UMTS network.
M11 The RNC now sends a Relocation Detect message to the SGSN
M12 The UE sends an RRC message to the RNC indicating the HO is complete. The UE can now send UL data -> RNC -> SGSN -> PGW -> SGi. DL data is now being forwarded.
M13 The RNC now sends a Relocation Complete message to the SGSN to indicate the completion of the UE relocating from the source E-UTRAN to the target WCDMA RNC. The SGSN is ready to receive data from the RNC.
M14 The SGSN will now send a Forward Relocation Complete message to the MME. MME starts a timer to release the resources in the eNodeB and the SGW.
M15 The MME responds to the SGSN with a Forward Relocation Complete Ack message.
M16 The SGSN starts a timer to release the indirect forwarding resources. The SGSN sends a Update PDP Context Request to the PGW. This is to tell the PGW to start sending data to the SGSN instead of the SGW.
M17 The PGW sends a response back to the SGSN and the data is now being sent from the PGW -> SGSN -> RNC -> UE. So no data forwarding is needed.
ME2 Routing Area Update
M18 After timer expires (one that was setup in step M16), the MME will send a message to the SGW to release the ePC resources.
ME3 After timer expires (one that was setup in step M16), the MME will send a message to the eNodeB to release resources. eNodeB releases resources.
M19 SGW deletes the ePC resources and sends a response to the MME.
5/3/2010
Page 20
LTE -> GERAN Blind HO (Ref: 23.401 V8.8.0 Dec 2009 Sec D.3.7)
ME3: SABM UA exchange re-establishment and XID negotiation for LLC ABM
ME4: Routing Area Update:
(M18) S11 Delete Session Request:
(M19) S1 Release Resources
(M20) S11 Delete Bearer Response
ME5: Delete Indirect Data Forwarding Tunnel Request/response
Downlink User Plane
5/3/2010
Page 22
LTE -> GERAN Blind HO (Ref: 23.401 V8.8.0 Dec 2009 Sec D.3.7)
Alcatel - Lucent Proprietary
M1 The source eNodeB decides to initiate an Inter RAT Handover to the target GERAN A/Gb mode (2G) system. This involves UE sending Event A2 message to eNodeB indicating that UE is experiencing very bad radio condition.
M2 The source eNodeB sends a Handover Required (Cause, Target System Identifier, Source eNodeB Identifier, Source BSS to Target BSS Transparent Container) message to the Source MME to request the CN to establish resources in the Target BSS, Target SGSN and the Serving GW.
M3 The Source MME initiates the PS Handover resource allocation procedure by sending a Forward Relocation Request (IMSI, Tunnel Endpoint Identifier Control Plane, RANAP Cause, Target Cell Identifier, MM Context, PDP Contexts, Packet Flow ID, SNDCP XID parameters, LLC XID parameters, PDP Context Prioritisation, Source BSS To Target BSS Transparent Container [RN part] in the BSS Container, Source RNC Id, SGSN Address for control plane) message to the new SGSN.
M4 The new SGSN sends a PS Handover Request (Local TLLI, IMSI, Cause, Target Cell Identifier, Source BSS to Target BSS Transparent Container (RN part), PFCs To Be Set Up List, NAS container for PS HO) message to the target BSS.
CMT2 Based upon the ABQP for each PFC the target BSS makes a decision about which PFCs to assign radio resources. The algorithm by which the BSS decides which PFCs that need resources is implementation specific. Due to resource limitations not all downloaded PFCs will necessarily receive resource allocation. The target BSS allocates TBFs for each PFC that it can accommodate.
CMT3 The target BSS shall prepare the Target BSS to Source BSS Transparent Container which contains a PS Handover Command including the CN part (NAS container for PS HO) and the RN part (PS Handover Radio Resources).
M5 Target BSS shall send the PS Handover Request Acknowledge message (Local TLLI, List of Set Up PFCs, Target BSS to Source BSS Transparent Container) message to the new SGSN.
M6 The new SGSN passes the assigned list of TEIDs for each PDP context for which a PFC was assigned in the RAB setup information IE in the Forward Relocation Response (Cause, List of Set Up PFCs, Target BSS to Source BSS Transparent Container) in the BSS Container, Tunnel Endpoint Identifier Control Plane, SGSN Address for User Traffic, Tunnel Endpoint Identifier Data II) message to the old MME. The Tunnel Endpoint Identifier Data II, one information for each PDP context, is the tunnel endpoint of the new SGSN and is used for data forwarding from the Source eNodeB, via the new SGSN, to the target BSS.
M7 If 'Indirect Forwarding' applies, the source MME sends a Create Indirect Data Forwarding Tunnel Request message (Cause, SGSN Address(es) and TEID(s) for Data Forwarding) to the Serving GW. Cause indicates that the bearer(s) are subject to data forwarding.
M8 The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding) message to the target MME.
M9 The Source MME sends the message Handover Command (Target BSS to Source BSS Transparent Container (PS Handover Command with RN part and EPC part), Bearers Subject to Data Forwarding List).
M10 The Source eNodeB will give a command to the UE to handover to the Target Access System via the message HO from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that the Target BSS has set-up in the preparation phase (RN part). This message also includes the XID and IOV-UI parameters received from the Target SGSN (EPC part).Upon the reception of the HO from E-UTRAN Command message containing the Handover Command message, the UE shall associate its bearer IDs to the respective PFIs based on the relation with the NSAPI and shall suspend the uplink transmission of the user plane data.
ME1 The UE executes the handover.
M11 After accessing the cell using access bursts and receiving timing advance information from the BSS, the MS processes the NAS container and then sends one XID Response message to the new SGSN
M12 Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the UE, the target BSS sends a PS Handover Complete (Local TLLI, Handover Complete Status) message to inform the new SGSN that the UE has arrived in the target cell
5/3/2010
Page 23
LTE -> GERAN Blind HO (Ref: 23.401 V8.8.0 Dec 2009 Sec D.3.7)
Alcatel - Lucent Proprietary
M13 After accessing the cell using access bursts and receiving timing advance information from the BSS, the MS processes the NAS container and then sends one XID Response message to the new SGSN.
M14 Upon receiving the PS Handover Complete message, the new SGSN send a Forward Relocation Complete message to the old SGSN to indicate completion of the PS handover procedures. A timer in source MME is started to supervise when resources in Source eNodeB and Source Serving GW shall be released.
M15 The MME responds with a Forward Relocation Complete Acknowledge message.
M16 The new SGSN sends an Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated) message to the PGW.
M17 The PGW updates the PDP context fields and returns an Update PDP Context Response (TEID) message. From now on the PGW sends new incoming downlink IP packets to the new SGSN instead of to the SGW.
ME2 If the new SGSN indicated Reset (i.e. reset to default parameters) in the NAS container for PS HO included in the Handover from UTRAN Command message (UTRAN) or the Handover from GERAN Iu Command message, then on receipt of the PS Handover Complete the new SGSN initiates an LLC/SNDCP XID negotiation for each LLC SAPI used in LLC ADM. In this case if the SGSN wants to use the default parameters, it shall send an empty XID Command. If the new SGSN indicated 'Reset to the old XID parameters' in the NAS container for PS HO, no further XID negotiation is required for LLC SAPIs used in LLC ADM only.
ME3 The new SGSN (re-)establishes LLC ABM for the PDP contexts which use acknowledged information transfer. During the exchange of SABM and UA the SGSN shall perform LLC/SNDCP XID negotiation.
ME4 Routing Area Update. The new SGSN knows that a handover has been performed for this UE and can therefore exclude the SGSN context procedures which normally are used within the RA Update procedure.
M18 When the timer started at step 8 (Gn Forward Relocation Complete) expires, the source MME deletes the EPS bearer resources by sending Delete Session Request (Cause, TEID) messages to the Serving GW. Cause indicates to the Serving GW that it shall not initiate a delete procedure towards the PDN GW.
M19 When the timer started at step 8 (Gn Forward Relocation Complete) expires, the source MME sends a Release Resources message to the source eNodeB. The Source eNodeB releases its resources related to the UE.
M20 The Serving GW acknowledges with Delete Session Response (TEID) messages.
ME5 When the timer started in step 8 expires and if resources for indirect forwarding have been allocated then they are released.
M1 The UE sends an Activate PDP Context Request (NSAPI, TI, PDP Type, PDP Address, Access Point Name, QoS Requested, Protocol Configuration Options, Request Type) message to the SGSN. The MS may use Access Point Name to select a reference point to a certain packet data network and/or to select a service.
M2 The SGSN sends a Create PDP Context Request (PDP Type, PDP Address, Access Point Name, QoS Negotiated, TEID, NSAPI, MSISDN, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Protocol Configuration Options, serving network identity, Maximum APN Restriction IMEISV, CGI/SAI, RAT type, S-CDR CAMEL information, CGI/SAI/RAI change support indication, NRSN) message to the affected GGSN
M3 The GGSN then returns a Create PDP Context Response (TEID, PDP Address, Protocol Configuration Options, QoS Negotiated, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, CGI/SAI/RAI change report required, BCM) message to the SGSN.
ME1 RAB setup is done by the RAB Assignment procedure
M4 if BSS trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, Trigger Id, OMC Identity) message to the RAN. Trace Reference, and Trace Type are copied from the trace information received from the HLR or OMC. Applied when the trace activation is triggered by means of signaling. Another alternative is the triggering of trace activation by the OMC.
M5 In case the QoS attributes have been downgraded by the SGSN, the SGSN may inform the GGSN about the downgraded QoS attributes by sending an Update PDP Context Request to the affected GGSN. The GGSN shall not attempt to renegotiate the QoS attributes.
M6 The GGSN confirms the new QoS attributes by sending an Update PDP Context Response to the SGSN.
M7 The SGSN inserts the NSAPI along with the GGSN address in its PDP context. The PDP address received from the GGSN or from HSS subscription records is inserted in the PDP context. The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and returns an Activate PDP Context Accept (PDP Type, PDP Address, TI, QoS Negotiated, Radio Priority, Packet Flow Id, Protocol Configuration Options) message to the UE.
M1 The UE sends an Activate PDP Context Request (NSAPI, TI, PDP Type, PDP Address, Access Point Name, QoS Requested, Protocol Configuration Options, Request Type) message to the SGSN. The MS may use Access Point Name to select a reference point to a certain packet data network and/or to select a service.
ME1 Security Function may be executed.
M2 if BSS trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, Trigger Id, OMC Identity) message to the BSS. Trace Reference, and Trace Type are copied from the trace information received from the HLR or OMC.
M3 The SGSN sends a Create PDP Context Request (PDP Type, PDP Address, Access Point Name, QoS Negotiated, TEID, NSAPI, MSISDN, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Protocol Configuration Options, serving network identity, Maximum APN Restriction IMEISV, CGI/SAI, RAT type, S-CDR CAMEL information, CGI/SAI/RAI change support indication, NRSN) message to the affected GGSN
M4 The GGSN then returns a Create PDP Context Response (TEID, PDP Address, Protocol Configuration Options, QoS Negotiated, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, CGI/SAI/RAI change report required, BCM) message to the SGSN.
ME2 BSS packet flow context procedures may be executed
M5 In case the QoS attributes have been downgraded by the SGSN, the SGSN may inform the GGSN about the downgraded QoS attributes by sending an Update PDP Context Request to the affected GGSN. The GGSN shall not attempt to renegotiate the QoS attributes.
M6 The GGSN confirms the new QoS attributes by sending an Update PDP Context Response to the SGSN.
M7 The SGSN inserts the NSAPI along with the GGSN address in its PDP context. The PDP address received from the GGSN or from HSS subscription records is inserted in the PDP context. The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and returns an Activate PDP Context Accept (PDP Type, PDP Address, TI, QoS Negotiated, Radio Priority, Packet Flow Id, Protocol Configuration Options) message to the UE.
