51学通信

深度解析TS 29.244：5.28, 5.32 & 5.33 - 边缘计算增强与数据交付保障

20分钟阅读

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

在前几期的内容中，我们已经穿越了PCC策略执行的复杂迷宫，见证了5G网络如何承载IPTV和TSN等截然不同的业务类型。这些功能展示了5G作为通用连接平台的强大能力。然而，5G的演进并未止步，5G-Advanced正将网络的“神经末梢”向更靠近用户和数据源的边缘延伸，这就是边缘计算（Edge Computing）。

边缘计算旨在将计算和存储资源从遥远的数据中心，下沉到网络的边缘（如基站、企业园区），从而为应用提供超低时延和海量带宽。但这给网络的用户面带来了新的挑战：当用户移动时，如何确保其与边缘应用的连接无缝切换？当边缘服务本身需要动态迁移时，网络如何保证业务不中断？

本篇文章将聚焦于TS 29.244规范中为应对这些挑战而设计的几大关键机制。我们将深入剖析5.28节（下行数据交付状态）、**5.32节（上行数据包缓冲）以及5.33节（边缘计算增强）**的核心内容，揭示PFCP协议如何成为实现动态、可靠的边缘业务的幕后英雄。

为了将这些概念付诸实践，让我们进入一个新的场景。网络工程师小明正在为一个自动驾驶测试场部署5G边缘计算解决方案。测试车辆需要与部署在园区UPF（作为本地PSA）上的边缘应用服务器（EAS）进行实时高频的数据交互，包括上传高清传感器数据和接收驾驶控制指令。我们将跟随小明，看他如何利用PFCP的强大能力，应对车辆移动、应用迁移等复杂场景，确保自动驾驶业务的极致连续性和可靠性。

深度解析TS 29.244：5.28, 5.32 & 5.33 - 边缘计算增强与数据交付保障

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中，关于“5.28 Downlink data delivery status with UPF buffering”、“5.32 Support of Uplink packets buffering”以及“5.33 Support of enhancement of Edge Computing”的核心章节。

在边缘计算场景中，尤其是当UE为了省电进入非连接状态时，边缘应用（EAS）和网络需要知道发送给UE的数据是被成功缓冲了，还是因为缓冲区满而被丢弃了。这种反馈对于EAS调整其数据发送策略至关重要。**DDDS（Downlink data delivery status）**功能就是为此而生。

这是一个可选功能，需要UPF通过在UP Function Features IE中设置**DDDS标志位**来宣告其能力。

PFCP实现机制

DDDS功能通过扩展Apply Action IE中的标志位来实现对“首个被缓冲包”和“首个被丢弃包”的精细化通知。

  • SMF指令：SMF在配置下行PDR关联的FAR时，在Apply Action IE中进行如下设置：
    • BUFF标志位：设置为“1”，指示UPF对下行数据进行缓冲。
    • BDPN (Buffered Downlink Packet Notification) 标志位：设置为“1”，指示UPF在缓冲第一个下行数据包时，立即向SMF上报一个通知。
    • DDPN (Discarded Downlink Packet Notification) 标志位：设置为“1”，指示UPF在因为缓冲区满而丢弃第一个下行数据包时，也向SMF上报一个通知。
  • UPF行为与上报：
    • 当BDPN被触发时，UPF发送PFCP Session Report Request，其中包含Downlink Data Report IE。该IE内部的DL Data Status IE中的**BUFF标志位**被置“1”，表明数据已被缓冲。
    • 当DDPN被触发时，流程类似，但DL Data Status IE中的**DROP标志位**被置“1”，表明数据已被丢弃。

BDPN vs NOCP：值得注意的是，BDPN与我们之前熟悉的NOCP标志位有所不同。NOCP是为每个QoS流上报一次首包到达，而BDPN则是为每个PDR（即每个业务数据流）上报一次。这提供了更细粒度的业务感知能力。

2. 业务无缝迁移的“保险丝”：上下行数据包缓冲

边缘应用服务器（EAS）的迁移是边缘计算中的常见操作，例如为了负载均衡或跟随用户移动。为了在迁移过程中实现“零丢包”，网络需要在切换的瞬间对数据进行缓冲。

当一个边缘应用从一个旧EAS迁移到一个新EAS时，在路由切换完成前，UE发往旧EAS的数据需要被UPF缓冲起来，待新路径就绪后再发出。

  • 能力宣告：UPF通过在UP Function Features IE中设置**UPBER (Uplink Packet Buffering during EAS Relocation) 标志位**来宣告支持此功能。
  • PFCP实现：
    • SMF指令：SMF向UPF发送PFCP Session Modification Request，更新用于处理该上行业务流的FAR。在Apply Action IE中，SMF将BUFF标志位置为“1”。
    • UPF行为：UPF开始缓冲所有匹配该PDR的上行数据包。
    • 恢复转发：当SMF确认新EAS的路径已经就绪后，它会再次发送PFCP Session Modification Request，将BUFF标志位改回FORW（转发）。UPF随即停止缓冲，并将缓冲区中的数据包发往新的目的地。

2.2 在线计费场景下的上行缓冲 (5.32.2)

上行缓冲也常用于在线计费场景。当用户的信用额度（Quota）耗尽，但又不能立即丢弃数据时（例如，等待用户充值），UPF可以缓冲上行数据。

  • PFCP实现：这依赖于**FAR ID for Quota Action**机制。SMF在URR中配置零配额，并指定一个FAR ID for Quota Action，该FAR的Apply Action即为BUFF。

3. 边缘计算的“瑞士军刀”：PFCP增强功能 (5.33 Support of enhancement of Edge Computing)

5.33章是PFCP协议为支持边缘计算而设计的核心功能集，它提供了一系列工具来解决边缘场景下的路由、寻址和效率问题。

3.1 无缝切换的核心：EAS IP地址与端口替换 (5.33.3)

这是实现边缘应用无感迁移的最关键技术。其核心思想是，对于UE来说，它始终与一个固定的“虚拟”EAS地址通信，而UPF则在后台悄悄地将这个虚拟地址动态地“翻译”成实际EAS的物理地址。

  • 能力宣告：UPF通过**IPREP (IP address and Port number replacement) 标志位**宣告支持此功能。
  • PFCP实现：
    • SMF指令：在EAS迁移后，SMF向UPF发送PFCP Session Modification Request，更新相关的UL和DL FAR。这两条FAR中都包含一个**IP Address and Port Number Replacement IE**。
      • 上行FAR中：该IE包含新EAS的IP地址和端口号。DIPV4/DIPV6/DPN等标志位被设置，指示UPF替换上行包的目的地址/端口。
      • 下行FAR中：该IE包含旧EAS的IP地址和端口号。SIPV4/SIPV6/SPN等标志位被设置，指示UPF替换下行包的源地址/端口。
    • UPF行为：
      • 上行：UE发往虚拟EAS地址的数据包到达UPF，UPF将其目的地址替换为新EAS的真实地址后发出。
      • 下行：新EAS发回的响应包，其源地址是新EAS的真实地址。UPF收到后，将其源地址“伪装”成虚拟EAS的地址，再发往UE。

场景代入：自动驾驶车辆的EAS迁移 测试车辆A正与部署在EAS_1上的应用交互。由于负载原因，运维系统决定将该应用迁移到EAS_2。

  1. 应用迁移完成。SMF得知EAS_2已准备就绪。
  2. SMF向UPF发送PFCP Session Modification Request，更新车辆A的FAR：
    • UL FAR：IP Address and Port Number Replacement IE中填入EAS_2的地址，DIPV4置“1”。
    • DL FAR：IP Address and Port Number Replacement IE中填入EAS_1的地址，SIPV4置“1”。
  3. 此后，车辆A继续向EAS_1的地址发送数据，但UPF已将其默默地重定向到了EAS_2。EAS_2的响应也被UPF“伪装”成来自EAS_1，车辆A的业务完全没有中断。

3.2 智能寻址：DNS流量疏导 (5.33.4, 5.33.7)

为了让UE能够发现最近的边缘应用，网络需要将UE的DNS请求智能地导向一个本地DNS服务器/解析器（L-DNS），由L-DNS返回EAS的本地IP地址。

  • 能力宣告：UPF通过**DNSTS (DNS Traffic Steering) 标志位**宣告支持此功能。
  • PFCP实现：
    • SMF指令：SMF下发一条高优先级的UL PDR，用于捕获特定的DNS查询请求。
    • PDI配置：PDR的PDI中包含一个**DNS Query/Response Filter IE**，该IE可以匹配特定的域名（FQDN）。
    • FAR配置：关联的FAR指示UPF将匹配的DNS请求转发到L-DNS的地址，这可以通过Outer Header Creation（隧道）或IP Address and Port Number Replacement（地址替换）来实现。

在更复杂的归属路由漫游场景（HR-SBO）下，不同漫游用户可能使用相同的私网IP地址，此时仅靠IP地址无法区分DNS请求。PFCP为此提供了更高级的解决方案 [5.33.7]：

  • N6隧道方案 (UN6TU)：为每个用户的DNS流量建立独立的N6隧道，通过N6 Routing Information IE 进行标识和转发。
  • N6地址映射方案 (UMN6IP)：由UPF为每个私网UE地址分配一个唯一的、可路由的Mapped N6 IP Address，并通过IP Address and Port Number Replacement IE中的UMN6RS标志位 进行地址替换。

3.3 实时反馈：直接上报QoS事件 (5.33.5)

对于时延敏感的边缘应用，当QoS发生劣化时，将事件先上报给SMF，再由SMF通知NEF/AF，这个链路太长了。直接上报机制允许UPF绕过SMF，直接向本地的NEF或AF“告警”。

  • 能力宣告：UPF通过**DRQOS (Direct Reporting of QoS monitoring events) 标志位**宣告支持。
  • PFCP实现：SMF在配置SRR（会话上报规则）时，除了包含QoS监控的参数外，还会额外包含一个Direct Reporting Information IE。
    • 该IE中包含一个Event Notification URI，即本地NEF/AF的地址。
    • 如果Reporting Flags IE中的DUPL标志位置“1”，则UPF会同时向NEF/AF和SMF上报。

总结

边缘计算不仅是对网络架构的重塑，也对PFCP协议提出了全新的要求。通过本篇文章的解析，我们看到TS 29.244通过一系列精巧的增强机制，为边缘业务的动态性和可靠性提供了坚实的协议保障：

  • 数据交付状态通知 (DDDS)：通过BDPN/DDPN标志，实现了对UE离线时数据缓冲/丢弃状态的精确反馈，让边缘应用能够感知连接的“可达性”。
  • 上下行缓冲机制：利用BUFF标志和UPBER特性，PFCP为EAS迁移等需要临时中断数据路径的场景提供了“数据保险丝”，确保了业务的零丢包。
  • IP地址与端口替换 (IPREP)：这是实现边缘应用无感迁移的核心武器。通过在UPF层面动态重写报文的源/目的地址，实现了UE与EAS之间的逻辑连接与物理位置的完全解耦。
  • DNS智能疏导 (DNSTS等)：通过DNS Query Filter和更高级的UN6TU/UMN6IP机制，PFCP赋予了网络智能解析DNS的能力，确保用户总能被导向最佳的边缘服务实例。
  • 直接上报 (DRQOS)：通过在SRR中配置Direct Reporting Information，PFCP打通了用户面到应用面的“快速通道”，为时延敏感应用提供了亚秒级的QoS事件反馈。

这些功能共同将UPF从一个简单的IP包转发器，升级为一个具备业务感知、动态路由、地址翻译和实时反馈能力的智能边缘网关，为5G在自动驾驶、工业控制、AR/VR等前沿领域的应用奠定了坚实基础。

FAQ

Q1：边缘应用迁移时，为什么需要对上行和下行流量都进行IP地址替换？ A1：这是为了对UE实现“透明”。上行替换（修改目的地址）是为了将UE发往旧EAS地址的流量，实际重定向到新EAS的地址。下行替换（修改源地址）是为了将新EAS发回的响应包，其源地址“伪装”成旧EAS的地址。这样一来，从UE的角度看，它始终在与同一个IP地址通信，完全感知不到后端的应用实例已经发生了迁移，从而保证了业务的连续性。

Q2：什么是DDDS（下行数据交付状态）？它和常规的DL Buffering有什么不同？ A2：常规的DL Buffering机制（通过BUFF+NOCP标志）只会在缓冲第一个下行包时通知SMF一次。而DDDS功能通过BDPN和DDPN标志，提供了更丰富的状态反馈。它不仅能报告“第一个包被缓冲了”（BDPN），还能在缓冲区满导致丢包时报告“第一个包被丢弃了”（DDPN）。这种“丢包”状态的反馈对于需要可靠交付消息的应用（如即时消息、物联网指令）非常重要。

Q3：在边缘计算场景下，为什么需要本地DNS解析？PFCP如何实现？ A3：因为边缘计算的核心是“就近服务”。如果UE的DNS请求被发送到远端的公共DNS服务器，它很可能会返回一个公网IP地址，导致流量绕行数据中心，失去了边缘计算的低时延优势。本地DNS解析可以将特定的域名（如edge-service.operator.com）解析为部署在本地UPF上的EAS的IP地址。PFCP通过在UL PDR中配置DNS Query Filter IE，让UPF能够识别出针对这些特定域名的DNS请求，并将其从普通上网流量中分离出来，转发给本地的DNS服务器。

Q4：直接上报QoS事件（DRQOS）相比于通过SMF上报，最大的优势是什么？ A4：最大的优势是时延。在传统的模型中，UPF检测到QoS事件（如时延超阈值） → 上报给SMF → SMF再通过N5/NEF接口通知AF。这个链路涉及多个网元，处理时延可能在百毫秒级。对于需要根据网络状况快速调整码率的实时视频或云游戏等边缘应用，这个时延太长了。DRQOS机制允许UPF直接将事件通知给本地的NEF/AF，将反馈时延缩短到毫秒级，实现了真正的实时闭环控制。

Q5：如果一个边缘应用从一个UPF迁移到另一个UPF（例如，用户移动导致PSA变更），PFCP如何保证业务连续性？ A5：这涉及到更复杂的PSA重定位流程。虽然本文未深入该流程，但其核心仍然依赖PFCP。旧SMF会通过PFCP将会话上下文（包括所有PDR/FAR/QER/URR规则、计费信息、以及通过MAC地址上报（5.13.5）等机制学习到的L2信息）传递给新SMF。新SMF再利用这些信息，在新UPF上通过PFCP Session Modification Request重建会话，并可能利用IP Address and Port Number Replacement等技术平滑地切换流量。这个过程确保了用户的业务状态在不同UPF之间能够无缝迁移。😊

关系图谱