做外场测试这些年最常被新人问的一句话就是“哥我这个log抓回来了但完全不知道从哪儿看起这UE到底是注上网了还是没注上”其实这不怪他们LTE注网这个事儿牵扯的协议流程和信令交互确实挺多光看密密麻麻的log消息列表很容易两眼一抹黑。但反过来如果能把从开机搜网到最终稳定驻留的路径理顺把每个阶段该看什么消息、盯什么字段搞明白那LTE这张网的“脾气”你基本就摸透了一半。这篇东西我就用自己的实战经验把注网全流程里最关键的几个节点拆开揉碎从PLMN选择一路聊到小区驻留顺带把log分析的核心技巧一起交底。它不一定能让你五分钟变成专家但足够帮你建立一个清晰的分析框架下次再有人把log丢给你至少能第一时间判断出问题出在哪一段。1. 先把注网这件事的完整链路刻在脑子里很多人一上来就急着抓log、翻消息这其实是本末倒置。我建议你先在脑子里建一条时间线一张SIM卡插进手机之后UE到底经历了什么才最终在状态栏上显示出“LTE”三个字这条链路大概分成六步先选网再搜小区然后读广播消息接着发起随机接入之后建立RRC连接并完成核心网侧的附着最后才是进入空闲态驻留。每一步都有对应的专有名词和log消息顺序绝对不能乱。你只有先记住这条主线看log的时候才能根据时间戳逐段定位否则就是大海捞针。我在带人的时候经常打个比方注网这六个步骤就像是坐飞机——先买机票确定航司和目的地选PLMN再去航站楼找登机口搜小区登机后听安全须知读系统消息起飞滑跑随机接入升空巡航RRC连接和附着最后平稳落地驻留。哪个环节出了问题你按这个流程去查永远不会偏。再深入一点说这六步其实分属不同的协议层。PLMN选择、附着这类偏向NAS层非接入层小区的搜索、同步、广播消息读取、随机接入这些都属于AS层接入层而RRC连接管理则是两者之间的桥梁。你在log工具里看消息时通常能看到每个消息所属的协议层标识先分清它是NAS还是AS就能把排查范围缩小一大半。注网全流程里绝大部分“注不上网”的问题要么死在AS层的搜索和接入要么死在NAS层的鉴权或附着拒绝很少有人会在中途遇到那种莫名其妙的卡住大概率还是前面某个步骤埋了雷。2. PLMN选择阶段选错了网后面全白搭2.1 SIM卡里的“身份信息”决定了UE往哪儿跑PLMN的全称是公共陆地移动网络你可以简单理解成运营商的编号。它由MCC移动国家码和MNC移动网络码组成比如中国移动的PLMN是460-00中国联通是460-01中国电信是460-11。UE开机后干的第一件事就是读取SIM卡里的IMSI、归属PLMN列表、禁止PLMN列表这些数据然后按照一套优先级规则去决定“我该找哪个网络”。这套规则说起来也不复杂先看能不能找到归属PLMN也就是SIM卡开户所属运营商的网络找不到就按SIM卡里存储的优先级找等效PLMN或其他运营商网络。整个过程在log里体现为NAS层的PLMN search相关消息。这里有个非常典型的排查场景如果一张卡插进去搜不到网你第一时间要去查log里有没有当前PLMN被加入了禁止列表。我处理过一次“某区域所有终端无法驻留”的投诉最后定位出来的原因就是核心网在某个时间段里下发过过度拒绝导致终端把那个PLMN拉黑了偏偏测试卡和现网卡共用了同一个SIM卡配置文件结果一批测试终端全部中招。2.2 log里怎么确切看到PLMN选择的每一步在QXDM或QCAT这类工具里PLMN选择相关的消息一般在NAS层的EMMEPS移动性管理分支下。你会看到类似NAS EMM: PLMN selection、NAS EMM: TAU request这类条目。重点盯两个字段一个是Selected PLMN另一个是Registered PLMN。前者代表UE当前正在选择的PLMN后者代表UE最终完成注册的PLMN。如果这两个值始终为空或不一致说明PLMN选择阶段就出了问题。实操中我习惯在log里加一个时间过滤器把开机瞬间的前几秒单独框出来然后按消息名过滤“PLMN”关键字。这个动作看起来简单但真的能省下大量翻log的时间。还有一个小技巧如果用的是鼎利或路测软件它的界面通常直接显示了当前PLMN和运营商名但内嵌log不一定完整这时候还是要回到后台原始log里去找NAS消息才能看到详细的拒绝原因或选择逻辑。2.3 PLMN层易踩的坑和排障思路PLMN选择阶段的问题远不止“搜不到网”一种。有些表现是“能搜到网但注册不上”这种多与核心网的附着流程有关但也可能是终端选错了频段导致信号质量太差最终注册超时。另外漫游场景下PLMN选择尤为复杂终端要先判断当前所在区域是否被归属运营商纳入了漫游协议再去搜索允许的漫游PLMN列表这个优先级关系在log里同样可以顺着NAS消息的字段一步步捋出来。我个人建议排查PLMN问题时养成一个习惯先看状态栏显示什么有无信号、有无运营商名再看log里的搜索记录搜到了哪些PLMN、信号强度如何最后看注册请求发给了哪个PLMN回了什么结果。这三个信息一对照90%的PLMN问题都能锁定根因。如果搜到了目标PLMN但信号强度极差那就别在PLMN层死磕把问题丢给射频层去查。3. 小区搜索与同步从“一片空白”到“锁定PCI”3.1 PSS/SSS和PCI的关系搞懂它就看懂了搜网选定了PLMN之后UE就要在当前允许的频段上去搜索具体的小区了。LTE的小区搜索分为两个层次主同步信号和辅同步信号。UE先检测PSS完成时隙和符号同步并拿到小区组内ID再检测SSS完成帧同步拿到小区组ID两者组合起来就是PCI物理小区标识。PCI的范围是0到503共504个相当于每个小区的“门牌号”。在log里这一步通常体现为物理层上报的SIB1、MIB之前的测量和同步消息。如果你用的是QXDM会看到GW_DSP或LTEA相关消息里出现了PSS/SSS的检测结果以及计算出的PCI值。这个阶段的log分析重点不是去看数值有多大而是看“是否搜到了足够强的小区”。我经常跟新人强调一个概念搜网阶段只判断“这个PCI是否存在且信号足够”至于这个小区能不能驻留那要等读完系统消息才知道两者不要混为一谈。3.2 同频邻区干扰和PCI混淆在log里的表现外场搜网时最让人头疼的问题之一是PCI混淆。简单说两个不同小区如果配置了同一个PCI终端就会犯迷糊分不清自己到底测的是哪个小区。在log里你会看到同一个小区的测量结果在短时间内剧烈抖动或者切换请求发出去之后目标小区始终无法确认。这种问题用再好的工具也很难直观发现必须结合工参工程参数表包含经纬度、PCI、频点等去判断。还有一种情况是弱信号下搜网速度极慢。UE反复搜索但始终同步不上log里PSS/SSS检测失败的记录刷屏。这时候别急着怀疑终端先看看是不是测试环境里存在同频干扰源比如旁边有其他基站用相同频点开到了最大功率。LTE网络对同频干扰非常敏感信号质量差往往不是灵敏度不足而是底噪被抬高了。你可以在log里通过携带RSRP和RSRQ的测量报告来判断如果RSRP还行但RSRQ掉得厉害那八成是同频干扰在捣鬼。3.3 实操视角下的搜网阶段分析建议搜网阶段的log分析我推荐你按频点分组来看。LTE实测时候终端会支持多个Band但实际搜索是分频点逐个进行的。在log里UE会按照内置的频点优先级逐个尝试每个频点下都会出现搜索结果记录。你把这些记录按时间轴排开就能清晰看到终端在哪个频点上逗留了多久、为什么跳到了下一个频点。这个视角非常有用——如果某个频点的搜索时间异常长大概率是该频点存在干扰或者小区配置异常。工具使用上QCAT的消息过滤窗口是必不可少的。你可以新建一个过滤器把消息名定位到Physical Cell ID、SIB1、MIB这些关键节点上忽略掉其他无关的物理层噪声。另外QCAT左侧树形窗口里往往有一个Serving Cell或LTE Cell Info分类点开之后能直接看到当前服务小区的PCI、频点、带宽和RSRP比满屏翻log要直观得多。但记住软件显示的这些信息都是通过log解算出来的如果原始log不全显示的也不准最终还是要回到原始消息去验证。4. 系统消息读取MIB和SIB是终端了解小区“规矩”的唯一途径4.1 MIB与SIB各管哪一块别搞混UE完成同步之后紧接着就要读取小区的广播信息搞清楚这个小区到底让不让进、怎么进、进了之后用什么参数通信。LTE的广播信息分为MIB和若干组SIB。MIB是最基础的包含了系统带宽、PHICH配置、SFN系统帧号等关键参数周期固定为40ms承载在PBCH上。SIB则承载在PDSCH上其中SIB1最核心包含了小区的PLMN列表、TAC跟踪区码、小区禁止状态、Q-RxLevMin这些驻留相关参数。其他SIB还有各自的用途比如SIB2管随机接入和上行功率控制公共配置SIB3到SIB8管小区重选和邻区信息。理解这些信息的分工对你分析log有决定性的帮助。举个例子假设终端始终驻留不了一个信号很强的小区你翻log看到SIB1已经读取成功了但小区状态字段显示barred那原因就很明确——这个小区被禁止接入问题出在网侧配置而不是终端侧。反过来如果SIB1压根没读出来那就要考虑是不是信号质量不够稳定导致广播信道误码太高解不出来。4.2 系统消息读取失败的五种典型场景从我实际抓log的经验来看系统消息读取阶段最常见的异常有这么几类。第一种是MIB解调失败。这种通常发生在极弱信号或高干扰场景log里会看到连续多次PBCH解码失败记录。第二种是SIB1调度信息拿不到可能是因为PDCCH被干扰或者终端在MIB里解析出的带宽参数与基站实际配置不匹配。第三种是SIB消息里的PLMN列表与当前选择的PLMN不一致终端会认为这个小区不属于目标网络直接判定为不可驻留。第四种是SIB1里的cellBarred字段被置为禁止这种属于网侧主动把小区屏蔽了。第五种是TAC不被UE当前注册网络接受终端会在后续的TAU或Attach流程中被核心网拒绝。每种异常的log特征都略有差异但有一条通用规律别只看一条消息的结果要把连续多个系统消息的读取过程连起来看。比如MIB解调失败一次不代表有问题可能是瞬间抖动但如果连续多次失败而且每次失败的信号强度都差不多那就值得深挖了。4.3 用log快速判断小区是否允许驻留读完SIB1之后终端实际上已经能做出“这个小区能不能待”的初步判断了。你可以在log里搜索SIB1消息直接看里面的PLMN Identity List、Cell Barred、Q-RxLevMin这几个关键IE信息元素。如果SIB1里的PLMN列表包含目标PLMN小区状态是notBarred且测量到的RSRP高于Q-RxLevMin加上UE自身的最小接入门限偏移那这个小区就具备驻留条件了。这里也有一个实操技巧注意区分“可以驻留”和“允许接入”是两回事。可以驻留意味着UE能在这个小区上读取寻呼消息、发起后续流程允许接入则意味着核心网接受这个UE的注册请求。前者是无线侧的判断后者是核心网的决定。在log里前者的直接依据是SIB1的解析结果后者的直接依据是Attach流程中核心网下发的响应消息。新手最容易把这两个概念搅在一起看到SIB1没问题就以为“网络状态正常”结果注册不上就懵了。5. 随机接入与RRC连接建立从“敲门”到“进门”5.1 四步随机接入的前前后后小区驻留条件满足之后UE就要发起随机接入流程来申请上行资源。LTE的随机接入分为竞争性和非竞争性两种注网场景下通常用的是基于竞争的随机接入大体分四步UE在PRACH信道上发送随机接入前导Preamble基站回复随机接入响应RARUE发送RRC连接请求消息基站回复冲突解决消息。这四步走完终端就拿到了上行同步和临时标识。在log里这个过程的痕迹非常清晰。你会在物理层消息里看到PRACH的发射记录然后是MAC层的随机接入响应消息再往上是RRC层的RRCConnectionRequest。这里有个重点RRCConnectionRequest里会携带UE的标识S-TMSI或随机值和建立原因Establishment Cause。建立原因是个很重要的分析线索比如mo-Signalling代表终端主动发起信令连接mt-Access代表被叫接入如果建链原因的分布和你测试场景对不上那可能是终端侧应用行为异常。5.2 RRC连接建立失败怎么查看哪里RRC连接建立失败是我在外场测试里遇到最多的问题之一表现形式也多种多样。归纳一下常见的无非几种PRACH前导发射了但基站没有响应RRC连接请求发出去了但一直没收到建链响应或者收到了响应但随后的配置消息出错。每种情况的排查方向完全不同这就要求你在log里能准确地区分失败节点。前导发出去没人理大概率是上行覆盖不够或者PRACH配置的频域位置与基站不匹配诺基亚和华为网管里都有对应的PRACH接收统计但外场测试只能靠log里的RSRP和SINR来判断。RRC连接请求发出去了没响应则要怀疑公共信道资源配置有问题比如PDCCH的公共搜索空间被改得不可用。收到建链响应但配置消息出错则可能是终端与基站版本不匹配或者某些IE解析不兼容。我个人的经验是随机接入阶段的log分析不要只看RRC层的消息一定要结合MAC层和物理层的反馈。如果MAC层压根没有生成RAR成功解调的指示那问题大概率在物理层覆盖或参数配置如果MAC层已经上报成功但RRC层超时了那才是无线资源控制层的配置问题。这种分层排查的思路能帮你少走很多弯路。5.3 RRC连接建立完成之后还有一个关键动作RRC连接建立完成之后UE会给基站回一条RRCConnectionSetupComplete这条消息里携带了NAS层的Attach Request或TAU Request的封装内容。从这一刻起无线侧的活算是干完了接下来看的就是核心网侧的“脸色”。在log分析里我特别建议你把RRCConnectionSetupComplete作为一个里程碑时刻标记出来。它的时间戳之前所有问题都属于无线侧它之后如果流程卡住才算真正进入核心网问题域。很多新人不懂得做这种切分拿着整段log从头翻到尾效率极低。学会“按消息切流程”是一项非常核心的log分析技巧。6. Attach附着过程真正的“验明正身”环节6.1 Attach Request到Attach Accept的完整信令链RRC连接建立完成之后NAS层正式接管后续工作。终端发出Attach Request其中包含了UE的网络能力、GUTI或IMSI、PDN connectivity请求等信息。这条消息经过基站透传给核心网后核心网开始执行鉴权、加密、位置更新等一连串操作。正常流程下终端会依次收到Authentication Request鉴权请求、Security Mode Command安全模式命令然后可能是Attach Accept附着接受和Activate Default EPS Bearer Context Request激活默认EPS承载。在log里这条链的完整顺序非常关键。我见过不少“注网半途而废”的情况就是发完Attach Request之后核心网发来了鉴权请求但终端没有相应回复或者回复了鉴权失败。这种情况下看log就要重点盯两个方向一是终端侧是否收到了鉴权请求并成功处理二是核心网侧是否接受了终端的鉴权结果。因为原始log里只记录了空口侧的消息核心网侧的决策过程是反推出来的所以你需要结合响应消息里的具体Cause值来判断。6.2 EMM Cause值就是核心网的“拒绝理由书”当附着失败时核心网会在下发的NAS消息里携带一个EMM Cause值这个值就是核心网给你开出的“拒绝理由书”。比如Cause #2表示IMSI未知Cause #3表示非法UECause #6表示非法MECause #7表示EPS服务不允许Cause #11表示PLMN不允许Cause #13表示 roaming不允许Cause #15表示在该TA下没有合适的蜂窝网。每种Cause值的背后对应的是不同层面的问题有的是卡数据异常有的是核心网开户数据错误有的是漫游协议未覆盖只有先把Cause值看懂才能往下聊怎么修。我最常遇到的有两个一个是Cause #7一个是Cause #15。Cause #7通常意味着用户签约数据里没有开通LTE服务但测试卡经常出现这种问题多半是核心网的签约数据同步出错Cause #15则多见于跨省或跨运营商测试场景终端的漫游权限没配好。针对这两种情况终端侧几乎做不了什么只能反馈给核心网或数据配置的人员去刷新签约数据或调整移动性限制。6.3 加密与完整性保护相关的坑附着流程里的安全模式命令阶段也有几个实操中容易踩的坑值得单独拎出来讲。第一终端收到的Security Mode Command里的加密算法如果终端不支持终端会回复Security Mode Reject附着直接中断。这种情况在测试中经常是因为终端和基站/核心网的算法优先级配置不一致尤其是一些定制化终端或新采购的测试终端算法表往往有差异。第二完整性保护失败也会导致附着失败但是这种失败在log里往往没有明确的Cause提示只看到终端在下行NAS消息后不再回复任何消息看起来像是“卡死”了。这时候要回头检查安全上下文的完整性比如终端上是否残留了上次注册的陈旧安全参数。个人建议是在做跨网测试时提前确认终端支持的加密算法列表并使用log里的UE Network Capability字段去核对防止到现场才爆雷。这种细节非常容易被人忽略但每次查附着失败查到最后我十有八九能从这里翻出点故事。7. 小区驻留与后续行为别以为驻留了就万事大吉7.1 “注上网了”和“驻留成功”其实是两个概念很多人把“状态栏出现LTE图标”和“驻留成功”画等号这个误解在外场测试里非常危险。状态栏出现LTE图标只能说明终端已经完成了网络注册但驻留成功指的是终端处于空闲态已经选定了合适的服务小区且能够正常读取寻呼消息。理论上讲注册成功之后必然会找到一个合适的服务小区待着但在实际操作中因为信号波动、小区禁止状态变化、重选参数调整驻留状态是动态的。在log里面判断驻留成功的标志是终端进入RRC_IDLE状态并且系统消息里SIB1的驻留条件持续得到满足。你可以在log里看到RRC Connection Release消息这个消息代表RRC连接被释放终端回落空闲态。之后如果log里持续出现SIB1的周期性读取记录且读取结果都满足驻留条件那说明终端已经处于稳定的驻留状态。7.2 重选参数对驻留行为的影响空闲态下小区重选参数的好坏直接决定了终端的驻留稳定性和用户体验。SIB3里包含的服务小区重选参数以及SIB4里的同频邻区重选参数、SIB5里的异频邻区重选参数是分析驻留稳定性的关键。如果这些参数配置不合理就会出现一种非常恼人的现象终端在A小区和B小区之间来回重选表现为log里频繁出现Cell Reselection记录连着看就像“打乒乓球”。遇到这种情况不要先去怀疑终端实现有Bug而是先核对重选门限参数比如ThreshServingLow服务小区低门限、Qhyst服务小区滞回值、QrxlevminOffset最小接入电平偏移量。这些参数任何一个设置得过于激进都可能加剧乒乓效应。在log里找这些参数不需要去解析SIB内容直接在QCAT的SIB3/SIB4条目下看解码结果就行非常直观。7.3 若隐若现的“间歇性脱网”怎么查还有一种很典型的驻留问题是终端在某些路线上定时定点的“掉网”但过几秒又自己恢复了。这种间歇性脱网的排查比“完全注不上”要难得多因为log大部分时间看起来都是正常的。我的做法是先把log按时间切块找出脱网的时间段然后重点看脱网前的最后几条消息。如果脱网前伴随RSRP急剧下跌那就是覆盖黑洞如果RSRP还算正常但SINR很差那就是干扰问题如果无线信号都没问题则要看是不是NAS层被核心网主动Detach了。这几种可能性的log特征差异非常明显只要你把时间轴对齐很快就能排除掉大半干扰项。外场测试里我最反感的就是“测了三个小时只有一次掉网复现不出来”这种case的log尤其宝贵抓到的一定要单独保存并且把时间点记录在现场测试Log的备注里。没有备注的log事后回放极度浪费时间这是无数次踩坑换来的教训。8. 实用速查注网问题定位的“一页纸”指南8.1 按现象查原因对照表为了让这些经验真正落地我把这些年碰到的典型问题整理成了一张速查表按现象对应到排查方向和关键log消息能帮你在现场快速圈定目标。现象描述可能原因优先排查的log消息开机后始终搜不到网频点配置错误、禁止PLMN、射频故障NAS EMM PLMN search、PSS/SSS检测消息搜到小区但无法驻留SIB1中小区被禁止、RSRP低于最小门限SIB1中的cellBarred、q-RxLevMin随机接入反复失败上行覆盖不足、PRACH参数配置错误MAC RAR响应、PRACH发射记录RRC连接建立超时公共信道配置异常、信令拥塞RRCConnectionRequest、RRCConnectionSetupAttach被拒绝签约数据异常、漫游权限不足NAS EMM Attach Accept中的Cause值驻留后频繁重选小区重选参数不合理、邻区漏配SIB3/SIB4/SIB5、Cell Reselection记录间歇性脱网覆盖空洞、干扰、核心网主动释放脱网前RSRP/SINR、NAS Detach消息8.2 log分析时的三条军规最后想说三条我在带测试团队时反复强调的纪律也算是我个人从上百次log分析实战里提炼出的底线原则。第一条任何log分析都必须先对齐时间基准。外场测试时log工具记录的时间有可能与现场测试手记的时间有偏差如果GPS锁星不稳定时间偏移甚至能达到几百毫秒甚至更多。分析之前先把log时间和当时测试记录的时间校准否则你按着手记时间点去翻log翻到的可能完全不是同一个场景。第二条永远不要只看单条消息下结论。无线通信系统中一次失败往往不是孤立事件前后几秒内的消息之间可能存在千丝万缕的因果联系。尤其是物理层的瞬态波动单看某一条消息可能只是偶发的小概率事件只有把连续多帧的上下文串联起来才能判断是“异常”还是“误伤”。我从来不会因为一个PRACH前导没响应就草木皆兵一定是把前导发射前后的RSRP和干扰水平都拉出来看一眼再定性。第三条原始log比任何解析工具都更可信。QCAT、QXDM这些工具解析出来的消息字段大部分时候是准确的但在信令异常或私有IE场景下偶尔会解析错位。遇到数据对不上或者结果看似矛盾的情况一定要回到16进制原始字节流去看这一条在我整个从业生涯里救了我无数次。9. 聊聊我自己常用的log分析节奏实际操作上我拿到一段注网log后很少会从头到尾逐条往下翻。我的习惯是先用QCAT自带的快速过滤功能把协议层定位到NAS层先看附着流程的整体脉络确认走没走完然后回到RRC层看连接建立过程最后才扎进物理层看信号质量和干扰水平。这个顺序从宏观到微观能快速筛掉大部分无关消息让你在最短时间内锁定问题区域。如果你也正处在“log打开了一堆消息但不知道先看什么”的阶段不妨试试这个三层过滤法。分析注网流程没有太多玄学无非是提前把主流程背得滚瓜烂熟然后把每一个异常点都放到整条链路里去定位。有时间的话拿几段老log反复练手很快你就能练出一双看log就能“脑补出信号波形”的眼睛。
