简介一份关于5G SA语音通话异常掉落到4G的实战处理案例主题聚焦VoNR通话结束后终端回落流程异常的根因定位。文档完整记录了从现场测试到核心网定位的全过程前台抓取LOG后确认Fast Return与LTE到NR重定向正常但随即出现NR RRC Normal Release事件后台NG接口与UU口信令进一步显示AMF下发了携带normal-release与nas:deregister原因值的UE上下文释放命令联合核心网定位后确认根因在UDM网元信令处理异常。对于5G网络优化、核心网运维及VoNR语音质量分析人员该案例既展示了如何判断无线侧接入正常但核心网异常释放也提供了前后台信令联合分析、跨域协同定界的完整排障框架同时可通过信令中的异常原因值快速锁定初步怀疑方向。资源为单篇docx文档压缩包大小约959KB章节涵盖问题概述、现象描述、前台LOG分析、后台信令跟踪、解决措施、应用成效与备注结构清晰适合直接作为同类问题复盘模板或案例上报参考。已有204人学习适合需要快速积累5G SA语音回落优化经验的工程师下载参考。1. 一次Fast Return后的异常回落问题出在核心网UDM5G SA语音通话结束后的Fast Return流程本应是终端从LTE快速返回NR的“最后一步”但在某地市实际测试中这个流程却变成了用户感知的“掉线”——电话挂断后终端不但没有驻留5G反而在5G侧发起PDU会话建立时被直接释放最终回落4G并重新附着。前台测试LOG和后台NG接口信令双双指向同一个现象NR侧随机接入成功后在UE与5GC交互阶段收到了一条本不该出现的NR RRC Normal Release紧随其后的NAS层DL NAS Transport携带了nRMM-cause: payload-was-not-forwarded最终定位到核心网UDM信令处理异常。这个案例的价值在于它把无线侧看似“正常”的释放事件通过前后台信令逐段比对最终穿透到了核心网网元级根因。对从事5G SA网络优化、VoNR语音质量分析和核心网信令排查的工程师来说这是一条完整的从现象到根因的排查路径值得拆开细看。2. Fast Return业务正常但NR接入阶段出现了不该有的RRC释放2.1 通话结束后终端确实完成了LTE到NR的重定向5G SA语音通话采用VoNR方案时语音承载在5G侧建立通话结束后如果终端在通话过程中因覆盖或容量原因曾被切换或重定向到LTEEPS Fallback场景则需要通过Fast Return机制快速返回NR。这里涉及两个关键信令过程终端在LTE侧发起Fast Return请求通常通过RRC Connection Release中的redirectedCarrier信息或基于测量的自主返回随后执行LTE到NR的重定向流程。从前台测试LOG看挂断电话后终端的动作顺序是清晰的先发起Fast Return请求然后完成LTE到NR的重定向。这说明LTE侧到NR侧的移动性控制是正常的基站侧下发的重定向参数、频点信息和终端侧的目标小区搜索、同步、读取系统消息等动作都按预期执行。如果这个阶段就失败问题通常出在LTE侧重定向参数配置或NR目标小区的信号质量上但本案例中这一段流程没有异常可以排除无线侧重定向参数配置错误。这个阶段的信令特征值得注意重定向完成意味着RRC连接在LTE侧被释放终端带着5G-GUTI或等效标识进入NR小区发起随机接入。随机接入成功是终端在NR侧建立信令连接的第一步它验证了上行同步和调度请求链路是通的。在11:00:15.274这个时间点终端在NR侧随机接入成功随后在11:00:16.354完成LTE到NR的重定向整个时间跨度约1.08秒属于正常范围内的重定向耗时。2.2 随机接入成功后却收到NR RRC Normal Release重定向完成后的38毫秒也就是11:00:16.392终端侧出现了一个NR RRC Normal Release事件。这个时间点极为关键随机接入刚完成终端正准备与5GC核心网进行NAS层交互RRC连接正处于激活状态此时任何网络侧下发的RRC释放都会中断这个交互过程。按照3GPP定义的正常流程随机接入成功后的下一步是RRC Connection Setup Complete消息中携带NAS层附着请求或服务请求由gNB转发给AMF然后AMF触发UE Context Setup等流程。在这个阶段UE与5GC之间的NAS消息正在传输中gNB不应该主动释放RRC连接。正常业务中RRC释放只会在显式信令流程结束后如UE Context Release由核心网触发且流程完整执行或在无线链路失败、定时器超时等异常场景下发生。信令细节显示核心网通过NAS层经由基站传递了DL NAS Transport给终端这条信令本身是正常的——它承载了核心网下发给终端的NAS消息。但问题在于这条DL NAS Transport中携带的原因值暴露了根因方向nRMM-cause: payload-was-not-forwarded。这个原因值在3GPP规范中对应的含义是网络侧通常是核心网网元在转发NAS消息时未能将有效载荷完整传递导致终端侧无法正常处理预期流程。终端收到这个原因值后判定当前NAS信令交互无法继续遂在无线侧触发释放。这里需要区分两个层面的“释放”终端侧记录到的NR RRC Normal Release是RRC层的释放原因而真正驱动这个释放的是NAS层收到的异常原因值。换句话说无线侧只是执行者核心网才是决策者。2.3 DL NAS Transport中的nRMM-cause到底意味着什么nRMM-cause是5G NAS层中与5G移动性管理相关的原因值编码payload-was-not-forwarded并不是一个常见的日常故障原因值。在正常运营的网络中更常见的是network failure、congestion、ue identity cannot be derived by the network等原因值。payload-was-not-forwarded的出现通常意味着核心网内部某个网元在处理NAS消息时没有把上层如SMF或UDM传递下来的内容完整转发给gNB/UE或者转发的时机不对导致终端侧接收到的NAS消息内容不完整。从协议栈视角看AMF收到UDM或SMF的响应后通过NGAP Initial Context Setup Request或DL NAS Transport将NAS PDU封装后发送给gNB。如果AMF内部分流、状态机处理出现异常可能在转发过程中丢弃了NAS PDU的有效载荷部分也可能在错误的时间点触发释放流程。本案例中的时间线显示终端在11:00:18.380发起NR PDU Session建立请求这是5G SA下建立用户面承载的正常动作。但请求发出后在11:00:22.655终端直接掉落至4G在LTE侧发起附着请求和RRC建立请求。这说明终端在NR侧等待核心网响应期间收到了无法继续的NAS指示不再尝试继续NR流程而是转向LTE。从排查思路上这个原因值出现后不要先急着查无线侧参数首要动作是抓取完整的NG接口信令和UU口信令进行时间戳对齐确认到底是AMF主动释放还是UDM下发异常导致AMF被动释放。无线侧的释放事件只是“果”“因”在核心网。3. NG接口信令里的释放命令把问题锁定到核心网AMF行为3.1 后台NGAP UE Context Release Command的时间点异常外场测试结束后后台对5G侧NG接口和UU口信令做了全量跟踪。NG接口是gNB与AMF之间的逻辑接口承载NGAP协议UE级别的信令交互都在这条接口上可见。跟踪结果显示终端在5G侧发起正常接入流程后流程尚未完成——具体而言gNB尚未收到AMF下发的Initial Context Setup Request或类似后续流程消息AMF却在此时下发了NGAP_UE_CONTEXT_REL_CMD命令给基站要求释放UE上下文。这条命令携带的原因值为normal-release。在NGAP协议中normal-release通常表示一次正常流程的释放比如UE去注册、隐式去注册、或核心网主动释放UE上下文。但问题在于本次流程中UE刚完成随机接入正在进行PDU会话建立请求没有任何合理的正常释放条件。正常业务中normal-release应该出现在UE注册流程完成后的去注册阶段、或UE Context Release的前置流程确实完整执行完毕时而不是在PDU会话建立请求刚发出时。对比前台LOG的时间戳终端11:00:18.380发起NR PDU Session建立请求11:00:22.655掉落4G。后台信令中AMF下发NGAP_UE_CONTEXT_REL_CMD的时间点正好在这两者之间。这意味着gNB收到释放命令后向UE下发RRC释放UE在LTE侧重新附着整个过程一气呵成。前台LOG中记录的NR RRC Normal Release事件与后台NG接口的释放命令是同一事件的无线侧与网络侧视角。3.2 nas: deregister原因值暴露了AMF的内部状态异常进一步钻取NG接口信令时发现了一个更值得注意的细节AMF下发的释放命令中除了normal-release还有携带nas: deregister原因值的释放命令。这两个原因值同时出现说明AMF的UE上下文管理状态机出现了异常。在5G核心网中deregister通常由以下场景触发UE显式发起去注册、UDM发下来订阅取消通知Subscription Withdrawal、或AMF因内部错误主动释放UE上下文。但本案例中终端没有发起去注册UDM侧也没有显式的订阅取消信令AMF却下发了带deregister的释放命令。结合前台LOG中的payload-was-not-forwarded可以推断AMF在向UE转发NAS消息时可能收到了UDM的下发数据但AMF内部信令处理出现问题误判为UE需要去注册从而触发释放流程。从信令交互看整个链条是UDM异常→AMF收到异常响应→AMF判定NAS消息无法正确转发→AMF向gNB下发UE Context Release Command→gNB向UE下发RRC释放→UE回到IDLE→UE在LTE侧重新附着。这就是前台看到“通话后返回5G时异常掉落4G”的完整信令链条。无线侧的执行逻辑完全正常gNB只是忠实执行了核心网的释放命令。3.3 前后台信令时间戳对齐的方法排查此类问题时前后台信令时间戳对齐是第一步也是最重要的一步。实际操作中我一般会以毫秒级精度拉出前台LOG中的关键事件时间点再与后台NG接口信令时间进行比对。以下是常用的时间对齐检查点| 信令事件 | 前台LOG观察点 | 后台NG接口观察点 | |---------|--------------|-----------------| | 随机接入完成 | RACH Success / RRC Setup Complete | Initial UE Message | | PDU会话建立请求 | UE发送PDU Session Establishment Request | Uplink NAS Transport | | 网络侧释放指示 | NR RRC Normal Release事件 | NGAP UE Context Release Command | | 核心网原因值 | DL NAS Transport中的nRMM-cause | UE Context Release Command中的Cause IE |对齐时重点看两个时间差的合理性随机接入完成到PDU会话建立请求之间的间隔正常应在200ms到1秒范围内间隔过长说明核心网响应慢PDU会话建立请求到网络侧下发释放之间的间隔正常应是在等待AMF/SMF响应如果这个间隔极短比如几十毫秒就收到释放命令大概率是AMF状态机异常。本案例中这两个时间差都指向核心网处理异常无线侧没有可优化的点。提示在NGAP Cause IE中normal-release可能被标记为Radio Network Layer、Transport Layer或NAS三个不同层级。本案例的nas: deregister属于NAS层原因出现时应优先检查AMF与UDM之间N8接口交互。4. 联合定位找到根因UDM信令处理异常导致释放命令下发的逻辑链4.1 从无线侧到核心网的联合排查分工前台无线侧的判断已经明确Fast Return执行正常NR接入正常问题出现在NAS信令交互阶段。后台NG接口信令也确认释放命令来自AMF。此时排查方向已经从无线侧转到核心网需要核心网工程师配合围绕AMF和UDM之间的信令交互展开。联合定位时的分工通常是无线侧负责确认gNB侧是否有异常丢弃或错误转发核心网负责排查AMF的UE上下文状态、AMF与UDM之间的N8接口交互、UDM的签约数据处理流程。在明确AMF下发释放命令后无线侧的工作基本结束剩下的核心网内部排查需要抓取AMF日志和UDM日志进行比对。4.2 UDM信令处理异常如何触发AMF释放UE最终定位的结果是核心网UDM信令处理异常。UDM统一数据管理在5G核心网中负责管理用户签约数据、鉴权数据、订阅通知等。当UE发起PDU会话建立请求时SMF会通过AMF向UDM请求会话管理相关订阅数据UDM的响应需要通过N8接口返回给AMF。本次故障中UDM信令处理异常的表现是UDM在处理某个特定请求时内部状态机进入了错误分支没有正确返回预期的数据响应而是返回了一个异常指示。AMF收到这个异常指示后按照标准流程判定NAS消息的载荷无法继续转发因此向UE下发了DL NAS Transport并携带了payload-was-not-forwarded原因值。与此同时AMF内部将该UE的上下文状态标记为需要释放触发了UE Context Release流程。UDM信令处理异常还要区分为两类一类是UDM内部软件缺陷比如特定消息序列触发的空指针或状态机跳转错误另一类是UDM与周边网元的接口交互异常比如与AUSF或NSSF的交互超时。本案例属于前者即UDM自身处理逻辑问题与周边网元无关。修复UDM后故障现象消失再次验证了这个定位。4.3 排查此类问题时的参数采集清单与验证方法遇到“5G SA通话后回落4G”且疑似核心网问题时建议按以下清单采集数据避免反复多次下站测试# 前台采集建议 # 1. 开启终端侧的详细信令日志确保包含NAS层原因为payload-was-not-forwarded # 2. 同时抓取LTE侧和NR侧的RRM测量报告排除无线侧覆盖因素 # 3. 记录通话前后的RSRP/RSRQ/SINR快照验证是否有弱覆盖叠加 # 后台采集建议 # 1. NG接口信令全量跟踪导出UE级别的Initial UE Message到UE Context Release完整信令链 # 2. AMF侧UE上下文管理日志重点关注N2接口释放命令触发源 # 3. UDM侧N8接口交互日志查看UE PDU会话建立请求对应的签约数据响应 # 4. 时钟同步检查确保gNB、AMF、UDM时间偏差在100ms内验证UDM修复效果时最简单的做法是让终端重复执行VoNR通话挂断后返回NR的测试连续测试20次以上确认没有复现。同时观察NG接口信令中是否还有携带deregister的异常释放命令。修复后正常的流程应该是通话结束→Fast Return发起→LTE到NR重定向→NR随机接入→PDU会话建立→UE回到5G驻留态全程无额外RRC释放。提示如果UDM修复无法立即实施可通过在AMF侧调整相关定时器或关闭特定流程的临时规避。但这类操作属于核心网应急手段必须由核心网服务商评估后执行无线侧不建议也不应该干预。5. 从一次释放原因值反推核心网状态机的排查技巧5.1 把nRMM-cause当作核心网状态机的“指纹”在排查5G SA VoNR问题时很多无线侧工程师会习惯性先看覆盖、干扰、切换参数但遇到非典型释放原因值时需要跳出现有框架。payload-was-not-forwarded这类原因值的出现频率很低但每次出现都指向核心网内部的数据流转异常。把它当作状态机“指纹”来用这个原因值出现时意味着AMF或SMF在转发NAS消息时丢失了有效载荷。跨层联查的思路是先抓住前台LOG中终端侧记录到的NAS原因值再关联后台NGAP释放命令原因值然后反查AMF到UDM之间的信令交互。这套反向追溯的核心在于时间戳和UE标识的严格对齐。如果前台LOG和后台抓包的时间基准不一致建议使用相对时间比如从随机接入成功到PDU会话建立请求的时间差进行对比。5.2 常见释放原因值的快速判别表实际排查中积累的常见原因值判别参考如下| 原因值 | 出现阶段 | 可能根因 | 排查优先级 | |--------|---------|---------|-----------| | payload-was-not-forwarded | NAS交互中 | UDM/AMF状态机异常 | 核心网内部排查 | | normal-release (NAS层) | 流程未完成时 | AMF主动释放逻辑错误 | 查看AMF日志 | | nas: deregister | 未发起去注册时 | AMF误判UE去注册 | 查N8接口交互 | | radio network layer cause | RRC连接中 | 无线侧链路失败/定时器超时 | 查UU口信令和RRM | | transport layer cause | NG接口传输中 | SCTP链路中断/传输超时 | 查传输设备状态 |这张表的使用场景是拿到一条异常释放信令后先判断原因值属于哪个协议层再决定排查方向。如果原因值属于NAS层无线侧调参基本无效应该直接走向核心网联查。5.3 现场排查时如何用最小代价复现并验证复现此问题时不需要复杂的路测配置一台支持VoNR的商用终端配合网优后台的NG接口信令跟踪即可。具体做法是在SA覆盖良好的区域发起VoNR语音通话通话时长控制在30秒左右确保通话结束后终端进入Fast Return流程挂断电话后立即观察终端是否在10秒内返回5G。如果终端回落4G并持续驻留超过30秒则判定为异常复现。验证UDM修复是否有效时可以观察同一终端在修复前后的行为差异。修复前终端每次通话后回落4G且NR侧能看到UE Context Release命令修复后终端通话结束后直接驻留NRNG接口不再出现携带deregister原因值的释放命令。对于此类问题无线侧能做的是提供精准的信令抓取和分析结果把决策点交给核心网工程师跨网联查时优先输出前台LOG关键事件时间轴、NG接口释放命令时间点、携带的原因值三个信息这三个要素对齐后根因定位通常不会偏离方向。本文还有配套的精品资源点击获取 5G SA VoNR Fast Return异常回落：核心网UDM信令处理故障定位
简介一份关于5G SA语音通话异常掉落到4G的实战处理案例主题聚焦VoNR通话结束后终端回落流程异常的根因定位。文档完整记录了从现场测试到核心网定位的全过程前台抓取LOG后确认Fast Return与LTE到NR重定向正常但随即出现NR RRC Normal Release事件后台NG接口与UU口信令进一步显示AMF下发了携带normal-release与nas:deregister原因值的UE上下文释放命令联合核心网定位后确认根因在UDM网元信令处理异常。对于5G网络优化、核心网运维及VoNR语音质量分析人员该案例既展示了如何判断无线侧接入正常但核心网异常释放也提供了前后台信令联合分析、跨域协同定界的完整排障框架同时可通过信令中的异常原因值快速锁定初步怀疑方向。资源为单篇docx文档压缩包大小约959KB章节涵盖问题概述、现象描述、前台LOG分析、后台信令跟踪、解决措施、应用成效与备注结构清晰适合直接作为同类问题复盘模板或案例上报参考。已有204人学习适合需要快速积累5G SA语音回落优化经验的工程师下载参考。1. 一次Fast Return后的异常回落问题出在核心网UDM5G SA语音通话结束后的Fast Return流程本应是终端从LTE快速返回NR的“最后一步”但在某地市实际测试中这个流程却变成了用户感知的“掉线”——电话挂断后终端不但没有驻留5G反而在5G侧发起PDU会话建立时被直接释放最终回落4G并重新附着。前台测试LOG和后台NG接口信令双双指向同一个现象NR侧随机接入成功后在UE与5GC交互阶段收到了一条本不该出现的NR RRC Normal Release紧随其后的NAS层DL NAS Transport携带了nRMM-cause: payload-was-not-forwarded最终定位到核心网UDM信令处理异常。这个案例的价值在于它把无线侧看似“正常”的释放事件通过前后台信令逐段比对最终穿透到了核心网网元级根因。对从事5G SA网络优化、VoNR语音质量分析和核心网信令排查的工程师来说这是一条完整的从现象到根因的排查路径值得拆开细看。2. Fast Return业务正常但NR接入阶段出现了不该有的RRC释放2.1 通话结束后终端确实完成了LTE到NR的重定向5G SA语音通话采用VoNR方案时语音承载在5G侧建立通话结束后如果终端在通话过程中因覆盖或容量原因曾被切换或重定向到LTEEPS Fallback场景则需要通过Fast Return机制快速返回NR。这里涉及两个关键信令过程终端在LTE侧发起Fast Return请求通常通过RRC Connection Release中的redirectedCarrier信息或基于测量的自主返回随后执行LTE到NR的重定向流程。从前台测试LOG看挂断电话后终端的动作顺序是清晰的先发起Fast Return请求然后完成LTE到NR的重定向。这说明LTE侧到NR侧的移动性控制是正常的基站侧下发的重定向参数、频点信息和终端侧的目标小区搜索、同步、读取系统消息等动作都按预期执行。如果这个阶段就失败问题通常出在LTE侧重定向参数配置或NR目标小区的信号质量上但本案例中这一段流程没有异常可以排除无线侧重定向参数配置错误。这个阶段的信令特征值得注意重定向完成意味着RRC连接在LTE侧被释放终端带着5G-GUTI或等效标识进入NR小区发起随机接入。随机接入成功是终端在NR侧建立信令连接的第一步它验证了上行同步和调度请求链路是通的。在11:00:15.274这个时间点终端在NR侧随机接入成功随后在11:00:16.354完成LTE到NR的重定向整个时间跨度约1.08秒属于正常范围内的重定向耗时。2.2 随机接入成功后却收到NR RRC Normal Release重定向完成后的38毫秒也就是11:00:16.392终端侧出现了一个NR RRC Normal Release事件。这个时间点极为关键随机接入刚完成终端正准备与5GC核心网进行NAS层交互RRC连接正处于激活状态此时任何网络侧下发的RRC释放都会中断这个交互过程。按照3GPP定义的正常流程随机接入成功后的下一步是RRC Connection Setup Complete消息中携带NAS层附着请求或服务请求由gNB转发给AMF然后AMF触发UE Context Setup等流程。在这个阶段UE与5GC之间的NAS消息正在传输中gNB不应该主动释放RRC连接。正常业务中RRC释放只会在显式信令流程结束后如UE Context Release由核心网触发且流程完整执行或在无线链路失败、定时器超时等异常场景下发生。信令细节显示核心网通过NAS层经由基站传递了DL NAS Transport给终端这条信令本身是正常的——它承载了核心网下发给终端的NAS消息。但问题在于这条DL NAS Transport中携带的原因值暴露了根因方向nRMM-cause: payload-was-not-forwarded。这个原因值在3GPP规范中对应的含义是网络侧通常是核心网网元在转发NAS消息时未能将有效载荷完整传递导致终端侧无法正常处理预期流程。终端收到这个原因值后判定当前NAS信令交互无法继续遂在无线侧触发释放。这里需要区分两个层面的“释放”终端侧记录到的NR RRC Normal Release是RRC层的释放原因而真正驱动这个释放的是NAS层收到的异常原因值。换句话说无线侧只是执行者核心网才是决策者。2.3 DL NAS Transport中的nRMM-cause到底意味着什么nRMM-cause是5G NAS层中与5G移动性管理相关的原因值编码payload-was-not-forwarded并不是一个常见的日常故障原因值。在正常运营的网络中更常见的是network failure、congestion、ue identity cannot be derived by the network等原因值。payload-was-not-forwarded的出现通常意味着核心网内部某个网元在处理NAS消息时没有把上层如SMF或UDM传递下来的内容完整转发给gNB/UE或者转发的时机不对导致终端侧接收到的NAS消息内容不完整。从协议栈视角看AMF收到UDM或SMF的响应后通过NGAP Initial Context Setup Request或DL NAS Transport将NAS PDU封装后发送给gNB。如果AMF内部分流、状态机处理出现异常可能在转发过程中丢弃了NAS PDU的有效载荷部分也可能在错误的时间点触发释放流程。本案例中的时间线显示终端在11:00:18.380发起NR PDU Session建立请求这是5G SA下建立用户面承载的正常动作。但请求发出后在11:00:22.655终端直接掉落至4G在LTE侧发起附着请求和RRC建立请求。这说明终端在NR侧等待核心网响应期间收到了无法继续的NAS指示不再尝试继续NR流程而是转向LTE。从排查思路上这个原因值出现后不要先急着查无线侧参数首要动作是抓取完整的NG接口信令和UU口信令进行时间戳对齐确认到底是AMF主动释放还是UDM下发异常导致AMF被动释放。无线侧的释放事件只是“果”“因”在核心网。3. NG接口信令里的释放命令把问题锁定到核心网AMF行为3.1 后台NGAP UE Context Release Command的时间点异常外场测试结束后后台对5G侧NG接口和UU口信令做了全量跟踪。NG接口是gNB与AMF之间的逻辑接口承载NGAP协议UE级别的信令交互都在这条接口上可见。跟踪结果显示终端在5G侧发起正常接入流程后流程尚未完成——具体而言gNB尚未收到AMF下发的Initial Context Setup Request或类似后续流程消息AMF却在此时下发了NGAP_UE_CONTEXT_REL_CMD命令给基站要求释放UE上下文。这条命令携带的原因值为normal-release。在NGAP协议中normal-release通常表示一次正常流程的释放比如UE去注册、隐式去注册、或核心网主动释放UE上下文。但问题在于本次流程中UE刚完成随机接入正在进行PDU会话建立请求没有任何合理的正常释放条件。正常业务中normal-release应该出现在UE注册流程完成后的去注册阶段、或UE Context Release的前置流程确实完整执行完毕时而不是在PDU会话建立请求刚发出时。对比前台LOG的时间戳终端11:00:18.380发起NR PDU Session建立请求11:00:22.655掉落4G。后台信令中AMF下发NGAP_UE_CONTEXT_REL_CMD的时间点正好在这两者之间。这意味着gNB收到释放命令后向UE下发RRC释放UE在LTE侧重新附着整个过程一气呵成。前台LOG中记录的NR RRC Normal Release事件与后台NG接口的释放命令是同一事件的无线侧与网络侧视角。3.2 nas: deregister原因值暴露了AMF的内部状态异常进一步钻取NG接口信令时发现了一个更值得注意的细节AMF下发的释放命令中除了normal-release还有携带nas: deregister原因值的释放命令。这两个原因值同时出现说明AMF的UE上下文管理状态机出现了异常。在5G核心网中deregister通常由以下场景触发UE显式发起去注册、UDM发下来订阅取消通知Subscription Withdrawal、或AMF因内部错误主动释放UE上下文。但本案例中终端没有发起去注册UDM侧也没有显式的订阅取消信令AMF却下发了带deregister的释放命令。结合前台LOG中的payload-was-not-forwarded可以推断AMF在向UE转发NAS消息时可能收到了UDM的下发数据但AMF内部信令处理出现问题误判为UE需要去注册从而触发释放流程。从信令交互看整个链条是UDM异常→AMF收到异常响应→AMF判定NAS消息无法正确转发→AMF向gNB下发UE Context Release Command→gNB向UE下发RRC释放→UE回到IDLE→UE在LTE侧重新附着。这就是前台看到“通话后返回5G时异常掉落4G”的完整信令链条。无线侧的执行逻辑完全正常gNB只是忠实执行了核心网的释放命令。3.3 前后台信令时间戳对齐的方法排查此类问题时前后台信令时间戳对齐是第一步也是最重要的一步。实际操作中我一般会以毫秒级精度拉出前台LOG中的关键事件时间点再与后台NG接口信令时间进行比对。以下是常用的时间对齐检查点| 信令事件 | 前台LOG观察点 | 后台NG接口观察点 | |---------|--------------|-----------------| | 随机接入完成 | RACH Success / RRC Setup Complete | Initial UE Message | | PDU会话建立请求 | UE发送PDU Session Establishment Request | Uplink NAS Transport | | 网络侧释放指示 | NR RRC Normal Release事件 | NGAP UE Context Release Command | | 核心网原因值 | DL NAS Transport中的nRMM-cause | UE Context Release Command中的Cause IE |对齐时重点看两个时间差的合理性随机接入完成到PDU会话建立请求之间的间隔正常应在200ms到1秒范围内间隔过长说明核心网响应慢PDU会话建立请求到网络侧下发释放之间的间隔正常应是在等待AMF/SMF响应如果这个间隔极短比如几十毫秒就收到释放命令大概率是AMF状态机异常。本案例中这两个时间差都指向核心网处理异常无线侧没有可优化的点。提示在NGAP Cause IE中normal-release可能被标记为Radio Network Layer、Transport Layer或NAS三个不同层级。本案例的nas: deregister属于NAS层原因出现时应优先检查AMF与UDM之间N8接口交互。4. 联合定位找到根因UDM信令处理异常导致释放命令下发的逻辑链4.1 从无线侧到核心网的联合排查分工前台无线侧的判断已经明确Fast Return执行正常NR接入正常问题出现在NAS信令交互阶段。后台NG接口信令也确认释放命令来自AMF。此时排查方向已经从无线侧转到核心网需要核心网工程师配合围绕AMF和UDM之间的信令交互展开。联合定位时的分工通常是无线侧负责确认gNB侧是否有异常丢弃或错误转发核心网负责排查AMF的UE上下文状态、AMF与UDM之间的N8接口交互、UDM的签约数据处理流程。在明确AMF下发释放命令后无线侧的工作基本结束剩下的核心网内部排查需要抓取AMF日志和UDM日志进行比对。4.2 UDM信令处理异常如何触发AMF释放UE最终定位的结果是核心网UDM信令处理异常。UDM统一数据管理在5G核心网中负责管理用户签约数据、鉴权数据、订阅通知等。当UE发起PDU会话建立请求时SMF会通过AMF向UDM请求会话管理相关订阅数据UDM的响应需要通过N8接口返回给AMF。本次故障中UDM信令处理异常的表现是UDM在处理某个特定请求时内部状态机进入了错误分支没有正确返回预期的数据响应而是返回了一个异常指示。AMF收到这个异常指示后按照标准流程判定NAS消息的载荷无法继续转发因此向UE下发了DL NAS Transport并携带了payload-was-not-forwarded原因值。与此同时AMF内部将该UE的上下文状态标记为需要释放触发了UE Context Release流程。UDM信令处理异常还要区分为两类一类是UDM内部软件缺陷比如特定消息序列触发的空指针或状态机跳转错误另一类是UDM与周边网元的接口交互异常比如与AUSF或NSSF的交互超时。本案例属于前者即UDM自身处理逻辑问题与周边网元无关。修复UDM后故障现象消失再次验证了这个定位。4.3 排查此类问题时的参数采集清单与验证方法遇到“5G SA通话后回落4G”且疑似核心网问题时建议按以下清单采集数据避免反复多次下站测试# 前台采集建议 # 1. 开启终端侧的详细信令日志确保包含NAS层原因为payload-was-not-forwarded # 2. 同时抓取LTE侧和NR侧的RRM测量报告排除无线侧覆盖因素 # 3. 记录通话前后的RSRP/RSRQ/SINR快照验证是否有弱覆盖叠加 # 后台采集建议 # 1. NG接口信令全量跟踪导出UE级别的Initial UE Message到UE Context Release完整信令链 # 2. AMF侧UE上下文管理日志重点关注N2接口释放命令触发源 # 3. UDM侧N8接口交互日志查看UE PDU会话建立请求对应的签约数据响应 # 4. 时钟同步检查确保gNB、AMF、UDM时间偏差在100ms内验证UDM修复效果时最简单的做法是让终端重复执行VoNR通话挂断后返回NR的测试连续测试20次以上确认没有复现。同时观察NG接口信令中是否还有携带deregister的异常释放命令。修复后正常的流程应该是通话结束→Fast Return发起→LTE到NR重定向→NR随机接入→PDU会话建立→UE回到5G驻留态全程无额外RRC释放。提示如果UDM修复无法立即实施可通过在AMF侧调整相关定时器或关闭特定流程的临时规避。但这类操作属于核心网应急手段必须由核心网服务商评估后执行无线侧不建议也不应该干预。5. 从一次释放原因值反推核心网状态机的排查技巧5.1 把nRMM-cause当作核心网状态机的“指纹”在排查5G SA VoNR问题时很多无线侧工程师会习惯性先看覆盖、干扰、切换参数但遇到非典型释放原因值时需要跳出现有框架。payload-was-not-forwarded这类原因值的出现频率很低但每次出现都指向核心网内部的数据流转异常。把它当作状态机“指纹”来用这个原因值出现时意味着AMF或SMF在转发NAS消息时丢失了有效载荷。跨层联查的思路是先抓住前台LOG中终端侧记录到的NAS原因值再关联后台NGAP释放命令原因值然后反查AMF到UDM之间的信令交互。这套反向追溯的核心在于时间戳和UE标识的严格对齐。如果前台LOG和后台抓包的时间基准不一致建议使用相对时间比如从随机接入成功到PDU会话建立请求的时间差进行对比。5.2 常见释放原因值的快速判别表实际排查中积累的常见原因值判别参考如下| 原因值 | 出现阶段 | 可能根因 | 排查优先级 | |--------|---------|---------|-----------| | payload-was-not-forwarded | NAS交互中 | UDM/AMF状态机异常 | 核心网内部排查 | | normal-release (NAS层) | 流程未完成时 | AMF主动释放逻辑错误 | 查看AMF日志 | | nas: deregister | 未发起去注册时 | AMF误判UE去注册 | 查N8接口交互 | | radio network layer cause | RRC连接中 | 无线侧链路失败/定时器超时 | 查UU口信令和RRM | | transport layer cause | NG接口传输中 | SCTP链路中断/传输超时 | 查传输设备状态 |这张表的使用场景是拿到一条异常释放信令后先判断原因值属于哪个协议层再决定排查方向。如果原因值属于NAS层无线侧调参基本无效应该直接走向核心网联查。5.3 现场排查时如何用最小代价复现并验证复现此问题时不需要复杂的路测配置一台支持VoNR的商用终端配合网优后台的NG接口信令跟踪即可。具体做法是在SA覆盖良好的区域发起VoNR语音通话通话时长控制在30秒左右确保通话结束后终端进入Fast Return流程挂断电话后立即观察终端是否在10秒内返回5G。如果终端回落4G并持续驻留超过30秒则判定为异常复现。验证UDM修复是否有效时可以观察同一终端在修复前后的行为差异。修复前终端每次通话后回落4G且NR侧能看到UE Context Release命令修复后终端通话结束后直接驻留NRNG接口不再出现携带deregister原因值的释放命令。对于此类问题无线侧能做的是提供精准的信令抓取和分析结果把决策点交给核心网工程师跨网联查时优先输出前台LOG关键事件时间轴、NG接口释放命令时间点、携带的原因值三个信息这三个要素对齐后根因定位通常不会偏离方向。本文还有配套的精品资源点击获取