19.2.2 S1 Interface Signalling Procedures

36.3003GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)Overall descriptionRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

The elementary procedures supported by the S1AP protocol are listed in Table 1 and Table 2 of TS 36.413 [25].

19.2.2.0 General

19.2.2.1 Paging procedure

Figure 19.2.2.1-1: Paging procedure

The MME initiates the paging procedure by sending the PAGING message to each eNB with cells belonging to the tracking area(s) in which the UE is registered. Each eNB can contain cells belonging to different tracking areas, whereas each cell can only belong to one TA. In case MME initiates the paging procedure with eDRX configuration it shall include the S-TMSI in the PAGING message.

The paging response back to the MME is initiated on NAS layer and is sent by the eNB based on NAS-level routing information.

19.2.2.2 S1 UE Context Release procedure

19.2.2.2.0 General

The S1 UE Context Release procedure causes the eNB to remove all UE individual signalling resources and the related user data transport resources. This procedure is initiated by the EPC and may be triggered on request of the serving eNB.

19.2.2.2.1 S1 UE Context Release (EPC triggered)

Figure 19.2.2.2.1-1: S1 UE Context Release procedure (EPC triggered)

– The EPC initiates the UE Context Release procedure by sending the S1 UE Context Release Command towards the E-UTRAN. The eNodeB releases all related signalling and user data transport resources.

– The eNB confirms the S1 UE Context Release activity with the S1 UE Context Release Complete message. The behaviour of the eNodeB in case of Control Plane CIoT EPS Optimisation is specified in TS 23.401 [11].

– In the course of this procedure the EPC releases all related resources as well, except context resources in the EPC for mobility management and the default EPS Bearer/E-RAB configuration.

19.2.2.2.2 S1 UE Context Release Request (eNB triggered)

The S1 UE Context Release Request procedure is initiated for E-UTRAN internal reasons and comprises the following steps:

– The eNB sends the S1 UE Context Release Request message to the EPC.

– The EPC triggers the EPC initiated UE context release procedure.

Figure 19.2.2.2.2-1: S1 UE Context Release Request procedure (eNB triggered)
and subsequent S1 UE Context Release procedure (EPC triggered)

If the E-UTRAN internal reason is a radio link failure detected in the eNB, the eNB shall wait a sufficient time before triggering the S1 UE Context Release Request procedure in order to allow the UE to perform the NAS recovery procedure, see TS 23.401 [17].

19.2.2.3 Initial Context Setup procedure

The Initial Context Setup procedure establishes the necessary overall initial UE context in the eNB in case of an Idle-to Active transition. The Initial Context Setup procedure is initiated by the MME.

The Initial Context Setup procedure comprises the following steps:

– The MME initiates the Initial Context Setup procedure by sending INITIAL CONTEXT SETUP REQUEST to the eNB. This message may include general UE Context (e.g. security context, roaming and access restrictions, UE capability information, UE S1 signalling connection ID, CN assistance information, etc.), E-RAB context (Serving GW TEID, QoS information, Correlation id i.e. collocated L-GW TEID or GRE key in case of LIPA support or in case of SIPTO@LN with collocated L-GW support), and may be piggy-backed with the corresponding NAS messages. When there are multiple NAS messages in the INITIAL CONTEXT SETUP REQUEST message, the MME shall ensure that the NAS messages in the E-RAB to be Setup List are aligned in the order of reception from the NAS layer to ensure the in-sequence delivery of the NAS messages.

– Upon receipt of INITIAL CONTEXT SETUP REQUEST, the eNB setup the context of the associated UE, and perform the necessary RRC signalling towards the UE, e.g. Radio Bearer Setup procedure. When there are multiple NAS messages to be sent in the RRC message, the order of the NAS messages in the RRC message shall be kept the same as that in the INITIAL CONTEXT SETUP REQUEST message. If present, the eNB uses the CN assistance information as defined in TS 23.401[17] and propagates it during inter-eNB mobility.

– The eNB responds with INITIAL CONTEXT SETUP RESPONSE to inform a successful operation, and with INITIAL CONTEXT SETUP FAILURE to inform an unsuccessful operation.

NOTE: In case of failure, eNB and MME behaviours are not mandated. Both implicit release (local release at each node) and explicit release (MME-initiated UE Context Release procedure) may in principle be adopted. The eNB should ensure that no hanging resources remain at the eNB.

Figure 19.2.2.3-1: Initial Context Setup procedure (highlighted in blue) in Idle-to-Active procedure

19.2.2.3a UE Context Modification procedure

The UE Context Modification procedure enables the MME to modify the UE context in the eNB for UEs in active state. The UE Context Modification procedure is initiated by the MME.

The UE Context Modification procedure comprises the following steps:

– The MME initiates the UE Context Modification procedure by sending UE CONTEXT MODIFICATION REQUEST to the eNB to modify the UE context in the eNB for UEs in active state.

– The eNB responds with UE CONTEXT MODIFICATION RESPONSE in case of a successful operation

– If the UE is served by a CSG cell, and is no longer a member of the CSG cell, the eNB may initiate a handover to another cell. If the UE is not handed over, the eNB should request the release of UE context;

– If the UE is served by a hybrid cell, and is no longer a CSG member of the hybrid cell, the eNB may provide the QoS for the UE as a non CSG member.

– The eNB responds with UE CONTEXT MODIFICATION FAILURE in case of an unsuccessful operation.

Figure 19.2.2.3a-1: UE Context Modification procedure

19.2.2.4 E-RAB signalling procedures

19.2.2.4.1 E-RAB Setup procedure

Figure 19.2.2.4.1-1: E-RAB Setup procedure

The E-RAB Setup procedure is initiated by the MME to support:

– Assignment of resources to a dedicated E-RAB.

– Assignment of resources for a default E-RAB.

– Setup of S1 Bearer (on S1) and Data Radio Bearer (on Uu).

The E-RAB Setup procedure comprises the following steps:

– The E-RAB SETUP REQUEST message is sent by the MME to the eNB to setup resources on S1 and Uu for one or several E-RAB(s). The E-RAB SETUP REQUEST message contains the Serving GW TEID, QoS indicator(s) and the corresponding NAS message per E-RAB within the E-RAB To Be Setup List. It may also include the Correlation id i.e. collocated L-GW TEID or GRE key in case of LIPA support or in case of SIPTO@LN with collocated L-GW support. When there are multiple NAS messages in the E-RAB SETUP REQUEST message, the MME shall ensure that the NAS messages in the E-RAB to be Setup List are aligned in the order of reception from the NAS layer to ensure the in-sequence delivery of the NAS messages.

– Upon receipt of the E-RAB SETUP REQUEST message the eNB establishes the Data Radio Bearer(s) (RRC: Radio Bearer Setup) and resources for S1 Bearers. When there are multiple NAS messages to be sent in the RRC message, the order of the NAS messages in the RRC message shall be kept the same as that in the E-RAB SETUP REQUEST message.

– The eNB responds with a E-RAB SETUP RESPONSE messages to inform whether the setup of resources and establishment of each E-RAB was successful or unsuccessful, with the E-RAB Setup list (E-RAB ID, eNB TEID) and the E-RAB Failed to Setup list (E-RAB ID, Cause) The eNB also creates the binding between the S1 bearer(s) (DL/UL TEID) and the Data Radio Bearer(s).

Interactions with UE Context Release Request procedure:

In case of no response from the UE the eNB shall trigger the S1 UE Context Release Request procedure.

19.2.2.4.2 E-RAB Modification procedure

Figure 19.2.2.4.2-1: E-RAB Modification procedure

The E-RAB Modification procedure is initiated by the MME to support the modification of already established E-RAB configurations:

– Modify of S1 Bearer (on S1) and Radio Bearer (on Uu).

– S-GW relocation without UE mobility.

The EPS Bearer Modification procedure comprises the following steps:

– The E-RAB MODIFY REQUEST message is sent by the MME to the eNB to modify one or several E-RAB(s). The E-RAB MODIFY REQUEST message contains the QoS indicator(s), and the corresponding NAS message per E-RAB in the E-RAB To Be Modified List. When there are multiple NAS messages in the E-RAB MODIFY REQUEST message, the MME shall ensure that the NAS messages in the E-RAB to be Modified List are aligned in the order of reception from the NAS layer to ensure the in-sequence delivery of the NAS messages. The transport information for the new S-GW may be included in case of S-GW relocation without UE mobility.

– Upon receipt of the E-RAB MODIFY REQUEST message the eNB modifies the Data Radio Bearer configuration (RRC procedure to modify the Data Radio bearer). When there are multiple NAS messages to be sent in the RRC message, the order of the NAS messages in the RRC message shall be kept the same as that in the E-RAB MODIFY REQUEST message. In case of S-GW relocation without UE mobility, if transport information for the new S-GW is included, the eNB ignores the included QoS indicator and NAS message and uses the included transport information for S-GW selection.

– The eNB responds with an E-RAB MODIFY RESPONSE message to inform whether the E-RAB modification has succeeded or not indicating with the E-RAB Modify list and E-RAB Failed to Modify list. With E-RAB ID(s) in the E-RAB Modify List or E-RAB Failed to Modify List the eNB identifies the E-RAB(s) successfully modified or failed to modify.

Interactions with UE Context Release Request procedure:

In case of no response from the UE the eNB shall trigger the S1 UE Context Release Request procedure.

19.2.2.4.3 E-RAB Release procedure

Figure 19.2.2.4.3-1: E-RAB Release procedure

The E-RAB Release procedure is initiated by the MME to release resources for the indicated E-RABs.

The E-RAB Release procedure comprises the following steps:

– The E-RAB RELEASE COMMAND message is sent by the MME to the eNB to release resources on S1 and Uu for one or several E-RAB(s). With the E-RAB ID(s) in the E-RAB To Be Released List contained in E-RAB RELEASE COMMAND message the MME identifies, the E-RAB(s) to be released.

– Upon receipt of the E-RAB RELEASE COMMAND message the eNB releases the Data Radio Bearers (RRC: Radio bearer release) and S1 Bearers.

– The eNB responds with an E-RAB RELEASE COMPLETE message containing E-RAB Release list and E-RAB Failed to Release list. With the E-RAB IDs in the E-RAB Release List/E-RAB Failed to Release List the eNB identifies the E-RAB(s) successfully released or failed to release.

Interactions with UE Context Release Request procedure:

In case of no response or negative response from the UE or in case the eNB cannot successfully perform the release of any of the requested bearers, the eNB shall trigger the S1 UE Context Release Request procedure, except if the eNB has already initiated the procedures associated with X2 Handover.

19.2.2.4.4 E-RAB Release Indication procedure

Figure 19.2.2.4.4-1: E-RAB Release Indication procedure

The E-RAB Release Indication procedure enables the E-UTRAN to send information about released resources for one or several E-RABs to the MME. The eNB initiates the procedure by sending the E-RAB RELEASE INDICATION message to the MME. The E-RAB ID(s) in the E-RAB Released List identifies the released E-RAB(s) in the eNB.

19.2.2.4.5 E-RAB Modification Indication procedure

Figure 19.2.2.4.5-1: E-RAB Modification Indication procedure

The E-RAB Modification Indication procedure is initiated by the eNB to support the modification of already established E-RAB configurations and CSG membership verification. The current version of the specification supports the modification of the transport information and CSG membership verification. This procedure is used for DC if the SCG bearer option is applied.

If the EPC is able to apply the requested modification, the MME responds with the E-RAB MODIFICATION CONFIRM.

If the EPC is not able to modify a transport path as requested, the MME responds with the list of E-RABs failed in the E-RAB MODIFICATION CONFIRM, the MeNB either keeps the previous transport path unchanged and, if applicable, triggers to release the corresponding SCG bearers, or tears down the corresponding E-RABs.

19.2.2.5 Handover signalling procedures

19.2.2.5.0 General

Handover signalling procedures support both, inter-eNB handover and inter-RAT handover.

Inter-RAT handovers shall be initiated via the S1 interface.

Inter-eNB handovers shall be initiated via the X2 interface except if any of the following conditions are true:

– the source eNB is not an RN and there is no X2 between source and target eNB.

– the source eNB is an RN and there is no X2 between DeNB and the target eNB or between the source RN and the DeNB.

– the source eNB is an RN and the UE’s serving MME is not included in the MME Pool(s) connected with the target eNB.

– the source eNB has been configured to initiate handover to the particular target eNB via S1 interface in order to enable the change of an EPC node (MME and/or Serving GW).

– the source eNB has attempted to start the inter-eNB HO via X2 but receives a negative reply from the target eNB with a specific cause value.

Inter-eNB handovers shall be initiated via the S1 interface, if one of the above conditions applies.

19.2.2.5.1 Handover Preparation procedure

The Handover preparation procedure is initiated by the source eNB if it determines the necessity to initiate the handover via the S1 interface.

Figure 19.2.2.5.1-1: Handover preparation procedure

The handover preparation comprises the following steps:

– The HANDOVER REQUIRED message is sent to the MME.

– The source eNB shall ensure that the size of the Source to Target Transparent Container does not exceed the limits that can be handled by interfaces involved in the handover.

NOTE: For SRVCC handover, the size limit is 2560 octets (see AN-APDU in TS 29.002 [84]). For inter RAT PS domain handover, the size limit is 4092 octets (see TS 25.412 [85]).

– The handover preparation phase is finished upon the reception of the HANDOVER COMMAND message in the source eNB, which includes at least radio interface related information (HO Command for the UE), successfully established E-RAB(s) and E-RAB(s) which failed to setup.

– In case the handover resource allocation is not successful (e.g. no resources are available on the target side) the MME responds with the HANDOVER PREPARATION FAILURE message instead of the HANDOVER COMMAND message.

19.2.2.5.2 Handover Resource Allocation procedure

The handover resource allocation comprises the following steps:

Figure 19.2.2.5.2-1: Handover resource allocation procedure

– The MME sends the HANDOVER REQUEST message including the E-RAB(s) which needs to be setup by the target eNB.

– In the case of a UE performing handover toward an RN, the HANDOVER REQUEST is received by the DeNB, which shall read the target cell ID from the message, find the target RN corresponding to the target cell ID, and forward the message toward the target RN.

– The target eNB responds with the HANDOVER REQUEST ACK message after the required resources for all accepted E-RABs are allocated. The HANDOVER REQUEST ACK message contains successfully established E-RAB(s), E-RAB(s) which failed to setup and radio interface related information (HO Command for the UE), which is later sent transparently via the EPC/CN from the target RAT to the source RAT.

– If no resources are available on the target side, the target eNB responds with the HANDOVER FAILURE message instead of the HANDOVER REQUEST ACK message.

19.2.2.5.3 Handover Notification procedure

The Handover Completion for S1 initiated handovers comprises the following steps:

– The HANDOVER NOTIFY message is sent by the target eNB to the MME when the UE has successfully been transferred to the target cell. If the eNB supports SIPTO@LN with stand-alone gateway, the message shall include the LHN ID.

Figure 19.2.2.5.3-1: Handover completion procedure

19.2.2.5.4 Handover Cancellation

This functionality is located in the source eNB to allow a final decision regarding the outcome of the handover, i.e. either to proceed or to cancel the handover procedure.

Figure 19.2.2.5.4-1: Handover cancellation procedure

– The source eNB sends a HANDOVER CANCEL message to the MME indicating the reason for the handover cancellation.

– The MME confirms the reception of the HANDOVER CANCEL message by returning the HANDOVER CANCEL ACK message.

19.2.2.5.5 Path Switch procedure

The handover completion phase for X2 initiated handovers comprises the following steps:

– The PATH SWITCH message is sent by the target eNB to the MME when the UE has successfully been transferred to the target cell. The PATH SWITCH message includes the outcome of the resource allocation: successfully established E-RAB(s). If the eNB supports SIPTO@LN with stand-alone gateway, the message shall include the LHN ID.

– The MME responds with the PATH SWITCH ACK message which is sent to the eNB.

– The MME responds with the PATH SWITCH FAILURE message in case a failure occurs in the EPC.

Figure 19.2.2.5.5-1: Path Switch procedure

19.2.2.5.6 Message sequence diagrams

This clause complements TR 25.922 [27] clause 5.1.7.2 regarding the E-UTRAN handling of containers.

Most RRC information is carried by means of containers across interfaces other than Uu. The following sequence diagrams illustrate which RRC information should be included within these containers used across the different network interfaces.

NOTE: In order to maintain independence between protocols, no requirements are included in the interface protocols that are used to transfer the RRC information.

SRVCC (see TS 23.216 [28]) is supported from EUTRAN to UTRAN or GERAN A/Gb mode and from UTRAN or GERAN A/Gb mode to EUTRAN.

There is no support for interworking between EUTRAN and GERAN Iu-mode and between EUTRAN and GAN.

Figure 19.2.2.5.6-1 and 19.2.2.5.6-1a illustrate the message sequence for handover from GERAN to EUTRAN procedure:

Figure 19.2.2.5.6-1. Handover of PS domain service from GERAN A/Gb mode to EUTRAN, normal flow

UE is not requested to provide E-UTRAN UE capabilities while in GERAN. Hence the HANDOVER REQUEST does not contain E-UTRAN UE capabilities, and the capabilities are fetched by Target eNB from UE after handover is completed.

Figure 19.2.2.5.6-1a. Handover of CS domain service from GERAN A/Gb mode to PS-domain service in EUTRAN, normal flow

Figure 19.2.2.5.6-2 illustrates the message sequence for PS handover and CS handover from UTRAN to EUTRAN procedure:

Figure 19.2.2.5.6-2: Handover of PS domain service and handover of CS domain service from UTRAN to EUTRAN, normal flow

Figure 19.2.2.5.6-3 to Figure 19.2.2.5.6-5 illustrate the message sequence for the handover from EUTRAN to GERAN A/Gb mode procedure:

Figure 19.2.2.5.6-3: Handover of CS domain service from EUTRAN to GERAN A/Gb mode, normal flow

Figure 19.2.2.5.6-4. Handover of PS domain service from EUTRAN to GERAN A/Gb mode, normal flow

Figure 19.2.2.5.6-5: Handover of CS and PS domain services from EUTRAN to GERAN A/Gb mode, normal flow

Figure 19.2.2.5.6-6 and Figure 19.2.2.5.6-7 illustrate the message sequence for the handover from EUTRAN to UTRAN procedure:

Figure 19.2.2.5.6-6. Handover of PS or CS domain service from EUTRAN to UTRAN, normal flow

Figure 19.2.2.5.6-7. Handover of PS and CS domain service from EUTRAN to UTRAN, normal flow

19.2.2.5.7 eNB Status Transfer procedure

The purpose of the eNB Status Transfer procedure is to transfer the uplink PDCP SN and HFN receiver status and the downlink PDCP SN and HFN transmitter status from the eNB to the MME during an S1 handover for each respective E-RAB for which PDCP SN and HFN status preservation applies.

Figure 19.2.2.5.7-1: eNB Status Transfer

19.2.2.5.8 MME Status Transfer procedure

The purpose of the MME Status Transfer procedure is to transfer the uplink PDCP SN and HFN receiver status and the downlink PDCP SN and HFN transmitter status from the MME to the eNB during an S1 handover for each respective E-RAB for which PDCP SN and HFN status preservation applies.

Figure 19.2.2.5.8-1: MME Status Transfer

19.2.2.6 NAS transport procedures

A NAS signalling message is transferred on the S1 interface in both directions. The procedures providing this functionality are:

– Initial UE Message procedure (eNB initiated);

– Uplink NAS transport procedure (eNB initiated);

– Downlink NAS transport procedure (MME initiated);

– Downlink NAS non delivery indication procedure (eNB initiated)

– Downlink NAS delivery indication procedure; (eNB initiated);

– Reroute NAS Request procedure.

i) Initial UE Message procedure

Figure 19.2.2.6-1: Initial UE Message procedure

– The INITIAL UE MESSAGE procedure is initiated by the eNB by sending the INITIAL UE MESSAGE message to the MME. The INITIAL UE MESSAGE contains a NAS message (e.g. Service Request), the UE signalling reference ID and other S1 addressing information. If the eNB is a HeNB supporting LIPA, the message shall include the HeNB collocated L-GW IP address to enable the establishment of a LIPA PDN connection. If the eNB supports SIPTO@LN with collocated L-GW, the message shall include the collocated L-GW IP address to enable the establishment of a SIPTO@LN PDN connection. If the eNB supports SIPTO@LN with stand-alone gateway, the message shall include the LHN ID. In case of UE access to a CSG cell the INITIAL UE MESSAGE contains the CSG id of the cell. In case of UE access to a hybrid cell the INITIAL UE MESSAGE contains the CSG id and Access Mode of the cell.

ii) Uplink NAS Transport procedure (eNB initiated)

Figure 19.2.2.6-2: Uplink NAS Transport procedure

– The Uplink NAS Transport procedure is initiated by the eNB by sending the UPLINK NAS TRANSPORT message to the MME. The UPLINK NAS TRANSPORT message contains a NAS message, UE identification and other S1 related addressing information. If the eNB is a HeNB supporting LIPA, the message shall include the HeNB collocated L-GW IP address to enable the establishment of a LIPA PDN connection. If the eNB supports SIPTO@LN with collocated L-GW, the message shall include the collocated L-GW IP address to enable the establishment of a SIPTO@LN PDN connection. If the eNB supports SIPTO@LN with stand-alone gateway, the message shall include the LHN ID.

iii) Downlink NAS Transport procedure (MME initiated)

Figure 19.2.2.6-3: Downlink NAS Transport procedure

– The Downlink NAS Transport procedure is initiated by the MME by sending the DOWNLINK NAS TRANSPORT message to the eNB. The DOWNLINK NAS TRANSPORT contains a NAS message, UE identification and other S1 related addressing information and may contain the UE Radio Capability information. In addition a request to indicate the successful delivery of the Downlink NAS PDU to the UE may be included in the DOWNLINK NAS TRANSPORT message.

iv) Downlink NAS non delivery indication procedure

Figure 19.2.2.6-4: Downlink NAS Non Delivery Indication procedure

– When the eNB decides to not start the delivery of a NAS message that has been received from MME, it shall report the non-delivery of this NAS message by sending a DOWNLINK NAS NON DELIVERY INDICATION message to the MME including the non-delivered NAS message and an appropriate cause value.

v) Downlink NAS delivery indication procedure

Figure 19.2.2.6-5: Downlink NAS Delivery Indication procedure

– The eNB may be requested by the MME to provide an indication whether the Downlink NAS PDU has been successfully delivered to the UE. The eNB then triggers the Downlink NAS Delivery Indication procedure per downlink NAS PDU provided in a DOWNLINK NAS TRANSPORT as specified in TS 23.401 [17].

vi) Reroute NAS Request procedure

Figure 19.2.2.6-6: Reroute NAS Request procedure

The Reroute NAS Request procedure is used to reroute a NAS message (and there by a UE) to another MME when DCNs are used.

The procedure is initiated by the MME sending the REROUTE NAS REQUEST message. Upon receiving the REROUTE NAS REQUEST message, the eNB selects a MME in the indicated DCN and sends the INITIAL UE MESSAGE message to the new selected MME as described in TS 23.401 [17]. In case a UE-associated logical S1-connection was established between the MME and the eNB, upon sending (respectively receiving) the REROUTE NAS REQUEST message the MME (respectively eNB) shall locally remove the UE-associated logical S1-connection.

19.2.2.7 S1 interface Management procedures

19.2.2.7.1 Reset procedure

The purpose of the Reset procedure is to re-initialize the peer entity or part of the peer entity after node setup and after a failure event occurred. This procedure is initiated by both the eNB and MME.

19.2.2.7.1a eNB initiated Reset procedure

Figure 19.2.2.7.1a-1: eNB initiated Reset procedure

– The eNB triggers the RESET message to indicate that an initialisation in the MME is required. The MME releases the corresponding references and resources.

– Afterwards the MME sends the RESET ACK message to confirm that the resources and references are cleared.

19.2.2.7.1b MME initiated Reset procedure

Figure 19.2.2.7.1b-1: MME initiated Reset procedure

– The MME triggers the RESET message to indicate that an initialisation in the eNB is required. The eNB releases the corresponding references and resources.

– Afterwards the eNB sends the RESET ACK message to confirm that the resources and references are cleared.

19.2.2.7.2 Error Indication functions and procedures

The Error Indication procedure is initiated by the eNB and the MME, to report detected errors in one incoming message, if an appropriate failure message cannot be reported to the sending entity.

19.2.2.7.2a eNB initiated error indication

Figure 19.2.2.7.2a-1: eNB initiated Error Indication procedure

The eNB sends the ERROR INDICATION message to report the peer entity which kind of error occurs.

19.2.2.7.2b MME initiated error indication

Figure 19.2.2.7.2b-1: MME initiated Error Indication procedure

The MME sends the ERROR INDICATION message to report the peer entity which kind of error occurs.

19.2.2.8 S1 Setup procedure

The S1 Setup procedure is used to exchange configured data which is required in the MME and in the eNB respectively to ensure a proper interoperation. The S1 Setup procedure is triggered by the eNB. The S1 Setup procedure is the first S1AP procedure which will be executed.

Figure 19.2.2.8-1: S1 Setup procedure

– The eNB initiates the S1 Setup procedure by sending the S1 SETUP REQUEST message including supported TAs and broadcasted PLMNs to the MME.

– In the successful case the MME responds with the S1 SETUP RESPONSE message which includes served PLMNs as well as a relative MME capacity indicator to achieve load balanced MMEs in the pool area.

The MME and the eNB may agree at the S1 Setup procedure that UE-related contexts and related signalling connection that have been existing before the S1 Setup shall not be affected. The MME or eNB or both may trigger an S1AP Reset procedure for any UE-related context and related signalling connection for UEs which could not be kept in ECM_CONNECTED and RRC_CONNECTED or for UEs for which the MME or the eNB decided to remove the UE-related context and related signalling connection. If either the MME and the eNB do not agree to keep the UE-related contexts (if any), then they are removed and all related signalling connections are erased.

– If the MME cannot accept the S1 Setup Request the MME responds with the S1 SETUP FAILURE message indicating the reason of the denial. The MME optionally indicates in the S1 SETUP FAILURE message when the eNB is allowed to re-initiate the S1 Setup Request procedure towards the same MME again.

19.2.2.9 eNB Configuration Update procedure

The eNB Configuration Update procedure is used to provide updated configured data in eNB. The eNB Configuration Update procedure is triggered by the eNB.

Figure 19.2.2.9-1: eNB Configuration Update procedure

– The eNB initiates the eNB Configuration Update procedure by sending the ENB CONFIGURATION UPDATE message including updated configured data like supported TAs and broadcasted PLMNs to the MME. In case one or more supported TA(s) needs to be updated, the eNB shall provide the whole list of TA(s), including those which has not been changed, in the ENB CONFIGURATION UPDATE message.

– The MME responds with the ENB CONFIGURATION UPDATE ACKNOWLEDGE message to acknowledge that the provided configuration data are successfully updated.

– The MME shall overwrite and store the received configuration data which are included in the ENB CONFIGURATION UPDATE message. Configuration data which has not been included in the ENB CONFIGURATION UPDATE message are interpreted by the MME as still valid. For the provided TA(s) the MME shall overwrite the whole list of supported TA(s).

– In case the MME cannot accept the received configuration updates the MME shall respond with the ENB CONFIGURATION UPDATE FAILURE message including an appropriate cause value to indicate the reason of the denial. The MME optionally indicates in the ENB CONFIGURATION UPDATE FAILURE message when the eNB is allowed to re-initiate the eNB Configuration Update procedure towards the same MME again. For the unsuccessful update case the eNB and the MME shall continue with the existing configuration data.

19.2.2.9a eNB Configuration Transfer procedure

The eNB Configuration Transfer procedure is initiated by the eNB to request and/or transfer RAN configuration information via the core network.

Figure 19.2.2.9a-1: eNB Configuration Transfer procedure

The eNB Configuration Transfer procedure is initiated by the eNB by sending the eNB CONFIGURATION TRANSFER message to the MME. The eNB CONFIGURATION TRANSFER message contains RAN configuration information (e.g. SON information) and other relevant information such as the routing address which identifies the final RAN destination node.

19.2.2.10 MME Configuration Update procedure

The MME Configuration Update procedure is used to provide updated configured data and changes of the relative MME capacity values in the MME. The MME Configuration Update procedure is triggered by the MME.

Figure 19.2.2.10-1: MME Configuration Update procedure

– The MME initiates the MME Configuration Update procedure by sending the MME CONFIGURATION UPDATE message including updated configured data like served PLMNs and changes of the relative MME capacity values to the eNB.

– The eNB responds with the MME CONFIGURATION UPDATE ACKNOWLEDGE message to acknowledge that the provided configuration data and the relative MME capacity values are successfully updated.

– The eNB shall overwrite and store the received configuration data and relative MME capacity values which are included in the MME CONFIGURATION UPDATE message. Configuration data which has not been included in the MME CONFIGURATION UPDATE message are interpreted by the eNB as still valid.

– In case the eNB cannot accept the received configuration updates the eNB shall respond with the MME CONFIGURATION UPDATE FAILURE message including an appropriate cause value to indicate the reason of the denial. The eNB optionally indicates in the MME CONFIGURATION UPDATE FAILURE message when the MME is allowed to re-initiate the MME Configuration Update procedure towards the same eNB again. For the unsuccessful update case the eNB and the MME shall continue with the existing configuration data and relative MME capacity values.

19.2.2.10a MME Configuration Transfer procedure

The MME Configuration Transfer procedure is initiated by the MME to request and/or transfer RAN configuration information to the eNB.

Figure 19.2.2.10a-1: MME Configuration Transfer procedure

The MME Configuration Transfer procedure is initiated by the MME by sending the MME CONFIGURATION TRANSFER message to the eNB. The MME CONFIGURATION TRANSFER message contains RAN configuration information (e.g. SON information) and other relevant information.

19.2.2.11 Location Reporting procedures

19.2.2.11.0 General

The Location Reporting procedures provide the means to report the current location of a specific UE.

The procedures providing this function are:

– Location Reporting Control procedure;

– Location Report procedure;

– Location Report Failure Indication procedure.

If DC is configured for a specific UE, the location reported refers to the cell served by the MeNB. If EN-DC is configured for a specific UE, the location reported refers to the cell served by the MeNB and, if requested, the PSCell at the en-gNB.

NOTE: The following S1AP procedures are able to provide location information without the reporting being triggered by the Location Reporting Control procedure:
S1 UE Context Release, UE Context Suspend, E-RAB Release, E-RAB Release Indication, Path Switch, Handover Notification, Initial UE Message, Uplink NAS Transport, Secondary RAT Data Usage Report.

19.2.2.11.1 Location Reporting Control procedure

Figure 19.2.2.11.1-1: Location Reporting Control procedure

The Location Reporting Control procedure is initiated by the MME sending the LOCATION REPORTING CONTROL to the eNB to request the current location information, e.g. Cell ID, of a specific UE, and how the information shall be reported, e.g. direct report, report every cell change. The Location Reporting Control procedure is also used to terminate reporting on cell change.

If the Location Reporting Control procedure fails, e.g. due to an interaction with an initiated handover then the eNB shall indicate the failure using the Location Report Failure Indication procedure.

If the Location Reporting Control procedure is on going for a specific UE and the eNB received an UE CONTEXT RELEASE COMMAND message from MME this specific UE then the eNB shall terminate the on-going Location Reporting.

19.2.2.11.2 Location Report procedure

Figure 19.2.2.11.2-1: Location Report procedure

The Location Report procedure is initiated by the eNB by sending the LOCATION REPORT to the MME to report the current location information of a specific UE as a standalone report, or every time UE changes cell.

19.2.2.11.3 Location Report Failure Indication procedure

Figure 19.2.2.11.3-1: Location Report Failure Indication procedure

The Location Report Failure Indication procedure is initiated by the eNB by sending the LOCATION REPORT FAILURE INDICATION to the MME to indicate that the Location Report Control procedure has failed due to e.g. UE has performed inter-eNB handover.

19.2.2.12 Overload procedure

19.2.2.12.1 Overload Start procedure

The Overload Start procedure is used by the MME to indicate to a proportion of eNBs to which the MME has an S1 interface connection that the MME is overloaded. The Overload Start procedure is used to provide an indication of which type of RRC connections needs to be rejected/permitted only.

Figure 19.2.2.12.1-1 Overload Start procedure

If the OVERLOAD START message contains a list of GUMMEIs, the eNB shall select the new RRC connections to be rejected based on this list.

The eNB may also trigger EAB as specified in TS 23.401 [17] clause 4.3.7.4.1 and TS 23.251 [54] clause 4.6.

19.2.2.12.2 Overload Stop procedure

The Overload Stop procedure is used by the MME to indicate the concerned eNB(s) that the MME is no longer overloaded.

Figure 19.2.2.12.2-1: Overload Stop procedure

If the OVERLOAD STOP message contains a list of GUMMEIs, the eNB shall stop rejecting the new RRC connections corresponding to each received GUMMEI value if applicable.

The eNB may also stop ongoing EAB actions.

19.2.2.13 Write-Replace Warning procedure

Figure 19.2.2.13.1-1: Write-Replace Warning procedure

The Write-Replace Warning procedure is used to start the broadcasting of a PWS warning message.

ETWS is an example of PWS warning system using this procedure where one message at a time can be delivered over the radio.

CMAS is another example of PWS warning system using this procedure which allows the broadcast of multiple concurrent warning messages over the radio.

The procedure is initiated by the MME by sending WRITE-REPLACE WARNING REQUEST message containing at least the Message Identifier, Warning Area list, information on how the broadcast should be performed, and the contents of the warning message to be broadcast.

The eNB responds with WRITE-REPLACE WARNING RESPONSE message to acknowledge that the requested PWS warning message broadcast was initiated.

ETWS and CMAS are independent services and ETWS and CMAS messages are differentiated over S1 in order to allow different handling.

In the case of ETWS, the Write-Replace Warning procedure can also be used to overwrite the ongoing broadcasting of an ETWS warning message.

19.2.2.14 eNB Direct Information Transfer procedure

The eNB Direct Information Transfer procedure is initiated by the eNB to request and transfer information to the core network.

Figure 19.2.2.14-1: eNB Direct Information Transfer procedure

The eNB Direct Information Transfer procedure is initiated by the eNB by sending the eNB DIRECT INFORMATION TRANSFER message to the MME. The eNB DIRECT INFORMATION TRANSFER message contains RIM information and RIM routing address which identifies the final RAN destination node.

19.2.2.15 MME Direct Information Transfer procedure

The MME Direct Information Transfer procedure is initiated by the MME to request and transfer information to the eNB.

Figure 19.2.2.15-1: MME Direct Information Transfer procedure

The MME Direct Information Transfer procedure is initiated by the MME by sending the MME DIRECT INFORMATION TRANSFER message to the eNB. The MME DIRECT INFORMATION TRANSFER message contains RIM information.

19.2.2.16 S1 CDMA2000 Tunnelling procedures

The S1 CDMA2000 Tunnelling procedures carry CDMA2000 signalling messages between UE and CDMA2000 RAT over the S1 Interface. This includes signalling for pre-registration and handover preparation for optimized mobility from E-UTRAN to CDMA2000 HRPD, signalling for handover preparation for mobility from E-UTRAN to CDMA2000 1xRTT and signalling to support CS fallback to CDMA2000 1xRTT for mobile originated and mobile terminated CS domain services. The CDMA2000 messages are tunnelled transparently to the eNB and MME, however, additional information may be sent along with the tunnelled CDMA2000 message to assist the eNodeB and MME in the Tunnelling procedure. The procedures providing this functionality are:

– Downlink S1 CDMA2000 Tunnelling procedure;

– Uplink S1 CDMA2000 Tunnelling procedure.

19.2.2.16.1 Downlink S1 CDMA2000 Tunnelling procedure

The MME sends the DOWNLINK S1 CDMA2000 TUNNELLING message to the eNB to forward a CDMA2000 message towards an UE for which a logical S1 connection exists (see Figure 19.2.2.16.1-1 below).

Figure 19.2.2.16.1-1: Downlink S1 CDMA2000 Tunnelling procedure

19.2.2.16.2 Uplink S1 CDMA2000 Tunnelling procedure

The eNB sends the UPLINK S1 CDMA2000 TUNNELLING message to the MME to forward a CDMA2000 message towards the CDMA2000 RAT (HRPD or 1xRTT) as depicted on Figure 19.2.2.16.2-1 below.

Figure 19.2.2.16.2-1: Uplink S1 CDMA2000 Tunnelling procedure

19.2.2.17 Kill procedure

Figure 19.2.2.17-1: Kill procedure

The Kill procedure is used to stop the broadcasting of a PWS warning message or all PWS warning messages.

CMAS is an example of warning system using this procedure. The ETWS warning system doesn’t use this procedure.

The procedure is initiated by the MME sending the KILL REQUEST message containing at least the Message Identifier and serial number of the message to be killed and the Warning Area List where it shall be killed.

The eNB responds with a KILL RESPONSE message to acknowledge that the requested PWS message broadcast delivery has actually been stopped.

19.2.2.18 LPPa Transport procedures

19.2.2.18.0 General

An LPPa signalling message is transferred on the S1 interface in both directions. The procedures providing this functionality are:

– Downlink UE Associated LPPa Transport procedure;

– Uplink UE Associated LPPa Transport procedure;

– Downlink Non UE Associated LPPa Transport procedure;

– Uplink Non UE Associated LPPa Transport procedure.

The UE-associated signalling is used to support E-CID positioning of a specific UE. The non-UE associated signalling is used to obtain assistance data from an eNodeB to support OTDOA positioning for any UE.

19.2.2.18.1 Downlink UE Associated LPPa Transport procedure

The Downlink UE Associated LPPa Transport procedure is initiated by the MME by sending the DOWNLINK UE ASSOCIATED LPPA TRANSPORT message to the eNB. The DOWNLINK UE ASSOCIATED LPPA TRANSPORT contains an LPPa message.

Figure 19.2.2.18.1-1: Downlink UE Associated LPPa Transport procedure

19.2.2.18.2 Uplink UE Associated LPPa Transport procedure

The Uplink UE Associated LPPa Transport procedure is initiated by the eNB by sending the UPLINK UE ASSOCIATED LPPA TRANSPORT message to the MME. The UPLINK UE ASSOCIATED LPPA TRANSPORT message contains a LPPa message.

Figure 19.2.2.18.2-1: Uplink UE Associated LPPa Transport procedure

19.2.2.18.3 Downlink Non UE Associated LPPa Transport procedure

The Downlink Non UE Associated LPPa Transport procedure is initiated by the MME by sending the DOWNLINK NON UE ASSOCIATED LPPA TRANSPORT message to the eNB. The DOWNLINK NON UE ASSOCIATED LPPA TRANSPORT contains a LPPa message.

Figure 19.2.2.18.3-1: Downlink Non UE Associated LPPa Transport procedure

19.2.2.18.4 Uplink Non UE Associated LPPa Transport procedure

The Uplink Non UE Associated LPPa Transport procedure is initiated by the eNB by sending the UPLINK NON UE ASSOCIATED LPPA TRANSPORT message to the MME. The UPLINK NON UE ASSOCIATED LPPA TRANSPORT message contains an LPPa message.

Figure 19.2.2.18.4-1: Uplink Non UE Associated LPPa Transport procedure

19.2.2.19 Trace procedures

19.2.2.19.0 General

The Trace procedures provide the means to control trace sessions and MDT sessions in the eNB for both signalling and management triggered sessions.

The procedures providing this function are:

– Trace Start procedure;

– Trace Failure Indication procedure;

– Deactivate Trace procedure;

– Cell Traffic Trace procedure.

19.2.2.19.1 Trace Start procedure

Figure 19.2.2.19.1-1: Trace Start procedure

The Trace Start procedure is initiated by the MME by sending the TRACE START message to the eNB in order to request the initiation of a trace session for a specific UE in ECM_CONNECTED mode or request the initiation of an MDT session for a specific UE.

19.2.2.19.2 Trace Failure Indication procedure

Figure 19.2.2.19.2-1: Trace Failure Indication procedure

The Trace Failure Indication procedure is initiated by the eNB by sending the TRACE FAILURE INDICATION message to the MME to report that a Trace Start procedure or a Deactivate Trace procedure has failed due to an interaction with a handover procedure.

19.2.2.19.3 Deactivate Trace procedure

Figure 19.2.2.19.3-1: Deactivate Trace procedure

The Deactivate Trace procedure is initiated by the MME by sending the DEACTIVATE TRACE message to the eNB to request the termination of an ongoing trace session.

19.2.2.19.4 Cell Traffic Trace procedure

Figure 19.2.2.19.4-1: Cell Traffic Trace procedure

The Cell Traffic Trace procedure is initiated by the eNB by sending the CELL TRAFFIC TRACE message to the MME to report the allocated Trace Recording Session Reference and the Trace Reference to MME. This procedure is used to support management triggered trace.

19.2.2.20 UE Capability Info Indication procedure

The purpose of the UE Capability Info Indication procedure is to enable the eNB to provide to the MME UE capability-related information, as described in TS 23.401 [17].

Figure 19.2.2.20-1: UE Capability Info Indication procedure

19.2.2.21 UE Radio Capability Match procedure

Figure 19.2.2.21-1: UE Radio Capability Match procedure

The UE Radio Capability Match procedure is initiated by the MME to request an indication on whether the UE Radio capabilities match the network configuration for voice continuity.

19.2.2.22 PWS Restart Indication procedure

Figure 19.2.2.22-1: PWS Restart Indication procedure

The PWS Restart Indication procedure is used to inform the MME that PWS information for some cells or all cells of the eNB are available for reloading from the CBC if needed.

The procedure is initiated by the eNB sending the PWS RESTART INDICATION message.

19.2.2.23 PWS Failure Indication procedure

Figure 19.2.2.23-1: PWS Failure Indication procedure

The PWS Failure Indication procedure is used to inform the MME that ongoing PWS operation has failed for one or more cells.

The procedure is initiated by the eNB sending the PWS FAILURE INDICATION message.

19.2.2.24 UE Context Modification Indication procedure

Figure 19.2.2.24-1: UE Context Modification Indication procedure

The UE Context Modification Indication procedure enables the eNB to request the modifications of the UE Context.

In the current version of the specification, the procedure is only used for CSG membership verification for Dual Connectivity.

This procedure is initiated by the eNB.

19.2.2.25 Connection Establishment Indication procedure

Figure 19.2.2.25-1: Connection Establishment Indication procedure

The Connection Establishment Indication procedure is used in case of CIoT EPS Optimisation and it enables the MME to provide information to the eNB to complete the establishment of the UE-associated logical S1-connection and/or to trigger the eNB to obtain and report UE Radio Capability.

The MME may trigger Connection Establishment Indication procedure either

– after receiving INITIAL UE MESSAGE message, if the MME has no NAS PDU to send in DL in case of Control Plane CIoT EPS Optimisation, or

– after receiving an eNB CP RELOCATION INDICATION message in case of Control Plane CIoT EPS Optimisation, or

– when deciding to trigger the eNB to obtain and report UE Radio Capability.

The UE Radio Capability may be provided from the MME to the eNB in this procedure. If the UE radio capability is not included, this may trigger the eNB to request the UE Radio Capability from the UE and to provide it to the MME in the UE CAPABILITY INFO INDICATION message.

NAS-level security information may be provided from the MME to the eNB in this procedure in case the UE-associated logical S1-signalling connection is established for a NB-IOT UE using Control Plane CIoT EPS optimisations after the MME receives an eNB CP RELOCATION INDICATION message from the eNB, as described in TS 33.401 [22].

This procedure is initiated by the MME.

19.2.2.26 UE Context Suspend procedure

Figure 19.2.2.26-1: UE Context Suspend procedure

The UE Context Suspend procedure is initiated by the eNB to request the MME to suspend the UE context and the related bearer contexts in the EPC after which the eNB sends the UE to RRC_IDLE.

After successful completion of the UE Context Suspend procedure the UE-associated signalling connection is said to be suspended. The eNB and the MME keep all context data necessary to resume the UE-associated signalling connection so that there is no need to exchange information that has been provided to the respective node already before the UE-associated signalling connection has been suspended. Only the following S1AP procedures are allowed to take place on a suspendend UE-associated signalling connection:

– UE Context Resume;

– S1AP UE Context Release (eNB and MME initiated);

19.2.2.27 UE Context Resume procedure

Figure 19.2.2.27-1: UE Context Resume procedure

The UE Context Resume procedure is initiated by the eNB to indicate that the UE has resumed the RRC connection and to request the MME to resume the UE context and related bearer contexts in the EPC. In case the UE context cannot be resumed in the EPC this is indicated by the MME by sending the UE CONTEXT RESUME FAILURE message.

19.2.2.28 Retrieve UE Information procedure

Figure 19.2.2.28: Retrieve UE Information procedure

The Retrieve UE Information procedure is initiated by the eNB to request the UE information (i.e. QoS parameters, UE capability) from MME for NB-IoT UE using Control Plane CIoT EPS Optimisation, as specified in TS 23.401 [17].

19.2.2.29 UE Information Transfer procedure

Figure 19.2.2.29: UE Information Transfer procedure

The UE Information Transfer procedure is initiated by the MME to send the UE information (i.e. QoS parameters, UE capability) to the eNB for NB-IoT UE using Control Plane CIoT EPS Optimisation, as specified in TS 23.401 [17].

19.2.2.30 eNB CP Relocation Indication

The eNB CP Relocation Indication procedure is only applicable for NB-IOT UEs using Control Plane CIoT EPS optimisations. The purpose of the eNB CP Relocation Indication procedure is to request the MME to authenticate the UE’s re-establishment request as described in TS 33.401 [22], and initiate the establishment of the UE-associated logical S1-connection after the UE has initiated a RRC Re-establishment procedure in an eNB.

When the eNB receives the RRCConnectionReestablishmentRequest message, it triggers the eNB CP Relocation Indication procedure including NAS-level security information received from the UE. If the MME authenticates the request, it initiates the Connection Establishment Indication procedure including NAS-level security information to be sent to the UE in the RRCConnectionReestablishment message. In case the MME cannot authenticate the UE’s request, the CONNECTION ESTABLISHMENT INDICATION message does not contain security information, and the eNB shall fail the RRC Re-establishment. In case of authentication failure, the eNB and the MME should locally release the allocated S1 resources, if any.

Figure 19.2.2.30-1: eNB CP Relocation Indication procedure (highlighted in blue)

Interactions with the MME CP Relocation and UE Context Release procedures:

In case of successful UE authentication, the MME initiates the UE Context Release procedure to release the UE’s old S1-connection. The MME may initiate the MME CP Relocation procedure before the release procedure in order to trigger the return of non-delivered NAS PDUs to the MME.

19.2.2.31 MME CP Relocation Indication

The MME CP Relocation Indication procedure is only applicable for UEs using Control Plane CIoT EPS optimisations. The purpose of the MME CP Relocation Indication procedure is to inform the previously serving eNB that the UE’s connection is to be relocated to a new eNB.

Upon reception of the MME CP RELOCATION INDICATION message, the old eNB shall terminate the delivery of downlink NAS PDUs towards the UE, and initiate NAS Non Delivery Indication procedure(s) to report the non-delivery of any NAS PDUs previously received from the MME.

Figure 19.2.2.31-1: MME CP Relocation Indication procedure (highlighted in blue).

19.2.2.32 Secondary RAT Report

The Secondary RAT Report procedure is used by the eNB during mobility procedures or for periodic reporting to provide information on the used NR resources during EN-DC.

Figure 19.2.2.32-1: Secondary RAT Report Procedure.

19.2.2.33 UE Radio Capability ID Mapping procedure

The UE Radio Capability ID Mapping procedure is initiated by the eNB to request the UE Radio Capability information that maps to a specific capability ID from the MME.

Figure 19.2.2.33-1: UE radio capability ID mapping procedure

The UE Radio Capability ID Mapping procedure comprises the following steps:

– The eNB initiates the UE Radio Capability ID Mapping procedure by sending UE RADIO CAPABILITY ID MAPPING REQUEST to the MME.

– The MME responds with UE RADIO CAPABILITY ID MAPPING RESPONSE including the UE radio capability information.