在5G边缘计算（Edge Computing）架构中，应用服务器（EAS/AF）部署在距离用户更近的本地数据网络（Local DN）。一个核心问题是：5G核心网（5GC）如何知道"某个UE的某段业务流量应该被路由到本地边缘UPF，而不是一路送到中心DN"？
答案就是 AF Influence on Traffic Routing（AF对流量路由的影响） 机制，定义在 3GPP TS 23.501 Clause 5.6.7 与 TS 23.502 Clause 4.3.6。它不是数据面机制本身（UL CL/BP插入是数据面动作），而是触发数据面重配的控制面信令链——AF（应用功能）通过NEF（或直连PCF）把自己的"路由偏好"告诉5GC，5GC将其翻译为PCC规则下发SMF，最终SMF完成UPF（重）选、UL CL插入、N4会话重配。
理解这条信令链是掌握5G MEC本地分流、边缘应用重定位（Edge Relocation）、SSC模式3切换的钥匙。本文基于Release 18规范，逐消息、逐IE拆解这条全链路。
注：本文聚焦的是控制面触发链（AF→NEF→BSF/UDR→PCF→SMF→UPF），区别于已覆盖的"UL CL插入与DNAI重定位"（数据面动作细节）与"EASDF发现"（基于DNS的边缘发现）。三者是MEC的三个互补维度。
| 网元 | 角色 | 相关服务/接口 |
|---|---|---|
| AF | 应用功能，发起流量影响请求，提供DNAI、N6路由需求、业务过滤信息 | Nnef_TrafficInfluence（经NEF）或Npcf_PolicyAuthorization（直连N5） |
| NEF | 网络开放功能，对AF做鉴权、外部信息→内部信息映射（如AF-Service-ID→DNN/S-NSSAI/DNAI列表）、存储到UDR | Nnef_TrafficInfluence（TS 29.522 §5.4） |
| BSF | 绑定支持功能，根据UE IP地址/DNN/S-NSSAI反查PCF实例 | Nbsf_Management_Discovery（TS 29.521） |
| UDR | 统一数据仓库，存储AF流量影响数据（Application Data），并通知订阅的PCF/SMF | Nudr_DataRepository（TS 29.519） |
| PCF | 策略控制功能，将AF请求翻译为PCC规则（含Traffic Steering Policy ID、DNAI），下发SMF | Npcf_PolicyAuthorization、Npcf_SMPolicyControl |
| SMF | 会话管理功能，根据PCC规则（重）选UPF、插入UL CL/BP、配N4（PDR/FAR）、订阅UP路径事件通知 | Nsmf_PDUSession、Nsmf_EventExposure |
| UPF | 用户面功能，执行UL CL分流、本地PSA锚定 | N4（TS 29.244，PFCP） |
AF流量影响请求有两种分发路径，取决于目标UE的范围：
下面以路径B为主线拆解（它信令最完整，包含BSF步骤），再说明路径A的差异。
sequenceDiagram
participant AF
participant NEF
participant BSF
participant PCF
participant SMF
participant UPF as UPF (UL CL/PSA)
participant UDR
Note over AF,PCF: 阶段1：AF请求提交与PCF发现
AF->>NEF: 1. Nnef_TrafficInfluence_Create<br/>(POST /{afId}/subscriptions)<br/>TrafficInfluSub: afAppId, dnai[], ipAddr,<br>trafDesc, appReloInd, n6RoutingReq
NEF-->>AF: 201 Created (subscriptionId)
NEF->>BSF: 2. Nbsf_Management_Discovery<br/>(UE IP addr, DNN, S-NSSAI)
BSF-->>NEF: 3. PCF instance URI (绑定信息)
NEF->>PCF: 4. Npcf_PolicyAuthorization_Create<br/>(映射后: DNAI, PFD, N6路由, 事件订阅)
PCF-->>NEF: 200 OK
Note over PCF,UPF: 阶段2：策略翻译与PCC下发
PCF->>SMF: 5. SMPolicyAssociationModification<br/>PCC Rule: SDF template + Traffic Steering Policy ID<br/>+ DNAI + afSigReq(事件订阅) + appReloInd
SMF-->>PCF: 200 OK
Note over SMF,UPF: 阶段3：用户面重配（UL CL插入）
SMF->>UPF: 6a. N4 Session Establishment (新Local PSA)
SMF->>UPF: 6b. N4 Session Modification (插入UL CL)<br/>下发PDR(检测规则)+FAR(转发规则)
Note right of UPF: 命中本地过滤的流量→Local PSA→Local DN<br/>其余流量→中心PSA→中心DN
Note over AF,SMF: 阶段4：UP路径变化通知（Early/Late）
SMF->>NEF: 7. Nsmf/Nnef UP路径管理事件通知<br/>(Early Notification: 源DNAI→目标DNAI)
NEF->>AF: Nnef_TrafficInfluence_Notify (DNAI change)
AF-->>NEF: Nnef_TrafficInfluence_AppRelocationInfo<br/>(AF ack, 可选上行缓冲指示)
NEF-->>SMF: 转发AF应答
Note over SMF,UPF: SMF激活新UP路径后发Late Notification
SMF->>NEF: 8. Late Notification (新UP路径已激活)
消息1 Nnef_TrafficInfluence_Create（TS 29.522 §5.4，HTTP POST /{afId}/subscriptions）
这是整条链的起点。AF向NEF发送 TrafficInfluSub 数据结构（TS 29.522 §5.4.3.3.2），核心字段：
afAppId（AF应用标识）：AF用其代某个应用发起请求，NEF据此鉴权并映射为DNN+S-NSSAI+DNAI列表（TS 23.501 §5.6.7.1 第1)、3)条）。appReloInd（应用可重定位指示）：若为false，5GC须保证该应用流量选定DNAI后不再变化（影响SSC行为）。dnais（潜在应用位置列表）：DNAI是连接AF请求与具体边缘部署点的关键参数（TS 23.501 §5.6.7.1 第3)条）。trafDesc/ipTrafficDesc/ethTrafficDesc（业务描述）：用于UPF检测流量。n6RoutingReq（N6路由需求）：按DNAI给出routing profile ID和/或N6 traffic routing information。snssai + dnn：切片与数据网络名，业务识别。afAckReq（"AF acknowledgment to be expected"）：见阶段4，决定SMF是否等待AF应答。tempValidities / spatialValidValidity：时间/空间有效性条件。upPath_chgSub：AF对UP路径变化事件的订阅（Early/Late）。消息2-3 Nbsf_Management_Discovery（TS 29.521）
NEF持有UE IP但不知PCF地址时，查BSF。BSF内部维护"绑定信息"：(UE IPv4/IPv6/Prefix, DNN, S-NSSAI, IPv4FrameRouteList) → (PCF ID, PCF FQDN/URI, SUPI, DNN, S-NSSAI)。BSF返回PCF实例URI，NEF据此精确路由到服务于该PDU会话的PCF（TS 23.502 §4.3.6.4 step 2-3）。BSF自身通过NRF发现（TS 23.502 NOTE 1）。
设计意图：PDU会话建立时PCF会在BSF注册绑定（IP↔PCF），这样任何外部功能都能凭UE IP反查到策略面，避免向全网PCF广播——这是5GC解耦PCF实例与具体会话的关键设计。
消息4 Npcf_PolicyAuthorization（TS 29.514，N5/经NEF）
NEF把映射后的请求转交给PCF。PCF在此完成鉴权（TS 23.502 §4.3.6.4 step 5）：若无法授权（如时延需求不满足），直接拒绝AF请求。
消息5 SMPolicyAssociationModification（TS 29.512）
PCF把AF请求翻译为PCC规则（TS 23.501 §5.6.7.1末段）下发SMF。PCC规则包含：
- 业务识别信息（SDF template）
- DNAI列表（流量应路由到的边缘位置）
- Traffic Steering Policy ID（按DNAI给出，由SMF/UPF预配置，指向具体分流策略）
- N6 traffic routing information（若AF显式提供）
- appReloInd、UE IP保持指示、traffic correlation指示
- 可选AF事件订阅信息（让SMF在UP路径变化时通知AF）
关键翻译：AF的
routing profile ID（AF与运营商预约定）→PCF导出的traffic steering policy ID（SMF/UPF本地可执行）。这是契约层→执行层的映射点。
消息6 N4 Session Establishment/Modification（TS 29.244，PFCP）
SMF依据PCC规则（重）选UPF并配置（TS 23.501 §5.6.7.1最后一段）： - 选定目标DNAI对应的Local PSA UPF； - 插入UL CL（和/或分支点BP）功能UPF； - 向UPF下发 PDR（Packet Detection Rule） + FAR（Forwarding Action Rule）：UL CL按包过滤器把上行流量分叉——匹配边缘业务过滤的送往Local PSA，其余送往中心PSA； - IPv6多归属场景下为UE分配新Prefix。
消息7-8 UP路径管理事件通知（TS 23.502 §4.3.6.3）
若AF订阅了UP路径变化，SMF经NEF向AF发送DNAI change通知，分两类（TS 23.501 §5.6.7.1 第8)条）：
- Early Notification：在新UP路径配置/激活之前发送，让AF提前准备目标DNAI的应用实例。若AF带了afAckReq，SMF等待AF应答（Nnef_TrafficInfluence_AppRelocationInfo）后再激活新路径——这是TS 23.501 §5.6.7.2"基于AF协调的UP路径管理增强"，用于SSC mode 3或UL CL场景下最小化业务中断。
- Late Notification：在新UP路径激活之后发送，确认完成。
当AF请求针对"任意访问某DNN+S-NSSAI+DNAI的UE"或一组UE时（TS 23.501 §5.6.7.1 NOTE 1 of Table 5.6.7-1），信令改为：
flowchart TD
AF -- Nnef_TrafficInfluence_Create --> NEF
NEF -- 存储Application Data<br/>Data Subset=AF流量影响信息 --> UDR
UDR -. 订阅通知 .-> PCF
UDR -- 数据变更通知 --> PCF
PCF -- SMPolicyAssocModification<br/>PCC规则 --> SMF
SMF -- N4重配 --> UPF
关键点：UDR是分发枢纽。PCF此前已向UDR订阅（Data Set=Application Data；Data Subset=AF traffic influence request information）。AF请求一写入，UDR即通知所有相关PCF（可能多个，因any UE会跨多个SMF/PCF）。这种方式支持未来才建立的PDU会话——会话建立时PCF自然命中该策略。Data Key的取法（TS 23.502 §4.3.6.5）：HPLMN ID + S-NSSAI + DNN + (UE IP / SUPI / "any UE"指示)。
下表给出AF请求的完整IE清单（节选核心项）：
| IE名称 | PCF适用 | NEF特有 | 必备性 | 说明 |
|---|---|---|---|---|
| Traffic Description（业务描述） | DNN+可选S-NSSAI+可选PLMN ID+应用标识/过滤信息 | 可用AF-Service-Identifier替代 | 必备 | 识别要影响的流量 |
| Potential Locations of Applications | DNAI列表+可选PLMN ID | 可用AF-Service-Identifier替代 | 条件 | 应用潜在位置，用于UPF重选 |
| Target UE Identifier(s) | 单UE/组(Internal Group ID)/任意UE | GPSI/External Group ID/External Subscriber Category | 必备 | 决定走BSF还是UDR路径 |
| Spatial Validity Condition | 有效性区域 | 可用地理区域（NEF映射为TA列表） | 可选 | 空间过滤 |
| Temporal Validity Condition | 时间区间/时长 | - | 可选 | 时间过滤 |
| AF transaction identifier | AF事务标识 | NEF映射为内部事务ID | 必备 | 用于更新/删除/事件关联 |
| N6 Traffic Routing requirements | 按DNAI的routing profile ID和/或N6路由信息+可选traffic correlation指示 | - | 条件 | N6分流需求 |
| Application Relocation Possibility | 应用是否可重定位 | - | 可选 | false→选定DNAI后不再变 |
| UE IP address preservation | UE IP保持 | - | 可选 | 阻止PSA重选以保IP |
| AF subscription to SMF events | Early/Late通知订阅+通知地址+afAckReq+立即上报标志 | - | 可选 | UP路径变化订阅 |
| EAS Correlation indication / Common EAS IP / Traffic Correlation ID / FQDN(s) | 一组UE选公共EAS/DNAI | - | 可选 | 公共EAS选择（Rel-17+） |
| 维度 | AF Traffic Influence（本文） | EASDF发现 | UL CL插入（数据面动作） | URSP（终端侧路由） |
|---|---|---|---|---|
| 规范 | TS 23.501 §5.6.7 / TS 23.502 §4.3.6 | TS 23.548 | TS 23.501 §5.6.4 / §5.8.2 | TS 23.501 §5.15 / TS 24.526 |
| 触发方 | AF（经NEF/直连PCF） | UE DNS查询 + SMF | SMF（由PCC规则驱动） | UE（按URSP规则选DNN/切片） |
| 本质 | 控制面策略注入 | DNS层边缘发现 | 用户面分流执行 | 终端业务流路由策略 |
| 关系 | 上游触发器 | 并行的发现机制 | 下游执行结果 | 互补（决定建哪个会话） |
一句话：AF Traffic Influence是"指令"，UL CL插入是"动作"，EASDF是"另一条发现路径"。三者常协同工作——AF注入DNAI策略→SMF插UL CL→UE通过EASDF解析到本地EAS IP→流量经UL CL分流到该EAS。
stateDiagram-v2
[*] --> 未创建: AF未发起
未创建 --> 活跃: Nnef_TrafficInfluence_Create成功<br/>(UDR存储/PCF接受)
活跃 --> 挂起: Temporal/Spatial条件未满足<br/>(PCC规则未激活)
挂起 --> 活跃: 时间到达/UE进入有效区域<br/>(SMF通知PCF触发PDU会话修改)
活跃 --> 重定位中: SMF发送Early Notification<br/>等待AF ack
重定位中 --> 活跃: AF ack到达,新UP路径激活<br/>(Late Notification)
活跃 --> [*]: Nnef_TrafficInfluence_Delete<br/>(AF删除/超时)
注意"激活/去激活"语义（TS 23.501 §5.6.7.1 NOTE 7）：从"无DNAI适用"到"某DNAI适用"=激活该AF请求；反向=去激活。这直接对应PCC规则的安装/卸载与UL CL的插入/移除。
这条链路横跨多个SBI接口，在抓包（HTTP/2 over TLS，建议在SEPP或各NF侧解密）中按如下特征定位：
POST /nnef-trafficinfluence/v1/{afId}/subscriptions，Body含TrafficInfluSub，看afAppId、dnais、appReloInd。GET /nbsf-management/v1/bindings?ipv4Addr=...&dnn=...&snssai=...——注意这是查询绑定而非创建。POST /npcf-policyauthorization/v1/app-sessions——这是策略授权会话创建。POST /npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}/update，Body的policyUpt里出现trafficSteeringPolIdDl/Ul和dnais是铁证。Create PDR/Create FAR中的F-TEID与Destination Interface——UL CL的FAR会把流量指向多个接口。POST /nnef-trafficinfluence/.../notify，Body含afTransId、dnais(source/target)、notifType(EARLY/LATE)。| 故障现象 | 可能根因 | 排查方向 |
|---|---|---|
| AF请求被NEF拒绝(403) | AF未授权/AF-Service-ID映射缺失 | 查NEF的AF鉴权配置与AF-Service-Identifier→DNN/S-NSSAI/DNAI映射表 |
| PCC规则下发但未插UL CL | Traffic Steering Policy ID在SMF/UPF未预配置 | 确认SMF/UPF本地是否配置了PCF下发的steering policy ID（这是契约层落地点） |
| BSF查不到PCF | PDU会话建立时PCF未注册绑定 / IP不匹配 | 在PDU会话建立流程中确认PCF的Nbsf_Management_Register；核对UE IP、DNN、S-NSSAI三元组 |
| UDR路径无PCF收到通知 | PCF未向UDR订阅Application Data / Data Key不匹配 | 核对PCF订阅的Data Subset与Data Key（S-NSSAI+DNN+anyUE/SUPI/IP） |
| Early Notification发出但SMF卡住不激活 | AF未回ack（afAckReq=true时） | 查AF侧Nnef_TrafficInfluence_AppRelocationInfo是否返回；负响应会中断重定位 |
| 边缘分流时通时不通 | Spatial Validity条件 / UE移出有效区域 | 查SMF对AMF的Presence Reporting Area订阅与通知；UE出区域→PCC规则去激活→UL CL移除 |
| ## 常见问题 |
Q1: BSF路径（单UE）和UDR路径（任意UE/组UE）能不能同时存在？ A: 不会对同一请求并存。路径选择由AF请求的"Target UE Identifier"决定：给具体UE IP→BSF反查PCF；给DNN+S-NSSAI+任意UE或组ID→UDR存储分发（TS 23.502 §4.3.6.4 vs §4.3.6.2）。但同一AF可对不同UE范围分别发两类请求。
Q2: AF Traffic Influence和AF Session with Required QoS（TS 23.501 §5.6.6）有什么区别？
A: 前者关注流量去哪路由（DNAI/UL CL），后者关注流量的QoS保障（QoS Flow/GBR）。两者可叠加：AF既可请求把流量引到边缘DNAI，也可同时为该流量要求专用QoS。前者经Nnef_TrafficInfluence，后者经Npcf_PolicyAuthorization的QoS相关服务操作。
Q3: appReloInd=false 到底约束了什么？
A: 它要求5GC在为该应用流量选定DNAI后不再变更DNAI（TS 23.501 §5.6.7.1 第5)条）。SMF据此避免PSA重选，保证应用连续性。它和"UE IP address preservation indication"配合，可彻底锁定锚点——这是对SSC行为的细粒度控制。
Q4: Early/Late Notification和SSC mode 3是什么关系？
A: SSC mode 3的会话重锚点必然伴随DNAI变化。当AF订阅了UP路径事件并带afAckReq时，SMF在激活新UP路径前发Early Notification并等待AF应答（TS 23.501 §5.6.7.2），让边缘应用实例提前就绪、上行数据可选缓冲，从而把切换中断压到最低。没有AF订阅时，SMF按本地策略处理。
Q5: 为什么NEF要把数据存到UDR，而不是直接调PCF？ A: 解耦与可扩展。any UE/组UE请求可能影响尚未建立的PDU会话、跨多个PCF实例。UDR作为集中数据仓库+订阅通知模型，让"数据写入"与"PCF消费"在时间与实例上解耦——PCF按需订阅、按Data Key精确匹配，避免NEF向全网PCF逐一推送。
本文由「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 等场景全覆盖。