51学通信

深度解析 3GPP TS 29.244：第5.2.3-5.2.5节 FAR, BAR & QER (转发、缓冲与QoS执行规则)_1

24分钟阅读

好的，我们继续对3GPP TS 29.244规范进行深度解析。

深度解析 3GPP TS 29.244：第5.2.3-5.2.5节 FAR, BAR & QER (转发、缓冲与QoS执行规则)

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范，并结合3GPP TS 23.501 V18.9.0 和 TS 23.502 V18.9.0 的系统架构与流程，重点解读“第5.2节 Packet Forwarding Model”中关于核心执行规则的章节，包括5.2.3 (Forwarding Action Rule), 5.2.4 (Buffering Action Rule) 和 5.2.5 (QoS Enforcement Rule)。本文旨在为读者全方位剖析PFCP协议中定义数据包“处置动作”的三大核心规则。

引言：从“识别”到“执行”——PFCP模型的完整闭环

在之前的系列文章中，我们已经深入探讨了PFCP分组转发模型的“侦察兵”——**PDR（包检测规则）**和“会计师”——URR（使用情况报告规则）。我们知道，PDR解决了“IF”的问题，即如何从纷繁复杂的数据洪流中精准识别出特定业务或用户的流量。而URR则解决了“How Much”的问题，即如何度量这些流量的使用情况。

然而，仅仅识别和度量是不够的。网络的核心价值在于对数据流进行有效的处置和保障。这正是本篇文章将要深入探讨的核心内容：构成“THEN”动作的执行规则。当一个数据包被PDR成功匹配后，它的“命运”将交由一组功能强大且高度协同的规则来决定。这些规则构成了从流量转发、服务质量保障到临时缓冲的完整执行链，它们分别是：

  • FAR (Forwarding Action Rule)：转发行为规则，作为数据流的“导航员”，决定数据包的前进方向——是转发、是丢弃，还是需要临时“靠边停车”（缓冲）。
  • BAR (Buffering Action Rule)：缓冲行为规则，是FAR的“配套设施”，如同“仓库管理员”，当FAR指令数据包需要缓冲时，BAR将提供详细的仓储策略。
  • QER (QoS Enforcement Rule)：QoS执行规则，如同服务质量的“宪兵”，通过门控、速率限制、优先级标记等手段，确保数据流的服务质量得到严格保障。

A PDR contains a set of information (Packet Detection Information - PDI) used to match packets. To one PDR corresponds:

  • zero or one FARs, which contains instructions related to the processing of the packets…
  • zero, one or more QERs, which contains instructions related to the QoS enforcement of the traffic;
  • zero, one or more URRs, which contains instructions related to traffic measurement and reporting.

我们将继续跟随主角“鹰眼-01”摄像头，但场景将引入新的挑战，以生动地诠释这些规则如何协同工作：

场景深化：“鹰眼-01”在完成一轮高强度的质检任务后，为了节省电力，进入了5G网络为其配置的**CM-IDLE（连接管理空闲）**状态。在此状态下，它与网络之间的无线连接（RRC Connection）和用户面隧道（N3）均已释放，但其在核心网的注册状态（RM-REGISTERED）和PDU会话依然保持。突然，中央控制室的管理员下发了一条紧急指令，要求“鹰眼-01”立即调整云台角度。这个指令数据包到达了UPF，但此时通往“鹰眼-01”的用户面路径已经“断开”。UPF该如何处理这个“无处可去”的数据包？这正是FAR的缓冲动作与BAR协同工作的经典场景。

1. FAR (Forwarding Action Rule)：数据流向的“导航员”

**转发行为规则（FAR）**是PDR匹配成功后必须执行的核心规则之一（除非被专用于多接入的MAR替代）。它明确指示UPF应如何处置数据包，是决定数据包“命运”的总指挥。

a FAR, which contains instructions related to the processing of the packets as follows:

  • an Apply Action parameter, which indicates whether the UP function shall:
  • forward, duplicate, drop or buffer the packet…

FAR的核心指令由两部分构成：宏观的应用动作（Apply Action）和具体的转发参数（Forwarding Parameters）。

1.1 应用动作 (Apply Action)：决定数据包的“命运”

Apply Action字段是一组标志位的集合，它通过不同的标志位组合，定义了对数据包的最终“命运裁决”。

  • FORW (Forward) - 转发：这是最常见的动作。它指示UPF将数据包发送到下一跳。在“鹰眼-01”正常工作时（处于CM-CONNECTED状态），其上行视频流和下行控制流关联的FAR都设置了FORW标志。
  • DROP (Drop) - 丢弃：指示UPF直接丢弃数据包。这可用于实现防火墙功能，例如，SMF可以下发一条高优先级的PDR/FAR组合，匹配并DROP掉所有来自某个已知恶意IP地址的流量。
  • BUFF (Buffer) - 缓冲：指示UPF将数据包（通常是下行数据）暂存起来。这就是我们新场景的关键。当“鹰眼-01”进入CM-IDLE状态时，其下行PDR关联的FAR的Apply Action就会被SMF修改为BUFF。
  • NOCP (Notify CP) - 通知控制面：该标志通常与BUFF标志一同使用。它指示UPF在缓冲第一个下行数据包时，需要向CP功能（SMF）发送一个“下行数据通知”（Downlink Data Notification）。SMF收到此通知后，便会启动网络侧寻呼流程，唤醒UE，重建无线和N3隧道，以便下发缓冲的数据。
  • DUPL (Duplicate) - 复制：指示UPF将数据包复制一份，并根据**复制参数（Duplicating Parameters）**将其发送到另一个目的地，常用于合法监听（LI）等场景。

1.2 转发参数 (Forwarding Parameters)：规划数据包的“路径”

当Apply Action包含FORW时，FAR中必须包含**转发参数（Forwarding Parameters）**来提供具体的转发路径信息。

  • forwarding, buffering and/or duplicating parameters, which the UP function shall use if the Apply Action parameter requests the packets to be forwarded, buffered or duplicated respectively.

转发参数的核心组件包括：

  • 目的接口（Destination Interface）：指定数据包的逻辑出接口。例如，对于“鹰眼-01”的上行视频流，Destination Interface为Core side（核心网侧），表示数据将从N6接口发往数据网络。对于下行控制指令，则为Access side（接入侧），表示数据将从N3接口发往RAN。
  • 外层头创建（Outer Header Creation）：这是实现隧道转发的灵魂指令。它指示UPF在转发数据包前需要添加何种封装头。
    • 场景示例：处理“鹰眼-01”的下行控制指令时，FAR中的Outer Header Creation会包含一个GTP-U/UDP/IP头的创建指令。其中，目标IP地址是为“鹰眼-01”服务的基站（gNB）的N3接口地址，GTP-U头中的**TEID（隧道端点标识符）**是gNB为这条N3隧道分配的ID。UPF就像一个打包工人，将原始数据包（AI服务器发给摄像头的指令）装进一个写着正确“收件地址”（gNB IP和TEID）的“快递箱”（GTP-U隧道）里，然后投递出去。

1.3 FAR的关键信息元素 (IE)

下表根据规范原文中的 Table 7.5.2.3-1: Create FAR IE within PFCP Session Establishment Request 及其相关章节，对创建FAR时的关键字段进行了整理和解释。

关键信息元素 (IE)描述与作用
FAR IDFAR的唯一标识符，用于被PDR关联。
Apply Action应用动作，定义对数据包的宏观处置（转发、丢弃、缓冲、复制等）。
Forwarding Parameters转发参数，当动作为转发或复制时，提供详细的路径信息。
BAR ID缓冲动作规则ID。当动作为缓冲时，指向一个BAR，获取详细的缓冲策略。
Duplicating Parameters复制参数，当动作为复制时，提供复制流的转发路径信息。

2. BAR (Buffering Action Rule)：CM-IDLE状态下的“仓库管理员”

**缓冲动作规则（BAR）**是FAR功能的延伸。它不被PDR直接关联，而是通过FAR中的BAR ID被引用。当FAR的Apply Action被设置为BUFF（缓冲）时，UPF就会根据关联的BAR中的指令来执行具体的缓冲操作。

A BAR provides instructions to control the buffering behaviour of the UP function for all the FARs of the PFCP session set with an Apply Action parameter requesting the packets to be buffered and associated to this BAR.

2.1 BAR的核心应用场景与参数

BAR最典型的应用场景，正是处理处于CM-IDLE状态UE的下行数据。此时，UE为了省电，释放了与基站的RRC连接，核心网侧对应的N3用户面隧道也被释放。当有下行数据到达UPF时，UPF无法直接送达UE，此时就必须执行缓冲。

BAR的核心参数为缓冲策略提供了明确的限制，以防止UPF内存被耗尽：

  • 下行缓冲时长（DL Buffering Duration）：指示UPF最多可以缓冲多长时间的数据。超出此时长后到达的数据包将被丢弃。
  • 下行缓冲建议包数（DL Buffering Suggested Packet Count）：指示UPF最多可以缓冲多少个数据包。超出此数量后到达的数据包将被丢弃。

场景示例：唤醒“鹰眼-01”

  1. “鹰眼-01”进入CM-IDLE状态。AMF通知SMF，SMF随即通过PFCP Session Modification流程，更新了“鹰眼-01”下行PDR关联的FAR，将其Apply Action从FORW修改为BUFF+NOCP，并确保其关联了正确的BAR ID。
  2. 中央控制室的紧急云台调整指令到达UPF。
  3. UPF匹配到下行PDR，发现关联的FAR要求执行BUFF。UPF将该指令数据包存入缓冲区，并遵循BAR中定义的时长和包数限制。
  4. 由于FAR中还设置了NOCP，UPF立即向SMF发送Downlink Data Notification消息。
  5. SMF收到通知，触发Network Triggered Service Request流程，向AMF发送Namf_Communication_N1N2MessageTransfer请求，要求对“鹰眼-01”进行寻呼（Paging）。
  6. “鹰眼-01”被唤醒，响应寻呼，发起UE Triggered Service Request流程，重建RRC连接和N3隧道。
  7. 在Service Request流程中，SMF再次通过PFCP Session Modification，将FAR的Apply Action改回FORW，并向UPF下发新的N3隧道信息。
  8. UPF将缓冲区中的指令数据包通过新建的N3隧道下发给“鹰眼-01”，摄像头成功执行了云台调整。

2.2 BAR的关键信息元素 (IE)

下表根据规范原文中的 Table 7.5.2.6-1: Create BAR IE within PFCP Session Establishment Request 对创建BAR时的关键字段进行了整理和解释。

关键信息元素 (IE)描述与作用
BAR IDBAR的唯一标识符，用于被FAR引用。
DL Buffering Duration下行缓冲时长，定义数据包在UPF中可被缓存的最大时间。
DL Buffering Suggested Packet Count下行缓冲建议包数，定义UPF可缓存的最大数据包数量。

3. QER (QoS Enforcement Rule)：服务质量的“宪兵”

**QoS执行规则（QER）**负责在UPF上对数据流实施具体的服务质量控制，确保高价值业务获得优先保障，同时限制低优先级业务对网络资源的过度占用。

zero, one or more QERs, which contains instructions related to the QoS enforcement of the traffic;

3.1 QER的核心控制手段

QER通过一系列参数，实现了对流量的精细化QoS控制。

  • 门控状态 (Gate Status)：这是一个简单的“开关”，可以是Open（打开）或Closed（关闭）。当状态为Closed时，所有匹配该QER的数据包都将被UPF直接丢弃。这为动态启停业务流（例如，预付费业务到期）提供了一个高效的手段。
  • MBR (Maximum Bitrate) / GBR (Guaranteed Bitrate)：最大比特率和保证比特率。MBR为数据流设置了速率上限，而GBR则为需要稳定带宽的业务（如VoNR、实时视频）提供了带宽保障。
  • QFI (QoS Flow Identifier)：QoS流标识符。QER最重要的功能之一，是指示UPF在GTP-U隧道的外层头上打上指定的QFI标记。无线接入网（(R)AN）会根据这个QFI，将数据流映射到合适的无线承载（Data Radio Bearer）上，从而在空口上提供差异化的调度优先级。
  • 反射QoS (Reflective QoS)：通过在QER中设置RQI（Reflective QoS Indication）标志启用。对于下行流量，QER可以指示UPF在GTP-U头中插入RQI标记。UE收到带有RQI标记的下行包后，会自动创建一条“派生QoS规则”，将具有相同五元组的上行流量映射到与下行相同的QoS Flow中，从而实现上下行业务QoS的自动匹配。

场景示例：为“鹰眼-01”配置QERs

  • QER-Video (关联PDR-Video)：
    • Gate Status: Open
    • UL GBR/MBR: 50 Mbps / 80 Mbps
    • QFI: 8 (假设8是运营商定义的代表高清实时视频的5QI值)
    • 作用：保证“鹰眼-01”的视频流至少有50Mbps的上行带宽，最高不超过80Mbps，并在空口上获得高优先级调度。
  • QER-Telemetry (关联PDR-Telemetry)：
    • Gate Status: Open
    • QFI: 9 (假设9是代表尽力而为（Best Effort）业务的5QI值)
    • 作用：遥测流作为非GBR流量，其速率将受限于整个PDU会话的总速率上限（Session-AMBR），并在空口上获得普通优先级调度。

3.2 QER的关键信息元素 (IE)

下表根据规范原文中的 Table 7.5.2.5-1: Create QER IE within PFCP Session Establishment Request 对创建QER时的关键字段进行了整理和解释。

关键信息元素 (IE)描述与作用
QER IDQER的唯一标识符，用于被PDR关联。
Gate Status门控状态，控制流量的开启或关闭。
Maximum Bitrate (MBR)最大比特率，定义流量的速率上限。可应用于SDF、QoS Flow或整个会话（Session-AMBR）。
Guaranteed Bitrate (GBR)保证比特率，为需要带宽保障的GBR QoS Flow提供承诺速率。
QFIQoS流标识符，用于指示(R)AN在空口进行差异化调度。
RQI (Reflective QoS)反射QoS指示。当在QER中设置时，指示UPF对下行包打上RQI标记，触发UE侧的反射QoS行为。

FAQ环节

Q1：FAR中的“缓冲（BUFF）”动作和BAR（缓冲动作规则）之间是什么关系？

A1： FAR和BAR是主从关系。FAR是主规则，定义了对数据包的宏观处置，其中一种动作是“缓冲”（BUFF）。当FAR决定要缓冲数据包时，它必须通过一个BAR ID来引用一条BAR。BAR作为从规则，提供了关于如何缓冲的具体细节，例如最大缓冲时长（DL Buffering Duration）或最大缓冲包数（DL Buffering Suggested Packet Count）。将缓冲的具体策略从FAR中分离出来设计成独立的BAR，主要是为了复用。在同一个PFCP会话中，可能有多条不同的下行数据流（对应不同的FARs）在UE空闲时都需要缓冲，而它们的缓冲策略可能是相同的。这时，所有这些FARs就可以引用同一个BAR，从而简化了信令配置。

Q2：QER中的“门控（Gating）”和FAR中的“丢弃（DROP）”有什么区别？

A2： 两者都能实现丢弃数据包的效果，但它们的语义和应用场景有所不同。FAR中的DROP动作通常用于实现静态的、基于策略的过滤，类似于防火墙规则。例如，永久性地阻止某个IP地址或应用的流量。而QER中的Gate Status（门控状态）则更像一个动态的“水龙头开关”。它通常用于基于会话状态或计费策略的动态控制。例如，当用户的预付费流量用尽时，PCF可以通知SMF，SMF便通过PFCP消息将该业务流对应的QER的Gate Status设置为“Closed”，从而立即停止该业务的流量。门控提供了一种在不删除PDR/FAR规则的情况下，快速启停业务流的灵活机制。

Q3：当UPF缓冲了一个下行数据包并通知SMF后，网络后续会发生什么？

A3： 这个过程会触发一个完整的“网络侧寻呼”流程，旨在唤醒处于CM-IDLE状态的UE。具体步骤如下：1. UPF根据FAR中的BUFF+NOCP指令，缓冲下行数据包并向SMF发送“下行数据通知”（Downlink Data Notification）。2. SMF收到通知后，向AMF发起Namf_Communication_N1N2MessageTransfer服务操作，请求寻呼UE。3. AMF向UE所在的注册区域（Registration Area）内的所有基站（gNBs）发送寻呼（Paging）消息。4. UE监听到寻呼消息后，发起“UE触发的服务请求”（UE Triggered Service Request）流程，与网络重建RRC连接和N3隧道。5. 连接重建成功后，SMF更新UPF上的FAR规则（将BUFF改回FORW），UPF随即将缓冲的数据通过新的N3隧道下发给UE。

Q4：QER中的QFI是如何帮助实现端到端QoS的？

A4： QFI是连接核心网QoS策略和无线接入网（RAN）QoS执行的桥梁。在核心网侧，SMF根据业务需求（如低时延、高带宽）和用户签约，为数据流（SDF）关联一个QER，并在QER中指定一个QFI值。UPF在处理数据包时，会读取QER中的QFI，并将其标记在GTP-U隧道的外层头中发往RAN。在无线侧，RAN（如gNB）看到这个QFI标记后，会将其映射到预先配置好的QoS特性上（如调度权重、HARQ重传次数、逻辑信道配置等），并为该数据流分配相应的无线承载（Data Radio Bearer）资源，从而在空口上提供差异化的调度优先级和服务质量。通过这种方式，QFI将核心网的抽象QoS要求转化为了RAN侧具体、可执行的无线资源调度策略，实现了端到端QoS保障的关键一环。

Q5：什么是反射QoS（Reflective QoS）？它是如何通过QER启用的？

A5： 反射QoS是一种简化上行业务QoS配置的机制。在传统方式下，为上下行匹配的业务流（如视频通话）配置QoS需要网络侧（SMF）分别为上下行创建独立的QoS规则。而启用反射QoS后，网络只需为下行流配置好QoS。当UPF处理这些下行数据包时，如果其匹配的PDR所关联的QER中设置了RQI（反射QoS指示），UPF就会在发往UE的GTP-U包头中插入一个RQI标记。UE的NAS层收到这个带有RQI标记的下行包后，会自动“学习”这个包的IP五元组和QFI，并生成一条派生的上行QoS规则。这条规则会自动将具有相同五元组（源目的IP/端口反转）的上行数据包映射到与下行相同的QoS Flow中，从而实现了上下行QoS的自动匹配，大大减少了信令开销。😊

关系图谱