首页 › slicing-mec › AF流量影响与UPF动态重选

5G AF Traffic Influence与MEC UPF动态重选信令拆解

一、机制概述:为什么需要AF Traffic Influence?

在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 Traffic Influence信令时序图

以下是完整的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参数深度解析

3.1 Nnef_TrafficInfluence_Create请求体(TS 29.522 Section 6.1.6)

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)

3.2 AfRoutReq(AF路由需求)子结构

子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 简单离开指示

3.3 TrafficDesc(流量描述符)匹配规则

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/>未命中→默认路由]

四、UPF重选决策机制与N4规则注入

4.1 SMF的UPF重选判断逻辑

当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

4.2 N4会话规则注入详解

当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

4.3 UP路径变更通知机制

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

六、PCF策略映射:从AF路由需求到PCC规则

AF的路由需求经过NEF鉴权后到达PCF,PCF将其映射为PCC规则(TS 29.512 Section 6.2)。

6.1 PCC规则中的路由相关属性

PCC属性 来源 说明
routingKey SMF内部 标识路由上下文
dnai AfRoutReq.routeToLocs 数据网络接入标识
routeToLocs AfRoutReq 路由目标位置
upPathChgNotif AfRoutReq UP路径变更通知需求
appReloc AfRoutReq 应用重定位能力
spatialValidCon AfRoutReq 空间约束(TAI列表)
temporalValidCon AfRoutReq 时间约束

6.2 PCF到SMF的策略下发

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重选评估。

七、实战抓包识别与故障排查

7.1 抓包关键过滤表达式

接口 抓包点 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)

7.2 常见故障点及排查

故障现象 可能原因 排查方法
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增强特性

8.1 Rel-18增强

8.2 Rel-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之间的"翻译器"和"安全网关"。

参考来源

  1. 3GPP TS 23.502 V18.10.0 — Section 4.3.6 Traffic Routing Influence by AF
  2. 3GPP TS 29.522 V18.10.0 — Nnef_TrafficInfluence API Stage 3
  3. 3GPP TS 23.501 V18.10.0 — Section 5.6.7 UPF Selection, Section 6.3.3.2 Routing Constraints
  4. free5GC Traffic Influence Guide — 开源5GC中AF Traffic Influence功能演示
  5. 3GPP TS 29.244 V18.x — N4 Session Management, PDR/FAR/QER规则定义

本文由「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 等场景全覆盖。

51学通信知识星球海报-扫码加入