干LTE外场测试这几年我见过最多的画面不是设备故障而是一群工程师对着LOG里一屏红色信令干瞪眼。手机信号格明明满着业务就是起不来测试计划卡在那里客户在旁边越催越急。这种时候能不能把这屏信令从上到下读明白直接决定了你是提出问题的人还是解决问题的人。先说个基本定律数据不动信令先行。UE每一次从无网络状态到注册成功从空闲态恢复数据业务背后都是NAS层和AS层两条信令链在协同工作。而其中最核心的两条流程就是Attach附着和Service Request业务请求。只要你把这两条链吃透后面查VoLTE时延、5G回落、VoNR信令用的都是同一个底子。这篇东西不打算写教科书式的协议原文而是按外场测试的真实视角来拆Attach到底怎么一步步完成的Service Request为什么经常在空闲态翻车出问题时日志里该看哪条消息、哪个字段以及我踩过的一些坑。1. 为什么Attach与Service Request是测试里最值得先啃掉的两条信令链1.1 外场测试里最常见的困境手机有信号但业务起不来测试中经常遇到的现象是终端显示LTE信号满格但拨不了电话、点不开网页、拉不起视频流。很多人第一反应是“核心网故障”或者“基站问题”其实很多时候问题就出在信令流程本身——要么Attach没有成功UE根本没注册进网络要么Service Request触发了但空口上下文建立失败用户面数据通道压根没搭起来。我在项目里带过不少新人发现他们有个共同习惯看到失败第一件事是截图然后问别人“这是什么原因”。但你要问他“这条失败消息是从哪个网元发出来的”“它属于NAS层还是AS层”“之前一条消息是什么”往往答不上来。信令排查的第一步不是猜原因而是先把流程位置定住——就像看病先分科你至少得知道是骨科还是内科的问题。Attach和Service Request恰恰覆盖了两种完全不同的定位场景。Attach解决的是“网络认不认你”的问题涉及签约、鉴权、位置更新、默认承载建立失败原因大多在NAS层能直接看到原因值。Service Request解决的是“网络怎么把你从挂起状态叫醒”的问题涉及RRC建立、UE上下文恢复、DRB重建失败原因往往分散在空口和S1接口两侧排查思路跟Attach有本质区别。1.2 NAS层与AS层信令流程里的两条腿要读懂LTE信令脑子里必须绷着一根弦信令是分层的一条完整流程往往要穿过ASAccess Stratum和NASNon-Access Stratum两层。打个比方。AS层是小区门口的保安负责你进小区这一段的秩序——随机接入、RRC连接建立、无线承载配置都归他管。NAS层是物业中心负责更上层的事务——你叫什么名字、住哪栋楼、有没有交物业费、门禁卡能开哪几扇门这些由MME移动性管理实体和UE之间的对话决定。Attach Request、Authentication、Attach Accept这些都是NAS消息但它们不能自己飞必须搭在AS层建立的RRC连接上走。这个关系在LOG里非常直观。你打开测试软件看到的第一条信令往往是RRC Connection Request然后是RRC Connection Setup Complete——这条消息里面就藏着一个NAS信封dedicatedInfoNAS里面装的可能就是Attach Request。eNodeB不拆这个信封直接把它打包进S1AP的Initial UE Message转发给MME。所以你在空口LOG上看到的“Attach Request”和核心网后台看到的“Initial UE Message”其实是同一件事的两面。理解这个分层逻辑之后排查就有方向了如果RRC连接都建立不起来那是AS层的问题先查覆盖、干扰、随机接入参数。如果RRC建立了但MME一直不回NAS响应那就是S1链路或核心网的问题你得跑到MME侧去跟踪。很多新手卡在“信号满但业务不通”这个死结就是因为没分清到底该看哪一层。2. Attach流程逐层拆解从开机到默认承载建立2.1 Attach的信令全景一条RRC连接串起四次握手Attach流程的最终目标是完成两件事一是让MME确认UE的身份和签约权限二是在UE和PGW之间建好一条默认承载让UE有“路”可以走数据。整个流程如果从空口LOG看消息顺序大概是这样的步骤方向主要信令功能说明1UE → eNodeBRRC Connection Request随机接入成功后请求建立RRC连接建立原因一般为mo-Signalling2eNodeB → UERRC Connection Setup分配SRB1资源空口连接初步建立3UE → eNodeBRRC Connection Setup Complete含Attach Request携带NAS Attach Request还有PLMN、TAI、UE网络能力等4eNodeB → MMES1AP Initial UE Message含Attach RequesteNodeB把NAS消息转发给MME同时带S1AP UE ID5MME → UENAS Authentication Request发起鉴权验证USIM卡合法性6UE → MMENAS Authentication Response返回鉴权响应参数7MME → UENAS Security Mode Command协商NAS加密和完整性保护算法8UE → MMENAS Security Mode CompleteNAS安全上下文建立完成9MME → eNodeBS1AP Initial Context Setup Request携带UE上下文、DRB建立列表、安全密钥有时Attach Accept也一同封装10eNodeB → UERRC Connection Reconfiguration建立SRB2和DRB配置AS安全11UE → eNodeBRRC Connection Reconfiguration CompleteUE完成无线承载配置12eNodeB → MMES1AP Initial Context Setup ResponseeNodeB通知MME空口上下文建立完成13MME → UENAS Attach Accept含Activate Default EPS Bearer Context Request通知UE附着成功并激活默认承载14UE → MMENAS Attach Complete含Activate Default EPS Bearer Context AcceptUE确认附着完成默认承载激活不同设备商的实现细节会有顺序差异但整体骨架不变。你只要记住整个Attach流程就是“先建路RRC、再验人鉴权、后发证安全模式、最终通水通电建承载”。2.2 关键消息里的隐性信息看LOG不能只看消息名关键字段才是排查的重点。第一条要盯的是RRC Connection Request里的establishmentCause。如果大量Attach请求的原因是mo-ExceptionData或者delayTolerantAccess那说明终端行为不太正常可能是应用层在频繁触发异常数据上报不是网络问题。第二条是Attach Request里的EPS attach type。它有三种取值EPS attach、combined EPS/IMSI attach、EPS emergency attach。外场测试里如果发现终端一直发起emergency attach说明USIM卡状态异常或者PLMN被禁止了这是一个很容易被忽略的信号。第三条是Initial UE Message里的TAI和ECGI。这两个字段能告诉你UE从哪个小区发起附着是验证小区规划、跟踪区配置是否合理的第一手数据。我遇到过很多次“附着失败但后台MME看不到任何记录”的情况最后检查发现是eNodeB配置的TACTracking Area Code和MME侧的TALTracking Area List对不上导致MME直接丢弃了消息。鉴权环节也要多看两眼。Authentication Request里的UMTS/EPS鉴权参数RAND和AUTN一般LOG软件会直接显示。如果经常出现Authentication FailureSSIM卡密钥和核心网的鉴权数据不一致历史原因多出在测试卡写卡环节或者HSS数据同步异常。外场碰到这种问题不要急着让核心网重新导数据先从测试仪表或终端侧把USIM的ICCID、IMSI抄下来核对十有八九是卡数据配错了。2.3 附着成功后为什么还要做TAU很多外场工程师有个误区以为Attach Accept收到就万事大吉。实际上在Attach流程里还隐含了一个过程——MME可能在Attach Accept里分配了GUTI同时下发了TAI List。如果UE发现当前小区不在TAI List里会在Attach完成后立刻发起Tracking Area UpdateTAU。这个细节非常重要。我见过有人做外场测试Attach明明成功了但业务就是一直起不来。后来抓LOG发现Attach Accept后紧跟着就是一次TAU Request而TAU被核心网拒绝了UE直接回到LIMITED_SERVICE状态。整个问题的根源是TAI List规划不合理并非Attach本身失败。所以分析日志的时候不能只看单条流程要把Attach和后面的TAU连起来看成一个完整的故事。3. Service Request空闲态到连接态的业务恢复之路3.1 Service Request和Attach的本质差异Attach完成后UE其实并没有一直占据空口资源。为了省电和降低信令负载网络会把长时间不传数据的UE释放到空闲态ECM-IDLERRC_IDLE。这时候UE和网络之间没有RRC连接也没有S1连接但核心网还保留着UE的上下文包括签约信息、安全上下文、默认承载信息。当UE侧有上行数据要发送或者网络侧有下行数据到达并触发寻呼Paging时UE就需要从空闲态回到连接态这个过程就是Service Request。所以两者的本质区别是Attach是从“无注册状态”到“已注册状态”Service Request是从“已注册但空闲”到“已注册且连接”。Service Request不需要重新做完整的鉴权和默认承载建立它要把原来留在网络里的上下文重新激活起来快速搭好空口数据通道。这个区别直接决定了排查思路。Service Request失败时不要一上来就去查签约和APN配置而要先检查UE上下文在网络侧还在不在、状态是否一致。3.2 Service Request时序拆解一次从空闲到激活的完整过程一个典型的Service Request流程从空口LOG看大概是这样的UE发RRC Connection RequestestablishmentCause一般填mo-Data或者mo-Signalling如果是响应寻呼发起的也可能是mt-Access。eNodeB回RRC Connection Setup分配SRB1。UE发RRC Connection Setup Complete里面携带NAS消息Service Request。eNodeB把Service Request封装在S1AP Initial UE Message里发给MME。MME收到后检查UE上下文是否有效向eNodeB发送S1AP Initial Context Setup Request里面携带需要建立的E-RAB列表通常是默认承载的E-RAB以及安全上下文参数。eNodeB配置AS安全向UE下发RRC Connection Reconfiguration里面包含DRB配置。UE回RRC Connection Reconfiguration Complete。eNodeB回S1AP Initial Context Setup Response给MME。此时空口用户面通道建立UE可以正常发送PDCP数据。这个流程的关键在第5步。如果MME发现UE上下文不在了——比如eNodeB侧因为长时间无数据已经释放了UE上下文或者MME侧因为定时器超时把UE上下文删掉了——那么MME就不能直接建上下文而是会走一遍网络侧的Service Request拒绝或者触发重新认证流程。3.3 常被忽视的状态不一致网络侧悄悄释放了UE上下文我实际排查过大量Service Request失败案例发现最普遍的一个问题就是UE认为自己在空闲态但网络侧的UE上下文状态却不一样。举一个真实场景。UE在某个小区做完业务后被释放到空闲态但释放流程只有eNodeB本地执行了没有正确通知MME导致MME认为UE还处于连接态。这时UE收到寻呼并触发Service RequestMME拿旧状态回应eNodeB侧根本没有UE上下文——表现在前台LOG上就是Service Request发出去S1AP Initial Context Setup Request很长时间不下来最后RRC连接被释放UE回到空闲态重试。这种问题排查起来最坑因为空口侧没有任何异常消息RRC建立成功、Service Request发出成功就是等不到回包。遇到这种“消息发出去石沉大海”的情况不要反复重测浪费外场时间直接拉MME侧的信令跟踪对比MME看到的UE状态和eNodeB上报的状态不一致的话就是异常释放流程导致的上下文残留。解决思路也简单让基站或核心网把异常UE上下文清掉或者等MME的移动性定时器超时后重新寻呼。商用网络上这类问题容易出现在切换失败后的释放阶段、S1链路闪断后的恢复阶段。4. 常见问题排查从一条失败消息反推根因4.1 排查方法论四步定位法在外场排一个信令问题我一般按固定套路走不靠猜第一步定位置。先在LOG里找到失败消息本身确认它是哪条消息、哪个网元发的、哪个方向上行还是下行。RRC层的失败还是NAS层的失败直接决定了后续方向。第二步看现象。是收到了显式的拒绝消息还是超时等不到响应是每台终端都失败还是特定终端失败是固定在一个小区失败还是每个小区都失败这几个问题能快速区分网络问题和终端问题。第三步读原因值。NAS拒绝消息里一般带着EMM Cause或ESM Cause这是核心网给终端的“官方解释”优先看这个。常见原因值的含义我放在下面。第四步联动核心网。空口LOG只能看到UE侧行为要确认是MME拒绝还是eNodeB没传上去必须拿S1-MME接口的跟踪数据比如华为U2020、中兴NetNumen、或者独立信令监测平台的Trace来对比。很多外场排查都是卡在“空口侧没看到错误、不知道去哪里找原因”这一步。4.2 Attach失败案例复盘MME原因值背后的链路案例一EMM Cause #11PLMN not allowed现象是UE发起Attach Request后MME回了一条Attach RejectCause值是#11。这个原因值的意思是网络不接受UE所在的PLMN。排查链路先看UE选择的PLMN跟SIM卡签约的PLMN是不是同一张网。外场测试卡经常有签约限制或者卡在写卡的时候只开了某个运营商的MCC/MNC。我当时查了一个“一台终端在所有站点都附着失败”的案例最后把卡拔出来插到另一台普通手机上就能正常入网再对比IMSI开头和PLMN配置确认是测试卡签约数据和目标网络不匹配联系卡商重新开卡解决。如果多台终端都失败那问题在网络侧。检查MME配置的PLMN列表是否包含当前TAC所属的PLMN检查HSS里签约的 subscribed PLMN有些场景是漫游限制。案例二RRC正常但MME侧始终没有Initial UE Message现象是LOG里RRC连接建立成功UE也发了Attach Request但MME后台信令跟踪里什么都查不到。排查链路这基本可以断定问题出在S1接口传输层。检查eNodeB和MME之间的SCTP链路状态通常用eNodeB网管查S1链路状态确认S1接口是否已经建立S1 Setup流程是否完成。如果S1接口正常再检查eNodeB上配置的MME IP、端口和SCTP偶联配置是否有问题。这个案例的教训是信令流程是端到端的空口消息发出去不等于核心网能收到。外场排查不能只看空口LOG一定要有后台联动能力。案例三Attach Accept之后立刻掉网现象是流程走完Attach Accept收到但UE马上释放RRC连接接着重新选择小区甚至报“No suitable cell”。排查链路先看Attach Accept里下发的TAI List确认UE当前所在小区是否包含在TAI List里。如果核心网把TAI List配错了UE会认为当前TA不允许驻留触发重新选网。再看释放原因如果是RRC Connection Release消息里携带的释放原因指示异常那要查eNodeB侧是否在Initial Context Setup阶段配置失败。4.3 Service Request失败案例复盘上下文丢失与寻呼响应案例四下行数据触发寻呼但UE响应寻呼呼叫失败现象是核心网下发寻呼UE收到Paging后发起Service Request但网络迟迟不回Initial Context Setup Request最终UE侧RRC被释放。排查链路这类问题要先区分是核心网主动拒绝还是没收到。空口LOG里Service Request发出去后如果MME侧能看到这条NAS消息说明空口传输正常问题在MME对UE上下文状态的判断。MME下发Paging时如果UE在MME侧显示为已连接ECM-CONNECTED那么MME会认为UE上下文应该在某个eNodeB上从而通过该eNodeB下发寻呼不会做空口寻呼。如果eNodeB侧其实已经释放了上下文寻呼就送不到UE。从UE行为看起来就像“没收到Paging”。这种情况的根因往往是eNodeB的UE上下文释放流程没有正确通知MME或者S1释放失败两边上下文状态不一致。排查方向是检查MME上这个UE的S1AP ID是否还挂在某个已释放的eNodeB上然后做MME侧UE上下文清理。商用网偶尔在eNodeB重启或S1链路闪断后会批量触发这种问题严重时会影响整片区域。案例五Service Request之后一直等不到RRC Connection Reconfiguration现象是Service Request发出成功S1AP Initial Context Setup Request也到了eNodeB但UE就是收不到承载配置消息。排查链路这一步卡在eNodeB侧。常见原因有三个一是无线资源不足eNodeB分配 DRB 失败二是UE和eNodeB在AS层安全模式配置上失败导致后续重配置没法进行三是eNodeB配置的QoS参数与自己实现的承载能力不匹配比如CSFB和VoLTE的QCI配置错误。遇到这个现象建议先看eNodeB告警和无线资源状态再拉eNodeB侧的UE信令跟踪看看是无线侧主动放弃建立还是配置参数错误导致内部失败。一般eNodeB侧都有比较明确的原因值。4.4 容易忽略的非信令因素频段、覆盖与终端能力排查过程中我发现很多信令层看起来正常的失败根因不在信令协议里而在射频和配置层面。一个是频段Band匹配问题。如果终端Band不支持或没开对应Band它根本不会发起Attach或会在Attach后立刻脱网。外场测试要确认测试终端支持的LTE Band列表以及当前小区的Band与终端能力是否匹配。测Band 41/40的时候特别容易踩到终端天线切换导致的掉网问题这种情况信令LOG上往往看不出任何拒绝就是单纯物理层失步。另一个是终端网络能力指示。Attach Request里有UE Network Capability字段里面包含了终端支持的安全算法、加密算法。如果测试终端和网络侧支持的算法差异过大安全模式协商就会失败。有一种很常见的坑外场用了某些定制终端或老旧终端EEA0不加密被网络侧禁用了但终端仍只上报EEA0导致安全模式建立失败。这个问题在LOG上会显示为Security Mode Command反复重传或者直接释放。还有覆盖边缘的随机接入失败。UE发RRC Connection Request之后没有收到RRC Connection Setup多半是PRACH信道覆盖不足或者上行干扰过高。这时不要往核心网想直接看扫频数据、上行干扰指标、以及终端上行发射功率是否到了极限。5. 测试日志抓取与信令分析的实用工具箱5.1 外场LOG抓取设备选型与参数设置外场测试终端一般选支持工程模式的商用机市面上主流方案是高通、海思、MTK芯片的终端。高通方案配合QXDM/QCAT抓LOG最通用能同时解NAS层和AS层而且空口消息齐全。MTK方案也有自己的LOG工具但解析能力相对弱一点。建议项目里至少备两台不同芯片平台的终端防止单平台问题和厂商兼容性问题干扰判断。LOG抓取时重点勾选LTE相关模块RRC、NAS、S1AP终端侧一般没有直接S1AP但工具箱可以关联、PDCP、RLC、MAC、PHY层调度信息。很多测试软件默认不开NAS层导致LOG里面看不到Attach Request内容只看到RRC包排查难度会大很多。有一点要提醒抓LOG要带上时间戳和GPS经纬度不然回来后对现场问题小区都定不了位。外场测试经常是“当时没在意回来看LOG发现异常”没有位置信息基本就只能重测。5.2 快速定位有效信令的过滤技巧拿到一份动辄几万条消息的LOG从头翻是不现实的。我的做法是先用关键字过滤。在Wireshark里如果解的是PCAP格式过滤表达式可用nas-eps直接筛出所有NAS消息然后找Attach Request、Authentication Request、Security Mode Command、Attach Accept、Attach Reject这类关键消息。如果用商用路测软件鼎利、华虎、万绿等一般有信令树形视图按流程分组直接点流程节点看失败位置。实际排查我一般只看三个视图时间线视图按时间把整个测试过程拉出来快速看在哪一秒发生了什么失败。信令列表视图过滤出NAS和RRC层关键消息看消息间的先后顺序。事件列表看测试软件自己判断的异常事件比如掉线、切换失败、建立失败省去自己找的时间。需要强调测试软件判断的失败未必是真失败。比如它会因为终端在短时间内发起多次Attach而报“反复附着”但有可能只是测试脚本正常重启了应用。最终要以信令流程本身的因果顺序为准。5.3 与核心网侧联动的排查方法单靠空口LOG只能定位到“消息发出去没回来”这个层面想要进一步定位是哪个网元吞了消息必须和核心网侧配合。操作上分三步第一步在MME侧开启端到端信令跟踪筛选条件用IMSI或者终端手机号。这样能把这个UE从空口到核心网的完整信令全拉出来不用跨系统对时间戳。第二步对比空口LOG和MME跟踪中同一时间点的消息。比如空口显示UE发了Attach Request但MME侧的Initial UE Message有没有对应记录立刻就能判断是传输问题还是MME处理问题。第三步如果MME侧也没有记录就往上排查SGW、PGW、HSS之间的Diameter消息。不同厂家后台界面不一样但思路一致从UE往核心网逐级对比找到最先消失的那条消息问题就出现在它上下游之间。还有一个技巧是善用信令监测平台DPI探针或者核心网信令面采集。大型项目一般都有独立信令监测系统可以把S1-MME、S6a、S11等接口的信令全部还原。在外场不确定问题归属时我通常会先查监测平台用IMSI拉这个UE最近几小时的信令全貌比自己跑后台快得多。5.4 外场测试中的关键参数记录一个容易被忽视的问题是外场测试完发现异常却缺少关键参数记录导致事后无法复现。我的建议是每次测完至少记录以下几个维度测试时间点精确到秒测试终端型号、SIM卡ICCID/IMSI、终端软件版本所在地点、小区CGI、Band、频点测试业务类型FTP下载、视频、VoLTE语音RSRP、SINR、TA时间提前量等基础RF指标这些数据配合信令LOG能在排查时快速排除变量。比如同一小区两台终端一个Attach成功一个失败那基本就是终端问题或者SIM卡问题不用往基站上折腾。我还见过一个项目反复出现Service Request失败但就是定位不到原因后来发现是测试终端处于省电模式应用层数据被推迟触发看起来像是信令流程卡死。这种问题如果没有业务层数据配合单看信令很容易误判。6. 从一个功能点延伸到系统级思维LTE信令分析的意义6.1 从Attach到5G为什么你会学得越来越轻松掌握LTE的Attach和Service Request流程对后续学习5G信令有直接帮助。5G的注册流程、Service Request流程在整体思路上跟LTE高度相似只是把MME拆成了AMF/SMF/UPF把 EPS Bearer 变成了 QoS Flow消息名称换了但“先认证后建承载”的核心逻辑没变。在网络热词里看到很多人关注5G信令流程详解、VoNR信令流程其实这些内容追根溯源都是建立在LTE时代这套信令分析基本功上的。我在项目里带人做VoNR问题分析时经常让他们先把LTE/VoLTE的端到端流程画一遍能把LTE画明白的人切到5G无非是换了一套参数和节点名思路完全相通。6.2 把信令当成系统级调试工具而不是死记硬背的协议还有一种心态要扭转信令分析不是背消息不是把几十条流程记下来就行。它是你观察无线通信系统内部状态的一台“显微镜”。很多时候用户上报的“上网慢”“掉线”“电话不通”映射到系统里都是某条信令流程失败或者时延过大。比如网页打不开可能是Service Request之后DRB建立时间太长也可能是Attach后默认承载一直没有真正激活——这两种情况在用户侧表现一样但排查方向完全不同。我建议你在日常测试中养成的习惯是每处理完一个问题就在自己的问题库里记一条格式是“现象—信令表现—根因—解决方案—验证结果”。时间长了你会发现自己能“闻”到问题。看到某条消息迟迟不出现或者某个原因值反复出现脑子里立刻能调出几个候选根因排查速度会快非常多。这也算是我个人在LTE外场摸爬滚打多年的一点体会。信令是枯燥的但每一屏LOG背后的故事都不同。拿到一份失败日志别急着下结论先把消息排好顺序把流程位置定住让信令自己告诉你它在哪里断了答案往往比你想象的要近。