基于 3GPP TS 23.548 V19.5.0(2026-01)§6.3、TS 23.502 §4.3.5.1、TS 29.244 N4 接口的深度机制解读
在MEC(多接入边缘计算)架构中,3GPP自Rel-17起通过TS 23.548把"5G系统对边缘计算的增强支持"正式标准化,到Rel-19(V19.5.0)已经形成完整的发现、分流与重定位体系。但真正困扰协议开发工程师的,从来不是"如何把流量导到边缘",而是当终端移动导致最优边缘应用服务器(EAS)发生变化时,如何在不中断业务的前提下完成边缘重定位——这就是TS 23.548 §6.3定义的 Edge Relocation 过程。
举一个最典型的场景:一辆搭载了MEC辅助驾驶的车辆,从基站gNB-A覆盖区驶入gNB-B覆盖区。在gNB-A下,SMF为其选择了本地PSA(PDU会话锚点)UPF1,并通过EASDF发现流程解析到边缘EAS-1的IP地址。当车辆驶入gNB-B区域后,继续连接EAS-1会导致端到端时延急剧上升(用户面迂回到原边缘站点)。此时网络必须做出决策:是只换一个更近的EAS(EAS重发现 / EAS IP Replacement),还是连PDU会话锚点一起搬到更近的UPF2(PSA Change)。这两条路径的信令复杂度、对UE的可见性、对应用连续性的影响截然不同,而它们的设计意图恰恰是本文要拆解的核心。
本文聚焦TS 23.548 §6.3(Edge Relocation)与TS 23.502 §4.3.5.1(PSA Change)的具体信令机制,逐步拆解触发条件、决策逻辑、N4会话建立、EASDF DNS处理规则更新、以及SSC模式3下的全链时序。
在边缘计算场景下,UPF被划分为三种功能角色(TS 23.501 §5.8.2、§5.6.4):
一个PDU会话可以同时挂接多个PSA(通过UL CL + Branching Point),这是实现"主锚点不变、本地分流"的基础,也是EAS IP Replacement能保持锚点不变的前提。
TS 23.548 §6.2把边缘应用服务器发现拆成三个相关但独立的过程:
| 过程 | 定义(TS 23.548) | 是否改变PSA | 是否改变UE已解析的EAS IP |
|---|---|---|---|
| EAS Discovery(发现) | UE首次通过EASDF解析某FQDN得到EAS IP | 否 | 首次获取 |
| EAS Re-discovery(重发现) | 当已发现的EAS不再最优时,UE再次发起DNS解析获取新的EAS IP | 可不变(若仅DNS层) | 是(新IP) |
| EAS IP Replacement(IP替换,§6.3.3) | EASDF依据SMF下发的DNS Message Handling Rule,把DNS响应里的EAS IP替换为更优的本地EAS IP | 否(锚点不变) | 是(网络侧替换) |
关键设计意图:EAS IP Replacement让"重定位"在不触碰PDU会话锚点的前提下完成。只要旧的L-PSA仍能可达目标EAS,网络只需在DNS层面"偷梁换柱",UE无需感知锚点变化,应用连续性最好。只有当旧PSA到新EAS的用户面路径已不可接受时,才升级为PSA Change。
TS 23.501 §5.6.9定义了三种会话与业务连续性(SSC)模式,它们直接决定了PSA Change的信令形态:
需要特别说明的是,在UL CL + 多PSA架构下,还有一种"PSA Change without SSC mode 3 / without UE involvement"(TS 23.548 §6.3、TS 23.502 §4.3.5.1),即SMF在多个L-PSA之间切换而UE完全不感知,本文第四节主流程即基于此。
SMF并非被动等待,而是依据多种触发条件评估是否启动重定位。TS 23.548明确了几类典型触发:
下面的状态机描述了SMF在收到触发后的决策路径:
stateDiagram-v2
[*] --> 已锚定: PDU会话建立于旧PSA<br/>EAS已发现
已锚定 --> 评估触发: 触发条件到达<br/>(UE移动/时延阈值/AF请求)
评估触发 --> 轻量重定位: 旧PSA仍可达新EAS<br/>仅需EAS IP替换
评估触发 --> PSA重锚点: 旧PSA距新EAS过远<br/>(SSC mode3 / ULCL)
评估触发 --> 已锚定: 评估后无需重定位(早释)
轻量重定位 --> EAS重发现: 更新DNS Message Handling Rule
PSA重锚点 --> 新N4建立: 选新PSA、建N4会话
新N4建立 --> EAS重发现: 指示UE重新DNS解析
EAS重发现 --> 应用迁移: UE获取新EAS IP
应用迁移 --> 已锚定: 旧PSA/N4释放<br/>重定位完成
这是本文最核心的部分。以"车辆从gNB-A驶入gNB-B,需把锚点从中央PSA(UPF1)搬到本地PSA(UPF2)"为例,完整信令流程如下。
sequenceDiagram
participant UE
participant RAN as gNB-B(新)
participant AMF
participant SMF
participant EASDF
participant OldPSA as UPF1(旧PSA/集中)
participant NewPSA as UPF2(新L-PSA)
participant AF
participant NEF
participant PCF
Note over UE,NewPSA: ===== 触发阶段:UE移动,旧PSA时延越限 =====
AF->>NEF: Nnef 影响: 订阅UE移动事件 / 路由要求
NEF->>PCF: Npcf_PolicyAuthorization (EAS部署/时延阈值)
PCF->>SMF: SM Policy Assoc Modification(触发PSA Change)
OldPSa-->>SMF: N4 Session Report(UE位置变化/时延上报)
Note over SMF: SMF决策: 执行PSA Change(SSC mode3)<br/>选择新L-PSA=UPF2
Note over UE,NewPSA: ===== 阶段1: 建立新PSA的N4会话 =====
SMF->>NewPSA: N4 PFCP Session Establishment Request
Note right of NewPSA: Create PDR(过滤UE IP)<br/>Create FAR(转发至EAS2/DN)<br/>Create QER(QFI/MBR)<br/>F-TEID(新N3/N9隧道)
NewPSA-->>SMF: N4 PFCP Session Establishment Resp(F-TEID)
Note over UE,NewPSA: ===== 阶段2: 用户面切换到新PSA =====
SMF->>AMF: Namf_Comm N1N2MsgTransfer<br/>(N2 SM Info:新PSA N3隧道)<br/>(N1: PDU会话修改/重建)
AMF->>RAN: N2 PDU Session Resource Setup/Modify
RAN->>UE: RRC Reconfig + NAS PDU Mod Cmd
UE-->>RAN: RRC Reconfig Complete
RAN->>NewPSA: N3 用户面隧道(新)
Note over UE,NewPSA: ===== 阶段3: EAS重发现(DNS层) =====
SMF->>EASDF: 更新 DNS Message Handling Rule(指向EAS2)
UE->>EASDF: DNS Query(FQDN) 经NewPSA转发
EASDF->>EASDF: 匹配Handling Rule<br/>(可选EAS IP Replacement)
EASDF-->>UE: DNS Response(新EAS2 IP)
UE->>NewPSA: 应用连接 EAS2
Note over UE: 应用层上下文迁移(旧EAS→新EAS)
Note over UE,NewPSA: ===== 阶段4: 释放旧PSA =====
SMF->>OldPSA: N4 PFCP Session Modification/Deletion
SMF->>UE: 释放旧锚点PDU会话(若SSC mode3重建)
触发阶段(步骤1-3)——AF影响经NEF/PCF传导到SMF
Npcf_PolicyAuthorization(TS 29.514)生成策略。SM Policy Association Modification(TS 29.512 Npcf_SMPolicyControl)把"PSA Change指示、目标DNAI、路由约束"下发给SMF。DNAI(Data Network Access Identifier)是这里的核心参数——它标识UE应接入的数据网络接入点,SMF据此选择新PSA。N4 Session Report(TS 29.244 §7.7)上报UE接入位置变化或时延测量,作为本地决策依据。阶段1(步骤5-6)——建立新L-PSA的N4会话
SMF向UPF2发送PFCP Session Establishment Request(TS 29.244 §7.5),这是整个PSA Change最重的信令。其IE树结构如下:
graph TD
A["N4 PFCP Session Establishment Request<br/>(SMF→UPF2, TS 29.244 §7.5)"] --> B1["Create PDR (包检测规则)"]
A --> B2["Create FAR (转发规则)"]
A --> B3["Create QER (QoS执行)"]
A --> B4["Create URR (用量上报, 可选)"]
A --> B5["F-TEID(CP) / UE IP Address"]
B1 --> C1["PDI 包检测信息"]
C1 --> D1["Source Interface (Core/Access)"]
C1 --> D2["UE IP Address(新前缀过滤)"]
C1 --> D3["F-TEID(CP)"]
B1 --> C2["Precedence(检测优先级)"]
B1 --> C3["Outer Header Removal"]
B2 --> E1["Action = FORWARD"]
B2 --> E2["Destination Interface(至EAS2/DN)"]
B2 --> E3["Outer Header Creation(N3/N9 TEID)"]
B3 --> F1["QFI"]
B3 --> F2["Gate Status = Open"]
B3 --> F3["MBR / GBR"]
B4 --> G1["Measurement Method"]
B4 --> G2["Reporting Triggers<br/>(UE位置/时延阈值)"]
其中需要特别关注:
- Create PDR / PDI:新PSA要能识别属于该UE的报文。由于SSC mode 3会分配新IP前缀,PDI中的UE IP Address过滤规则必须用新前缀,否则上下行数据无法正确匹配。
- Create FAR:Destination Interface指向边缘DN(即EAS2所在网络),Outer Header Creation承载N3/N9隧道的TEID。
- Create URR:配置Reporting Triggers为"UE位置变化/时延阈值",这是下一轮重定位的触发数据来源——形成闭环。
UPF2回PFCP Session Establishment Response,携带分配的F-TEID,用于N3/N9隧道封装。
阶段2(步骤8-12)——用户面切换到新PSA
Namf_Communication_N1N2MessageTransfer(TS 29.518)把两类信息交给AMF:N2 SM Info(含新PSA的N3隧道地址+TEID)与N1 SM容器(PDU会话修改命令,若SSC mode 3则可能指示UE重建会话并获新IP)。PDU Session Resource Setup/Modify Request(TS 38.413),RAN经RRC Reconfiguration把NAS消息带给UE,并建立到UPF2的新N3隧道。阶段3(步骤14-18)——EAS重发现(DNS层)
这是PSA Change与EAS重发现协同的关键点: - SMF更新EASDF上的DNS Message Handling Rule(TS 23.548 §6.2.3.2.2),把FQDN→EAS IP的解析指向新边缘站点的EAS2。规则可包含"EAS IP Replacement"指示,即EASDF把DNS响应中的EAS IP直接替换为本地最优EAS2的IP。 - UE(应用层)重新发起DNS Query,报文经新PSA(UPF2)转发到EASDF;EASDF匹配Handling Rule后返回新EAS2 IP。 - UE连接到EAS2,应用层完成上下文迁移(这部分超出3GPP范围,由ETSI MEC/应用自身处理,TS 23.548 §6.3.2/§6.3.4对"Edge Relocation involving AF change"有约束)。
阶段4(步骤20-21)——释放旧PSA
确认新PSA与EAS2连通后,SMF向UPF1发PFCP Session Modification/Deletion Request拆除旧N4会话,并按SSC模式释放旧PDU会话分支。至此Edge Relocation完成。
为什么3GPP要设计"EAS IP Replacement"和"PSA Change"两条路径?核心是用最小信令代价换取应用连续性。
| 对比维度 | EAS IP Replacement(§6.3.3) | PSA Change(§4.3.5.1, SSC mode 3) |
|---|---|---|
| 锚点变化 | 不变(仅DNS层) | 变(搬到新UPF) |
| UE IP地址 | 不变 | 变(新前缀) |
| 涉及信令接口 | 仅SMF↔EASDF(DNS Handling Rule更新)+ UE DNS | N4建链+N2/N1+DNS,全链 |
| 信令开销 | 低 | 高 |
| 应用连续性 | 最好(无IP变更、无会话重建) | 需应用层适配IP变更 |
| 适用场景 | 旧PSA仍可达新EAS(如UL CL下换本地EAS) | 旧PSA距新EAS过远,必须重锚点 |
| 禁用机制 | SMF可下发"Disable EAS IP Replacement"(§6.3.3.1.3) | 受SSC模式约束 |
设计意图总结:网络总是优先尝试DNS层的轻量重定位;只有用户面路径质量无法接受时,才升级到重锚点。 这种分层降级策略,把昂贵的N4/N2信令限制在真正必要的场景,是边缘重定位能大规模商用的工程前提。
| 信令消息 | 接口/规范 | 关键IE | 含义与作用 |
|---|---|---|---|
| N4 PFCP Session Estab Req | N4 / TS 29.244 §7.5 | Create PDR.PDI.UE IP Address | 用新IP前缀过滤UE报文 |
| N4 PFCP Session Estab Req | N4 / TS 29.244 | Create FAR.Outer Header Creation | 承载N3/N9隧道TEID与对端地址 |
| N4 PFCP Session Estab Req | N4 / TS 29.244 | Create QER.QFI/MBR | 在新PSA上重装QoS执行 |
| N4 Session Report | N4 / TS 29.244 §7.7 | Reporting Triggers | UE位置/时延上报,触发下一轮重定位 |
| SM Policy Assoc Modification | N7 / TS 29.512 | DNAI、路由约束 | 指示目标数据网络接入点 |
| Npcf_PolicyAuthorization | N5/NEF / TS 29.514 | EAS部署信息、时延阈值 | AF对路由的影响 |
| DNS Message Handling Rule | SMF↔EASDF / TS 23.548 §6.2.3.2.2 | FQDN匹配、EAS IP Replacement指示 | 控制DNS响应指向新EAS |
| NGAP PDU Session Resource Setup | N2 / TS 38.413 | UL NG-U UP TNL Info | 新PSA的N3隧道地址+TEID |
Q1: EAS重发现(Re-discovery)和EAS IP Replacement有什么区别? A: EAS重发现是UE主动重新发起DNS查询得到新EAS IP的过程;而EAS IP Replacement是EASDF依据SMF下发的Handling Rule,在DNS响应中网络侧替换EAS IP,UE可能并不感知这是一次"重定位"。后者锚点完全不变,开销最小。
Q2: 为什么PSA Change一定要配SSC mode 3,而不是mode 2? A: SSC mode 2在网络释放旧PSA后会中断会话,UE需重建,业务必断;SSC mode 3允许先建新PSA再释放旧的,实现无中断切换。边缘重定位追求业务连续性,因此强制要求SSC mode 3(或在UL CL架构下走"无UE参与"的PSA Change)。
Q3: DNAI在Edge Relocation中起什么作用? A: DNAI(Data Network Access Identifier)标识UE应接入的数据网络接入点。AF/PCF通过DNAI告诉SMF"目标边缘站点在哪",SMF据此选择新PSA。DNAI是AF影响与SMF执行之间的"路由坐标"。
Q4: 抓包时怎么区分这是一次PSA Change还是普通PDU会话修改?
A: 看N4面:出现对新UPF的PFCP Session Establishment、同时对旧UPF的PFCP Session Deletion,且N7面有DNAI Changed指示——三联征即PSA Change的指纹。普通修改通常只是PFCP Session Modification。
Q5: Edge Relocation完成后,应用层上下文如何从旧EAS迁移到新EAS? A: 这部分超出3GPP范围,由ETSI MEC架构(如MEC应用迁移、状态同步)和应用自身实现。TS 23.548 §6.3.2/§6.3.4定义了"Edge Relocation involving AF change"的信令约束(AF如何告知网络),但具体的应用状态迁移是MEC平台与应用的责任。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护,聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
