5G NR双激活协议栈（DAPS）~导入

so~what

已于 2022-07-02 16:49:07 修改

阅读量1.2k

点赞数

分类专栏：通信一点通文章标签：通信 5G

于 2022-07-02 16:42:35 首次发布

本文链接：https://blog.csdn.net/qfturauyls/article/details/125574213

版权

通信一点通专栏收录该内容

23 篇文章 22 订阅

订阅专栏

名词解释

3GPP在TS38.300 R16（Stage2）中定义了支持“双激活协议栈（DAPS-Dual Active Protocol Stack）”切换。

在双激活协议栈切换中终端在接收到含有切换命令的RRC消息后仍将保持与源gNB的资源连接，直到成功完成在目标gNB上随机接入后再释放源小区。---这类似于3G时代的”软切换“。

In case of DAPS handover, the UE continues the downlink user data reception from the source gNB until releasing the source cell and continues the uplink user data transmission to the source gNB until successful random access procedure to the target gNB.

为什么需要DAPS切换？

在传统的4G LTE网络和5G NR直到R15，UE通常在与目标小区建立连接之前从源小区释放连接（硬切换），从而导致UE和基站之间的通信中断几十毫秒。这种中断对于5G的URLLC场景应用是非常致命的。

因此协议提出了一种解决方案来解决这个问题，作为R16的一部分，称为双激活协议栈（DAPS），其中UE与源小区连接以保持对用户数据的收发，直到它能够在目标小区中发送和接收用户数据。这对UE端提出了新的要求，即在切换过程中，短时间内同时在源小区和目标小区收发数据。类似于软切换。

DAPS的切换特性

如上图所示，为了支持DAHO，UE必须保持Dual Stack处于活动状态。目标小区的一个用户平面协议栈，包含PHY（物理），MAC（媒体访问控制）和RLC（无线电链路控制）层，同时保持第二个用户平面协议栈处于活动状态，以便在源小区中传输和接收用户数据。

UE同时从源和目标小区接收用户数据，PDCP（分组数据汇聚协议）层被重新配置为用于源和目标用户平面协议栈的通用PDCP实体。为了确保按顺序传送用户数据，在整个切换过程中都将保持PDCP序列号（SN）的连续性。因此在单个PDCP实体中提供了一个通用的（针对源和目标）重新排序和复制功能。加密/解密和报头压缩/解压缩需要在公共PDCP实体中分别处理，具体取决于下行链路/上行链路数据包的来源/目标。

UE收到HO请求后，在源小区继续发送Tx / Rx。
UE同时执行来自源小区和目标小区的用户数据接收。
在RACH程序完成后，UE将用户数据的上行链路传输切换到目标小区。
DAPS通过在建立目标小区无线链路的同时保持源小区无线链路（包括数据流），在接近0 ms的切换过程中减少了中断。
在接口Xn和N2上都可以进行DAPS切换。
DAPS切换可用于RLC-AM或RLC-UM承载。
When DAPS handover fails, the UE falls back to the source cell configuration, resumes the connection with the source cell, and reports DAPS handover failure via the source without triggering RRC connection re-establishment if the source link has not been released.
Only source and target PCell are used during DAPS handover. CA, DC, SUL, multi-TRP, EHC, CHO, UDC, NR sidelink configurations and V2X sidelink configurations are released by the source gNB before the handover command is sent to the UE and are not configured by the target gNB until the DAPS handover has completed (i.e. at earliest in the same message that releases the source PCell).

DAPS切换流程

0. The UE context within the source gNB contains information regarding roaming and access restrictions which were provided either at connection establishment or at the last TA update.

1. The source gNB configures the UE measurement procedures and the UE reports according to the measurement configuration.

2. The source gNB decides to handover the UE, based on MeasurementReport and RRM information.

3. The source gNB issues a Handover Request message to the target gNB passing a transparent RRC container with necessary information to prepare the handover at the target side. The source gNB may also request a DAPS handover for one or more DRBs.

NOTE 1: After issuing a Handover Request, the source gNB should not reconfigure the UE, including performing Reflective QoS flow to DRB mapping.

4. Admission Control may be performed by the target gNB. Slice-aware admission control shall be performed if the slice information is sent to the target gNB. If the PDU sessions are associated with non-supported slices the target gNB shall reject such PDU Sessions.

5. The target gNB prepares the handover with L1/L2 and sends the HANDOVER REQUEST ACKNOWLEDGE to the source gNB, which includes a transparent container to be sent to the UE as an RRC message to perform the handover. The target gNB also indicates if a DAPS handover is accepted.

NOTE 2: As soon as the source gNB receives the HANDOVER REQUEST ACKNOWLEDGE, or as soon as the transmission of the handover command is initiated in the downlink, data forwarding may be initiated.

NOTE 3: For DRBs configured with DAPS, downlink PDCP SDUs are forwarded with SN assigned by the source gNB, until SN assignment is handed over to the target gNB in step 8b, for which the normal data forwarding follows as defined in 9.2.3.2.3.

6. The source gNB triggers the Uu handover by sending an RRCReconfiguration message to the UE, containing the information required to access the target cell: at least the target cell ID, the new C-RNTI, the target gNB security algorithm identifiers for the selected security algorithms. It can also include a set of dedicated RACH resources, the association between RACH resources and SSB(s), the association between RACH resources and UE-specific CSI-RS configuration(s), common RACH resources, and system information of the target cell, etc.

NOTE 4: For DRBs configured with DAPS, the source gNB does not stop transmitting downlink packets until it receives the HANDOVER SUCCESS message from the target gNB in step 8a.

NOTE 4a: CHO cannot be configured simultaneously with DAPS handover.

7a. For DRBs configured with DAPS, the source gNB sends the EARLY STATUS TRANSFER message. The DL COUNT value conveyed in the EARLY STATUS TRANSFER message indicates PDCP SN and HFN of the first PDCP SDU that the source gNB forwards to the target gNB. The source gNB does not stop assigning SNs to downlink PDCP SDUs until it sends the SN STATUS TRANSFER message to the target gNB in step 8b.

7. For DRBs not configured with DAPS, the source gNB sends the SN STATUS TRANSFER message to the target gNB to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of DRBs for which PDCP status preservation applies (i.e. for RLC AM). The uplink PDCP SN receiver status includes at least the PDCP SN of the first missing UL PDCP SDU and may include a bit map of the receive status of the out of sequence UL PDCP SDUs that the UE needs to retransmit in the target cell, if any. The downlink PDCP SN transmitter status indicates the next PDCP SN that the target gNB shall assign to new PDCP SDUs, not having a PDCP SN yet.

NOTE 5: In case of DAPS handover, the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status for a DRB with RLC-AM and not configured with DAPS may be transferred by the SN STATUS TRANSFER message in step 8b instead of step 7.

NOTE 6: For DRBs configured with DAPS, the source gNB may additionally send the EARLY STATUS TRANSFER message(s) between step 7 and step 8b, to inform discarding of already forwarded PDCP SDUs. The target gNB does not transmit forwarded downlink PDCP SDUs to the UE, whose COUNT is less than the conveyed DL COUNT value and discards them if transmission has not been attempted already.

8. The UE synchronises to the target cell and completes the RRC handover procedure by sending RRCReconfigurationComplete message to target gNB. In case of DAPS handover, the UE does not detach from the source cell upon receiving the RRCReconfiguration message. The UE releases the source resources and configurations and stops DL/UL reception/transmission with the source upon receiving an explicit release from the target node.

NOTE 6a: From RAN point of view, the DAPS handover is considered to only be completed after the UE has released the source cell as explicitly requested from the target node. RRC suspend, a subsequent handover or inter-RAT handover cannot be initiated until the source cell has been released.

8a/b In case of DAPS handover, the target gNB sends the HANDOVER SUCCESS message to the source gNB to inform that the UE has successfully accessed the target cell. In return, the source gNB sends the SN STATUS TRANSFER message for DRBs configured with DAPS for which the description in step 7 applies, and the normal data forwarding follows as defined in 9.2.3.2.3.

NOTE 7: The uplink PDCP SN receiver status and the downlink PDCP SN transmitter status are also conveyed for DRBs with RLC-UM in the SN STATUS TRANSFER message in step 8b, if configured with DAPS.

NOTE 8: For DRBs configured with DAPS, the source gNB does not stop delivering uplink QoS flows to the UPF until it sends the SN STATUS TRANSFER message in step 8b. The target gNB does not forward QoS flows of the uplink PDCP SDUs successfully received in-sequence to the UPF until it receives the SN STATUS TRANSFER message, in which UL HFN and the first missing SN in the uplink PDCP SN receiver status indicates the start of uplink PDCP SDUs to be delivered to the UPF. The target gNB does not deliver any uplink PDCP SDUs which has an UL COUNT lower than the provided.

9. The target gNB sends a PATH SWITCH REQUEST message to AMF to trigger 5GC to switch the DL data path towards the target gNB and to establish an NG-C interface instance towards the target gNB.

10. 5GC switches the DL data path towards the target gNB. The UPF sends one or more "end marker" packets on the old path to the source gNB per PDU session/tunnel and then can release any U-plane/TNL resources towards the source gNB.

11. The AMF confirms the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST ACKNOWLEDGE message.

12. Upon reception of the PATH SWITCH REQUEST ACKNOWLEDGE message from the AMF, the target gNB sends the UE CONTEXT RELEASE to inform the source gNB about the success of the handover. The source gNB can then release radio and C-plane related resources associated to the UE context. Any ongoing data forwarding may continue.