做5G核心网测试这行干得久了你会发现一个很有意思的现象5G网络里最容易被新手绕进去的概念不是波束管理不是毫米波而是“会话管理上下文”。尤其当你从4G的EPS承载思维切换到5G的服务化架构单是“上下文”这三个字就牵扯出UE侧、接入网侧、核心网控制面、用户面一大堆状态数据。网上讲5G的帖子很多但大多是把网元功能罗列一遍真正把“会话性管理上下文”讲清楚、做对比的少之又少。我这次聊的内容就是围绕5G会话管理上下文做一次高密度对比拆解4G时代怎么管会话5G时代怎么管会话两者底层差异在哪同一个PDU会话里UE、基站、AMF、SMF、UPF各自维护什么以及我在模拟项目X里实操抓包、看日志、排会话故障时踩过的坑。看完你至少能对三件事有把握会话上下文都存了什么分布在哪儿出问题时往哪个方向查。如果你是刚转5G核心网的开发者、测试工程师或者做协议栈开发的同学这篇文章可以当一份“会话上下文对比速查手册”用。内容不堆术语但该有的协议字段、状态机流程都会给到能帮你省下不少翻规范的时间。1. 项目概述5G会话管理上下文是什么为什么要做对比1.1 会话管理上下文到底是什么先把概念钉死。5G里的“PDU会话”PDU Session就是UE和网络之间的一条数据通路相当于4G时代的PDN连接。所谓“会话管理上下文”就是围绕这条数据通路在网络侧和UE侧保存的一组状态信息集合。它包括会话标识、DNN数据网络名称、切片信息S-NSSAI、QoS参数、用户面隧道信息、IP地址、计费关联信息等等。我习惯把它理解成一张“会话档案卡”。UE发起一个PDU会话SMF会开一张新卡把这条会话的所有关键属性填进去UPF拿到一张“转发规则卡”指示数据来了往哪走基站有一张“无线资源卡”告诉空口怎么调度UE自己留一张“轻量副本”只在发信令时用。四张卡不是孤立存在的它们通过NAS消息、NGAP消息、PFCP消息随时同步。一旦哪张卡上的数据对不上就会出现会话建立失败、数据不通、切换后业务中断这类问题。所以“对比介绍”的真正价值就是把这几张卡放在一张桌子上一张张对照看。只盯SMF日志看会话参数不看RAN侧上下文很多问题你是找不出原因的。1.2 这个对比的适用人群与场景这个内容适合三类人第一类是5G核心网测试工程师。天天抓信令面日志需要快速定位是SMF没下发QoS参数还是UPF没建隧道还是基站没接收PDU会话资源建立请求。第二类是协议栈开发者尤其是做NAS层、NGAP层、PFCP消息解析的同学。你需要清楚一份PDU Session Establishment Accept消息里的参数最终会被映射到哪个网元的哪个上下文表。第三类是刚入行的网络学习者。4G的EPS Bearer和5G的QoS Flow到底差在哪SSC模式1、2、3分别解决了什么问题单读规范容易晕。用对比的方式切入能少走很多弯路。在我做的模拟项目X里我们搭了一套“标准混合组网”环境5G核心网作为目标4G EPC作为对照组。目的很单纯同一个业务场景在两张网络里各跑一遍把会话管理相关的上下文抓出来对比。接下来我把整个对比过程拆成四个层面逐步展开。2. 两个时代的会话模型从EPS承载到QoS Flow的台前幕后2.1 4G时代的承载体系与上下文落点有5G经验的人很容易忽略一个事实4G网络的会话管理核心是“承载”Bearer而并非“连接”。一个PDN连接下默认承载Default Bearer保证基础连通性专用承载Dedicated Bearer保证差异化业务质量。所有数据跑在EPS Bearer上一条Bearer对应一套GBR保障比特率或Non-GBR参数、一个QCI等级、一组TFT流量模板规则。4G上下文的关键特征是“集中”。整个会话状态主要落在MME和SGW上。MME保存的是NAS层的PDN连接上下文包括APN、IP地址、默认承载QCI、PGW地址等SGW和PGW保存的是用户面隧道上下文包括TEID、S5/S8接口IP、承载级QoS参数。基站侧也有S1承载上下文但相对简单本质是数据无线承载DRB和S1-U隧道的一对一映射。有一个比较容易被新手忽略的地方4G的会话管理是“以承载为颗粒度”的。也就是说上行数据包到PGW后PGW按TFT匹配决定数据走哪条专用承载空闲态下MME要维护所有承载的保持状态。链路一多MME的上下文表size膨胀得很快。2.2 5G的PDU会话与QoS Flow模型5G把这套思路整体重写了。5G不再叫PDN连接改叫PDU会话核心操作单位从“Bearer”变成了“QoS Flow”。PDU会话里先有默认QoS Flow之后可以建立多个专用QoS Flow。5G QoS Flow比4G Bearer更灵活它不再绑定固定的隧道组合而是一组带QoS特性的数据流集合可以动态映射到同一个DRB上也可以重新映射到另一个DRB。也就是说空口的DRB和核心网的QoS Flow之间是多对多的关系而不是4G那种一对一的硬绑定。会话上下文的落点也明显变了。MME的职责被拆掉移动性管理功能放AMF会话管理功能放SMF。AMF只保留UE级上下文比如UE的注册状态、CM状态、NAS连接信息它不关心PDU会话的QoS细节SMF是会话上下文的“主控方”PDU会话的创建、修改、释放都由它发起和协调。UPF也不再只是转发它维护着“停靠规则”“转发规则”这些被称为“会话上下文”的关键部分。2.3 EPS承载与QoS Flow的核心差异对照表这里我把两套模型放在同一张表里直接对比方便大家抄作业对比项4G EPS承载模型5G QoS Flow模型最小管理单位EPS Bearer默认/专用QoS Flow会话名称PDN连接PDU会话QoS参数QCI、ARP、GBR/MBR5QI、ARP、GFBR/MFBR承载与DRB映射一对一多对多数据流分类TFT匹配QoS规则/包检测规则控制面主控网元MME移动性会话混合AMF管移动性SMF管会话用户面锚点SGWPGW分两层UPF可多级部署核心网接口S11、S5/S8、S1-U服务化接口PFCP(N4)空闲态上下文保存MME/SGW/PGWAMF/SMF/UPF/RAN按需保留看这张表至少能回答一个问题为什么很多人说5G比4G“灵活”。因为4G的会话上下文本质上是一个“树状结构”一个PDN连接下挂一堆Bearer每层都要建隧道链路状态必须严格对应5G的会话上下文更像“规则集合”QoS Flow是逻辑颗粒真正干活的转发路径由UPF按规则生成RAN侧只关心QoS Flow到DRB的映射关系。这个差异直接影响到后面所有排障逻辑。3. 同一场会话五张“小抄”UE、RAN、AMF、SMF、UPF各自维护什么3.1 状态机与上下文的关系RM、CM、PDU会话状态要理解上下文的保存方式必须捎带提一下状态机。5G核心网管理UE有注册管理状态RM-DEREGISTERED / RM-REGISTERED和连接管理状态CM-IDLE / CM-CONNECTED。这两个状态是UE级上下文的核心维度存的位置在AMF。PDU会话状态则是会话级维度主要由SMF维护常见的有PDU会话建立中、已建立、已释放、待激活等。UE侧也保存PDU会话状态表示这个终端是否认为自己有一条可用会话。如果UE侧状态和SMF侧状态不一致大概率就是上下文失步。实际排查中我们见过“UE显示已连接SMF显示会话不存在”的情况。本质原因是UE在CM-IDLE状态时RRC连接释放后SMF把不活跃的会话上下文保留一段时间但某些异常流程下AMF收到UE的新业务请求后没有携带原PDU会话IDSMF就会按“未知会话”处理。所以五张“小抄”必须同步这个原则无论4G还是5G都一样。3.2 各网元上下文清单我用一张图能说清的事不用流程图直接列清单UE侧上下文当前PDU会话ID、DNN、S-NSSAI会话对应的IP地址和QoS规则映射到哪个DRB以及NAS层的PDU会话状态5G-SM状态PDU会话建立请求是否收到响应RANgNB侧上下文PDU会话ID以及该会话相关的QoS Flow列表每个QoS Flow与DRB的映射关系NG-U隧道信息gNB侧TEID、UPF侧TEIDNGAP关联IDAMF侧UE NGAP ID、gNB侧UE NGAP ID空口承载配置RLC/MAC逻辑信道配置AMF侧上下文UE的注册信息、CM状态、RM状态与UE之间的NAS连接信息已注册的PDU会话ID列表不存QoS细节与SMF之间的服务化接口关联信息SMF侧上下文PDU会话最完整的数据DNN、切片、签约信息、IP分配策略QoS参数5QI、GFBR/MFBR、ARP优先级会话的转发规则列表PDR、FAR、QER由SMF下发UPF与UPF的用户面隧道关联N4会话参数策略控制关联与PCF交互的会话数据UPF侧上下文N4会话标识检测规则PDR匹配哪些数据包转发规则FAR匹配后怎么处理QoS执行规则QER限速/标记隧道端点信息远端TEID本地TEID这里特别强调一下在5G服务化架构里SMF并不直接存有全部上下文的数据副本它存的是“会话控制信息”真正的“用户面上下文”在UPF里。测试的时候如果你只抓SMF的PFCP消息看不到UPF内部结构必须连UPF的转发面统计一起看才能形成完整证据链。3.3 建立与释放的关键流程一个典型PDU会话建立流程的上下文流转可以这么理解UE发PDU Session Establishment Request经过gNB转发到AMF。AMF查询UE上下文确认UE注册状态、切片权限然后把请求路由给合适的SMF。SMF收到后做签约检查、策略交互分配IP地址通过PFCP Session Establishment Request请求UPF创建会话上下文。UPF反馈PFCP Session Establishment Response带上自己的TEID。SMF再通过Namf_Communication或N1N2MessageTransfer把N1消息PDU Session Establishment Accept和N2消息PDU Session Resource Setup Request推给AMFAMF转给gNB。gNB收到N2消息后建立DRB配置完成空口资源分配再回N2 PDUSession Resource Setup Response。到这一步UPF的TEID、gNB的TEID都齐了一条可用的数据链路打通。释放流程则是反过来的“拆卡”。UE想会话发PDU Session Release RequestSMF通知UPF删掉N4会话上下文通知AMF释放N2资源最后AMF给gNB下PDU Session Resource Release Command。这个过程中最容易出现上下文不一致的节点有两个一是PFCP消息中的TEID与NGAP消息中填的下行TEID不匹配二是SMF释放完UPF上下文后N2释放迟迟没结束。前者会导致用户面数据丢给一个“没人接”的隧道端点后者会让基站还一直往下发数据。3.4 服务化接口下的查询与修改5G把传统点对点接口改成了服务化接口会话上下文的操作也变成常态化的增删改查Nsmf_PDUSession_Create创建会话上下文Nsmf_PDUSession_Update更新会话上下文比如QoS改动Nsmf_PDUSession_Release删除会话上下文Nsmf_EventExposure订阅会话状态变化这意味着会话上下文不仅是网络内部的数据还能通过服务化接口主动暴露给其它网元。例如AMF订阅SMF的PDU Session状态变更事件一旦UPF报会话异常SMF就能把事件推给AMF实现从“被动查到”变成“主动感知”。从测试视角看这套服务化机制带来一个新排查方式不一定要抓底层包可以直接调用服务化接口查看某个PDU会话的当前状态字段。模拟项目X里我们就是这么做的抓不到空口日志时直接调SMF的Nsmf接口查询会话详情能很快看到QoS参数、状态码和last known cause。4. 会话连续性、锚点与服务化改造会话管理的深度对比4.1 会话与服务连续性SSC模式5G把“维持会话还是重建会话”这个选择题正式化定义了三种SSC模式这是对比4G时非常值得关注的一块因为4G基本只有“保锚点”这一种玩法。SSC模式1UE移动时PDU会话锚点UPF保持不动相当于整个会话期间IP地址不变适合低时延、长连接业务。代价是数据可能绕路。SSC模式2当业务搬移到新站点附近网络会先把原会话的PDU会话释放掉再在新UPF建立一条新会话IP地址可能变化。适合对IP不敏感的业务比如大文件下载能明显优化路径。SSC模式3先在新UPF建立新会话同时保留旧的会话一小段时间让IP地址变化不产生断流。适合需要优雅过渡的业务比如视频通话中的媒体路径切换。三种模式对比下来核心点是“用户面锚点UPF上下文的管理策略不同”。模式2的切换中SMF要发起“释放新建”两个会话流程模式3则需要SMF在同一时间维护两个UPF上下文还对计费和QoS协调提出更高要求。做测试时三模之间最容易测出差错的点是旧会话UPF还没删干净新会话UPF已建立两个UPF同时导流导致双隧道冲突。4.2 切片、DNN与多接入的并存5G会话管理里S-NSSAI网络切片标识和DNN一起组成会话的路由标识。同样一个PDU会话如果S-NSSAI不同可以走完全不同的SMF实例和UPF实例。这是4G没有的“软切片”维度。实操时创建PDU会话请求里如果带了多个S-NSSAISMF只能挑自己能服务的切片来响应。如果AMF选SMF时没注意切片匹配就会产生“3GPP规范里叫SMF selection失败”的异常。另外5G ATSSS接入流量转向、切换与分流支持同一PDU会话同时跑在3GPP和非3GPP接入上比如Wi-Fi和5G同时在线。这时SMF要维护两个接入网侧的上下文把它们映射到同一份用户面策略上。相比之下4G不大会有这种“双接入上下文并存”的麻烦。4.3 漫游与本地转发另外一个对比点是漫游会话管理。4G漫游时会话上下文往往要通过归属网络的PGWHPLMN建立绕路明显。5G里的多归属架构允许SMF和UPF更灵活分布会话在某些场景下可以本地分流LBO也可以在归属地构建端到端会话HR。这直接影响UPF上下文存储在归属地还是拜访地。测试漫游场景时最常见的问题就是拜访地SMF和归属地PCF之间拿不到策略导致SMF建立会话时缺少一些必要的QoS参数。这种问题从上下文内容角度观察就是“被建立PDU会话里QoS参数不完整”。排查思路不是看空口而是查PCF返回的策略授权值看是签约数据没同步还是服务化调用超时。5. 模拟项目X实操如何抓一份会话上下文日志并读出关键信息5.1 抓包与日志采集实操环节我用模拟项目X的真实环境来说。我们要做的第一步是确定日志采集点。会话管理上下文相关的日志主要来自四个位置UE侧通过终端Modem日志看NAS层的PDU Session流程RAN侧gNB的操作维护日志看NGAP消息解析核心网控制面AMF/SMF日志看服务化接口调用记录用户面UPF日志看PFCP会话建立和转发规则下发记录在这个环境里我们当时用了一套信令跟踪工具同时抓N1/N2/N4三层的消息。抓包不复杂难点在于对齐几个日志事件的时间戳。实际经验是先用秒级时间戳粗对再根据消息ID和事务ID细对。只有对上事务ID你才能确定某段PFCP消息和某条NGAP消息属于同一个PDU会话。5.2 构造一份PDU会话建立日志下面是一段经过脱敏和简化的PDU会话建立日志字段是我根据实际环境格式调整过的可以直接当样例参考12:03:22.105 UE-AMF NAS PDU_SESSION_ESTABLISHMENT_REQUEST PDU session ID: 5 Request type: Initial request S-NSSAI: 1-010203 DNN: internet 5G-SM capability: IPv4 12:03:22.208 AMF-SMF POST /nsmf-pdusession/v1/sm-contexts Global UE AMF ID: {AMF ID, UE AMF ID} Supi: 99901XXXXXXXXXX PDU session ID: 5 DNN: internet S-NSSAI: 1-010203 12:03:22.342 SMF-UPF PFCP SessionEstablishmentRequest N4 Session ID: 88 PDR: UE_IP - 10.20.0.2/32 FAR: Action FORWARD QER: GateOPEN, MBR/GFBR5Mbps 12:03:22.370 UPF-SMF PFCP SessionEstablishmentResponse N4 Session ID: 88 Cause: Success F-TEID: UPF-S5U-11 12:03:22.441 SMF-AMF Nsmf_PDUSession_CreateResponse PDU Session ID: 5 PDU address: 10.20.0.2 UPF TEID: UPF-S5U-11 QoS Flow 1: QoS ID 9, GBR 0/0 12:03:22.442 AMF-gNB N2 PDU Session Resource Setup Request PDU Session ID: 5 QoS Flow 1: QoS ID 9, DRB ID 3 UPF TEID: UPF-S5U-11 12:03:22.513 gNB-AMF N2 PDU Session Resource Setup Response gNB TEID: GNB-S1U-22 DRB ID: 3我们可以顺着日志看上下文如何流转第一步UE发NAS层请求AMF从这条消息里提取PDU会话ID、DNN、切片然后调用SMF上下文创建接口把“UE的会话请求”转成“控制面的会话上下文创建请求”。这个阶段SMF上下文还不存在。第二步SMF通过PFCP触发UPF会话建立。日志里N4 Session ID 88就是UPF内部上下文编号。UPF回成功并带出自己的隧道端点标识F-TEID。第三步SMF给AMF回PDU Session CreateResponse把分配给终端的IP和UPF隧道ID交给AMF。AMF把这些信息放到N2消息发给gNB。此时gNB开始建立用户面承载。第四步gNB回响应带出gNB侧TEID。SMF或AMF经N4更新把gNB TEID同步给UPF后续下行数据才能直接通过这个TEID找到基站。所呈现的就是一份“会话上下文从无到有、从控制面到用户面”的完整轨迹。实测排障时只要有一条日志缺失或与另一条不一致我基本能立刻判断是哪段链路出现问题。5.3 日志里看上下文同步时间戳对齐法在实操中我比较推荐维护一张“上下文一致性检查表”尤其在测会话建立和释放时特别管用。检查项UE侧RAN侧AMFSMFUPFPDU会话ID555588N4会话切片S-NSSAI1-0102031-0102031-0102031-010203对应IP地址10.20.0.2否是是规则里TEID下行否UPF-S5U-11是是本地TEID上行否GNB-S1U-22是是FAR里做检查时按时间戳从早到晚数一遍NAS、服务化接口、PFCP、NGAP消息各层的会话ID和TEID是否匹配。经验是一半以上的“会话上下文不一致”故障都能归结为某个网元没有收到上一跳回包的明细建议只看丢包而是回包内容不完整比如UPF回复PFCP响应时没带F-TEID导致SMF在N2消息里填了空隧道。6. 常见问题与排查实录6.1 空口恢复后PDU会话为什么还在不少初学者看见UE在CM-IDLE状态后重新发起Service RequestPDU会话还在觉得很奇怪会话不是释放了吗这里要分清两个概念RRC连接释放不等于会话释放。网络只释放了空口和NG-U的连接态资源PDU会话本身继续保留SMF和UPF上的N4会话上下文也不删。排查思路很简单查看AMF上PDU Session状态是否处于“已建立但未激活”以及UPF有没有因为Idle Detection Timer超时触发N4报告。有些部署中UPF配置了闲置会话回收策略超过一定时间才真正删除会话如果UE快速重连会发现会话还在但是如果时间太长发起了新的PDU会话可能拿到新的IP业务会受影响。6.2 切换之后QoS Flow重建失败切换场景里容易出问题的是target gNB没建对应的QoS Flow映射。比如源gNB上QoS Flow 1映射到DRB 3切换后目标gNB回N2 Path Switch时只回复了部分QoS Flow已接受另外一些流失败。这时SMF只保留成功部分的上下文失败流对应的业务就断了。处理时我习惯在源和目标gNB两侧各抓一次N2消息比对“PDU Session Resource Setup Response”里携带的QoS Flow结果列表看是否是切片原因、资源原因、还是策略原因。很多时候是目标小区带宽不足gNB拒绝新建GBR流这属于资源类问题不应盲目去改核心网侧参数。6.3 双连接场景的上下文合并EN-DC或NR-DC双连接场景UE同时连接4G和5G或者连接两个gNB。此时会话上下文会被拆分一个PDU会话在Master Node和Secondary Node上各有一部分无线上下文。核心网SMF看到的还是一套上下文但RAN侧有两份DRB映射。排障时不要只查一条链路需要对Master Node和Secondary Node的空口调度和NG-U隧道做联合分析。实际踩过的坑是SSN切换后发现数据全丢因为Secondary Node Group的TEID在路径切换时没有被及时更新到UPF的转发规则里。处理方法是重触发PDU Session Modification流程由SMF向UPF下新的FAR覆盖旧隧道端点。6.4 排查经验速查表最后整理一份排查速查表方便平时遇到问题快速对号入座故障表现优先排查位置常用手段关键点会话建立失败SMF日志查Nsmf_PDUSession_CreateResponse原因值关注切片、DNN、PCF策略是否一致空口正常但业务不通RAN/UPF隧道查N2 TEID与PFCP TEID上下行TEID必须成对出现切换后丢数据目标gNB/UPF查Path Switch是否上报成功新FAR是否覆盖旧TEID空闲态后找不到会话AMF/UPF查Idle Detection Timer会话保留还是删除要依据策略双连接数据乱序Master/Secondary节点查两条链路QoS参数检查分流策略和PDCP配置同一个UE多个会话互踢AMF/UE查UE上下文并发数大量终端并发时容易触发异常这套速查表是从实际测试里磨出来的不一定覆盖所有场景但排查方向基本够用。我个人的体会是5G会话管理上下文在架构上确实比4G复杂但如果你一直带着“上下文一致性”的角度去看日志所有网元之间传什么、存什么、为什么失步都会变得清晰。最后再分享一个小技巧做会话管理上下文分析时不要只盯着SMF一家日志一定要同时打开AMF、gNB和UPF的跟踪四层窗口同时滚。看到某一条消息卡住顺着事务ID往前翻一跳通常答案就在上一跳的响应里。这个习惯救了我很多次值得保留。