A.1.1 Attach

The User Equipment (UE) needs to register with the network to receive Evolved Packet System (EPS) services like Internet connectivity. This registration is referred to as network attachment, in short Attach. “Always-on” Internet Protocol (IP) connectivity is enabled in EPS by establishing a so-called default EPS bearer during Attach (see Figure A.1).

1. The UE initiates the Attach procedure by sending an Attach Request that is encapsulated in the Radio Resource Control (RRC) connection setup complete message. The RRC message is sent to the Evolved NodeB (eNodeB). The UE provides its Globally Unique Temporary Identity (GUTI) in the Attach, if this is available. If GUTI is not available, it provides its International Mobile Subscriber Identity (IMSI). If an UE without Universal Subscriber Identity Module (USIM) initiates the Attach procedure for emergency services, it may provide its International Mobile Equipment Identity (IMEI). The Attach Type can either be an Initial Attach, Handover, or Emergency. If the UE has valid security parameters, then the Attach Request is integrity protected.
2. The eNodeB forwards the Attach Request to the selected Mobility Management Entity (MME) (either derived from the old Globally Unique Mobile Management Entity Identifier (GUMMEI) or selected based on MME selection function) in a S1-MME control message.
3. If the UE context is not present anywhere in the network (in old or new MME) and the Attach Request was not integrity protected or if the integrity check failed, then authentication and Non Access Stratum (NAS) security setup to activate integrity protection and NAS ciphering are mandatory. Otherwise it is optional during Attach procedure. MME initiates this procedure for authenticating the UE and involves Home Subscriber Server (HSS) to obtain authentication vectors for the UE.
4. The MME sends an Update Location Request message to the HSS to update the records for the given IMSI. This message is sent, if any of the following conditions is true:
   1. MME has changed since the last detach.
   2. There is no valid subscription context for the UE in the MME.
   3. ME identity has changed, and UE provides an IMSI.
   4. UE provides an old GUTI which does not refer to a valid context in the MME or.
   5. UE is not performing an emergency attach.
5. The HSS acknowledges the Update Location message with an Update Location Ack.
6. The MME selects an Serving Gateway (S-GW) and Packet Data Network Gateway (P-GW) and allocates an EPS Bearer Identity for the default bearer associated with the UE. Then it sends a Create Session Request to the selected S-GW to initiate the creation of default bearers for the UE.
7. The S-GW creates a new entry in its EPS Bearer table and sends a Create Session Request to the P-GW.
8. If dynamic policy control (PCC, Policy and Charging Control) is deployed and the handover indication is not present, the P-GW performs IP-Connectivity Access Network (IP-CAN) Session Establishment procedure and thereby obtains the default PCC rules for the UE. If PCC is deployed and the handover indication is present, the P-GW reports the new access type to the Policy and Charging Rules Function (PCRF). If PCC is not deployed, the P-GW may apply local Quality of Service (QoS) policies. Either of these conditions could result in establishment of a number of dedicated bearers for the UE in association or combination with the default bearer.
9. The P-GW creates a new entry in its EPS bearer context table and generates a General Packet Radio Service (GPRS) Charging Correlation Identifier. This allows the P-GW to route user plane packets between the S-GW and the Packet Data Network (PDN) (e.g., the Internet), and to start a new charging session. The P-GW responds to the S-GW with Create Session Response. If the Handover Indication is present, the P-GW does not yet send downlink packets to the S-GW until the downlink path is switched. The S-GW responds to the MME with Create Session Response.
10. The MME determines the UE AMBR to be used by the eNodeB based on the subscribed UE-AMBR and the APN Aggregate Maximum Bit Rate (APN-AMBR) for the default Access Point Name (APN). The MME responds to the UE with Attach Accept. The GUTI is included, if the new MME allocates a new GUTI. This message is contained in the S1-MME control message Initial Context Setup Request. This S1 control message also includes the AS security context information for the UE, the Handover Restriction List, the EPS Bearer QoS, the UE-AMBR, EPS Bearer Identity, as well as the Tunnel Endpoint Identifier (TEID) and the address of the S-GW for user plane traffic.
11. The eNodeB sends the RRC Connection Reconfiguration message including the EPS Radio Bearer Identity along with the Attach Accept to the UE. The APN for which the default bearer is associated is provided to the UE. IP address allocation procedure for the UE is initiated during the attach procedure.
12. The UE sends the RRC Connection Reconfiguration complete message to the eNodeB and the eNodeB sends the Initial Context Response message to the 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.
13. The UE sends a Direct Transfer message to the eNodeB, which includes the Attach Complete.
14. The eNodeB forwards the Attach Complete message to the new MME in an Uplink NAS Transport message. The UE can now send uplink data packets toward the eNodeB, which will then be tunneled to the S-GW and P-GW.
15. The MME sends a Modify Bearer Request message to the S-GW. This includes the EPS bearer ID, eNodeB address, and the eNodeB TEID.
16. The S-GW sends Modify Bearer Request toward P-GW only when UE is connected via non-3GPP (3rd Generation Partnership Program) access. This can be determined based on the presence of the Handover Indication. If the Handover Indication is present, the S-GW sends a Modify Bearer Request message to the P-GW to prompt the P-GW to tunnel packets from non-3GPP IP access to 3GPP access system and immediately start routing packets to the S-GW for the default and any dedicated EPS bearers established.
17. The P-GW sends a Modify Bearer Response to the S-GW and a Modify Bearer Response to the MME. Bearers are now established and ready to exchange uplink and downlink packets.
18. The MME sends a Notify Request to the HSS to update the HSS with APN and P-GW pair. The HSS stores the APN and the P-GW identity pair and sends a Notify Response to the MME.

For further details, please refer to 3GPP TS 23.401 [1].

A.1.2 Detach

The Detach procedure allows the user equipment to inform the network that it does not want to access the network any longer and allows the network to inform the user equipment that it does not have access to the network any longer (see Figure A.2).

1. The UE initiates the Detach procedure by sending a Detach Request to the MME and also indicates, if the detach is due to power off.
2. The MME triggers deletion of established sessions by sending Delete Session Request to the S-GW, which in turn sends it to the P-GW to deactivate all the bearers for the UE. Both P-GW and S-GW release the resources and acknowledge the Delete Session Request.
3. The P-GW employs a Policy Charging Enforcement Function (PCEF) initiated IP-CAN Session Termination Procedure with the PCRF to indicate that EPS bearers are released, if PCC is deployed in the network.
4. If the Detach is not due to a switch off, the MME sends Detach Accept to the UE.
5. The MME releases the S1-MME signaling connection for the UE by sending S1 Release Command to the eNodeB with cause value set to Detach. This triggers the release of logical S1-AP signaling connections over the S1-MME interface and all S1 bearers on S1-U for a UE. The UE moves from ECM-CONNECTED to ECM-IDLE state in both UE and MME. UE-related context information is deleted in the eNodeB.

For further details, please refer to 3GPP TS 23.401 [1].

A.1.3 Tracking Area Update

Once the UE is successfully attached, it needs to keep the network informed about its current location in order to be reachable for downlink signaling and user data even when it is in idle mode, that is, when the signaling connection to the UE has been released. In order to keep the network informed, the UE performs a Tracking Area Update (TAU) (see Figure A.3).

1. The UE sends a TAU request encapsulated within an RRC message to the new eNB, for example, because the tracking area has changed or its periodic TAU timer has expired. The TAU contains information such as old GUTI, last visited Tracking Area Identity (TAI), and EPS bearer status.
2. The eNodeB derives the MME from the RRC parameters such as GUMMEI and the selected network. eNodeB forwards the TAU request to the new MME.
3. The new MME uses the GUTI to derive the old MME and sends a Context Request message to the old MME to retrieve user context information. The new MME provides the complete NAS message TAU Request, including the integrity protection information, with the GPRS Tunneling Protocol (GTP) message Context Request to the old MME to check the integrity of the message. The old MME answers with a Context Response including UE's context data, including the EPS security context, and mobility management and session management information. If the old MME indicates in the Context Response message that the integrity check was not successful, the new MME will authenticate the UE.
4. In this case the new MME decides to relocate the S-GW, for example, because the old S-GW cannot serve the UE any longer. The new MME sends a Context Acknowledge with S-GW change indication to the old MME.
5. The new MME sends a Create Session Request with IMSI, bearer context data, P-GW address, MME Address for each PDN connection to the new S-GW.
6. The new S-GW informs the P-GWs about, for example, a radio access type change (could be Wireless Local Area Network (WLAN) to Evolved Universal Terrestrial Radio Access Network (E-UTRAN)) by sending Modify Bearer Request per PDN connection to the P-GWs. The P-GWs update their bearer contexts and send a Modify Bearer Response.
7. The new S-GW returns a Create Session Response with its own address, user plane, and control plane connection addresses to the new MME.
8. If the new MME has no subscription data for the UE, it sends an Update Location Request to the HSS. MME registration is updated in the HSS, that is, MME address is stored in the HSS as serving node for the UE. In turn the HSS sends Cancel Location to the old MME and an Update Location Ack including the subscription data to the new MME.
9. The old MME deletes bearer resources by sending Delete Session Request to the old S-GW.
10. Finally, the new MME sends a TAU accept with GUTI, TAI list, and EPS bearer status to the UE. If the MME was changed, the new MME will also include a new GUTI which identifies the new MME. If a new GUTI was allocated, the UE has to confirm the receipt of the identity with a NAS message TAU Complete.

For further details, please refer to 3GPP TS 23.401 [1].

A.1.4 Paging

The paging procedure (see Figure A.4) is initiated by the network to request the establishment of a NAS signaling connection to the UE. When the UE is in RRC-IDLE, the UE monitors for paging messages and the frequency for this monitoring is determined by the “DRX cycle in idle mode”.

1. The P-GW receives a downlink IP packet for the UE from an external source (e.g., an Application Server).
2. The P-GW forwards the downlink IP packet to the corresponding S-GW. The route for the packet is determined by flow attributes such as packet filters, Downlink Traffic Flow Template (DL TFT), and TEID.
3. The S-GW receives the packet and determines that the corresponding S1-U tunnel is not established. Thus, it buffers the packet and determines from its context data the corresponding MME that is serving the UE. It sends a Downlink Data Notification (DDN) to the MME that has control plane connectivity for the given UE. The Address Resolution Protocol (ARP) and EPS Bearer ID are always set in Downlink Data Notification. The MME responds with a Downlink Data Notification Ack message. The priority indicator, that is ARP, is derived from the bearer triggering the Downlink Data Notification.
4. The MME receives the Downlink Data Notification message. It determines whether the UE is registered in the MME. The MME uses parameters such as EPS bearer ID, ARP to determine the paging strategy (i.e., paging in all TAIs of the stored TAI list, stepwise paging by initially paging only in the last known eNB or last known TAI, etc.). Accordingly, it initiates a paging message toward the eNB over S1-AP.
5. The eNB initiates paging based on UE's idle mode paging DRX cycle.

For further details, please refer to 3GPP TS 23.401 [1] and 3GPP TS 24.301 [2].

A.1.5 Service Request

The Service Request can be sent by the UE either based on pending UL data or signaling messages or in response to a paging message from the network. Service Request (see Figure A.5) is normally sent to request the establishment of a NAS signaling connection.

1. The UE sends a NAS message Service Request toward the MME. The NAS message is encapsulated in an RRC message sent to the eNB.
2. The eNB forwards the NAS message to the MME. The NAS message is encapsulated in an S1-AP Initial UE message. The Initial UE message also includes the TAI and ECGI of the cell and the S-TMSI. The MME can use the S-TMSI to locate the UE context.
3. NAS authentication/security procedures may be performed. This is an optional step during a Service Request procedure.
4. The MME sends a S1-AP Initial Context Setup Request to the eNB. It contains, for example, S-GW address, S1-TEID(s), EPS Bearer QoS(s), Security Context, and MME Signaling Connection ID. This step activates the radio and S1 bearers for all active EPS bearers. The eNB stores the Security Context, MME Signaling Connection Id, EPS Bearer QoS(s), and S1-TEID(s) in the UE context.
5. The eNB performs the radio bearer establishment procedure. The user plane security is established at this step. When the user plane radio bearers are setup, EPS bearer state synchronization is performed between UE and network, that is, the UE shall locally remove any EPS bearers for which no radio bearers are setup and, if the radio bearer for a default EPS bearer is not established, the UE shall locally deactivate all EPS bearers associated to that default EPS bearer.
6. The UL data from UE can now be forwarded by the eNB to the S-GW and P-GW.
7. The eNodeB sends an S1-AP Initial Context Setup Complete to the MME. It includes the eNB address, S1 TEID(s) for the DL, list of accepted EPS bearers, and list of rejected EPS bearers.
8. The MME sends a Modify Bearer Request per PDN connection to the S-GW. This includes all the parameters such as S1 TEID(s) provided by the eNB. The S-GW is now able to transmit DL data toward the UE. If a default EPS bearer is not accepted by the eNB, all the EPS bearers associated to that default bearer shall be treated as non-accepted bearers. The MME releases the non-accepted bearers by triggering the bearer release procedure.
9. If a RAT type change was requested by the P-GW and the RAT type has changed, the S-GW shall send the Modify Bearer Request per PDN connection to the P-GW. If the S-GW receives a DL packet for a non-accepted bearer, the S-GW drops the DL packet and does not send a Downlink Data Notification to the MME.
10. If dynamic PCC is deployed, the P-GW interacts with the PCRF to get the PCC rule(s) according to the Radio Access Type (RAT) type. If dynamic PCC is not deployed, the P-GW may apply local QoS policies.
11. The P-GW sends the Modify Bearer Response to the S-GW.
12. The S-GW sends the Modify Bearer Response to the MME.

For further details, please refer to 3GPP TS 23.401 [1] and 3GPP TS 24.301 [2].

A.1.6 X2-Based Handover

If both eNodeBs are connected to the same MME, source eNodeB and target eNodeB can exchange the S1AP signaling for the handover preparation and execution directly via the X2 interface. In this case we are talking about X2-based handover (see Figure A.6).

1. Once the source eNodeB determines that a handover is required (e.g., based on signal strength measurements), it initiates the so-called handover preparation procedure. Within this procedure, the source eNodeB sends a handover command to the UE. During handover execution, user data can be forwarded from the source eNodeB to the target eNodeB without involving the EPC.
2. After handover execution, the target eNodeB sends a Path Switch request to MME to inform that the UE has changed cell, including TAI and ECGI of the target cell and the list of EPS bearers.
3. The MME determines that the S-GW can serve the UE and sends a Modify Bearer Request to the S-GW for each PDN connection that has been accepted by the target eNodeB.
4. The MME releases dedicated bearers that were not accepted. If the S-GW receives a DL packet for a non-accepted bearer, it drops the packet. If the default bearer of a PDN connection has not been accepted by the target eNodeB and multiple PDN connections are active, the MME releases the whole PDN connection for which the default bearer was not accepted.
5. If required, the S-GW sends a Modify Bearer Request to the P-GWs to inform them about changed user location or time zone. This message is sent per PDN connection.
6. The S-GW sends DL packets to the target eNodeB. A Modify Bearer Response is sent to the MME.
7. To allow reordering of packets in the target eNodeB, the S-GW sends “end marker” packets on the old path immediately after switching the path.
8. The MME confirms the Path Switch Request with the Path Switch Request Ack. If the UE-AMBR is changed, the MME provides the updated value of UE-AMBR to the target eNodeB in the Path Switch Request Ack message. If some bearers have not been switched, the MME shall indicate the failed bearers in the Path Switch Request Ack. Resources for failed dedicated bearers are released. The target eNodeB also removes corresponding bearer context data.
9. The target eNodeB sends Release Resource to the source eNodeB.
10. Finally, the UE might send a TAU request to the new eNodeB depending on the TAI and other TAU triggering criteria.

For further details, please refer to 3GPP TS 23.401 [1] and 3GPP TS 36.300 [3].

A.1.7 S1-Based Handover

S1-based handover is used in cases when X2-based handover cannot be used, for example, when source eNodeB and target eNodeB are served by different MMEs or have no direct X2 connection. During the handover preparation (see Figure A.7), the signaling information is exchanged between source eNodeB and target eNodeB via the involved MME(s), that is, messages are sent via the S1 interfaces, and possibly via the S10 interface between the MME(s).

1. The source eNodeB decides to initiate a S1-based handover to the target eNodeB, for example, as there is no X2 connection to the target eNodeB.
2. The source eNodeB sends Handover Required including target eNodeB identity and target TAI to the source MME. The target TAI is used by the source MME to select a target MME.
3. If the MME is relocated, the source MME sends Forward Relocation Request with the MME UE context and target TAI to the target MME. The target TAI is used by the target MME to determine whether S-GW relocation is needed and to select the new S-GW. The MME UE context includes IMSI, ME identity, UE security context, AMBR, S-GW address, and EPS bearer context data (e.g., P-GW addresses, APN, and S-GW addresses). If the MME has been relocated, the target MME decides whether the S-GW has to be relocated, otherwise the source MME decides whether S-GW needs to be relocated.
4. If a new S-GW is selected, the target MME sends a Create Session Request per PDN connection to the target S-GW. The target S-GW allocates the S-GW addresses and TEIDs for the uplink traffic and sends a Create Session Response to the target MME.
5. The Target MME sends a Handover Request with EPS Bearers to setup and AMBR to the target eNodeB. This message creates the UE context in the target eNodeB, including information about the bearers and the security context. For each EPS bearer to be setup, it includes S-GW address and uplink TEID for the user plane and the bearer QoS.
6. The target eNodeB sends a Handover Request Acknowledge with a list of EPS bearers to be setup and EPS bearers failed to setup to the target MME. The EPS Bearer setup list includes a list of addresses and TEIDs allocated at the target eNodeB for downlink traffic on the S1-U reference point and addresses and TEIDs for receiving forwarded data if necessary. If the UE-AMBR is changed, the MME shall recalculate the new UE-AMBR and signal the modified UE-AMBR value to the target eNodeB. If none of the default EPS bearers have been accepted by the target eNodeB, the target MME rejects the handover.
7. If indirect forwarding applies and the S-GW is relocated, the target MME sets up forwarding parameters by sending Create Indirect Data Forwarding Tunnel Request to the S-GW. The S-GW sends a Create Indirect Data Forwarding Tunnel Response to the target MME. If the S-GW is not relocated, indirect forwarding can be set up later on.
8. If the MME has been relocated, the target MME sends a Forward Relocation Response to the source MME. For indirect forwarding, this message includes the S-GW address and TEIDs for indirect forwarding.
9. If indirect forwarding applies, the source MME sends Create Indirect Data Forwarding Tunnel Request to the S-GW. If the S-GW is relocated, it includes the tunnel identifier to the target S-GW. The S-GW responds with Create Indirect Data Forwarding Tunnel Response to the source MME.

Procedure for the S1 HO execution phase (Figure A.8):

1. Once the handover preparation phase is completed, the source MME sends a Handover Command including list of bearers that are subject to forwarding and bearers to release to the source eNodeB. The list of bearers that are subject to forwarding includes a list of addresses and TEIDs allocated for forwarding. The Handover Command is sent to the UE. Upon reception of this message, the UE will remove any EPS bearers for which it did not receive the corresponding EPS radio bearers in the target cell.
2. The source eNodeB may send Status Transfer to the target eNodeB via the MME to convey the status of the radio bearers. In case of MME relocation, the source MME sends this information to the target MME via Forward Access Context Notification. The source or target MME sends the information then to the target eNodeB.
3. The source eNodeB forwards downlink data received by the source eNodeB towards the target eNodeB for bearers subject to data forwarding.
4. After the UE has synchronized to the target cell, it sends a Handover Confirm to the target eNodeB. Downlink packets forwarded from the source eNodeB are sent to the UE. Uplink packets are forwarded to the target S-GW and to the P-GW. The target eNodeB sends a Handover Notify with TAI and ECGI to the target MME.
5. If the MME has been relocated, the target MME sends a Forward Relocation Complete Notification to the source MME. The source MME sends a Forward Relocation Complete Acknowledge to the target MME.
6. The MME sends a Modify Bearer Request including eNodeB address and TEID allocated for downlink traffic for the accepted bearers to the target S-GW for each PDN connection, including the PDN connections that need to be released. If the S-GW supports Modify Access Bearers Request procedure and if there is no need for the S-GW to send signaling messages to the P-GW (e.g., user location or time zone data required for charging), the MME may send Modify Access Bearers Request per UE to the S-GW.
7. The MME releases the non-accepted dedicated bearers. If the S-GW receives a DL packet for a non-accepted bearer, it drops the packet.
8. If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are other PDN connections active, the MME releases this connection.
9. If the S-GW is relocated, the target S-GW assigns addresses and TEIDs per bearer for downlink traffic. It sends a Modify Bearer Request including its addresses for user plane and TEIDs per PDN connection to the P-GWs. The S-GW allocates downlink TEIDs on S5/S8 interfaces also for non-accepted bearers. The P-GW updates its context data and returns a Modify Bearer Response with charging ID and MSISDN to the target S-GW. The P-GW sends downlink packets to the target S-GW, which will be forwarded to the target eNodeB. If the S-GW is not relocated, it sends also necessary information such as user location or time zone to the P-GWs by a Modify Bearer Request. This message is answered by the P-GW with a Modify Bearer Response. If the S-GW is relocated, the P-GW sends one or more “end marker packets” on the old path to allow the reordering of packets in the target eNodeB. The source S-GW forwards “end marker packets” to the source eNodeB.
10. The S-GW returns a Modify Bearer Response or a Modify Access Bearers Response with its address and TEIDs for uplink traffic to the MME. If the S-GW does not change, it sends one or more “end marker packets” on the old path after switching the path.
11. The UE may initiate a TAU. The target MME performs only a subset of the TAU procedure, for example, context data are not transferred between source and target MME.
12. The source MME sends a UE Context Release Command to the source eNodeB. The source eNodeB releases its resources related to the UE and responds with a UE Context Release Complete. If the source MME received the S-GW change indication in the Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Session Request to the source S-GW. The source S-GW acknowledges with Delete Session Response.
13. If indirect forwarding was used, the source MME sends a Delete Indirect Data Forwarding Tunnel Request to the (source and/or target) S-GW to release temporary resources.

For further details, please refer to 3GPP TS 23.401 [1] and 3GPP TS 36.300 [3].

A.1.8 MBMS Session Start

The BM-SC initiates the MBMS Session Start procedure (see Figure A.9) when it is ready to send DL data. This is a request to activate all necessary bearer resources in the network for the transfer of MBMS data and to notify interested UEs of the imminent start of the data transmission.

1. BM-SC sends a Session Start Request toward MBMS GW(s) to initiate MBMS sessions. It also indicates the impending transmission of downlink data and provides the attributes that are relevant for the session. Some key attributes are TMGI, Flow ID, QoS, MBMS service area, duration of the session, time to MBMS data transfer, and MBMS data transfer start. In addition, BM-SC also provides a list of MME(s) that are relevant for the session. The MBMS GW responds with a Session Start Response message.
2. The MBMS GW creates an MBMS bearer context for the session. It sends a Session Start Request including the session attributes received from the BM-SC. In addition, it also includes transport network IP multicast address, IP address of the multicast source, and GTP TEID to the list of MMEs that were provided by the BM-SC. Data are transmitted to eNB(s) using IP multicast. This avoids replication of user data in multiple GTP tunnels toward all the eNB(s) in the service area.
3. MME creates an MBMS context for the session. It sends a Session Request with all the session attributes received from the MBMS GW. It can either send the Session Request to all the connected Multicell Coordination Entity (MCE)(s) or only to certain MCE(s) based on service area.
4. The E-UTRAN network establishes the necessary radio resources for the transfer of MBMS data to the interested UEs. MCE checks whether the radio resources are sufficient for the establishment of new MBMS service(s) in the area it controls. If resources are available, MCE sends MBMS Session Start to the eNBs in the targeted service area. If not, MCE decides not to establish the radio bearers of the MBMS service(s) and does not forward the MBMS Session Start Request to the involved eNBs. It may also decide to preempt radio resources from other radio bearer(s) of ongoing MBMS service(s) according to the ARP. The MCE confirms the reception of the MBMS Session Start Request to the MME.
5. MCE sends the MBMS Session Start to the eNBs in the targeted MBMS service area. eNBs confirm the reception of the MBMS Session Start message.
6. MCE sends the MBMS scheduling information message to the eNBs including the updated Multicast Control Channel (MCCH) information, which carries MBMS service's configuration information. eNBs confirm the reception of this message.
7. The eNB indicates MBMS Session Start to UEs by MCCH change notification and updated MCCH information, which carries MBMS service's configuration information. eNB joins the IP multicast group to receive the downlink user plane data from MBMS GW.
8. The BM-SC starts sending the MBMS data toward MBMS-GW. MBMS GW sends the data using IP multicast distribution toward all joined eNBs.
9. The eNB transmits MBMS user data in a synchronized manner to all the interested UE(s).

For further details, please refer to 3GPP TS 23.246 [4] and 3GPP TS 36.300 [3].

A.1.9 MBMS Session Stop

The BM-SC initiates the MBMS Session Stop procedure (see Figure A.10) when it considers the MBMS session to be terminated.

1. The BM-SC sends a Session Stop Request to the MBMS GW(s) to indicate the end of a session and that the bearer plane resources can be released. The MBMS context can be uniquely identified by the TMGI and Flow ID. BM-SC sets the status of the MBMS Bearer Context to “Standby.”
2. The MBMS GW releases the MBMS bearer context in case of a broadcast MBMS bearer service and responds to the BM-SC with Session Stop Response.
3. The MBMS GW forwards Session Stop Request to the MME(s) to which it previously sent the Session Start Request and it sets the status of its MBMS bearer context to “Standby.”
4. The MME sets the status of its MBMS bearer context to “Standby” and responds to the MBMS GW with Session Stop Response.
5. The MME forwards Session Stop Request to the MCE(s) to which it previously sent the Session Start Request.
6. Each MCE responds with Session Stop Response to the MME. The MME releases the MBMS bearer context.
7. Each MCE forwards the Session Stop to the eNBs. The eNB confirms the reception of the MBMS Session Stop.
8. The MCE sends the MBMS scheduling information message to the eNBs including the updated MCCH information, which carries MBMS service's configuration information. The eNB confirms the reception of this message.
9. The eNB indicates MBMS session stop to UEs by removing any service configuration associated with the stopped session from the updated MCCH message. The corresponding E-RAB is released, and eNB leaves the IP multicast group.

For further details, please refer to 3GPP TS 23.246 [4] and 3GPP TS 36.300 [3].

A.1.10 MBMS Session Update

The BM-SC initiates a MBMS Session Update procedure (see Figure A.11) when attributes such as service area or bearer ARP value for an ongoing MBMS session have to be modified. This procedure can be used to notify eNBs to join or leave a service area or change the priority of an ongoing group communication service.

1. The BM-SC sends a Session Update Request to the MBMS GW, which includes information such as TMGI, Flow Identifier, session identifier, QoS, service area, estimated session duration, time to data transfer, data transfer start, and a list of MBMS control plane nodes. TMGI and session identifier are used to identify the ongoing session. Except the ARP parameter, all other QoS parameters should be identical as in the MBMS Session Start Request. The ARP parameter may be different if it needs to be updated. Service area and list of MBMS control plane nodes can define the new MBMS service area. The estimated session duration shall be set to a value corresponding to the remaining part of the session. The MBMS GW sends a Session Update Response to the BM-SC.
2. The MBMS GW sends an MBMS Session Start Request to newly added MMEs, an MBMS Session Stop Request to removed MMEs, and an MBMS Session Update Request to all other MMEs in the control plane node list.
3. The MME sends an MBMS Session Update Request including the new session attributes received from the MBMS GW. It can either send the Session Update Request to all the connected MCE(s) or only to certain MCE(s) based on service area. MCE(s) eventually forward it to the eNB(s) that belong to the service area. If at least one node newly added to the MBMS service area accepts the Session Update Request and the proposed IP multicast and source address for backbone distribution, the MME includes an indication that IP multicast distribution is accepted in the MBMS Session Update Response to MBMS GW. If at least one of the nodes does not accept these addresses, the MME uses normal point-to-point MBMS bearer establishment procedure for these nodes and responds with an MBMS Session Update Response providing the tunnel identifier for bearer plane that the MBMS GW has to use.
4. If the E-UTRAN network has no MBMS bearer context with the TMGI indicated in the MBMS Session Update Request, it creates an MBMS bearer context. Otherwise the E-UTRAN updates the existing context. E-UTRAN responds to the MME with a Session Update Response. The MME updates the session attributes in its MBMS bearer context and responds to the MBMS GW.
5. The E-UTRAN network establishes or releases radio resources for the transfer of MBMS data. If the ARP parameter is updated, the MCE shall ensure that any necessary changes to radio resources are synchronized across all eNodeBs in the corresponding MBSFN area. For E-UTRAN, the radio resource set up is scheduled using the MBMS data transfer start parameter, if present, otherwise using the time to MBMS data transfer parameter, if present.
6. The eNodeBs send IP multicast Join or Leave messages to the received user plane IP multicast address allocated by the MBMS GW.

For further details, please refer to 3GPP TS 23.246 [4] and 3GPP TS 36.300 [3].

A.1.11 UE-requested PDN Connectivity

EPS supports simultaneous exchange of IP traffic via multiple PDNs through the use of separate P-GWs or a single P-GW. This is controlled by operator policies and defined in the user subscription. Hence, EPS supports UE-initiated connectivity establishment in order to allow multiple PDN connections to one or more PDNs. This procedure may trigger establishment of dedicated EPS bearers(s) for that UE. During the attach procedure, PDN connectivity request is piggybacked within the attach request. If the UE is requesting for an additional PDN connection, this can be performed after successful normal Attach and UE can send a stand-alone PDN connectivity request message. In this case, the Activate EPS Default Bearer Context procedure is initiated in response to the UE requested PDN Connectivity request message (see Figure A.12).

1. The UE initiates additional PDN Connectivity request procedure by sending PDN Connectivity Request. It specifies the type of PDN requested. If it is requesting PDN connectivity for emergency services, this is specified in the request type.
2. If the MME receives a PDN Connectivity Request from an emergency attached UE or the PDN Connectivity Request is for normal services and the mobility or access restrictions do not allow the UE to access normal services, the MME rejects this request. If the PDN connection is requested for emergency services by a normally attached UE, the MME selects a P-GW from the VPLMN based on APN or the statically configured P-GW from the emergency configured data stored within the MME. Upon selection of S-GW and P-GW, MME initiates the session creation for the UE with S-GW and P-GW and responds to the UE with Activate Default EPS Bearer Context Request. The network allocates an IP address for the UE as part of the default bearer activation procedure.
3. The UE responds with Activate Default EPS Bearer Context Accept.

For further details, please refer to 3GPP TS 23.401 [1] and 3GPP TS 24.301 [2].

A.1.12 Dedicated Bearer Context Activation

With this procedure the network can establish a dedicated bearer for a UE fulfilling special QoS requirements. As an example, the network can detect establishment of a VoLTE call and decide to establish a dedicated voice bearer (see Figure A.13).

1. If dynamic PCC is deployed, IP-CAN session modification procedure can be a trigger for the dedicated bearer activation procedure.
2. The P-GW uses the QoS policy to assign the EPS Bearer QoS. It sends a Create Bearer Request to the S-GW.
3. The S-GW sends Create Bearer Request to the MME. If the UE is in ECM-IDLE state, the MME will trigger the Network Triggered Service Request procedure in which case steps 4–7 are either combined in to that procedure or performed stand alone.
4. The MME selects an EPS Bearer Identity, which has not yet been assigned to the UE. The MME builds a Session Management Request. The MME includes the EPS bearer identity of the associated default bearer as the linked EPS bearer identity. The MME signals the Bearer Setup Request which includes the Session Management request message to the eNodeB.
5. The eNodeB maps EPS Bearer QoS to Radio Bearer QoS. It then sends a RRC Connection Reconfiguration message to the UE. The UE stores the EPS bearer identity. The linked EPS bearer identity included in the Session Management request indicates to the UE to which default bearer, IP address, and PDN the dedicated bearer is linked to.
6. The UE acknowledges the radio bearer activation to the eNodeB with a RRC connection reconfiguration complete message.
7. The eNodeB acknowledges the bearer activation to the MME with Bearer Setup Response. The eNodeB indicates whether the requested EPS Bearer QoS can be allocated or not.
8. The UE builds a Session Management Response including EPS Bearer Identity. The UE then sends a Direct Transfer including Session Management Response to the eNodeB.
9. The eNodeB sends an Uplink NAS Transport message to the MME.
10. Upon receipt of Bearer Setup Response (step 7) and Session Management Response (step 9), the MME acknowledges the bearer activation to the S-GW by sending a Create Bearer Response.
11. The S-GW acknowledges the bearer activation to the P-GW by sending a Create Bearer Response.
12. If the dedicated bearer activation procedure was triggered by the PCRF, the P-GW indicates to the PCRF whether the requested QoS policy could be enforced or not, completing the PCRF-Initiated IP-CAN Session Modification procedure.

For further details, please refer to 3GPP TS 23.401 [1] and 3GPP TS 24.301 [2].