INTRODUCTION
The S1 interface management procedure manages the signaling associations between eNBs and MME. When eNB starts, it performs S1 setup procedures with MME according to 3GPP TS36.413, and it manages the connection by exchanging Keep Alive, S1 Reset, eNB/MME Configuration Update, and Error Indication message.
The S1 interface management also include path management between eNB and SGW. Once eNB and MME setup an E-RAB connection, eNB and S-GW can transmit user packets unlink and downlink through GTP tunnel. They distinguish each E-RAB bearer by Tunnel Endpoint Identifier (TEID). The eNB supports path management function as per 3GPP TS29.281.
BENEFIT
The operator can manage the signaling associations between eNB and EPC such as setting up, resetting S1 interface, and recovering from errors.
This feature provides path monitoring between eNB and SGW
DEPENDENCY AND LIMITATION
Limitation
The eNB can connect to up to 16 MMEs at the same time.
The eNB can communicate with any SGWs informed by MME without the limitation on the number of SGWs as long as there is IP connectivity between eNB and SGW.
In some operator's network, IPsec tunnelling is used between eNB and SeGW. S1 signaling and data traffic is delivered from/to EPC through the IPsec tunnel.
FEATURE DESCRIPTION
There are two types of S1 interface:
S1-MME for control plane
S1-U for user plane
The S1-MME includes a direct SCTP connection between eNB and MME. The eNB must establish single SCTP connection to each MME during initial
configuration phase. Also, SCTP connection is used to manage UE-associated S1-AP connections and to carry handover related messages, eNB/MME configuration message, and NAS TRANSPORT messages.
The S1-U is a direct GTP tunnel between eNB and SGW. The GTP tunnel is UE-associated connection and created when UE attaches to the network. Through the GTP tunnel, eNB delivers/receives user packets to/from S-GW. The GTP tunnel is maintained while UE is in active mode and released when UE's state changes to idle mode.
The following sub-sections describe the method of configure S1-MME and S1-U interface related parameters and how eNB and MME manages S1 interface via S1-AP procedures defined in 3GPP TS 36.413.
S1 Setup
The S1 Setup procedure is the first S1AP procedure after a TNL (Transport Network Layer) association has been made. When this procedure is performed, the application level configuration data between eNB and MME, if there is, is
removed and replaced with the newly received data. During S1 setup procedure, eNB sends its basic application level configuration data such as Global eNB ID, Supported Tracking Area list consisting of PLMN and Tracking Area Code, and Default paging DRX and MME sends its list of served GUMMEIs, Relative MME capacity and so on. If eNB initiating the S1 SETUP procedure on (or more) CSG cell(s), the S1 SETUP REQUEST message shall contain the CSG ID(s) of the supported CSG(s).
The S1 Setup successful procedure is as follows:
When MME cannot accept S1 Setup request, it should respond with S1 Setup Failure and appropriate cause value. If S1 Setup Failure message includes Time to Wait IE, eNB shall wait at least for the indicated time before reinitiating the S1 Setup towards the same MME.
If eNB fails to receive the S1 Setup Response message within certain amount of time configured by S1_SETUP timer, it retransmits the S1 Setup Request again to MME.
Note that the S1 management interface is essential for LTE service, there is no retry count. It means that eNB retransmits S1 Setup Request to MME unlimitedly
S1 Reset
When an abnormal situation occurs, S1 interface of all or some UEs can be initialized through reset procedure which runs on S1-C. (However, the application level configuration data, which was exchanged by S1 Setup procedure, is not changed.)
The S1 Reset procedure is executed over S1-C interface which is a control plane interface of S1. The eNB sends the Reset Acknowledge message to MMEs after receiving the Reset message and then sends the RRC Connection Release message to the target UEs. After that, UE related resources, which are controlled by eNB, are released.
The S1 Reset MME triggered procedure is as follows:
Another example of S1 Reset is when eNB selects a specific S/W or H/W module is in an abnormal state and unable to provide the normal service, which has resulted in the loss of some or all transaction reference information, it sends the Reset message to the MME.
When Samsung eNB determines the cell is not normal any more due to Channel Card, DSP or RF unit, it sends S1 Reset to MME. The list of UEs, whose resources should be released, can be specified by “MME UE S1AP ID” IE or eNB UE S1AP ID IE of the UE-Associated logical S1-connection list IE in S1 Reset message.
Note that MME UE S1AP ID uniquely identifies a connected UE association among many UE associations within MME and “eNB UE S1AP ID” does in the same way within eNB. Hence, by informing these IDs to MME or eNB, MME or eNB can easily identify which UEs are impacted by this Reset message and releases them.
The S1 Reset eNB triggered procedure is as follows:
If eNB fails to receive the S1 Reset Acknowledge message within certain amount of time configured by s1Reset timer, it retransmits the S1 Reset message again to MME upto s1ResetRetryCount times.
Unlike Reset by MME, eNB does not send RRC Connection Release to UE right after Reset if Reset is triggered by eNB. The reason is that in case of Reset by eNB, the eNB is in an abnormal state and may not be able to send RRC Connection Release to the corresponding UEs correctly. Hence, instead of sending RRC Connection Release to UEs right away, the eNB relies on each UE‟s failure detection mechanism such as Radio Link Failure (RLF) detection.
When UE detects RLF due to eNB‟s reset, it tries to send RRC Connection Reestablishment request to eNB and if eNB is able to accept this request, the connection continues. If it fails after several times of retries, UE will release RRC connection by itself and goes to Idle. Later when RRC connection is needed, UE will send RRC Connection Request to create new RRC connection.
Error Indication
When the received message cannot be processed normally and cannot be
responded with the appropriate failure message, eNB or MME can report this fact to the peer with Error Indication procedure.
In case the Error Indication procedure is triggered by utilising UE associated signalling 'MME UE S1AP ID' and 'eNB UE S1AP' shall be included in the ERROR INDICATION message as below procedure. Otherwise, the Error Indication does not include 'MME UE S1AP ID' and 'eNB UE S1AP ID'.
The Error Indication eNB originated procedure is as follows:
The Error Indication MME originated procedure is as follows:
eNB Configuration Update
When eNB needs to update the application level data impacting UE-related context, eNB can send eNB Configuration Update message to MME with which eNB has an established S1 connection currently.
If the current TAC, eNB Name, or DefaultPagingDRX value set in the PLD is changed during system operation, eNB includes not only the changed parameter values but also the unchanged parameter values in eNB Configuration Update message, and sends it to MMEs.
At this time, eNB must send the message to all MMEs with S1 Setup established.
When eNB Configuration Update message is sent, a timer starts configured by
“s1Update” and eNB expects eNB Configuration Update Acknowledge message to be received before the timer expires.
When MME cannot accept eNB Configuration Update request, it shall respond with eNB Configuration Update Failure and appropriate cause value. If eNB Configuration Update Failure message includes the Time to Wait IE, eNB shall wait at least for the indicated time before reinitiating the eNB Configuration Update towards the same MME.
Both eNB and MME shall continue to operate the S1 with their respective configuration data. If eNB configuration update acknowledge message is not received before the s1Update timer expires, eNB kills the timer, resends the eNB configuration update message upto S1_UPDATE_RETRY_COUNT times. If the supported CSG ID(s) is/are to be updated in CSG or hybrid cell, the whole loss of supported CSG IDs, including those that are not to be updated, shall be included in the CSG Id List IE. The MME shall overwrite the whole list of CSG IDs
The eNB Configuration Update successful procedure is as follows:
The eNB Configuration Update unsuccessful procedure is as follows:
MME Configuration Update
Similar to eNB Configuration Update, when MME needs to update the application level data impacting UE-related context, MME can send MME Configuration Update message to eNB with which eNB has an established S1 connection currently.
If the current TAC, CSGID, eNBName, or DefaultPagingDRX value set in the PLD is changed during system operation, MME includes not only the changed parameter values but also the unchanged parameter values in MME Configuration Update message, and sends it to eNBs.
At this time, MME must send the message to all eNBs with S1 Setup established.
When MME Configuration Update message is sent, MME starts a timer configured by S1AP timer and expects an MME Configuration Update Acknowledge message from eNB before the timer expires.
If eNB sends MME Configuration Update failure, then there might be mismatch in the Relative MME Capacity between MME and eNB. In some cases, eNB selects MME according to the old Relative MME Capacity.
The MME Configuration Update successful procedure is as follows:
The MME Configuration Update Unsuccessful procedure is as follows:
Keep Alive between eNB and MME
The SCTP parameter names of the below description is used conceptually. Refer to COM-IP0401 for exact SCTP parameter names of S1 interface.
The eNB and MME can monitor S1-MME connection by exchanging SCTP HEARTBEAT/ HEARTBEAT ACK messages defined by SCTP protocol. The HEARTBEAT message is periodically transmitted and the period is configured as
„HEART_BEAT_INTERVAL‟. When transmitting HEARTBEAT message, eNB delivers the current time in the Heartbeat Information field, which is also included in the HEARTBEAT ACK message so that the sender and receiver can calculate the Round Trip Time (RTT).
The Keep Alive between eNB and MME successful procedure is as follows:
When HEARTBEAT ACK message is not received, eNB tries to retransmit HEARTBEAT message periodically. The maximum number of retransmission is configured as NUM_PATH_RE_TX.
The period of retransmission is „Heartbeat Retransmission Interval‟ in the below figure and calculated as HEART_BEAT_INTERVAL + RTO + RTO*[-0.5, 0.5], where RTO is increased as exponential backoff if the previous HEARTBEAT message is unanswered. The initial, minimum and maximum values are configured as RTO_INITIAL, RTO_MIN, and RTO_MAX.
When HEARTBEAT ACK is not received after all the retransmission, the link status is considered as abnormal. If MME SCTP connection is considered as abnormal, MME_FAILOVER_TIMER is triggered and the call is not released when the SCTP connection is restored before the timer expiry. However, when MME_FAILOVER_TIMER expires, all active calls on the SCTP Connection are released and MME_COMMUNICATION_FAIL alarm is generated. Note that, eNB does not manage Idle calls.
While MME_COMMUNICATION_FAIL alarm is ON, eNB routes new call attempts to another alive MMEs via S1-flex. For example, when there are three MMEs (MME1, MME2, MME3), eNB normally maintains three S1 interfaces, one for each MME1, MME2 and MME3 and distributes calls among them. In case S1 interface to MME1 fails, eNB routes new call attempts to two remaining MMEs (MME2 and MME3).
The Keep Alive between eNB and MME unsuccessful operation procedure is as follows:
In case of S1 setup procedure, eNB transmits INIT message to establish SCTP association. If it fails to get the response of INIT ACK message, eNB transmits INIT message once again after one second. If it is not answered also, eNB repeats this procedure with the period of „CONNECT_INTERVAL‟ until SCTP setup is successful as described in the below figure.
The SCTP Setup between eNB and MME unsuccessful procedure is as follows:
Path Management between eNB and S-GW
According to 3GPP TS 29.281, eNB and S-GW can monitor S1-U path using ECHO REQUEST/ECHO RESPONSE messages defined by GTP-U protocol.
Here, S1-U Path means a logical connection between eNB and S-GW. In other words, only single S1-U Path exists between a certain eNB and a certain S-GW even though there may be many S1 bearers between them. Hence, eNB manages only one S1-U path for each S-GW by sending an Echo Request to find out if it is alive.
The following figure shows path management procedures between eNB and three S-GW, successful operation. In this case, there are three S1-U paths and for each path, eNB sends the ECHO REQUEST message to S-GW periodically and waits for ECHO RESPONSE message.
If eNB fails to receive the ECHO RESPONSE message, it resends the ECHO REQUEST message up to the configured maximum retransmissions
N3_REQUEST. When eNB fails to receive the ECHO RESPONSE message even after maximum resending, it will release all E-RAB connections with the failed S-GW and triggers MME to release the related calls via S1-Reset procedure.
The Keep Alive between eNB and S-GW unsuccessful procedure is as follows:
SYSTEM OPERATION
How to Activate
Execute the CHG-MME-CONF command to configure MME by adding IP address and set the status to be Equip and unlock active state of the corresponding MME.
Key Parameters
CHG-MME-CONF/RTRV-MME-CONF
Parameter Description
MME_INDEX The index used to access the information. Since there are a total of 16 MMEs that can be connected to an eNB, the index range is 0 to 15.
STATUS The EQUIP status information on MME.
N_EQUIP: The MME to connect does not exist.
EQUIP: The MME to connect exists
ACTIVE_STATE The state information on the specified MME in operation. The MMEs for which the S1 Setup is established, if there is an undesired MME, this parameter value must be changed to Inactive. The default is active. If the STATUS parameter is set to Equip, it is better not to change this parameter value to inactive.
Inactive: MME (S1 assigned) is not used.
Active: MME (S1 assigned) is used.
IP_VER The IP address version of MME. Either IPv4 or IPv6 is assigned.
MME_IPV4 Information on the IPV4 address of MME. This parameter value is valid only if the IP_VER parameter is set to IPv4. It is not used if the IP_VER parameter is set to IPv6.
Parameter Description
MME_IPV6 Information on the IPV6 address of eNB. This parameter value is valid only if the IP_VER parameter is set to IPv6. It is not used if the IP_VER parameter is set to IPv4.
ADMINISTRATIVE_STATE The status of MME link:
Locked: A state where active calls connected to MME are all dropped, and new call connections are not possible.
Unlocked: Connection to MME is normal.
Shutting down: A state where active calls connected to MME are maintained, but new call connections are not possible.
SECONDARY_MME_IPV4 The secondary IP address of the IPv4 type set in MME node to support the SCTP Multi Homing function. It is valid only if the IP_VER parameter is set to IPv4.
This is for SCTP multi-homing
SECONDARY_MME_IPV6 The secondary IP address of the IPv6 type set in MME node to support the SCTP Multi Homing function. It is valid only if the IP_VER parameter is set to IPv6.
This is for IPv6.
S1_TUNNE_GROUP_ID This parameter defines IPSec Tunnel Group ID of MME.
(valid only if IPsec tunnel group function is supported)
Counters and KPIs
There are no related counters or KPIs.
REFERENCE
[1] 3GPP TS36.300 Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2
[2] 3GPP TS36.412 Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 signalling transport
[3] 3GPP TS36.413 Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)
[4] 3GPP TS29.281 General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)
[5] IETF RFC4960 Stream Control Transmission Protocol