深度解析TS 29.244:5.4 Policy and Charging Control (策略与计费控制) - Part 1 核心机制

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中,关于“5.4 Policy and Charging Control”的核心章节,旨在为读者提供一个策略与计费控制核心机制的全景视图。

引言

欢迎来到5G核心网控制面与用户面接口协议TS 29.244的深度解析系列。在现代移动通信网络中,如何对海量的数据流进行精细化管理、保障用户体验并实现商业价值,是运营商网络运营的核心。这一切的背后,都离不开一个强大而灵活的大脑——策略与计费控制(Policy and Charging Control, PCC)架构。

本系列文章将聚焦于控制面功能(CP function, 如SMF)与用户面功能(UP function, 如UPF)之间的N4接口,深入剖析PFCP协议如何承载PCC的指令,将策略的“意图”转化为用户面数据流的“行动”。

在本篇文章中,我们将从第5.4章“策略与计费控制”入手,重点解读其最基础、最核心的四大机制:业务检测与绑定、门控、QoS控制。为了让抽象的技术概念变得生动具体,我们将跟随一位名叫“小明”的5G用户,通过他在一天中的上网体验,来串联和解析这些技术细节。想象一下,小明早晨醒来,拿起他的5G手机,准备开始一天的数字生活。从他打开第一个APP开始,PCC就已经悄然介入,为他的每一次网络交互保驾护航。

1. 策略与计费控制(PCC)概述 (5.4.1 General)

在深入具体的技术细节之前,规范首先对本章的范围做出了纲领性的说明。

This clause describe how Policy and Charging Control requirements are supported over the Sxa, Sxb, Sxc and N4 reference points.

这段简短的文字点明了本章的核心任务:阐述策略与计费控制(PCC)的需求是如何在Sxa、Sxb、Sxc(EPC架构中CU分离的接口)以及我们重点关注的N4接口(5GC架构中SMF与UPF之间的接口)上实现的。

可以这样理解,PCC架构本身(由PCF、SMF等网元组成)负责制定“规则”,比如“对于观看高清视频的用户,要保证20Mbps的下行速率”或者“对于未付费的游戏玩家,禁止其访问高速游戏服务器”。而TS 29.244定义的PFCP协议,则是将这些“规则”从大脑(SMF)传递给四肢(UPF)的神经信号。UPF接收到这些指令后,忠实地对流经它的每一个数据包进行检查和处理,从而实现策略的落地。

场景代入:小明的“智能网络管家”

对于小明来说,PCC就像一个为他贴身服务的“智能网络管家”。这个管家看不到摸不着,但时刻在后台工作。当小明打开手机时,这个管家就已经准备就绪,随时根据小明将要使用的业务,为他调配最合适的网络资源,并确保他的使用行为符合套餐规定。我们接下来要探讨的所有机制,都是这位“管家”指挥UPF执行具体任务的方式。

2. 业务检测与承载/QoS流绑定 (5.4.2 Service Detection and Bearer/QoS Flow Binding)

“智能管家”要做的第一件事,就是识别出小明到底在用什么业务。是看视频、听音乐,还是在进行视频通话?这个过程就是“业务检测”。检测出来之后,就需要把这个业务“绑定”到合适的网络通道上,以提供差异化的服务质量。这个通道,在EPC中称为“承载(Bearer)”,在5GC中则称为“QoS流(QoS Flow)”。

2.1 业务检测与绑定的基本概念

规范首先对业务检测和绑定给出了定义。

Service detection refers to the process that identifies the packets belonging to a service data flow or application. For 5GC, QoS flow binding is the procedure that associates service data flow(s) to a QoS flow deemed to transport the service data flow. UL QoS flow binding verification refers to the process of discarding uplink packets due to no matching QoS flow for the uplink direction.

简单来说,业务数据流(Service Data Flow, SDF) 是具有相同特征的一组IP流,例如来自同一个视频服务器、发往小明手机特定端口的所有数据包,就可以看作一个SDF。业务检测就是UPF通过分析数据包的头部信息,准确识别出它属于哪个SDF或哪个特定的应用。

QoS流绑定则是SMF的决策过程,它决定了某个SDF应该由哪个QoS流来承载。例如,高清视频SDF应该绑定到一个具有低时延、高带宽保障的QoS流上,而普通的网页浏览SDF则可以绑定到一个尽力而为(Best Effort)的QoS流上。

上行QoS流绑定验证是UPF的一项重要职责。它要确保从UE(小明手机)发出的数据包确实使用了SMF为其指定的QoS流。如果UE“不听话”,用错了QoS流,那么UPF有权将这些数据包丢弃,以维护网络策略的严肃性。

2.2 PFCP如何实现业务检测

那么,SMF是如何通过N4接口,指挥UPF进行业务检测的呢?答案在于PDR(Packet Detection Rule,包检测规则)

Service detection is controlled over the Sxa, Sxb, Sxc and N4 reference points by configuring Packet Detection Information in PDRs to match the intended service data flows or application.

SMF会为每一个需要识别的SDF或应用,在UPF上创建一条或多条PDR。每条PDR的核心是PDI(Packet Detection Information,包检测信息),它定义了匹配数据包的“模板”。

场景代入:小明打开视频APP

小明打开了一款名为“5G超清影院”的APP,点播了一部4K电影。此时,网络中发生了以下交互:

  1. 策略决策:PCF(策略控制功能)知道“5G超清影院”是一个需要高质量保障的视频业务。它将相应的策略(如需要25Mbps的保证比特率)下发给SMF。
  2. PDR下发:SMF收到策略后,立即通过PFCP协议向UPF发送一条PFCP Session Modification Request消息,其中包含一条Create PDR IE。这条PDR的PDI中就定义了如何识别“5G超清影院”的视频流。

这个PDI可能包含如下信息,也就是我们常说的“五元组”:

  • 源IP地址:视频服务器的IP地址(可能是一个地址段)。
  • 目的IP地址:小明手机的IP地址。
  • 源端口号:视频服务器使用的端口。
  • 目的端口号:小明手机上APP接收视频流的端口。
  • 协议ID:通常是TCP或UDP。

UPF会将这条PDR存储起来。当一个数据包到达UPF时,UPF会逐一检查其PDR列表,如果某个数据包的头部信息与这条PDR的PDI完全匹配,UPF就知道:“嘿,这是小明正在看的4K电影的数据包!”

除了五元组,PDI还可以使用应用标识(Application ID) 来进行更深度的包检测(DPI)。如果配置了Application ID,UPF就能识别出这是“5G超清影院”的流量,而不仅仅是某个IP和端口的流量。

2.3 PFCP如何实现下行QoS流绑定

识别出是电影数据包后,下一步就是确保它能通过正确的“高速公路”(即高规格的QoS流)到达小明手机。

For 5GC, the mapping of DL traffic to QoS flows is achieved by configuring QERs with QFI(s) for the QoS flow marking and associating FARs to the downlink PDRs, with FARs set to forward the packets to the appropriate downstream GTP-U tunnel (N9 or N3).

这个过程涉及到另外两个重要的规则:QER(QoS Enforcement Rule,QoS执行规则)FAR(Forwarding Action Rule,转发行为规则)

继续小明的场景:

  1. QER的关联:SMF在创建上述PDR时,还会创建一个QER,并将其与PDR关联起来。这个QER中最重要的信息之一就是QFI(QoS Flow Identifier)。假设SMF为这个4K视频业务分配的QFI是“5”。QER中就会包含QFI=5的信息。
  2. FAR的关联:同时,SMF还会创建一个FAR,并将其也与该PDR关联。这个FAR的核心作用是告诉UPF:“匹配上这条PDR的数据包,该往哪里送?” FAR中的Outer Header Creation字段会指定下游GTP-U隧道的F-TEID(包括目标IP地址和隧道ID),这个隧道正是通往gNB的N3接口隧道。

当电影的下行数据包到达UPF并匹配了PDR后,UPF会执行以下动作:

  • 应用QER:UPF查找与PDR关联的QER,发现QFI=5。于是,它会在数据包的GTP-U头部扩展中打上QFI为“5”的标记。
  • 应用FAR:UPF查找与PDR关联的FAR,根据其中的转发信息,将打了标的数据包封装到正确的N3隧道中,发往基站。

这样,基站收到数据包后,一看QFI是“5”,就知道这是需要高QoS保障的业务,从而在空口侧为其分配优先的无线资源,保证了小明流畅的观影体验。

2.4 PFCP如何实现上行QoS流绑定验证

不仅下行流量需要管理,上行流量同样需要。当小明的手机为视频播放发送TCP确认包(ACK)时,这些ACK包也必须使用正确的QoS流。

For 5GC, uplink QoS flow binding verification (see clause 5.7.1.7 of 3GPP TS 23.501) is achieved by configuring Packet Detection Information in uplink PDRs containing the local F-TEID of the uplink PDU session, the UE IP address (source IP address to match for the incoming packet), the QFI of the QoS flow and the SDF filter(s) or the Application ID. As a result, uplink packets received on the uplink PDU session but that do not match the SDF filter(s) or Application detection filter and QFI associated to the uplink PDRs are discarded.

为了实现上行验证,SMF会为上行业务流配置专门的UL PDR。这条PDR的PDI与下行PDR有所不同,它包含了更严格的匹配条件:

  • 源接口(Source Interface):设置为“Access”,表示来自UE侧。
  • 本地F-TEID:UPF侧接收上行数据的GTP-U隧道端点标识。
  • UE IP地址:作为源IP地址进行匹配。
  • QFI:期望该数据包被打上的QFI标记。
  • SDF Filter 或 Application ID:用于匹配上行业务流,例如视频的TCP ACK包。

当小明手机发出的一个上行数据包到达UPF时,UPF会用这条UL PDR进行匹配。只有当数据包的源IP、目标F-TEID、内容(匹配SDF Filter)以及GTP-U头中的QFI全部符合PDR的规定时,才算匹配成功,数据包才会被正常转发。如果一个数据包虽然内容是视频ACK,但却错误地使用了QFI=9(例如,一个用于普通上网的QoS流)的标记,那么它将无法匹配这条UL PDR,最终很可能因为没有匹配任何PDR而被UPF丢弃。

这个机制确保了QoS策略的端到端闭环,防止了终端滥用高优先级的QoS资源。

3. 门控 (5.4.3 Gating Control)

业务检测和绑定解决了“是什么”和“走哪条路”的问题,而门控则解决了“让不让走”的问题。它就像是在数据流的通道上安装了一个可以由网络控制的开关。

Gating control refers to the process within the user plane function (i.e. PGW-U and TDF-U for EPC, UPF for 5GC) of enabling or disabling the forwarding of IP packets, belonging to a service data flow or detected application’s traffic, to pass through to the desired endpoint.

门控功能由PCF发起,通过SMF下发给UPF执行。其核心目的在于基于业务授权状态来控制数据流的通断。

场景代入:小明体验付费加速服务

小明正在玩一款大型在线游戏,突然感觉网络有些卡顿。游戏APP弹出一个提示:“是否启用‘5G尊享加速’服务,费用5元/小时?” 小明点击了“是”。

网络后台发生了以下变化:

  1. 初始状态:游戏流量本身是允许通过的,但可能使用的是一个普通的QoS流。对于“尊享加速”这个特定的SDF(可能通过特定的服务器IP或端口来识别),SMF在UPF中为其配置的QER中,Gate Status(门控状态) IE被设置为CLOSED(关闭)
  2. 授权与开门:小明确认付费后,游戏服务器通过AF通知了PCF。PCF更新策略给SMF,授权小明使用加速服务。
  3. PFCP指令:SMF立即向UPF发送PFCP Session Modification Request消息,其中的Update QER IE将那条针对“尊享加速”业务的QER中的Gate Status修改为OPEN(打开)
  4. 流量通过:门控打开后,匹配该PDR的游戏加速流量被允许通过。同时,SMF可能还会通过修改QER中的其他参数(我们将在下一节讨论)来提升其QoS。

The UP function shall discard packets matching a PDR if the PDR is associated with at least one QER provisioned with the Gate Status set to CLOSED.

规范明确指出,只要一个PDR关联的QER中门控状态为关闭,那么匹配该PDR的所有数据包都将被丢弃。值得注意的是,门控可以独立控制上行和下行。例如,可以只打开下行门控,让小明接收游戏数据,但关闭上行门控,禁止他发送(除非有其他规则允许),这为实现灵活的业务控制提供了可能。

4. QoS控制 (5.4.4 QoS Control)

门控解决了“通”与“不通”的问题,而QoS控制则解决了“以什么样的质量通”的问题。这是保障用户体验最直接的手段。

QoS control refers to the authorization and enforcement of the maximum QoS that is authorized:

  • for 5GC,
    • at the session level (Session-AMBR, UL and DL Packet Rate of a PDU session or Authorized DL Session AMBR for Offloading);
    • at the QoS Flow level;
    • at the service data flow (SDF) or application level.

规范指出了QoS控制可以在多个层面进行,包括会话级、QoS流级和SDF/应用级。在N4接口上,这些控制同样是通过配置和关联PDR与QER来实现的。

场景代入:小明在观看视频的同时下载文件

我们回到小明看4K视频的场景。为了保证观影体验,网络需要为视频流提供有保障的比特率(Guaranteed Bit Rate, GBR)。与此同时,小明在后台启动了一个大文件的下载任务,这是一个非GBR业务。

4.1 QoS流/SDF级的QoS控制(GBR/MBR)

对于需要质量保障的业务,如小明的4K视频或之前的游戏加速,网络会为其分配一个GBR QoS流。

The CP function shall control the QoS enforcement in the UP function by:

  • creating QERs for the QoS enforcement of the aggregate of SDFs with the same GBR QFI (for 5GC);
  • associating the SDF or application QER to the PDRs associated to the SDF or application;

SMF会执行以下操作:

  1. 创建PDR:为4K视频的SDF创建一条PDR。
  2. 创建QER:为这条PDR关联一个QER。这个QER中会包含两个关键参数:
    • GBR(Guaranteed Bitrate):例如设置为25 Mbps。这是网络承诺为该视频流提供的最低保障速率。
    • MBR(Maximum Bitrate):例如设置为40 Mbps。这是该视频流允许使用的最高速率,即使网络再空闲,也不会超过这个值。
  3. 关联:将PDR与这个QER关联起来。

这样,UPF在处理匹配该PDR的视频数据包时,就会像一个智能的阀门,确保其流速不低于25Mbps,也不高于40Mbps,从而实现了精细化的速率保障。

4.2 会话级的QoS控制(Session-AMBR)

对于那些不需要严格速率保障的业务,如小明的文件下载和网页浏览,它们通常使用非GBR QoS流。这些流量共同受到一个总的速率限制。

For 5GC, this IE [MBR IE] may be set to the value of:

  • the Session-AMBR, for a QER that is referenced by all the PDRs of the non-GBR QoS flows of a PDU session;

SMF会为小明整个PDU会话的所有非GBR业务创建一个共享的QER,并将其关联到所有非GBR业务的PDR上。这个QER中会包含Session-AMBR(会话聚合最大比特率) 的值,例如设置为100 Mbps。

这意味着,小明的文件下载、浏览网页、后台刷新APP等所有非GBR流量,它们共享这100 Mbps的总带宽。如果他只下载文件,下载速率最高可以达到100 Mbps(假设网络空闲)。如果他同时浏览网页,那么两者将共同分享这100 Mbps的资源。

关键点:Session-AMBR的执行与GBR业务是独立的。UPF会先满足所有GBR流的速率需求(例如,保证小明视频的25 Mbps),然后才让所有非GBR流在Session-AMBR的限制下去争抢剩余的资源。这体现了网络资源调度的优先级。

4.3 规则的优先级

当网络策略变得复杂时,一个数据包可能会同时满足多条PDR的匹配条件。例如,一条PDR匹配所有发往某个视频网站的流量,另一条PDR则更精确地匹配该网站上的4K视频流。这时该如何处理?

The CP function shall map the precedence of a PCC rule to the precedence of the PDRs associated to the corresponding service data flows.

答案是优先级(Precedence)。SMF在下发PDR时,会为每条PDR指定一个优先级数值。数值越小,优先级越高。UPF在匹配数据包时,会从高优先级到低优先级逐一检查PDR列表,一旦找到第一条匹配的PDR,就会立即停止搜索,并执行与该PDR关联的规则(FAR, QER, URR等)。

这保证了更具体、更重要的规则会被优先应用,实现了策略的精确覆盖和无冲突执行。

5. 总结

在本篇文章中,我们通过小明的5G生活场景,深入剖析了TS 29.244中策略与计费控制的四大核心机制:

  • 业务检测与绑定 (5.4.2):通过下发带有PDI的PDR,SMF教会了UPF如何识别特定的业务数据流,并通过关联QER(含QFI)和FAR,将其绑定到正确的QoS流和物理通道上。
  • 门控 (5.4.3):通过在QER中设置Gate Status,SMF可以灵活地打开或关闭特定业务数据流的通道,实现了基于业务授权的精细化访问控制。
  • QoS控制 (5.4.4):通过在QER中配置GBR/MBR和Session-AMBR,SMF能够对GBR和非GBR业务进行差异化的速率保障和限制,确保关键业务的用户体验和网络资源的公平使用。
  • 优先级 (Precedence):通过为PDR设置优先级,保证了在复杂策略环境下,规则能够被准确、无歧义地执行。

这四大机制构成了PCC在用户面执行的基础框架。SMF正是通过在PFCP消息中灵活组合和更新PDR、FAR、QER这三大规则,实现了对用户面流量的动态、精细化管控。在下一篇文章中,我们将继续探讨更多高级的PCC功能,如流量标记、重定向和疏导等,敬请期待!

FAQ

Q1:PDR、FAR、QER三者之间是什么关系? A1:它们是PFCP协议中定义的三种核心规则,协同工作。PDR(包检测规则) 负责识别流量,回答“这是什么数据包?”的问题。一旦数据包被PDR匹配,UPF就会查找与该PDR关联的FAR(转发行为规则)QER(QoS执行规则)。FAR负责决定数据包的命运,回答“拿它怎么办?(转发、丢弃、缓存等)以及送到哪里去?”的问题。QER则负责QoS相关的处理,回答“以什么样的质量和权限放行?”的问题,例如速率限制(GBR/MBR)和门控(Gating)。一个PDR必须关联一个FAR,但可以关联零个或多个QER。

Q2:一个数据包可能匹配多个PDR吗?如果可能,UPF会如何处理? A2:对于同一个PFCP会话(即同一个PDU会话),一个数据包只会匹配一个PDR。这是因为每条PDR都有一个优先级(Precedence) 值。UPF会按照从高到低(数值从小到大)的顺序检查PDR列表,一旦找到第一个匹配的PDR,就会立即停止搜索并应用该PDR的规则。这种机制确保了规则执行的唯一性和确定性。不同PFCP会话的PDR通常不会重叠,以保证一个数据包只属于一个会话。

Q3:Session-AMBR和MBR有什么区别? A3:MBR(Maximum Bitrate) 通常在QER中为特定的GBR QoS流或SDF定义,它规定了该GBR流允许使用的峰值速率。而Session-AMBR(Session Aggregate Maximum Bit Rate) 是针对整个PDU会话中所有非GBR QoS流的总速率限制。它不关心单个非GBR流的速率,只控制它们的聚合速率不能超过上限。GBR流的流量不计入Session-AMBR的计算中。

Q4:门控(Gating Control)和FAR中的丢弃(DROP)行为有什么不同? A4:两者都能实现丢弃数据包的效果,但应用场景和机制不同。FAR中的DROP是一个静态的转发指令,一旦PDR关联的FAR设置为DROP,匹配的流量就会被一直丢弃,直到FAR被修改。它更像是一个永久性的“黑名单”规则。而门控(Gating Control) 是QER中的一个动态状态(OPEN/CLOSED),通常用于基于业务授权的临时性控制。例如,用户未付费时门控关闭,付费后打开。它更像一个由策略动态控制的“开关”,状态变更频繁且与业务逻辑紧密相关。

Q5:SMF如何知道要为某个应用(比如高清视频)配置什么样的QoS策略? A5:SMF本身通常不直接决定具体的QoS策略。它从PCF(Policy Control Function,策略控制功能) 获取策略。PCF是PCC架构的策略决策点,它会根据用户的签约信息(存储在UDR中)、运营商的策略、以及来自应用功能(AF,如视频APP的服务器)的请求,来为特定的业务流生成PCC规则(包含QoS、计费等信息),然后通过N7接口下发给SMF。SMF的角色更像是一个策略的“翻译官”和“执行官”,将PCF的PCC规则翻译成UPF能懂的PFCP规则(PDR, FAR, QER等)并下发执行。这个过程在规范TS 23.503中有详细定义。