5G核心网的信令流程很多同行看了无数遍但每次排查问题都会有新收获。注册流程里有个Step21b以前我基本是一扫而过直到有一次现网遇到终端不定时复网异常查了一圈最后定位到跟UE策略结果回执有关系才被迫把这个步骤从头到尾翻了个底朝天。这篇文章干脆把它单独拆出来聊透顺带把UE策略从下发到反馈的完整逻辑理清楚希望能帮你避开我踩过的那些坑。文章围绕四件事展开Step21b在注册流程里到底处在什么位置UE策略包含哪几类、为什么AMF要在注册完成之后下发UE回执的UL NAS TRANSPORT里到底装了什么东西现网排错时常见的几种异常怎么处理。内容我会尽量贴合实际信令报文和核心网实现来写适合刚接触5G注册流程的协议测试工程师也适合做了几年核心网开发但始终没细看UE策略这块的同行。1. 先把注册流程的主干重新梳理一遍1.1 从RRC建立到注册完成的完整链路5G注册流程平时讲的人很多但每个人划分步骤的方式不一样。按我习惯的说法一条完整的注册链路大概分五个阶段。第一阶段是空口准备。UE先跟gNB建立RRC连接紧接着通过初始UE消息把注册请求送到AMF这条消息在N2接口上是Initial UE MessageNAS里则是Registration Request。第二阶段是安全与签约准备AMF拿到UE身份后跟AUSF、UDM完成认证向量校验和签约数据获取这是整个流程里最耗时、也是异常报警最多的环节。第三阶段是上下文建立AMF向gNB下发Initial Context Setup Request把安全上下文、能力协商、允许的切片信息一并带过去gNB回响应后空口进入激活态。第四阶段是注册收尾UE收到Registration Accept后会回一条Registration CompleteAMF再根据注册类型决定是否触发后续流程。第五阶段就是PDU会话建立和UE策略交互通常在注册完成后直接衔接实际信令里经常是PDU会话建立请求和UE策略结果反馈紧挨着出现。我说的Step21b就在第四阶段和第五阶段交汇的位置。不同资料里Step21、Step21a、Step21b的叫法可能对不上号有的把Registration Complete叫21a把UE策略结果回执叫21b也有反过来排的。这都不重要关键是你要清楚这一步骤承载的信息一定是UE通过UL NAS TRANSPORT向AMF反馈UE策略处理结果。记住这条主线无论看哪个版本的流程编号都能准确对上。1.2 Step21b在整条信令链路上的真实角色有一点很多刚接触5G的人容易忽略注册流程走到AMF收到Registration Complete只代表基本的注册过程结束了不代表UE真正拿到了可用的网络策略。尤其是URSP和接入层策略这类东西基本都靠注册完成后AMF主动下发UE收到后必须给一个明确的成功或失败反馈。Step21b就是专门干这件事的。AMF在下行方向通过DL NAS TRANSPORT把UE策略部分带出来UE逐条检查策略规则的条件是否满足、参数是否合法然后把自己能接受的和不能接受的策略标识符单独打包塞进UL NAS TRANSPORT里回给AMF。AMF只有收到这份回执才能确定哪个终端真正应用了哪条策略后续做会话路由或者切片选择时才有依据。我见过不少同事在排查URSP相关问题时习惯盯着AMF下发的策略内容看半天却忽略UE回执这一环。实际上很多问题恰恰出在UE这边要么策略标识符对不上要么规则优先级冲突要么UE能力不支持某些路由组件最后回了个半失败状态。这就牵扯到Step21b的报文中一个关键字段UE策略部分结果信息。下面我先把UE策略体系展开讲清楚。2. UE策略的两条腿URSP规则与接入层策略2.1 URSP是终端的“路由大脑”UI策略里大家接触最多的就是URSP全称叫UE Route Selection Policy直接翻译就是“终端路由选择策略”。它的作用可以理解成给终端装了一个路由决策大脑当某个应用要发起数据连接时终端拿应用的流量描述符去匹配URSP规则匹配中了再按规则里的路由选择组件确定走哪个切片、哪个数据网络、建立什么类型的PDU会话。URSP规则的组织结构是分层的。整条策略由多个规则组成每个规则有独立的优先级和流量描述符。流量描述符可以匹配应用ID、IP五元组、域名、DNN这些粒度。规则内部又包含路由选择组件常见的有S-NSSAI选择、DNN选择、SSC模式选择、PDU会话类型选择还有非无缝卸载指示。一条URSP规则可以把这些组件组合起来形成一个完整的“数据业务到网络资源的映射关系”。实际配置时运营商经常把通用的互联网业务配成一条默认规则运营商自有业务配成单独规则企业定制终端再配企业专用规则。规则的优先级顺序决定了终端匹配时的先后选择。这块配错了最典型的后果是终端建立PDU会话时选的切片或DNN跟预期不一致业务跑起来才发现流量没走到对的网络平面上。2.2 接入层策略与跨网协同除了URSP5G注册流程里还会涉及一些接入层策略比如RRC连接控制相关的参数、系统消息里OSI相关的指示、某些场景下的接入限制策略。这些策略跟URSP不同URSP管的是PDU会话层的路由选择接入层策略管的是终端在空口上的行为和接入控制。AMF下发UE策略时往往会把URSP和接入层策略放在同一个下行消息里带出来。UE处理的时候也按策略类别的不同分别校验和反馈。所以在Step21b的回执里你会看到既有URSP相关的策略结果也有接入层策略相关的结果两者编码在同一个UE策略部分结果信息里但标识符范围不同。要注意的是UE策略的关联关系在注册过程中其实很早就建立了。AMF在完成签约数据获取之后就会决定要给这个UE下发哪些策略甚至可能在注册流程还没结束时就触发策略下发。但考虑到UE当前可能还在处理注册请求AMF通常会把策略压到注册收尾阶段再传。这也是为什么Step21b会出现在注册流程尾部的原因它既是注册流程的延续又是策略关联的生效确认。2.3 策略下发的信令载体与透明传输概念AMF下发UE策略时走的是NAS透明传输这条通道载体是DL NAS TRANSPORT消息。所谓透明传输是指网络把策略内容当成一个不透明的数据容器原封不动地交给UE侧的策略管理模块解析。AMF自己并不逐字节地理解策略内容的安全性和完整性由NAS层的安全机制兜底。UE收到DL NAS TRANSPORT后如果消息里带了UE策略部分就会触发策略管理模块做校验和安装。安装完成后它需要把每个策略标识符的处理结果反馈给AMF这个反馈同样走NAS透明传输通道也就是UL NAS TRANSPORT。这里就正式进入Step21b的报文细节了。3. Step21b的NAS报文细节从字段到编码3.1 UL NAS TRANSPORT怎么把策略结果装进去UL NAS TRANSPORT本身是一条很灵活的NAS消息它主要用来承载UE与AMF之间不需要特定流程上下文的信息交换。在Step21b里这条消息的关键信息元素包括消息类型、PDU会话身份、旧PDU会话身份、请求类型、S-NSSAI、DNN、EPS Bearer身份以及最重要的一个容器Payload Container。这里的Payload Container是个通用字段里面可以放不同的负载类型。当携带的是UE策略结果时负载类型会被标记为UE策略部分结果信息。AMF解析UL NAS TRANSPORT时优先看负载类型识别出这是策略反馈而不是普通的UL NAS消息再按TS 24.501里的数据结构去解码具体内容。实际操作中我遇到过一种情况终端把UE策略结果信息和PDU会话建立请求塞在同一条UL NAS TRANSPORT里下发负载类型字段写着PDU会话建立请求而策略结果放在另一个补充字段里。这种复合型报文扫描的时候特别容易看漏排查时一定要把整个消息体都展开不能只看第一个负载类型。3.2 UE策略部分结果信息的数据结构UE策略部分结果信息按照协议定义由两部分组成策略标识符列表和对应的结果值。UE每验证完一条策略就把这条策略的标识符和结果值放进列表里。结果值的分类不是简单成功或者失败而是区分为成功、失败或者部分成功。具体到URSP一个策略标识符代表一条完整的URSP规则。设计上一个策略部分可以包含多条规则但反馈结果时是按策略标识符逐个反馈的。协议数据里对每个标识符提供4比特的结果值。某些具体码值定义起来分得很细包括UE不支持该策略、策略参数错误、优先级冲突、流量描述符无法识别等。我提醒一下不同厂商实现时对结果码的细化程度参差不齐。有的统一回两个码成功就成功拒绝就拒绝有的会把拒绝原因细分到第几个路由组件不受支持。ARFC和实验室联调时最怕的就是终端回了个“不支持该策略”的笼统结果AMF侧日志只能看到拒绝具体哪个组件出了问题得靠终端侧日志配合定位。为了让你有个直观印象我给一个典型的伪代码解码结果UE policy part result information - 策略部分标识符1Policy identifier : URSP_Rule_ID_0101Result : SuccessUE policy part result information - 策略部分标识符2Policy identifier : URSP_Rule_ID_0102Result : RejectReject cause : route selection component not supported这里有几点值得注意。首先规则ID 0101和0102是AMF侧配置策略时维护的唯一标识UE侧原样回传不能自行修改。其次策略部分标识符和规则标识符是两回事前者对应AMF下发的“策略部分”后者对应部分里的“单条规则”。调试时经常有人把这两个ID搞混结果对着错误日志查了一下午。3.3 策略结果不是“二元”那么简单上面提到结果值有“部分成功”的情况很多人不理解这个状态存在的意义。举个例子AMF下发的一条URSP规则里同时带了S-NSSAI选择、DNN选择和SSC模式选择三个组件。UE评估后发现DNN选择对应的DNN在本地签约数据里不存在但切片选择组件没问题。这时UE不能简单回一个拒绝因为拒绝会导致整条规则失效但也不能回成功因为确实有组件没生效。协议就允许UE回一个部分成功具体哪些组件成功了AMF可以从其他信令里判断或者UE把具体原因放在后面附带信息里。AMF收到部分成功的结果通常不会立刻重新下发策略而是记录下来等待后续事件触发更新。比如UDM签约变更或者注册流程再次执行时AMF会重新评估是否补发缺失的策略部分。这种设计目的是尽量减少空口信令开销毕竟UE策略更新越频繁NAS信令量越大对接入网的冲击也越明显。3.4 Step21b和Registration Complete的时间关系这里有一个容易混淆的点Step21b这个UL NAS TRANSPORT消息和Registration Complete之间是什么先后关系从我处理的信令trace来看常见的顺序有两种。第一种是UE先发Registration Complete紧接着发UL NAS TRANSPORT携带策略结果两条消息分开间隔很短。第二种是UE把Registration Complete内容作为NAS消息的一部分放在UL NAS TRANSPORT的Payload里策略结果字段再同步携带上两条逻辑消息合并成一条物理消息。第二种方式更高效但抓包时会发现一条消息里同时出现两个NAS消息的语法特征阅读时别觉得奇怪。AMF侧在等待回执时是有超时机制的。如果收到Registration Complete但迟迟没等到策略结果AMF会周期性重发UE策略下发请求或者等待终端的移动性注册更新触发新一轮策略推送。有些实现里甚至会主动释放用户面的相关连接来强制终端重新注册这类手段属于优化级不常用但出现过在异常终端场景上的确能缓解问题。4. 实操对照从日志里看懂Step21b的真实交互4.1 正常流程的信令日志怎么看这个部分拿一个典型的N2/NAS解码日志片段来带大家走一遍。假设某厂商核心网的信令跟踪工具输出如下UL NAS TRANSPORTMessage Type : 0x7CPDU Session ID : 0x05Request Type : Initial RequestS-NSSAI : SST1, SD0x000001DNN : internet-mnc001.mcc001.gprsPayload Container Type : UE Policy Part Result InformationPayload ContainerPolicy Part Identifier : 2Policy Identifier : 0x01, Result : SuccessPolicy Identifier : 0x02, Result : SuccessPolicy Identifier : 0x03, Result : Reject, Reject Cause : Traffic descriptor cannot be identified从这个日志能得到几条有效信息。UE已经成功建立或者请求建立S-NSSAI为1的缺省切片下的PDU会话Internet的DNN也被正确填入。UE策略部分标识符2对应URSP规则组三条规则里有两条安装成功一条因流量描述符无法识别被拒。AMF侧收到这个回执后在后台日志里会记录一个“URSP部分更新完成有1条规则未生效”的状态。正常情况下策略结果中不应出现大面积的Reject。如果看到所有规则全部Reject首先怀疑目标终端的协议栈是否完整支持URSP解析其次检查AMF下发的URSP格式是否合规。大部分现网URSP问题都是AMF在下发时把规则的优先级字段重复配置了导致终端无法判定哪条规则优先整包拒收。终端在拒绝的同时会把对应策略标识符标记出来把标识符往AMF的配置表里一比对很快就能定位到是第几条规则。4.2 空口侧和核心网侧的判断标准判断Step21b处理是否正常不能只看核心网日志还要同步看gNB侧的空口信令。因为UL NAS TRANSPORT是嵌套在RRC信令里传上来的UE先发给gNB一条RRC UL Information Transfer里面携带UL NAS TRANSPORTgNB再通过N2的Uplink NAS Transport送给AMF。链路跨越了空口、F1、N2三个段任何一段出问题都会导致AMF这边收不到。实际操作中定位“AMF没等到策略结果”问题时排查顺序是这样的先在AMF侧查Uplink NAS Transport有没有收到如果没有去gNB侧查RRC UL Information Transfer有没有收到UE的上报再没有让终端侧同事复现时抓空口日志看UE是否真的发出了UL NAS TRANSPORT。三级排查各管一段都能快速锁定故障域。这个思路在很多核心网问题里都通用建议刚入行的同事刻在脑子里。4.3 周期性注册和移动性注册场景下的差异前面讨论的主要是初始注册流程里的Step21b但UE策略更新还会出现在周期性注册和移动性注册里。周期性注册时UE如果判断自己的策略没有变化可能直接省略策略结果回执但如果AMF在注册响应里带了新的UE策略部分URSP就必须反馈。移动性注册时跨AMF场景下策略关联需要迁移新AMF可能需要重新下发策略给UEStep21b的出现频率就更高了。在很多现网案例里终端跨TA移动后出现的数据业务异常都跟移动性注册时UE策略没有正确安装有关。问题根源往往是旧AMF下发的URSP在切换过程中被终端缓存了新AMF没及时触发覆盖更新旧规则里引用的DNN或切片在新区域不可用业务就打着“转圈”的典型症状。碰上这种情况先别怀疑终端协议栈优先看新AMF是否重新下发策略部分以及UE有没有在Step21b里确认安装成功。5. 常见问题与排查技巧实录5.1 UE一直不回策略结果该怎么查这类问题的典型表现是AMF侧能看到UE注册成功但UE策略关联状态一直停留在待确认。排查分三步先在核心网侧确认AMF是否成功下发了DL NAS TRANSPORT这个可以从N2口的Downlink NAS Transport报文字节数来判断带策略的下行消息通常比普通消息更长然后结合空口日志确定UE是否真的收到了策略内容最后确认UE侧策略管理模块是否被禁用部分定制终端为了省电会在特定场景下关闭策略处理能力这种只能靠终端侧配置核查解决。还有一个被忽视的细节UE在漫游场景下从VPLMN的AMF收到策略后如果策略归属是HPLMN的UE可能需要回HPLMN的UDM做二次确认导致回执延迟。现网联调VPLMN漫游特性时Step21b超时是常见现象要结合漫游状态机一起看别让AMF单侧提前判定失败。5.2 策略结果大面积RejectAMF要不要立即重发部分初做这个功能的人看到UE回Reject就条件反射地重新下发策略。这个习惯在现网要改一改。如果Reject是配置问题导致的重发只会造成信令风暴。建议先收集Reject原因码确认是UE能力、参数不合法还是优先级冲突逐项排除后由网管侧修改策略配置再触发一轮更新。如果Reject原因是UE侧临时状态引起的比如UE正处于入网预注册阶段等个几秒让UE状态就绪再触发重下成功率会明显提升。5.3 URSP规则优先级配置不当这是所有UE策略问题里出现频率最高的。URSP规则按优先级从高到低排列UE拿来跟流量描述符匹配时一旦匹配到优先级最高的规则就不再往下匹配。运营商早期配置时喜欢把企业专属规则配成一个很宽泛的域名通配符结果把默认规则完全“饿死”了大量流量被导入专属切片。排查这种问题最快的方法就是让终端抓一份全部URSP规则的结果报告看一眼匹配顺序就能找到冲突源。规则下发前用离线工具做一次冗余检查能把这类隐患消灭在配置阶段。5.4 一个现网小案例的复盘最后分享一下之前定位过的一个真实案例。当时某运营商区域频繁出现部分终端接入后业务流量异常核心网日志显示URSP存在Reject记录Reject原因指向“S-NSSAI值不可用”。看起来像是终端拒绝了网络下发的切片标识。排查后才发现问题根源是AMF在注册流程里下发的URSP规则里同时绑定了两个S-NSSAI其中一个属于平台侧未在签约数据里开通的切片终端校验签约切片列表时直接拒绝了整条规则导致另一个可用的切片也没被应用。修改配置把规则拆成两条独立规则后问题当天消失。这个案例说明UE策略结果回执里的每个Reject码都值得深挖原因往往藏在AMF和UDM之间的数据一致性上。5.5 值得记住的排错基本信息画个简表方便大家日常查现象可能原因排查动作AMF未收到UL NAS TRANSPORT空口丢包、gNB未转发分段查RRC和N2日志UE策略结果全Reject规则优先级冲突、参数不合法比对配置表、看Reject码URSP规则部分成功个别路由组件不可用核对签约数据和切片开通状态跨AMF移动后策略丢失新AMF未重下策略检查移动性注册的UE策略关联迁移终端不回策略结果终端策略处理模块异常/关闭终端侧日志与能力配置核查这些经验总结下来其实就一句话Step21b不只是一条信令它背后是整个UE策略生命周期的反馈闭环。理解了这个闭环5G注册流程里很多看似复杂的问题定位起来都比想象中简单。我自己在写完这篇总结后又回头把之前经手过的几个异常case对照了一遍几乎都能在这个框架里找到位置。
