简介《LTE 抓包分析指导手册》是一份面向通信网络工程师与优化维护人员的实战文档重点解决LTE网络数据包捕获与分析中的实际难题。手册系统介绍了UU口、eNodeB和核心网三类场景的抓包准备工作与操作流程既包含测试电脑和安卓手机的UU口抓包方法也覆盖基站侧专用工具的配置要点。数据分析部分详细讲解了单个业务线程过滤、丢包与乱序分析、IO Graphs可视化应用以及无线侧BLER与丢包联合分析方法便于读者定位网络拥塞、时序紊乱或空口异常。资源以单个PDF文档呈现大小约1.72MB目录结构清晰总计1个文件。目前已有293人学习浏览适合需要快速掌握LTE信令抓包与分析思路的现场维护、网优及测试人员参考。1. LTE 抓包分析不是事后补救外场问题定位的第一现场外场测试最尴尬的场面是用户在电梯口刷不出视频测试手机却显示 LTE 信号满格。空口指标全绿问题到底出在接入、承载还是内容侧现场谁都不敢拍板唯一能当客观依据的就是抓包文件。LTE 抓包分析要做的就是把 Uu 口与 S1 口的信令按时间线还原让一次业务从终端到核心网的每一步都变成可判读的字段。这套思路的核心不是工具而是在哪一层抓、抓完解什么、解完看什么。把三点捋顺外场测试、协议栈开发和网优排查遇到信号正常但业务失败的场景就能用同一套方法收敛。下面按数据源、解析、场景和验证往下走。2. LTE 抓包的数据源选型终端侧日志与网络侧镜像怎么配抓包的第一步不是打开某个工具而是先回答一个问题这一包数据要为哪个结论服务。定位 Attach 失败需要 NAS 消息定位速率问题需要 PDCP 和 RLC定位核心网响应慢则需要 S1 口数据。数据源选错分析做得越细越偏离现场所以先花几分钟把终端侧和网络侧两套抓法讲清。2.1 高通平台最小抓包配置QXDM 日志组与文件管理外场测试里高通平台测试机用 QXDM 抓空口信令是默认动作。连接前先确认驱动把手机识别为 Qualcomm HS-USB Diagnostics 端口否则 QXDM 的设备列表里什么都不会出现。连上之后不要贪全在 Options → Log Packet Configuration 里按层勾选RRC 和 NASEMM/ESM覆盖接入、鉴权、注册这类移动性问题涉及速率和时延再补 PDCP 的按序递交和 RLC 的 ARQ 统计。MAC 层调度日志一开就是每秒几百 MB 的写入外场笔记本的磁盘多半扛不住我一般只在外场复测调度类问题时才开。日志落盘建议打开 Save to file按 200MB 一个文件轮转、最多保留 5 个。连续跑一天既有完整记录又不会撑爆磁盘很多故障恰好发生在终端重启前的最后几秒手动停止存储会恰好丢掉这段。保存成 .hdf 还是 .isf 不影响后续分析关键是别在测试过程中反复开关日志外场抓包最怕的就是看起来在抓其实没写盘。2.2 S1 口镜像抓包tcpdump 抓 S1AP 与 GTP-U 的最小命令终端侧日志只反映手机自己的视角判断问题是否在核心网时需要 S1 口数据。S1-MME 用 SCTP 承载 S1AP常见监听端口是 36412用户面 S1-U 是 UDP 2152 上的 GTP-U。网络侧常见做法是把这两个口镜像到专用抓包机一条 tcpdump 同时收sudo tcpdump -i eth0 -s 0 -w /data/s1_$(date %Y%m%d_%H%M).pcap \ sctp port 36412 or (udp port 2152)-s 0 表示抓全包SCTP 和 GTP 都是可变长承载截断后 Wireshark 连 S1AP 的边界都找不对这是新手最容易踩的坑-w 指定输出文件过滤表达式把控制面 SCTP 和数据面 UDP 两个端口用 or 连起来。需要长时间挂机时加 -C 200 -W 10 让 tcpdump 按 200MB 轮转并最多保留 10 个文件。镜像口流量大时 tcpdump 可能丢包加 -B 4096 把内核抓包缓冲提到 4MB结束时会打印丢包统计先确认没丢包再谈信令缺失。提示上外场前先在办公室验证镜像口通不通、端口是不是 36412。很多现场 S1AP 走私有端口抓回来一堆 SCTP DATA 却解不出 S1AP不是数据没抓到是没告诉 Wireshark 怎么解。2.3 手机、lte 无线路由器与网络侧的抓包差异同样是LTE 抓包手机、lte 无线路由器CPE和 eNodeB 镜像口三处的可行方案差别很大。CPE 上没有 QXDM 那种空口全量日志方案商通常只给工程模式 AT 命令高通方案常见 ATQENG 查询服务小区和电平想看空口信令得依赖方案商的私有日志工具支持到哪一层是不确定的。所以遇到 CPE 类设备通用做法是把 S1 口抓包当主证据、AT 命令输出当辅助不要指望复现手机侧那种完整协议栈。抓包位置常用工具能覆盖的范围主要限制手机外场测试QXDM QCAT / MTK CatcherRRC、NAS、PDCP、RLC 全栈需要测试机授权日志量大LTE 无线路由器/CPE方案商日志 工程模式 AT 命令小区参数、少量 NAS 事件空口信令基本不可见eNodeB S1 镜像口tcpdump / tshark WiresharkS1AP、透传 NAS、GTP-U需要网管配合Uu 口是盲区选型结论很直接外场复现手机问题以 QXDM 终端日志为主设备侧或核心网侧问题以 S1 镜像为主CPE 场景接受网络侧证据加射频指示的折中。数据源定了下一步才轮到 Wireshark 怎么把原始日志变成可读信令。3. 用 Wireshark 做 LTE 信令抓包与解析日志转换、解码偏好与过滤语法原始日志几乎不能直接拖进 WiresharkQXDM 的 .isf/.hdf 是私有格式S1 镜像抓回来的 SCTP 也要先告诉 Wireshark 按 S1AP 解。这一章把从原始日志到可判读信令的三步处理讲清楚转换格式、设置解码偏好、用过滤语法锁定目标消息。3.1 日志转 pcapQCAT 导出与时间基准确认QXDM 保存的 .isf/.hdf 用配套的 QCAT高通协议分析工具打开选中 LTE 相关记录导出为 pcap 或 pcapngMTK 平台则是 Catcher/工程日志导出界面不同但出口一致。导出后先做两件事确认时间戳是设备本地时间还是 GPS 授时这决定了后面能不能和 S1 抓包做时间对齐确认转出的包有没有带 RLC/MAC 头带头的能做调度和重传统计不带头的只能看 RRC/NAS 内容。这里有个关键差异值得单独说终端侧 QXDM 是在协议栈内部取日志RRC 和 NAS 是加解密之前的内容所以空口开了加密也能读明文。S1 口抓包里的 NAS-PDU 是被 NAS 密钥加密后的容器没有密钥就只能看哪条流程、哪个步骤看不到里面字段。因此做跨接口对比时NAS 字段以终端侧为准S1 侧用来核对交互时序和核心网响应行为。3.2 解码偏好设置让 S1AP、NAS 和 RRC 字段都显示出来把 pcap 拖进 Wireshark 后最常遇到三种显示不出来。第一种是 SCTP 端口不是默认值导致 S1AP 不被识别在 Analyze → Decode As 里把对应 SCTP 端口强制解为 S1AP。第二种是 RRC 信令在空口被 RLC 分段传输转出时没有重组NAS 部分显示为残缺数据在 Preferences → Protocols → LTE RRC 里打开重组选项即可。第三种是时间显示问题把 View → Time Display Format 切成 Seconds Since Previous Displayed Packet逐条看间隔比看绝对时间更能快速定位异常等待。注意Wireshark 版本差异主要影响 RRC 字段前缀新版用 lte_rrc老版本叫 rrc。换电脑分析时字段不一致先检查版本再怀疑数据。3.3 NAS 消息类型速查与过滤语法定位一次失败NAS 层是 LTE 移动性分析的入口每条 EMM 消息都有固定消息类型值记住几个常用的比每次翻规范快得多NAS 消息msg_type典型用途Attach Request0x41开机注册起点Attach Reject0x44注册失败带 EMM CauseDetach Request0x45去注册或关机TAU Request0x48跨 TA 更新、周期性更新Authentication Request0x52鉴权流程起点Security Mode Command0x5DNAS/AS 安全激活过滤语法直接对应 Wireshark 的显示过滤栏tshark -r attach.pcap -Y nas-eps.msg_type 0x41 \ -T fields -e frame.number -e frame.time -e nas-eps.msg_type | head-Y 指定显示过滤和 Wireshark 顶部过滤栏是同一套语法-T fields -e 指定按列输出。把 0x41 换成 0x44再补一个 -e nas-eps.emm.cause就能把整段日志里所有 Attach Reject 及其拒绝原因一次性列出来。空口侧 RRC 同理用 lte_rrc.RRCConnectionSetup、lte_rrc.RRCConnectionReconfiguration 过滤对应消息在消息上右键 Apply as Filter 可以自动生成合法字段比手敲稳妥。4. 三个高频场景的 LTE 抓包分析Attach、切换与 TAU 的时间线还原有了能读的数据和过滤手段分析就要落到具体流程。外场和现网优化里八成的问题集中在 Attach 失败、切换异常和 TAU/寻呼三类场景。下面按先找起点、再找终点、最后对参数的顺序逐一展开。4.1 Attach 失败从 Attach Request 到 EMM Cause 的判读一次成功的 Attach 至少包含 RRC 建立、Attach Request、鉴权/安全、Attach Accept、Activate Default Bearer、Attach Complete 六个环节。失败定位的三步是在终端侧日志里找第一条 Attach Request 的时间找对应的 Reject 或超时点出现 Reject 就立刻看 EMM Cause。用 tshark 一步拿到所有拒绝tshark -r attach.pcap -Y nas-eps.msg_type 0x44 \ -T fields -e frame.time -e nas-eps.emm.causeEMM Cause 必须对照 3GPP TS 24.301 的编号表判读凭经验猜最容易出错。外场里高频的有下面几种EMM Cause含义排查方向#2IMSI unknown in HSS签约数据、开户状态#6Illegal MEIMEI 黑名单或鉴权失败#7EPS services not allowed数据业务未签约#12Tracking area not allowedTAC/TA list 配置#22Congestion核心网过载、节流#35Requested service option not subscribed套餐与 APN 不匹配超时类失败没有 cause 可看只能看间隔RRC 建立完成 10 秒内 NAS 层无响应优先怀疑空口覆盖边缘或核心网处理不过来3 秒内就被回拒则基本是配置和签约层面的问题。这个先分超时还是被拒的习惯能把一半的排查时间省掉。4.2 切换异常RRCConnectionReconfiguration 与 lte band 核对切换是外场测试里占比最高的场景抓包里的关键信令是带 mobilityControlInfo 的 RRCConnectionReconfiguration。收到这条消息后终端要完成到目标小区的随机接入并回 Reconfiguration Complete。判读时我一般看三个字段targetPhysCellId 确认目标小区是否和邻区表中的 PCI 一致carrierFreq 即 EARFCN按 3GPP TS 36.101 的表换算成 lte band异频切换里最常见的问题就是目标频点被配成了终端能力之外的 bandt304 定时器配得太短时切换执行稍慢就会触发 RLF抓包里的表现是配了 t304 之后没等到 Complete 就出现无线链路失败。另一种常见现场是信号满格但不切换。抓包里通常连着好几条 measurement report却迟迟没有 Reconfiguration这时候要回头看 measConfig 里有没有把目标小区的频点和 band 加进测量对象。抓包只会告诉你测量报告上没上报要解释为什么没上报得把测量配置和邻区表拿过来对着看。4.3 TAU 与寻呼多接口时间戳对齐的通用做法TAU 和寻呼问题往往要终端侧与 S1 侧拼接时间线多接口对齐这件事做不好所有后续判断都是猜的。通用做法是拿同一条 NAS 消息在两个文件里的到达时刻做差把其中一个整体平移再逐条比对时序。两侧时间源一致抓包机 NTP、终端 GPS 授时是前提小脚本直接算偏移# 计算同一个 Attach Request 在终端侧与 S1 侧抓包中的到达时刻差 import subprocess def first_msg_time(pcap, msg_type): out subprocess.check_output( [tshark, -r, pcap, -Y, fnas-eps.msg_type {msg_type}, -T, fields, -e, frame.time_epoch], textTrue) return float(out.splitlines()[0].split(\t)[0]) ue_t first_msg_time(ue.pcap, 0x41) s1_t first_msg_time(s1.pcap, 0x41) print(f偏移: {ue_t - s1_t:.3f}s S1时间 UE时间 {ue_t - s1_t:.3f}s)脚本逻辑是分别取两个 pcap 里第一条 Attach Request 的绝对时间戳做差。算出来的偏移若在整段测试里基本稳定就按这个值统一换算如果每条都会漂移说明某个时间源失锁先把时钟问题解决掉再继续。寻呼问题里重点核对 S1AP 寻呼消息的到达时间和终端侧 Paging 的接收时间两者相差过大时先查 eNB 到 MME 的链路质量而不要直接怀疑发射功率。5. 让 LTE 抓包结论站得住的三个验证技巧抓包分析最容易犯的错是一眼定罪看到某个 cause 或某个字段异常就急于下结论。后面三步是我每次出报告前都会过的检查比多翻十层字段更管用。5.1 先看时间差再看字段把时间显示切成 Seconds Since Previous Displayed Packet按顺序扫一遍同一条流程内相邻消息的间隔。RRC 请求发出去超过 1 秒才收到响应多数是上行覆盖或功控问题NAS 请求到响应正常、但后续承载激活中断才是核心网侧问题。时间差先把嫌疑范围缩小字段核对只在缩小后的范围内做效率高得多。5.2 用重传和窗口统计交叉确认信令字段对不代表结论对把用户面中断和信令流程对到同一个时间窗口才是闭环。tshark 一条命令出统计tshark -r out.pcap -q -z io,stat,3,s1ap,gtp-q 静默模式只出统计-z io,stat 按 3 秒窗口输出 S1AP 和 GTP 的包量。看丢点窗口与 GTP 中断是否重合再检查该窗口里数据面的重传统计如果信令正常、数据面重传却成堆问题往往是空口条件轻易不要归到核心网。5.3 把每个字段反查回配置表最后一步也是外场报告能否被采纳的关键把抓包里读到的 EARFCN、band、t304、EMM Cause 逐项和现网配置表核对一遍。抓包只告诉你发生了 A不告诉你 A 应不应该发生只有配上配置表才能从发生了重配超时推进到t304 配置比邻区平均切换时延短了 40%。核对一致后再改参数复测时用同一条过滤条件重新抓包对比 t304 与切换完成时间是否落回预期区间。本文还有配套的精品资源点击获取 LTE抓包分析实战：从QXDM日志到Wireshark信令定位
简介《LTE 抓包分析指导手册》是一份面向通信网络工程师与优化维护人员的实战文档重点解决LTE网络数据包捕获与分析中的实际难题。手册系统介绍了UU口、eNodeB和核心网三类场景的抓包准备工作与操作流程既包含测试电脑和安卓手机的UU口抓包方法也覆盖基站侧专用工具的配置要点。数据分析部分详细讲解了单个业务线程过滤、丢包与乱序分析、IO Graphs可视化应用以及无线侧BLER与丢包联合分析方法便于读者定位网络拥塞、时序紊乱或空口异常。资源以单个PDF文档呈现大小约1.72MB目录结构清晰总计1个文件。目前已有293人学习浏览适合需要快速掌握LTE信令抓包与分析思路的现场维护、网优及测试人员参考。1. LTE 抓包分析不是事后补救外场问题定位的第一现场外场测试最尴尬的场面是用户在电梯口刷不出视频测试手机却显示 LTE 信号满格。空口指标全绿问题到底出在接入、承载还是内容侧现场谁都不敢拍板唯一能当客观依据的就是抓包文件。LTE 抓包分析要做的就是把 Uu 口与 S1 口的信令按时间线还原让一次业务从终端到核心网的每一步都变成可判读的字段。这套思路的核心不是工具而是在哪一层抓、抓完解什么、解完看什么。把三点捋顺外场测试、协议栈开发和网优排查遇到信号正常但业务失败的场景就能用同一套方法收敛。下面按数据源、解析、场景和验证往下走。2. LTE 抓包的数据源选型终端侧日志与网络侧镜像怎么配抓包的第一步不是打开某个工具而是先回答一个问题这一包数据要为哪个结论服务。定位 Attach 失败需要 NAS 消息定位速率问题需要 PDCP 和 RLC定位核心网响应慢则需要 S1 口数据。数据源选错分析做得越细越偏离现场所以先花几分钟把终端侧和网络侧两套抓法讲清。2.1 高通平台最小抓包配置QXDM 日志组与文件管理外场测试里高通平台测试机用 QXDM 抓空口信令是默认动作。连接前先确认驱动把手机识别为 Qualcomm HS-USB Diagnostics 端口否则 QXDM 的设备列表里什么都不会出现。连上之后不要贪全在 Options → Log Packet Configuration 里按层勾选RRC 和 NASEMM/ESM覆盖接入、鉴权、注册这类移动性问题涉及速率和时延再补 PDCP 的按序递交和 RLC 的 ARQ 统计。MAC 层调度日志一开就是每秒几百 MB 的写入外场笔记本的磁盘多半扛不住我一般只在外场复测调度类问题时才开。日志落盘建议打开 Save to file按 200MB 一个文件轮转、最多保留 5 个。连续跑一天既有完整记录又不会撑爆磁盘很多故障恰好发生在终端重启前的最后几秒手动停止存储会恰好丢掉这段。保存成 .hdf 还是 .isf 不影响后续分析关键是别在测试过程中反复开关日志外场抓包最怕的就是看起来在抓其实没写盘。2.2 S1 口镜像抓包tcpdump 抓 S1AP 与 GTP-U 的最小命令终端侧日志只反映手机自己的视角判断问题是否在核心网时需要 S1 口数据。S1-MME 用 SCTP 承载 S1AP常见监听端口是 36412用户面 S1-U 是 UDP 2152 上的 GTP-U。网络侧常见做法是把这两个口镜像到专用抓包机一条 tcpdump 同时收sudo tcpdump -i eth0 -s 0 -w /data/s1_$(date %Y%m%d_%H%M).pcap \ sctp port 36412 or (udp port 2152)-s 0 表示抓全包SCTP 和 GTP 都是可变长承载截断后 Wireshark 连 S1AP 的边界都找不对这是新手最容易踩的坑-w 指定输出文件过滤表达式把控制面 SCTP 和数据面 UDP 两个端口用 or 连起来。需要长时间挂机时加 -C 200 -W 10 让 tcpdump 按 200MB 轮转并最多保留 10 个文件。镜像口流量大时 tcpdump 可能丢包加 -B 4096 把内核抓包缓冲提到 4MB结束时会打印丢包统计先确认没丢包再谈信令缺失。提示上外场前先在办公室验证镜像口通不通、端口是不是 36412。很多现场 S1AP 走私有端口抓回来一堆 SCTP DATA 却解不出 S1AP不是数据没抓到是没告诉 Wireshark 怎么解。2.3 手机、lte 无线路由器与网络侧的抓包差异同样是LTE 抓包手机、lte 无线路由器CPE和 eNodeB 镜像口三处的可行方案差别很大。CPE 上没有 QXDM 那种空口全量日志方案商通常只给工程模式 AT 命令高通方案常见 ATQENG 查询服务小区和电平想看空口信令得依赖方案商的私有日志工具支持到哪一层是不确定的。所以遇到 CPE 类设备通用做法是把 S1 口抓包当主证据、AT 命令输出当辅助不要指望复现手机侧那种完整协议栈。抓包位置常用工具能覆盖的范围主要限制手机外场测试QXDM QCAT / MTK CatcherRRC、NAS、PDCP、RLC 全栈需要测试机授权日志量大LTE 无线路由器/CPE方案商日志 工程模式 AT 命令小区参数、少量 NAS 事件空口信令基本不可见eNodeB S1 镜像口tcpdump / tshark WiresharkS1AP、透传 NAS、GTP-U需要网管配合Uu 口是盲区选型结论很直接外场复现手机问题以 QXDM 终端日志为主设备侧或核心网侧问题以 S1 镜像为主CPE 场景接受网络侧证据加射频指示的折中。数据源定了下一步才轮到 Wireshark 怎么把原始日志变成可读信令。3. 用 Wireshark 做 LTE 信令抓包与解析日志转换、解码偏好与过滤语法原始日志几乎不能直接拖进 WiresharkQXDM 的 .isf/.hdf 是私有格式S1 镜像抓回来的 SCTP 也要先告诉 Wireshark 按 S1AP 解。这一章把从原始日志到可判读信令的三步处理讲清楚转换格式、设置解码偏好、用过滤语法锁定目标消息。3.1 日志转 pcapQCAT 导出与时间基准确认QXDM 保存的 .isf/.hdf 用配套的 QCAT高通协议分析工具打开选中 LTE 相关记录导出为 pcap 或 pcapngMTK 平台则是 Catcher/工程日志导出界面不同但出口一致。导出后先做两件事确认时间戳是设备本地时间还是 GPS 授时这决定了后面能不能和 S1 抓包做时间对齐确认转出的包有没有带 RLC/MAC 头带头的能做调度和重传统计不带头的只能看 RRC/NAS 内容。这里有个关键差异值得单独说终端侧 QXDM 是在协议栈内部取日志RRC 和 NAS 是加解密之前的内容所以空口开了加密也能读明文。S1 口抓包里的 NAS-PDU 是被 NAS 密钥加密后的容器没有密钥就只能看哪条流程、哪个步骤看不到里面字段。因此做跨接口对比时NAS 字段以终端侧为准S1 侧用来核对交互时序和核心网响应行为。3.2 解码偏好设置让 S1AP、NAS 和 RRC 字段都显示出来把 pcap 拖进 Wireshark 后最常遇到三种显示不出来。第一种是 SCTP 端口不是默认值导致 S1AP 不被识别在 Analyze → Decode As 里把对应 SCTP 端口强制解为 S1AP。第二种是 RRC 信令在空口被 RLC 分段传输转出时没有重组NAS 部分显示为残缺数据在 Preferences → Protocols → LTE RRC 里打开重组选项即可。第三种是时间显示问题把 View → Time Display Format 切成 Seconds Since Previous Displayed Packet逐条看间隔比看绝对时间更能快速定位异常等待。注意Wireshark 版本差异主要影响 RRC 字段前缀新版用 lte_rrc老版本叫 rrc。换电脑分析时字段不一致先检查版本再怀疑数据。3.3 NAS 消息类型速查与过滤语法定位一次失败NAS 层是 LTE 移动性分析的入口每条 EMM 消息都有固定消息类型值记住几个常用的比每次翻规范快得多NAS 消息msg_type典型用途Attach Request0x41开机注册起点Attach Reject0x44注册失败带 EMM CauseDetach Request0x45去注册或关机TAU Request0x48跨 TA 更新、周期性更新Authentication Request0x52鉴权流程起点Security Mode Command0x5DNAS/AS 安全激活过滤语法直接对应 Wireshark 的显示过滤栏tshark -r attach.pcap -Y nas-eps.msg_type 0x41 \ -T fields -e frame.number -e frame.time -e nas-eps.msg_type | head-Y 指定显示过滤和 Wireshark 顶部过滤栏是同一套语法-T fields -e 指定按列输出。把 0x41 换成 0x44再补一个 -e nas-eps.emm.cause就能把整段日志里所有 Attach Reject 及其拒绝原因一次性列出来。空口侧 RRC 同理用 lte_rrc.RRCConnectionSetup、lte_rrc.RRCConnectionReconfiguration 过滤对应消息在消息上右键 Apply as Filter 可以自动生成合法字段比手敲稳妥。4. 三个高频场景的 LTE 抓包分析Attach、切换与 TAU 的时间线还原有了能读的数据和过滤手段分析就要落到具体流程。外场和现网优化里八成的问题集中在 Attach 失败、切换异常和 TAU/寻呼三类场景。下面按先找起点、再找终点、最后对参数的顺序逐一展开。4.1 Attach 失败从 Attach Request 到 EMM Cause 的判读一次成功的 Attach 至少包含 RRC 建立、Attach Request、鉴权/安全、Attach Accept、Activate Default Bearer、Attach Complete 六个环节。失败定位的三步是在终端侧日志里找第一条 Attach Request 的时间找对应的 Reject 或超时点出现 Reject 就立刻看 EMM Cause。用 tshark 一步拿到所有拒绝tshark -r attach.pcap -Y nas-eps.msg_type 0x44 \ -T fields -e frame.time -e nas-eps.emm.causeEMM Cause 必须对照 3GPP TS 24.301 的编号表判读凭经验猜最容易出错。外场里高频的有下面几种EMM Cause含义排查方向#2IMSI unknown in HSS签约数据、开户状态#6Illegal MEIMEI 黑名单或鉴权失败#7EPS services not allowed数据业务未签约#12Tracking area not allowedTAC/TA list 配置#22Congestion核心网过载、节流#35Requested service option not subscribed套餐与 APN 不匹配超时类失败没有 cause 可看只能看间隔RRC 建立完成 10 秒内 NAS 层无响应优先怀疑空口覆盖边缘或核心网处理不过来3 秒内就被回拒则基本是配置和签约层面的问题。这个先分超时还是被拒的习惯能把一半的排查时间省掉。4.2 切换异常RRCConnectionReconfiguration 与 lte band 核对切换是外场测试里占比最高的场景抓包里的关键信令是带 mobilityControlInfo 的 RRCConnectionReconfiguration。收到这条消息后终端要完成到目标小区的随机接入并回 Reconfiguration Complete。判读时我一般看三个字段targetPhysCellId 确认目标小区是否和邻区表中的 PCI 一致carrierFreq 即 EARFCN按 3GPP TS 36.101 的表换算成 lte band异频切换里最常见的问题就是目标频点被配成了终端能力之外的 bandt304 定时器配得太短时切换执行稍慢就会触发 RLF抓包里的表现是配了 t304 之后没等到 Complete 就出现无线链路失败。另一种常见现场是信号满格但不切换。抓包里通常连着好几条 measurement report却迟迟没有 Reconfiguration这时候要回头看 measConfig 里有没有把目标小区的频点和 band 加进测量对象。抓包只会告诉你测量报告上没上报要解释为什么没上报得把测量配置和邻区表拿过来对着看。4.3 TAU 与寻呼多接口时间戳对齐的通用做法TAU 和寻呼问题往往要终端侧与 S1 侧拼接时间线多接口对齐这件事做不好所有后续判断都是猜的。通用做法是拿同一条 NAS 消息在两个文件里的到达时刻做差把其中一个整体平移再逐条比对时序。两侧时间源一致抓包机 NTP、终端 GPS 授时是前提小脚本直接算偏移# 计算同一个 Attach Request 在终端侧与 S1 侧抓包中的到达时刻差 import subprocess def first_msg_time(pcap, msg_type): out subprocess.check_output( [tshark, -r, pcap, -Y, fnas-eps.msg_type {msg_type}, -T, fields, -e, frame.time_epoch], textTrue) return float(out.splitlines()[0].split(\t)[0]) ue_t first_msg_time(ue.pcap, 0x41) s1_t first_msg_time(s1.pcap, 0x41) print(f偏移: {ue_t - s1_t:.3f}s S1时间 UE时间 {ue_t - s1_t:.3f}s)脚本逻辑是分别取两个 pcap 里第一条 Attach Request 的绝对时间戳做差。算出来的偏移若在整段测试里基本稳定就按这个值统一换算如果每条都会漂移说明某个时间源失锁先把时钟问题解决掉再继续。寻呼问题里重点核对 S1AP 寻呼消息的到达时间和终端侧 Paging 的接收时间两者相差过大时先查 eNB 到 MME 的链路质量而不要直接怀疑发射功率。5. 让 LTE 抓包结论站得住的三个验证技巧抓包分析最容易犯的错是一眼定罪看到某个 cause 或某个字段异常就急于下结论。后面三步是我每次出报告前都会过的检查比多翻十层字段更管用。5.1 先看时间差再看字段把时间显示切成 Seconds Since Previous Displayed Packet按顺序扫一遍同一条流程内相邻消息的间隔。RRC 请求发出去超过 1 秒才收到响应多数是上行覆盖或功控问题NAS 请求到响应正常、但后续承载激活中断才是核心网侧问题。时间差先把嫌疑范围缩小字段核对只在缩小后的范围内做效率高得多。5.2 用重传和窗口统计交叉确认信令字段对不代表结论对把用户面中断和信令流程对到同一个时间窗口才是闭环。tshark 一条命令出统计tshark -r out.pcap -q -z io,stat,3,s1ap,gtp-q 静默模式只出统计-z io,stat 按 3 秒窗口输出 S1AP 和 GTP 的包量。看丢点窗口与 GTP 中断是否重合再检查该窗口里数据面的重传统计如果信令正常、数据面重传却成堆问题往往是空口条件轻易不要归到核心网。5.3 把每个字段反查回配置表最后一步也是外场报告能否被采纳的关键把抓包里读到的 EARFCN、band、t304、EMM Cause 逐项和现网配置表核对一遍。抓包只告诉你发生了 A不告诉你 A 应不应该发生只有配上配置表才能从发生了重配超时推进到t304 配置比邻区平均切换时延短了 40%。核对一致后再改参数复测时用同一条过滤条件重新抓包对比 t304 与切换完成时间是否落回预期区间。本文还有配套的精品资源点击获取