任 驰，马瑞涛（中国联通研究院，北京 100176）

1 概述

3GPP 在R15阶段针对5G 系统定义了一些有助于降低网络端到端延迟并提升可靠性的特性，如SSC 模式2 或3 下的PDU 会话锚点重定位，AF 影响下的数据流量路由等，但单纯的用户面传输路径优化并不能够解决所有的问题，网络中的其他因素如UE 移动性等仍有可能会导致用户业务延迟和抖动的增加，进而影响到极端性能要求下业务的体验。针对这些问题，3GPP 在R16 阶段专门针对极高可靠性低延迟通信（uRLLC）业务场景定义了新的网络架构和增强能力要求，通过UE 和外部数据网络之间用户面的冗余传输机制，提升用户业务的可靠性体验，进而实现通过5G网络满足uRLLC业务性能需求的目标。

为支持高可靠性通信能力，3GPP 基于uRLLC 业务需求，定义了2 种用户面冗余传输方案以提升数据传输的可靠性，分别为：基于双连接的端到端冗余用户面路径方案和冗余N3/N9接口传输方案。

同时，为协助运营商对uRLLC 业务进行性能监控和管理，定义了不同粒度的QoS 监控机制，包括每UE的每QoS 流粒度的QoS 监控和每GTP-U 隧道粒度的QoS监控。

2 用于高可靠性通信的冗余传输机制

2.1 基于双连接的端到端冗余用户面路径方案

为了支持高可靠性的uRLLC 业务，UE 可以在5G网络中建立一对冗余的PDU 会话，为保障这2 个PDU会话用户面数据传输互不影响，网络应确保这2 个PDU 会话的用户面路径是互不交叉的，该方案即为基于双连接的端到端冗余用户面路径方案。在实际的会话建立过程中，UDM 通过向SMF 提供对应的指示，指示SMF 该用户所使用的业务是否允许建立冗余的PDU会话。

基于不同的业务场景和应用能力，应用侧可以通过不同的高层协议，如IEEE TSN（Time Sensitive Networking）FRER（Frame Replication and Elimination for Reliability），利用冗余的用户面路径进行端到端的数据流量分发，实现业务数据在发端的复制和在收端的消除。如当应用传输上行业务流量时，UE端的应用客户端可以进行上行数据报文的复制，并将重复的上行数据报文通过所建立的2个冗余PDU会话发送至应用服务器端，应用服务器端在接收到复制的冗余上行数据报文后，基于特定的机制进行冗余数据报文的消除以及数据报文的排序，完成上行数据的发送和接收。反之，下行数据的发送和接收也可以通过应用服务器端的数据报文复制以及UE 应用客户端的数据报文消除实现。所有的冗余传输机制通过应用层实现，对3GPP系统本身没有特殊的要求。

为了建立完全冗余的端到端用户面路径，运营商在实际的网络部署中应该尽可能确保冗余系统间各自的独立性，包括：

a）RAN 支持双连接能力，并且在uRLLC 业务的目标区域内，支持双连接的RAN 侧覆盖足够满足业务要求。

b）UE支持双连接功能。

c）核心网侧的UPF 部署需要和RAN 侧部署对齐，支持建立冗余用户面路径。

d）底层的传输拓扑也应和RAN 以及UPF 部署对齐，确保传输网转发面路径也是互不交叉的。

e）物理网络的拓扑和地理分布应在运营商认为的足够范围内支持必要的冗余用户面路径。

f）整体冗余用户面的操作应在运营商认为的范围内足够独立，如分别设置独立的供电系统等。

图1为使用冗余机制时的双PDU会话用户面资源配置示例。

图1 基于双连接的端到端冗余用户面路径方案架构示意

其中一个PDU 会话由UE 通过主NG-RAN（Master NG-RAN）连接到PDU 会话锚点UPF1，并最终连接到数据网络（DN），另一个PDU 会话由UE 通过副NGRAN（Secondary NG-RAN）连 接 到PDU 会 话 锚 点UPF2，并最终连接到同一个DN，在此过程中，NGRAN 应能够感知2 个PDU 会话的冗余用户面资源是否是通过2 个NG-RAN 节点建立的，以便进行后续的用户移动性及会话控制。需要注意的是，基于5G系统的移动性管理原则，即使UE的双PDU会话是通过2个NG-RAN 节点建立的，该UE 也仅有1 个到AMF 的N1连接，即这2个NG-RAN 都通过N2接口连接到同一个AMF。

基于UE 建立的2 个PDU 会话，5G 系统为UE 建立2 条独立的用户面路径。5G 网络可以通过UE 路由选择策略（URSP——UE Route Selection Policy）协助UE建立到同一个DN 的冗余PDU 会话，即PCF 可以为UE的同一个应用分别配置2 条不同的URSP 策略，这2 条URSP 策略应配置不同的流量描述符，以确保UE 在套用这2条URSP 规则时，会分别建立2个不同的PDU 会话。在实际的应用中，URSP 的配置和应用侧的系统架构及能力高度相关，但应用侧的配置和部署要求不属于运营商网络的管理范围。

在具体的冗余PDU 会话建立和管理过程中，由UE 发起2 个互为冗余的PDU 会话建立请求，UE 基于不同的URSP 策略在2 个PDU 会话的建立请求中分别携带不同的DNN 和S-NSSAI，并由SMF 基于PCF 提供的PDU 会话相关策略信息、UE 指示的DNN/S-NSSAI以及从UDM 获得的用户签约信息决定PDU 会话是否应该按冗余PDU 会话的标准进行处理。SMF 基于这些信息生成一个冗余序列号（RSN——Redundancy Sequence Number）用于区分这2 个互为冗余的PDU 会话，并通过RSN 向RAN 侧指示冗余用户面资源需求。运营商基于DNN 和S-NSSAI 的组合配置SMF 为不同的PDU 会话选择不同的UPF，并确保冗余PDU 会话的用户面路径互不相交。

在PDU 会话建立，或会话状态转换为CM-CONNECTED 时，网络通过RSN 参数向NG-RAN 指示通过双连接为对应的PDU 会话提供冗余的用户面资源，RSN 具体的取值指示了PDU 会话对应的冗余用户面需求。与不同的RSN 取值相关联的PDU 会话需要通过不同的、冗余的用户面资源进行建立，基于RSN 和RAN 侧的配置，由NG-RAN 完成双连接的建立，实现端到端冗余用户面路径的建立。

NG-RAN 根据自身配置，结合由RSN 指示的通过双连接建立的用户面资源需求判断针对一个PDU 会话的RAN 资源建立请求是否可以满足，如果可以满足针对PDU 会话的RAN 资源建立请求，即使由RSN 指示的用户面需求无法满足，PDU 会话也可以成功建立，而如果RAN 判断无法满足针对PDU 会话的RAN资源建立请求，则RAN 会拒绝该请求并最终导致SMF向UE 拒绝PDU 会话建立请求。在实际的业务过程中，针对每个PDU 会话是否能够被建立的判断是分别进行的，即使冗余PDU 会话其中之一的建立请求被网络拒绝，也不会影响另一个PDU 会话的建立。RAN 基于网络配置判断是否在无法继续保持由RSN 参数指示的资源时向SMF 发送相关的通知，以便SMF 进一步决定是否释放对应的PDU会话。

在移动性管理过程中，RSN 指示会在切换过程中从源NG-RAN发送到目标NG-RAN。

2.2 冗余N3/N9接口传输方案

除2.1 节介绍的基于双连接的端到端冗余用户面路径方案外，为解决可能的由特定回传网络部署环境等原因造成的单N3隧道可靠性不足的问题，冗余传输机制也可能会部署在PDU 会话锚点UPF 和NG-RAN之间，即通过建立关联到同一个PDU 会话的2 个独立的N3 隧道实现。这2 个N3 隧道可以进一步的通过关联到不同的传输层路径进一步增强其可靠性。

为确保所建立的用于冗余传输的2 个N3 隧道通过互不交叉的传输层路径进行数据传输，SMF 或PDU会话锚点UPF 可在隧道信息中提供不同的路由信息，如不同的IP 地址，或不同的网络实例，这些路由信息进一步由网络基于网络部署配置映射为互不交叉的传输层路径。在对应的隧道建立过程中，SMF 向NGRAN 和PDU 会话锚点UPF 指示2 个CN/AN 隧道信息其中之一用作对应PDU 会话的冗余隧道。利用2 个N3/N9 隧道的冗余传输以QoS 流的粒度进行，同一个QoS 流在冗余N3/N9 隧道中的传输共享同一个QoS 流ID。

在一个uRLLC 业务的QoS 流建立期间，或建立完成后，如果SMF 基于授权的5QI、NG-RAN 节点能力、运营商配置等因素决定执行冗余传输，SMF 分别通过N2信息和N4接口通知NG-RAN 和PDU会话锚点UPF建立冗余用户面隧道。在这种情况下，NG-RAN 也需要在隧道信息中提供不同的路由信息如不同的IP 地址，以协助网络将这些路由信息映射为互不交叉的传输层路径。在用于SMF 决定是否应用冗余传输的信息中，NG-RAN 节点对N3/N9 传输能力的支持情况可以在SMF 中预先进行配置，配置的粒度可以基于网络切片粒度或基于SMF服务区域粒度。

当用户面路径仅涉及N3 接口时，即无中间UPF（I-UPF）插入情况下，冗余N3 接口传输方案如图2 所示。

图2 无中间UPF情况下的冗余N3接口传输方案架构示意

针对PDU 会话锚点UPF 从DN 收到的该QoS 流的每个下行数据报文，PDU 会话锚点UPF 对报文进行复制，并为所复制的数据报文分配相同的GTP-U 序列号以协助后续的冗余传输，NG-RAN 在接收到复制的数据报文后，将具有相同GTP-U 序列号的数据报文中冗余的数据报文消除，之后将保留的数据报文转发给UE。而针对NG-RAN 从UE 收到的该QoS流的每个上行数据报文，则由NG-RAN 对报文进行复制以及相同的GTP-U 序列号的分配，这些复制的数据报文分别通过2 条N3 隧道传输至PDU 会话锚点UPF，UPF 在接收到复制的数据报文后，将具有相同GTP-U 序列号的数据报文中冗余的数据报文消除，之后将保留的数据报文转发至DN。

当用户面路径涉及中间UPF（I-UPF）插入时，冗余N3/N9接口传输方案如图3所示。

图3 存在中间UPF情况下的冗余N3/N9接口传输方案架构

针对同时在N3和N9接口执行冗余传输机制的情况，在NG-RAN 和PDU 会话锚点UPF 之间会插入2 个中间UPF，这2 个中间UPF 服务于同一个PDU 会话的同一个uRLLC 业务的QoS 流，此时针对下行流量，由PDU 会话锚点UPF 对下行数据报文进行复制并分配相同的GTP-U 序列号，然后将这2 个具有相同GTP-U序列号的下行数据报文分别通过2 条N9 隧道发送到不同的中间UPF，再分别由这2 个中间UPF 通过不同的N3 隧道发送至NG-RAN，最终NG-RAN 完成重复数据报文的消除后将数据发送给UE。上行流量的数据报文传送机制和下行类似。在涉及插入中间UPF的情况下，NG-RAN 和PDU 会话锚点UPF 需要如上文所述支持数据报文的复制和消除功能，但中间UPF 不需要支持和执行这些功能。

2.3 传输层的冗余传输

在数据网络DN 的应用层不支持专门用于冗余传输的协议（如IEEE FRER），同时5G 系统也不支持冗余的N3 隧道机制的情况下，仍然可以通过在UPF 和NG-RAN 之间提供2条不相交的回传传输路径实现冗余传输能力，在这种情况下，NG-RAN 和UPF 内的冗余处理功能利用这2条独立的传输路径实现对上下行uRLLC 业务流量的冗余处理。单纯的传输层冗余机制不影响已有的3GPP协议。

UE 发起一个用于uRLLC 业务的PDU 会话，SMF通过DNN、S-NSSAI、UPF 支持传输层冗余机制能力的情况等信息为该PDU 会话选择一个合适UPF，并指示UPF 和NG-RAN 之间建立一条N3 隧道。针对下行数据传输，UPF 在单一的N3 隧道上发送下行数据报文，UPF的冗余处理功能在传输层进行下行数据报文的复制，NG-RAN 的冗余处理功能消除复制数据报文并将其发送给NG-RAN 的正常用户面报文处理模块，并由NG-RAN 最终发送给UE。同理，针对上行数据报文，由NG-RAN 的冗余处理功能在传输层的回传部分对报文进行复制，由UPF 的冗余处理功能消除复制报文并转发给UPF 的正常用户面报文处理模块，并最终转发至数据网络DN。

3 针对uRLLC业务的QoS监控

为配合移动网运营商进行uRLLC 业务的性能监控和管理，5G 系统支持用于QoS 监控的报文延迟测量机制。在UE 和PDU 会话锚点UPF 之间的报文延迟包括上下行报文的Uu 接口延迟以及NG-RAN 和PDU 会话锚点UPF 之间的延迟。针对上下行数据报文延迟的QoS 监控可以在不同粒度上进行，包括每UE 的每QoS流粒度以及每GTP-U 隧道粒度等。具体的QoS监控执行粒度可基于运营商策略，第三方应用需求等因素决定，并通过PCF 的PCC 策略进行配置、下发和执行。

3.1 每UE每QoS流粒度

以每UE 每QoS 流粒度进行的上下行报文端到端延迟测量由SMF 在PDU 会话建立或修改的过程中激活，在此过程中，SMF 分别向PDU 会话锚点UPF 和NG-RAN 发送QoS 监控请求，要求进行UE 和PDU 会话锚点之间的上下行报文延迟测量，SMF 基于PCF 发送的QoS监控策略信息生成对应的监控参数并包含在发送给NG-RAN 和PDU 会话锚点UPF 的QoS 监控请求中，对应的监控参数也可以在SMF本地进行配置。

在端到端的报文延迟测量中，由NG-RAN 基于SMF 下发的监控参数进行Uu 接口的上下行报文延迟测量，并将测量结果通过上行数据报文发送给PDU 会话锚点UPF，NG-RAN 也可以在没有可用的上行数据报文的情况下自行生成一个伪上行报文（Dummy UL Packet），并将Uu 接口的上下行报文延迟测量结果包含在其中上报给PDU会话锚点UPF。

如果NG-RAN 和PDU 会话锚点是时间同步的，那么单向的NG-RAN 和PDU 会话锚点UPF 之间的报文延迟监控通过在GTP-U 报文头中传送时间戳的方式支持，NG-RAN和PDU会话锚点UPF分别在GTP-U的报文头中封装QoS 监控报文指示，用于表示该报文是用于上下行报文延迟测量的，并同时在其中封装本地时间。PDU会话锚点UPF基于所接收到的QoS监控报文中的时间戳以及本地时间进行NG-RAN 和PDU 会话锚点UPF 之间的上行和下行报文延迟的计算，并结合接收到的由NG-RAN 上报的Uu 接口的上下行报文延迟，最终得到端到端的数据报文延迟并上报给SMF。

如果NG-RAN 和PDU 会话锚点UPF 不是时间同步的，那么后续的计算需要假设在NG-RAN 和PDU 会话锚点UPF 之间的上行和下行的数据报文延迟是一样的，在此前提下，由PDU 会话锚点UPF 生成监控报文并发送给NG-RAN，在此过程中：

a）PDU 会话锚点UPF 在发送下行数据报文时，在GTP-U 报文头中封装QoS 监控报文指示以及此时PDU会话锚点UPF的本地时间T1。

b）NG-RAN 记录接收到的来自PDU 会话锚点UPF 的QoS 监控报文中的时间戳T1 以及NG-RAN 接收到该报文时NG-RAN 的本地时间T2，同时发起Uu接口上下行报文延迟测量。

c）在接收到UE 发送的上行数据报文或NG-RAN发送伪上行报文用于监控响应时，NG-RAN 在上行报文的GTP-U 报文头中封装QoS 监控指示、上述PDU 锚点发送下行报文时封装的时间戳T1、NG-RAN 收到T1报文时的本地时间T2 以及此时NG-RAN 的本地时间T3，并将其发送给PDU会话锚点UPF。

d）PDU 会话锚点UPF 记录收到上述上行QoS 监控响应报文时的时间戳T4，并通过公式（T2-T1+T4-T3）/2 计算得到NG-RAN 和PDU 会话锚点UPF 之间的数据报文延迟，结合从NG-RAN 收到的Uu 接口报文延迟得到端到端的报文延迟，最终上报给SMF。

在应用了N3/N9 接口冗余传输的情况下，PDU 会话锚点UPF和NG-RAN 将分别在2条用户面路径上进行QoS 监控，并由PDU 会话锚点UPF 向SMF 分别报告2条用户面路径的报文延迟。

3.2 每GTP-U隧道粒度

每GTP-U 隧道粒度的QoS 监控同样由SMF 发起，并由SMF 分别向UPF 和NG-RAN 下发对应的QoS 监控请求。NG-RAN 或UPF 通过向对端发送Echo请求，并测量发送Echo 请求和收到Echo 响应之间的时长来估算NG-RAN 和UPF 之间GTP 隧道的双向延迟（RTT——Round Trip Delay），NG-RAN 或UPF 通过累加RTT/2、节点自身处理时长以及可能的其他节点如IP设备的处理时长，得到估算的GTP-U 隧道的数据报文延迟。

为了能够及时掌握传输延迟的变化，NG-RAN 或UPF 可以周期性地进行RTT 的测量。GTP-U 隧道粒度的QoS 监控由接收并存储了包括报文延迟预算等QoS 信息的GTP-U 端点执行，该GTP-U 端点通过比较接收到的累加的报文延迟和QoS参数中的报文延迟预算判断当前的RTT 是否超出了所要求的延迟需求，如果当前的GTP-U 隧道延迟超出了业务所要求的延迟要求，GTP-U 端点将会基于运营商的管理需求触发一个到对应控制面网络功能如SMF 或OAM 的QoS 监控告警信令，用于触发运营商进行后续的uRLLC 业务性能管理和优化过程。

4 结束语

uRLLC 是垂直行业尤其是工业制造相关产业所关注的重要场景，同时也是移动网运营商介入垂直行业市场所需要具备的重要能力。本文根据3GPP 相关标准的要求，重点分析了5G 核心网支持uRLLC 能力的系统架构增强要求，讨论了用于uRLLC 业务的几种不同的冗余传输机制，并介绍了支持运营商进行uRLLC业务性能管理的QoS监控方案。

uRLLC 所面向的业务场景对业务延迟、抖动以及可靠性等性能要求相对苛刻，相关的能力增强除了对5G 网络设备功能本身的要求外，还对运营商端到端整体的网络部署如无线侧NG-RAN 的覆盖规划，传输网的冗余传输路径设置等有较高的需求，极致的uRLLC业务体验保障也必将带来网络建设和运营成本的水涨船高，因此在后续针对uRLLC 业务需求和场景的网络部署及业务对接落地的过程中，如何在考虑网络建设成本的情况下满足行业用户的业务需求，形成uRLLC 整体性和系统性的建设和运营思路，将是下一步运营商网络演进研究和网络业务运营过程中需要重点考虑的内容。