URSP路由选择策略全链拆解：从PCF下发到UE流量匹配的完整机制

一、URSP在5G网络切片体系中的定位

在5G网络切片（Network Slicing）的工程实现中，存在一个长期被低估却决定端到端切片成败的关键机制——URSP（UE Route Selection Policy，UE路由选择策略）。很多工程师把切片理解为"网络侧通过NSSF/UDM为UE选好S-NSSAI就完成了"，但实际上，当一个UE同时签约多个切片、且终端上跑着几十个不同的应用时，"哪个应用的流量走哪个切片、走哪条PDU会话、是否走非3GPP卸载"这个决策，是由UE本地的URSP规则做出的。网络侧的切片选择（TS 23.501 clause 5.15）只解决了"这个UE最多能用哪些切片"的问题，而URSP解决的是"这个UE的应用流量应当被导向哪一条具体路径"的问题。

URSP定义在 3GPP TS 23.503 clause 6.6.2，是UE Policy（TS 23.503 clause 6.6）的三大组成部分之一。UE Policy共包含三类规则：

• URSP（clause 6.6.2）：用于UE决定如何为应用流量选择路由（PDU会话/非3GPP卸载）；
• ANDSP（Access Network Discovery & Selection Policy，clause 6.6.3）：用于非3GPP接入网发现与选择；
• V2XP（Vehicle-to-Everything Policy，clause 6.6.4）：用于V2X通信策略。

本文聚焦URSP。它的设计目标是为切片差异化、边缘计算（MEC）本地分流、非无缝非3GPP卸载（NSNO）、ATSSS多接入分流提供统一的UE侧控制面。可以说，没有正确下发和匹配的URSP，运营商在核心网侧精心规划的切片隔离和MEC UPF锚点都将在终端这一环失效——因为应用流量根本不会进入预期的PDU会话。

下文按照"规则结构 → 下发信令 → UE匹配决策 → 抓包实战 → 厂商差异与排错 → 设计意图与增强"的顺序，逐层拆解URSP机制，所有引用均落实到具体TS章节。

二、URSP规则的三层结构：Precedence + Traffic Descriptor + RSD

一条URSP规则由三部分组成（TS 23.503 clause 6.6.2.2），逻辑上是一个"匹配-动作（match-action）"结构，与PCC规则中的SDF模板+QoS决策异曲同工，但运行在UE侧：

1. Rule Precedence（规则优先级）：8位整数，UE内所有URSP规则按此值升序匹配（值越小优先级越高），必须唯一；
2. Traffic Descriptor（TD，流量描述符）：匹配条件，描述"哪些应用流量命中本规则"；
3. Route Selection Descriptor List（RSD列表）：动作集合，一组有序的RSD，每个RSD描述"命中后如何路由"。

2.1 Traffic Descriptor（TD）可包含的组件

TD是"或"匹配——只要应用流量命中TD中任一组件，即视为该规则命中。其可选组件见下表（TS 23.503 Table 6.6.2.2-1）。

关键纠正：在很多二手资料里，S-NSSAI被错误地列进TD。实际上 S-NSSAI不是TD组件，而是RSD组件（见TS 23.503 Table 6.6.2.3-1）。TD只负责"认出流量"，RSD才负责"指定走哪个切片/DNN/会话"。

2.2 Route Selection Descriptor（RSD）可包含的组件

一条规则命中后，UE按RSD列表内每个RSD的 RSD Precedence 升序逐个尝试，直到找到可满足的RSD（TS 23.503 clause 6.6.2.3）。RSD组件见下表。

值得注意的是，并非每个RSD都要包含全部组件——一条RSD可以只含 S-NSSAI + DNN，另一条只含 NSNO指示，UE会按优先级"逐条试"。这种"有序尝试列表"的设计，使得运营商可以用一条URSP规则实现"主用切片不可用时回落到WLAN卸载"的弹性策略。

下面用Mermaid展示URSP规则的IE嵌套结构：

flowchart TB
    A["UE Policy Container<br/>(TS 24.501, NAS透明容器)"] --> B["MANAGE UE POLICY COMMAND"]
    B --> C["URSP Rule #1"]
    B --> D["URSP Rule #2 (Precedence更高)"]
    B --> E["URSP Rule #N"]
    C --> C0["Rule Precedence"]
    C --> C1["Traffic Descriptor (TD)"]
    C --> C2["RSD List (有序)"]
    C1 --> C1a["OS App Id / OS Id"]
    C1 --> C1b["IP 3-tuple descriptor"]
    C1 --> C1c["Domain Name descriptor"]
    C1 --> C1d["Connection Capabilities"]
    C1 --> C1e["DNN"]
    C2 --> R1["RSD-1: Precedence + 组件"]
    C2 --> R2["RSD-2: Precedence + 组件"]
    R1 --> R1a["SSC Mode"]
    R1 --> R1b["S-NSSAI (切片)"]
    R1 --> R1c["DNN"]
    R1 --> R1d["Access Type Pref"]
    R1 --> R1e["NSNO 指示"]

三、URSP下发信令全流程：PCF→AMF→UE的透传机制

URSP规则的"产生"和"送达"是分离的：PCF基于UDR中的订阅数据生成URSP规则，但PCF不直接与UE通信，而是借助AMF的N1 NAS信令透传通道下发。AMF对UE Policy Container的内容完全不解析（仅做透明转发），这一点是理解整条信令链的关键。

3.1 涉及的接口与消息

• N15（PCF↔AMF）：UE策略控制服务 Npcf_UEPolicyControl；
• N1（UE↔AMF）：NAS消息 DOWNLINK NAS TRANSPORT / UPLINK NAS TRANSPORT（TS 24.501 clause 8.2）；
• UE Policy Container内部消息：MANAGE UE POLICY COMMAND（下发）/ MANAGE UE POLICY COMPLETE（确认），定义于TS 24.501 clause 7.6 / 8.3。

3.2 两个下发时机

URSP有两个典型的下发时机（TS 23.502 clause 4.2.2.2 Registration 与 clause 4.2.4 UE Configuration Update）：

1. 初始注册时：PCF在UE策略关联建立阶段主动下发完整URSP规则集；
2. 运行中更新：订阅变更或策略变更后，PCF通过 Namf_Communication_N1N2MessageTransfer 触发AMF，由AMF透传新的UE Policy Container更新URSP。

完整信令时序如下：

sequenceDiagram
    participant UE
    participant RAN as (R)AN
    participant AMF
    participant PCF
    participant UDR
    Note over UE,PCF: 阶段一：注册中建立UE策略关联并下发URSP
    UE->>AMF: Registration Request (含Requested NSSAI)
    AMF->>PCF: Npcf_UEPolicyControl_Create<br/>(SUPI, PD, UE Policy Request)
    PCF->>UDR: Nudr_DataQuery (订阅策略数据)
    UDR-->>PCF: URSP Rule Set
    PCF-->>AMF: Npcf_UEPolicyControl_Create Response<br/>(UE Policy Container)
    AMF->>UE: DOWNLINK NAS TRANSPORT<br/>(UE Policy Container: MANAGE UE POLICY COMMAND)
    Note right of AMF: AMF不解析容器内容，仅透传
    UE->>UE: 校验规则 + 存储URSP
    UE->>AMF: UPLINK NAS TRANSPORT<br/>(MANAGE UE POLICY COMPLETE)
    AMF->>PCF: Namf_Communication_N1MessageNotify (Complete)
    Note over UE,PCF: 阶段二：策略变更触发的URSP更新
    PCF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(新UE Policy Container)
    AMF->>UE: DOWNLINK NAS TRANSPORT (MANAGE UE POLICY COMMAND)
    UE->>AMF: UPLINK NAS TRANSPORT (MANAGE UE POLICY COMPLETE)
    AMF->>PCF: Namf_Communication_N1MessageNotify

3.3 关键消息与IE逐条解析

(1) Npcf_UEPolicyControl_Create（PCF↔AMF, N15） - PCF为该UE建立UE策略关联，请求中携带SUPI、PD（Policy Decision的上下文，如DNN、S-NSSAI、接入类型）； - PCF向UDR查询订阅数据，生成与该用户签约切片匹配的URSP规则集。

(2) UE Policy Container（N1 NAS承载） - 这是核心载体，结构上是一个NAS透明容器（TS 24.501 clause 8.2.4 DOWNLINK NAS TRANSPORT中的IE）； - 容器内封装一条 MANAGE UE POLICY COMMAND，其Payload即一条或多条URSP规则（编码见TS 24.526 clause 4）。

(3) MANAGE UE POLICY COMMAND - 内含URSP规则列表，每条规则按前述Precedence + TD + RSD三段编码； - UE解码后进行完整性校验与本地存储（替换同Precedence的旧规则）。

(4) MANAGE UE POLICY COMPLETE（上行确认） - UE通过 UPLINK NAS TRANSPORT（TS 24.501 clause 8.2.5）回送； - AMF经 Namf_Communication_N1MessageNotify 上报PCF，PCF据此确认URSP生效； - 若UE拒绝某条规则（如规则不合法），则回 MANAGE UE POLICY COMMAND COMPLETE 中携带拒绝指示，PCF需决策重传或修订。

3.4 设计意图：为什么用"AMF透传容器"而非PCF直连UE？

这一设计有三个考量：第一，安全隔离——UE Policy Container可被完整性保护/加密（NAS安全上下文），AMF无需感知内容即可保证传输安全；第二，接口解耦——PCF不需要维护与UE的直接NAS连接，复用现有N1通道；第三，统一承载——URSP、ANDSP、V2XP可共用同一个容器与同一条确认流程，减少信令开销。代价是排错时AMF日志看不到URSP具体内容，必须从PCF或UE侧抓取（见第五节）。

四、UE侧URSP匹配与PDU会话路由决策

URSP的"动作"完全在UE本地执行，这是它区别于AM Policy（AMF执行）、SM Policy（SMF执行）的根本特征。当UE上的应用产生上行流量时，操作系统向5GS协议栈提交流量及其属性（App Id / FQDN / IP 3-tuple等），UE按以下算法（TS 23.503 clause 6.6.2.3）匹配：

flowchart TD
    S["应用发起上行流量<br/>(携带App Id/FQDN/IP等属性)"] --> T["按Rule Precedence升序遍历URSP规则"]
    T --> M{"当前规则的TD是否命中?"}
    M -->|否| T
    M -->|是| R["按RSD Precedence升序遍历该规则RSD"]
    R --> E{"存在满足RSD_i组件的现存PDU会话?<br/>(SSC+S-NSSAI+DNN+接入类型一致)"}
    E -->|是| U1["复用该PDU会话承载流量"]
    E -->|否| F{"UE有能力/资源新建满足RSD_i的PDU会话?"}
    F -->|是| U2["发起新PDU会话建立<br/>(携带RSD_i的S-NSSAI/DNN)"]
    F -->|否| G{"RSD_i含NSNO指示?<br/>(非无缝非3GPP卸载)"}
    G -->|是| U3["旁路5GC,经WLAN直接卸载"]
    G -->|否| R
    U1 --> END["流量发送"]
    U2 --> END
    U3 --> END

4.1 三种典型路由结果

• 复用现存PDU会话：UE优先复用已存在且满足RSD组件（SSC模式、S-NSSAI、DNN、接入类型）的会话，避免重复建立；
• 新建PDU会话：若无匹配会话，UE以RSD_i中的S-NSSAI、DNN、PDU会话类型发起PDU Session Establishment（TS 23.502 clause 4.3.2.2），此时UE在请求里携带的S-NSSAI/DNN直接决定了流量进入哪个切片、锚定到哪个UPF；
• 非无缝非3GPP卸载（NSNO）：流量绕过5GC UPF，直接从WLAN出去，常用于本地家庭网络或省流量场景。

4.2 一个端到端实例

假设运营商为视频流媒体签约了eMBB切片、为低时延云游戏签约了URLLC切片，且为WLAN卸载签约了NSNO。下发到UE的URSP示例如下：

• 当用户打开视频App，命中规则10 → 优先尝试复用eMBB切片的internet会话；若该切片会话不存在则新建；若新建失败则按RSD-2走WLAN卸载；
• 当用户打开云游戏App，命中规则20 → 使用URLLC切片、DNN指向MEC本地的lcl-mec，由SMF选择边缘UPF锚点（与EASDF/DNAI机制联动），实现本地分流。

这就把"切片选择"与"MEC本地分流"在UE侧串联起来——URSP是终端侧的"流量总调度"。

五、实战：抓包识别与常见故障点

5.1 抓包识别URSP流程

在Wireshark/TShark中，URSP相关信令分布在N1 NAS与N15两个层面：

• N1侧：过滤 nas_5gs.msg.message_type == 110（DOWNLINK NAS TRANSPORT），展开 UE policy container IE，进一步可见 MANAGE UE POLICY COMMAND（TS 24.501 message type 0x71/0x72）及其中的URSP规则编码（TS 24.526）；
• N15侧：过滤 ngap 或 SBI n2 之外的服务调用 Npcf_UEPolicyControl，以及 Namf_Communication_N1N2MessageTransfer 中payloadType指示UE Policy的条目；
• TShark示例：tshark -r ue.pcap -Y "nas_5gs.msg.message_type==110 || nas_5gs.msg.message_type==111" 可分别抓取下行/上行NAS传输消息。

需要强调：AMF的N1信令抓包能看到容器外壳，但容器内的URSP规则明文需正确加载TS 24.526的解析器才能展开，这是很多新手"看到容器却看不到规则"的原因。

5.2 常见故障点与排错思路

URSP的核心设计意图是把网络切片与边缘路由的控制点从网络侧前移到终端侧，使运营商能在不改动任何业务服务器、不依赖应用配合的前提下，对每个App的流量做"切片+DNN+接入类型+卸载"的精细化引导。这对eMBB/URLLC/mMTC差异化承载、MEC本地分流、固移融合（FMC）都至关重要。

Rel-17引入了条件URSP（Conditional URSP）：RSD中新增 Time Window（仅在指定时段生效，如办公时段走企业切片、夜间走公众切片）与 Location Criteria（仅当UE处于特定TA/地理区域时生效，如进入园区才走专网切片）。这使URSP具备了时空维度，与NPN（非公共网络）、园区专网、MEC应用重定位场景高度契合。

Rel-18进一步围绕 多播广播（MBS）、无人驾驶与低能力RedCap终端 对URSP规则做适配，并强化了URSP与ATSSS多接入、与边缘计算DNAI发现的联动。Rel-19则持续增强条件URSP在卫星/非地面网络（NTN）与时间敏感通信（TSC）下的适用性。

与其他路径选择机制的对比

常见问题

Q1：URSP规则里的S-NSSAI与注册时Requested NSSAI/Allowed NSSAI是什么关系？ A：Requested/Allowed NSSAI由网络侧决定"UE能使用哪些切片"（TS 23.501 §5.15.5），是切片接入的准入控制；URSP里的S-NSSAI则是UE决定"哪个应用的流量走哪个切片"的本地策略。两者是"准入"与"选择"的关系——URSP中引用的S-NSSAI必须落在Allowed NSSAI范围内，否则UE无法为该流量建立PDU会话。

Q2：如果一个应用没有任何URSP规则命中怎么办？ A：UE会采用"URSP default behavior"——通常复用已有的默认PDU会话（一般是internet DNN的会话）或发起一次默认PDU会话建立，由运营商预配置的默认DNN/S-NSSAI兜底（TS 23.503 clause 6.6.2.3）。这也是为何未规划URSP时所有流量都挤到internet会话。

Q3：URSP下发为什么走NAS透传容器而不是直接SBI？ A：因为UE只有NAS一条与5GC的控制通道，没有直接的HTTP/SBI接口；且容器可复用NAS安全机制（加密+完整性保护）。AMF作为透明中继，既保证安全又实现接口解耦。

Q4：非无缝非3GPP卸载（NSNO）和N3IWF的非3GPP PDU会话有何区别？ A：NSNO是流量直接从WLAN旁路出网，不经过5GC UPF、不锚定5GS；而N3IWF建立的是一条"非3GPP接入PDU会话"，流量仍经5GC UPF，属"seamless"——可保持5GS会话连续性与计费。URSP的NSNO指示位决定了走哪一种。

Q5：条件URSP（时间窗/位置）在漫游场景下由H-PLMN还是V-PLMN提供？ A：URSP由UE归属地的H-PCF主导下发；在漫游下H-PCF与V-PCF协同，但URSP本质属于H-PLMN策略域，V-PCF主要影响AM Policy等本地接入策略。实际可用性还需结合漫游协议与终端支持情况。

参考来源

1. 3GPP TS 23.503 — Policy and Charging Control Framework, clause 6.6.2 URSP — URSP规则结构与匹配流程的权威定义
2. 3GPP TS 23.502 — Procedures for the 5G System, clause 4.2.2 / 4.2.4 — Registration与UE Configuration Update中的UE策略下发流程
3. 3GPP TS 24.501 — NAS Protocol, clause 7.6 / 8.2 / 8.3 — UE Policy Container与MANAGE UE POLICY消息定义
4. ShareTechnote — 5G Manage UE Policy — URSP规则下发与匹配的图示化解读
5. 3GPP — Access and Mobility & UE Policy Management in 5G — AM/UE Policy管理机制总览
6. GSMA NG.141 — Guidelines for URSP — 运营商URSP规则部署与终端一致性指导

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。