51学通信

深度解析TS 29.244：5.4 Policy and Charging Control (策略与计费控制) - Part 2 高级流量管控

27分钟阅读

深度解析TS 29.244：5.4 Policy and Charging Control (策略与计费控制) - Part 2 高级流量管控

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中，关于“5.4 Policy and Charging Control”后续核心章节（5.4.5至5.4.8），旨在为读者提供一个关于高级流量标记、监控、重定向与疏导机制的全景视图。

引言

在上一篇文章中，我们跟随5G用户小明的脚步，初步探索了策略与计费控制（PCC）架构下的四大核心基石：业务检测与绑定、门控、QoS控制以及规则优先级。这些机制共同构成了PCC策略在用户面（UPF）落地的基础框架，解决了“识别什么业务”、“让不让走”以及“以何种质量走”的核心问题。

然而，现代移动网络的精细化运营远不止于此。运营商不仅需要保障业务质量，还需要对流量进行更智能、更灵活的引导和处理，以支持增值业务、优化网络资源、并实现复杂的计费与策略联动。

本篇文章将继续深入TS 29.244规范的5.4章节，聚焦于更为高级的四大流量管控技术：下行流级别标记、用量监控、流量重定向和流量疏导。我们将继续通过小明的5G生活场景，揭示这些看似抽象的技术如何协同工作，为运营商的网络增值和用户的个性化体验提供强大的技术支撑。想象一下，当小明沉浸在运营商提供的专属视频服务中，或是不经意间触发了某个需要付费订阅的业务时，这些高级机制便在后台悄然启动，精准地引导着每一个数据包的走向。

1. 下行流级别标记以支持应用检测 (5.4.5 DL Flow Level Marking for Application Detection)

在复杂的网络架构中，不同的网络功能（NF）可能协同完成一项策略。例如，一个专门的设备负责深度包检测（DPI）识别应用，而另一个设备则根据识别结果执行QoS或计费策略。为了让这两个设备高效协同，“下行流级别标记”应运而生。它本质上是一种在网络内部“贴标签”的机制。

DL flow level marking is performed using DL DSCP marking. DL DSCP marking for application indication refers to the process in the TDF of marking detected downlink application traffic with a DSCP value received within an installed ADC rule matching this traffic.

规范开宗明义，指出下行流级别标记是通过下行DSCP（Differentiated Services Code Point，差分服务代码点）标记来实现的。在EPC架构中，这个角色通常由TDF（Traffic Detection Function，流量检测功能）扮演。当TDF-U（用户面）根据TDF-C（控制面）下发的ADC（Application Detection and Control，应用检测与控制）规则，识别出某个特定的下行应用流量时，它就会在这个应用的数据包的IP头部，打上一个特定的DSCP值。

这个DSCP值就像一个内部通行证，当数据包继续向下游传递时，其他网元（如PGW-U/PCEF）无需再次进行复杂的DPI，仅通过检查这个DSCP值就能快速识别出这是什么应用，并执行相应的策略。

1.1 PFCP如何实现下行流标记

TDF-C是通过PFCP协议，向TDF-U下达标记指令的。

DL DSCP marking for application indication is controlled by the TDF-C by associating a QER, including the ToS or Traffic Class within the DL Flow Level Marking IE, to the PDR matching the DL traffic to be marked.

具体来说，TDF-C会为需要标记的下行流量创建一个PDR，并为其关联一个QER。这个QER的特殊之处在于它包含了一个名为**DL Flow Level Marking（下行流级别标记）**的信息单元（IE）。该IE中会明确指定要打上的ToS（Type of Service）或Traffic Class值，其中就包含了DSCP值。TDF-U在处理匹配该PDR的数据包时，就会按照QER的指令，修改数据包IP头的DSCP字段。

1.2 场景代入：小明的专属视频服务体验

假设小明正在使用运营商推出的一款名为“沃派影视”的专属视频APP，该APP的流量可以享受特殊的网络优化。这个场景在网络中通常涉及TDF和PGW的联动。

  1. 应用识别与标记（在TDF-U）：

    • PCF通知TDF-C，需要对“沃派影视”的下行流量进行标记。
    • TDF-C通过N4接口（在EPC中是Sxc接口）向TDF-U下发一条PFCP Session Modification Request消息，其中包含：
      • 一条Create PDR，其PDI中包含识别“沃派影视”的应用ID。
      • 一条Create QER，其中包含DL Flow Level Marking IE，指定了一个特殊的DSCP值，例如“AF41”。
      • 将此QER与PDR关联。
    • 当“沃派影视”的下行视频包流经TDF-U并匹配该PDR时，TDF-U会将其IP头部的DSCP值修改为“AF41”。

  2. 基于标记执行策略（在PGW-U）：

    • TDF-U将打好标记的数据包发往PGW-U。
    • PCF早已通知PGW-C（SMF），对于DSCP值为“AF41”的流量，需要进行特殊的处理（例如，我们将在后续章节讲解的“流量疏导”）。
    • PGW-C向PGW-U下发另一条PDR，其PDI中的SDF Filter不再需要复杂的五元组或应用ID，而仅仅匹配DSCP=AF41。

Policy and charging control in the downlink direction by the PCEF for an application detected by the TDF is performed by the PGW-C configuring a PDR with a PDI containing an SDF Filter with the corresponding DSCP value.

这种方式极大地简化了PGW-U的配置，提升了处理效率，实现了网络功能间的解耦与高效协作。

值得注意的是，如果TDF-U和PGW-U之间存在GTP隧道，那么DSCP标记会被打在内层的IP头部。当TDF-C想要停止这一标记行为时，只需通过PFCP消息移除相关的QER或从QER中移除DL Flow Level Marking IE即可。

2. 用量监控 (5.4.6 Usage Monitoring)

用量监控是计费和策略实施的“眼睛”。网络需要精确地知道用户在不同业务上消耗了多少资源，才能执行如套餐限量、按需付费等策略。

Usage Monitoring Control refers to the process of monitoring the user plane traffic in the PGW-U, TDF-U or UPF for the accumulated usage of network resources per:

  • individual or group of service data flows;
  • individual or group of applications;
  • PDU session, possibly excluding an individual SDF or a group of service data flow(s) (for 5GC); …and/or more.

规范明确了用量监控可以在多个粒度上进行，小到一个特定的SDF（如某个视频流），大到整个PDU会话（用户的一次上网连接）。监控的资源可以是流量（volume）、时长（duration）或者事件（events）。

2.1 PFCP如何实现用量监控

用量监控的核心PFCP规则是URR（Usage Reporting Rule，用量上报规则）。

The CP function shall control the Usage Reporting in the UP function by:

  • creating the necessary PDR(s) to represent the service data flow, application or session;
  • creating a URR for each Monitoring key; and
  • associating the URR to … the PDR(s)…

这个过程可以分解为三步：

  1. 创建PDR：首先，CP功能（如SMF）需要创建PDR来识别需要监控的流量，这与我们在第一篇文章中讲到的业务检测完全相同。
  2. 创建URR：然后，CP功能为每一个“监控项”（在PCC架构中称为Monitoring key）创建一个URR。一个URR定义了要“测量什么”（如流量、时长）、“何时上报”（如达到1GB流量时、每隔1小时、或者检测到某个事件时）等一系列指令。
  3. 关联：最后，将创建好的URR与相应的PDR关联起来。一个URR可以关联多个PDR（例如，监控一组应用的总流量），一个PDR也可以关联多个URR（例如，同一个视频流量既要计入个人总流量，也要计入视频专属流量包）。

2.2 场景代入：小明的流量套餐监控

小明办理了一个月度套餐，包含50GB通用流量和20GB的“沃派影视”定向流量。运营商需要精确监控这两种流量的使用情况。

  1. 通用流量监控：

    • SMF为小明的PDU会话创建一个URR，我们称之为URR_Total。
    • URR_Total的测量方法是“流量（Volume）”，上报触发器是“达到阈值（Volume Threshold）”和“达到配额（Volume Quota）”。SMF会设置一个阈值（如49GB）和一个配额（50GB）。
    • SMF会将这个URR_Total关联到小明PDU会话中所有的PDR上，实现对所有流量的累加监控。

  2. 定向流量监控：

    • SMF为“沃派影视”业务创建一个URR，我们称之为URR_Video。
    • URR_Video同样设置了流量阈值（如19GB）和配额（20GB）。
    • SMF仅将URR_Video关联到那些用于识别“沃派影视”流量的PDR上。

当小明观看“沃派影视”时，流经UPF的数据包会同时匹配通用流量的PDR和定向流量的PDR，因此其流量会计入URR_Total和URR_Video两个桶里。当他浏览网页时，数据包只会计入URR_Total。当任一URR达到阈值时，UPF就会通过PFCP Session Report Request消息向SMF上报用量，触发后续的策略动作，如提醒用户或限速。

3. 流量重定向 (5.4.7 Traffic Redirection)

流量重定向是一种强大的控制手段，它能够将用户的上行流量强制导向一个不同于其原始请求的目的地。

Traffic Redirection refers to the process of redirecting uplink application traffic, in a PGW, TDF or UPF, towards a redirect destination, e.g. redirect some HTTP flows to a service provisioning page.

最常见的例子就是，当用户访问需要付费的内容时，网络将其浏览器请求重定向到一个订购页面。这个功能通常由PGW、TDF或5G的UPF来执行。UPF需要通过UP Function Features IE向CP功能报告自己是否支持该功能。

3.1 PFCP如何实现流量重定向

流量重定向的核心PFCP规则是FAR（Forwarding Action Rule，转发行为规则）。

To enforce the traffic redirection in the UP function, the CP function shall:

  • create the necessary PDR(s) to represent the traffic to be redirected …
  • create a FAR with … the Redirect Information IE … or … the Forwarding Policy IE …
  • associate the FAR to the above PDRs …

CP功能（SMF）控制UPF重定向流量的步骤如下：

  1. 创建PDR：识别需要被重定向的上行流量。
  2. 创建FAR：创建一个特殊的FAR，这个FAR不包含常规的转发信息，而是包含重定向指令。指令有两种形式：
    • CP功能提供重定向目标：FAR中包含Redirect Information IE，里面直接写明了重定向的目标地址（如URL）。这种方式最为灵活。
    • UPF预定义重定向目标：FAR中包含Forwarding Policy IE，里面是一个预定义策略的标识符。UPF根据这个标识符查找本地配置的重定向策略来执行。
  3. 关联：将这个特殊的FAR与PDR关联起来。

3.2 场景代入：小明访问付费体育频道

小明在使用“沃派影视”APP时，点击了“付费体育直播”频道。由于他尚未订购此服务，网络需要将他的访问请求重定向到订购页面。

  1. 策略决策：APP的上行请求到达UPF。PCF/SMF检测到这是一个访问未授权服务的请求。
  2. PFCP指令：SMF立即向UPF发送一条PFCP Session Modification Request消息，其中包含：
    • 一条Create PDR，用于精确匹配小明发往体育直播服务器的HTTP请求。
    • 一条Create FAR，这条FAR的内容非常关键：
      • Redirect Information IE被包含在内。
      • 其中的Redirection Address Type被设置为“URL”。
      • Redirect Server Address被设置为运营商的订购页面URL，例如http://subscribe.operator.com/sports。
      • 非常重要的一点是，Destination Interface被设置为“Access”。
  3. UPF执行：当小明的请求匹配PDR后，UPF并不会将请求发往“Core”网络侧，而是根据FAR的指令，模拟一个HTTP服务器，向“Access”侧（即小明手机）回送一个HTTP 302重定向响应，响应头中的Location字段就是订购页面的URL。
  4. 用户体验：小明的手机浏览器或APP收到HTTP 302响应后，自动跳转到运营商的订购页面，引导他完成付费。

对于非HTTP流量的重定向，Destination Interface则可能被设置为“Core”，意味着UPF会将数据包的目标IP地址直接修改为重定向服务器的地址，然后发往核心网侧。

4. 流量疏导 (5.4.8 Traffic Steering)

流量疏导与重定向相似，都是改变流量的路径，但其目的和应用场景有所不同。重定向通常是终止用户原始意图，引导至新目的地；而疏导则是在用户访问原始目的地的路径上，插入一些网络服务功能节点。

Traffic Steering refers to the process of applying a specific (S)Gi-LAN traffic steering policy in the PCEF or TDF (or TSSF), or a specific N6-LAN traffic steering policy in the UPF (PDU Session Anchor), for the purpose of steering the subscriber’s traffic to appropriate operator or 3rd party service functions (e.g. NAT, antimalware, parental control, DDoS protection) in the (S)Gi-LAN or N6-LAN…

这些服务功能通常部署在运营商的SGi-LAN/N6-LAN中，例如网络地址转换（NAT）、防病毒网关、家长控制系统、视频优化服务器等。这个过程也被称为“服务链（Service Function Chaining）”。UPF需要通过UP Function Features IE中的TRST标志位来声明其支持流量疏导功能。

4.1 PFCP如何实现流量疏导

流量疏导的实现同样依赖于FAR。

The CP function shall control Traffic Steering towards SGi-LAN, N6-LAN and/or N6 in the UP function by:

  • creating the necessary PDRs to represent the service data flows or applications to be steered;
  • creating a FAR with the Forwarding Policy IE … or creating a FAR with a Outer Header Creation …; and
  • associating the FAR to the above PDRs…

具体实现方式也有两种：

  1. 通过预定义策略：CP功能下发一个FAR，其中包含Forwarding Policy IE，该IE内含一个“流量疏导策略标识符”。UPF根据此标识符，查找本地配置的疏导策略（例如，需要经过哪些服务节点、如何进行封装等），并执行相应的包处理和路由动作。
  2. 通过显式路由信息：CP功能下发一个FAR，其中包含Outer Header Creation IE。这个IE指示UPF对原始数据包进行隧道封装（如GTP-U或IP-in-IP），并将封装后的包发往服务链的第一个服务节点。

4.2 场景代入：小明的视频被“智能优化”

我们回到小明观看“沃派影视”的场景。为了节省带宽并提升观看体验，运营商决定对该视频流量进行实时优化。

  1. 识别与疏导决策：PGW-U通过DSCP值“AF41”识别出这是“沃派影视”的下行流量（如5.4.5所述）。SMF/PGW-C的策略是需要将此流量疏导至位于N6-LAN的“视频优化引擎”。
  2. PFCP指令：PGW-C向PGW-U下发指令，更新匹配DSCP=“AF41”的DL PDR，为其关联一个新的FAR。该FAR中包含了Outer Header Creation IE，其内容指示UPF：
    • 创建一个新的IP头（或GTP-U头）。
    • 新头的目的IP地址设置为“视频优化引擎”的入口IP地址。
    • 将原始的视频数据包作为新封装包的载荷。
  3. UPF执行：PGW-U收到指令后，对所有匹配的视频包进行封装，并发往视频优化引擎。
  4. 服务链处理：视频优化引擎对视频流进行压缩和优化后，可能会将数据包再发回PGW-U。此时，PGW-U需要有另一条PDR来处理这些“二次加工”后的流量。

…the CP function can generate two pairs of PDRs and FARs, one is to instruct the UP function to detect the relevant … traffic and to steer the traffic to the N6-LAN; the other is to instruct the UP function to detect the same traffic sent back from the Service Chaining Functions and steer it to the Data Network or UE.

这条新的DL PDR的PDI源接口（Source Interface）会被设置为“SGi-LAN/N6-LAN”，以识别从服务功能节点返回的流量，其关联的FAR则会指示UPF将数据包解封装，并最终发往基站和小明手机。这就完成了一个完整的流量疏导与回注的闭环。

总结

在本篇文章中，我们继续通过小明的5G生活场景，深入探讨了策略与计费控制（PCC）中四种高级的流量管控机制：

  • 下行流级别标记 (5.4.5)：通过在QER中配置DL Flow Level Marking IE，使得TDF-U等上游节点能够为特定应用流量打上DSCP标记，简化下游节点（如PGW-U）的策略执行，实现网络功能间的协同与解耦。
  • 用量监控 (5.4.6)：通过创建URR并与PDR关联，网络可以对任意粒度（SDF、应用、会话级）的流量进行精确的用量统计，这是实现精细化计费和动态策略调整的基石。
  • 流量重定向 (5.4.7)：通过在FAR中配置Redirect Information IE或Forwarding Policy IE，UPF可以将用户的上行请求强制导向新的目的地，广泛应用于业务订购、门户网站引导等场景。
  • 流量疏导 (5.4.8)：同样通过在FAR中配置Forwarding Policy IE或Outer Header Creation IE，UPF可以将用户流量在送达最终目的地前，先经过一个或多个网络服务功能节点（服务链），以实现视频优化、安全过滤等增值服务。

这四种机制相互补充，共同构成了运营商进行网络增值、提升资源效率和创造丰富业务模式的强大工具箱。从简单的流量标记，到复杂的流量路径编排，PFCP协议通过PDR、QER、URR、FAR等规则的灵活组合，将PCC架构的“智慧”精确地转化为用户面数据流的“行动”。

FAQ

Q1：流量重定向（Traffic Redirection）和流量疏导（Traffic Steering）有什么核心区别？ A1：两者都改变了流量的原始路径，但目的和行为有本质区别。流量重定向的目的是替代用户的原始目标，通常将用户的请求导向一个全新的、最终的目的地，如业务订购页面，原始的请求流程在此中断。而流量疏导的目的是在去往原始目标的路径上插入一个或多个服务节点（服务链），流量经过这些节点处理后，通常还会继续前往其原始目的地。前者是“改道”，后者是“途经”。

Q2：在EPC架构中，下行流级别标记（DL Flow Level Marking）通常涉及哪两个网络功能，它们是如何通过PFCP协同工作的？ A2：通常涉及TDF（流量检测功能）和PCEF（策略与计费执行功能，位于PGW中）。协同流程如下：1）TDF-C通过PFCP指令（带DL Flow Level Marking IE的QER）让TDF-U识别特定应用并为之下行流量打上DSCP标记。2）PGW-C再通过PFCP指令（带匹配DSCP的SDF Filter的PDR）让PGW-U（PCEF）基于这个DSCP标记执行后续策略（如计费、QoS或流量疏导），从而避免了在PGW-U重复进行昂贵的DPI。

Q3：什么是“监控密钥（Monitoring Key）”，它在用量监控中是如何通过PFCP实现的？ A3：“监控密钥（Monitoring Key）”是PCC架构中的一个逻辑概念，代表一个独立的监控任务或计费单元，例如“视频业务总用量”或“社交应用用量”。在PFCP层面，它通过一个**URR（用量上报规则）**来实现。CP功能会为每一个Monitoring Key创建一个URR，定义其测量方法和上报触发器，然后将这个URR关联到所有与该监控任务相关的PDR上，从而实现对特定流量集合的用量监控。

Q4：在对HTTP流量进行重定向时，为什么FAR中的Destination Interface通常要设置为“Access”？ A4：因为HTTP重定向是通过向客户端（UE）发送一个HTTP状态码为302的响应来实现的，该响应头中包含了新的URL。为了能够向UE发送这个HTTP响应，UPF必须将这个响应包发往“Access”侧（即UE和基站所在的方向）。如果Destination Interface设置为“Core”，数据包将被发往核心网深处，无法到达UE，也就无法触发浏览器或APP的跳转行为。

Q5：CP功能指示UPF执行流量疏导时，使用FAR中的Forwarding Policy IE和Outer Header Creation IE这两种方式有什么不同？ A5：这两种方式代表了不同的配置抽象层次。使用Forwarding Policy IE是一种高层抽象方式，CP功能只需告诉UPF要执行哪个“预定义”的疏导策略（通过标识符），具体的疏导路径、封装方式等细节都已在UPF本地配置好，CP功能无需关心。而使用Outer Header Creation IE是一种底层显式方式，CP功能直接告诉UPF如何对数据包进行隧道封装，以及封装后的下一个确切的目的IP地址（即服务链的第一跳），控制更为直接和灵活。

关系图谱