Section: 5.3.4B.2 Mobile Originated Data Transport in Control Plane CIoT EPS Optimisation with P-GW connectivity
Content: Figure 5.3.4B.2-1: MO Data transport in NAS PDU 0. The UE is ECM-IDLE. 1. The UE establishes a RRC connection or sends the RRCEarlyDataRequest message as defined in TS 36.300[ Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 ]  [5] and sends as part of it an integrity protected NAS PDU. The NAS PDU carries the EPS Bearer ID and encrypted Uplink Data. For IP PDN type PDN connections configured to support Header Compression, the UE shall apply header compression before encapsulating data into the NAS message. The UE may also indicate in a NAS Release Assistance Information in the NAS PDU whether no further Uplink or Downlink Data transmissions are expected, or only a single Downlink data transmission (e.g. Acknowledgement or response to Uplink data) subsequent to this Uplink Data transmission is expected. 1b. In the NB-IoT case, the eNodeB, based on configuration, may retrieve the EPS negotiated QoS profile from the MME, if not previously retrieved. The MME Code within the S-TMSI in the RRCConnectionRequest message is used to identify the MME. In the case of network sharing, the MME Codes shall be unique within the area of overlapping MME pools of the participating operators. The eNodeB may apply prioritisation between requests from different UEs before triggering step 2 and throughout the RRC connection. The eNodeB may retrieve additional parameters (e.g., UE Radio Capabilities - see TS 36.413[ Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) ]  [36]). 2. The NAS PDU sent in step 1 is relayed to the MME by the eNodeB using a S1-AP Initial UE message. If the RRCEarlyDataRequest message was received in step 1, the eNodeB includes the "EDT Session" indication in the S1-AP Initial UE message. To assist Location Services, the eNodeB indicates the UE's Coverage Level to the MME. If the NAS Release Assistance Information is received from the UE it overrides the Traffic Profile (see TS 23.682[ Architecture enhancements to facilitate communications with packet data networks and applications ]  [74]) and the MME does not send the Traffic Profile to the eNodeB. 3. If there is a Service Gap timer running in the MME MM Context for the UE and the MME is not waiting for a MT paging response from the UE, the MME rejects the request by discarding the NAS data PDU and sending a Service Reject message to the UE with an appropriate cause. The MME may also provide UE with a Mobility Management Back-off timer set to the remaining value of Service Gap timer, followed by executing step 15. The MME checks the integrity of the incoming NAS PDU and decrypts the data it contains. When the ROHC is configured to be used, the MME shall decompress the IP header if header compression applies to the PDN connection. The MME performs (and the UE responds to) any EMM or ESM procedures if necessary, e.g. the security related procedures. Steps 4 to 9 can continue in parallel to this, however, steps 10 and 11 shall await completion of all the EMM and ESM procedures. 4a. If the S11-U connection is not established, the MME sends a Modify Bearer Request message (MME address, MME TEID DL, Delay Downlink Packet Notification Request, RAT Type, LTE-M RAT type reporting to PGW flag, MO Exception data counter) for each PDN connection to the Serving GW. The Serving GW is now able to transmit downlink data towards the UE. The usage of the Delay Downlink Packet Notification Request Information Element is specified in clause 5.3.4.2 with reference to the UE initiated service request procedure, but it equally applies in this case. The MME shall indicate S11-U tunnelling of NAS user data and send its own S11-U IP address and MME DL TEID for DL data forwarding by the SGW. Also, regardless of whether the S11-U was already established: - If the PDN GW requested UE's location and/or User CSG information and the UE's location and/or User CSG information has changed, the MME shall send the Modify Bearer Request message and also includes the User Location Information IE and/or User CSG Information IE in this message. - If the Serving Network IE has changed compared to the last reported Serving Network IE then the MME shall send the Modify Bearer Request message and also includes the Serving Network IE in this message. - If the UE Time Zone has changed compared to the last reported UE Time Zone then the MME shall send the Modify Bearer Request message and include the UE Time Zone IE in this message. If the RAT type currently used is NB-IOT this shall be reported as different from other E-UTRA flavours. If the UE is using the LTE-M RAT type and the PDN GW expects the LTE-M RAT type reporting as specified in clause 5.11.5, the MME also includes the LTE-M RAT type reporting to PGW flag to indicate to the Serving GW to forward the LTE-M RAT type to the PDN GW. The MME only includes MO Exception data counter if the RRC establishment cause is set to "MO exception data" and the UE is accessing via the NB-IoT RAT. The Serving GW indicates each use of this RRC establishment cause by the related counter on its CDR. The MME maintains the MO Exception Data Counter for Serving PLMN Rate Control purposes (see clause 4.7.7.2). The MME may immediately send the MO Exception Data Counter to the Serving GW. Alternatively, in order to reduce signalling, the MME may send the MO Exception Data Counter to the Serving GW as indicated in TS 29.274[ 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 ]  [43]. 4b If the S11-U connection is established and the UE is accessing via the NB-IoT RAT with the RRC establishment cause set to "MO exception data", the MME should notify the Serving Gateway. The MME maintains the MO Exception Data Counter for Serving PLMN Rate Control purposes (see clause 4.7.7.2). The MME may immediately send the MO Exception Data Counter to the Serving GW. Alternatively, in order to reduce signalling, the MME may send the MO Exception Data Counter to the Serving GW as indicated in TS 29.274[ 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 ]  [43]. 5. If the RAT Type has changed compared to the last reported RAT Type or if the UE's Location and/or Info IEs and/or UE Time Zone and Serving Network id are present in step 4, the Serving GW shall send the Modify Bearer Request message (RAT Type, MO Exception data counter) to the PDN GW. User Location Information IE and/or User CSG Information IE and/or Serving Network IE and/or UE Time Zone are also included if they are present in step 4. If LTE-M RAT type and the LTE-M RAT type reporting to PGW flag were received at step 4a, the Serving GW shall include the LTE-M RAT type in the Modify Bearer Request message to the PGW. Otherwise the Serving GW includes RAT type WB-E-UTRAN. If the Modify Bearer Request message is not sent because of above reasons and the PDN GW charging is paused, then the SGWS-GW shall send a Modify Bearer Request message with PDN Charging Pause Stop Indication to inform the PDN GW that the charging is no longer paused. Other IEs are not included in this message. If the Modify Bearer Request message is not sent because of above reasons but the MME indicated MO Exception data counter, then the Serving Gateway should notify the PDN GW that this RRC establishment cause has been used by the indication of the MO Exception Data Counter (see TS 29.274[ 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 ]  [43]). The Serving GW indicates each use of this RRC establishment cause by the related counter on its CDR. 6. The PDN GW sends the Modify Bearer Response to the Serving GW. The PDN GW indicates each use of the RRC establishment cause "MO Exception Data" by the related counter on its CDR. 7. If a Modify Bearer Request message was sent at step 4 the Serving GW shall return a Modify Bearer Response (Serving GW address and TEID for uplink traffic) to the MME as a response to a Modify Bearer Request message. The Serving GW address for S11-U User Plane and Serving GW TEID are used by the MME to forward UL data to the SGW. 8. The MME sends Uplink data to the P-GW via the S-GW. 9. If no Downlink Data are expected based on the NAS Release Assistance Information from the UE in step 1, this means that all application layer data exchanges have completed with the UL data transfer, and if the MME is not aware of pending MT traffic and S1-U bearers are not established, step 10 is skipped and step 11 applies. Otherwise, Downlink data may arrive at the P-GW and the P-GW sends them to the MME via the S-GW. If no data is received steps10-12 are skipped and the eNodeB may trigger step 14 after step 13 detects no activity. While the RRC connection is active, the UE may still send Uplink data and may receive Downlink data in NAS PDUs that are carried in a S1AP Uplink or (respectively) Downlink messages (not shown in the figure). At any time the UE has no user plane bearers established it may provide NAS Release Assistance Information with the Uplink data. In this case, to assist Location Services, the eNodeB may indicate, if needed, the UE's Coverage Level to the MME. 10. If Downlink data are received in step 9, the MME encrypts and integrity protects the Downlink data. 11. If step 10 is executed then Downlink data are encapsulated in a NAS PDU and sent to the eNodeB in a S1-AP Downlink NAS Message. If the configuration in the MME indicates that the eNodeB supports acknowledgements of downlink NAS data PDUs and if acknowledgements of downlink NAS data PDUs are enabled in the subscription information for the UE, the MME indicates in the S1-AP Downlink NAS message that acknowledgment is requested from the eNodeB. For IP PDN type PDN connections configured to support Header Compression, the MME shall apply header compression before encapsulating data into the NAS message. If step 10 is not executed, or NAS Service Accept message is not to be sent, the MME sends Connection Establishment Indication message to the eNodeB to complete the establishment of the UE-associated logical S1-connection. The UE Radio Capability may be provided from the MME to the eNodeB in the DL NAS Transport message or Connection Establishment Indication message, and the eNodeB shall store the received UE Radio Capability information as specified in TS 36.300[ Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 ]  [5]. If the NAS Release Assistance Information was received with Uplink data and it indicated that Downlink data was expected, it means that the next downlink packet following the sending of the NAS Release Assistance Information is the last packet of the application layer data exchange, then for this case, unless the MME is aware of additional pending MT traffic and unless S1-U bearers are established, the MME sends a S1 UE Context Release Command immediately after the S1-AP message including the Downlink data encapsulated in NAS PDU as an indication that the eNodeB shall release the RRC connection promptly after successfully sending data to the UE. Alternatively, if "EDT Session" indication was received in step 2, the MME may include End Indication for no further data in the S1-AP message including the Downlink data encapsulated in NAS PDU. If the MME includes the End Indication indicating no further data and if the eNodeB does not proceed with RRC connection establishment, then the eNodeB skips step 12a and initiates step 12b. If the NAS Release Assistance Information was received indicating no Downlink Data expected, it means that all application layer data exchanges have completed with the UL data transfer, then for this case, unless the MME is aware of additional pending MT traffic and unless S1-U bearers are established: - the MME sends S1AP UE Context Release Command either: - immediately after the S1AP DL NAS TRANSPORT (NAS Service Accept), in which case steps 12b and 14 are skipped, or - immediately after S1AP CONNECTION ESTABLISHMENT INDICATION, in which case steps 12a, 12b, 13, and 14 are skipped. - Alternatively, if the MME received "EDT Session" indication from the eNodeB in step 2, the MME should include End Indication with no further data in S1AP DL NAS TRANSPORT (NAS Service Accept) or S1AP CONNECTION ESTABLISHMENT INDICATION. If the eNodeB does not proceed with RRC connection establishment, the eNodeB skips step 12a and initiates stop 12b. If the UE is accessing via an NB-IoT cell, or if it is accessing via an WB-E-UTRAN cell and is capable of CE mode B, to determine the NAS PDU retransmission strategy the MME should take into account the transmission delay of the NAS PDU and the CE mode B Restricted parameter stored in the MME's MM context and, if applicable, the CE mode, i.e. set the NAS timers long enough according to the worst transmission delay (see TS 24.301[ Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3 ]  [46]). 12a. The eNodeB sends a RRC Downlink data message including the Downlink data encapsulated in NAS PDU. If in step 11 the S1-AP message with the NAS DATA PDU was followed by an S1 UE Context Release Command, step 15 is completed promptly after the Downlink Data transmission of the NAS PDU to the UE and the acknowledgement to MME in step 13 have been completed at the eNodeB, and the eNodeB does not need to enter step 14. If header compression was applied to the PDN, the UE would perform header decompression to rebuild the IP header. 12b. If End Indication with no further data is received in S1AP message from the MME, the eNodeB may send the RRCEarlyDataComplete message with any NAS payload received from step 11 (either NAS data PDU or NAS service accept) as defined in TS 36.300[ Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 ]  [5]. Step 14 is skipped in this case. 13. The eNodeB sends a NAS Delivery indication to the MME if requested. If the eNodeB reports an unsuccessful delivery with an S1-AP NAS Non Delivery Indication, the MME should wait for some time until the UE has potentially changed cell and re-established contact with the MME, by which MME should resend the Downlink S1-AP message to the eNodeB, otherwise the MME reports an unsuccessful delivery to the SCEF in the case of T6a procedure (see TS 23.682[ Architecture enhancements to facilitate communications with packet data networks and applications ]  [74], clause 5.13.3). If the eNodeB reports a successful delivery with an S1-AP NAS Delivery Indication and if the Downlink data was received over the T6a interface, the MME should respond to the SCEF (see TS 23.682[ Architecture enhancements to facilitate communications with packet data networks and applications ]  [74], clause 5.13.3). If the eNodeB does not support S1-AP NAS delivery indications, the MME indicates a cause code 'Success Unacknowledged Delivery' to the SCEF otherwise 'Success Acknowledged Delivery', for the SCEF to know if reliable delivery was possible or not. 14. If no NAS PDU activity exists for a while, the eNodeB starts an S1 release in step 15. 15. An S1 release procedure according to clause 5.3.5 triggered by the eNodeB or MME. Alternatively, if the MME in step 11 sent S1 UE Context Release Command then the procedure starts with step 5 in clause 5.3.5, or Connection Suspend Procedure defined in clause 5.3.4A. The UE and the MME shall store the ROHC configuration and context for the uplink/downlink data transmission when entering ECM_CONNECTED state next time.