<!-- title: 5G PDU会话建立全链拆解 -->
<!-- domain: core-network -->

# 5G PDU会话建立全链拆解：SMF/UPF选择、N4(PFCP)会话锚定与PCF策略关联机制

## 一、为什么PDU会话建立是5GC最复杂的单条信令流

在5G核心网（5GC）中，**PDU会话（PDU Session）** 是UE与数据网络（DN）之间建立端到端用户面连接的逻辑载体。相比于4G EPS中相对扁平的"PDN连接+EPS承载"模型，5G的PDU会话建立流程（定义于 **3GPP TS 23.502 Section 4.3.2.2.1 "UE-initiated PDU Session Establishment"**）一次性串联了**SMF选择、UPF/PSA选择、订阅数据获取、PCF策略关联、N4(PFCP)会话锚定、N3/N9隧道建立、N2 AN资源建立**等7大子流程，涉及AMF、SMF、UDM、PCF、UPF、(R)AN、NRF、NSSF共8类网元。

这条信令流的特殊性在于：**控制面（N11/N7/N10）与用户面（N4/N3/N9）在同一过程中并行建立并相互依赖**。SMF既是控制面的"指挥中枢"，又是用户面的"配置源头"——它必须先通过N7从PCF拿到PCC规则，才能通过N4向UPF下发PDR/QER/FAR/URR，而N4会话的隧道信息又必须回填给AMF以驱动N2接口向gNB下发无线承载。任何一个环节的IE缺失或时序错配，都会导致PDU会话建立失败。

本文以 **TS 23.502 4.3.2.2.1** 的标准流程为主线，结合 **TS 23.501 6.2.2/6.3.3（SMF/UPF功能与选择）、TS 23.503（PCC框架）以及TS 29.244（N4 PFCP协议）**，逐消息拆解关键Information Element，并辅以free5GC开源实现中的源码级映射（`ApplyPccRules`/`CreatePccRuleDataPath`/`AssignQFI`/`AddQoS`/`ActivateTunnelAndPDR`），帮助协议开发与抓包排错工程师建立"从信令到数据面"的完整心智模型。

---

## 二、整体信令时序：UE-initiated PDU会话建立全流程

下图基于TS 23.502 Figure 4.3.2.2.1-1，绘制了一次完整的UE发起PDU会话建立过程，标注了每条消息的归属接口与核心动作。

```mermaid
sequenceDiagram
    participant UE
    participant AN as (R)AN/gNB
    participant AMF
    participant SMF
    participant UDM
    participant PCF
    participant UPF
    participant NRF

    Note over UE,AMF: 1. AN信令连接已建立（注册流程后）
    UE->>AMF: NAS Msg: PDU Session Establishment Request<br/>(PDU Session ID, DNN, S-NSSAI, PDU Session Type, SSC mode, Request Type)
    Note over AMF: 2. SMF Selection<br/>(DNN+S-NSSAI+签约→Nnrf_NFDiscovery)
    AMF->>NRF: Nnrf_NFDiscovery (nf-type=SMF, DNN, S-NSSAI)
    NRF-->>AMF: SMF实例列表
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request<br/>(SUPI, DNN, S-NSSAI, PDU Session ID, AMF ID, N1 SM container, User Location)
    Note over SMF: 3a. SM Context创建
    SMF->>UDM: Nudm_SDM_Get (SUPI, DNN, S-NSSAI)<br/>获取SessionManagementSubscriptionData
    UDM-->>SMF: 签约数据(默认SSC模式, Allowed DNN, Subscribed QoS, Charging)
    SMF->>UDM: Nudm_SDM_Subscribe (数据变更通知)
    SMF-->>AMF: Nsmf_PDUSession_CreateSMContext Response<br/>(SM Context ID, N1 SM: PDU Estab Accept/Reject)
    Note over SMF: 3b. SM Policy Association建立
    SMF->>PCF: Npcf_SMPolicyControl_Create<br/>(SUPI, DNN, S-NSSAI, IPv4/IPv6, UE IP, Subscription)
    Note over PCF: 策略决策：选PCC规则、QoS决策、计费决策
    PCF-->>SMF: SmPolicyDecision<br/>(PCC rules, QoS decision, Charging decision, Session rules)
    Note over SMF: 4. UPF Selection + ApplyPccRules→Session Rules
    SMF->>NRF: Nnrf_NFDiscovery (nf-type=UPF, DNAI/DNN)
    NRF-->>SMF: UPF实例列表
    SMF->>SMF: ApplyPccRules(): PCC→PDR/QER/FAR/URR, AssignQFI
    Note over SMF,UPF: 5. N4会话锚定（PFCP）
    SMF->>UPF: N4 Session Establishment Request<br/>(PDR, FAR, QER, URR, F-TEID请求)
    UPF-->>SMF: N4 Session Establishment Response<br/>(CN Tunnel Info = N9 F-TEID)
    SMF->>SMF: 分配UE IP地址（IPAM/DHCP）
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N1: PDU Estab Accept[UE IP,PDU Type,SSC,QoS规则]<br/> N2: PDU Session Resource Setup[QoS Profile, N3 UL F-TEID, QFI])
    Note over AMF,AN: 6. N2 AN资源建立
    AMF->>AN: N2 PDU Session Resource Setup Request<br/>(PDU Session ID, NAS Msg, N3 Tunnel Info, QoS Flow List)
    AN->>UE: RRC Reconfiguration（建立DRB）
    AN-->>AMF: N2 PDU Session Resource Setup Response<br/>(N3 DL F-TEID = AN Tunnel Info)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request<br/>(AN Tunnel Info)
    Note over SMF,UPF: 7. 下行隧道下发
    SMF->>UPF: N4 Session Modification Request<br/>(更新FAR: 下行AN Tunnel Info)
    UPF-->>SMF: N4 Session Modification Response
    SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response
    Note over UE,UPF: ✅ 端到端用户面打通：UE↔DRB↔N3↔UPF↔N6
```

整条流程可分为**七个逻辑阶段**：①请求与SMF选择；②SM Context创建与签约获取；③SM Policy关联与策略决策；④UPF选择与PCC规则映射；⑤N4会话锚定；⑥N2/N3用户面资源建立；⑦下行隧道回填与确认。下面逐阶段拆解关键IE。

---

## 三、阶段一：PDU会话建立请求与SMF选择

### 3.1 UE侧NAS请求中的关键IE

UE通过已注册时建立的N1 NAS信令连接，向AMF发送 **`PDU Session Establishment Request`**（TS 24.501 Section 8.3.8.1）。该消息封装在UL NAS TRANSPORT中，核心IE如下表：

| Information Element | 说明 | 抓包定位（Wireshark NAS-5GS） | 设计意图 |
|---|---|---|---|
| **PDU Session ID** | UE本地分配的会话标识（1~15，0保留） | `nas_5gs.pdu_session_identity` | 同一UE可并行多PDU会话，需唯一标识以供SM Context路由 |
| **DNN**（Data Network Name） | 目标数据网络，等价4G APN | `nas_5gs.dnn` | 决定UPF到DN的N6出口与PSA选择域 |
| **S-NSSAI**（Slice） | 切片标识（SST+SD） | `nas_5gs.s_nssai` | 缩小SMF/UPF选择范围，实现切片隔离 |
| **Requested PDU Session Type** | IPv4 / IPv6 / Ethernet / Unstructured | `nas_5gs.requested_type` | 决定UPF数据面处理方式与IP分配策略 |
| **Requested SSC mode** | SSC1/2/3，会话与服务连续性模式 | `nas_5gs.ssc_mode` | 决定锚点是否可迁移（SSC3允许重定位PSA） |
| **Request type** | INITIAL_REQUEST / EXISTING_PDU_SESSION / MODIFICATION / EMERGENCY | `nas_5gs.request_type_value` | 区分新建、切换重建、紧急呼叫等场景 |
| **Old PDU Session ID** | 非3GPP/4G互操作时携带 | 仅异系统场景 | 保持PDU Session ID连续性 |

**设计意图**：5G把"DNN+S-NSSAI"作为**会话寻址的复合主键**，而非4G仅靠APN。这是为了支持一个UE在同一DNN下对不同切片建立独立的PDU会话，是切片商用化的协议基础。

### 3.2 SMF选择机制（TS 23.501 6.3.2 + NRF发现）

AMF收到请求后执行 **SMF Selection**，其决策依据（TS 23.501 Section 6.3.2）：

1. **切片约束**：UE请求的S-NSSAI必须在注册流程中AMF返回的**Allowed NSSAI**内，否则AMF直接拒绝（Cause: DNN not supported / Slice not available）。
2. **签约约束**：从UDM的**AccessAndMobilitySubscriptionData**获取UE签约的`Subscribed S-NSSAI`与默认DNN列表。
3. **NRF发现**：AMF通过 **`Nnrf_NFDiscovery`** 服务（`nf-type=SMF`），以 DNN+S-NSSAI+NF Set为查询参数，获取候选SMF实例列表（含负载、容量、服务区域）。
4. **NSSF辅助**（可选）：若AMF自身无法解析（如跨切片、漫游），可调用 **Nssf_NSSelectionGet** 获取NSI ID与候选SMF Set。
5. **拓扑/负载亲和**：AMF在候选集合内按SMF Set优先选择与AMF Set有良好拓扑关系、负载较低的实例。

```mermaid
flowchart TD
    A[UE: PDUSEstab Request<br/>DNN+S-NSSAI] --> B{AMF: S-NSSAI在<br/>Allowed NSSAI内?}
    B -- 否 --> X1[拒绝#DNN/切片不可用]
    B -- 是 --> C[从UDM取签约<br/>Subscribed S-NSSAI/DNN]
    C --> D{本地Configured可解析?}
    D -- 是 --> E[本地选择规则<br/>DNN+S-NSSAI→SMF Set]
    D -- 否 --> F[Nssf_NSSelectionGet]
    F --> G[获得NSI ID + 候选SMF Set]
    E --> H[Nnrf_NFDiscovery<br/>nf-type=SMF,DNN,S-NSSAI]
    G --> H
    H --> I[候选SMF实例列表]
    I --> J[按负载/拓扑/亲和选择<br/>单个SMF]
    J --> K[Nsmf_PDUSession_CreateSMContext]
    style X1 fill:#f8d7da
    style K fill:#d4edda
```

**CreateSMContext的关键IE**（Nsmf_PDUSession_CreateSMContext Request，TS 29.502）：`SUPI`、`PDU Session ID`、`DNN`、`S-NSSAI`、`PDU Session Type`、`AMF ID`、`User Location Info (TAI+CGI)`、`RAT Type`、`N1 SM container`（透传UE的N1 SM消息）、`PEI`、`Guami`、`Serving NF ID`。AMF在此时将**会话管理上下文的所有权正式移交SMF**。

---

## 四、阶段二：SM Context创建与订阅数据获取

SMF收到CreateSMContext后，第一步是**创建SM Context**，并向UDM拉取会话管理签约数据。

### 4.1 Nudm_SDM_Get 关键签约IE

SMF调用 **`Nudm_SDM_Get`**（TS 29.503），请求 **SessionManagementSubscriptionData**，返回的关键字段：

| 签约IE | 取值/含义 | 对会话建立的影响 |
|---|---|---|
| **Single NSSAI** | 签约切片 | 校验UE请求切片合法性 |
| **DNN Configuration** | 每DNN的配置（PDU Session Type、SSC mode、Allowed SSC、5QI、Session-AMBR） | 决定默认QoS与速率上限 |
| **Subscribed default 5QI** | 默认QoS特征（如9=Non-GBR） | 生成默认QoS Flow（QFI=映射值） |
| **Session-AMBR** | 会话聚合最大比特率 | 下发UPF QER限速 |
| **Default SSC mode** | 默认SSC（通常SSC3或SSC1） | 若UE未请求则使用签约默认 |
| **Charging characteristics** | 计费特性（在线/离线） | 后续驱动CHF/计费规则 |
| **Static IP Address** | 静态UE IP（如签约） | 跳过DHCP/IPAM动态分配 |

随后SMF调用 **`Nudm_SDM_Subscribe`** 订阅该数据的变更通知（如用户套餐变更），这是5G SBI**订阅-通知模式**的典型应用，避免数据不一致。

> **排错提示**：若UDM返回`SessionManagementSubscriptionData`中该DNN不存在，SMF会向AMF回`CreateSMContext Response`中携带**N1 SM Cause = "#DNN_NOT_SUPPORTED_OR_NOT_SUBSCRIBED (27)"**，UE侧表现为"无法建立该APN"。这是商用网中最常见的会话建立失败之一。

---

## 五、阶段三：SM Policy关联与PCC规则决策（TS 23.503）

SMF在获得签约后，建立与PCF的 **SM Policy Association（会话管理策略关联）**，这是5G策略控制的核心。

### 5.1 Npcf_SMPolicyControl_Create

SMF调用 **`Npcf_SMPolicyControl_Create`**（TS 29.512），携带：SUPI、DNN、S-NSSAI、PDU Session Type、UE IP Address（若已分配）、Subscription（签约QoS/AMBR）、RAT Type、Serving Network、User Location。

PCF综合**签约数据（UDR）、应用信息（AF经NEF请求）、预定义PCC规则、本地策略**，返回 **`SmPolicyDecision`**，其中包含四类决策：

| 决策类别 | 关键参数 | 落地到用户面的网元IE |
|---|---|---|
| **PCC Rules** | 规则ID、SDF模板（五元组/流向）、precedence、Gate status | 映射为 **PDR（Packet Detection Rule）** |
| **QoS Decision** | 5QI、ARP、GBR/Non-GBR、Session-AMBR、QoS Flow | 映射为 **QER（QoS Enforcement Rule）** + QFI分配 |
| **Flow Control Decision** | Flow status、Flow Information | 影响PDR的UE/N3/N9方向FAR |
| **Charging Decision** | Charging key、Metering/Reporting level、Online/Offline | 映射为 **URR（Usage Reporting Rule）** |

### 5.2 PCC规则映射为Session规则（free5GC源码视角）

在free5GC的SMF实现中，这一映射由 **`ApplyPccRules()`** 完成，调用链为：

```mermaid
flowchart TD
    A[PCF SmPolicyDecision] --> B["ApplyPccRules()"]
    B --> C["CreatePccRuleDataPath()<br/>读tcData取DNAI<br/>配UPF选择参数<br/>判断默认路径(PCC precedence=255)<br/>标记GBR/Non-GBR<br/>激活tunnel+PDR"]
    B --> D["AssignQFI()<br/>每条PCC规则分配唯一QFI"]
    B --> E["AddQoS()<br/>遍历DataPath节点<br/>创建/配置QER(QFI+gate)<br/>QER关联PDR"]
    B --> F["ActivateTunnelAndPDR()<br/>激活UL/DL隧道<br/>设置URR(可选)<br/>生成FAR转发规则"]
    C --> G["下发N4: PDR+QER+FAR+URR"]
    D --> G
    E --> G
    F --> G
    G --> H[UPF 数据面生效]
```

这一过程揭示了5G策略落地的本质：**PCF输出"业务语义级"规则，SMF翻译成"用户面机器可执行"的四类规则（PDR/QER/FAR/URR），UPF按这些规则对每个报文执行检测、QoS、转发、计费**。

---

## 六、阶段四+五：UPF选择与N4(PFCP)会话锚定

### 6.1 UPF/PSA选择（TS 23.501 6.3.3）

SMF通过 **`Nnrf_NFDiscovery (nf-type=UPF)`** 获取候选UPF，选择依据（TS 23.501 Section 6.3.3）：

- **DNN与DNAI**：DNAI（Data Network Access Identifier）标识UPF可访问的DN接入点，PSA（PDU Session Anchor）必须支持目标DNAI；
- **S-NSSAI**：UPF所属切片；
- **SSC mode约束**：SSC1/2要求锚点固定，SSC3允许后续重定位；
- **UE位置与UPF服务区域**：优先选择拓扑最近、时延最低的UPF（边缘计算场景关键）；
- **负载与容量**：从NRF的nfProfile获取；
- **DNAI变更触发**：AF流量影响（TS 23.502 4.3.6）可指示DNAI，驱动SMF选择特定边缘UPF。

### 6.2 N4会话建立：PFCP协议四类规则IE（TS 29.244）

SMF向选定的UPF发送 **N4 Session Establishment Request**（PFCP协议），这是用户面真正"配置成型"的关键消息。PFCP会话的核心是四类IE：

| 规则类型 | 全称 | 作用 | 典型IE字段 |
|---|---|---|---|
| **PDR** | Packet Detection Rule | 报文检测：识别哪些报文属于该会话/QoS流 | PDR ID、Precedence、PDI（Source Interface=N6/N3/N9、F-TEID、UE IP、SDF Filter）、Outer Header Removal |
| **FAR** | Forwarding Action Rule | 转发动作：报文去向（转发/Drop/Buffer） | FAR ID、Apply Action（FORW/BUFF/DROP）、Forwarding Parameters（Destination Interface、Network Instance、Outer Header Creation=N3/N9 F-TEID） |
| **QER** | QoS Enforcement Rule | QoS执行：限速、QFI标记、门控 | QER ID、QFI、Gate Status（UL/DL open/close）、MBR、GBR |
| **URR** | Usage Reporting Rule | 用量上报：计费测量 | URR ID、Measurement Method（VOLUME/DURATION）、Reporting Triggers、Measurement Period |

**N4建立消息流程要点**：
1. SMF为该PDU会话在UPF侧创建N4 Session（由SEID标识）；
2. 下发默认QoS Flow的PDR（匹配UE IP / N3 F-TEID）；
3. 通过FAR的Outer Header Creation请求UPF分配**N9侧F-TEID（CN Tunnel Info）**；
4. UPF在Response中返回该F-TEID，SMF将其作为N9隧道端点；
5. 此时UPF的下行（向UE方向）隧道端点（N3 DL F-TEID）尚未确定——需等AN建立完成后回填。

```text
graph TD
    subgraph UPF侧N4 Session(SEID)
        PDR["PDR<br/>Source IF=Core(N6)<br/>UE IP / SDF<br/>去外层头"]
        PDR2["PDR<br/>Source IF=Access(N3)<br/>N3 F-TEID"]
        QER["QER<br/>QFI=9, Gate=Open<br/>Session-AMBR限速"]
        FAR1["FAR(下行)<br/>FORW→Access<br/>OuterHdr=N3 F-TEID<br/>(待AN回填)"]
        FAR2["FAR(上行)<br/>FORW→Core<br/>OuterHdr=N6"]
        URR["URR<br/>Volume计量<br/>周期上报"]
        PDR --> QER --> FAR1
        PDR2 --> QER
        PDR --> URR
        PDR2 --> FAR2
    end
    style FAR1 fill:#fff3cd
```

> **抓包识别**：在Wireshark中，N4对应 **pfcp** 协议，可通过`pfcp.msg_type == 50`（Session Establishment Request）定位建立消息，`pfcp.msg_type == 51`为Response。展开`pfcp.pdr`/`pfcp.qer`/`pfcp.far`/`pfcp.urr`即可看到上述IE。

---

## 七、阶段六+七：N1N2下发、N2资源建立与下行隧道回填

### 7.1 N1N2消息下发（Namf_Communication_N1N2MessageTransfer）

SMF完成N4会话建立并分配UE IP后，调用 **`Namf_Communication_N1N2MessageTransfer`** 向AMF同时下发：

- **N1 SM消息**（给UE）：`PDU Session Establishment Accept`，含 UE IP Address、Selected PDU Session Type、SSC mode、**QoS Rules**（UE侧QoS Flow到SDF的映射，TS 24.501 9.11.4）、Session-AMBR、DNN、S-NSSAI、QoS Flow List。
- **N2 SM信息**（给(R)AN）：`PDU Session Resource Setup Request Transfer`，含 **QoS Flow List with QoS Profile**（5QI、ARP、GBR）、**N3 UL F-TEID**（UPF侧N3隧道端点，gNB据此封装上行GTP-U）、PDU Session ID、PDU Session Type。

### 7.2 N2 AN资源建立与DRB

AMF将N2信息通过 **N2 PDU Session Resource Setup Request**（NGAP，TS 38.413）发给gNB。gNB：
1. 解析QoS Flow List，按5QI执行**DRB映射**（TS 38.331 RRC）；
2. 向UE发送 **RRC Reconfiguration** 建立对应DRB与SDAP/PDCP实体；
3. 完成后通过 **N2 PDU Session Resource Setup Response** 返回 **AN Tunnel Info（N3 DL F-TEID）**——即gNB侧N3隧道端点。

### 7.3 下行隧道回填（关键易错点）

AMF将AN Tunnel Info通过 **`Nsmf_PDUSession_UpdateSMContext`** 回传给SMF。SMF随即执行 **N4 Session Modification**，更新UPF下行FAR的Outer Header Creation为该AN Tunnel Info。

**至此，端到端用户面才真正打通**：UE上行报文经DRB→gNB→N3(UL F-TEID)→UPF→N6→DN；DN下行报文经N6→UPF→N3(DL F-TEID=gNB)→gNB→DRB→UE。

> **常见故障**：若AN建立失败（无线资源不足/DRB建立失败），gNB在N2 Response中返回`Unsuccessful Resource`，SMF收到UpdateSMContext后需决定是否回滚N4会话或保持（等UE重试），具体见TS 23.502 4.3.2.2.1 step 14-18。很多"信令成功但ping不通"的案例，根因是N4 Modification未正确回填AN F-TEID，导致UPF下行报文被FAR丢弃。

---

## 八、状态转换与失败处理

PDU会话在其生命周期内经历若干状态，SMF维护的SM Context状态机（结合TS 23.502与实现实践）如下：

```mermaid
stateDiagram-v2
    [*] --> No_SmContext: CreateSMContext到达前
    No_SmContext --> Pending: 收到CreateSMContext<br/>(取签约/建Policy)
    Pending --> Active: N1N2下发成功<br/>且N4建立完成
    Pending --> Rejected: 签约/切片/PCF拒绝<br/>(返回Cause)
    Active --> Inactive_Downlink: AN资源释放<br/>(UE空闲/DDN)
    Inactive_Downlink --> Active: Service Request恢复N3
    Active --> Modifying: PDU Session Modification
    Modifying --> Active: 修改完成
    Active --> Released: PDU Session Release
    Inactive_Downlink --> Released: 释放
    Rejected --> [*]
    Released --> [*]
```

PDU会话建立可能返回的典型N1 SM Cause（TS 24.501 9.11.3.2）：`#27 DNN_NOT_SUPPORTED_OR_NOT_SUBSCRIBED`、`#28 INSUFFICIENT_RESOURCES_FOR_SPECIFIC_SLICE_AND_DNN`、`#67 INSUFFICIENT_RESOURCES_FOR_SLICE_AND_DNN`、`#73 SERVICE_NOT_ALLOWED`。抓包定位可在`nas_5gs.sm_cause`字段确认。

---
## 十、常见问题

**Q1: PDU会话建立和PDU会话修改的区别是什么？**
A: 建立（TS 23.502 4.3.2.2.1）是从零创建SM Context、N4 Session、N3隧道与DRB的完整流程；修改（4.3.3）是在已有PDU会话上调整QoS Flow、新增/删除专用QoS Flow、改变计费或转发规则，只触发N4 Modification与可选的N2修改，不重建SM Context。

**Q2: 默认QoS Flow是怎么来的？PCF没下发PCC规则怎么办？**
A: SMF用UDM签约的默认5QI和Session-AMBR构造默认QoS Flow（通常是Non-GBR的5QI=9），即使PCF未下发动态PCC规则，SMF也会生成默认PDR/QER/FAR/URR下发UPF，保证"尽力而为"连通性。这对应TS 23.501 5.7.1与free5GC中`precedence=255`的默认路径逻辑。

**Q3: N4的PDR/QER/FAR/URR可以不下发URR吗？**
A: 可以。URR（计费）是可选的。若该会话不计费或仅离线统计，SMF可不下发URR或下发简化版。但商用网络中计费是刚需，通常PDR/QER/FAR必备、URR按计费策略选择性下发。

**Q4: SMF选择和UPF选择都是SMF做的吗？**
A: 不是。**SMF选择由AMF完成**（基于DNN+S-NSSAI+签约+NRF），**UPF/PSA选择由SMF完成**（基于DNAI+切片+SSC+负载+UE位置）。两者是"AMF选SMF、SMF选UPF"的级联关系，分属不同网元的职责。

**Q5: 为什么N4会话建立后用户面还没通？**
A: 因为N4建立时gNB的N3 DL F-TEID（AN Tunnel Info）尚未产生。必须等gNB完成DRB建立、通过N2 Response返回AN Tunnel Info，再经SMF的**N4 Session Modification回填下行FAR**后，UPF才知道下行报文往哪发。这一"回填"步骤是初学者最易遗漏的环节。

---

## 参考来源
1. [3GPP TS 23.502 V18.x — Procedures for the 5G System, Section 4.3.2.2.1 UE-initiated PDU Session Establishment](https://www.3gpp.org/dynareport/23502.htm) — PDU会话建立信令流程定义
2. [3GPP TS 23.501 — System architecture for the 5G System, Section 6.2.2/6.3.2/6.3.3](https://www.3gpp.org/dynareport/23501.htm) — SMF功能、SMF/UPF选择机制
3. [3GPP TS 29.244 — Interface between SMF and UPF (N4) PFCP Protocol](https://www.3gpp.org/dynareport/29244.htm) — N4 PDR/QER/FAR/URR IE规范
4. [ShareTechnote — 5G Core SMF and UE-Initiated PDU Session Establishment](https://www.sharetechnote.com/html/5G/5G_Core_SMF.html) — SMF交互与流程图解
5. [free5GC Blog — Mapping PCC Rules into Session Rules (2024-11-13)](https://free5gc.org/blog/20241113/20241113/) — ApplyPccRules源码级PCC→Session规则映射

---
> 本文由「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)