This procedure is used to release the logical S1-AP signalling connection (over S1-MME) and all S1 bearers (in S1-U) for a UE. This Procedure releases the S11-U bearer in Control Plane CIoT EPS Optimisation (except in the case of buffering in MME), instead of the S1-U bearer. The procedure will move the UE from ECM-CONNECTED to ECM-IDLE in both the UE and MME, and all UE related context information is deleted in the eNodeB. When the S1-AP signalling connection is lost, e.g. due to loss of the signalling transport or because of an eNodeB or MME failure, the S1 release procedure is performed locally by the eNodeB and by the MME. When the S1 release procedure is performed locally by the eNodeB or by the MME each node performs locally its actions as described in the procedure flow below without using or relying on any of the signalling shown directly between eNodeB and MME.
If Service Gap Control shall be applied for the UE (see clause 18.104.22.168) and the Service Gap timer is not already running, the Service Gap timer shall be started in MME and UE when entering ECM-IDLE, unless the connection was initiated after a paging of an MT event, or after a TAU procedure without any active flag set or signalling active flag set.
The initiation of S1 Release procedure is either:
eNodeB-initiated with cause e.g. O&M Intervention, Unspecified Failure, User Inactivity, Repeated RRC signalling Integrity Check Failure, Release due to UE generated signalling connection release, CS Fallback triggered, Inter-RAT Redirection, etc. as defined in TS 36.413; or
MME-initiated with cause e.g. authentication failure, detach, not allowed CSG cell (e.g. the CSG ID of the currently used CSG cell expires or is removed from the CSG subscription data), etc.
Both eNodeB-initiated and MME-initiated S1 release procedures are shown in Figure 5.3.5-1.
1a. In certain cases the eNodeB may release the UE's signalling connection before or in parallel to requesting the MME to release the S1 context, e.g. the eNodeB initiates an RRC Connection Release for CS Fallback by redirection. If the reason for the release is that the eNodeB received Release Assistance Indicator in Access Stratum as defined in TS 36.321, the eNodeB should not immediately release the RRC connection, instead send S1 UE context Release Request with appropriate cause value e.g. user inactivity.
If the eNodeB detects a need to release the UE's signalling connection and all radio bearers for the UE, the eNodeB sends an S1 UE Context Release Request (Cause) message to the MME. Cause indicates the reason for the release (e.g. O&M intervention, unspecified failure, user inactivity, repeated integrity checking failure, or release due to UE generated signalling connection release).
If the PLMN has configured secondary RAT reporting and the eNodeB has Secondary RAT usage data to report, the Secondary RAT usage data is included in S1 UE Context Release Request.
The MME upon receiving S1 UE context Release Request with Cause=user inactivity continues with the S1 release procedure unless the MME is aware of pending MT traffic or signalling and/or NAS Release Assistance Information that may have been received in NAS PDU when Control Plane CIoT EPS Optimisation is used, which indicates that downlink data is expected.
For Control Plane CIoT EPS Optimisation with data buffering in the MME, step 2 and step 3 are skipped.
The MME sends a Release Access Bearers Request (Abnormal Release of Radio Link Indication, Secondary RAT usage data) message to the S-GW that requests the release of all S1-U bearers for the UE, or the S11-U in Control Plane CIoT EPS Optimisation if buffering is in the S-GW. This message is triggered either by an S1 Release Request message from the eNodeB, or by another MME event. The Abnormal Release of Radio Link Indication is included if the S1 release procedure is due to an abnormal release of the radio link. If secondary RAT usage data was received in Step 1b, the MME includes Secondary RAT usage data in this message.
If the S-GW has received a Release Access Bearers Request, the S-GW releases all eNodeB related information (address and TEIDs), or the MME TEIDs related information in Control Plane CIoT EPS Optimisation (address and TEIDs), for the UE and responds with a Release Access Bearers Response message to the MME. Other elements of the UE's S-GW context are not affected. The S-GW retains the S1-U configuration that the S-GW allocated for the UE's bearers. The S-GW starts buffering downlink packets received for the UE and initiating the "Network Triggered Service Request" procedure, described in clause 22.214.171.124, if downlink packets arrive for the UE. In Control Plane CIoT EPS Optimisation Downlink data triggers Mobile Terminated Data transport in NAS signalling defined in clause 5.3.4B.3.
If the RRC connection is not already released, the eNodeB sends a RRC Connection Release message to the UE in Acknowledged Mode. Once the message is acknowledged by the UE, the eNodeB deletes the UE's context.
The eNodeB confirms the S1 Release by returning an S1 UE Context Release Complete (ECGI, TAI, Secondary RAT usage data) message to the MME. With this, the signalling connection between the MME and the eNodeB for that UE is released. This step shall be performed promptly after step 4, e.g. it shall not be delayed in situations where the UE does not acknowledge the RRC Connection Release.
If Dual Connectivity was activated by that eNodeB at the time of the release or earlier by that eNodeB, the eNodeB shall include the last known PSCell ID and the time elapsed since the Dual Connectivity was released.
If the eNodeB supports WUS, the eNodeB should include the Information On Recommended Cells And eNodeBs For Paging in the S1 UE Context Release Complete message; otherwise, the eNodeB may include the Information On Recommended Cells And eNodeBs For Paging in the S1 UE Context Release Complete message. If available, the MME shall store this information to be used when paging the UE.
The eNodeB includes Information for Enhanced Coverage, if available, in the S1 UE Context Release Complete message.
If the PLMN has configured secondary RAT usage data reporting, the eNodeB has not included Secondary RAT usage data at step 1b, and the eNodeB has Secondary RAT usage data to report, the Secondary RAT usage data is included in this message. If Secondary RAT usage data was included at step 1b then MME ignores Secondary RAT usage data at step 6.
The MME deletes any eNodeB related information ("eNodeB Address in Use for S1-MME", "MME UE S1 AP ID" and "eNodeB UE S1AP ID") from the UE's MME context, but, retains the rest of the UE's MME context including the S-GW's S1-U configuration information (address and TEIDs). All non-GBR EPS bearers established for the UE are preserved in the MME and in the Serving GW.
If the cause of S1 release is because of User I inactivity, Inter-RAT Redirection, the MME shall preserve the GBR bearers. If the cause of S1 release is because of CS Fallback triggered, further details about bearer handling are described in TS 23.272. Otherwise, e.g. Radio Connection With UE Lost, S1 signalling connection lost, eNodeB failure the MME shall trigger the MME Initiated Dedicated Bearer Deactivation procedure (clause 126.96.36.199) for the GBR bearer(s) of the UE after the S1 Release procedure is completed.
If LIPA is active for a PDN connection, the HeNB informs the collocated L-GW by internal signalling to releases the direct user plane path to the HeNB. After the direct user plane path is released, if downlink packets arrive for the UE, the L-GW forwards the first packet on the S5 tunnel to the S-GW to initiate the "Network Triggered Service Request" procedure, as described in clause 188.8.131.52.
If the eNodeB provided and MME accepted Secondary RAT usage data in step 6 (i.e. MME initiated S1 release), the MME initiates the Secondary RAT usage data reporting procedure in clause 5.7A.3 as illustrated in Figure 5.7A.3-2 (steps 7a - 7d). If PGW secondary RAT usage reporting is active, steps 7b and 7c are performed, otherwise only steps 7a and 7d are performed.
If the eNodeB provided Secondary RAT usage data in step 1b (i.e. eNodeB initiated S1 release) and PGW secondary RAT usage data reporting is active, the MME initiates the Secondary RAT usage data reporting procedure in clause 5.7A.3 as illustrated in Figure 5.7A.3-2.
This procedure is used by the UE to resume the ECM-connection if the UE and the network support User Plane CIoT EPS Optimisation and the UE has stored the necessary information to conduct the Connection Resume procedure (see TS 36.300) otherwise the Service Request procedures are used, see clause 5.3.4.
The UE triggers the RRC Connection Resume procedure including information needed by the eNodeB to access the UE's stored AS context, see TS 36.300. The E-UTRAN performs security checks. EPS bearer state synchronization is performed between the UE and the network, i.e. the UE shall locally remove any EPS bearer for which no radio bearer is setup and which is not a Control Plane CIoT EPS bearer. 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.
The eNodeB notifies the MME that the UE's RRC connection is resumed in the S1-AP UE Context Resume Request message which includes an RRC resume cause. If the eNodeB is not able to admit all suspended bearers, the eNodeB shall indicate this in the list of rejected EPS bearers, see TS 36.413.
If there is a Service Gap timer running in the MME for the UE and the MME is not waiting for a MT paging response from the UE and the RRC Connection Establishment Cause for the Connection Resume Request is not 'mo-Signalling', the MME rejects the resume request by sending a S1-AP UE Context Resume Reject message to eNodeB.
The MME enters the ECM-CONNECTED state. The MME identifies that the UE returns at the eNodeB for which MME has stored data related to the S1AP association, UE Context and bearer context including the DL TEID(s), necessary to resume the connection, see Connection Suspend procedure in clause 5.3.4A.
If a default EPS bearer is not accepted by the eNodeB, all the EPS bearers associated to that default bearer shall be treated as non-accepted bearers. The MME releases the non-accepted and non-established bearers by triggering the bearer release procedure as specified in clause 184.108.40.206.
To assist Location Services, the eNodeB indicates the UE's Coverage Level to the MME.
If the S1-U connection is resumed and the UE is accessing via the NB-IoT RAT with the RRC resume cause set to "MO exception data", the MME should notify the Serving Gateway of each use of this establishment cause by the MO Exception Data Counter. The MME maintains the MO Exception Data Counter and sends it to the Serving GW as indicated in TS 29.274.
The Serving Gateway should notify the PDN GW if the RRC establishment cause "MO Exception Data" has been used by the MO Exception Data Counter (see TS 29.274). The Serving GW indicates each use of this RRC establishment cause by the related counter on its CDR.
MME acknowledges the connection resumption in S1-AP UE Context Resume Response message. If the MME is not able to admit all suspended E-RABs the MME shall indicate this in the E-RABs Failed To Resume List IE.
The uplink data from the UE can now be forwarded by eNodeB to the Serving GW. The eNodeB sends the uplink data to the Serving GW address and TEID stored during the Connection Suspend procedure, see clause 5.3.4A. The Serving GW forwards the uplink data to the PDN GW.
The MME sends a Modify Bearer Request message (eNodeB address, S1 TEID(s) (DL) for the accepted EPS bearers, Delay Downlink Packet Notification Request, RAT Type) per PDN connection to the Serving GW. If the Serving GW supports Modify Access Bearers Request procedure and if there is no need for the Serving GW to send the signalling to the PDN GW, the MME may send Modify Access Bearers Request (eNodeB address(es) and TEIDs for downlink user plane for the accepted EPS bearers, Delay Downlink Packet Notification Request) per UE to the Serving GW to optimise the signalling. The Serving GW is now able to transmit downlink data towards the UE.
The MME and the Serving GW clears the DL Data Buffer Expiration Time in their UE contexts if it was set, to remember that any DL data buffered for a UE using power saving functions has been delivered and to avoid any unnecessary user plane setup in conjunction with a later TAU.
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, or a Modify Access Bearers Response (Serving GW address and TEID for uplink traffic) as a response to a Modify Access Bearers Request message. If the Serving GW cannot serve the MME Request in the Modify Access Bearers Request message without S5/S8 signalling other than to unpause charging in the PDN GW or without corresponding Gxc signalling when PMIP is used over the S5/S8 interface, it shall respond to the MME with indicating that the modifications are not limited to S1-U bearers, and the MME shall repeat its request using a Modify Bearer Request message per PDN connection.
If SIPTO at the Local Network is active for a PDN connection with stand-alone GW deployment and the Local Home Network ID for stand-alone accessed by the UE differs from the Local Home Network ID where the UE initiated the SIPTO@LN PDN Connection, the MME shall request disconnection of the SIPTO at the local network PDN connection(s) with the "reactivation requested" cause value according to clause 5.10.3. If the UE has no other PDN connection, the MME initiated "explicit detach with reattach required" procedure according to clause 220.127.116.11.
If SIPTO at the Local Network is active for a PDN connection with collocated LGW deployement and the L-GW CN address of the cell accessed by the UE differs from the L-GW CN address of the cell where the UE initiated the SIPTO at the Local Network PDN Connection, the MME shall request disconnection of the SIPTO at the local network PDN connection(s) with the "reactivation requested" cause value according to clause 5.10.3. If the UE has no other PDN connection, the MME initiated "explicit detach with reattach required" procedure according to clause 18.104.22.168.
Same as step 2 in clause 22.214.171.124, with the following addition:;
The Serving-GW may send the downlink data size to the MME for MT-EDT consideration if the downlink data is applicable for User Plane CIoT EPS Optimisation and MT-EDT is applicable for this PDN connection.
Same as step 3 in clause 126.96.36.199, with the following addition;
If MT-EDT is applicable for the PDN Connection, the MME may include the downlink data size in the Paging message to assist eNodeB to use MT-EDT.
Same as step 4 in cluse 188.8.131.52, with the following addition;
If data size is included in Paging message from MME, the eNodeB may decide to use MT-EDT, by adding a MT-EDT indication in the Paging message to the UE.
The PDN GW Pause of Charging procedure is optionally supported by the Serving GW and PDN GW and has the purpose to limit a mismatch between PDN GW and Serving GW charging volume and packet counts. Generally, it aims for the PDN GW charging and usage monitoring data to more accurately reflect the downlink traffic actually sent to the E-UTRAN.
The Serving GW may indicate support of this function to the PDN GW when the PDN connection is activated or when a new/target Serving GW is used for a PDN connection. This is indicated to the PDN GW by a "PDN Charging Pause Support Indication" in the Create Session Request during PDN activation/Attach and in the Modify Bearer Request in procedures with a change of Serving GW.
The PDN GW may indicate if the feature is to be enabled on a per PDN connection basis, if the current Serving GW supports the feature and the operator's policy is to enable the feature. This is indicated to the Serving GW by a "PDN Charging Pause Enabled" Indication in the Create Session Response during PDN activation/Attach and in the Modify Bearer Response in procedures with a change of Serving GW. This is an indication to the Serving GW that when the criteria for pause of PDN GW charging are met (as described further down in this clause) the PDN GW charging can be paused.
The PDN GW shall stop any charging and usage monitoring actions for the PDN connection upon receiving a "PDN Charging Pause Start" Indication in a Modify Bearer Request. When the PDN GW receives a Modify Bearer Request for a PDN connection for which charging has been stopped previously and, if the Modify Bearer Request contains a "PDN Charging Pause Stop" Indication or does not contain a "PDN Charging Pause Start" Indication, then the PDN GW shall continue charging for the PDN connection.
When bearers become suspended for a UE (see TS 23.272), the PDN GW charging is no longer paused and the PDN GW continues charging for the PDN connection after suspended bearers are resumed.
While the PDN GW charging is currently paused and the UE is in ECM-IDLE (for ISR case the device is at same time in PMM-IDLE or STANDBY in UTRAN/GERAN accesses) the following applies:
The PDN GW shall not perform charging and usage monitoring actions for downlink traffic on this PDN.
Based on operator policy/configuration in the PDN GW, the PDN GW may limit the rate of downlink traffic sent to the Serving GW.
Based on operator policy/configuration in the Serving GW, the Serving GW may discard rather than buffer the downlink user plane packets for this PDN connection while the PDN GW charging is paused. This is to avoid delivery of user plane packets to the UE that were not counted in the PDN GW for charging and usage monitoring purposes. Regardless of operator policy/configuration, the downlink user plane packets received from PDN GW at the Serving GW shall trigger Downlink Data Notifications as described in clause 184.108.40.206.
When the Serving GW receives a Modify Bearer Request or Modify Access Bearers Request for a PDN connection triggering a Modify Bearer Request towards the PDN GW, the Serving GW shall consider the PDN charging as being unpaused if it has been paused previously.
The Serving GW receives downlink data packets for a UE known as not user plane connected (i.e. the Serving GW context data indicates no downlink user plane TEID for the eNodeB) as described in clause 220.127.116.11 step 1, i.e. the packets are buffered or discarded in Serving GW based on operator policy.
Based on operator policy/configuration the Serving GW triggers the procedure to pause PDN charging. Triggering criteria are based on Serving GW operator policy/configuration. Example of such policy may be:
Operator specified criteria/threshold (e.g. number/fraction of packets/bytes dropped at Serving GW in downlink since last time the UE was in ECM-CONNECTED state (or for ISR case PMM-CONNECTED state)).
Recent indication of "Abnormal Release of Radio Link" (see clause 5.3.5) or a recent Downlink Data Notification Reject (clause 18.104.22.168) without UE shortly re-entering ECM-CONNECTED state (or for ISR case without also re-entering PMM-CONNECTED state).
The MME may initiate the GUTI Reallocation procedure to reallocate the GUTI and/or TAI list at any time when a signalling association is established between UE and MME. The GUTI Reallocation procedure allocates a new GUTI and/or a new TAI list and/or PLMN-assigned UE Radio Capability ID to the UE. The GUTI and/or the TAI list may also be reallocated by the Attach or the Tracking Area Update procedures.
When the UE supports RACS, and the MME needs to configure the UE with a UE Radio Capability ID, and the MME already has the UE radio capabilities for the UE, the MME may initiate the GUTI Reallocation procedure to provide the UE with the UE Radio Capability ID for the UE radio capabilities the UCMF returns to the MME for this UE. When the UE supports RACS, and the MME needs to delete any previously assigned PLMN-assigned UE Radio Capability ID(s) for the UE, the MME may initiate the GUTI Reallocation procedure to signal a PLMN-assigned UE Radio Capability ID deletion indication. If the UE receives PLMN-assigned UE Radio Capability ID deletion indication, the UE shall delete any PLMN-assigned UE Radio Capability ID(s) for this PLMN.
The GUTI Reallocation procedure is illustrated in Figure 5.3.7-1.