在5G MEC(多接入边缘计算)场景中,应用功能(AF)需要动态影响用户面流量路由,将业务流引导至最优UPF锚点。当UE移动或应用需求变化时,AF通过NEF向SMF注入路由策略,触发UPF重选和N4会话修改,实现边缘计算节点的动态关联。
这一机制定义在 3GPP TS 23.502 Section 4.3.6 "Traffic Routing Influence by AF",是MEC场景下流量本地化的核心信令流程。与静态配置的UL CL/BP方案不同,AF Traffic Influence允许第三方AF通过标准化SBI接口(Nnef_TrafficInfluence)动态请求路由变更,无需人工干预。
| 网元 | 角色 | 关键接口 |
|---|---|---|
| AF | 第三方应用功能,发起路由影响请求 | Nnef(北向API) |
| NEF | 网络开放功能,AF请求鉴权与映射 | Nnef → Npcf/Nsmf |
| PCF | 策略控制,生成PCC规则下发SMF | Npcf → Nsmf(N7) |
| SMF | 会话管理,执行UPF选择与N4修改 | N4(SMF↔UPF) |
| UPF | 用户面功能,执行流量转发规则 | N4规则注入 |
| UDM | 订阅数据存储,提供AF路由策略签约 | Nudm(Nudr) |
以下是完整的AF请求影响UPF路由的信令流程,覆盖从AF发起到UPF重选完成的全链路:
sequenceDiagram
participant AF as AF(应用功能)
participant NEF as NEF
participant UDM as UDM
participant PCF as PCF
participant SMF as SMF
participant UPF_old as UPF(旧锚点)
participant UPF_new as UPF(新锚点/MEC)
participant UE as UE
Note over AF,UE: 阶段1: AF路由影响请求创建
AF->>NEF: Nnef_TrafficInfluence_Create<br/>{AF-Router-Identity, TrafficDesc,<br/>RoutingReq, UPPathChangeNotif}
NEF->>NEF: 鉴权AF请求<br/>检查AF是否授权
NEF->>UDM: Nudm_SDM_Get<br/>查询UE路由签约数据
UDM-->>NEF: {RoutingPermission, AllowedRoutes}
alt AF直接请求模式
NEF->>PCF: Npcf_PolicyAuthorization_Create<br/>{TrafficDesc, RoutingReq,<br/>AF-Router-Identity}
PCF->>PCF: 生成/更新PCC规则<br/>映射路由需求到QoS参数
PCF-->>NEF: 201 Created {PolicyDecision}
else AF绕过PCF模式(NEF直接→SMF)
Note over NEF,SMF: 仅当运营商策略允许
NEF->>SMF: Nsmf_TrafficInfluence_Notify<br/>{RoutingReq, TrafficDesc}
end
NEF-->>AF: 201 Created<br/>{ResourceId, NotificationURI}
Note over AF,UE: 阶段2: SMF执行UPF重选
PCF->>SMF: Npcf_SMPolicyControl_Update<br/>{PCC-Rule-Update,<br/>RoutingRequirement}
SMF->>SMF: 评估当前UPF拓扑<br/>决定是否需要UPF重选
alt 需要UPF重选(新锚点)
SMF->>UPF_new: N4 Session Establishment<br/>{FAR, PDR, QER, URR<br/>新锚点规则注入}
UPF_new-->>SMF: N4 Session Establishment Response
SMF->>UPF_old: N4 Session Modification<br/>{更新FAR/PDR,<br/>流量重定向至新锚点}
UPF_old-->>SMF: N4 Session Modification Response
Note over SMF,UE: 可选: 插入UL CL/BP分流
SMF->>UPF_new: N4 Session Modification<br/>{UL CL规则注入}
else 仅修改N4规则(同UPF)
SMF->>UPF_old: N4 Session Modification<br/>{更新PDR/FAR,<br/>新增/修改路由规则}
UPF_old-->>SMF: N4 Session Modification Response
end
Note over AF,UE: 阶段3: UP Path变更通知(可选)
alt UPPathChangeNotif=true
SMF->>PCF: Npcf_SMPolicyControl_Update<br/>{UPPathChange notification}
PCF->>NEF: Nnef_TrafficInfluence_Notify<br/>{UPPathChange, NewUPF-Info}
NEF->>AF: Nnef_TrafficInfluence_Notify<br/>{UPPathChange, NewUPF-Info,<br/>SourceIP-Addr}
end
| IE名称 | 类型 | 必选/可选 | 说明 |
|---|---|---|---|
| afAppId | string | 可选 | AF应用标识,标识哪个MEC应用发起请求 |
| afRoutReq | AfRoutReq | 必选 | AF路由需求,包含目标UPF/路由规则 |
| trafficDesc | TrafficDesc | 必选 | 流量描述符,匹配业务流(IP五元组/DNN/S-NSSAI) |
| upPathChgNotif | UpPathChgNotif | 可选 | UP路径变更通知要求,AF请求回调通知 |
| appId | string | 可选 | 应用标识(运营商分配) |
| snssai | Snssai | 可选 | 网络切片标识 |
| dnn | Dnn | 可选 | 数据网络名称 |
| externalGroupId | string | 可选 | 外部组标识(群组路由) |
| anyUeInd | boolean | 可选 | 指示是否对所有UE生效 |
| subscriptionId | string | 可选 | 订阅标识(NEF内部关联) |
| supportedFeatures | SupportedFeatures | 可选 | 支持的特性集(Feature bitmask) |
| 子IE | 类型 | 说明 |
|---|---|---|
| appReloc | boolean | 应用是否支持重定位(true=可迁移至新UPF) |
| routeToLocs | array(RouteToLocation) | 路由目标位置列表(DNAI+UPF地址) |
| spatialValidCon | SpatialValidCon | 空间有效性条件(UE在某区域时生效) |
| temporalValidCon | TemporalValidCon | 时间有效性条件(某时间段内生效) |
| upPathChgNotif | UpPathChgNotif | UP路径变更通知订阅 |
| addrPreserInd | boolean | 地址保留指示(重选后是否保留UE IP) |
| simpArrivalInd | boolean | 简单到达指示(数据面"推"模式触发) |
| simpDepartInd | boolean | 简单离开指示 |
graph TB
TD[TrafficDesc 流量描述符]
TD --> IP5[IP五元组<br/>SrcAddr + DstAddr<br/>SrcPort + DstPort + Protocol]
TD --> DNN[DNN匹配<br/>特定数据网络名称]
TD --> SNSSAI[S-NSSAI匹配<br/>特定网络切片]
TD --> MAC[MAC地址匹配<br/>以太网PDU会话]
TD --> DNAD[DNAI匹配<br/>数据网络接入标识]
IP5 --> MATCH{流量匹配<br/>逻辑}
DNN --> MATCH
SNSSAI --> MATCH
MAC --> MATCH
DNAD --> MATCH
MATCH --> RULE[命中→应用路由规则<br/>未命中→默认路由]
当SMF收到PCF下发的路由影响PCC规则后,执行以下判断(TS 23.501 Section 6.3.3.2):
flowchart TD
START[SMF收到PCC路由规则] --> EVAL{评估当前<br/>UPF拓扑位置}
EVAL -->|目标DNAI可达<br/>且当前UPF覆盖| SAME[同UPF执行<br/>仅更新N4规则]
EVAL -->|目标DNAI不可达<br/>需新锚点| NEW[触发UPF重选]
EVAL -->|多DNAI目标<br/>需分流| SPLIT[插入UL CL<br/>+新增BP锚点]
SAME --> N4MOD[N4 Session Modification<br/>更新PDR/FAR/QER]
N4MOD --> DONE[完成]
NEW --> SELECT[SMF选择新UPF<br/>基于DNAI+拓扑+负载]
SELECT --> N4EST[N4 Session Establishment<br/>向新UPF注入规则]
N4EST --> N4MOD2[N4 Modification<br/>旧UPF更新转发规则]
N4MOD2 --> ADDR{addrPreserInd?}
ADDR -->|true: 保留IP| BP[插入Branching Point<br/>保持IP连续性]
ADDR -->|false: 可换IP| DIRECT[直接切换锚点]
BP --> DONE2[完成]
DIRECT --> DONE2
SPLIT --> ULCL[建立UL CL会话<br/>N4 Session Establishment]
ULCL --> PSA1[PSA1(原锚点)<br/>保持Internet路由]
ULCL --> PSA2[PSA2(新锚点/MEC)<br/>本地分流路由]
PSA1 --> DONE3[完成]
PSA2 --> DONE3
当SMF决定重选UPF时,需要在新的UPF上建立N4会话并注入以下规则(TS 29.244 Section 7.5):
| 规则类型 | 功能 | 关键参数 |
|---|---|---|
| PDR (Packet Detection Rule) | 报文检测 | 源/目的IP、隧道TEID、Filter ID、Application ID |
| FAR (Forwarding Action Rule) | 转发动作 | 转发目标接口(N3/N6/N9)、外层隧道封装、重定向 |
| QER (QoS Enforcement Rule) | QoS执行 | Gate Status、MBR/GBR、QFI、Packet Rate |
| URR (Usage Reporting Rule) | 用量报告 | 测量方法、报告触发、配额、阈值 |
| MAR (Miscellaneous Action Rule) | 辅助动作 | 缓存、丢弃、通知CP |
SMF在N4 Session Establishment Request中按以下优先级注入PDR: 1. 高优先级PDR:匹配AF指定的流量描述符(如特定App Server IP),FAR指向新UPF/MEC 2. 默认PDR:匹配所有其他流量,FAR指向原UPF/Internet
AF在创建请求时可设置 upPathChgNotif,要求SMF在UP路径发生变更时回调通知。这是MEC应用感知UE移动性的关键机制。
通知消息体(TS 29.522 Section 6.1.7 Nnef_TrafficInfluence_Notify):
| 字段 | 说明 |
|---|---|
| notifyId | 通知标识,关联原始订阅 |
| upPathChg | UP路径变更类型(EARLY/LATE) |
| srcUeIpv4Addr / srcUeIpv6Prefix | UE源地址(新旧可能不同) |
| dnaiChgType | DNAI变更类型 |
| targetDnai | 目标DNAI |
| targetUeIpv4Addr | 重选后UE新地址 |
| ebcsiInfo | 边缘计算服务信息 |
EARLY通知模式:SMF在UP路径变更之前通知AF,AF提前准备MEC应用状态迁移。
LATE通知模式:SMF在UP路径变更之后通知AF,AF收到后更新服务绑定。
| 维度 | 场景A:同UPF路由修改 | 场景B:UPF重选+BP插入 | 场景C:UPF重选+UL CL插入 |
|---|---|---|---|
| 触发条件 | 目标DNAI可达当前UPF | 需新锚点,保留IP | 需新锚点+多路由分流 |
| N4操作 | Modification only | Est(New)+Mod(Old) | Est(ULCL)+Est(PSA2)+Mod(PSA1) |
| UE IP保留 | 自动保留 | 通过BP保留 | 通过UL CL保留 |
| 业务中断 | 无 | 极短(ms级) | 极短(ms级) |
| 信令复杂度 | 低 | 中 | 高 |
| 典型场景 | UPF内MEC负载均衡 | UE移动至新MEC区域 | 本地+远端双路由 |
| TS 23.502章节 | 4.3.6.2 | 4.3.6.3 | 4.3.6.4 |
AF的路由需求经过NEF鉴权后到达PCF,PCF将其映射为PCC规则(TS 29.512 Section 6.2)。
| PCC属性 | 来源 | 说明 |
|---|---|---|
| routingKey | SMF内部 | 标识路由上下文 |
| dnai | AfRoutReq.routeToLocs | 数据网络接入标识 |
| routeToLocs | AfRoutReq | 路由目标位置 |
| upPathChgNotif | AfRoutReq | UP路径变更通知需求 |
| appReloc | AfRoutReq | 应用重定位能力 |
| spatialValidCon | AfRoutReq | 空间约束(TAI列表) |
| temporalValidCon | AfRoutReq | 时间约束 |
PCF通过 Npcf_SMPolicyControl_Update 服务将路由PCC规则推送到SMF。关键步骤:
PCF → SMF:
Npcf_SMPolicyControl_Update
{
"policyUpdate": {
"pccRules": [{
"pccRuleId": "pcc-rule-af-001",
"refAppId": "app-mec-video",
"flowInfos": [{"flowDesc": "permit out ip from 10.1.2.0/24 to 192.168.100.5/32"}],
"routeToLocs": [{"dnai": "mec-site-bj-01", "routeProfId": "rp-1"}],
"upPathChgNotif": {"notifyUri": "https://nef.example.com/notify/uppathchg", "notifCorreId": "nc-12345"}
}]
}
}
SMF收到后解析PCC规则,执行UPF重选评估。
| 接口 | 抓包点 | Wireshark过滤 |
|---|---|---|
| AF↔NEF (HTTP/2) | NEF北向接口 | http2.headers.path contains "traffic-influence" |
| NEF↔PCF (HTTP/2) | SBI接口 | http2.headers.path contains "policy-authorization" |
| PCF↔SMF (HTTP/2) | N7接口 | http2.headers.path contains "sm-policies" |
| SMF↔UPF (PFCP) | N4接口 | pfcp.message_type == 50(Session Est)pfcp.message_type == 52(Session Mod) |
| 故障现象 | 可能原因 | 排查方法 |
|---|---|---|
| AF收到403 Forbidden | AF未签约Traffic Influence服务 | 检查UDM中AF的Service Authorization数据 |
| NEF未转发至PCF | TrafficDesc与签约DNN/S-NSSAI不匹配 | 检查NEF日志中的mapping rule |
| SMF忽略路由规则 | PCC规则中DNAI在SMF拓扑中不可达 | 检查SMF的UPF拓扑配置(NRF注册信息) |
| UPF重选后业务中断 | N4规则注入错误,FAR指向错误接口 | 抓N4 Session Est消息,检查FAR的Destination Interface |
| UP Path通知未送达 | SMF未设置Notification URI | 检查PCF下发的PCC规则中upPathChgNotif是否正确 |
| UE IP变更导致会话断开 | 未设置addrPreserInd=true | 检查AF请求中地址保留指示 |
| UL CL插入后双路由失败 | PDR优先级冲突 | 检查N4中PDR的Precedence值是否正确排序 |
| ## 八、Rel-18/19增强特性 |
Q1: AF Traffic Influence与静态UL CL配置有什么区别?
A: 静态UL CL由运营商在SMF上预配置分流规则,基于固定的流量匹配条件(如目的IP段),无法动态调整。AF Traffic Influence通过SBI接口由第三方AF动态请求路由变更,支持空间/时间条件约束,且能触发UPF重选。前者适合固定的企业专线分流,后者适合MEC应用的动态部署场景。
Q2: UP Path变更的EARLY和LATE通知模式如何选择?
A: EARLY模式适合需要"无感切换"的场景——AF提前收到通知后,可在新UPF侧预加载应用状态(如缓存数据、会话上下文),等UP路径正式切换时应用已就绪。LATE模式适合应用对切换时延不敏感的场景。5G VoNR或云游戏等低时延业务推荐EARLY模式,普通物联网业务可用LATE模式。
Q3: addrPreserInd(地址保留)为什么重要?
A: 当UPF重选时,如果不保留UE IP地址,UE会被分配新IP,导致所有TCP连接断开。设置addrPreserInd=true后,SMF通过插入BP(Branching Point)或UL CL,在保持原IP地址的同时将流量引导至新UPF。代价是增加了N4信令复杂度和额外的用户面跳数。
Q4: AF如何知道应该影响哪个UE的流量路由?
A: AF在Nnef_TrafficInfluence_Create请求中通过以下方式指定目标UE:直接指定UE的外部标识(GPSI/SUPI)、指定外部组标识(External Group ID)、设置anyUeInd=true影响所有UE、或指定IP地址/前缀让SMF匹配对应PDU会话。MEC平台通常通过ETSI MEC API获取UE位置信息后决定目标UE。
Q5: NEF在AF Traffic Influence中的具体作用是什么?
A: NEF执行三个关键功能:(1) AF鉴权与授权——验证AF是否有权请求路由影响;(2) 参数映射——将AF提供的外部标识(如GPSI)映射为内部标识(如SUPI),将外部DNAI映射为内部DNAI;(3) 请求路由——根据运营商策略决定将请求转发给PCF(标准路径)或直接转发给SMF(优化路径)。NEF是AF与5GC之间的"翻译器"和"安全网关"。
本文由「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 等场景全覆盖。
