本文技术原理深度参考了3GPP TS 23.501 V18.9.0 (2025-03) Release 18规范中，关于“5.33 Support for Ultra Reliable Low Latency Communication”的核心章节，旨在为读者提供一个5G网络如何通过多层次的冗余机制，为要求最严苛的URLLC业务构建“永不中断”的通信链路的全景视图。

深度解析 3GPP TS 23.501：5.33 Support for Ultra Reliable Low Latency Communication (超可靠低时延通信支持)

欢迎来到“解构5G核心网”系列。在之前的文章中，我们已经探索了5G如何通过切片为不同业务划分“车道”，通过优先级机制为VIP车辆“开路”。今天，我们将把目光投向金字塔尖的需求——那些一毫秒都不能等、一个包都不能丢的关键任务。这就是URLLC（超可靠低时延通信）。

URLLC是5G区别于前几代移动通信技术的关键能力之一，它将移动网络的角色从“通信娱乐”提升到了“工业生产”和“生命攸关”的层面。远程手术、自动驾驶、电网差动保护、工厂精准协同，这些场景对网络的可靠性要求达到了前所未有的“六个九”（99.9999%），甚至更高。

为了实现这一目标，5G不能再依赖单路径的“尽力而为”或简单的QoS保障，它必须引入一种全新的设计哲学——冗余（Redundancy）。本篇，我们将深入规范的5.33章节，揭示5G是如何通过构建端到端的冗余用户面路径，来打造这条“永不中断”的数字生命线的。

为了具象化地理解这一极致的可靠性追求，让我们引入今天的场景。“领航者一号”是一辆正在城市复杂路况下进行L4级测试的自动驾驶汽车。在远程监控中心，安全员陈师傅正实时监控着车辆传回的多路高清视频，并随时准备在紧急情况下，通过远程驾驶（Tele-driving）接管车辆。

从陈师傅按下指令到车辆执行，整个来回的延迟必须在20毫秒以内；更重要的是，从车辆到监控中心的视频流和从监控中心到车辆的控制流，绝对不能中断。任何瞬间的连接丢失，都可能导致灾难性后果。我们将通过“领航者一号”的这次测试，来剖析5G是如何为它构建“双保险”甚至“多保险”通信链路的。

---

1. URLLC的核心：冗余传输 (5.33.1 General & 5.33.2 Redundant transmission for high reliability communication)

URLLC的目标不仅仅是低延迟，更核心的是高可靠性。为了对抗无线环境的不可预测性（如信号遮挡、干扰），唯一的办法就是“不要把所有鸡蛋放在一个篮子里”——即冗余传输。

In order to support highly reliable URLLC services, a UE may set up two redundant PDU Sessions over the 5G network, such that the 5GS sets up the user plane paths of the two redundant PDU Sessions to be disjoint. The user’s subscription indicates if user is allowed to have redundant PDU Sessions and this indication is provided to SMF from UDM.

这段原文开宗明义，点出了实现URLLC高可靠性的核心手段：建立两条（或多条）冗余且分离（disjoint）的PDU会话。

1.1 “双保险”设计理念

这个设计的核心思想，是在UE（或车载终端）和数据网络（DN）之间，建立两条物理上和逻辑上都尽可能相互独立的端到端用户面路径。应用层（如自动驾驶系统）可以将同一份关键数据（如一个控制指令或一帧视频）复制两份，分别从这两条路径发送出去。只要其中任何一条路径能够成功送达，通信就不会中断。

规范在“Figure 5.33.2.1-1: Example scenario for end to end redundant User Plane paths using Dual Connectivity”中清晰地展示了这种架构。图中，一个UE同时通过主基站（Master RAN node）连接到UPF1，并通过辅基站（Secondary RAN node）连接到UPF2，从而形成了两条端到端的独立路径。

1.2 场景代入：“领航者一号”的双重生命线

为了保障绝对的可靠性，“领航者一号”上安装了两个独立的5G通信模组（即两个UE）。

• 模组A（UE1）： 通过车载天线A，连接到了路边的基站gNB-1。它建立的PDU会话，被SMF-1锚定在了运营商边缘机房A的UPF-1上。
• 模组B（UE2）： 通过车载天线B，连接到了另一栋楼顶的基站gNB-2。它建立的PDU会话，被SMF-2锚定在了运营商边缘机房B的UPF-2上。

当自动驾驶系统需要向陈师傅的监控中心发送一帧关键视频数据时，它会将这帧数据复制一份，一份交给模组A，一份交给模组B。这两份相同的数据将沿着两条完全不同的物理路径（不同的基站、不同的传输网络、不同的UPF）传输。即使其中一条路径因为信号被高楼遮挡而瞬时中断，另一条路径的数据依然能够准时到达，确保了陈师傅看到的监控画面毫无卡顿。

---

2. 构筑“双活”链路：端到端冗余路径的建立 (5.33.2.1 Dual Connectivity based end to end Redundant User Plane Paths)

如何才能确保这两条路径是真正“分离”的？规范要求在RAN、核心网和传输网等多个层面都实现冗余。

The operation of the redundant user plane paths is made sufficiently independent, to the extent deemed necessary by the operator, e.g. independent power supplies.

2.1 端到端分离的要素

1. RAN侧分离： 最理想的情况是使用双连接（Dual Connectivity），UE同时连接到两个不同的基站（Master gNB 和 Secondary gNB），这两个基站最好物理位置也不同。
2. 核心网用户面分离： 这两条路径必须锚定在不同的UPF上。SMF在选择UPF时，需要根据策略，为这两条冗余的PDU会话选择物理上分离的UPF实例。
3. 传输网分离： 连接RAN和UPF的N3接口，以及UPF之间的N9接口，都应该走在物理上不同的传输链路上（如不同的光纤路由）。
4. 基础设施分离： 更严格的部署，甚至要求这两个UPF、两个gNB位于不同的机房，由不同的电源供电。

2.2 “配对”的信令：PDU Session Pair ID 与 RSN

网络如何知道这两个看似独立的PDU会话，实际上是一对“孪生兄弟”，需要为它们提供冗余保障呢？这就需要UE在建立会话时提供特殊的“配对”信息。

When URSP is used to establish two redundant PDU Sessions, duplicated traffic from the application… is differentiated by two distinct traffic descriptors, each in a distinct URSP rule… These Route Selection Descriptors of distinct URSP rules may include corresponding RSNs and PDU Session Pair IDs.

• PDU Session Pair ID: 这是一个唯一的ID，用于将两条PDU会话“绑定”在一起，告诉网络它们是互为冗余的一对。
• RSN (Redundancy Sequence Number): 这个参数（在URSP中定义）和另一个参数Redundancy（在PDU会话中）一起，告知NG-RAN这条PDU会话需要冗余处理，并可能指示具体的冗余级别或类型。

流程：

1. URSP规则配置： 运营商在URSP规则中，为自动驾驶应用配置两条规则，它们指向不同的DNN/S-NSSAI组合，但拥有相同的PDU Session Pair ID。
2. UE发起请求： “领航者一号”上的两个UE模组，根据URSP规则，分别发起PDU会话建立请求，并在请求中带上这个PDU Session Pair ID和相应的RSN。
3. 网络侧协同：
   • AMF将请求转发给SMF。
   • SMF看到PDU Session Pair ID，就明白了这是一个冗余会话请求。它会根据策略选择一个与“孪生兄弟”会话物理分离的UPF。
   • SMF将RSN和PDU Session Pair ID等信息传递给NG-RAN。
   • NG-RAN收到这些信息后，就知道了需要为这条会话启用双连接等冗余的无线资源分配方案。

---

3. 其他冗余模式：N3/N9隧道冗余与传输层冗余

除了端到端的双PDU会话模式，规范还定义了两种更轻量级的冗余方式，它们不直接对UE可见。

3.1 N3/N9隧道冗余 (5.33.2.2)

To ensure the two N3 tunnels are transferred via disjointed transport layer paths, the SMF or PSA UPF should provide different routing information in the tunnel information… The redundant transmission using the two N3/N9 tunnels are performed at QoS Flow granularity…

• 原理： 对于单个PDU会话，在RAN和UPF之间建立两条并行的N3（或N9）GTP-U隧道。UPF在下行方向复制数据包，分别从两条隧道发出；RAN在接收到后进行去重。上行方向则相反。
• 适用场景： 这种模式主要用于对抗核心网传输链路的故障，而不能对抗空口链路的故障。

场景代入： 假设连接gNB-1和UPF-1之间有两条不同的光纤路径。SMF可以指示gNB-1和UPF-1在这两条光纤上，为“领航者一号”的同一个QoS Flow建立两条N3隧道。UPF会将发给“领航者一号”的数据包复制一份，同时从两条隧道发出。即使其中一条光纤被意外挖断，数据依然可以通过另一条到达基站。

3.2 传输层冗余 (5.33.2.3)

Redundant transmission can be supported within the 5G System without making any assumption on support for protocols such as IEEE FRER in the application layer (DN only) at the same time it can be supported without requiring redundant GTP-U tunnel over N3. The backhaul provides two disjoint transport paths between UPF and NG-RAN.

• 原理： 这是最透明的一种方式。GTP-U层面上只有一条N3隧道，但底层的IP传输网络自身具备冗余和快速路径切换能力（例如，MPLS FRR）。当主传输路径故障时，底层IP网络会自动将GTP-U包切换到备用路径上。
• 适用场景： 当运营商的承载网本身就具备高可靠性时，可以使用这种方式。

---

4. “健康监测”：URLLC的QoS监控 (5.33.3)

对于URLLC业务，仅仅建立冗余连接是不够的，还需要持续监控其服务质量，特别是端到端时延。

QoS Monitoring for packet delay can be applied based on 3rd party application request or PCF policy control or both, e.g. to assist URLLC services.

核心机制：

• AF/PCF发起： 陈师傅的监控中心（AF）向PCF请求对“领航者一号”的PDU会话进行时延监控。
• SMF配置： PCF生成策略，SMF根据策略，向UPF和RAN下发QoS监控请求。
• RAN/UPF测量：
  • RAN侧时延： NG-RAN负责测量数据包在空口传输的时延。
  • CN侧时延： UPF和RAN之间通过带时间戳的GTP-U扩展头或其他机制，测量数据包在N3/N9隧道中的传输时延。
• 结果上报： UPF汇总RAN和CN的时延数据，计算出端到端的时延，并根据SMF的指令进行上报。

场景代入： SMF为“领航者一号”的两条冗余PDU会话都激活了时延监控。监控中心的大屏上实时显示着两条链路的端到端时延。当陈师傅发现路径A的时延从10ms突然跳升到30ms时，虽然路径B依然正常，业务没有中断，但这已经是一个潜在的风险信号。他可以立即通知网络运维团队（李工）进行排查，从而在故障真正发生前，就将其消除在萌芽状态。

5. FAQ

Q1: URLLC的冗余传输和我们之前谈到的ATSSS（Wi-Fi/5G协同）有什么区别？

A: 虽然两者都利用了多条路径，但它们的目的和实现层次完全不同。

• ATSSS 的核心是多接入（Multi-Access），即同时使用3GPP和non-3GPP两种不同类型的接入技术。它的主要目的是提升吞吐量（负载均衡）、实现无缝切换（主备）或根据网络质量进行智能选择。它主要解决的是不同技术间的协同问题。
• URLLC的冗余传输 的核心是冗余（Redundancy），通常是在同一种接入技术（如5G NR）内部，构建两条或多条物理和逻辑上都分离的路径。它的唯一目的是提升可靠性，通过复制数据包来对抗单点故障。它解决的是“有或无”的问题，而非“快或慢”的问题。

Q2: 实现端到端冗余PDU会话，是否意味着我的设备（如自动驾驶汽车）必须安装两个SIM卡？

A: 不一定需要两个物理SIM卡，但需要两个独立的UE通信模组。这两个模组可以：

• 使用两个独立的物理SIM/eSIM。
• 使用同一个支持多USIM profile的eSIM，但在逻辑上作为两个独立的UE向网络注册。 关键在于，设备需要具备同时与两个不同基站建立和维持RRC连接的能力，并拥有两个独立的协议栈来处理两个并行的PDU会话。

Q3: 谁来负责复制数据包，以及在接收端去掉重复的数据包？

A: 这是一个端到端的机制，需要应用层和网络层的协同。

• 发送端复制： 数据包的复制通常发生在应用层。例如，“领航者一号”的自动驾驶系统，它会将同一个控制指令或视频帧，分别发送给两个5G通信模组（UE1和UE2）。
• 接收端去重： 接收端的应用层（例如，陈师傅的远程监控平台）需要负责处理收到的重复数据包。它会根据数据包的序列号或时间戳，只采纳第一个到达的数据包，并丢弃后续到达的重复包。 3GPP网络本身（如UPF和RAN）在某些冗余模式下（如N3/N9隧道冗余）也具备复制和去重的能力，但在端到端的双PDU会话模式中，这个任务主要由两端的应用来完成。

Q4: 如果我只是想让我的VoNR通话更可靠，网络会为我建立两条冗余的PDU会话吗？

A: 通常不会。 端到端的双PDU会话冗余是一种“重量级”的解决方案，主要针对可靠性要求达到极致的URLLC业务。 普通的VoNR通话，其可靠性主要通过以下方式保障：

1. 高优先级的QoS Flow： 使用5QI=1，具有高优先级的ARP，在网络拥塞时可以优先获得资源。
2. 快速切换： 优化的切换参数，确保在移动时能够快速、平滑地切换到新的小区。
3. EPS Fallback： 在5G语音不可用时，能够快速回落到4G的VoLTE。 这些机制已经能够为语音通话提供非常高的可靠性，足以满足绝大多数商用场景的需求，无需动用双PDU会话这样的“终极武器”。

Q5: PDU Session Pair ID和RSN这两个参数，UE是如何获取的？

A: 这两个参数的来源可以是UE侧的配置，也可以是网络侧的策略。

• 通过URSP规则： 这是最主要的方式。运营商的PCF会为需要冗余通信的应用，生成两条特殊的URSP规则。这两条规则除了流量描述符不同外，会包含相同的PDU Session Pair ID和相应的RSN值。当UE的应用流量匹配到这两条规则时，UE就能从中解析出这些参数，并在建立PDU会话时使用。
• UE本地配置/实现： 规范也允许UE根据自身的实现逻辑来决定何时使用冗余会话。例如，一个高度定制化的工业终端，可能在内部硬编码了当某个特定应用启动时，就必须建立两条带有特定PDU Session Pair ID的会话。

无论来源如何，这两个参数都是UE与网络之间的“暗号”，用于启动和协调整个端到端的冗余流程。