企业官网建设流程全解析

5G 网络的会话性管理上下文对比介绍

做核心网技术这些年，每次跟人聊起5G的会话管理，我总要先提醒一句：别再用4G那套“承载上下文”的脑子去想5G的问题。标题里这个“会话性管理上下文”，说白了就是5G核心网里跟PDU会话相关的全套状态与配置——从UE跟网络建立的那条“数据通道”开始，到中间经过哪些网元、转发规则长什么样、QoS怎么保障、切换时怎么迁移，全都要靠一套比4G精细得多的上下文体系来支撑。

这篇文章就是想把5G会话管理上下文这摊事彻底讲透，重点跟4G时代的EPS承载上下文做逐项对比。对刚接触5G核心网的研发、测试和运维同学来说，这篇能帮你把SMF、UPF、AMF、PCF这几个网元之间“各自管什么上下文、怎么配合”这条主线理顺；对已经有一定基础的同学，里面也有些实际调测中才会撞上的坑和排查思路可以当参考。

什么是PDU会话上下文？举个例子：智能手机通过5G上网，网络给它分配一个IP地址，并在核心网里为这个地址建立一条逻辑通道。这条通道的编号、归属用户、接入的DNN、使用的UPF、绑定的QoS规则、IP地址租约、计费状态，全部合在一起，就是这条会话的上下文。如果UE走的是VoNR打电话，那还会有一条IMS会话，上下文参数里就多了语音相关的专用承载信息。

提示：5G里的“PDU会话”可以看作4G“PDN连接”的进化版。PDU（协议数据单元）提供的是一种更通用的“数据管线”能力，不只是IP包，Ethernet帧、非IP报文也能承载，这是5G往后支持工业控制、车联网这类场景的基础。

1. 为什么5G要重新定义“会话上下文”

1.1 从“承载”到“会话”：4G时代的会话管理画像

要说清楚5G的改动，得先把4G的家底翻出来。4G核心网里，UE附着后先建默认承载，再按业务需求建专有承载。承载是分层的：无线侧有DRB，传输侧有S1-U承载，核心网侧有S5/S8承载。每一层承载在网元里都有对应的表项。MME管的是移动性上下文和EPS承载上下文，SGW和PGW各自保存S5/S8接口的GTP-U隧道上下文。这个体系本身是闭环的，能跑，但问题也很明显。

首先是僵化。PGW是用户面的唯一锚点，UE的IP地址绑定在PGW上，一旦PGW部署位置离用户远，业务时延就压不下来。其次是耦合，控制面的承载管理和用户面的转发规则是绑在一个“承载”概念里的，想单独调整某个转发路径很费劲。最麻烦的是上下文分散，UE的会话信息散落在MME、SGW、PGW多个节点上，接口协议又多，排障时要在好几个网元抓信令挨个对表项。

1.2 5G服务化架构对上下文管理的倒逼

5G核心网引入SBA（服务化架构），核心原则是把网络功能拆成独立服务，通过HTTP/2接口互相调用。这个改动一落地，会话管理的责任就重新分工了：SMF专门负责会话级控制，AMF负责注册和移动性管理，UPF只干活不决策，PCF/UDM则提供策略和签约数据。上下文不再是“每个网元存一份”，而是“每个网元按职责存自己需要的那一份”。

这带来的好处是接口简化了。4G里MME跟SGW之间要维护GTP-C隧道，SGW跟PGW之间还要维护一套GTP-C和GTP-U。5G里这些隧道关系大幅简化：N4接口上SMF和UPF之间用PFCP协议管理会话，N2接口上AMF和基站（gNB）之间通过NGAP消息管理会话上下文。网元之间的接口更扁平，信令交互就更好跟踪。

1.3 一句话看懂“会话性管理上下文”是什么

我个人习惯把它拆成四个层面来理解。

• UE侧上下文：UE内存里维护的PDU会话状态，包含会话ID、QoS规则、IP地址，以及和网络侧协商的会话参数。注意，UE侧不知道UPF的地址，也不关心路径怎么走。
• 接入网侧上下文：gNB里针对这个UE、这条PDU会话保存的N3隧道信息、QoS Flow到DRB的映射关系。这里上下文是面向空口和用户面传输的。
• 核心网控制面上下文：SMF是总维护者。PDU会话ID、SUPI、DNN、切片信息（S-NSSAI）、IP地址、QoS规则、PFCP会话状态、会话连续性模式，全在SMF里有记录。
• 核心网用户面上下文：UPF里保存的转发规则（FAR）、包检测规则（PDI）、QoS执行规则（QER）、计费规则（URR），以及N3/N9/N6隧道的TEID信息。

把这四个层面合起来，就是一份完整的“会话性管理上下文”。4G的承载上下文只覆盖了其中两个层面，而且没有像5G这样把用户面规则独立出来。所以我说5G这套是一次模型级的重构，不只是换个叫法。

2. 5G会话管理上下文的核心组成与交互关系

2.1 SMF：会话管理的总控中心

SMF在5G里就是“会话的大脑”。UE发起PDU会话建立请求后，SMF要执行一整套动作：从UDM取签约数据、向PCF要策略、为会话分配IP地址、选择UPF并下发转发规则、通过AMF把无线侧配置转发出去。这一整套过程中产生的中间状态，全部属于SMF维护的SM上下文。

SMF内保存的关键上下文包括：SUPI（用户永久标识）、PDU会话ID（0到15，UE范围唯一）、DNN、S-NSSAI、IP地址（或前缀）、QoS规则（含ARP优先级）、PFCP会话ID、UPF节点信息、SSC模式、以及用户面隧道终点信息。跟4G的PGW相比，SMF多了一个重要能力：动态选择UPF。而且能根据业务场景建立“多锚点”会话。

一个反直觉的细节：SMF并不保存所有业务的完整包过滤规则。数据包怎么识别、怎么做标记，主要交给UPF执行，SMF只负责下发规则。所以排查问题时分清“决策”和“执行”两个层面非常关键，别一上来就在UPF上找策略逻辑。

2.2 AMF上的UE级上下文与SM上下文的配合

AMF的职责不是管会话，而是管“这个UE现在在哪、能不能找到它”。它保存的是UE上下文，包括注册状态、当前所在TA、允许的切片列表、以及为这个UE建立的所有PDU会话ID列表。但会话的详细参数在AMF上是不全的，AMF只保留一个“会话索引”，真正要查细节得去SMF。

这种分工经常让初学者困惑：在信令流程里，N1/N2消息都经过AMF中转，AMF看到的内容其实比较有限。比如UE发起PDU会话建立请求，AMF只知道“这个用户要建一条新会话”，具体的DNN、QoS参数它不解析。它做完接入和鉴权校验后，把消息转给SMF就算完成角色。AMF上下文与SM上下文的关系，就像前台登记簿和后台档案室——前台只记编号，档案都在后台。

这里有个实操中的易错点：排查时看到AMF日志里有PDU会话建立失败，不要直接在AMF上翻会话详细参数，要顺着UE上下文里的SMF ID去找对应SMF的日志。

2.3 UPF侧的用户面上下文：N3/N9/N6隧道

UPF是5G会话上下文里最“实”的一层，它直接处理数据包。UPF维护的上下文分为两部分：接口隧道上下文和规则上下文。

接口隧道上下文包括：N3接口上与gNB通信的GTP-U隧道（上行TEID和下行TEID）、N4接口上与SMF通信的PFCP会话、N6接口上通往外部数据网络的接口信息，以及N9接口上与其他UPF级联时的隧道信息。

规则上下文就丰富了：包检测规则（PDI）定义了什么样的包走这条会话，转发规则（FAR）定义了包该被封装的隧道、该标记的QFI，QoS执行规则（QER）定义了带宽、门控、最大包长等，计费规则（URR）定义了对业务流怎么统计。整个UPF上下文的结构，可以类比成一套“快递分拣规则”：检测规则是这个包裹长什么样，转发规则是它该走哪条传送带，计费规则是这个包裹要过几次秤。

2.4 UDM/PCF：会话级签约与策略上下文

UDM和PCF不属于“会话管理的直接执行者”，但它们提供的输入会直接影响会话上下文内容。UDM保存签约数据，包括每个DNN下允许的会话类型、默认QoS、最大带宽等。SMF建立会话时，必须先从UDM取到这些数据，否则拒绝请求。

PCF通过策略关联为每个会话下发策略。这里包含：会话聚合最大比特率、默认QoS规则、以及被叫侧/主叫侧计费相关策略。而且PCF策略是动态的，比如用户套餐突然降级，PCF能主动推送新策略，SMF收到后更新上下文，UPF上的QoS限速也会实时变化。

注意：PDU会话建完后，SMF、UPF、PCF之间的上下文彼此不是静态拷贝，而是通过会话管理策略更新（如PFCP Session Modification）持续同步。调试时如果只改了一边的配置，忘了触发另一边的更新，就会出现“会话看起来正常、实际转发异常”的隐患。

3. 4G与5G会话管理上下文逐项对比

3.1 架构模型：紧耦合承载 vs 服务化会话

4G把所有跟会话相关的功能揉在一个“EPS承载”模型里。MME建承载、SGW传节点、PGW给IP、HSS供签约。接口协议是GTP-C、GTP-U、Diameter。4G的会话上下文是按“Bearer ID”这个核心字段组织的，Bearer ID在S1和S5/S8接口上对应不同的TEID值，整个会话的生命周期管理脱不开GTP这个协议框架。

5G的会话模型是“服务化”的，PDU会话由SMF独立决策，UPF独立执行。接口协议以PFCP和HTTP/2为主，N4接口用PFCP维护会话活性，服务化接口用JSON格式传递结构体。5G的上下文具有更强的可扩展性——比如多PDU会话、会话和切片绑定、MEC本地分流，都是在旧模型里很难优雅实现的能力。

用一句话概括：4G的会话上下文是“管道路由表”风格，5G的是“微服务状态管理”风格。

3.2 粒度差异：Bearer vs QoS Flow

4G的QoS粒度是Bearer级别的。每一条业务流的TFT（流量模板）描述了哪些IP包要进哪条承载，核心网按承载给空口配置QCI。如果业务流量比较复杂，需要多条承载、多套TFT，管理和切换的成本都会上升。

5G引入QoS Flow概念，类似把Bearer继续细分。一条PDU会话里可以同时存在多个QoS Flow，每个Flow有一个QFI（QoS Flow ID），承载不同的QoS需求。gNB可以在空口侧把多个QoS Flow映射到同一个DRB里，这在4G里是做不到的——4G里一个DRB对应一个承载的绑定关系比较固定。

这个差异对上下文管理的影响很大。5G的UPF在做包转发时不关心空口DRB是什么，只关心包上打的QFI标记；gNB负责QFI到DRB的映射。所以排查问题时，用户面丢包、调度异常还是QoS规则下发错误，能更快定位到具体网元层。

3.3 状态存储：分布式表项 vs 结构化状态机

4G各网元间的状态同步，依赖GTP-C消息里的“Create Bearer / Modify Bearer”这类操作来增删改查。一旦信令丢了或超时，网元间对不上表项，就会出现“MME认为承载存在、PGW认为不存在”的悬空状态。这类问题在4G现网里太常见了，排查起来要么重启MME，要么手动删承载。

5G的状态存储明确按网元职责划分：AMF只管注册状态，SMF管会话生命周期，UPF管转发规则。每个网元都实现自己的状态机，比如SMF里会话状态包括“PDU会话建立请求已接受”“激活中”“已释放”等。配合服务化接口，其他网元能实时查询会话状态，数据一致性比4G的分布式GTP表项高得多。

再补充一点：5G PFCP协议里有会话报告机制，也就是UPF（用户面功能）发现异常时能主动上报给SMF。这条反馈通道在4G里几乎没有。

3.4 会话连续性：4G的“尽力而为” vs 5G的SSC模式

这个点最能体现5G“为业务场景而设计”的思路。4G的会话通常绑在固定PGW上，UE跨大区移动时，PGW不变，IP地址不变，但转发路径可能变得很长。这种设计假设“IP不能变”。可到了5G，URLLC、MEC、车联网等场景对路径最优和数据本地化要求极高，IP地址保持不变不再是唯一目标。

5G定义SSC模式1、2、3。

• SSC模式1：IP锚点不变，会话始终保持在原UPF，适合普通手机业务，和4G行为类似。
• SSC模式2：允许UE重新选择UPF，会话先释放再重建，IP地址可能会变化。适合移动办公、视频流这类能接受短时断档的场景。
• SSC模式3：会话在新老UPF之间“先建后断”，做到不断网的情况下迁移IP锚点。适合车联网、实时在线游戏这类对连续性要求苛刻的场景。

SSC模式的切换逻辑全部在SMF上下文里管理，UPF和AMF不感知SSC类型。这个“状态在控制面、执行在用户面”的设计，也是5G能实现灵活连续性控制的关键。

下面用一个表格把核心对比项汇总一下。

这个表只是一个速查。真正理解差异，还是要把自己放进三种真实业务场景里：普通手机上网、边缘计算本地分流、车联网频繁跨区。用同一个“会话”思维去推，就会发现4G那套逻辑在不同场景下会有多吃力。

4. 典型流程中的上下文创建与迁移实测

4.1 PDU会话建立：三步看懂N1/N2/N4信令

一次完整的PDU会话建立，是了解5G会话上下文的最好教材。我拆成关键节点说一下。

第一步，UE通过N1接口发PDU Session Establishment Request，里面带上PDU会话ID、DNN、请求的S-NSSAI、以及会话类型（IPv4/IPv6/Ethernet）。AMF收到后先检查UE上下文里有没有禁止该切片的签约，然后选一个合适的SMF。AMF向SMF发请求时，会带上SUPI、DNN、S-NSSAI等参数。

第二步，SMF开始决策。SMF查UDM拿签约数据，确认这个用户能不能在这个DNN下建会话；再向PCF请求策略；然后为会话分配IP地址。SMF选择UPF时，要考虑拓扑位置、切片能力、负载情况。选完UPF后，SMF通过N4接口发送PFCP Session Establishment Request，里面包含PDI、FAR、QER、URR等一套规则。

第三步，UPF回复PFCP Session Establishment Response，携带分配的N3 TEID。SMF把无线侧配置和核心网侧配置合成一条N2 PDU Session Resource Setup Request，通过AMF发给gNB。gNB成功分配空口资源后，用户面隧道双向打通，整条会话上下文创建完成。

我在某实验室抓过一次完整信令，印象很深的是N4接口的PFCP报文里光PDI就包含5个完整字段组。生产环境里，一个PDU会话可能同时下发几套FAR，对应不同业务流的不同出口。做联调时一定要学会过滤抓包，只看PFCP消息里跟会话ID相关的字段，别被一大片无关信令淹没。

4.2 系统间切换时的上下文映射规则

5G和4G互操作是现阶段绕不开的课题。UE从5G覆盖走进4G覆盖，核心网侧要做一次“PDU会话映射为EPS承载”的上下文转换。这个过程发生在SMF和PGW-C之间，N26接口可选但强烈建议部署。

映射的关键点分三层。第一层，会话标识映射：把PDU会话ID映射为EPS Bearer ID，默认承载和默认PDU会话一一对应。第二层，QoS流映射：每个QoS Flow映射到一个EPS承载，EPS承载的QCI由5G的5QI映射得出。第三层，上下文归属转移：原来存于AMF的UE上下文移交MME，SMF侧通过PGW-C+SMF合设或互通接口继续沿用。

实际现场最常见的问题，是两侧核心网对QoS映射规则的理解不一致。有一次现网调测，5G侧给某业务下发了5QI=3（实时语音类），映射到4G侧时按默认表格转成QCI=3，看起来没错，但对方MME里QCI=3的承载不支持某种RRC状态下的数据转发，导致语音业务在切换后单向通话。后来改了映射规则，单独用QCI=1处理，问题才消掉。所以做互操作测试时，别只盯着切换成功、IP没变就完事，要把切换后的QoS执行情况实际测一遍。

4.3 双连接场景下的上下文分支与合并

5G里的双连接（EN-DC）会让会话上下文出现“分支”现象：用户面既有4G路径也有5G路径。会话的主上下文仍在SMF和PGW-C侧，gNB和eNB各自维护着N3或S1-U下行隧道。

这种场景做反馈排查时，要看清“用户面的数据在哪个网元上拐了弯”。比如UE同时在LTE和NR下工作，主、辅站的承载分别通过不同隧道把数据送到核心网。查阅UPF上的转发规则时，可以看到同一个PDU会话对应两条不同的FAR，一个指向LTE侧TEID，一个指向NR侧TEID。如果某个方向不通，要注意可能是“会话在UPF上正常但基站侧隧道未激活”的典型情况。

4.4 实操参数示例：抓包里如何锁定会话上下文

拿一次IP地址下发过程举例。UE建会话时，SMF通过N1接口发送PDU Session Establishment Accept，里面包含UE分配的IP地址、QoS规则。抓包时观察到的信息顺序是：先有QoS规则，后有IP地址；IP地址是SMF通过UPF分配的（UPF的UE IP地址池）。若抓包里没有看到“PDU SESSION ESTABLISHMENT ACCEPT”，说明SMF未发成功或消息在N1链路丢失。判断依据就是“SMF上下文属性里的IP状态”是否从“空闲”走到了“已分配”。

另一处细节是观察N4接口的“心跳”和“会话报告”。如果PFCP链路正常但会话报告里出现“Usage Report”字段，计费可能触发端到端。不要小看这些字段，我见过一个现场，因为某个业务流匹配到了错误的URR规则，导致用户流量被统计到另一个套餐档位，用户投诉流量异常，最后排查下来就是上下文里URID绑定错位。

5. 常见问题与排查技巧实录

5.1 PDU会话建立失败的典型原因定位

PDU会话建立失败是5G核心网调测中出现频率最高的问题。按原因值有个快速定位路径：

• 错误原因在接入侧：比如gNB资源分配失败、N2消息应答超时。抓包从NGAP消息查起，看消息类型和cause值。
• 错误原因在核心网侧：比如签约数据不存在、DNN不允许、切片未授权。此类含义很直白，优先查UDM。常见场景是用户尚未开通某个DNN的权限，SMF一查签约数据直接拒绝。
• 错误原因在UPF侧：比如N4路径不通、UPF上行链路非激活、地址池耗尽。直观点就是SMF发出PFCP建立请求后，UPF不回响应或返回错误。一句提醒：N4链路调测永远是PDU会话建立前必须先做的“体检项目”。

5.2 N4会话异常导致的用户面不通

用户面不通但控制面显示会话正常，这是第二个高频坑。某次测试中，PDU会话成功建立，但UE ping不通外部网络。排查时发现SMF上下文显示会话状态为“激活”，UPF也显示“会话建立成功”，但N3隧道没有数据。后来抓包发现UPF的N3口根本没收到任何GTP-U包。

换个角度想，核心网侧的N4会话可能早就断了。PFCP协议有Session Report机制，如果UPF检测到N3链路异常，应主动上报SMF。但这个现场UPF没有上报，说明“会话异常”没有同步到“控制面状态”。考虑关闭PFCP的会话保持特性后重新加载UPF，问题解决。

这个场景给我们的教训就是：会话上下文的一致性不能只信状态机，还要看实际转发路径是否贯通。排查时，可以在UPF上发起一个“Ping测试”或“抓包测试”来确认隧道方向。千万别提着一个“会话正常”的结论就回去交差。

5.3 QoS Flow映射错乱与速率异常

用户反馈网速很慢，核心网侧却查不到明显拥塞。这类问题往往不是拥塞，而是QoS模板配置错误。5G的QoS规则里，每个QoS Flow都绑定一个5QI。数据包在UPF上被打上对应QFI，gNB按QFI找到对应DRB，再按调度参数执行。如果UPF上QFI映射错位，比如把视频业务流量打成了默认的QFI=9，那就会走默认的、非GBR的“尽力而为”队列，表现就是卡顿。

有个快速检查方法：在UPF上查看一条会话的所有QoS Flow，比对QFI与5QI的对应关系，再用端到端抓包确认数据包上的QFI标记。gNB侧映射如果错乱，常见原因是基站版本与核心网的“QFI映射表”不匹配。做新版本升级或基站更换时，建议顺手做一轮“QoS一致性拨测”，用几种典型业务各跑一遍，比事后看投诉高效得多。

5.4 切换后会话状态不一致

UE从一个gNB切换到另一个gNB时，目标基站会向AMF发起“Path Switch Request”。AMF把这个请求转给SMF，SMF更新N3隧道：把下行目的地址改成新gNB的TEID。如果SMF没有完成更新，数据会继续发往老gNB，UE在新基站下能收到随机性时通时断的流量。

判断方式很简单：切换前后分别抓N3接口包，对比下行GTP-U的目的IP和TEID。如果还是老值，定位在SMF未执行N4 Modify步骤；如果改了但数据仍然走老路径，则说明UPF的FAR没有真正更新。这种问题可能是因为UPF上PFCP缓冲队列堵塞，N4 Session Modification刷下去了但没执行。

注意：开功放抓包前，记得确认N3链路镜像口的位置。很多现场的核心网机房没有把UPF的N3口镜像出来，这会导致“核心网日志正常但用户面查不下去”的尴尬处境。建议把N3/N4口的镜像在开局时预先配齐，排障效率会大幅提升。

5.5 排查思路小结和工具习惯

把会话管理上下文的排查思路整理成几个顺手的原则：

• 先从UE侧确认“会话是否建立成功”，再逐层查AMF、SMF、UPF的日志。
• 控制面正常，先别急着看用户面；用户面包抓到了，再反过来验证控制面规则。
• 每个PDU会话都有一个唯一的PFCP会话ID，它在SMF、UPF、抓包软件中是同一把钥匙。定位时先找到它再展开。
• 用到“策略变更”类问题时，先确认PCF与SMF之间的策略关联是否触达。有的策略下发后SMF没有主动刷新UPF，导致UPF一直用旧规则。

我个人调测中最受用的习惯是，在同一台调试终端上同时开三个标签页：一个盯着N4接口的会话变更，一个盯着N2接口的上下文消息，一个开信令跟踪工具看UE状态。三个视图一起看，绝大多数会话问题都能在几分钟内定位出“卡在哪个接口”。

6. 往后扩展：从会话上下文到网络能力开放

聊完对比和排查，还想多说一句：会话管理上下文这套机制，影响的远不止“让用户能上网”。它实际上是整个5G网络能力开放的地基。比如MEC边缘分流，就是在UPF上下发“本地分流规则”，核心是给某类业务流打上特殊标记，再配一条指向本地应用的FAR。再比如面向企业的5G专网切片，本质就是“在会话上下文中绑定特定S-NSSAI和DNN”。

所以做5G核心网的同学，早一点把会话性管理上下文的结构和逻辑吃透，往后接触边缘计算、网络切片、车联网V2X这些场景都会走得很顺。“建立会话、维护上下文、按需调整规则”这套思维，几乎贯穿所有5G进阶功能的实现路径。希望这篇对比整理能对正在入门或已经踩坑的同行有一点帮助。