拓冰网站定制 
简介面向LTE/4G网络学习与日常优化的一份信令流程梳理材料重点解决协议层级多、信令流程分散带来的理解门槛。文档先建立协议层与概念基础依次拆解NAS、RRC、PDCP、RLC、MAC、PHY等协议职责并说明控制面/用户面、空闲态/连接态、网络标识及承载概念随后按照实际网络行为主线详细展开开机附着、随机接入、Service Request、寻呼、切换与CSFB等核心流程每类流程均交代触发条件、主要信令消息与状态变化便于对照现网消息抓取和参数理解形成从原理到流程的完整认知。压缩包内为单个docx文档大小1.83MB目录按章节渐进、条理清晰既可以作为通信专业学生对LTE信令体系的入门导图也适合网络优化人员在日常排障时按图索骥、快速定位流程节点。目前已有1935人浏览/学习。1. 4G信令全流程一条投诉电话背后的信令链路远比满格信号重要我有一次处理用户投诉「手机显示满格信号但打开网页就是转圈」现场蹲了一天RF报告没有任何弱覆盖迹象。最后调出核心网跟踪发现Attach流程根本没走到默认承载激活MME回的是Attach Rejectcause #15。满格只是下行接收好信令链路没完成业务自然起不来。这就是4G信令全流程的价值从UE开机、小区选择、附着、TAU到业务请求与切换一套信令交互能把用户感知问题精确锁到一个网元或一条配置上。这篇笔记适合网优、核心网测试和刚转信令分析的人目标不是背协议栈而是拿着跟踪就能看懂信令在说什么、卡在哪。2. 先把信令面拆开协议栈分层、网元接口与消息清单长什么样2.1 控制面不是一根线Uu口、S1-MME口与S11口各传递什么4G信令并不只在网元间单向传递。一次附着同时穿过多条接口每条接口上跑的协议不同、职责也不同。UE和eNodeB之间跑的Uu口信令是RRCRadio Resource Control它负责建立、重配置和释放空口资源UE和MME之间的NASNon-Access Stratum消息则承载在RRC之上由eNodeB透明转发不做解析。eNodeB和MME之间是S1-MME接口跑S1AP协议负责把NAS消息封装成Initial UE Message、Uplink/Downlink NAS Transport这类信令并管理UE在基站侧的上下文。MME往核心网侧走还有S11接口的GTP-C信令链路用于EPS承载的创建、修改和删除。这三层链路在Wireshark里同一条抓包里经常交叠出现。我在分析时有个习惯先把抓包按接口分开理解。空口抓包往往包含RRC和NAS两层但如果没有同时抓S1-MME就只能看到eNodeB的出入口看不到MME侧的响应逻辑反过来只抓核心网侧S1-MME或S11口可以看清MME和SGW的行为但空口重配是否下发又要靠路测日志补全。所以做全流程信令分析最理想的是把Uu口和S1-MME口时间对齐一起看否则很容易把「空口已经下发重配核心网还没收到响应」这类问题误判成对端网元不响应。2.2 NAS消息是业务意图RRC、S1AP是搬运通道双层结构怎么区分很多新手看信令最大的障碍是分不清NAS和RRC/S1AP。NAS消息表达的是UE和MME之间的业务意图比如我要附着、我要做TAU、我要请求服务RRC消息表达的则是UE和eNodeB之间空口资源的分配比如我要建立连接、我配置了哪些无线承载。S1AP消息又是eNodeB和MME之间的交换行为对应物比如初始UE上下文建立、UE上下文释放请求。同一个流程里NAS消息会被封装在RRC和S1AP消息内部形成一层套一层的结构。举个例子UE发起附着时先看到RRC Connection Request、RRC Connection Setup随后UE发的RRC Connection Setup Complete里就携带了Attach Request这条NAS消息这条NAS消息到了eNodeB再被封装进S1AP的Initial UE Message里送给MME。如果分析时只在过滤器里输入nas_eps是看不到RRC层在发声的但如果只盯RRC又看不出用户到底是附着还是TAU。我一般会在Wireshark里同时保留rrc || s1ap || nas_eps用Time列做时间轴按消息先后关系还原整个流程比单看某一层容易定位得多。2.3 一张表看清常用信令消息的触发场景与关键参数消息层消息名称触发场景关键字段NAS(EMM)Attach RequestUE开机、从无服务到有服务IMSI或old GUTI、attach类型、T3410相关定时器NAS(EMM)Attach AcceptMME接受附着T3412周期TAU定时器、T3402、EPS附着结果NAS(EMM)TAU Request跨TA边界、周期TAUold GUTI、last visited TAINAS(ESM)PDN Connectivity Request附着时建立默认承载APN、PDN type、用户面协议参数NAS(ESM)Activate Default EPS Bearer Context RequestMME准备激活默认承载分配的IP地址、QCI、APN-AMBRRRCRRC Connection Setup Complete空口连接建立完成携带初始NAS消息RRCRRC Connection ReconfigurationeNodeB下发专用配置DRB配置、测量配置、NAS透传S1APInitial UE MessageeNodeB上送NAS消息给MMEeNB UE S1AP ID、NAS消息载荷S1APUE Context Release CommandMME释放UE上下文S1AP Cause、释放原因表格里最容易被忽略的是ESM消息。很多人只要看到Attach Accept就认为成功但真正决定「能不能上网」的是后面那条Activate Default EPS Bearer Context Request。它带了分配的IP地址和QCIQCI决定用户面数据走哪条承载、优先级和丢包预算。如果Attach Accept正常但这条ESM消息没出来大概率是PDN Connectivity Request里APN解析出问题或PGW侧会话建立失败。3. 从开机到可用的完整流程拆解附着、TAU、业务请求与切换3.1 Attach流程逐条递进从RRC Connection Setup到默认承载激活Attach是4G信令里最完整、也最能锻炼读包能力的流程。从UE开机到能上网通常经过十几步信令交互。我用一张简化的消息序列来描述序号传输方向消息作用与关键信息1UE → eNodeBRRC Connection Request发起空口连接携带初始UE标识2eNodeB → UERRC Connection Setup分配SRB1资源配置信令承载3UE → eNodeBRRC Connection Setup Complete携带NAS Attach Request含IMSI或old GUTI4eNodeB → MMES1AP Initial UE Message透传Attach Request到MME5MME → HSSDiameter AIR/UIA鉴权矢量请求与用户订阅数据获取6MME → UENAS Authentication Request下发随机数和鉴权令牌7UE → MMENAS Authentication Response回传鉴权应答验证网络合法性8MME → UENAS Security Mode Command启动完整性保护和加密算法协商9UE → MMENAS Security Mode Complete确认安全上下文激活10UE → MMENAS PDN Connectivity RequestESM层请求建立默认PDN连接携带APN11MME → SGW/PGWGTP-C Create Session Request/Response核心网侧建立默认承载12MME → UENAS Attach Accept携带GUTI、T3412、T3402、EPS附着结果13UE → MMENAS Attach Complete确认附着完成T3410停止14MME → eNodeBS1AP Initial Context Setup Request请求eNodeB建立UE上下文与DRB15eNodeB → UERRC Connection Reconfiguration下发DRB配置与测量配置16UE → eNodeBRRC Connection Reconfiguration Complete空口承载建立完成17eNodeB → MMES1AP Initial Context Setup Response通知MME上下文建立成功第12步Attach Accept里面的T3412就是周期TAU定时器默认值常见的是30分钟到60分钟运营商可按需求调整T3402则是附着或TAU被拒绝之后UE需要等待多久才能再发起流程。很多「手机莫名其妙从4G掉到无法注册」的投诉追根究底就是T3402太长或太短。第14步到第17步容易和Attach流程混淆注意上下文建立完成之后用户面数据才开始真正能跑。若遇到第4步Initial UE Message之后MME不回鉴权请求多半要查HSS侧是否能查到USIM信息若在第10步之后卡住则优先看APN设置和PGW可达性。3.2 TAU流程里的「为什么换小区会卡」TAC边界与定时器TAU全称是Tracking Area UpdateUE发现当前所在的跟踪区不在注册的TA List里就会发起请求。触发场景有三类跨TA边界、周期TAU由T3412控制、以及从旧小区回到可注册区域。TAU流程在信令里最常见的问题是「UE发TAU Request但MME回了TAU Rejectcause #12或#13」。#12表示该跟踪区不被允许#13表示该跟踪区不允许漫游。处理思路完全不同#12是TA规划问题通常需要核对运营商TA List配置和MME Pool边界#13则涉及漫游白名单和运营商间协议。周期TAU也是一类高发问题。如果T3412设置过短UE频繁发起TAU会显著增加MME信令负荷小区掉线率和呼叫建立时延都会被拉高如果T3412设置过长MME和SGW容易认为UE不可达导致下行寻呼失败。通常做法是在MME上按「寻呼响应率」反向调参寻呼成功率低于阈值时适当缩短T3412否则调长。我在分析抓包时会特别对比TAU Request里的last visited TAI和当前小区广播的TAC——两者一致但MME还回TAU Accept并重新分配GUTI说明是老GUTI关联不上旧MME变成了「类似初始附着的TAU」这是MME Pool过大导致上下文丢失的典型信号。3.3 Service Request和S1释放小流量状态下的信令节省机制UE完成附着后并不会一直占用空口资源。当UE处于RRC Connected态且无数据时eNodeB会通过S1AP UE Context Release来释放空口连接但保留核心网PDN连接这叫RRC Idle态。之后一旦UE有上行数据或收到寻呼就通过Service Request流程恢复连接。Service Request和Attach最大的区别是它不重建PDN连接只是空口和用户面承载恢复所以信令步骤明显更少。序号方向消息作用1UE → eNodeBRRC Connection Request/Setup空口恢复SRB2UE → MMENAS Service Request携带P-TMSI或GUTI、请求的业务类型3MME → eNodeBS1AP Initial Context Setup Request请求恢复建立UE上下文与DRB4eNodeB → UERRC Connection Reconfiguration恢复DRB配置5eNodeB → MMES1AP Initial Context Setup Response用户面恢复成功Service Request最容易遇到的坑是UE在空口侧连发多次请求但核心网没有响应。原因通常有两个一是MME侧的UE上下文已被释放比如T3412周期TAU超时核心网认为UE失联需要先做TAU再发起Service Request二是eNodeB配置的上行非连续接收参数和MME的寻呼参数不匹配导致下行寻呼消息发给了错误的小区。信令分析里有一种典型场景手机上显示4G但有下行流量时页面转圈打开S1-MME跟踪发现MME发出Paging后空口侧完全没有RRC连接建立请求这时基本可以断定是寻呼消息没有正确下发到UE驻留小区。3.4 切换流程的分类X2切换和S1切换的判断路口切换按接口分为X2切换和S1切换。X2切换是源eNodeB和目标eNodeB之间通过X2接口直接协商MME只负责事后做Path SwitchS1切换则由MME全程参与适用于跨MME或X2不可用的场景。从信令上判断切换类型很直观X2切换里源eNodeB直接发Handover Request给目标eNodeB随后UE收到RRC Connection Reconfiguration里面带新的C-RNTI和无线资源配置目标eNodeB直接发送SN Status Transfer给核心网最后通过Path Switch Request通知MME更新承载路径。S1切换则在源eNodeB处多了一条S1AP Handover RequiredMME收到后向目标eNodeB发Handover Request完成资源准备后再下发Handover Command。两者对应的排查思路不同X2切换失败优先查X2接口链路、目标小区的负荷准入策略和邻区关系S1切换失败则要查MME到目标eNodeB的SCTP链路、目标eNodeB覆盖异常或MME配置的切换白名单。分析切换信令时还有一个容易被忽略的点RRC Connection Reconfiguration里携带的measConfig如果切换目标小区频点不在测量配置里UE根本不会上报测量报告再完美的邻区关系也白搭。4. 抓包与解码怎么让一张信令跟踪数据「开口说话」4.1 常见采集方式网管侧跟踪、路测软件与核心网信令监测屏的取数差异市面上能拿到信令数据的途径不少但出问题也各有各的难处。网管侧跟踪比如基站OMC的UE信令跟踪可以拿到Uu口RRC和部分NAS适合做单用户问题回溯路测软件一般是路测小哥手里那套工具和测试终端配合可以拿到空口AS和NAS解码但需要厂家授权解密而且如果用的不是内置基带上报某些加密NAS消息会显示成密文核心网信令监测屏或抓包工具挂S1-MME能拿到S1AP和NAS明文但看不到空口Radio Resource配置细节。我在实际项目中常做的做法是「双端对齐」Uu口侧用路测软件的logS1-MME侧用核心网跟踪或分流探针抓包。两边分别导出原始日志再用同一时刻的GUTI或IMEI做关联。否则只取一端经常会遇到「RRC层显示成功、S1MME没有对应消息」或反之非常容易出现误判。如果你是在实验室搭环境直接用模拟基站加一台普通抓包电脑就能拿到较理想的双端数据完全不需要上商用网。4.2 用tshark和Python在离线抓包里统计信令时序拿到pcap后第一步是把信令按时间顺序过滤出来。我习惯用Wireshark自带的tshark做批处理把NAS、S1AP和RRC消息导成CSV再交给Python做聚合统计。下面这个命令适合在拿到离线抓包后快速评估整段信令的时间分布tshark -r attach.pcapng -Y rrc || s1ap || nas_eps -T fields \ -e frame.time_relative \ -e frame.protocols \ -e rrc.messageName \ -e s1ap.ProcedureCode \ -e nas_eps.nas_msg_emm_type \ -E headery -E separator, attach_msgs.csv这里-Y做了三层协议过滤器-T fields指定输出自定义字段frame.time_relative是相对时间戳便于后续计算消息间隔。rrc.messageName在空口抓包里能看到RRC层具体的消息名s1ap.ProcedureCode会显示S1AP的流程码nas_eps.nas_msg_emm_type则是NAS EMM消息类型。如果你的抓包工具在S1-MME口抓的RRC层就没有数据此时rrc.messageName为空属正常现象。后续用Python做流程统计可以直接把这个CSV读进来按消息类型做时序还原import csv from collections import Counter with open(attach_msgs.csv, r, encodingutf-8) as f: reader list(csv.DictReader(f)) # 按时间排序保证流程顺序正确 reader.sort(keylambda r: float(r[frame.time_relative])) # 统计NAS EMM消息类型 emm_counter Counter(r[nas_eps.nas_msg_emm_type] for r in reader if r[nas_eps.nas_msg_emm_type]) for msg_type, cnt in emm_counter.most_common(): print(msg_type, cnt)这段脚本只做了一件事把NAS消息类型按出现次数归并输出。真正有价值的用法是把EMM类型和S1AP ProcedureCode结合起来看。比如Attach Request之后如果S1AP里同时出现Initial Context Setup Request说明MME已经完成了默认承载建立并开始请求空口资源反之如果只有Initial UE Message没有后续则说明认证或订阅数据环节出了问题。此时再在CSV里搜Authentication Request和Security Mode Command就能快速定位卡在哪一环节。4.3 从IMEI、GUTI、TAC还原一次完整流程的标注技巧同一段抓包里可能混杂多台UE的信令直接按消息名过滤会非常混乱。我的做法是先在抓包时按IMEI或IMSI建立纵向线索再辅助GUTI做横向关联最后再按时间轴把该用户的RRC Setup、Attach、TAU、Service Request、Handover逐条串起来。大多数商用终端在Attach Request里会携带IMEI或IMEISVGUTI则在附着成功后的Attach Accept里重新分配。所以如果只有整段抓包没有终端日志通常做法是先找到Attach Accept拿到新GUTI后再用GUTI字段反向过滤这个用户的后续信令。抓包软件里保存一份表格会使整个过程清晰很多| 关联维度 | 典型字段 | 用途 | |---|---|---| | 硬件标识 | IMEI/IMEISV | 终端级唯一标识 | | 用户标识 | IMSI | 对应SIM卡身份 | | 临时标识 | old GUTI / new GUTI | 跨节点关联用户上下文 | | 位置标识 | TAI/TAC | 判断是否跨TA或跨MME Pool | | 承载标识 | EPS Bearer ID | 关联默认承载与专用承载 |另一个实用技巧是同时查看UE发起的源IP。Attach成功后SGW分配的IP会出现在Activate Default EPS Bearer Context Request消息里这个IP在后端日志里往往能直接对应到用户面流量。如果抓包里同时有SGi接口镜像用这个IP做关联用户面和信令面就全部打通了定位问题时能直接看到「信令完成但用户面没流量」还是「信令就没成功」。5. 避坑与排查信令分析里最常见的5个翻车现场5.1 现象Attach Request反复重发MME始终不响应UE在空口侧发出Attach Request后迟迟没有收到任何NAS层回应随后会因T3410超时重发。T3410定时器控制UE等待Attach Accept/Reject的时间默认15秒可配置。原因最常见的是MME到HSS的Diameter链路不通或HSS返回签约数据错误。MME在收到Initial UE Message后会先向HSS发送鉴权信息请求如果这个环节失败MME既不会回复UE也不会拒绝唯一的结果就是等待。解决先看S6a接口抓包确认AIR/AIA消息是否返回正常返回内容是鉴权五元组再在MME侧看用户签约数据是否为空或APN配置缺失。经验是把S6a信令和空口RRC时间戳对齐只要看到AIR没有对应AIA问题就锁定在HSS或传输链路省得反复抓空口。5.2 现象TAU Request里的GUTI对不上被MME当成非法UE一次跨MME Pool的TAU过程中UE在TAU Request里携带了旧GUTI但MME向旧MME请求上下文时拿到失败随后MME直接回TAU Rejectcause #9UE identity cannot be derived by network。原因通常是旧MME侧保留的UE上下文已经被清除或MME Pool内的GUMMEI解析配置错误。解决对比GUTI里的GUMMEI和当前MME所服务的映象组确认旧MME和新MME是否属于同一个MME Pool然后检查MME间的S10接口链路如果S10不可达跨MME的TAU必然失败。这类问题不是无线问题别让网优同事白跑一趟。5.3 现象Wireshark里NAS消息全是密文看不到bearer建立细节在路测软件或终端侧日志里经常看到安全模式激活之后NAS消息就变成一串不可读的字节。原因Security Mode Command激活完整性保护后NAS消息本体在空口加密传输如果没有加载K_eNB和密钥普通抓包软件很难解码。解决如果只关心流程完整性可以直接看核心网S1-MME侧抓包因为NAS在S1-MME口上依然以明文或可解格式传输如果必须看空口就用终端厂家路测软件的解密功能并确保在log配置里勾选安全参数输出。注意即使不解密EMM消息类型字段很多时候仍然可以识别别因为内容不可读就判断信令异常先确认是不是解码问题再下结论。5.4 现象S1AP显示Initial Context Setup Request已下发空口却没有任何RRC重配在分析S1-MME抓包时看到MME确实发出了Initial Context Setup Request但路测日志里没有对应的RRC Connection Reconfiguration随后S1AP收到的是Setup Failure。原因eNodeB空口侧或承载建立失败比如目标小区发生了RLF、UE失步或eNodeB的内部DRB配置出现冲突。还有一种常见情况eNodeB配置的PRACH前导格式或随机接入参数不合理导致空口RACH过程一直失败。解决把S1AP Failure消息中的Cause值摘出来S1AP的Cause通常区分Radio Network、Transport和Protocol三类Radio Network类原因对应的就是空口或UE失步问题再在eNodeB侧告警里查是否有RRU异常、小区高负荷导致的准入拒绝。信令分析可以定位区间但无法代替基站侧最终告警判断。5.5 现象Attach成功了但用户面流量仍然不通信令完整走到RRC Connection Reconfiguration Complete核心网创建会话成功但网页打开还是失败。原因有可能是建立默认承载的QCI或APN-AMBR参数过小导致吞吐被限也可能是S1-U接口的GTP-U隧道建好但eNodeB到SGW的路由不通。解决先看Activate Default EPS Bearer Context Request中的QCI、APN-AMBR和BR值再检查S1-U口抓包看GTP Echo是否正常、是否有ICMP不可达回包。最直接的办法是同一时刻抓S1-MME和S1-U两侧数据S1-U只要看到GTP-U下行数据开始传就说明MME信令链路没毛病问题在无线侧或承载配置速率上。6. 进阶用「指标-消息-流程」三段式快速从整段信令集收敛到具体病根先看指标把整段跟踪里的EMM Cause、S1AP Cause、RRC建立成功率、切换成功率做成分布不看具体某条消息先从宏观判断是哪一类失败特征。EMM Cause里出现#15、#12、#13相对高频会引导我直接去查跟踪区规划、TA List配置和漫游签约S1AP Cause集中在Radio Network时优先查基站侧资源与RF问题。再看消息选一条关键消息看关键参数而不是把十几条消息全部展开读。比如选Attach Accept重点看T3412、T3402、EPS Attach Result这3个字段选Security Mode Command则直接看选定的算法和密钥长度选RRC Connection Reconfiguration关注measConfig里是否包含当前服务小区的同频邻区频点。很多黑匣子问题靠的是关键参数比对而不是消息数量。最后走流程把这条用户的信令按时间轴完整串起来确认每一步是否「该出现时出现、该结束时结束」。如果遇到中间缺少某条响应那就是问题区间如果出现重复发送某条请求优先怀疑定时器超时或对端处理延迟。这套方法我用过很多年最深的体会是信令分析不要一上来就扎进单条消息里反复看同一段抓包里先做指标分布再挑典型消息最后补完流程比靠直觉直接看图高效得多。还有一个养成很久的习惯每次分析完都会把最终定位的原因记录在表格里避免下一次在同类cause上跳进同一个坑。希望这套步骤对和你一样的信令分析和优化工程师也有帮助。本文还有配套的精品资源点击获取 4G信令全流程实战：从Attach到切换的信令分析与故障排查
简介面向LTE/4G网络学习与日常优化的一份信令流程梳理材料重点解决协议层级多、信令流程分散带来的理解门槛。文档先建立协议层与概念基础依次拆解NAS、RRC、PDCP、RLC、MAC、PHY等协议职责并说明控制面/用户面、空闲态/连接态、网络标识及承载概念随后按照实际网络行为主线详细展开开机附着、随机接入、Service Request、寻呼、切换与CSFB等核心流程每类流程均交代触发条件、主要信令消息与状态变化便于对照现网消息抓取和参数理解形成从原理到流程的完整认知。压缩包内为单个docx文档大小1.83MB目录按章节渐进、条理清晰既可以作为通信专业学生对LTE信令体系的入门导图也适合网络优化人员在日常排障时按图索骥、快速定位流程节点。目前已有1935人浏览/学习。1. 4G信令全流程一条投诉电话背后的信令链路远比满格信号重要我有一次处理用户投诉「手机显示满格信号但打开网页就是转圈」现场蹲了一天RF报告没有任何弱覆盖迹象。最后调出核心网跟踪发现Attach流程根本没走到默认承载激活MME回的是Attach Rejectcause #15。满格只是下行接收好信令链路没完成业务自然起不来。这就是4G信令全流程的价值从UE开机、小区选择、附着、TAU到业务请求与切换一套信令交互能把用户感知问题精确锁到一个网元或一条配置上。这篇笔记适合网优、核心网测试和刚转信令分析的人目标不是背协议栈而是拿着跟踪就能看懂信令在说什么、卡在哪。2. 先把信令面拆开协议栈分层、网元接口与消息清单长什么样2.1 控制面不是一根线Uu口、S1-MME口与S11口各传递什么4G信令并不只在网元间单向传递。一次附着同时穿过多条接口每条接口上跑的协议不同、职责也不同。UE和eNodeB之间跑的Uu口信令是RRCRadio Resource Control它负责建立、重配置和释放空口资源UE和MME之间的NASNon-Access Stratum消息则承载在RRC之上由eNodeB透明转发不做解析。eNodeB和MME之间是S1-MME接口跑S1AP协议负责把NAS消息封装成Initial UE Message、Uplink/Downlink NAS Transport这类信令并管理UE在基站侧的上下文。MME往核心网侧走还有S11接口的GTP-C信令链路用于EPS承载的创建、修改和删除。这三层链路在Wireshark里同一条抓包里经常交叠出现。我在分析时有个习惯先把抓包按接口分开理解。空口抓包往往包含RRC和NAS两层但如果没有同时抓S1-MME就只能看到eNodeB的出入口看不到MME侧的响应逻辑反过来只抓核心网侧S1-MME或S11口可以看清MME和SGW的行为但空口重配是否下发又要靠路测日志补全。所以做全流程信令分析最理想的是把Uu口和S1-MME口时间对齐一起看否则很容易把「空口已经下发重配核心网还没收到响应」这类问题误判成对端网元不响应。2.2 NAS消息是业务意图RRC、S1AP是搬运通道双层结构怎么区分很多新手看信令最大的障碍是分不清NAS和RRC/S1AP。NAS消息表达的是UE和MME之间的业务意图比如我要附着、我要做TAU、我要请求服务RRC消息表达的则是UE和eNodeB之间空口资源的分配比如我要建立连接、我配置了哪些无线承载。S1AP消息又是eNodeB和MME之间的交换行为对应物比如初始UE上下文建立、UE上下文释放请求。同一个流程里NAS消息会被封装在RRC和S1AP消息内部形成一层套一层的结构。举个例子UE发起附着时先看到RRC Connection Request、RRC Connection Setup随后UE发的RRC Connection Setup Complete里就携带了Attach Request这条NAS消息这条NAS消息到了eNodeB再被封装进S1AP的Initial UE Message里送给MME。如果分析时只在过滤器里输入nas_eps是看不到RRC层在发声的但如果只盯RRC又看不出用户到底是附着还是TAU。我一般会在Wireshark里同时保留rrc || s1ap || nas_eps用Time列做时间轴按消息先后关系还原整个流程比单看某一层容易定位得多。2.3 一张表看清常用信令消息的触发场景与关键参数消息层消息名称触发场景关键字段NAS(EMM)Attach RequestUE开机、从无服务到有服务IMSI或old GUTI、attach类型、T3410相关定时器NAS(EMM)Attach AcceptMME接受附着T3412周期TAU定时器、T3402、EPS附着结果NAS(EMM)TAU Request跨TA边界、周期TAUold GUTI、last visited TAINAS(ESM)PDN Connectivity Request附着时建立默认承载APN、PDN type、用户面协议参数NAS(ESM)Activate Default EPS Bearer Context RequestMME准备激活默认承载分配的IP地址、QCI、APN-AMBRRRCRRC Connection Setup Complete空口连接建立完成携带初始NAS消息RRCRRC Connection ReconfigurationeNodeB下发专用配置DRB配置、测量配置、NAS透传S1APInitial UE MessageeNodeB上送NAS消息给MMEeNB UE S1AP ID、NAS消息载荷S1APUE Context Release CommandMME释放UE上下文S1AP Cause、释放原因表格里最容易被忽略的是ESM消息。很多人只要看到Attach Accept就认为成功但真正决定「能不能上网」的是后面那条Activate Default EPS Bearer Context Request。它带了分配的IP地址和QCIQCI决定用户面数据走哪条承载、优先级和丢包预算。如果Attach Accept正常但这条ESM消息没出来大概率是PDN Connectivity Request里APN解析出问题或PGW侧会话建立失败。3. 从开机到可用的完整流程拆解附着、TAU、业务请求与切换3.1 Attach流程逐条递进从RRC Connection Setup到默认承载激活Attach是4G信令里最完整、也最能锻炼读包能力的流程。从UE开机到能上网通常经过十几步信令交互。我用一张简化的消息序列来描述序号传输方向消息作用与关键信息1UE → eNodeBRRC Connection Request发起空口连接携带初始UE标识2eNodeB → UERRC Connection Setup分配SRB1资源配置信令承载3UE → eNodeBRRC Connection Setup Complete携带NAS Attach Request含IMSI或old GUTI4eNodeB → MMES1AP Initial UE Message透传Attach Request到MME5MME → HSSDiameter AIR/UIA鉴权矢量请求与用户订阅数据获取6MME → UENAS Authentication Request下发随机数和鉴权令牌7UE → MMENAS Authentication Response回传鉴权应答验证网络合法性8MME → UENAS Security Mode Command启动完整性保护和加密算法协商9UE → MMENAS Security Mode Complete确认安全上下文激活10UE → MMENAS PDN Connectivity RequestESM层请求建立默认PDN连接携带APN11MME → SGW/PGWGTP-C Create Session Request/Response核心网侧建立默认承载12MME → UENAS Attach Accept携带GUTI、T3412、T3402、EPS附着结果13UE → MMENAS Attach Complete确认附着完成T3410停止14MME → eNodeBS1AP Initial Context Setup Request请求eNodeB建立UE上下文与DRB15eNodeB → UERRC Connection Reconfiguration下发DRB配置与测量配置16UE → eNodeBRRC Connection Reconfiguration Complete空口承载建立完成17eNodeB → MMES1AP Initial Context Setup Response通知MME上下文建立成功第12步Attach Accept里面的T3412就是周期TAU定时器默认值常见的是30分钟到60分钟运营商可按需求调整T3402则是附着或TAU被拒绝之后UE需要等待多久才能再发起流程。很多「手机莫名其妙从4G掉到无法注册」的投诉追根究底就是T3402太长或太短。第14步到第17步容易和Attach流程混淆注意上下文建立完成之后用户面数据才开始真正能跑。若遇到第4步Initial UE Message之后MME不回鉴权请求多半要查HSS侧是否能查到USIM信息若在第10步之后卡住则优先看APN设置和PGW可达性。3.2 TAU流程里的「为什么换小区会卡」TAC边界与定时器TAU全称是Tracking Area UpdateUE发现当前所在的跟踪区不在注册的TA List里就会发起请求。触发场景有三类跨TA边界、周期TAU由T3412控制、以及从旧小区回到可注册区域。TAU流程在信令里最常见的问题是「UE发TAU Request但MME回了TAU Rejectcause #12或#13」。#12表示该跟踪区不被允许#13表示该跟踪区不允许漫游。处理思路完全不同#12是TA规划问题通常需要核对运营商TA List配置和MME Pool边界#13则涉及漫游白名单和运营商间协议。周期TAU也是一类高发问题。如果T3412设置过短UE频繁发起TAU会显著增加MME信令负荷小区掉线率和呼叫建立时延都会被拉高如果T3412设置过长MME和SGW容易认为UE不可达导致下行寻呼失败。通常做法是在MME上按「寻呼响应率」反向调参寻呼成功率低于阈值时适当缩短T3412否则调长。我在分析抓包时会特别对比TAU Request里的last visited TAI和当前小区广播的TAC——两者一致但MME还回TAU Accept并重新分配GUTI说明是老GUTI关联不上旧MME变成了「类似初始附着的TAU」这是MME Pool过大导致上下文丢失的典型信号。3.3 Service Request和S1释放小流量状态下的信令节省机制UE完成附着后并不会一直占用空口资源。当UE处于RRC Connected态且无数据时eNodeB会通过S1AP UE Context Release来释放空口连接但保留核心网PDN连接这叫RRC Idle态。之后一旦UE有上行数据或收到寻呼就通过Service Request流程恢复连接。Service Request和Attach最大的区别是它不重建PDN连接只是空口和用户面承载恢复所以信令步骤明显更少。序号方向消息作用1UE → eNodeBRRC Connection Request/Setup空口恢复SRB2UE → MMENAS Service Request携带P-TMSI或GUTI、请求的业务类型3MME → eNodeBS1AP Initial Context Setup Request请求恢复建立UE上下文与DRB4eNodeB → UERRC Connection Reconfiguration恢复DRB配置5eNodeB → MMES1AP Initial Context Setup Response用户面恢复成功Service Request最容易遇到的坑是UE在空口侧连发多次请求但核心网没有响应。原因通常有两个一是MME侧的UE上下文已被释放比如T3412周期TAU超时核心网认为UE失联需要先做TAU再发起Service Request二是eNodeB配置的上行非连续接收参数和MME的寻呼参数不匹配导致下行寻呼消息发给了错误的小区。信令分析里有一种典型场景手机上显示4G但有下行流量时页面转圈打开S1-MME跟踪发现MME发出Paging后空口侧完全没有RRC连接建立请求这时基本可以断定是寻呼消息没有正确下发到UE驻留小区。3.4 切换流程的分类X2切换和S1切换的判断路口切换按接口分为X2切换和S1切换。X2切换是源eNodeB和目标eNodeB之间通过X2接口直接协商MME只负责事后做Path SwitchS1切换则由MME全程参与适用于跨MME或X2不可用的场景。从信令上判断切换类型很直观X2切换里源eNodeB直接发Handover Request给目标eNodeB随后UE收到RRC Connection Reconfiguration里面带新的C-RNTI和无线资源配置目标eNodeB直接发送SN Status Transfer给核心网最后通过Path Switch Request通知MME更新承载路径。S1切换则在源eNodeB处多了一条S1AP Handover RequiredMME收到后向目标eNodeB发Handover Request完成资源准备后再下发Handover Command。两者对应的排查思路不同X2切换失败优先查X2接口链路、目标小区的负荷准入策略和邻区关系S1切换失败则要查MME到目标eNodeB的SCTP链路、目标eNodeB覆盖异常或MME配置的切换白名单。分析切换信令时还有一个容易被忽略的点RRC Connection Reconfiguration里携带的measConfig如果切换目标小区频点不在测量配置里UE根本不会上报测量报告再完美的邻区关系也白搭。4. 抓包与解码怎么让一张信令跟踪数据「开口说话」4.1 常见采集方式网管侧跟踪、路测软件与核心网信令监测屏的取数差异市面上能拿到信令数据的途径不少但出问题也各有各的难处。网管侧跟踪比如基站OMC的UE信令跟踪可以拿到Uu口RRC和部分NAS适合做单用户问题回溯路测软件一般是路测小哥手里那套工具和测试终端配合可以拿到空口AS和NAS解码但需要厂家授权解密而且如果用的不是内置基带上报某些加密NAS消息会显示成密文核心网信令监测屏或抓包工具挂S1-MME能拿到S1AP和NAS明文但看不到空口Radio Resource配置细节。我在实际项目中常做的做法是「双端对齐」Uu口侧用路测软件的logS1-MME侧用核心网跟踪或分流探针抓包。两边分别导出原始日志再用同一时刻的GUTI或IMEI做关联。否则只取一端经常会遇到「RRC层显示成功、S1MME没有对应消息」或反之非常容易出现误判。如果你是在实验室搭环境直接用模拟基站加一台普通抓包电脑就能拿到较理想的双端数据完全不需要上商用网。4.2 用tshark和Python在离线抓包里统计信令时序拿到pcap后第一步是把信令按时间顺序过滤出来。我习惯用Wireshark自带的tshark做批处理把NAS、S1AP和RRC消息导成CSV再交给Python做聚合统计。下面这个命令适合在拿到离线抓包后快速评估整段信令的时间分布tshark -r attach.pcapng -Y rrc || s1ap || nas_eps -T fields \ -e frame.time_relative \ -e frame.protocols \ -e rrc.messageName \ -e s1ap.ProcedureCode \ -e nas_eps.nas_msg_emm_type \ -E headery -E separator, attach_msgs.csv这里-Y做了三层协议过滤器-T fields指定输出自定义字段frame.time_relative是相对时间戳便于后续计算消息间隔。rrc.messageName在空口抓包里能看到RRC层具体的消息名s1ap.ProcedureCode会显示S1AP的流程码nas_eps.nas_msg_emm_type则是NAS EMM消息类型。如果你的抓包工具在S1-MME口抓的RRC层就没有数据此时rrc.messageName为空属正常现象。后续用Python做流程统计可以直接把这个CSV读进来按消息类型做时序还原import csv from collections import Counter with open(attach_msgs.csv, r, encodingutf-8) as f: reader list(csv.DictReader(f)) # 按时间排序保证流程顺序正确 reader.sort(keylambda r: float(r[frame.time_relative])) # 统计NAS EMM消息类型 emm_counter Counter(r[nas_eps.nas_msg_emm_type] for r in reader if r[nas_eps.nas_msg_emm_type]) for msg_type, cnt in emm_counter.most_common(): print(msg_type, cnt)这段脚本只做了一件事把NAS消息类型按出现次数归并输出。真正有价值的用法是把EMM类型和S1AP ProcedureCode结合起来看。比如Attach Request之后如果S1AP里同时出现Initial Context Setup Request说明MME已经完成了默认承载建立并开始请求空口资源反之如果只有Initial UE Message没有后续则说明认证或订阅数据环节出了问题。此时再在CSV里搜Authentication Request和Security Mode Command就能快速定位卡在哪一环节。4.3 从IMEI、GUTI、TAC还原一次完整流程的标注技巧同一段抓包里可能混杂多台UE的信令直接按消息名过滤会非常混乱。我的做法是先在抓包时按IMEI或IMSI建立纵向线索再辅助GUTI做横向关联最后再按时间轴把该用户的RRC Setup、Attach、TAU、Service Request、Handover逐条串起来。大多数商用终端在Attach Request里会携带IMEI或IMEISVGUTI则在附着成功后的Attach Accept里重新分配。所以如果只有整段抓包没有终端日志通常做法是先找到Attach Accept拿到新GUTI后再用GUTI字段反向过滤这个用户的后续信令。抓包软件里保存一份表格会使整个过程清晰很多| 关联维度 | 典型字段 | 用途 | |---|---|---| | 硬件标识 | IMEI/IMEISV | 终端级唯一标识 | | 用户标识 | IMSI | 对应SIM卡身份 | | 临时标识 | old GUTI / new GUTI | 跨节点关联用户上下文 | | 位置标识 | TAI/TAC | 判断是否跨TA或跨MME Pool | | 承载标识 | EPS Bearer ID | 关联默认承载与专用承载 |另一个实用技巧是同时查看UE发起的源IP。Attach成功后SGW分配的IP会出现在Activate Default EPS Bearer Context Request消息里这个IP在后端日志里往往能直接对应到用户面流量。如果抓包里同时有SGi接口镜像用这个IP做关联用户面和信令面就全部打通了定位问题时能直接看到「信令完成但用户面没流量」还是「信令就没成功」。5. 避坑与排查信令分析里最常见的5个翻车现场5.1 现象Attach Request反复重发MME始终不响应UE在空口侧发出Attach Request后迟迟没有收到任何NAS层回应随后会因T3410超时重发。T3410定时器控制UE等待Attach Accept/Reject的时间默认15秒可配置。原因最常见的是MME到HSS的Diameter链路不通或HSS返回签约数据错误。MME在收到Initial UE Message后会先向HSS发送鉴权信息请求如果这个环节失败MME既不会回复UE也不会拒绝唯一的结果就是等待。解决先看S6a接口抓包确认AIR/AIA消息是否返回正常返回内容是鉴权五元组再在MME侧看用户签约数据是否为空或APN配置缺失。经验是把S6a信令和空口RRC时间戳对齐只要看到AIR没有对应AIA问题就锁定在HSS或传输链路省得反复抓空口。5.2 现象TAU Request里的GUTI对不上被MME当成非法UE一次跨MME Pool的TAU过程中UE在TAU Request里携带了旧GUTI但MME向旧MME请求上下文时拿到失败随后MME直接回TAU Rejectcause #9UE identity cannot be derived by network。原因通常是旧MME侧保留的UE上下文已经被清除或MME Pool内的GUMMEI解析配置错误。解决对比GUTI里的GUMMEI和当前MME所服务的映象组确认旧MME和新MME是否属于同一个MME Pool然后检查MME间的S10接口链路如果S10不可达跨MME的TAU必然失败。这类问题不是无线问题别让网优同事白跑一趟。5.3 现象Wireshark里NAS消息全是密文看不到bearer建立细节在路测软件或终端侧日志里经常看到安全模式激活之后NAS消息就变成一串不可读的字节。原因Security Mode Command激活完整性保护后NAS消息本体在空口加密传输如果没有加载K_eNB和密钥普通抓包软件很难解码。解决如果只关心流程完整性可以直接看核心网S1-MME侧抓包因为NAS在S1-MME口上依然以明文或可解格式传输如果必须看空口就用终端厂家路测软件的解密功能并确保在log配置里勾选安全参数输出。注意即使不解密EMM消息类型字段很多时候仍然可以识别别因为内容不可读就判断信令异常先确认是不是解码问题再下结论。5.4 现象S1AP显示Initial Context Setup Request已下发空口却没有任何RRC重配在分析S1-MME抓包时看到MME确实发出了Initial Context Setup Request但路测日志里没有对应的RRC Connection Reconfiguration随后S1AP收到的是Setup Failure。原因eNodeB空口侧或承载建立失败比如目标小区发生了RLF、UE失步或eNodeB的内部DRB配置出现冲突。还有一种常见情况eNodeB配置的PRACH前导格式或随机接入参数不合理导致空口RACH过程一直失败。解决把S1AP Failure消息中的Cause值摘出来S1AP的Cause通常区分Radio Network、Transport和Protocol三类Radio Network类原因对应的就是空口或UE失步问题再在eNodeB侧告警里查是否有RRU异常、小区高负荷导致的准入拒绝。信令分析可以定位区间但无法代替基站侧最终告警判断。5.5 现象Attach成功了但用户面流量仍然不通信令完整走到RRC Connection Reconfiguration Complete核心网创建会话成功但网页打开还是失败。原因有可能是建立默认承载的QCI或APN-AMBR参数过小导致吞吐被限也可能是S1-U接口的GTP-U隧道建好但eNodeB到SGW的路由不通。解决先看Activate Default EPS Bearer Context Request中的QCI、APN-AMBR和BR值再检查S1-U口抓包看GTP Echo是否正常、是否有ICMP不可达回包。最直接的办法是同一时刻抓S1-MME和S1-U两侧数据S1-U只要看到GTP-U下行数据开始传就说明MME信令链路没毛病问题在无线侧或承载配置速率上。6. 进阶用「指标-消息-流程」三段式快速从整段信令集收敛到具体病根先看指标把整段跟踪里的EMM Cause、S1AP Cause、RRC建立成功率、切换成功率做成分布不看具体某条消息先从宏观判断是哪一类失败特征。EMM Cause里出现#15、#12、#13相对高频会引导我直接去查跟踪区规划、TA List配置和漫游签约S1AP Cause集中在Radio Network时优先查基站侧资源与RF问题。再看消息选一条关键消息看关键参数而不是把十几条消息全部展开读。比如选Attach Accept重点看T3412、T3402、EPS Attach Result这3个字段选Security Mode Command则直接看选定的算法和密钥长度选RRC Connection Reconfiguration关注measConfig里是否包含当前服务小区的同频邻区频点。很多黑匣子问题靠的是关键参数比对而不是消息数量。最后走流程把这条用户的信令按时间轴完整串起来确认每一步是否「该出现时出现、该结束时结束」。如果遇到中间缺少某条响应那就是问题区间如果出现重复发送某条请求优先怀疑定时器超时或对端处理延迟。这套方法我用过很多年最深的体会是信令分析不要一上来就扎进单条消息里反复看同一段抓包里先做指标分布再挑典型消息最后补完流程比靠直觉直接看图高效得多。还有一个养成很久的习惯每次分析完都会把最终定位的原因记录在表格里避免下一次在同类cause上跳进同一个坑。希望这套步骤对和你一样的信令分析和优化工程师也有帮助。本文还有配套的精品资源点击获取