做5G核心网的人心里都清楚网络功能再怎么云化、服务化信令面花样再多用户真正感知到的永远是业务通不通、时延低不低、速率够不够——这一切最终都落在数据面的那一连串转发动线上。5G核心网里的 Packet Forwarding Model数据包转发模型就是定义这条动线怎么走、怎么判、怎么转、怎么断的行为契约。UPF 里的包检测规则、转发动作规则、QoS 执行规则全部都是这个模型的具体落地。搞懂它比背一堆接口名管用得多。1. 转发模型在 5G 核心网中的位置不止是“查表转发”很多刚接触核心网的朋友会对“模型”这个词感到抽象觉得网络设备不就是查路由表转发吗用得着专门立一个模型这个想法在 4G 时代勉强说得过去到了 5G Core数据面已经不再是简单的“进隧道、出隧道”而是多接入、多切片、多接入边缘计算场景下的一等公民。UPF 作为唯一的数据面网元要同时处理 PDU Session 的锚点、QoS 流的映射、RAN 与 DN 之间的桥接还要支持 ULCL、BPBranching Point、本地分流这些复杂拓扑。1.1 数据包转发模型到底是什么在 3GPP TS 23.501 的语境里数据包转发模型描述的是一个 PDU Session 在核心网数据面上从 UE 侧到 DN 侧或从 DN 侧到 UE 侧中间经历的转发行为。它把传统的“一维路由表”拆成了几个执行阶段先对进入 UPF 的报文做检测和分类识别出它属于哪个 PDU Session、哪条 QoS Flow再根据分类结果决定执行什么转发动作是封装成 GTP-U 发给 RAN还是剥掉隧道头发给 DN或者拷贝一份给本地分流节点最后还要叠加计费、QoS 速率控制、包缓冲、丢包等执行动作。也就是说转发模型不是一张静态路由表而是一套“匹配 动作 执行参数”的流水线。这样的设计在 4G 时代没有完全展开因为那时 SGW/PGW 的数据面行为相对固定基本上就是 TEID 进来、TEID 出去。5G 里引入了服务化架构UPF 可以按需部署在边缘、汇聚机房、核心机房转发拓扑越来越灵活必须要有一个统一的模型来容纳这些变化。1.2 N3、N6、N9 与转发模型的对应关系看转发模型之前先把三个关键接口在脑子里装好N3UPF 与 RAN 之间的接口承载 GTP-U 隧道N6UPF 与外部数据网络DN之间的接口通常是普通 IP 转发N9两个 UPF 之间的接口典型场景是 I-UPF中间 UPF与 PSA UPFPDU Session Anchor UPF之间的转发以及 ULCL 与 PSA 之间的转发。这三个接口正好对应了转发模型的“两边”。N6 进、N3 出就是下行N3 进、N9 出或者 N3 进、N6 出就是上行和中间转发。模型里每一项规则最终都要落到这些接口上的具体报文操作上。比如说一个下行视频报文从 CDN 到达 PSA UPF 的 N6 口模型要先通过 PDR 匹配它的目的 IP、PDU Session 信息再通过 FAR 决定“封装 GTP-U、打上 QoS Flow Identifier从 N3 发给基站”这一整套动作本质上就是数据包转发模型在做的事。1.3 给“模型”一个更直观的类比如果一定要用生活化类比来理解可以把它看成快递分拣中心的分拣规则。包裹IP 包进来后先看运单上的地址属于哪个分区PDR 匹配然后决定送到哪个货台、用哪辆运输车FAR 指定出口同时还要记录包裹重量算运费URR 计费并且保证某一类包裹不超过每天的配送配额QER QoS 控制。核心网里的转发模型本质上就是这套分拣规则的形式化定义。2. 模型核心构件拆解PDR、FAR、URR、QER 是怎样协同工作的真正在 UPF 上落地时转发模型主要由几类规则组成。记住一句话PDR 管“认”FAR 管“干”URR 管“记”QER 管“限”。四者通过规则 ID 相互引用形成一个完整的数据面调度闭环。2.1 PDR包检测规则先回答“这个包是谁的”Packet Detection RulePDR是模型的第一步。PDR 里包含 Packet Detection InformationPDI也就是一组匹配字段源/目的 IP、端口、PDU Session 标识、QFI、网络实例、应用标识等。每个 PDP 上下文里会有多条 PDR每条 PDR 又关联着一个指向 FAR 的 ID以及可能指向 URR 和 QER 的引用 ID。实际做配置的人会关心一个问题PDR 要不要把五元组写满我的经验是能写多精确就写多精确但别为了精确牺牲灵活性。UPF 侧收到报文后是按优先级逐条匹配 PDR 的一旦命中就不再往下走。同一份业务如果既有 IPv4 流量又有 IPv6 流量很多初配现场就漏了一条结果 IPv6 流量直接走默认 PDR 甚至被丢弃业务监控里就看见“IPv4 正常IPv6 打不开”。配置时建议明确标注 PDR 的 precedence 属性把精确匹配规则的优先级调高兜底规则优先级放低这样后续插新规则时不容易互相覆盖。2.2 FAR转发动作规则决定“接下来做什么”Forwarding Action RuleFAR描述匹配后的具体行为。动作通常有几种DROP丢弃报文一般用于拦截非法流量FORWARD正常转发需要指定目的接口、GTP-U 封装的 TEID、QFI 等内容BUFFER缓存报文用于终端的 idle 态数据到达时先缓存再触发寻呼NOTIFY通知 CP 侧触发某些流程DUPL复制报文用于流量镜像、合规审计、抓包分析。我一直觉得 FAR 里最容易忽略的是 Buffer缓存动作的时长配置。终端从空闲态恢复到连接态需要时间如果缓冲区配置过小或者 Buffer 超时时间跟 CP 侧寻呼定时器不匹配就会出现“用户明明收到了寻呼、也发起了 Service Request但数据包已经被 UPF 丢了”的情况。表现为短视频首帧卡顿、微信消息延迟到达。这种问题跑到无线那边查永远是正常的启动点几乎都在 UPF 数据面转发模型上。2.3 URR 与 QER计费和 QoS 不再是附属品Usage Reporting RuleURR负责计费数据采集与用量上报比如流量统计、时长统计、上下行字节数、事件触发上报阈值等。5G 时代计费粒度可以精确到 QoS Flow 级别一套 URR 可以关联多个 PDR保证同一个用户的不同业务流量分开统计。QoS Enforcement RuleQER则负责速率限制与 QoS 标识控制包括 QFI、Gate Status门控开关、最大上行/下行速率、保证速率等。这里要注意 QER 带给转发模型的一个关键语义QoS 执行是在 UPF 数据转发路径上实时作用的不是靠后续旁路统计去“补刀”。也就是说超过配额的包在 UPF 这里就会被标记或丢弃避免拥塞传递到 RAN 空口。这个设计让 5G 核心网的 QoS 控制比 4G 更接近“端到端”而不是“逐段碰运气”。2.4 PFCP 消息中规则表的建立顺序如果是在 N4 接口上用 PFCPPacket Forwarding Control Protocol3GPP TS 29.244建 PDU Session规则下发是有逻辑顺序的。CP 侧先建立 PFCP Association然后发送 PFCP Session Establishment Request。在一条建立请求里通常会携带一个或多个 PDR并由 PDR 的far_id、urr_id、qer_id分别引用相应的 FAR、URR、QER。排障时如果看到“PDR 建立成功但业务不通”多半是引用关系断裂FAR 没建、或者 FAR 的目的接口参数没配比如下行方向的 FAR 里没填 Outer Header Creation 参数导致 UPF 不知道要封 GTP-U 头又或者 PDR 的 PDI 和实际承载不匹配报文始终命不中。这种问题在信令侧看 CP 状态是“PDU Session 已建立”但 UPF 数据面一个包都转不出去特别容易被误判为传输链路故障。3. 模型落到报文GTP-U 封装、QoS Flow 与 TEID 的映射细节没有 packet 层面的理解转发模型永远只是纸面的框框。这里我会沿着上下行两个方向把模型的行为“翻译”成真实报文操作。3.1 下行方向从 N6 到 N3假设 UE 发起一个视频请求CDN 的回包达到 UPF 的 N6 口。UPF 首先识别这是一个下行报文根据目的 IP、目的端口等信息匹配到对应 PDU Session 的下行 PDR命中后该 PDR 引用 FARFAR 的Apply Action是 FORWARD同时指定Outer Header Creation创建一个 GTP-U 头里面填充 RAN 侧的 TEID、PDU Session Type 以及 QoS Flow Identifier报文从 N3 口发给 RANRAN 再根据 QFI 映射到对应的 DRBData Radio Bearer如果该 QoS Flow 关联了 QER则转发前还需要做速率整形超出配置的 GBR/MBR 时丢弃或降级。这个过程中转发模型其实承担了三层映射IP 流 → QoS Flow → GTP-U TEID → DRB。UPF 是中间最关键的翻译器它把核心网侧的隧道标识与 RAN 侧的无线承载最终打通。很多人只盯着 GTP-U 头里的 TEID忽略了 QFI 的作用。实际看抓包里业务卡顿或者 QoS 策略不生效时要重点核对下行 GTP-U 头中的 QFI 是不是与切片/Slice 的优先级一致。QFI 只有 6 bit取值范围 0~63配置错一个值QoS 调度就全错位了。3.2 上行方向从 N3 到 N6上行方向UE 发出的数据包先到 RAN由 RAN 打成 GTP-U 隧道包发给 UPF此时 GTP-U 头里的 TEID 是 UPF 侧分配的 N3 TEID。UPF 剥掉 GTP-U 头后拿到内部 IP 报文再做一次 PDR 匹配。匹配成功后FAR 指令Apply Action设置为 FORWARD同时Outer Header Removal负责去掉 GTP-U 头然后报文从 N6 口送到 DN。上行方向最容易踩坑的地方是“GTP-U 头的拆除和重建时机”。如果 UPF 把上行报文送到本地 DN 前没有正确处理外层头抓包看到的就是隧道头和内层 IP 串在一起要么 N6 侧路由器不认识、要么端口对端进程收到垃圾报文。常见原因不是 UPF 转发逻辑坏了而是 FAR 里的 Outer Header Removal 参数与对端建立的 GTP-U 隧道参数不匹配。隧道参数这种东西排查时就要把 PFCP 建会话时的 IE 和实际转发报文逐字节对不要想当然认为“接口通了就不会错”。3.3 中间 UPF 与 N9多一跳不意味着多一套模型在漫游或者边缘组网里数据面可能不止一个 UPF。比如 UE 通过 I-UPF 连接 PSA UPFN3 到 I-UPFI-UPF 和 PSA UPF 之间走 N9。这时转发模型依然是同一套规则只是 FAR 的出口从 N3 变为 N9外层头对端从 RAN 变为另一个 UPF。N9 口的 GTP-U 同样需要 TEID 和 QFI而 QoS 控制可以由多个 UPF 分担比如 I-UPF 做数据缓存或本地转发PSA UPF 做全局锚点。这里有一个实际会遇到的性能问题多 UPF 串联时N9 隧道很容易成为吞吐瓶颈。我在调优时见过物理链路 10G业务流量只跑 4G 就丢包、但 CPU 占有率很低的情况。原因往往是这类多 UPF 场景中UPF 之间的转发没有打开 GTP-U 报文快速路径或者报文经过太多软转层。要解决问题得看报文是否走了硬件加速表、N9 口的负载均衡 hash 是否导致某个 CPU 核过热。转发模型本身没问题可执行引擎不给力照样卡死业务。4. 数据包转发模型真正跑起来性能调优与故障排查转发模型的内容说起来简单但要在一张现网里稳定跑到线速需要处理很多“模型之外”的约束。4.1 哈希匹配与 PDR 条目顺序的隐性成本每条进入 UPF 的报文都需要查找 PDR。PDR 数量几十上百条时顺序遍历是扛不住高速转发的所以 UPF 实现里通常会为 PDR 建哈希索引。哈希的 key 可能是 TEID、QFI、IP 五元组或者多种组合。如果设计不合理例如多条 PDR 的匹配字段重叠度高哈希碰撞会把查表退化成一个慢路径转发延迟直接翻几倍。这也是为什么我给新人的第一个建议是不要把 PDR 写成“全模糊”匹配。五元组里的前缀长度、端口范围、网络实例尽量精确PDR 优先级的分层要清晰。这样不仅符合模型语义更重要的是能让 UPF 的查表引擎把大部分流量迅速定位到少数几个热条目上。4.2 抓包定位转发问题的三条有效路径现网排障时抓包是优先级最高的动作。在 UPF 上抓包目光不要只盯在一个口上。常用思路是 N3 口和 N6 口同时抓然后做对比下行看 N6 口进包、N3 口是否同名出包、GTP-U 头里的 TEID 是否与 PFCP 建立时下发的 TEID 一致、QFI 是否一致上行看 N3 口进包、N6 口出包、GTP-U 头是否正确拆除如果中间还有 N9就要形成 N3-N9-N6 三张抓包的时间序列对应同一组 GTP-U 报文找出丢包发生在哪一跳。一个容易忽略的点是 GTP-U 报文的 Sequence Number。很多转发路径故障跟报文重排序有关特别是多链路聚合或 ECMP 场景。同一个 QoS Flow 的报文被分流到两条物理链路上时如果链路时延不同就可能乱序到达 RANTCP 层将呈现重传率高、吞吐低的现象。数据包转发模型在规则层面没有“乱序”这个概念所以排查时必须在执行层面关注链路哈希、负载均衡策略。我自己处理过的一个案例是基站侧持续上报丢包率 2%无线指标全好最后发现是 N3 接口 ECMP 哈希的 key 没有包含 TEID导致同一个 GTP-U 隧道被拆到了两条物理链路上乱序引起 RLC 重传。核心网转发模型照顾不到这个层面但优化哈希 key 却能救回很大一部分性能。4.3 常见故障从规则层面到隧道层面现象可疑点排查方向下行不通上行通PDR 匹配不到下行包或 FAR 缺 Outer Header Creation核对目的 IP 归属、PFCP 建会话的 PDR/FAR 参数上行不通下行通N3 TEID 不匹配或 FAR 的 Outer Header Removal 错误与 RAN 核对 TEID对比抓包业务通但无计费URR 与 PDR 的引用关系没建全看 PFCP 的 URR 引用 ID突发流量丢包QER 速率门限过低、缓存动作冲突调整 QoS 参数确认 Gate Status用户空闲后消息丢失FAR 的 BUFFER 时长不足或缓冲触发条件不满足优化寻呼缓存时长协同 CP 侧寻呼定时器这类问题有个共同特征信令面全绿谁也想不到是转发模型某个参数埋了雷。所以每次我调 UPF一定会把 PFCP 会话里的 PDR/FAR/URR/QER 以表格形式导出来跟实际流量做交叉比对。不做这件事就谈不上排障。5. 转发模型在新场景里的扩展ULCL、MEC 与 5G LAN理解了模型原语后再看新的数据面场景会发现它们无非是模型的排列组合。5.1 ULCL一次 PDR 命中复制两个动作上行分类器Uplink Classifier是边缘计算最常见的功能。它让 UPF 在 N9 段上把一部分上行流量“截流”到本地 MEC 服务器另一部分继续走原 PSA UPF 转发到远端 DN。这个功能在转发模型里的本质是在 UPF 上配置一条优先级更高的 PDR匹配 MEC 服务的目标 IP 段FAR 指向本地 N6 接口同时仍保留一条默认 PDRFAR 指向 N9 PSA UPF。当业务 IP 落在边缘服务网段时UPF 执行本地出口动作当 IP 落在公网时走原有出口。同一个报文流两条规则两次匹配这就是 ULCL 的模型形态。实操上ULCL 配完后本地访问通、公网不通反过来公网通、本地不通的情况我都遇到过。绝大多数原因是两条 PDR 的匹配条件存在交叠结果边缘流量被默认规则先命中了。解决方式就是精确设置 PDR 的 precedence边缘网段的 PDR 优先级数值更小优先级更高默认 PDR 兜底。这是转发模型语义上的一个经典考点。5.2 5G LAN模型多了二层语义5G LAN 让 5G 网络支持终端之间的二层互通。转发模型的支持方式是在 PDR 的 PDI 中增加以太网报文头相关字段FAR 中则增加对应的二层转发动作。UPF 内部可能需要维护一张 MAC 地址表把目的 MAC 映射到对应 UE 的 PDU Session 或 N6 端口。这个场景对传统做 IP 转发的人冲击不小因为查表维度变了。以前五元组现在变成了 Ethernet Source/Destination Address、Ethertype、甚至 VLAN ID。我在实验室里搭 5G LAN 时还发现配置里要明确区分“转发到远端 UE”和“转发到本地服务”两条路径否则 ARP 请求会被 UPF 当作普通 IP 包丢掉二层互通直接失败。本质上转发模型的多层语义是开放的只是很多人第一次接触时下意识只按 IP 思维配置忽略了 Ethertype 的匹配项。5.3 数据面模型对 MEC 和边缘调度的启发MEC 场景下的流量调度本质上也在吃转发模型的“规则红利”。比如检测到某个应用的流量后FAR 可以做报文复制送一份到探针或者 AI 分析平台业务本身不受影响。或者根据 PDR 里的时间维度、网络实例维度做条件分流让某个 IDC 的测试流量和正式生产流量在同一个 UPF 上互不干扰。转发模型被定义得这么细给运维带来的最大好处是“可以用配置解决以前要改代码的问题”。以前要做一个流量镜像要在设备上改端口镜像策略现在在 PFCP 会话里加一条带 DUPL 动作的 FAR就能精准复制某个 QoS Flow 的报文。对现网运维来说这种可编程性远比“提高转发速度”更让人踏实。6. 个人观点怎么学转发模型才能真的用得上总有人问我要不要先把 3GPP 规范整个啃下来。我的看法是别硬啃规范是工具书不是小说。学 Packet Forwarding Model 最有效的方式是“反向学”先在实验室搭一套最小版 5G Core有 AMF、SMF、UPF 那种把一个终端附着上去开一个 PDU Session然后去看 SMF 在 N4 接口上下发了哪些 PDR、哪些 FAR。拿真实配置去对照规范里的字段你会发现规范里那些拗口的 IE 突然就活了。有条件的话再抓一把 N3 和 N6 的报文把某个具体视频流的上下行报文编号一步步对上模型里的步骤。只要完整走过一次“PDU Session 建立 → 视频下载 → 抓包对比 → 修改 PDR → 重新验证”的循环你以后看任何 5G 数据面问题都会有底气。最后分享一个排障习惯配置完 UPF 后别急着点“保存”先在内存态把当前会话的规则清单导出确认 PDR/FAR 引用完整再让业务测试流量过一遍看计数器是否增长。数据包转发模型出问题时往往不是某个单点配置写错了而是规则之间的优先级和引用关系形成了死锁。带着“模型是整体”的视角去查比在接口参数里钻牛角尖高效得多。
5G核心网数据包转发模型详解：从PDR到GTP-U的UPF实战指南
做5G核心网的人心里都清楚网络功能再怎么云化、服务化信令面花样再多用户真正感知到的永远是业务通不通、时延低不低、速率够不够——这一切最终都落在数据面的那一连串转发动线上。5G核心网里的 Packet Forwarding Model数据包转发模型就是定义这条动线怎么走、怎么判、怎么转、怎么断的行为契约。UPF 里的包检测规则、转发动作规则、QoS 执行规则全部都是这个模型的具体落地。搞懂它比背一堆接口名管用得多。1. 转发模型在 5G 核心网中的位置不止是“查表转发”很多刚接触核心网的朋友会对“模型”这个词感到抽象觉得网络设备不就是查路由表转发吗用得着专门立一个模型这个想法在 4G 时代勉强说得过去到了 5G Core数据面已经不再是简单的“进隧道、出隧道”而是多接入、多切片、多接入边缘计算场景下的一等公民。UPF 作为唯一的数据面网元要同时处理 PDU Session 的锚点、QoS 流的映射、RAN 与 DN 之间的桥接还要支持 ULCL、BPBranching Point、本地分流这些复杂拓扑。1.1 数据包转发模型到底是什么在 3GPP TS 23.501 的语境里数据包转发模型描述的是一个 PDU Session 在核心网数据面上从 UE 侧到 DN 侧或从 DN 侧到 UE 侧中间经历的转发行为。它把传统的“一维路由表”拆成了几个执行阶段先对进入 UPF 的报文做检测和分类识别出它属于哪个 PDU Session、哪条 QoS Flow再根据分类结果决定执行什么转发动作是封装成 GTP-U 发给 RAN还是剥掉隧道头发给 DN或者拷贝一份给本地分流节点最后还要叠加计费、QoS 速率控制、包缓冲、丢包等执行动作。也就是说转发模型不是一张静态路由表而是一套“匹配 动作 执行参数”的流水线。这样的设计在 4G 时代没有完全展开因为那时 SGW/PGW 的数据面行为相对固定基本上就是 TEID 进来、TEID 出去。5G 里引入了服务化架构UPF 可以按需部署在边缘、汇聚机房、核心机房转发拓扑越来越灵活必须要有一个统一的模型来容纳这些变化。1.2 N3、N6、N9 与转发模型的对应关系看转发模型之前先把三个关键接口在脑子里装好N3UPF 与 RAN 之间的接口承载 GTP-U 隧道N6UPF 与外部数据网络DN之间的接口通常是普通 IP 转发N9两个 UPF 之间的接口典型场景是 I-UPF中间 UPF与 PSA UPFPDU Session Anchor UPF之间的转发以及 ULCL 与 PSA 之间的转发。这三个接口正好对应了转发模型的“两边”。N6 进、N3 出就是下行N3 进、N9 出或者 N3 进、N6 出就是上行和中间转发。模型里每一项规则最终都要落到这些接口上的具体报文操作上。比如说一个下行视频报文从 CDN 到达 PSA UPF 的 N6 口模型要先通过 PDR 匹配它的目的 IP、PDU Session 信息再通过 FAR 决定“封装 GTP-U、打上 QoS Flow Identifier从 N3 发给基站”这一整套动作本质上就是数据包转发模型在做的事。1.3 给“模型”一个更直观的类比如果一定要用生活化类比来理解可以把它看成快递分拣中心的分拣规则。包裹IP 包进来后先看运单上的地址属于哪个分区PDR 匹配然后决定送到哪个货台、用哪辆运输车FAR 指定出口同时还要记录包裹重量算运费URR 计费并且保证某一类包裹不超过每天的配送配额QER QoS 控制。核心网里的转发模型本质上就是这套分拣规则的形式化定义。2. 模型核心构件拆解PDR、FAR、URR、QER 是怎样协同工作的真正在 UPF 上落地时转发模型主要由几类规则组成。记住一句话PDR 管“认”FAR 管“干”URR 管“记”QER 管“限”。四者通过规则 ID 相互引用形成一个完整的数据面调度闭环。2.1 PDR包检测规则先回答“这个包是谁的”Packet Detection RulePDR是模型的第一步。PDR 里包含 Packet Detection InformationPDI也就是一组匹配字段源/目的 IP、端口、PDU Session 标识、QFI、网络实例、应用标识等。每个 PDP 上下文里会有多条 PDR每条 PDR 又关联着一个指向 FAR 的 ID以及可能指向 URR 和 QER 的引用 ID。实际做配置的人会关心一个问题PDR 要不要把五元组写满我的经验是能写多精确就写多精确但别为了精确牺牲灵活性。UPF 侧收到报文后是按优先级逐条匹配 PDR 的一旦命中就不再往下走。同一份业务如果既有 IPv4 流量又有 IPv6 流量很多初配现场就漏了一条结果 IPv6 流量直接走默认 PDR 甚至被丢弃业务监控里就看见“IPv4 正常IPv6 打不开”。配置时建议明确标注 PDR 的 precedence 属性把精确匹配规则的优先级调高兜底规则优先级放低这样后续插新规则时不容易互相覆盖。2.2 FAR转发动作规则决定“接下来做什么”Forwarding Action RuleFAR描述匹配后的具体行为。动作通常有几种DROP丢弃报文一般用于拦截非法流量FORWARD正常转发需要指定目的接口、GTP-U 封装的 TEID、QFI 等内容BUFFER缓存报文用于终端的 idle 态数据到达时先缓存再触发寻呼NOTIFY通知 CP 侧触发某些流程DUPL复制报文用于流量镜像、合规审计、抓包分析。我一直觉得 FAR 里最容易忽略的是 Buffer缓存动作的时长配置。终端从空闲态恢复到连接态需要时间如果缓冲区配置过小或者 Buffer 超时时间跟 CP 侧寻呼定时器不匹配就会出现“用户明明收到了寻呼、也发起了 Service Request但数据包已经被 UPF 丢了”的情况。表现为短视频首帧卡顿、微信消息延迟到达。这种问题跑到无线那边查永远是正常的启动点几乎都在 UPF 数据面转发模型上。2.3 URR 与 QER计费和 QoS 不再是附属品Usage Reporting RuleURR负责计费数据采集与用量上报比如流量统计、时长统计、上下行字节数、事件触发上报阈值等。5G 时代计费粒度可以精确到 QoS Flow 级别一套 URR 可以关联多个 PDR保证同一个用户的不同业务流量分开统计。QoS Enforcement RuleQER则负责速率限制与 QoS 标识控制包括 QFI、Gate Status门控开关、最大上行/下行速率、保证速率等。这里要注意 QER 带给转发模型的一个关键语义QoS 执行是在 UPF 数据转发路径上实时作用的不是靠后续旁路统计去“补刀”。也就是说超过配额的包在 UPF 这里就会被标记或丢弃避免拥塞传递到 RAN 空口。这个设计让 5G 核心网的 QoS 控制比 4G 更接近“端到端”而不是“逐段碰运气”。2.4 PFCP 消息中规则表的建立顺序如果是在 N4 接口上用 PFCPPacket Forwarding Control Protocol3GPP TS 29.244建 PDU Session规则下发是有逻辑顺序的。CP 侧先建立 PFCP Association然后发送 PFCP Session Establishment Request。在一条建立请求里通常会携带一个或多个 PDR并由 PDR 的far_id、urr_id、qer_id分别引用相应的 FAR、URR、QER。排障时如果看到“PDR 建立成功但业务不通”多半是引用关系断裂FAR 没建、或者 FAR 的目的接口参数没配比如下行方向的 FAR 里没填 Outer Header Creation 参数导致 UPF 不知道要封 GTP-U 头又或者 PDR 的 PDI 和实际承载不匹配报文始终命不中。这种问题在信令侧看 CP 状态是“PDU Session 已建立”但 UPF 数据面一个包都转不出去特别容易被误判为传输链路故障。3. 模型落到报文GTP-U 封装、QoS Flow 与 TEID 的映射细节没有 packet 层面的理解转发模型永远只是纸面的框框。这里我会沿着上下行两个方向把模型的行为“翻译”成真实报文操作。3.1 下行方向从 N6 到 N3假设 UE 发起一个视频请求CDN 的回包达到 UPF 的 N6 口。UPF 首先识别这是一个下行报文根据目的 IP、目的端口等信息匹配到对应 PDU Session 的下行 PDR命中后该 PDR 引用 FARFAR 的Apply Action是 FORWARD同时指定Outer Header Creation创建一个 GTP-U 头里面填充 RAN 侧的 TEID、PDU Session Type 以及 QoS Flow Identifier报文从 N3 口发给 RANRAN 再根据 QFI 映射到对应的 DRBData Radio Bearer如果该 QoS Flow 关联了 QER则转发前还需要做速率整形超出配置的 GBR/MBR 时丢弃或降级。这个过程中转发模型其实承担了三层映射IP 流 → QoS Flow → GTP-U TEID → DRB。UPF 是中间最关键的翻译器它把核心网侧的隧道标识与 RAN 侧的无线承载最终打通。很多人只盯着 GTP-U 头里的 TEID忽略了 QFI 的作用。实际看抓包里业务卡顿或者 QoS 策略不生效时要重点核对下行 GTP-U 头中的 QFI 是不是与切片/Slice 的优先级一致。QFI 只有 6 bit取值范围 0~63配置错一个值QoS 调度就全错位了。3.2 上行方向从 N3 到 N6上行方向UE 发出的数据包先到 RAN由 RAN 打成 GTP-U 隧道包发给 UPF此时 GTP-U 头里的 TEID 是 UPF 侧分配的 N3 TEID。UPF 剥掉 GTP-U 头后拿到内部 IP 报文再做一次 PDR 匹配。匹配成功后FAR 指令Apply Action设置为 FORWARD同时Outer Header Removal负责去掉 GTP-U 头然后报文从 N6 口送到 DN。上行方向最容易踩坑的地方是“GTP-U 头的拆除和重建时机”。如果 UPF 把上行报文送到本地 DN 前没有正确处理外层头抓包看到的就是隧道头和内层 IP 串在一起要么 N6 侧路由器不认识、要么端口对端进程收到垃圾报文。常见原因不是 UPF 转发逻辑坏了而是 FAR 里的 Outer Header Removal 参数与对端建立的 GTP-U 隧道参数不匹配。隧道参数这种东西排查时就要把 PFCP 建会话时的 IE 和实际转发报文逐字节对不要想当然认为“接口通了就不会错”。3.3 中间 UPF 与 N9多一跳不意味着多一套模型在漫游或者边缘组网里数据面可能不止一个 UPF。比如 UE 通过 I-UPF 连接 PSA UPFN3 到 I-UPFI-UPF 和 PSA UPF 之间走 N9。这时转发模型依然是同一套规则只是 FAR 的出口从 N3 变为 N9外层头对端从 RAN 变为另一个 UPF。N9 口的 GTP-U 同样需要 TEID 和 QFI而 QoS 控制可以由多个 UPF 分担比如 I-UPF 做数据缓存或本地转发PSA UPF 做全局锚点。这里有一个实际会遇到的性能问题多 UPF 串联时N9 隧道很容易成为吞吐瓶颈。我在调优时见过物理链路 10G业务流量只跑 4G 就丢包、但 CPU 占有率很低的情况。原因往往是这类多 UPF 场景中UPF 之间的转发没有打开 GTP-U 报文快速路径或者报文经过太多软转层。要解决问题得看报文是否走了硬件加速表、N9 口的负载均衡 hash 是否导致某个 CPU 核过热。转发模型本身没问题可执行引擎不给力照样卡死业务。4. 数据包转发模型真正跑起来性能调优与故障排查转发模型的内容说起来简单但要在一张现网里稳定跑到线速需要处理很多“模型之外”的约束。4.1 哈希匹配与 PDR 条目顺序的隐性成本每条进入 UPF 的报文都需要查找 PDR。PDR 数量几十上百条时顺序遍历是扛不住高速转发的所以 UPF 实现里通常会为 PDR 建哈希索引。哈希的 key 可能是 TEID、QFI、IP 五元组或者多种组合。如果设计不合理例如多条 PDR 的匹配字段重叠度高哈希碰撞会把查表退化成一个慢路径转发延迟直接翻几倍。这也是为什么我给新人的第一个建议是不要把 PDR 写成“全模糊”匹配。五元组里的前缀长度、端口范围、网络实例尽量精确PDR 优先级的分层要清晰。这样不仅符合模型语义更重要的是能让 UPF 的查表引擎把大部分流量迅速定位到少数几个热条目上。4.2 抓包定位转发问题的三条有效路径现网排障时抓包是优先级最高的动作。在 UPF 上抓包目光不要只盯在一个口上。常用思路是 N3 口和 N6 口同时抓然后做对比下行看 N6 口进包、N3 口是否同名出包、GTP-U 头里的 TEID 是否与 PFCP 建立时下发的 TEID 一致、QFI 是否一致上行看 N3 口进包、N6 口出包、GTP-U 头是否正确拆除如果中间还有 N9就要形成 N3-N9-N6 三张抓包的时间序列对应同一组 GTP-U 报文找出丢包发生在哪一跳。一个容易忽略的点是 GTP-U 报文的 Sequence Number。很多转发路径故障跟报文重排序有关特别是多链路聚合或 ECMP 场景。同一个 QoS Flow 的报文被分流到两条物理链路上时如果链路时延不同就可能乱序到达 RANTCP 层将呈现重传率高、吞吐低的现象。数据包转发模型在规则层面没有“乱序”这个概念所以排查时必须在执行层面关注链路哈希、负载均衡策略。我自己处理过的一个案例是基站侧持续上报丢包率 2%无线指标全好最后发现是 N3 接口 ECMP 哈希的 key 没有包含 TEID导致同一个 GTP-U 隧道被拆到了两条物理链路上乱序引起 RLC 重传。核心网转发模型照顾不到这个层面但优化哈希 key 却能救回很大一部分性能。4.3 常见故障从规则层面到隧道层面现象可疑点排查方向下行不通上行通PDR 匹配不到下行包或 FAR 缺 Outer Header Creation核对目的 IP 归属、PFCP 建会话的 PDR/FAR 参数上行不通下行通N3 TEID 不匹配或 FAR 的 Outer Header Removal 错误与 RAN 核对 TEID对比抓包业务通但无计费URR 与 PDR 的引用关系没建全看 PFCP 的 URR 引用 ID突发流量丢包QER 速率门限过低、缓存动作冲突调整 QoS 参数确认 Gate Status用户空闲后消息丢失FAR 的 BUFFER 时长不足或缓冲触发条件不满足优化寻呼缓存时长协同 CP 侧寻呼定时器这类问题有个共同特征信令面全绿谁也想不到是转发模型某个参数埋了雷。所以每次我调 UPF一定会把 PFCP 会话里的 PDR/FAR/URR/QER 以表格形式导出来跟实际流量做交叉比对。不做这件事就谈不上排障。5. 转发模型在新场景里的扩展ULCL、MEC 与 5G LAN理解了模型原语后再看新的数据面场景会发现它们无非是模型的排列组合。5.1 ULCL一次 PDR 命中复制两个动作上行分类器Uplink Classifier是边缘计算最常见的功能。它让 UPF 在 N9 段上把一部分上行流量“截流”到本地 MEC 服务器另一部分继续走原 PSA UPF 转发到远端 DN。这个功能在转发模型里的本质是在 UPF 上配置一条优先级更高的 PDR匹配 MEC 服务的目标 IP 段FAR 指向本地 N6 接口同时仍保留一条默认 PDRFAR 指向 N9 PSA UPF。当业务 IP 落在边缘服务网段时UPF 执行本地出口动作当 IP 落在公网时走原有出口。同一个报文流两条规则两次匹配这就是 ULCL 的模型形态。实操上ULCL 配完后本地访问通、公网不通反过来公网通、本地不通的情况我都遇到过。绝大多数原因是两条 PDR 的匹配条件存在交叠结果边缘流量被默认规则先命中了。解决方式就是精确设置 PDR 的 precedence边缘网段的 PDR 优先级数值更小优先级更高默认 PDR 兜底。这是转发模型语义上的一个经典考点。5.2 5G LAN模型多了二层语义5G LAN 让 5G 网络支持终端之间的二层互通。转发模型的支持方式是在 PDR 的 PDI 中增加以太网报文头相关字段FAR 中则增加对应的二层转发动作。UPF 内部可能需要维护一张 MAC 地址表把目的 MAC 映射到对应 UE 的 PDU Session 或 N6 端口。这个场景对传统做 IP 转发的人冲击不小因为查表维度变了。以前五元组现在变成了 Ethernet Source/Destination Address、Ethertype、甚至 VLAN ID。我在实验室里搭 5G LAN 时还发现配置里要明确区分“转发到远端 UE”和“转发到本地服务”两条路径否则 ARP 请求会被 UPF 当作普通 IP 包丢掉二层互通直接失败。本质上转发模型的多层语义是开放的只是很多人第一次接触时下意识只按 IP 思维配置忽略了 Ethertype 的匹配项。5.3 数据面模型对 MEC 和边缘调度的启发MEC 场景下的流量调度本质上也在吃转发模型的“规则红利”。比如检测到某个应用的流量后FAR 可以做报文复制送一份到探针或者 AI 分析平台业务本身不受影响。或者根据 PDR 里的时间维度、网络实例维度做条件分流让某个 IDC 的测试流量和正式生产流量在同一个 UPF 上互不干扰。转发模型被定义得这么细给运维带来的最大好处是“可以用配置解决以前要改代码的问题”。以前要做一个流量镜像要在设备上改端口镜像策略现在在 PFCP 会话里加一条带 DUPL 动作的 FAR就能精准复制某个 QoS Flow 的报文。对现网运维来说这种可编程性远比“提高转发速度”更让人踏实。6. 个人观点怎么学转发模型才能真的用得上总有人问我要不要先把 3GPP 规范整个啃下来。我的看法是别硬啃规范是工具书不是小说。学 Packet Forwarding Model 最有效的方式是“反向学”先在实验室搭一套最小版 5G Core有 AMF、SMF、UPF 那种把一个终端附着上去开一个 PDU Session然后去看 SMF 在 N4 接口上下发了哪些 PDR、哪些 FAR。拿真实配置去对照规范里的字段你会发现规范里那些拗口的 IE 突然就活了。有条件的话再抓一把 N3 和 N6 的报文把某个具体视频流的上下行报文编号一步步对上模型里的步骤。只要完整走过一次“PDU Session 建立 → 视频下载 → 抓包对比 → 修改 PDR → 重新验证”的循环你以后看任何 5G 数据面问题都会有底气。最后分享一个排障习惯配置完 UPF 后别急着点“保存”先在内存态把当前会话的规则清单导出确认 PDR/FAR 引用完整再让业务测试流量过一遍看计数器是否增长。数据包转发模型出问题时往往不是某个单点配置写错了而是规则之间的优先级和引用关系形成了死锁。带着“模型是整体”的视角去查比在接口参数里钻牛角尖高效得多。
