S1切换流程

参考23401,36300。 1:LTE系统中，按照源小区和目标小区的从属关系和位置关系，一般将切换分为： LTE系统内切换和LTE系统与异系统之间的切换，其中LTE系统内切换包括eNB切换，通过X2接口连接的eNB间切换和通过S1接口连接的eNB间切换。 2: S1接口的切换过程从信令流程上分为切换准备，切换资源分配，切换通知等过程，切换准备过程由源eNB发起，通过核心网节点，要求目标eNB为本次切换准备资源。切换资源分配过程由MME发起，在目标eNB中为本次切换准备和预留所需要的资源。在UE成功接入到目标eNB后，由目标eNB发起切换通知过程，通知MME这个UE已经成功转移到目标小区，S1切换协议： 3：源eNB决定发起基于S1接口的切换，原因可能是源eNB和目标eNB直接没有X2连接，或者源eNB发起的基于X2接口的切换没有成功，或者源eNB通过一些动态信息作为基于S1接口发起切换的决定 切换程序如下： Handover signalling procedures: 1：Handover preparation procedure The handover preparation comprises the following steps: -    The HANDOVER REQUIRED message is sent to the MME. -    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. 2：handover resource allocation -    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. 3：Handover Notification procedure -    The HANDOVER NOTIFY message is sent by the target eNB to the MME when the UE has successfully been transferred to the target cell. UE成功发送RRC消息到目标小区，T-eNB发送此消息到MME 4: Handover Cancellation -    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. 源eNB发送到MME表示切换取消，同时MME确认发送 消息到S-eNB. 1：S1-based handover, normal NOTE 1:    For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 16 and 16a concern GTP based S5/S8. NOTE 2:    If the Serving GW is not relocated, the box "Source Serving GW" in figure 5.5.1.2.2-1 is acting as the target Serving GW. 1：源eNodeB决定进行基于S1的切换。S1切换的原因可能是源eNodeB和目标eNodeB之间不存在X2连接，或者源eNodeB根据其他情况作出的判断。 2:源eNode B向 源MME发送 Handover Required消息（Direct Forwarding Path Availability, Source to Target transparent container, target eNodeB Identity, CSG ID, CSG access mode, target TAI, S1AP Cause)， 3：源MME选定合适的目标MME，通过S10接口发送Forward Relocation Request消息(MME UE context, Source to Target transparent container, RAN Cause, target eNodeB Identity, CSG ID, CSG Membership Indication, target TAI, MS Info Change Reporting Action (if available), CSG Information Reporting Action (if available), UE Time Zone, Direct Forwarding Flag, Serving Network)给目标MME。 4：目标MME选定相应的目标SGW，发送Create Session Request消息给目标SGW，消息中包含每个承载的上下文（针对基于GTP的S5/S8而言，包括PGW的地址和上行GTP－U在PGW侧的TEID值）。目标SGW为数据承载分配上行GTP－U的地址和TEID值，返回Create Session Response消息给源MME 5：目标MME发送Handover Request消息给目标eNodeB，其中包括要建立的EPS承载的列表等内容，每个EPS承载的信息包括SGW的地址，上行GTP－U的在SGW侧的TEID值，EPS 承载的QoS等。目标eNodeB收到上述消息后会建立UE上下文，包括承载的信息，安全上下文等。目标eNodeB 也回送Handover Request Ack消息给目标MME，其中包含EPS承载建立结果的信息。对于每个成功建立的EPS承载，其信息包括下行数据在目标eNodeB侧的GTP－U的TEID值(会在步骤15使用)。如果目标eNodeB和源eNodeB之间不存在X2接口，需要通过S1接口来转发数据的话，那么目标eNodeB也需要将数据转发隧道的TEID值上报给目标MME。 6：目标MME发送 Create Indirect Data Forwarding Tunnel Request消息给目标SGW，将上述数据转发通道的TEID值（在目标eNodeB侧）通知目标SGW，转发通道的从目标SGW到目标eNodeB的部分可以建立。目标SGW回复Create Indirect Data Forwarding Tunnel Response消息。(为什么要建立这个通道？不能使用每个EPS Bear对应的通道吗？目标SGW->目标eNodeB)，在此Response消息中，包含了Indirect Tunnel在目标SGW侧的地址和TEID值。 7：目标MME发送Forward Relocation Response消息给源MME，将EPS Bearers Setup Result 通知源MME。在Indirect Tunnel的情况下，转发通道在目标SGW侧的地址和TEID值也会在此消息中通知源MME。 8：在Indirect Tunnel的情况下，源MME发送Create Indirect DataForwarding Tunnel Request消息给源SGW，转发通道在目标SGW侧的地址和TEID值通知源SGW。转发通道的从源SGW到目标SGW的部分可以建立。源SGW回复 Create Indirect DataForwarding Response，将转发通道在源SGW侧的地址和TEID值通知源MME。源MME将会把此信息转发给源eNodeB 9：源MME发送Handover Command消息给源eNodeB， 将目标eNodeB分配的需要转发的EPS Bearers的TEID 值和目标eNodeB的地址通知源eNodeB。（23.401 V9.1.0 Page 128, 我的理解应该是源SGW侧的TEID值，这样转发通道从源eNodeB到源SGW就建立起来了，整个的源eNodeB到目标eNodeB的通道就可以建立起来了） 源eNodeB会将Handover Command包含在 Target To Source Transparent Container中发送给UE。 10：源eNodeB发送eNB Status Transfer消息，此消息经源MME，目标MME，最终到达目标eNodeB。此消息将无损切换的EPS Bearer的PDCP的状态通知目标eNodeB。 11: 源eNodeB此时可以经过Indirect Data Forwarding Tunnel 将下行数据转发给目标eNodeB。（上行数据呢？） 下行数据经PGW，源SGW到达源eNodeB后，源eNodeB发现需要将数据向目标eNodeB转发，源eNodeB首先将数据发送到源SGW，（通道在步骤9建立），源SGW转发数据到目标SGW（通道在步骤8建立），目标SGW将数据最终转发到目标eNodeB（通道在步骤6建立）。 12：UE与目标eNodeB建立上，下行同步后，发送Handover Confirm消息给目标eNodeB。此时目标eNodeB可以将从源eNodeB转发过来的下行数据发送给UE，UE也开始发送上行数据，经目标eNodeB到目标SGW最后到PGW 。在步骤4中，上行数据在PGW处的TEID和地址，已经由目标MME通知了目标SGW。在步骤16中，PGW可能更改其上行的GTP－U的TEID值。 13：目标eNodeB发送Handover Notify消息给目标MME。 14：目标MME发送Forward Relocation Complete Notification消息给源MME。源MME回应Forward Relocation Complete Acknowledge 消息。源MME和目标MME启动相应的定时器，以便在切换结束后，删除相应的资源。 15：目标MME发送Modify Bearer Request消息给目标SGW，将在步骤五建立的 GTP－U在目标eNodeB侧的地址和TEID值通知目标SGW。这样，切换后的下行数据通道在目标SGW到目标eNodeB之间的部分建立了起来。 16：目标SGW分配下行EPS Bearer在SGW的TEID值，发送Modify Bearer Request消息给PGW，这样切换后的下行数据通道在PGW到目标SGW之间的部分建立了起来。这样整个的PGW到目标eNodeB之间的下行通道就建立完毕。下行数据就可以从PGW，经由目标SGW以及目标eNodeB到达UE了。 PGW更新相应的上下文，分配相应的上行EPS Bearer在PGW的TEID值，返回Modify Bearer Response消息给目标SGW。 17：目标SGW收到PGW的回应后，上行通道在SGW到PGW的部分可以建立，目标SGW返回Modify Bearer Response 消息给目标MME。目标MME到目标SGW的上行通道已经在步骤4建立起来，在步骤16中，PGW可以在切换后分配不同的上行TEID值。 18：UE可以触发相应的TAU的过程。 随后的步骤中，源MME和目标MME将触发相应的资源释放过程。 2：S1-based handover, Reject The Target eNodeB rejects the use of the Handover procedure if none of the requested bearers in the Handover Request message could be established. In this case no UE context is established in the target MME/eNodeB and no resources are allocated. Further, the Target MME rejects the handover request and clears all resource in Target eNodeB and Target MME if the Target eNodeB accepts the handover request but none of the default EPS bearers gets resources allocated. In both cases, the UE remains in the Source eNodeB/MME. 如果切换请求消息中没有确立请求承载，目标eNodeB拒绝切换程序。 步骤1-5和S1-based handover.normal相同。 6a.    If the Target eNodeB fails to allocate any resources for any of the requested EPS bearers it sends a Handover Failure (Cause) message to the Target MME. The Target MME clears any reserved resources for this UE in the target MME. 6b.If the Target MME receives a Handover Request Acknowledge message from the Target eNodeB but none of the default EPS bearers are in the EPS Bearer Setup list IE, the Target MME clears any reserved resources for this UE in both the Target MME and the Target eNodeB. 7.    This step is only performed for Serving GW relocation, i.e. if steps 4/4a have been performed. The Target MME deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the Target Serving GW. The Target Serving GW acknowledges with Delete Session Response (Cause) messages. 8.    The Target MME sends the Forward Relocation Response (Cause) message to the Source MME. 9.    When the Source MME receives the Forward Relocation Response message, it sends a Handover Preparation Failure (Cause) message to the Source eNodeB. 3：S1-based handover, Cancel Instead of completing the handover procedure, the source eNodeB may at any time during the handover procedure, up to the time when a handover command message is sent to the UE cancel the handover. 当 Handover Command 消息发送到 UE取消切换，源eNodeB 会立即更新。 The MME shall cancel the handover resources as defined in clause 5.5.2.5.1 for case the source RAN is eNodeB. 1.    The source RAN decides to cancel the previously requested relocation of Handover resources. This may be due to not enough accepted bearers, UE returned to source cell or any other reason. 2.    The source RAN sends a Cancel message with a Cause to the source EPC node (SGSN or MME). If the source RAN is: a)    BSS the message sent is PS Handover Cancel (Cause), b)    RNC the message sent is Relocation Cancel (Cause), or c)    eNodeB the message sent is Handover Cancel (Cause). 3.    The source EPC node terminates the relocation towards the target side by sending a Relocation Cancel Request (IMSI) message to the target EPC node. The Source EPC node also resumes operation on the resources in the source side. 4.    The target EPC node triggers the release of resources in the target RAN and also releases its own resources allocated for this handover. 5.    This step is only performed for Serving GW relocation. The Target EPC node deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the Target Serving GW. The Target Serving GW acknowledges with Delete Session Response (Cause) messages. 6.    The target EPC node acknowledge the release of all resources on the target side by returning a Relocation Cancel Response (Cause) message to the source EPC node. 7.    The source EPC node returns a Cancel acknowledge message to the source RAN. If the source RAN is: a)    BSS there will be no acknowledge message sent to the source BSS, b)    RNC the message sent is Relocation Cancel Acknowledge (Cause), or c)    eNodeB the message sent is Handover Cancel Acknowledge (Cause). 8.    If indirect forwarding tunnel is setup during handover preparation then cancellation of handover triggers the source MME/SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the SGW to release the temporary resources used for indirect forwarding. 9.    If indirect forwarding tunnel is setup during handover preparation and serving GW is relocated then cancellation of handover triggers the target MME/SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the SGW to release the temporary resources used for indirect forwarding.