简介面向LTE/4G网络工程师与通信专业学习者的一份信令流程梳理文档以LTE系统为背景系统讲解4G信令全流程。内容先介绍协议层与基本概念包括控制面与用户面、NAS/RRC/PDCP/RLC/MAC/PHY各层职责、空闲态与连接态、网络标识与承载概念为理解信令交互建立基础随后按章节展开开机附着、随机接入、Service Request、寻呼、切换及CSFB等主要信令流程并配有分层目录便于按需查阅。资料包共1个docx文档压缩包体量约1.83MB适合作为从入门到进阶的信令流程学习笔记也可作为日常排错与备考复习的参考速查。该文档已有1935人学习下载内容组织清晰、覆盖完整便于快速建立4G信令全景认知。1. 凌晨三点的寻呼投诉为什么要翻一遍4G信令凌晨两点半被一个“有信号但被叫无响应”的投诉叫起来LTE指标绿得发亮RSRP、SINR全都正常可就是打不进去电话。RF参数换了一圈没用最后同事翻了一条S1AP的Paging消息才发现跟踪区更新流程里终端没走到最后一步MME压根没下发寻呼。这类问题不看空口指标只能靠信令定位。4G信令是终端、基站、核心网之间控制面消息的完整链条从附着的第一次握手到去附着后的资源释放每一个动作都有对应的消息来回。本文把这条链条从头到尾拆开讲清楚适合网优、核心网、测试人员以及刚转信令分析想快速上手的开发者。2. 抓包位置与协议栈空口、S1口分别能看到4G信令的哪一层很多人拿到一份LTE信令log第一反应是搜“Attach”关键字却不知道Attach这条消息背后叠了三层协议抓包位置不同、看到的内容也不同。这一章先把协议栈和抓包位置对齐再落几条能直接抄走的抓包命令。2.1 三个抓包位置与看到的消息范围LTE信令的中文翻译容易误导人好多人以为“信令”特指某一个接口的消息。实际上一次4G通话或上网行为会同时触发空口、S1接口和核心网内部的多个流程。按抓包位置划分常见做法是分三档第一档是空口也就是终端和基站之间的Uu口。这里能看到RRC层的全部消息包括RRC Connection Setup、RRC Connection Reconfiguration还有NAS消息。注意NAS消息在空口里是“透传”的RRC只是把它当成一个信息元素包在payload里解RRC时Wireshark或前台工具能顺带解出来。空口抓包一般用终端侧log工具、扫频仪或者商用路测工具特点是基站侧的调度细节看得最清楚SINR、MCS、PRB分配都在同一份log里。第二档是S1-MME口也就是基站到MME的接口。这一层既能看到S1AP消息也能看到透传的NAS消息。因为S1AP是基站和MME之间对话的语言所以牵扯到核心网的流程比如Attach、TAU、Service Request、Handover在这个口上都能找到完整的触发和响应。S1口抓包常用交换机镜像口把基站侧的上行流量镜像出来用Wireshark直接解S1AP。第三档是核心网内部的N11/NG接口之类这一般是核心网开发或端到端联调才需要日常投诉定位很少用。三档抓包范围对比如下抓包位置可见协议典型使用场景空口 UuRRC NAS透传无线侧弱覆盖、干扰、调度问题S1-MMES1AP NAS透传Attach、TAU、寻呼、切换的全流程分析核心网内部接口DIAMETER / S6a / S11 等鉴权、会话管理、签约数据问题如果你只是想梳理“一次注册流程”S1-MME口的log是最好的起点它覆盖了从开机附着到去附着的整个NAS层生命线。2.2 用Wireshark过滤一份LTE信令最少要会这四条过滤语法Wireshark解LTE信令不需要额外装插件它的协议解析器已经内置了RRC、NAS-EPS和S1AP。但刚打开一个pcap时pcap里往往混着GTP-U数据面流量、DNS查询、甚至背景流量。我一般会先用协议名把范围收紧# 只看S1AP相关消息 s1ap # 只看NAS层消息 nas-eps # NAS S1AP 一起看 s1ap || nas-eps # 空口抓包只看RRC rrc第一条s1ap是协议名Wireshark的显示过滤器直接按协议名过滤凡是包含S1AP层的帧都会留下。nas-eps同理过滤所有含NAS消息的帧注意这里不是只看NAS消息而是“包含NAS层”。第四条rrc在空口pcap里最常见的场景是过滤出所有RRC消息。# 只看某个IMSI的初始UE消息 s1ap.InitialUEMessage nas-eps.emm.imsi 460001234567890这条是查单个用户的第一利器。s1ap.InitialUEMessage是S1AP协议里的一个信元名Wireshark里有全部S1AP信元的显示字段nas-eps.emm.imsi需要pcap里恰好有明文IMSI很多商用终端在附着时是先发IMEI或GUTI这时IMSI字段会是空的。如果没解出IMSI可以用终端分配的临时ID过滤后面第4章的tshark命令里会给出替代方案。2.3 用tshark把消息名批量化地列出来Wireshark的图形界面适合单帧点开看但一份信令log动辄几十万帧我用的方法是先把消息轮廓“拉平”成一张表再定位异常点。tshark做这个事最快tshark -r lte_s1.pcap -Y s1ap || nas-eps -T fields \ -e frame.number -e frame.time \ -e s1ap.ProcedureCode -e s1ap.ProcedureCode.name \ -e nas_eps.msg_type -e nas_eps.msg_type.name \ -e s1ap.UEAPIIES -e nas_eps.emm.guti说明一下这些字段s1ap.ProcedureCode是S1AP过程码的数值s1ap.ProcedureCode.name是它对应的可读名字比如“initialContextSetup”“handoverPreparation”nas_eps.msg_type是NAS消息类型编号“0x41”代表Attach Requestnas_eps.msg_type.name直接显示消息名字省得一个个查号。nas_eps.emm.guti是GUTI临时标识当pcap里没有明文IMSI时用GUTI区分终端是最稳的同一终端的GUTI在一条流程里通常不变。实际跑出来的表会像这样帧号时间S1AP过程名NAS消息名GUTI135612:01:03.221initialUEMessageAttach request0410-121234135812:01:03.307downlinkNASTransportIdentity request0410-121234这张表一列出来整个流程的骨架就清楚了。新手最容易踩的坑是只盯NAS消息、丢了S1AP消息结果看不到基站和MME之间的动作节点。两条腿走路才是对的。3. 读懂4G信令的消息信封RRC、NAS与S1AP结构速读打开一条Attach Request消息Wireshark里能看到RRC层、S1AP层、NAS层层层嵌套。很多人一头扎进去看内容却不知道这三层各自负责什么边界。这一章把三层的职责拆开每层只讲最关键的字段读完就能看懂80%的消息。3.1 RRC消息终端和基站之间的小区级对话RRCRadio Resource Control是终端和基站之间控制面信令负责连接建立、重配置、释放、测量报告这些无线资源管控动作。RRC消息种类不算多日常信令分析里最常碰到的几张面孔如下RRCConnectionSetupRequest终端主动请求建立RRC连接带一个establishmentCause字段可能是mo-Signalling发信令、mo-Data发数据或mt-Access被叫寻呼响应。RRCConnectionSetup基站给终端分配的资源配置里面是完整的SRB1配置包含逻辑信道、MAC层配置、物理层配置。很多无线问题在setup消息里能看出端倪比如分配的信道质量很差往往是小区资源接近耗尽。RRCConnectionReconfiguration基站修改终端的无线配置切换流程中这条消息最关键里面带有目标小区ID和测量配置。RRCConnectionRelease基站释放RRC连接releaseCause常见的有loadBalancingTAURequired这也是后面避坑章要讲的一个触发点。RRC信令有个特性它只在空口范围内有意义不会上送到MME。所以S1接口的pcap里看不到RRC只有在空口抓包里能看到。理解这一点就不会拿着S1口的log满世界找RRC了。3.2 NAS消息里的EMM与ESM终端与核心网“真正在聊什么”NASNon-Access Stratum是终端和MME之间的对话RRC和S1AP都是“传话人”把NAS消息原封不动地打包透传。NAS分两个子层EMMEPS Mobility Management管移动性ESMEPS Session Management管会话和承载。EMM层的核心消息编号开头有规律0x41是Attach Request0x42是Attach Accept0x43是Attach Complete0x44是Attach Reject0x45/0x46是Detach0x47/0x48是Tracking Area Update Request/Accept0x49/0x4A是Service Request/Response。记住了这几个编号翻log时基本不用查表。ESM层消息常见的是0xD1 PDN Connectivity Request和0xD2 PDN Connectivity Accept主要管默认承载的建立。EMM消息里必看的字段有三个字段名位置含义EPS attach typeAttach Request可选的值有EPS attach、combined attach、emergency attach区分纯LTE注册还是需要同时注册CS域GUTI / IMSIAttach Request终端身份attach类型和身份一起决定了后续走Identity流程还是直接鉴权TAI listAttach Accept 和 TAU AcceptMME分配的跟踪区列表决定了终端在哪些小区移动不需要发起TAUESM层里重点看EPS bearer context status和QoS。一个常见误读是把“Default bearer”当成网络侧建立的实际上默认承载是终端在PDN Connectivity Request里主动请求的MME只是接受或拒绝。这个归属关系搞错了排查“有信号但不能上网”时会绕远路。3.3 S1AP把基站和MME连起来ProcedureCode决定消息功能S1AP是S1-MME接口上的协议基于SCTP承载消息结构比RRC/NAS更像“信封”。每条S1AP消息都有两个核心标识ProcedureCode过程码和MessageType消息类型。MessageType分三类initiating message发起方发出、successful outcome成功响应、unsuccessful outcome失败响应组合起来就构成了一次完整的S1AP过程。实际工作中最常用的S1AP过程就几个InitialUEMessage基站向MME转发终端的NAS消息、InitialContextSetupMME请求基站建立终端上下文和承载、UEContextRelease释放终端上下文、PagingMME寻呼基站、HandoverPreparation切换准备阶段系列消息。S1AP消息虽然复杂但我建议不要一开始就去死记字段。先学会看ProcedureCode.nameWireshark已经把它翻译成人话了。真正要训练的是“配对”概念S1AP的每个过程都有请求和响应如果只看到InitialContextSetupRequest却没有InitialContextSetupResponse那就是消息丢了或流程中断这本身就是一个排查方向。# 列出所有InitialContextSetup过程的响应码 tshark -r lte_s1.pcap -Y s1ap.ProcedureCode 14 -T fields \ -e frame.number -e s1ap.ProcedureCode.name -e s1ap.MessageType过程码14就是InitialContextSetup。s1ap.MessageType字段取值有0initiating、1successful outcome、2unsuccessful outcome一眼就能看出哪些帧是请求、哪些是响应、哪些是失败。这个技巧对第5章讲到的“有请求无响应”类问题非常有用。4. 把一次Attach跑通从RRC Connection Request到默认承载建立Attach是终端开机后的第一个大流程也是信令分析入门绕不开的必修课。这一章不展开所有细节只梳理主干RRC连接建立、NAS附着请求、鉴权与安全、上下文建立、默认承载激活五个环节走完终端才算真正入了网。4.1 初始消息到RRC Setup第一个信令闭环终端开机后第一步是找小区完成驻留之后才会触发Attach。在空口上你看到的第一个信令动作通常是RRC Connection RequestestablishmentCause大概率是“mo-Signalling”因为附着本身就是一条信令流程。正常时序是终端发RRCConnectionRequest请求建立RRC连接。基站回RRCConnectionSetup分配SRB1资源和初始配置。终端回RRCConnectionSetupComplete这条消息里带着NAS Attach RequestWireshark里能看到RRC层嵌套着NAS层。基站收到RRCConnectionSetupComplete后马上在S1口发InitialUEMessage把NAS Attach Request原封不动转发给MME。这个过程有两条判断要点第一在S1口log里看不到前三步RRC消息只能看到第4步InitialUEMessage这是正常现象第二InitialUEMessage里除了有NAS消息还有一个S1AP的RANAP UE ID字段是基站给这个终端在S1口上的临时编号后面同一终端的S1AP消息都带它。如果log里出现了RRC Connection Request却没有RRCConnectionSetup说明基站侧资源分配失败。如果出现了RRCConnectionSetup却没有RRCConnectionSetupComplete那是空口丢包多半是下行覆盖差或终端异常。4.2 鉴权、安全模式与Identity别跳过这些“安全的仪式”Attach Request上传后MME会先判断终端身份。如果不认识这个终端没有有效的GUTI上下文MME会下发IdentityRequest终端回IdentityResponse把IMSI报上去。这是最常见的一个环节也是新手最容易漏看的地方——如果你在log里看到了Attach Request却没找到后续流程先去找Identity。身份确认后是鉴权MME向终端发Authentication Request包含RAND和AUTN参数终端验证网络侧的AUTN通过后回Authentication Response携带一个RES参数。这里有个坑如果终端回了AuthenticationFailure原因通常是AUThReject反映SIM卡和HLR的鉴权数据不一致比如卡在别的设备上被更新过。鉴权通过后是Security Mode Command和Security Mode Complete。这两条消息虽然没有信令分析常用的“业务”字段但是必须出现的。它们代表了NAS和AS两层的安全上下文生效时间点。从Security Mode Complete之后的消息在空口里看已经被加密但Wireshark在字段解析上仍然能给出消息类型在S1口上看到的是明文的NAS消息S1口不加密NAS。一条实战经验SecurityModeCommand发出去了但迟迟没有SecurityModeComplete回来优先怀疑终端侧解密失败常见于运营商开了一些兼容性不太好的加密算法组合可以尝试关掉EEA2、只保留EEA0/EEA1来验证。4.3 初始上下文建立与默认承载激活Attach Accept里的关键参数鉴权加密完成后MME会向基站发送InitialContextSetupRequest里面带了两个重要信息一是终端的NAS上下文二是需要建立的承载列表。这条消息意味着核心网已经认可这个终端让基站在空口上给它建数据通道。在NAS层面MME同时下发Attach Accept里面包含了终端最关键的几个签约参数EPS attach result取值为“EPS attached”说明附着成功。TAI list跟踪区列表终端在这个列表覆盖的小区移动不需要触发TAU。ESM message container里面是PDN Connectivity Accept包含默认承载的APN、QoS参数。GUTIMME分配的新临时标识终端后续发起信令时会优先用GUTI而不是IMSI。基站收到InitialContextSetupRequest后会先向终端下发RRC Connection Reconfiguration配置DRB数据无线承载这一步完成后终端回Reconfiguration Complete基站再向MME回InitialContextSetupResponse。最后一步是终端发Attach Complete通过基站透传下行是UplinkNASTransport上行是DownlinkNASTransport送到MME。收到Attach Complete整个Attach流程才真正走完。新手在判断附着成功时习惯只盯Attach Accept我在实际排查里发现有一种情况是Attach Accept已经下发、但InitialContextSetup失败结果终端虽然显示已注册就是上不了网。所以判断标准应该是Attach Accept InitialContextSetupResponse Attach Complete三条都出现才算完整成功。4.4 用tshark按IMSI提取某台终端的完整Attach消息序列前面都是单条消息分析现在落到实操怎么从一份大的pcap里快速抽出一个终端的整条Attach流程。常见做法是先找GUTI再用GUTI过滤。# 步骤1列出所有Attach Request相关的帧和GUTI tshark -r lte_s1.pcap -Y nas_eps.msg_type 0x41 -T fields \ -e frame.number -e nas_eps.emm.guti -e nas_eps.emm.imsi # 步骤2假设查到GUTI为0410-121234提取该终端的全部信令 tshark -r lte_s1.pcap -Y nas_eps.emm.guti 0410-121234 || s1ap.UEAPIIES contains 0410-121234 \ -T fields -e frame.number -e s1ap.ProcedureCode.name -e nas_eps.msg_type.name第一步是“在log里找入口”。nas_eps.msg_type 0x41过滤Attach Request帧输出GUTI字段因为大多数终端初次附着时不会携带明文IMSI。第二步用GUTI过滤全部信令消息同时过滤S1AP层里的UE ID字段保证不把同一条GUTI在其他终端上复用的情况漏掉。这里参数UEAPIIES是Wireshark里的S1AP终端信息元素用contains做子串匹配能捕获GUTI出现在任何信元里的场景。现实中还有一个坑终端在Attach流程成功后MME会重新分配GUTI所以同一个终端在“Attach Request”和“Attach Complete”之后的GUTI可能不同。遇到这种情况先用时间线手工对齐两条GUTI再分别过滤提取。5. 4G信令排查的四个高频坑从寻呼失败到TAU风暴这一章是我做信令分析这几年积攒的踩坑记录全部来自真实场景。每一条都是“现象→原因→解决”的固定结构可以直接对照。5.1 现象一小时内同一个位置区出现上千条TAU Request形成信令风暴原因TAU Request带着大量的网络侧异常行为最典型的是“周期性TAU定时器过短 TAC配置边界模糊”。当终端在TAI列表边缘反复移动时基站和MME对终端的TA归属判断不一致终端频繁发起TAU。另一个高频原因是TAU Request里带Active Flag0的请求被MME拒绝终端反复重发。解决先在pcap里统计TAU Request的源GUTI和所在小区ID找出最集中的几台终端和一个区域。如果是孤立的几十台终端查这些终端是否集中在某个TA边界如果全网量都在涨检查MME下发的TAI list长度和周期性TAU timer参数。TAU timer配置在MME上常见值是5分钟到30分钟调过小必出问题。# 统计TAU Request最多的前20个GUTI tshark -r lte_s1.pcap -Y nas_eps.msg_type 0x48 -T fields -e nas_eps.emm.guti | sort | uniq -c | sort -nr | head -20nas_eps.msg_type 0x48是Tracking Area Update Request的编号。这条命令在几十万帧的pcap里跑几秒就能得到嫌疑名单比在界面里一格一格翻快得多。5.2 现象Paging消息丢了但RRC层却看到了附近小区的寻呼下发原因查寻呼问题只看RRC会翻车。RRC的Paging消息是基站实际空口下发的但寻呼的源头是MME。MME在S1口发Paging给基站基站收到后才在空口广播RRC Paging。如果RRC Paging空口有、S1口Paging也有但明明在服务区内的终端没响应那是空口寻呼时机或DRX周期问题如果S1口Paging压根没下来那是MME的跟踪区判断认为终端不在这个基站底下跟空口一点关系都没有。解决先分两个节点看。S1口过滤s1ap.Paging空口过滤rrc.Paging两个都看完了再下结论。S1口有Paging、空口没有是基站下行丢消息或寻呼拥塞S1口没有Paging、空口却有大概率是MME跟踪区数据库有问题或者终端状态在MME侧被标记成空闲态但不该满足寻呼条件。5.3 现象Service Request反复失败同一台终端不断在“有数据要传”和“回落空闲”之间振荡原因Service Request的触发目的是从空闲态切换到连接态终端发完Service Request后MME会触发S1AP的InitialContextSetup。如果终端在非激活态下立即又发了上行数据MME会认为上下文还没建立完成直接回Service Reject。这种情况最常见的根因是终端的APP层重传机制过于激进数据包间隔短于信令建立时间导致请求和拒绝形成死循环。解决在log里看Service Request失败后的下一个动作。如果是终端立即又重发Service Request那基本是APP重传太快的问题。可以统计一下两次Service Request的时间间隔低于100毫秒的几乎全是这种。终端侧优化方向是把应用层的连接失败退避时间调大给信令流程留足时间。5.4 现象Attach Reject原因值是“no suitable cells in tracking area”但现场信号满格原因这个错误码和无线覆盖没关系。no suitable cells in tracking area意味着MME认为终端所在位置不在它注册的TA列表范围内常见场景是终端驻留在MME禁止的CSPB回落小区或者配置了不允许的PLMN。信号满格只是空口功率强不代表核心网许可你在这个区域注册。解决先看Attach Request里的TAI、PLMN和终端上报的ECGI再对照MME侧的TA白名单。如果现场有两个网络并存比如4G/5G共站可能是终端在NSA组网下上报了错误的ECGI可以先让终端关掉5G重新触发附着验证。这类问题更容易驻留在无线侧排查但根因经常在核心网配置。6. 让信令分析“快起来”五条必查线索与一份终端信令存档格式最后一章讲两个我长期用下来的习惯。一是面对一堆信令时怎么快速定位“问题消息”二是怎么处理那些原始log让它们能支撑几个月后的追溯。6.1 五条必查线索先定流程再定失败点我的固定套路是这样先定流程阶段看第一条NA S消息是Attach Request、TAU Request还是Service Request确定用户在干什么。找失败消息全log搜NAS层的Reject消息以及S1AP层MessageType 2unsuccessful outcome的帧。对上下文建立如果是成功流程确认InitialContextSetup Request / Response是否成对出现这一条是“假注册、真断网”的头号元凶。看释放原因UEContextRelease Request里的Cause字段“radioNetwork”还是“nas”开头直接区分无线侧和核心网侧。拉出时间差同一条NAS消息在S1口和空口的时间差超过1秒就要看是不是空口传输有问题。6.2 一份自用的信令存档格式与对比法原始pcap文件因为涉及终端标识和用户位置不适合长期保存。我习惯把每个case筛出来的关键信令转成CSV文本按“日期-场景-定位结论”命名存档。文件名格式固定为20250110_乒乓球室_寻呼失败_TAI不匹配.csv里面的字段就是2.3节tshark那张表再加一列备注栏。这个方法带来的最大好处是可以做“对比法”排查同一个地点、同一型号终端、同一个场景把好的一周前信的log和今天坏的信令并排比较看GUTI变化、TAI分配、PDN连接参数哪个环节不同问题通常就在那个差异里。我自己现在的习惯是接到新投诉先把历史存档拉出来扫一眼。有一次客户的“突然无法上网”问题就是靠对比发现上个月同一位置TAU Accept里的TAI list有多个条目而这次只剩了一个再往下查发现是MME TA删配导致的。信号的“玄学”问题十有八九是信令里的一个字段变了而已。这套信令分析的思路核心就是两层看得懂协议结构抓得住关键差异。希望帮到你。本文还有配套的精品资源点击获取