做LTE/NR外场测试和信令排查这些年我翻过最多的东西是log里那一行行cause。很多刚入行的同事问过我同一个问题这个cause到底是什么意思说实话我刚开始看日志时也有同样的困惑——一条RRC连接莫名其妙被释放NAS层弹出一串数字编号网管侧显示的失败原因五花八门到底该信哪一个、从哪查起这篇文章不写空泛的理论把我这些年实际遇到过的高频cause场景完整整理一遍从RRC层到NAS层从LTE到NR把“失败原因值”的判断思路和定位方法讲清楚。适合外场测试工程师、网优人员和刚转行做协议栈开发的朋友参考看完至少能少走几次弯路。1. Cause机制到底在解决什么问题1.1 一个生活化的类比快递退单原因码打个比方你在电商平台下单后迟迟没收到货物流轨迹上会更新一条“派送失败原因收件人电话无法接通”。这条原因码不会直接告诉你“快递小哥心情不好”也不会替你解决联系不上人的问题但它能让你知道该往哪个方向去处理——是重新联系收件人、换时间派送还是退回仓。LTE和NR里的cause就是干这个事的。终端、基站、核心网三方在信令交互过程中一旦某个流程走到一半走不下去失败的一方就会在响应消息里塞一个原因值告诉对端“我为什么没办成”。这里的关键是cause不是给你看热闹的它是信号系统里标准的“故障交接单”让下游设备能针对不同原因做差异化处理也让运维人员能按图索骥式地排查。1.2 为什么需要分层的Cause体系LTE/NR的协议栈本身就是分层的所以cause也天然地分层出现不能混在一起谈。在空口侧RRC层负责连接建立、重配和释放RRC消息里带的cause主要描述“无线侧为什么失败”。在NAS层也就是终端和核心网之间的信令负责附着、位置更新、PDN/PDU会话建立这里返回的cause是一串编号比如“#7 EPS services not allowed”描述的是核心网对终端签约状态、位置权限的判决结果。再往上走在基站和核心网之间的接口S1AP/NGAP以及基站与基站之间的接口X2/Xn也各自有一套cause体系分门别类叫“radioNetwork”“transport”“nas”“protocol”“misc”。这几层cause不是相互独立的很多时候一个业务失败会在多层同时留下痕迹。比如VoLTE呼叫失败空口RRC层可能释放连接NAS层显示“#17 Network failure”NGAP接口上又显示“radioNetwork: release-due-to-ng-ran-generated-reason”三层信息叠加起来才能拼出完整画面。这也是为什么一线测试时不能只看一个接口的cause否则很容易被单点误导。1.3 Cause是现象不是根因这是我特别想强调的一点。Cause告诉你的是“哪个环节报了什么失败”不是“底层到底出了什么问题”。打个比方你打开电脑发现浏览器打不开网页系统提示“无法连接到服务器”这个提示是cause但真正的原因可能是网线松了、DNS配置错了、服务器宕机甚至可能是防火墙拦截。你把系统提示当成根因去修大概率白忙活。在LTE/NR排查中我看到太多人一看到“congestion”就下结论说核心网拥塞一看到“RRC Connection Setup Failure”就说是基站覆盖问题。实际上一个cause背后往往对应着三四种甚至更多的底层可能。处理cause的正确姿势是把它当成一条排查的线索结合信令时间线、测量报告、射频参数去反推真正的罪魁祸首。2. 从LTE到NRCause体系的演进与布局2.1 LTE时代的经典Cause分布LTE的cause体系经过了多年的商用打磨已经相对稳定。RRC层最常见的释放原因无外乎“loadBalancingTAURequired”和“other”前者通常是系统为了负载均衡主动让终端去做TAU后者是一个兜底值绝大多数非典型释放都会挂上“other”。RRC连接建立失败时RRC Reject消息里常带“congestion”或“other”同时会携带一个waitTime告诉终端过多久再重试。NAS层的cause则是外场测试里最常需要查询的内容。核心网拒绝附着或TAU时会返回EMM cause编号常见的有#7EPS services not allowed、#11PLMN not allowed、#12Tracking area not allowed、#13Roaming not allowed in this tracking area、#15No suitable cells in tracking area、#17Network failure、#22Congestion。这几个值在LTE时代几乎是每天都要翻一遍的。接口侧的cause同样重要。S1AP接口的cause大类分为radioNetwork、transport、nas、protocol、misc其中radioNetwork子类下的“radio-connection-with-ue-lost”和“ue-inactivity”出现频率最高。X2接口处理切换时如果目标小区资源不足会返回“radioNetwork: no-radio-resources-available-in-target-cell”这一类原因对判断切换失败归因很有帮助。2.2 NR新增了哪些值得关注的Cause场景到了5G NRcause体系在继承LTE思路的基础上针对新架构和新特性增加了一些内容。NR的RRC层依然保留RRC Release cause但在RRC重配和SCGSecondary Cell Group管理上新增了更细的失败原因。尤其是NSA组网下终端上报的SCG Failure Information里会携带failureType常见的有t310-Expiry主小区定时器超时、randomAccessProblem随机接入问题、rlc-MaxNumRetxRLC达到最大重传次数、synchReconfigFailureSCG同步重配失败、scg-ReconfigFailureSCG重配失败、srb3-IntegrityFailureSRB3完整性校验失败这个字段在做5G CA和双连接测试时非常管用。NAS层面NR的5GMM/5GSM cause在编号和语义上基本延续了LTE的思路比如#3、#6、#7、#22这些经典值。但NR引入了网络切片、服务化架构所以新增了和切片相关的拒绝原因。比如终端请求的S-NSSAI不被网络支持时注册接受消息里会带上相应的cause这时候如果你还拿着LTE时代的经验去查签约状态可能查半天发现方向错了。2.3 各层Cause的协议出处速查下面这个表是我平时建议团队里新人先背下来的不需要记全但至少要能在30秒内翻开正确的协议章节。协议层协议文档Cause出现的位置典型应用LTE RRCTS 36.331RRCReject / RRCRelease / RRCConnectionSetupFailure等空口连接建立与释放NR RRCTS 38.331RRCReject / RRCRelease / SCG Failure Information空口连接、CA/DC流程LTE NASTS 24.301EMM/ESM cause附着、TAU、PDN连接NR NASTS 24.5015GMM/5GSM cause注册、PDU会话、切片S1APTS 36.413Cause IE基站与LTE核心网NGAPTS 38.413Cause IE基站与5G核心网X2/XnTS 36.423 / TS 38.423Cause IE基站间切换、双连接实际工作中我的习惯是先在log搜索窗口里按“cause”关键字过滤定位到失败消息后再反查协议而不是抱着协议文档从头翻。因为协议里的cause枚举项很多但外场实际能看到的就那么几十个做得多了自然有敏感度。3. 外场测试中高频Cause场景拆解3.1 RRC连接建立失败一个“Congestion”背后至少三种可能RRC连接建立失败是外场测试里最经典的场景。终端发起RRC Setup Request之后网络侧如果回复了RRC Reject最常见的cause就是congestion或者other同时还带一个waitTime。很多人看到congestion就把问题定性为“小区拥塞用户太多”这个结论我见过太多次是不准确的。我实际维护过的现网案例里RRC Reject显示congestion的情况至少有三种底层可能第一小区确实处于高负荷状态随机接入前导资源和RRC信令资源不足这个占一部分比例第二基站侧存在配置问题比如上行干扰导致RRC Setup Request消息在空口被基站解不到或者解错基站误判为资源不足于是回了congestion第三终端的接入等级被限制比如AC barring机制起作用网络主动拒绝接入此时cause也可能显示congestion或类似语义。排查这类问题不要只看cause字段。正确的做法是同时看终端和基站两端的log确认RRC Setup Request是否真的到达基站再看基站的资源状态和干扰指标。如果请求消息基站压根没收到那congestion大概率是误判真正的问题在上行覆盖、干扰或者参数配置。3.2 移动性与切换失败场景切换失败是外场路测里另一类高频问题而且这类问题的cause往往隐藏在两个环节里准备阶段和执行阶段。准备阶段源基站向目标基站发起切换请求如果目标基站没有资源给终端会返回切换准备失败X2/Xn接口上的cause大概率是“no-radio-resources-available-in-target-cell”或者“radioNetwork: insufficient-uplink-quality”之类。这种问题通常要往目标小区的容量配置和邻区关系上查。执行阶段终端收到切换命令后尝试接入目标小区如果随机接入不成功或者目标小区信号质量实际上不满足条件RRC重配流程可能失败。此时空口侧大概率看不到一个明确的“cause”终端只是静默地触发RRC重建或者上报SCG Failure Information。实际log里经常要通过定时器状态来判断——比如T310超时、T304超时这些定时器本身就是隐式的失败原因。做外场测试时我建议切换类问题不要试图只靠一个字段定性要把源小区、目标小区的测量报告和定时器日志放在一起看。终端在切换命令中配置的目标小区PCI、频率和实际测量到的是否一致这个基本检查往往能排除一半的“莫名失败”。3.3 释放类Cause与“被静默断开”场景释放类cause里用户主动挂断时的释放和网络侧主动释放的cause是完全不同的。网络侧主动释放最常见的原因之一是“Radio Connection With UE Lost”翻译成人话就是网络侧在定时器规定的时间内没有收到终端的反馈认为你“失联”了于是主动把资源释放掉。这个场景在外场最大的特点是隐蔽。终端看起来是“突然没信号”或者“业务卡住几秒后自己断了”不像切换失败那样有明显的信令冲突。你翻空口日志可能只看到下行发了一堆RRC重配或者RLC轮询但终端一直没有回应过了几秒基站直接下发RRC Releasecause挂的是“other”更老练的抓法是在旁边的小区看到“UE Context Release Request”里带“radio-connection-with-ue-lost”。遇到这种情况我的排查经验是先确认是上行失步还是下行漏检。上行失步往往跟覆盖边缘、上行干扰、TA值维护有关下行漏检则可能跟终端实现有关。这里没有万能公式但有两条保命原则一是把释放前最后几秒的下行调度和上行收到情况完整导出来看二是不要一看到“UE lost”就怪终端基站下行波束配置在5G里造成终端解不到下行的案例同样不少。3.4 核心网判决类Cause附着、TAU和注册拒绝核心网侧的cause和无线侧风格完全不同它们更像是一个“法院判决书”直接给出终端的权限和状态结论。外场测试里手机如果插了一张签约不完整的卡或者测试区域和卡的签约地不匹配最常见的就是附着或TAU被拒绝。比如终端发起附着请求后核心网返回#7 EPS services not allowed说明这个网络的EPS业务对该终端不可用常见原因包括卡未开通数据业务、网络类型不匹配。如果返回#11 PLMN not allowed说明当前PLMN不在卡的允许列表里漫游场景尤其常见。如果返回#13 Roaming not allowed in this tracking area说明漫游功能在用户级别或者位置区级别被限制了这种问题多数要联系核心网改数据无线的兄弟们再怎么调参数都解决不了。做这类问题定位时我习惯先把卡的信息确认清楚包括用户的APN配置、签约QoS、漫游白名单。很多看起来是“信号问题”的投诉最后都是核心网侧签约数据错误排查时不要在空口浪费太多时间。4. 一次完整排障从Cause到根因的实战记录4.1 问题现象与现场环境有一次在外场做VONR测试遇到一个特别典型的情况测试终端在5G覆盖良好的区域发起VoNR呼叫主叫界面显示拨出后大概三秒钟电话自动挂断界面弹“呼叫失败”。从无线环境看RSRP和SINR都在正常范围内PSS/SSS同步和小区接入都没有异常。当时的第一反应是IMS侧注册可能有问题但空口的连接建立过程看起来是成功的。我先把log从终端侧完整导出来从上到下扫述。过程是这样的终端做初始注册RRC建立成功NAS层发送注册请求网络回了注册接受这些都很正常。但随后终端发起PDU会话建立请求时网络返回了5GSM cause拒绝具体是“#26 Insufficient resources”类似语义。这就很有意思了因为无线侧指标良好核心网却回了资源不足。4.2 抓取日志后的逐层逆行排查拿到拒绝消息后我先不急着下结论而是采用“逐层逆行”的方式排查。所谓逆行就是按NAS - NGAP - RRC - 物理层的顺序从高层往底层推。第一步看NAS层PDU会话建立请求检查终端请求的DNN、S-NSSAI和QoS参数是否在套餐允许范围内。这里发现终端请求的5QI/ARP组合比较特殊是一个视频类高优先级业务。第二步看NGAP接口上核心网和基站之间的消息确认核心网拒绝时携带的NGAP cause类型属于radioNetwork、transport还是nas。最后再看基站侧log在这段时间有没有资源过载或license受限的告警。排查下来发现问题果然不在无线侧。核心网返回资源不足的原因是用户签约的DNN不支持该5QI组合对应的QoS特性导致UPF资源无法按请求参数分配。这个原因在无线侧完全看不出任何异常如果只盯着空口cause很容易得出“5G覆盖有问题”的错误结论。4.3 根因定位与结论最后联系核心网的同事核对签约数据确认这条用户数据里QCI/5QI映射表确实少配了对应的承载类型修改签约后问题消失。整个排查过程耗时不到半天但其中最有价值的不是“找到错了”而是验证了一条排查方法遇到高层cause时先把cause所在的协议层定位清楚再沿着接口向上查别在一个层面死磕。这个案例我后来也讲过很多次。很多外场测试人员对空口信令很熟但一看到NAS层的数字编号就发怵其实NAS层的cause反而比RRC更“诚实”——它直接告诉你是业务层面被拒还是网络层面出错更容易导向根因。5. 排查工具与速查表5.1 常用信令分析工具与操作技巧现在做LTE/NR信令分析主流终端厂家的log工具、路测软件都能直接解析RRC和NAS消息。不管是哪家工具我建议重点关注三个过滤能力按消息类型过滤、按Cause字段过滤、按流程ID过滤。流程ID这个功能特别重要。一个业务从建立到释放会跨多条消息工具如果能把同一次呼叫的所有信令串成一个流程树配合时间线看cause的位置就非常清楚。比如同样是RRC Release有的发生在IMS注册过程中有的发生在呼叫结束时处置优先级完全不同。如果工具解析不出来或者厂商字段命名不统一最快的方法是在原始log里搜“cause”“reject”“failure”“timerExpiry”这几个关键词把失败消息附近的原始信令翻出来人工读。这个方法老土但有效关键时刻能救命。5.2 常见Cause值速查表下面是我个人整理的外场高频cause速查表分享出来供参考。NAS层EMM/5GMM常见值如下cause编号含义常见方向#3非法UE卡数据问题#6非法终端终端IMEI被拉黑#7EPS/5GS业务不允许未开通数据业务、卡类型不匹配#11PLMN不允许漫游列表外#12位置区不允许TAC白名单问题#13当前TA不允许漫游漫游签约限制#15TA内无合适小区覆盖、频段、PLMN选择问题#17网络失败核心网内部、传输故障#22拥塞网络过载、资源不足SCG失败类型速查如下failureType含义高频排查点t310-ExpiryPCell物理层失步定时器超时主小区覆盖、干扰randomAccessProblem随机接入问题目标小区接入参数、干扰rlc-MaxNumRetxRLC达到最大重传空口质量、RLC参数synchReconfigFailureSCGSCG同步重配失败PSCell配置、波束配置scg-ReconfigFailureSCG重配失败参数兼容性、能力集srb3-IntegrityFailureSRB3完整性校验失败安全参数协商需要说明的是这两张表只能帮你快速定位方向具体到项目时要结合厂商的给网状态和信令版本微调不建议死记硬背。5.3 怎么建一份自己的Cause知识库我个人比较推荐新人在做项目时顺手建一份自己的cause对照表格式不用复杂一列是cause原文一列是实际遇到的时间点一列是当时的根因结论一列是后续的处理动作。每次遇到一个新cause就补一行半年之后你会发现自己对外场问题的判断速度比翻协议快得多。这块我还有一个心得给cause打标签时不要只按“无线/核心网”分成两类建议再细分到具体流程比如“注册阶段”“PDU会话建立阶段”“切换阶段”“释放阶段”。因为同一个cause在不同流程里的含义差异很大按流程归类比按值归类更实用。6. 避坑清单一线工程师的真实体会6.1 只看Cause不看上下文最容易走偏这是我踩过最大的坑。有一次排查一个低速率投诉终端侧log显示RRC Release cause是“other”同事看了一眼就说“基站主动释放问题在无线侧”结果查了半天覆盖和干扰都没有异常。后来把核心网侧log调出来才发现是核心网侧的策略控制触发了专载去激活空口的RRC Release只是执行层动作。所以我现在定下一个铁规矩任何cause都必须放到至少三条消息组成的上下文里看脱离上下文的cause没有意义。6.2 别把“网络翻译”当成“原始定义”很多log工具会给你把cause自动翻译成一段文字比如“UE Context Release Request”里的radioNetwork cause被翻译成“无线侧原因无线连接丢失”。翻译本身没错但容易造成两个误导一是让人觉得问题已经定位了二是掩盖了原始字段的具体值。正确做法是双击打开原始IE看它到底是radioNetwork下的哪一个枚举值因为同一个大类下的不同子类排查方向完全不同。6.3 忘了看时间线和重传是最常见的隐性失误很多失败cause背后的关键信息不在cause本身而在它出现前几秒发生了什么。比如相同的一条“radio-connection-with-ue-lost”原因可能是终端长时间没收到下行数据触发检测也可能是上行方向大量重传导致网络判定失联。这两个方向一个查下行覆盖和波束一个查上行干扰和调度。只盯着cause字段看永远发现不了区别。所以我做信令分析时一定会先把时间轴网格打开确认重传率和定时器状态。6.4 别急着甩锅给“对端”做RAN侧的人容易把核心网回复的cause当证据说“是核心网拒的”做核心网侧的人容易把空口释放当证据说“是无线侧丢的”。实际上很多cause是“上游触发、下游执行”两侧看到的都是同一个结果的不同侧面。我比较推荐的做法是把NGAP口和空口的两段log对齐拉到同一时间坐标系里看谁是先发起的失败是响应失败还是主动失败。这种视角转换往往能发现真正的根因反而在你们都没注意的传输层或配置层。说到最后我在实际工作中最深刻的体会是cause这套东西本质上是一套标准化的“问题交接语言”它不可能替你完成思考但能帮你在几十条错综复杂的信令里快速框定范围。真正拉开一线工程师差距的不是背了多少cause值而是拿到一个cause后能不能冷静地把上下文梳理清楚把时间线拉平把相关接口的信息都对齐。如果这篇文章能帮你少走一次弯路下次看到“congestion”和“other”时多留一个心眼我就没白写。