深度解析TS 29.244:5.4 Policy and Charging Control (策略与计费控制) - Part 4 传输层标记、延迟激活与速率控制

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中,关于“5.4 Policy and Charging Control”后续核心章节(5.4.13至5.4.15),旨在为读者提供一个关于传输层标记、策略延迟激活以及数据包速率控制机制的全景视图。

引言

在本系列的前三篇文章中,我们已经全面探讨了策略与计费控制(PCC)的基础框架、高级流量管控手段,以及与实际运营紧密相关的预定义规则、计费和应用上报机制。我们已经知道,SMF通过N4接口下发的PDR、FAR、QER、URR等规则,构成了指挥UPF处理数据流的“语法”。

然而,PCC策略的执行不仅限于核心网内部。数据包一旦离开UPF,将进入复杂的IP传输网络,如何确保这些数据包在传输网络中依然能够获得与其业务等级相匹配的优先处理?当一项策略需要在未来的特定时刻生效或失效时,网络如何实现“定时任务”的部署?对于某些特定业务(如物联网设备),运营商可能不关心其总流量,而更关心其发包的频率,又该如何进行控制?

本篇文章将继续深入TS 29.244规范的5.4章,聚焦于解决上述问题的三大关键技术:传输层标记(5.4.13)、延迟PDR激活与去激活(5.4.14)以及包速率执行(5.4.15)。我们将继续跟随5G用户小明的数字生活。今天,小明将使用VoNR进行高清语音通话,订阅一项只在周末生效的“游戏加速包”,并体验一个对发包频率有严格限制的物联网业务。通过这些场景,我们将揭示这些高级策略控制机制的内部工作原理。

1. 传输层标记 (5.4.13 Transport Level Marking)

数据包在核心网用户面(UPF)内,其服务质量由QFI(QoS Flow Identifier)来标识和保障。但是,当数据包离开UPF进入承载网络(Transport Network)后,传输网的路由器并不识别GTP-U头中的QFI。为了让传输网络也能识别业务的优先级,就需要一种通用的标记机制——传输层标记,通常是利用IP头中的DSCP(Differentiated Services Code Point)字段。

For EPC, transport level marking is performed on a per EPS bearer basis in the SGW and PGW. Transport level marking refers to the process of marking traffic with a DSCP value based on the locally configured mapping from the QCI and optionally the ARP priority level. For 5GC, transport level marking is performed on a per QoS flow basis. Transport level marking refers to the process of marking traffic at the UPF/MB-UPF with a DSCP value based on the mapping from the 5QI, the Priority Level (if explicitly signalled) and optionally the ARP priority level configured at the SMF/MB-SMF.

规范明确了传输层标记的核心思想:将核心网内部的QoS等级(EPC中的QCI/ARP,5GC中的5QI/Priority Level/ARP)映射为一个IP传输网络能够识别的DSCP值。这样,当数据包在传输网中传递时,支持DiffServ的路由器就可以根据DSCP值对其进行差异化处理,例如优先转发、保证低时延等,从而将5G网络的QoS承诺延伸到承载网中。

1.1 PFCP如何实现传输层标记

CP功能(SMF)通过配置FAR来指示UPF执行传输层标记。

Transport level marking shall be controlled by the CP function by providing the DSCP in the ToS or Traffic Class within the Transport Level Marking IE in the FAR that is associated to the PDR matching the traffic to be marked. The UP function shall perform the transport level marking for the detected traffic and sends the marked packet to the peer entity.

具体步骤如下:

  1. 策略决策:SMF根据PCF的策略或本地配置,确定某个QoS流(例如,基于其5QI)需要被标记上特定的DSCP值。
  2. PFCP指令:SMF向UPF发送PFCP Session Modification Request(或在会话建立时发送PFCP Session Establishment Request)。
  3. 规则配置:在该消息中,SMF为需要标记的流量创建或更新PDR,并为其关联一条FAR。这条FAR的特殊之处在于,其Forwarding Parameters中包含了一个Transport Level Marking IE。该IE中明确指定了要打上的ToS/Traffic Class值(其中就包含了DSCP值)。
  4. UPF执行:当UPF处理匹配该PDR的数据包时,它会读取关联FAR中的Transport Level Marking IE,并修改数据包最外层IP头的DSCP字段为指定的值,然后再将其发出。

SMF也可以随时通过修改FAR中的Transport Level Marking IE来改变标记策略。

1.2 场景代入:小明的高清VoNR通话

小明正在使用他的5G手机拨打一通VoNR(Voice over New Radio)高清语音电话。VoNR业务对时延和抖动非常敏感,需要最高优先级的保障。

  1. QoS流建立:为了承载VoNR的语音数据,网络为小明的PDU会话建立了一个5QI为1的GBR QoS流。
  2. DSCP映射策略:在SMF的配置中,5QI=1被映射为DSCP值为“EF”(Expedited Forwarding),这是DiffServ中用于语音等实时业务的最高优先级标记。
  3. PFCP指令下发:SMF向UPF下发指令:
    • 为下行VoNR语音流创建一个PDR,PDI中包含该SDF的五元组信息,并关联一个QER(其中QFI=1)。
    • 为该PDR关联一个FAR。在该FAR的Forwarding Parameters中,包含Transport Level Marking IE,其ToS/Traffic Class字段的值被设置为“EF”。
  4. UPF标记执行
    • 当一个下行VoNR语音包到达UPF时,它匹配了上述PDR。
    • UPF根据关联的FAR,在将该数据包封装到发往基站的N3 GTP-U隧道之前,会修改GTP-U隧道的外层IP头的DSCP字段为“EF”。
    • 同样,对于上行语音包,UPF在将其转发到核心网N6接口时,也会修改其IP头的DSCP字段为“EF”。
  5. 传输网优先处理:这些被标记为“EF”的数据包在经过传输网的路由器时,会被放入最高优先级的队列中,得到优先转发,从而保证了小明通话的清晰流畅。

2. 延迟PDR激活与去激活 (5.4.14 Deferred PDR activation and deactivation)

在某些业务场景下,策略规则并非需要立即生效,而是要在未来的某个特定时间点才被激活或停止。例如,用户订购了仅在夜间生效的流量优惠包,或者只在周末生效的游戏加速服务。为了支持这种“定时任务”式的策略管理,PFCP引入了延迟PDR激活/去激活机制。

As specified in clause 6.3.2 of 3GPP TS 23.203 and clauses 4.5.13 and 4a.5.13 of 3GPP TS 29.212, Policy and charging control rule operations can be also performed in a deferred mode. To support such deferred PCC rule activation or deactivation, the CP function and UP function may optionally support the Deferred PDR activation and deactivation (DPDRA) as described below.

这是一个可选功能,需要CP和UP功能都支持(UPF通过UP Function Features中的DPDRA标志位来声明)。

2.1 PFCP如何实现延迟激活/去激活

实现该功能的核心是PDR中的两个时间戳IE:Activation TimeDeactivation Time

If the feature DPDRA is supported in both CP function and UP function, and when a PCC rule is provisioned in a deferred mode, i.e. with a Rule-Activation-Time and/or Rule-Deactivation-Time, the CP function shall provision the corresponding PDR using Create PDR IE or Update PDR together with an Activation Time and/or Deactivation Time to enable the PDR being activated or deactivated at requested time.

当SMF下发一条PDR时,它可以附带Activation Time和/或Deactivation Time。UPF收到后,会根据这两个时间戳来管理PDR的“激活”与“非激活”状态。

  • 非激活状态(inactive):PDR虽然存在于UPF中,但不会参与数据包的匹配过程。UPF的行为就好像这条PDR被删除了一样。
  • 激活状态(active):PDR正常参与数据包的匹配。

2.2 不同时间组合下的UPF行为

规范详细定义了在不同时间组合下UPF的行为逻辑:

  1. 只提供Activation Time
    • 如果Activation Time是未来时间,UPF将PDR设为非激活,并等到该时间点到达时自动将其变为激活
    • 如果Activation Time是过去时间,UPF立即将PDR设为激活
  2. 只提供Deactivation Time
    • 如果Deactivation Time是未来时间,UPF立即将PDR设为激活,并等到该时间点到达时自动将其变为非激活
    • 如果Deactivation Time是过去时间,UPF立即将PDR设为非激活
  3. 同时提供且Activation Time < Deactivation Time
    • 如果当前时间在两者之间,PDR为激活状态,并将在Deactivation Time到达时变为非激活
    • 如果当前时间在两者之前,PDR为非激活,将在Activation Time激活,再在Deactivation Time变为非激活
    • 如果当前时间在两者之后,PDR立即变为非激活
  4. 同时提供且Deactivation Time < Activation Time
    • 如果当前时间在两者之间,PDR为非激活状态,并将在Activation Time到达时变为激活
    • 如果当前时间在两者之前,PDR为激活,将在Deactivation Time变为非激活,再在Activation Time重新激活。
    • 如果当前时间在两者之后,PDR立即变为激活

2.3 场景代入:小明的“周末游戏加速包”

小明订购了一项名为“周末王者荣耀加速”的增值业务,该业务只在每周六的00:00到周日的23:59期间生效,为他的游戏流量提供低时延的QoS保障。

  1. 订阅与策略下发:周五下午,小明通过运营商APP成功订购了这项业务。PCF生成了相应的PCC规则,并下发给SMF。
  2. 延迟PDR的配置:SMF随即向UPF发送一条PFCP Session Modification Request消息,其中包含一条Create PDR。这条PDR专门用于识别“王者荣耀”的游戏流量,并且:
    • Precedence(优先级)被设置为一个很高的值(例如100),高于用于普通游戏流量的PDR(例如优先级200)。
    • 与该PDR关联的QER中,配置了低时延的GBR参数。
    • 关键:这条PDR中包含了两个时间戳IE:
      • Activation Time: 设置为本周六的00:00:00。
      • Deactivation Time: 设置为本周日的23:59:59。
  3. UPF的行为
    • 周五:UPF收到这条PDR后,由于当前时间早于Activation Time,将其状态设置为非激活。小明的游戏流量仍然由优先级为200的普通PDR处理。
    • 周六00:00:00:UPF的内部时钟到达激活时间,自动将这条PDR的状态切换为激活。此时,小明的游戏流量因为匹配了优先级更高的PDR(100),开始享受低时延的QoS保障。
    • 周日23:59:59:UPF的内部时钟到达去激活时间,自动将这条PDR的状态切换回非激活。小明的游戏流量又重新由优先级为200的普通PDR处理。

通过这种方式,运营商无需在周六凌晨和周日午夜进行两次信令交互来开关业务,而是提前一次性部署好“定时任务”,大大提升了网络自动化和运营效率。

3. 包速率执行 (5.4.15 Packet Rate enforcement)

对于某些业务,特别是物联网(IoT)场景中的小数据业务,运营商可能更关心设备的发包频率而非总流量。例如,一个智能水表每天只允许上报几次数据。为了实现这种基于数据包数量的控制,PFCP提供了包速率执行机制。

Packet rate enforcement refers to the process of limiting the rate of uplink and/or downlink packets allowed to be sent for a PDN connection or a PDU session.

该功能主要用于以下场景:

  • APN速率控制:在EPC与5GC互通场景中,对连接到某个APN的所有PDN连接进行总的发包速率限制。
  • 小数据速率控制:在5GC中,对单个PDU会话进行发包速率限制,这是CIoT(Cellular IoT)优化的关键部分。
  • 服务PLMN速率控制:对控制面承载的数据进行下行速率限制。

3.1 PFCP如何实现包速率执行

包速率执行是通过在QER中配置Packet Rate IE来实现的。

The CP function shall control packet rate enforcement in the UP function by:

  1. creating the necessary PDR(s) to represent the uplink or downlink traffic to be enforced …
  2. creating QER(s) containing the Packet Rate IE …
  3. associating the QER(s) to the UL and/or DL PDRs of the traffic for which packet rate enforcement is required.

具体步骤如下:

  1. 识别流量:SMF创建PDR来识别需要进行速率限制的流量。
  2. 创建QER:SMF创建或更新一个QER,其中包含Packet Rate IE。该IE定义了速率限制的规则,主要包括:
    • Maximum Uplink/Downlink Packet Rates:定义了在一个时间单位内(如分钟、小时、天)允许发送的最大上/下行数据包数量。
    • Additional Maximum Uplink/Downlink Packet Rates:可选参数,允许在达到最大速率后,额外再发送一定数量的“例外”数据包。
  3. 关联:将此QER与相应的PDR关联起来。

当UPF收到这样的指令后,它会像一个“计包器”,在指定的时间单位内对匹配PDR的数据包进行计数。一旦计数值达到了最大允许速率,UPF就会丢弃或延迟后续的数据包。

3.2 速率状态的上报与切换

在一些场景下(如小数据速率控制和APN速率控制),CP功能需要知道当前周期内还剩余多少数据包额度,特别是在发生移动性事件时。

  • 状态上报:SMF可以在QER中通过QER Control Indications IE里的RCSR(Rate Control Status Reporting)标志位,请求UPF在PFCP会话释放时,通过Packet Rate Status IE上报剩余的包数量和当前时间周期的剩余有效时间。
  • 状态继承:当UE发生移动性事件(如从5GS切换到EPS),SMF需要将旧系统下的速率控制状态(如已用包数)传递到新系统。SMF可以通过Query Packet Rate Status IE查询UPF获取当前状态,然后在更新QER时,将这个状态通过Packet Rate Status IE下发给UPF,UPF会优先执行这个“剩余状态”,执行完毕后再应用新的完整速率限制规则。

3.3 场景代入:小明的智能水表

小明家安装了一个基于NB-IoT的智能水表。根据他办理的物联网套餐,该水表每天最多允许上报24次数据(平均每小时一次)。

  1. 策略配置:当水表的PDU会话建立时,SMF根据其签约信息,决定为其启用“小数据速率控制”。
  2. PFCP指令:SMF向UPF发送PFCP Session Establishment Request,其中:
    • 创建了一条UL PDR,用于匹配水表上报的所有数据。
    • 创建了一条QER,并与该PDR关联。QER中包含Packet Rate IE,其参数设置为:
      • Maximum Uplink Packet RateNumber of Uplink Packets Allowed = 24。
      • Time unit = day(天)。
    • QER的QER Control Indications中设置了RCSR=1,要求会话释放时上报状态。
  3. UPF执行
    • UPF开始为该PDU会话的上行流量计数,时间周期为一天。
    • 在一天之内,水表上报的前24个数据包都被正常转发。
    • 当水表尝试发送第25个数据包时,UPF检测到已超出当天配额,于是将这个数据包丢弃
    • 到第二天的零点,UPF的计数器和时间周期重置,水表又可以重新开始上报数据。

这种机制可以有效防止物联网终端异常,产生大量信令风暴,保障了网络的稳定。

总结

在本篇文章中,我们继续深入PCC的世界,探讨了三种更为具体和精细的策略控制技术,它们共同丰富了运营商的策略工具箱:

  • 传输层标记 (5.4.13):通过在FAR中配置Transport Level Marking IE,将核心网内部的QoS等级(5QI)映射为传输网络通用的DSCP标记,实现了QoS策略的端到端延伸,确保了高优先级业务在整个传输路径上的服务质量。
  • 延迟PDR激活与去激活 (5.4.14):通过在PDR中配置Activation TimeDeactivation Time,实现了策略规则的“定时生效”和“定时失效”,为运营商部署具有时间属性的业务(如夜间套餐、假日套餐)提供了极大的便利,降低了实时信令开销。
  • 包速率执行 (5.4.15):通过在QER中配置Packet Rate IE,对数据包的发送频率进行限制,是实现物联网场景下小数据业务控制、防止信令风暴的关键技术。

从基础的流量检测,到高级的流量疏导,再到今天我们讨论的定时策略和频率控制,TS 29.244规范通过PFCP协议,为5G网络赋予了前所未有的灵活性和智能化水平。这些机制的组合应用,使得网络不再是一个简单的“管道”,而是一个能够深刻理解业务意图并精确执行策略的智能平台。

FAQ

Q1:传输层标记(Transport Level Marking)与我们之前讨论的下行流级别标记(DL Flow Level Marking)有什么区别? A1:两者都使用DSCP进行标记,但目的和应用场景不同。下行流级别标记(5.4.5节)是一种核心网内部的协作机制,通常由TDF(流量检测功能)执行,目的是为了让下游的PGW-U/UPF能够识别应用类型而无需再次进行DPI。而传输层标记(5.4.13节)的目的是为了让核心网外部的IP传输网络能够识别业务的QoS优先级。它的标记依据是核心网内部的QoS参数(如5QI),执行者是UPF(作为核心网的边缘节点),标记的对象是发往传输网络的数据包外层IP头。

Q2:当一个PDR被设置为延迟去激活(Deactivation Time)后,到达指定时间点时,这条PDR是被删除了吗? A2:不是被删除,而是状态变为“非激活(inactive)”。PDR及其关联的FAR、URR、QER等规则仍然存储在UPF中,但它不再参与数据包的匹配流程。这种设计的好处是,如果后续需要重新激活这条规则(例如,下一个周末),SMF只需发送一个更新Activation TimeUpdate PDR消息,而无需重新下发整套规则,效率更高。

Q3:如果SMF下发一条PDR,其Activation TimeDeactivation Time都已经是过去的时间,UPF会如何处理? A3:UPF会比较这两个时间的先后顺序来决定PDR的最终状态。如果Activation TimeDeactivation Time之前,说明这个PDR的有效“生命周期”已经完全过去,UPF会立即将其设置为非激活状态。反之,如果Deactivation TimeActivation Time之前(这代表了一个“跨越时间零点”的周期,例如从昨晚10点到今早6点),而当前时间已经晚于Activation Time,那么PDR会被立即设置为激活状态。

Q4:包速率执行中的“Additional Maximum Packet Rates”是做什么用的? A4:它提供了一种额外的、超出常规速率限制的“突发”能力。例如,一个物联网设备可能被限制为每小时最多发送10个包(Maximum Packet Rate),但运营商策略允许它在某些紧急情况下,每小时可以额外再发送2个“例外”包(Additional Maximum Packet Rate)。这样,UPF的总速率限制就变成了12个包/小时。这种机制为策略设计提供了更大的灵活性。

Q5:UE在5GC和EPC之间切换时,网络如何保证小数据速率控制(Small Data Rate Control)和APN速率控制(APN Rate Control)的连续性? A5:这是通过速率状态的继承来实现的。当UE即将从5GS切换到EPS时,SMF会向UPF发送一个PFCP Session Modification Request,其中包含Query Packet Rate Status IE,以查询当前时间周期内小数据速率控制的已用包数和剩余时间。收到UPF的响应后,SMF将这些状态信息转换为EPS下的APN速率控制参数,并在更新UPF/PGW-U的QER时,通过Packet Rate Status IE下发。UPF会先耗尽这个“剩余额度”,然后再开始应用新的完整APN速率限制规则,反之亦然,从而保证了跨系统切换时速率控制策略的平滑过渡。😊