<!-- title: AF流量影响与UPF动态重选 -->
<!-- domain: slicing-mec -->

# 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重选完成的全链路：

```mermaid
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（流量描述符）匹配规则

```mermaid
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）：

```text
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）<br/>`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增强

- **TS 23.502 V18.x Section 4.3.6.8**：AF可直接向SMF请求路由影响（绕过NEF/PCF），当运营商信任AF时减少信令跳数
- **Enhanced Edge Computing**：支持多个DNAI的并发路由影响请求，AF可同时影响多个MEC站点
- **AF Session With Required QoS**：AF不仅指定路由，还可指定QoS参数（5QI、GFBR、MFBR）

### 8.2 Rel-19方向

- **AI辅助UPF重选**：SMF利用ML模型预测UE移动轨迹，提前触发UPF重选
- **分布式UPF池**：支持UPF池化部署，AF路由请求指向池而非单个UPF
- **跨运营商MEC路由**：支持漫游场景下AF影响VPLMN的UPF路由

## 常见问题

**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](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — Section 4.3.6 Traffic Routing Influence by AF
2. [3GPP TS 29.522 V18.10.0](https://www.etsi.org/deliver/etsi_ts/129500_129599/129522/18.10.00_60/ts_129522v181000p.pdf) — Nnef_TrafficInfluence API Stage 3
3. [3GPP TS 23.501 V18.10.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123501/18.10.00_60/ts_123501v181000p.pdf) — Section 5.6.7 UPF Selection, Section 6.3.3.2 Routing Constraints
4. [free5GC Traffic Influence Guide](https://free5gc.org/guide/8-traffic-influence/) — 开源5GC中AF Traffic Influence功能演示
5. [3GPP TS 29.244 V18.x](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3393) — 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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)