51学通信

深度解析TS 29.244：5.12-5.13 挂起恢复与以太网类型PDU会话

26分钟阅读

深度解析TS 29.244：5.12-5.13 挂起/恢复与以太网类型PDU会话

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中，关于“5.12 Suspend and Resume Notification procedures”和“5.13 Ethernet traffic (for 5GC)”的核心章节，旨在为读者提供一个关于挂起恢复流程以及5G支持以太网业务的全景视图。

引言

在本系列的前几篇文章中，我们已经深入探讨了PFCP协议的诸多核心机制，包括策略执行、计费、会话管理、异常处理与资源优化等。这些机制共同构成了5G核心网控制面（CP）与用户面（UP）之间高效协同的基石。我们已经熟悉了网络在处理传统的、基于IP的移动数据业务时的工作模式。

然而，5G的设计初衷远不止于为手机提供更快的上网速度。它的一个重要使命是“连接万物”，并深入到各行各业的生产网络中。这意味着5G网络必须具备承载多样化业务类型的能力，其中就包括对传统局域网技术——**以太网（Ethernet）**的支持。

本篇文章将开启一个新的篇章，我们将首次跳出IP PDU会话的范畴，深入探索TS 29.244规范中关于以太网类型PDU会话的定义。我们将揭示PFCP协议如何进行扩展，以处理二层（L2）的以太网帧，而不仅仅是三层（L3）的IP包。这将涉及到全新的包检测规则、对ARP/ND等二层协议的特殊处理、以及UE MAC地址的学习与上报等一系列 fascinating 的技术细节。

在正式进入以太网的世界之前，我们将首先简要解读5.12章节中一个与传统EPC网络管理相关的流程——挂起与恢复通知（Suspend and Resume Notification），将其作为我们从传统移动业务向更广阔连接场景过渡的桥梁。

为了让这些概念更加生动具体，让我们引入一个新的场景：一家名为“未来制造”的高科技企业，为了实现工厂车间的柔性生产，决定采用5G网络来连接其生产线上的机器人和传感器，构建一个无线的工业局域网。我们将跟随网络工程师小明，看看他是如何利用5G的以太网PDU会话能力，将工厂设备无缝接入公司网络的，以及PFCP协议在其中扮演了怎样不可或缺的角色。

1. 过渡篇：挂起与恢复通知流程 (5.12 Suspend and Resume Notification procedures)

在深入探讨5.13节的以太网业务之前，规范在5.12节描述了一个相对独立且主要与EPC相关的流程。根据我们的解读原则，对于内容较短的章节，我们在此进行简述和过渡。

Upon receipt of a Suspend Notification message, the PGW-C should request the PGW-U to discard packets received for the suspended PDN connection by:

  • setting the DROP flag in the Apply Action IE of the FARs of the corresponding PFCP session; or
  • setting the gate fields in the Gate Status IE of QERs to the value CLOSED. Upon being requested to resume the PDN connection, the PGW-C should re-allow the PGW-U to forward the packets for the PDN connection (unless not permitted for other reasons) by:
  • setting the FORW flag in the Apply Action IE of the FARs of the corresponding PFCP session; or
  • setting the gate fields in the Gate Status IE of QERs to the value OPEN.

这一章节描述了当PGW-C（控制面）收到来自上层（如HSS）的“挂起通知”（例如，由于用户欠费或策略变更）时，它应如何指示PGW-U（用户面）暂停用户的数据转发。规范给出了两种实现方式：

  1. 修改FAR：将该用户PDN连接对应的所有FAR中的Apply Action IE的DROP标志位置为“1”，指示UPF直接丢弃所有数据包。
  2. 修改QER：将对应的QER中的Gate Status IE设置为CLOSED（关闭），通过门控机制来阻止数据包通过。

同样地，当收到“恢复通知”时，PGW-C会执行相反的操作，通过修改FAR将DROP标志位改回FORW（转发），或者修改QER将Gate Status设置为OPEN（打开），从而恢复用户的数据业务。

这个流程本质上是利用我们已经熟知的FAR和QER规则，来实现对整个PDN连接的“一键启停”控制。它体现了PCC架构下策略的集中控制和动态执行能力。现在，让我们从这个传统的移动数据管理场景，迈向更为新颖和复杂的5G以太网世界。

2. 核心篇：以太网流量处理 (5.13 Ethernet traffic (for 5GC))

5G系统的一大革命性进步是原生支持以太网类型的PDU会话。这意味着UE（或通过UE接入的设备）可以直接与5G网络建立一个二层连接，就像将设备插入一个巨大的虚拟以太网交换机一样。这为企业专网延伸、工业物联网、云化PLC等场景打开了大门。

2.1 通用原则 (5.13.1 General)

An SMF and UPF may support Ethernet PDU sessions, as specified in clause 5.6.10.2 of 3GPP TS 23.501. … For a PFCP session set up for an Ethernet PDU session, the UPF shall:

  • detect Ethernet traffic, based on Ethernet Packet Filter(s) provisioned in PDR(s) by the SMF, and process the Ethernet traffic as instructed in the FAR, QER(s) and URR(s) associated to the PDR(s);

规范首先明确了对以太网PDU会话的支持是SMF和UPF的可选功能。当该功能被启用时，SMF和UPF的职责分工与IP PDU会话类似：SMF负责制定规则，UPF负责执行。但执行的对象从IP包变成了以太网帧。

为了识别和处理以太网帧，PFCP引入了全新的“武器”——以太网包过滤器（Ethernet Packet Filter）。

For a PFCP session set up for an Ethernet PDU session, the SMF shall:

  • include the PDN Type IE set to “Ethernet” in the PFCP Session Establishment Request;
  • provision PDR(s), for uplink and/or downlink traffic, with Ethernet Packet Filter(s), based on at least any combination of:
    • Source/destination MAC address;
    • Ethertype as defined in IEEE 802.3;
    • Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-TAG) VID fields as defined in IEEE 802.1Q;
    • Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-TAG) PCP/DEI fields as defined in IEEE 802.1Q;
    • IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6 payload;

SMF在建立以太网PDU会话时，必须在PFCP Session Establishment Request消息中将PDN Type IE设置为“Ethernet”。然后，它下发的PDR中，PDI（包检测信息）将不再使用我们熟悉的SDF Filter（五元组），而是使用Ethernet Packet Filter。这个新的过滤器可以基于纯二层信息来匹配流量，包括：

  • 源/目的MAC地址
  • 以太类型（Ethertype），例如0x0800代表IPv4，0x0806代表ARP
  • VLAN标签，包括C-TAG和S-TAG的VID（VLAN ID）
  • VLAN标签中的优先级和服务等级，即PCP（Priority Code Point）和DEI（Drop Eligible Indicator）字段
  • 内嵌的IP过滤器：如果以太类型是IP，还可以进一步对内部的IP包头进行五元组匹配，实现了L2+L3的混合过滤。

场景代入：“未来制造”的5G工业局域网

“未来制造”的工厂里，一条生产线上的所有设备（机器人、传感器、控制器）都通过一个5G CPE（RG）接入5G网络。这个RG为整个生产线建立了一个以太网类型的PDU会话。这样，这条生产线就如同一个独立的VLAN，无缝地接入了公司的企业内网。

  • 网络工程师小明 的任务是为这个“5G VLAN”配置网络策略。
  • SMF 会为这个PDU会话下发一系列PDR。例如，为了区分控制信令和数据上报，小明可能会配置：
    • 一条PDR，其Ethernet Packet Filter匹配Ethertype为PROFINET（一种工业以太网协议）的流量，并关联一个高优先级的QER。
    • 另一条PDR，其Ethernet Packet Filter匹配源MAC地址为某个特定传感器、Ethertype为IPv4的流量，并关联一个用于数据统计的URR。

2.2 二层地址发现：ARP与IPv6邻居发现的处理

在传统的以太网中，设备通过广播ARP（地址解析协议）或IPv6邻居请求（Neighbor Solicitation）来发现目标设备的MAC地址。然而，5G核心网并非一个原生的广播域，这些二层广播消息无法在网络中自由泛滥。因此，PFCP必须提供特殊的处理机制。

2.2.1 由SMF响应 (5.13.2)

If the SMF requests the UPF to forward all Address Resolution Protocol (ARP) … or IPv6 Neighbour Solicitation … traffic to the SMF to respond to the ARP or IPv6 Neighbour Solicitation based on the local cache information for Ethernet PDU sessions, the SMF shall provision a PDR in the UPF with:

  • an Ethernet Packet Filter containing EtherType 2054 (hexadecimal 0x0806) and associate the PDR with a FAR, for forwarding ARP traffic to the SMF; and/or
  • a PDI containing an application ID such that the identified application ID matches against EtherType 34525 (hexadecimal 0x86DD), IPv6 Next Header type as 58 and ICMP Field Type as 135 and associate the PDR with a FAR, for forwarding IPv6 Neighbour Solicitation traffic to the SMF.

在这种模式下，SMF扮演了“ARP服务器”的角色。它指示UPF将所有的ARP/NS请求都“上交”给自己来处理。

  • PFCP实现：SMF下发一条高优先级的PDR，其Ethernet Packet Filter精确匹配ARP的Ethertype（0x0806），或者通过Application ID匹配IPv6 NS的报文特征。
  • 关键动作：与这条PDR关联的FAR，其Destination Interface被设置为“CP-function”，指示UPF将匹配到的ARP/NS请求通过N4-U隧道封装后发往SMF。
  • SMF处理：SMF收到请求后，查询自己的信息（例如，从UDR获取的企业内网设备地址信息），然后构造一个ARP/NS响应，再通过N4-U隧道发回给UPF，由UPF转发给发起请求的设备。

场景代入：工厂里的一个机器人需要与公司数据中心的服务器通信，它发出ARP请求来查询服务器的MAC地址。

  1. ARP请求到达UPF，匹配了SMF下发的“ARP上交”PDR。
  2. UPF将ARP请求封装在GTP-U隧道中，通过N4-U接口发往SMF。
  3. SMF查询后得知服务器的MAC地址，构造ARP响应包，再通过N4-U发回给UPF。
  4. UPF解封装后，将ARP响应发回给机器人，地址发现完成。

2.2.2 由UPF响应 (5.13.3)

将所有ARP/NS请求都上报给SMF会增加控制面的负担。一种更优化的方式是授权UPF在本地进行代理响应。

If the SMF requests the UPF to respond to Address Resolution Protocol (ARP) … or IPv6 Neighbour Solicitation … based on the local cache information for an Ethernet PDU session, the SMF shall provision a PDR in the UPF with:

  • an Ethernet Packet Filter containing EtherType 2054 … and associate the PDR with a FAR that has the ARP bit in Proxying IE of the Forwarding Parameters IE set to “1”; or
  • a PDI containing an application ID … and associate the PDR with a FAR that has the INS bit in Proxying IE of the Forwarding Parameters IE set to “1”.
  • PFCP实现：SMF下发的PDR与前一种方式类似，但关联的FAR不再是转发给CP，而是包含一个特殊的Proxying IE，并将其中的ARP或INS（IPv6 Neighbor Solicitation）标志位置为“1”。
  • UPF处理：UPF收到这条指令后，对于匹配到的ARP/NS请求，它会尝试在自己的本地缓存中查找目标IP对应的MAC地址。如果找到，就直接构造响应包发回给源设备；如果找不到，可能会丢弃或执行其他默认策略。UPF的缓存通常是通过学习流经它的上行流量的源MAC地址来建立的。

场景代入：生产线上的一个传感器需要与旁边的另一个传感器通信。

  1. 传感器A发出ARP请求，查询传感器B的MAC地址。
  2. 请求到达UPF，匹配了SMF下发的“ARP代理”PDR。
  3. UPF在本地缓存中查找。由于传感器B之前也上报过数据，UPF已经学习并缓存了它的IP与MAC地址的映射关系。
  4. UPF直接构造ARP响应，告诉传感器A“传感器B的MAC地址是XXX”，并将响应发回。整个过程无需SMF介入，效率极高。

2.3 高效配置：双向以太网过滤器 (5.13.4 Bidirectional Ethernet Filters)

为了简化配置，PFCP也为以太网过滤器引入了双向（Bidirectional）机制，其原理与IP SDF Filter类似。

The CP function may provision bidirectional Ethernet Filters in the UP function … i.e. Ethernet filters that may be associated to both uplink and downlink PDRs of a same PFCP session, as follows:

  • when provisioning a bidirectional Ethernet Filter the first time for a PFCP session, the CP function shall set the BIDE (Bidirectional Ethernet Filter) flag in the Ethernet Filter Properties IE and provision the Ethernet filter definition together with a Ethernet Filter ID …
  • the CP function may then provision a PDR for the same PFCP session but the opposite direction, by provisioning the Ethernet Filter ID in the Ethernet filter ID field of the PDI, without provisioning again the Ethernet Filter …
  • PFCP实现：SMF在首次定义一个过滤器时，在其Ethernet Filter Properties IE中设置BIDE标志位，并为其分配一个在会话内唯一的Ethernet Filter ID。
  • 复用：当需要为相反方向的流量创建PDR时，SMF无需再重复定义整个过滤器，只需在PDI中填入这个Ethernet Filter ID即可。
  • UPF行为：UPF在处理带有Ethernet Filter ID的PDR时，会自动根据PDR的Source Interface（是Access还是Core）来决定是否需要交换过滤器中的源/目的MAC地址和IP地址。

2.4 感知能力：UE MAC地址上报 (5.13.5 Reporting of UE MAC addresses to the SMF)

核心网需要知道RG背后有哪些活跃的设备，以便进行管理和策略制定。为此，PFCP定义了MAC地址上报机制。

In a PFCP Session Establishment Request or a PFCP Session Modification Request, the SMF may request the UPF to start or stop … reporting the UE MAC addresses, i.e. the different MAC (Ethernet) addresses used as source address of frames sent UL by the UE in a PDU Session, by:

  • creating a URR requesting the UPF to report Ethernet traffic information (i.e. with the Reporting Trigger set to ‘MAC Addresses Reporting’); and
  • associating the URR to the PDR provisioned for the UL traffic of the PDU session.
  • PFCP实现：SMF创建一个URR，其Reporting Trigger中包含**MACAR (MAC Addresses Reporting)**标志位，然后将这个URR关联到该PDU会话的上行PDR上。
  • UPF行为：UPF在收到该指令后，会监控上行流量的源MAC地址。
    • 当一个新的MAC地址首次出现时，UPF会向SMF发送PFCP Session Report Request，在Usage Report的Ethernet Traffic Information IE中的MAC Addresses Detected字段里上报这个新地址。
    • 如果SMF还在URR中配置了Ethernet Inactivity Timer，当UPF在指定时间内没有再看到某个MAC地址的流量时，它会认为该设备已离线，并上报MAC Addresses Removed事件。

场景代入：小明临时将一台测试设备接入了工厂的5G网络。

  1. 测试设备一通电，发出第一帧数据。
  2. UPF收到数据后，发现其源MAC地址是一个从未见过的地址。
  3. 由于SMF配置了MACAR触发的URR，UPF立即向SMF上报，报告检测到一个新的MAC地址。
  4. SMF收到报告后，就可以执行相应的策略，例如，将其计入资产清单，或检查其是否在允许接入的设备白名单中。

总结

本篇文章带领我们走出了传统的IP世界，深入探索了5G网络支持二层以太网业务的核心机制。我们了解到，TS 29.244通过对PFCP协议的精巧扩展，成功地将PCC架构的控制能力从L3延伸到了L2：

  • 以太网包过滤器 (Ethernet Packet Filter)：作为核心的识别工具，它使得UPF能够基于MAC地址、VLAN标签、Ethertype等二层信息对流量进行精细分类，这是实现以太网业务策略的基础。
  • ARP/ND代理与转发：通过在FAR中配置Proxying IE或设置Destination Interface为CP-function，PFCP解决了在非广播的5G网络中进行二层地址发现的难题，实现了UPF本地代理和SMF集中处理两种灵活的模式。
  • MAC地址上报：通过URR中的MACAR触发器，赋予了核心网“感知”CPE背后设备动态的能力，使得SMF能够实时了解到哪些L2设备正在接入网络，为安全和策略管理提供了关键输入。
  • 双向过滤器与锚点重定位：通过BIDE标志位和Ethernet Context Information IE，PFCP进一步优化了配置效率，并为以太网PDU会话的移动性（锚点重定位）提供了必要的L2上下文传递机制，保障了业务的连续性。

这些机制的组合，使得5G网络能够真正扮演起一个“虚拟交换机”的角色，将企业和家庭的局域网安全、高效、灵活地延伸到任何有5G信号的地方，为工业4.0、企业上云、智能家居等众多创新应用场景铺平了道路。

FAQ

Q1：从PFCP协议的角度看，处理以太网PDU会话和IP PDU会话最根本的区别是什么？ A1：最根本的区别在于包检测信息（PDI）的构成。对于IP PDU会话，PDI主要使用基于三/四层信息的SDF Filter（IP五元组）来识别业务流。而对于以太网PDU会话，PDI则使用基于二层信息的Ethernet Packet Filter，其匹配字段包括MAC地址、VLAN标签、Ethertype等。这是两种完全不同的流量识别维度。

Q2：为什么在以太网PDU会话中，需要对ARP和IPv6邻居发现消息进行特殊处理？ A2：因为ARP和邻居发现都依赖于二层广播/组播来工作，而5G核心网本身并不是一个原生的二层广播网络。如果不加处理，设备发出的ARP请求广播将无法到达同一“虚拟局域网”内的其他设备。因此，PFCP必须定义机制让UPF能够“捕获”这些广播/组播请求，并通过UPF本地代理响应或转发给SMF集中处理的方式，来模拟传统以太网的地址发现行为。

Q3：SMF如何知道一台新电脑接入了某个由5G CPE提供网络服务的家庭局域网？ A3：通过MAC地址上报机制。SMF可以在为该家庭CPE建立PFCP会话时，配置一条URR，并将其Reporting Trigger设置为MACAR（MAC Addresses Reporting）。当新电脑发出第一个上行数据包时，UPF会检测到一个新的源MAC地址，这个事件会触发URR，UPF随即向SMF发送一份包含MAC Addresses Detected信息的用量报告，从而通知了SMF新设备的存在。

Q4：双向以太网过滤器（Bidirectional Ethernet Filter）的好处是什么？ A4：主要好处是提升信令效率和简化配置。对于一个需要双向控制的业务流（例如，在某台设备和服务器之间），传统方式需要定义两条PDR，分别用于上行和下行，并且每条PDR都包含一个完整的Ethernet Packet Filter（其中源/目的MAC地址相反）。而使用双向过滤器，SMF只需在下发第一条PDR时定义完整的过滤器、设置BIDE标志并分配一个Ethernet Filter ID。在下发另一方向的PDR时，只需引用这个ID即可，无需重复发送冗长的过滤器定义，UPF会自动根据流量方向应用正确的匹配规则。

Q5：在以太网PDU会话的锚点重定位过程中，PFCP扮演了什么关键角色？ A5：PFCP扮演了传递二层上下文的关键角色。以太网转发依赖于MAC地址学习。当PDU会话的锚点UPF从一个旧的UPF切换到一个新的UPF时，新UPF对CPE背后的设备MAC地址一无所知，会导致下行流量中断。为了解决这个问题，SMF在向新UPF发送PFCP Session Modification Request时，会携带一个Ethernet Context Information IE，其中包含了从旧UPF处得知的、所有已学习到的MAC地址列表。新UPF可以利用这些信息预先填充自己的转发表，并可能通过发送免费ARP等方式更新数据网络中的交换机，从而实现快速、平滑的切换。😊

关系图谱