# 5G N4会话建立：SMF到UPF规则注入全链路信令拆解 ## 一、背景与问题定义 5G核心网控制面与用户面分离（CUPS）架构中，**SMF（Session Management Function）**与**UPF（User Plane Function）**之间通过**N4接口**交换PFCP（Packet Forwarding Control Protocol）信令。N4会话建立（PFCP Session Establishment）是PDU会话建立过程中最关键的"规则注入"环节——SMF将包检测规则（PDR）、转发动作规则（FAR）、QoS执行规则（QER）、使用量上报规则（URR）打包注入UPF，从而让UPF获得"识别、分类、转发、限速、计费"的完整数据面能力。 **核心问题**：SMF如何在一个PFCP Session Establishment Request消息中，将多套规则以正确的关联关系注入UPF？UPF又如何分配F-TEID并返回隧道信息？本文基于**3GPP TS 29.244 V19.1.0**（Release 19）和**TS 23.502 V19.2.0 Section 4.3.2.2.1**，逐IE拆解这一过程。 --- ## 二、N4会话建立在整个PDU会话流程中的位置 N4会话建立嵌套在UE触发的PDU Session Establishment流程中，位于SMF完成UPF选择之后、SMF向AMF返回N2 SM信息之前。其上下文关系如下： ```mermaid sequenceDiagram participant UE participant RAN as (R)AN participant AMF participant SMF participant UPF as UPF(PSA) participant PCF participant UDM UE->>AMF: NAS PDU Session Establishment Request Note right of AMF: DNN, S-NSSAI, PDU Session Type AMF->>SMF: Namf_Communication_N1N2MessageTransfer
(forward NAS) SMF->>UDM: Nudm_SDM_Get (SM数据) UDM-->>SMF: Subscription Data SMF->>PCF: Npcf_SMPolicyControl_Create PCF-->>SMF: PCC Rules (QoS, Charging) rect rgb(255,240,220) Note over SMF,UPF: ★ N4会话建立（本文聚焦） ★ SMF->>UPF: PFCP Session Establishment Request
(PDR + FAR + QER + URR) UPF-->>SMF: PFCP Session Establishment Response
(F-TEID, Cause) end SMF-->>AMF: N1N2MessageTransfer Response
(N2 SM Info + N1 SM Container) AMF->>RAN: N2 PDU Session Resource Setup Request RAN->>UE: RRC Reconfiguration (DRB建立) RAN-->>AMF: N2 PDU Session Resource Setup Response AMF->>SMF: Nsmf_PDUSession_UpdateSMContext SMF->>UPF: N4 Session Modification (AN Tunnel Info) Note over SMF,UPF: 数据面通路打通 ``` --- ## 三、N4会话建立请求消息深度解析 ### 3.1 消息整体结构 根据**TS 29.244 Section 7.5.2**，PFCP Session Establishment Request消息由以下顶层IE组成： | IE名称 | 类型值 | 是否必选 | 说明 | |--------|--------|---------|------| | Node ID | 60 | 必选 | SMF的节点标识（IP或FQDN） | | F-SEID | 57 | 必选 | SMF侧的PFCP会话端点标识 | | Create PDR | 1 | 必选（可多个） | 创建包检测规则 | | Create FAR | 3 | 必选（可多个） | 创建转发动作规则 | | Create QER | 5 | 条件必选 | 创建QoS执行规则 | | Create URR | 7 | 条件必选 | 创建使用量上报规则 | | Create BAR | 9 | 可选 | 创建缓存动作规则 | | Create Traffic Endpoint | 127 | 可选 | 流量端点信息（Rel-16+） | | PDN Type | 13 | 可选 | IPv4/IPv6/IPv4v6/Ethernet | | User Plane Inactivity Timer | 114 | 可选 | 用户面不活动超时 | ### 3.2 规则关联拓扑 关键设计原则：**PDR是规则的入口，通过ID引用关联到FAR、QER、URR**。UPF收到数据包后，先按PDR的Precedence值从小到大匹配，命中后执行关联的FAR/QER/URR。 ```mermaid graph TB subgraph "PFCP Session Establishment Request" subgraph "PDR #1 (UL)" p1[PDR ID = 1] p1_prec[Precedence = 100] p1_pdi[PDI: Source=ACCESS
F-TEID=SMF分配
SDF Filter] p1 -->|关联| far1[FAR ID = 1
FORWARD→CORE] p1 -->|关联| qer1[QER ID = 1
QFI=9, Gate=OPEN
MBR UL/DL] end subgraph "PDR #2 (DL)" p2[PDR ID = 2] p2_prec[Precedence = 100] p2_pdi[PDI: Source=CORE
UE IP Addr
SDF Filter] p2 -->|关联| far2[FAR ID = 2
FORWARD→ACCESS] p2 -->|关联| qer1 end subgraph "PDR #3 (DL Default)" p3[PDR ID = 3] p3_prec[Precedence = 255] p3_pdi[PDI: Source=CORE
UE IP Addr] p3 -->|关联| far2 end end ``` ### 3.3 Create PDR核心IE详解 PDR（Packet Detection Rule）是整个规则注入体系的**入口点**。TS 29.244 Section 7.5.2.2定义了其结构： **PDI（Packet Detection Information）**是PDR的核心，决定了UPF如何识别一个数据包： | PDI子IE | 说明 | UL PDR取值 | DL PDR取值 | |----------|------|-----------|-----------| | Source Interface | 包来源方向 | ACCESS（来自AN） | CORE（来自DN） | | F-TEID | GTP-U隧道端标识 | SMF分配TEID，UPF填充IP | UPF分配（Response返回） | | UE IP Address | 用户IP | 可选（F-TEID已足够） | 必选（DN侧无隧道） | | SDF Filter | 业务流过滤器 | 如 `permit out ip from to 80` | 对应下行方向 | | Application ID | 应用识别 | 可选 | 可选（代替SDF Filter） | **Precedence**（优先级）：数值越小优先级越高。当多个PDR匹配同一数据包时，选择Precedence最小的。典型取值： | Precedence范围 | 用途 | 设计意图 | |---------------|------|---------| | 1-32 | 运营商专有业务 | 最高优先保障 | | 33-64 | IMS语音/VoNR | 语音业务优先 | | 65-128 | 普通签约业务 | SDF Filter匹配 | | 129-254 | Default Bearer | 兜底匹配 | | 255 | Lowest Default | 完全兜底 | **Outer Header Removal**：UL PDR通常设置值为`0`（移除GTP-U/UDP/IP外层头），DL PDR通常不设置（需要保留或添加GTP-U封装）。 ### 3.4 Create FAR核心IE详解 FAR决定了匹配到PDR的数据包应该执行什么动作： | FAR子IE | 取值 | 说明 | |---------|------|------| | Apply Action | FORWARD/DROP/BUFFER/NOTIFY/DUPLICATE | 最核心的4bit标志位 | | Destination Interface | ACCESS / CORE / SGi-LAN / CP-function | FORWARD时的目标方向 | | Network Instance | DNN字符串 | 路由到特定DN实例 | | F-TEID | UPF分配或SMF指定 | GTP-U封装用的隧道端 | | Outer Header Creation | GTP-U/UDP/IPv4等 | 封装外层头 | **典型配置模式**： - **UL FAR**：Apply Action=FORWARD, Destination Interface=CORE → 上行数据发往DN - **DL FAR**：Apply Action=FORWARD, Destination Interface=ACCESS, Outer Header Creation=GTP-U → 下行数据封装GTP-U发往AN - **DL Default FAR（无SDF匹配时）**：与DL FAR相同，但没有QoS保障 ### 3.5 Create QER核心IE详解 QER（QoS Enforcement Rule）是5G QoS Flow到UPF执行面的映射桥梁： | QER子IE | 说明 | 典型取值 | |---------|------|---------| | QER ID | 唯一标识 | 1 | | Gate Status | OPEN/CLOSED | OPEN（放行） | | Maximum Bit Rate (UL) | 上行最大速率 | 来自PCF授权的MBR | | Maximum Bit Rate (DL) | 下行最大速率 | 来自PCF授权的MBR | | Guaranteed Bit Rate (UL) | 上行保障速率 | 仅GBR QoS Flow | | Guaranteed Bit Rate (DL) | 下行保障速率 | 仅GBR QoS Flow | | QoS Flow Identifier (QFI) | 5QI到QoS Flow的映射 | 如QFI=9(non-GBR), QFI=1(GBR) | | Packet Rate (UL/DL) | 包速率限制 | Rel-17+用于URLLC | | DL Buffering Duration | 下行缓存时长 | 可选 | --- ## 四、F-TEID分配博弈：SMF预分配 vs UPF分配 N4会话建立中有一个重要的设计选择：**F-TEID由谁分配？**这直接影响信令交互次数和时延。 ### 4.1 两种分配模式对比 ```text sequenceDiagram participant SMF participant UPF rect rgb(220,240,255) Note over SMF,UPF: 模式一：SMF预分配（CH=0） SMF->>UPF: PFCP Session Est. Request
PDR包含完整F-TEID(IP+TEID) UPF-->>SMF: PFCP Session Est. Response
无需返回F-TEID Note right of SMF: 优点：Response更轻
缺点：SMF需知道UPF IP end rect rgb(255,240,220) Note over SMF,UPF: 模式二：UPF分配（CH=1） SMF->>UPF: PFCP Session Est. Request
PDR中F-TEID仅设CH=1 UPF-->>SMF: PFCP Session Est. Response
返回UPF分配的F-TEID Note right of SMF: 优点：SMF无需知道UPF IP
缺点：需等Response end end ``` ### 4.2 CH（Choose）标志位详解 F-TEID IE中有一个关键bit：**CH（Choose）**= 1时，表示请求UPF自行分配F-TEID。 | 场景 | CH值 | 谁分配 | 为什么 | |------|------|-------|--------| | UL PDR, SMF预知UPF地址 | 0 | SMF | SMF已知UPF的N3地址 | | DL PDR, UPF需要暴露N3地址 | 1 | UPF | UPF知道自己的N3接口地址 | | UL PDR, SMF不知道UPF地址 | 1 | UPF | UPF动态分配 | | I-UPF（中间UPF） | 1 | UPF | 中间UPF自行决定 | **设计意图**：5G UPF可以有多组IP地址（N3/N9侧、N6侧），SMF不一定知道UPF会使用哪个接口的IP，因此让UPF自己分配更灵活。在**SSC Mode 2/3**的UPF重选场景中，新UPF的地址未知，CH=1是必须的。 --- ## 五、N4会话建立响应消息解析 ### 5.1 Response核心IE UPF在成功处理PFCP Session Establishment Request后，返回Response消息（TS 29.244 Section 7.5.2.2）： | IE名称 | 说明 | 关键场景 | |--------|------|---------| | Cause | 成功/失败原因 | Success / RequestRejected | | F-SEID | UPF侧会话端点 | UPF标识此会话 | | Created PDR | PDR创建结果 | 包含UPF分配的F-TEID | | Cause（per PDR） | 每条PDR的创建结果 | 粒度更细的失败诊断 | | Usage Report | 可选，即时使用量 | URR触发 | | F-TEID（in Created PDR） | UPF分配的隧道端 | DL PDR的N3 F-TEID | ### 5.2 响应时序与后续动作 ```mermaid stateDiagram-v2 [*] --> SMF_ConstructRules: SMF收到PCF PCC Rules SMF_ConstructRules --> Send_PFCP_Est_Req: 构造PDR/FAR/QER/URR Send_PFCP_Est_Req --> Wait_Response: 等待UPF响应 Wait_Response --> Success: Cause=Success Wait_Response --> Failure: Cause=RequestRejected Wait_Response --> PartialSuccess: 部分PDR失败 Success --> Check_FTEID: 提取UPF分配的F-TEID Check_FTEID --> Build_N2SM: 构造N2 SM Information Build_N2SM --> Send_N1N2_ToAMF: 发给AMF Failure --> Select_NewUPF: 重选UPF Select_NewUPF --> Send_PFCP_Est_Req PartialSuccess --> EvaluateFailure: 评估失败PDR EvaluateFailure --> Success: 核心PDR成功→继续 EvaluateFailure --> Failure: 核心PDR失败→重选 ``` --- ## 六、多QoS Flow场景下的规则注入策略 ### 6.1 一个PDU会话多个QoS Flow 5G允许一个PDU会话内建立多个QoS Flow，每个Flow有不同的5QI。N4会话建立时，SMF需要为每个QoS Flow创建独立的PDR+QER组合。 **典型配置**（VoNR场景：1个Default + 1个IMS Signaling + 1个Voice）： | PDR ID | 方向 | Precedence | SDF Filter | 关联QER(QFI) | 关联FAR | |--------|------|-----------|------------|-------------|---------| | 1 | UL | 50 | SIP信令(5060/5061) | QER1(QFI=5) | FAR1→CORE | | 2 | DL | 50 | SIP信令(5060/5061) | QER1(QFI=5) | FAR2→ACCESS | | 3 | UL | 30 | RTP语音(media) | QER2(QFI=1,GBR) | FAR1→CORE | | 4 | DL | 30 | RTP语音(media) | QER2(QFI=1,GBR) | FAR2→ACCESS | | 5 | UL | 255 | 无（匹配所有） | QER3(QFI=9) | FAR1→CORE | | 6 | DL | 255 | 无（匹配所有） | QER3(QFI=9) | FAR2→ACCESS | **关键设计**： - 语音RTP包Precedence=30，优先于SIP信令Precedence=50和Default的255 - QER2包含GBR保障参数，确保语音速率 - Default PDR作为兜底，QFI=9（non-GBR），Precedence=255 ### 6.2 Rule之间引用关系验证 SMF在构造PFCP Session Establishment Request时，必须确保引用完整性： ```mermaid graph TD subgraph "规则引用校验" PDR1_UL["PDR#1(UL)
SIP→QFI5"] -->|"FAR ID"| FAR_UL["FAR#1
FWD→CORE"] PDR1_UL -->|"QER ID"| QER1["QER#1
QFI=5,MBR"] PDR1_UL -->|"URR ID"| URR1["URR#1
Volume Threshold"] PDR2_DL["PDR#2(DL)
SIP→QFI5"] -->|"FAR ID"| FAR_DL["FAR#2
FWD→ACCESS"] PDR2_DL -->|"QER ID"| QER1 PDR3_UL["PDR#3(UL)
RTP→QFI1"] -->|"FAR ID"| FAR_UL PDR3_UL -->|"QER ID"| QER2["QER#2
QFI=1,GBR"] PDR4_DL["PDR#4(DL)
RTP→QFI1"] -->|"FAR ID"| FAR_DL PDR4_DL -->|"QER ID"| QER2 PDR5_UL["PDR#5(UL)
Default→QFI9"] -->|"FAR ID"| FAR_UL PDR5_UL -->|"QER ID"| QER3["QER#3
QFI=9"] PDR6_DL["PDR#6(DL)
Default→QFI9"] -->|"FAR ID"| FAR_DL PDR6_DL -->|"QER ID"| QER3 end style PDR3_UL fill:#ff9999 style PDR4_DL fill:#ff9999 style PDR1_UL fill:#99ccff style PDR2_DL fill:#99ccff style PDR5_UL fill:#cccccc style PDR6_DL fill:#cccccc ``` --- ## 七、与4G EPS CUPS的对比 | 维度 | 5G N4 (TS 29.244) | 4G CUPS Sx (TS 29.244 R14) | |------|-------------------|--------------------------| | 协议名 | PFCP | PFCP（同一协议，但功能差异） | | 核心规则集 | PDR/FAR/QER/URR/BAR/MAR | 相同（但字段差异） | | QoS映射 | QFI（QoS Flow Identifier） | EPS Bearer ID / TFT | | 隧道封装 | GTP-U on N3/N9 | GTP-U on S1-U/S5/S8 | | SDF Filter | 支持Ethernet PDU类型 | 仅IP类型 | | F-TEID CH模式 | 支持（CH=1） | 支持 | | UL CL/BP支持 | 原生支持（Rel-15+） | 不支持 | | 时间敏感网络 | 支持（Rel-16+，QER增加Packet Rate） | 不支持 | | 多路由 | FAR支持Duplicate + MAR | FAR仅Forward/Drop | | Release | Rel-15~Rel-19持续增强 | Rel-14~Rel-15 | **核心差异解读**：5G N4最大的增强在于**QER引入QFI**取代了EPS的Bearer级别QoS，以及**FAR的Duplicate能力**支持了URLLC冗余传输场景（TS 23.501 Section 5.33.2.1）。 --- ## 八、抓包识别与故障排查 ### 8.1 Wireshark抓包过滤 ```bash # 过滤PFCP Session Establishment Request pfcp.message_type_value == 50 # 过滤PFCP Session Establishment Response pfcp.message_type_value == 51 # 过滤特定SEID的会话 pfcp.seid == 0x1234567890abcdef # 过滤Create PDR中的F-TEID pfcp.f_teid # 过滤特定QFI pfcp.qfi == 9 ``` ### 8.2 常见故障点与排错 | 故障现象 | 可能原因 | 排错方法 | |---------|---------|---------| | Cause=RequestRejected | UPF资源不足（会话数/流表满） | 检查UPF会话容量和流表使用率 | | UPF不返回F-TEID | CH=1但UPF不支持自分配 | 检查UPF能力集（PFCP Association Setup中UPF返回的Feature） | | 数据面不通 | FAR中Destination Interface配置错误 | 抓包确认UL→CORE, DL→ACCESS方向 | | QoS不生效 | QER Gate Status=CLOSED | 检查PCF授权结果，Gate应为OPEN | | 包匹配不到PDR | Precedence设置冲突 | 检查PDR优先级顺序和SDF Filter语法 | | UPF丢弃默认包 | 无Default PDR（Precedence=255） | 确认至少有一条兜底PDR | | N4 Session Est超时 | UPF PFCP端口不可达 | `ping` UPF PFCP端口（通常DSCP=48） | ## 九、N4会话修改与建立的协同博弈 N4会话建立并非一次性完成所有规则注入。实际部署中，**Session Establishment + Session Modification**的配合才是完整的数据面通路打通过程： 1. **Session Establishment**（本文主题）：注入UL/DL PDR+FAR+QER，建立PSA UPF上的规则上下文 2. **Session Modification #1**：SMF收到AN Tunnel Info后，修改DL FAR，填入(R)AN的N3 F-TEID 3. **Session Modification #2**（可选）：QoS Flow建立/修改时，增删PDR/QER 4. **Session Modification #3**（可选）：UL CL/BP插入时，增加中间UPF的规则 这种"**先建后改**"的设计，是因为SMF在N4 Session Establishment阶段还不知道(R)AN的隧道信息（要等N2交互后才知道），所以DL FAR的目标隧道地址在第一次Modification时才填充。 --- ## 十、Release 18/19增强特性 TS 29.244在Rel-18和Rel-19中引入了多项N4增强： | 特性 | Release | 增强内容 | |------|---------|---------| | Ethernet PDU会话增强 | Rel-18 | 支持Ethernet类型的SDF Filter和MAC地址匹配 | | 时间敏感通信（TSC） | Rel-18 | QER增加Port Management Information Container | | ATPP（Anti-Spoofing） | Rel-18 | PDR增加Source MAC Address验证 | | 网络切片增强 | Rel-18 | 支持S-NSSAI关联到Network Instance | | Red Cap UE优化 | Rel-18 | PDR匹配简化 | | 多路径传输 | Rel-19 | FAR支持多路径转发（MAR规则增强） | | AI/ML流量识别 | Rel-19 | PDI增加ML-based Application Detection | --- ## 常见问题 **Q1: N4 Session Establishment中UL和DL方向是否必须各创建至少一个PDR？** A: 是的。根据TS 29.244，一个N4会话必须包含至少一个UL方向（Source Interface=ACCESS）和一个DL方向（Source Interface=CORE）的PDR，以确保双向数据通路。但在某些特殊场景（如仅下行推送），可能只创建DL PDR。 **Q2: SDF Filter和Application ID在PDR中可以同时使用吗？** A: 不建议。TS 29.244规定PDI中的SDF Filter和Application ID是互斥的检测条件。如果同时存在，UPF的行为取决于实现。SDF Filter基于五元组精确匹配，Application ID基于DPI/深度包检测，适用于无法用五元组定义的应用流量。 **Q3: UPF返回Cause=RequestRejected时，SMF应该如何处理？** A: TS 23.502 Section 4.3.2.2.1规定SMF应：①记录日志并上报网管；②如果有备选UPF（同S-NSSAI/DNN），触发UPF重选并重新发起N4 Session Establishment；③如果没有备选UPF，向UE返回PDU Session Establishment Reject（Cause=27 "Missing or unknown DNN"或Cause=67 "Insufficient resources"）。 **Q4: 多个QER引用同一个QFI时，UPF如何处理速率限制？** A: UPF在执行QoS速率限制时，会按照**Session-AMBR**（会话级聚合最大速率）和**Flow-GBR/MBR**（流级速率）两级执行。同一QFI的多个PDR引用的QER中的MBR应该一致（由SMF确保），UPF在实现上通常会对同一QFI的PDR共享速率计数器。 **Q5: N4会话建立和PFCP Association Setup是什么关系？** A: PFCP Association Setup是**节点级**的握手（TS 29.244 Section 7.4.1），在N4会话建立之前完成。Association建立SMF与UPF之间的控制面连接，交换能力集（UPF Features、SMF Features）。N4 Session Establishment是**会话级**操作，在Association之上创建具体的PDU会话规则。一个Association可以承载多个N4 Session。 --- ## 参考来源 1. [3GPP TS 29.244 V19.1.0](https://www.3gpp.org/DynaReport/29244.htm) — Section 7.5.2 (PFCP Session Establishment), Section 7.5.2.2 (Create PDR/FAR/QER/URR IE定义) 2. [3GPP TS 23.502 V19.2.0](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.3.2.2.1 (UE-requested PDU Session Establishment) 3. [PFCP Session Lifecycle in free5GC](https://free5gc.org/blog/20260204/20260204/) — free5GC开源实现中的PFCP会话生命周期详解 4. [N4 Handler and Rule Application — DeepWiki/open5gs](https://deepwiki.com/open5gs/open5gs/5.2.2-n4-handler-and-rule-application) — open5gs开源UPF中N4规则处理机制 5. [Cisco UCC 5G UPF N4 Procedures Guide](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/upf/2025-04/config-admin/ucc-5g-upf-config-and-admin-guide-2025-04/m_upf-n4-sm-node-level-and-reporting-procedures.html) — Cisco UPF产品N4会话管理实践 --- > 本文由「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 等场景全覆盖。