LTE NAS信令详解：空口抓包、Attach流程与核心网交互实战

简介LTE-L3-NAS-信令详解.ppt 是一份面向移动通信工程师、网优人员及通信专业学生的技术文档聚焦 LTE 网络中用户设备与 MME 之间的非接入层控制信息传输帮助读者理清 Attach、Detach、Tracking Area Update、Handover 与 CSFB 等关键流程的信令交互逻辑。资源包内仅含 1 个 ppt 文件整体约 2.31MB以幻灯片形式组织内容便于按主题逐页讲解与演示。文档结合 RRC Connection Request、RRC Connection Setup 等实际信令消息逐项拆解 ue-Identity、establishmentCause、rrc-TransactionIdentifier、radioResourceConfigDedicated 等参数含义并延伸至 SRB 配置、RLC 与 MAC 层参数、上行同步控制等细节适合用于协议学习、信令分析入门与问题排查参考。目前已有 333 人学习可作为 LTE 信令体系梳理的实用资料。1. LTE-L3-NAS-信令详解从空口抓包到核心网交互的完整链路做 LTE 网络优化或者终端协议栈开发的工程师迟早会撞上 NAS 信令这个黑匣子。你打开一份 LTE-L3-NAS-信令详解的 PPT看到的是 Attach Request、Authentication Request、Security Mode Command 这些消息名但真正让你头疼的是这些消息在空口上怎么抓、怎么解码、怎么和核心网侧的信令流程对上。LTE 的 NAS 层位于 UE 和 MME 之间它不经过 eNodeB 解析而是作为透明传输的容器穿过整个无线接入网。这意味着你在 eNodeB 侧抓到的 NAS 消息是加密的只有拿到密钥才能在 UE 或 MME 侧解开。这篇文章不讲教科书上的协议栈分层图而是从实操角度拆解怎么用 QXDM 或 Wireshark 抓到可读的 NAS 信令、TAC 和 CellID 在 Attach 流程中怎么关联、EPS Mobility Management 和 EPS Session Management 两条状态机怎么配合、以及当你看到 Attach Reject 时该从哪几个 Cause Code 入手排查。适合做 LTE 终端测试、核心网对接、以及需要定位入网失败问题的工程师。2. NAS 信令在 LTE 协议栈中的位置与承载方式2.1 NAS 消息如何穿过 eNodeB 到达 MMELTE 协议栈分两层AS 层和 NAS 层。AS 层包括 RRC、PDCP、RLC、MAC、PHY终结在 eNodeBNAS 层包括 EMM 和 ESM终结在 MME。UE 发出的 NAS 消息先封装在 RRC 消息里通过 SRB1 或 SRB2 承载eNodeB 收到后把 NAS PDU 从 RRC 中提取出来再封装进 S1AP 的 Initial UE Message 或 Uplink NAS Transport 消息通过 S1 接口发给 MME。反过来MME 下发的 NAS 消息通过 S1AP 的 Downlink NAS Transport 到达 eNodeB再被塞进 RRC DL Information Transfer 或 RRC Connection Reconfiguration 里发给 UE。这个过程中eNodeB 对 NAS 内容是不可见的。它只看 S1AP 的 Header不解析 NAS PDU 的内部结构。所以如果你在 eNodeB 侧用 S1 抓包工具看到的 NAS 消息是十六进制裸流需要 MME 侧的解码工具才能还原。常见做法是在 UE 侧用 QXDM 或 QCAT 抓取空口日志或者在 MME 侧用 Wireshark 配合 S1AP 解析插件。两者抓到的 NAS 消息内容一致但 UE 侧能看到加密前的明文MME 侧看到的是解密后的明文中间空口传输的是加密后的密文。注意如果你在 eNodeB 的 S1 接口抓包NAS PDU 字段是加密的除非你有 MME 的密钥否则无法直接解码。不要浪费时间在 eNodeB 侧尝试解密 NAS。2.2 EMM 与 ESM 两条状态机的分工NAS 层内部拆成两个子层EMM 和 ESM。EMM 管的是移动性管理包括 Attach、Detach、TAU、Service Request、Authentication、Security Mode 这些流程。ESM 管的是会话管理包括 PDN 连接建立、承载激活、QoS 修改、去激活。两条状态机独立运行但 ESM 的消息必须通过 EMM 建立的 NAS 信令连接才能传输。EMM 的状态分三种EMM-DEREGISTERED、EMM-REGISTERED-INITIATED、EMM-REGISTERED。UE 开机后从 DEREGISTERED 开始发起 Attach Request 后进入 REGISTERED-INITIATED收到 Attach Accept 后进入 REGISTERED。ESM 的状态分两种ESM-INACTIVE 和 ESM-ACTIVE。当 UE 发起 PDN Connectivity Request 并收到 Activate Default EPS Bearer Context Accept 后ESM 进入 ACTIVE。实操中你会在 QXDM 的 NAS 消息视图里看到这两条状态机的消息交替出现。一个典型的 Attach 流程里EMM 消息和 ESM 消息的先后顺序是Attach Request (EMM) → Authentication Request/Response (EMM) → Security Mode Command/Complete (EMM) → Attach Accept (EMM) → Activate Default EPS Bearer Context Request (ESM) → Activate Default EPS Bearer Context Accept (ESM) → Attach Complete (EMM)。如果你看到 Attach Accept 之后没有 ESM 消息说明 PDN 连接建立失败需要检查 APN 配置或核心网侧的策略。2.3 用 QXDM 抓取 NAS 信令的最小操作步骤下面是一套我常用的 QXDM 配置流程适用于高通芯片的测试终端。不同版本的 QXDM 菜单略有差异但核心逻辑一致。# 步骤 1连接设备并确认端口 # 在 QXDM 中点击 Connect选择目标设备的 DIAG 端口 # 确认端口号通常为 COMx 或 /dev/ttyUSBx # 步骤 2加载 LTE NAS 的过滤配置 # 在 View - Filter 中勾选 LTE NAS 相关项 # 具体路径LTE - NAS - EMM / ESM # 步骤 3设置日志保存路径 # File - Save Items选择保存为 .isf 或 .dlf 格式 # 建议同时保存原始日志和解析后的文本 # 步骤 4触发 Attach 流程 # 飞行模式开关一次或重启终端 # 观察 NAS 消息窗口是否出现 Attach Request # 步骤 5导出 NAS 消息 # 右键 NAS 消息窗口 - Export - 选择 CSV 或 TXT这段操作的核心是过滤器的设置。QXDM 默认会抓取所有层级的消息如果不加过滤NAS 消息会被淹没在 RRC 和 PHY 的日志里。设置过滤后你只看到 EMM 和 ESM 的消息每条消息会显示方向UL/DL、消息类型、关键 IE。导出时建议选 CSV方便后续用脚本做批量分析。参数说明DIAG 端口的选择取决于终端类型。高通芯片通常用 DIAG 口MTK 芯片用 MD 口。如果你用的是工程机可能需要先解锁 DIAG 权限。日志格式选 .dlf 可以保留原始二进制方便用 QCAT 做二次解析选 .isf 则直接是文本格式可读性更好但会丢失部分底层信息。3. Attach 流程中信令交互的逐条拆解与参数解读3.1 Attach Request 里必须关注的五个 IEAttach Request 是 UE 入网的第一条 NAS 消息它携带的信息决定了后续流程的走向。在 QXDM 里展开这条消息你会看到十几个 IE但以下五个是排查问题的关键。第一个是 EPS Attach Type。取值有 EPS attach、combined EPS/IMSI attach、EPS emergency attach。如果你看到 combined attach说明 UE 同时要注册 CS 域这时候如果 MME 不支持 combined attach会回 Attach Reject 带 Cause Code #22Combined attach not supported。第二个是 EPS Mobile Identity通常是 IMSI 或 GUTI。如果 UE 之前注册过会用 GUTI 来减少 IMSI 暴露如果 GUTI 无效MME 会发起 Identity Request 要 IMSI。第三个是 UE Network Capability里面包含加密算法和完整性保护算法的支持列表。如果 UE 只支持 EEA0空加密而 MME 策略要求 EEA2就会在 Security Mode 阶段失败。第四个是 DRX Parameter影响寻呼周期。第五个是 TAITracking Area Identity包含 TAC 和 PLMN。如果 TAC 不在 MME 的 TA List 里MME 会回 Attach Reject 带 Cause Code #12Tracking area not allowed。# 用 pyshark 解析 NAS 消息的示例 import pyshark # 加载 S1AP 抓包文件 cap pyshark.FileCapture(s1ap_capture.pcap, display_filters1ap) for pkt in cap: if hasattr(pkt, s1ap): # 提取 NAS PDU if hasattr(pkt.s1ap, nas_pdu): nas_pdu pkt.s1ap.nas_pdu # 解析 NAS 消息类型 # 第一个字节的低 4 位是 EPS Mobility Management 的消息类型 msg_type int(nas_pdu[:2], 16) 0x0F if msg_type 0x01: print(fAttach Request: {nas_pdu}) elif msg_type 0x02: print(fAttach Accept: {nas_pdu}) elif msg_type 0x03: print(fAttach Complete: {nas_pdu}) elif msg_type 0x04: print(fAttach Reject: {nas_pdu})这段代码的逻辑是从 S1AP 抓包中提取 NAS PDU 字段然后根据 NAS 消息的第一个字节判断消息类型。EMM 消息类型的编码规则是0x01 是 Attach Request0x02 是 Attach Accept0x03 是 Attach Complete0x04 是 Attach Reject。ESM 消息类型从 0xC1 开始0xC1 是 PDN Connectivity Request0xC2 是 Activate Default EPS Bearer Context Request。参数说明display_filter 设为 s1ap 可以过滤掉无关报文nas_pdu 字段是十六进制字符串需要转成整数再取低四位。这个脚本适合快速统计一次 Attach 流程里各消息的出现次数和顺序。3.2 Authentication 与 Security Mode 的密钥推导链路Authentication Request 携带 RAND 和 AUTNUE 用 USIM 卡里的 Ki 和 OPc 计算出 RES、CK、IK。UE 回 Authentication Response 带 RESMME 比对 RES 和 XRES一致则认证通过。接下来 MME 发起 Security Mode Command携带选定的加密算法和完整性保护算法以及 KASME 推导出的 KNASenc 和 KNASint。UE 回 Security Mode Complete之后所有 NAS 消息都用 KNASenc 加密、KNASint 做完整性保护。实操中常见的翻车点是Security Mode Command 里的算法 UE 不支持。比如 MME 选了 EEA2128-bit AES但 UE 只支持 EEA0 和 EEA1。这时候 UE 会回 Security Mode RejectCause Code 是 #23UE security capabilities mismatch。解决方法是检查 UE 的 Network Capability IE确认支持的算法列表然后在 MME 侧调整算法优先级。另一个坑是 NAS 计数器不同步。UE 和 MME 各自维护上行和下行 NAS COUNT每发一条 NAS 消息计数器加一。如果 UE 侧复位了计数器但 MME 没复位MME 会丢弃后续消息表现为 UE 反复重发同一条 NAS 消息但收不到响应。这时候需要抓取 UE 和 MME 两侧的 NAS COUNT对比是否一致。QXDM 里可以在 NAS 消息的 Security Header 里看到 COUNT 值。3.3 Attach Accept 与 Activate Default EPS Bearer 的关联Attach Accept 是 EMM 层的消息它表示 UE 已经注册成功。但真正让 UE 能上网的是 ESM 层的 Activate Default EPS Bearer Context Request。这两条消息通常一起下发Attach Accept 里会带 Activate Default EPS Bearer Context Request 的 NAS PDU。如果你在 QXDM 里只看到 Attach Accept 没看到 ESM 消息可能是 MME 没有下发 PDN 连接或者 UE 的 APN 配置和 MME 不匹配。Attach Accept 里的关键 IE 包括EPS Attach Result通常为 EPS only、TAI ListUE 需要更新的 TAC 列表、ESM Message Container里面封装了 Activate Default EPS Bearer Context Request。ESM 消息里的关键 IE 包括EPS Bearer Identity、APN、PDN AddressUE 分配的 IP、EPS QoS。如果 PDN Address 是 0.0.0.0说明 IP 分配失败需要检查 MME 的 IP 池配置或 DHCP 服务器状态。# 用 tshark 过滤 Attach Accept 并导出关键字段 tshark -r s1ap_capture.pcap -Y s1ap.nas_pdu -T fields \ -e frame.number \ -e s1ap.nas_pdu \ -e _ws.col.Info \ | grep -i attach accept # 输出示例 # 15 0x0742010b... Attach Accept # 其中 0x07 是 EPS Attach Result0x42 是 TAI List 长度这段命令的作用是从抓包文件里提取所有 NAS PDU然后过滤出 Attach Accept 消息。参数说明-Y 是显示过滤器s1ap.nas_pdu 表示只显示带 NAS PDU 的报文-T fields 指定输出字段-e 指定字段名。输出结果里NAS PDU 的十六进制字符串需要对照 3GPP TS 24.301 的 IE 编码表来解读。比如 0x07 表示 EPS Attach Result 是 EPS only0x42 表示 TAI List 的长度和类型。4. TAU、Service Request 与去附着流程的实操差异4.1 TAU 流程里 TAC 变更的触发条件TAUTracking Area Update是 UE 在移动过程中更新位置的过程。触发 TAU 的条件有几种UE 进入新的 TAC 且该 TAC 不在 MME 下发的 TAI List 里周期性 TAU 定时器超时UE 从空闲态转到连接态时发现 TAI 变化。TAU Request 里的关键 IE 是 EPS Update Type取值有 TA updating、combined TA/LA updating、periodic updating。实操中你会遇到 TAU Request 被拒的情况。如果 Cause Code 是 #12Tracking area not allowed说明目标 TAC 不在 MME 的允许列表里。这时候需要检查 MME 的 TA List 配置确认目标 TAC 是否已经添加。如果 Cause Code 是 #9UE identity cannot be derived by the network说明 GUTI 无效且 MME 无法推导 IMSI需要 UE 重新发起 Attach。另一个常见问题是 TAU 过程中 TAC 和 CellID 的映射关系。在 S1AP 的 Handover 流程里源 eNodeB 和目标 eNodeB 的 TAC 可能不同。如果目标 TAC 不在 TAI List 里UE 会在切换完成后发起 TAU。这时候你会在 QXDM 里看到 Handover Complete 之后紧跟 TAU Request。如果 TAU 失败UE 会回退到源小区或重新 Attach。4.2 Service Request 与寻呼的配合Service Request 是 UE 从空闲态转到连接态时发的 NAS 消息。它有两种触发方式UE 主动发起比如要发数据或者响应 MME 的寻呼。Service Request 里的关键 IE 是 Service Type取值有 mobile originating calls、mobile terminating calls、emergency calls、high priority access。如果 Service Type 是 mobile terminating calls说明 UE 是在响应寻呼。实操中常见的问题是寻呼丢失。MME 下发 Paging 消息eNodeB 在空口广播但 UE 没收到。原因可能是 DRX 周期不匹配、TAC 不匹配、或者 UE 处于异常状态。排查方法是在 QXDM 里看 UE 的 DRX Parameter 和 MME 下发的 Paging 消息里的 DRX 是否一致检查 UE 当前注册的 TAC 和 Paging 消息里的 TAC 是否一致。如果 UE 刚做完 TAUTAC 可能还没更新到 MME导致 Paging 发到了旧的 TAC。4.3 Detach 流程的两种发起方式与 Cause CodeDetach 分两种UE 主动发起和 MME 主动发起。UE 主动 Detach 时Detach Request 里的 Detach Type 是 UE initiated。MME 主动 Detach 时Detach Request 的 Detach Type 是 MME initiated通常带 Cause Code比如 #2IMSI unknown in HSS、#3Illegal UE、#8EPS services and non-EPS services not allowed。实操中如果看到 MME 主动 Detach 带 Cause Code #2说明 HSS 里没有这个 IMSI 的签约数据。需要检查 HSS 的用户配置确认 IMSI 已经开通 LTE 权限。如果 Cause Code 是 #15No suitable cells in tracking area说明 UE 当前所在的 TAC 没有可用的 PDN 连接需要检查 MME 的 TA List 和 PGW 的配置。# 统计 Detach 消息的 Cause Code 分布 import pyshark from collections import Counter cause_codes Counter() cap pyshark.FileCapture(s1ap_capture.pcap, display_filters1ap.nas_pdu) for pkt in cap: if hasattr(pkt.s1ap, nas_pdu): nas_pdu pkt.s1ap.nas_pdu msg_type int(nas_pdu[:2], 16) 0x0F if msg_type 0x05: # Detach Request # Cause Code 通常在 NAS PDU 的特定偏移位置 # 具体偏移取决于消息结构这里假设在最后两个字节 cause_code int(nas_pdu[-2:], 16) cause_codes[cause_code] 1 print(cause_codes.most_common())这段代码的逻辑是遍历抓包文件找到 Detach Request 消息提取 Cause Code 并统计分布。参数说明msg_type 0x05 对应 Detach RequestCause Code 的偏移位置需要根据实际消息结构确定不同厂商的 NAS PDU 编码可能略有差异。这个统计可以帮助你快速判断当前网络里 Detach 的主要原因比如是 HSS 配置问题还是 TA List 问题。5. NAS 信令排查中的五个血泪坑5.1 坑一QXDM 抓不到 NAS 消息只看到 RRC现象QXDM 连接正常RRC 消息能看到但 NAS 消息窗口一片空白。原因QXDM 的 NAS 过滤没有打开或者终端没有上报 NAS 层日志。部分商用终端默认关闭 NAS 日志上报需要刷工程固件或解锁 DIAG 权限。解决在 QXDM 的 Filter 里勾选 LTE NAS 的所有子项如果还是不行检查终端的 DIAG 配置确认 NAS 日志开关已打开。高通芯片可以用 QPST 里的 DIAG 配置工具修改日志掩码。5.2 坑二Attach Reject 的 Cause Code 看不懂现象UE 反复发起 Attach Request每次都被 Attach Reject但 Cause Code 是陌生的数字。原因3GPP TS 24.301 里定义的 Cause Code 有几十个不同版本还有差异。常见的 #2、#3、#12、#15、#22 之外还有一些厂商私有扩展。解决对照 3GPP TS 24.301 的 Annex A 查表。如果 Cause Code 是 #22Combined attach not supported说明 UE 发了 combined attach 但 MME 不支持需要把 UE 的 Attach Type 改成 EPS only。如果是 #15No suitable cells in tracking area检查 TAC 和 TA List 的匹配关系。5.3 坑三Security Mode 之后 NAS 消息变成乱码现象Security Mode Complete 之后QXDM 里的 NAS 消息显示为加密的十六进制无法解析。原因这是正常现象。Security Mode 之后所有 NAS 消息都用 KNASenc 加密QXDM 如果没有密钥就无法解密。但 QXDM 通常能从终端拿到密钥如果拿不到说明终端的密钥上报接口没打开。解决在 QXDM 的配置里打开 NAS 解密选项或者用 QCAT 配合终端的密钥日志做离线解密。如果终端不支持密钥上报只能在 MME 侧抓包看明文。5.4 坑四TAU 过程中 TAC 和 CellID 对不上现象UE 发起 TAUTAU Request 里的 TAC 和当前服务小区的 TAC 不一致。原因UE 可能读到了邻区的 TAC或者 eNodeB 的 SIB1 里广播的 TAC 和 MME 配置的 TAC 不一致。解决在 QXDM 里查看当前服务小区的 SIB1确认 TAC 值同时在 MME 侧检查 TA List 配置。如果 eNodeB 和 MME 的 TAC 配置不一致需要统一配置。5.5 坑五Service Request 发出后没有响应现象UE 发 Service Request但收不到 Service Accept 或 Service RejectUE 反复重发。原因可能是 NAS COUNT 不同步MME 丢弃了消息或者 eNodeB 的 SRB 资源不足消息没发出去。解决检查 UE 和 MME 的 NAS COUNT 是否一致在 eNodeB 侧查看 SRB1/SRB2 的占用情况。如果是 COUNT 不同步需要复位 UE 和 MME 的 NAS 层。6. 用 Wireshark 做 NAS 信令的离线深度分析6.1 配置 Wireshark 解析 S1AP 里的 NAS PDUWireshark 默认能解析 S1AP但 NAS PDU 需要额外配置。在 Wireshark 的 Preferences 里找到 Protocols - S1AP确认 NAS PDU 的解析开关已打开。如果 NAS PDU 显示为十六进制而不是解码后的消息说明 Wireshark 没有加载 NAS 解码器。这时候需要检查 3GPP TS 24.301 的解析插件是否安装。# 用 tshark 导出 NAS 消息并解码 tshark -r s1ap_capture.pcap -Y s1ap.nas_pdu -T fields \ -e frame.number \ -e s1ap.nas_pdu \ -e _ws.col.Info \ nas_messages.txt # 统计各类型 NAS 消息的数量 tshark -r s1ap_capture.pcap -Y s1ap.nas_pdu -T fields \ -e _ws.col.Info | sort | uniq -c | sort -rn这段命令的作用是导出所有 NAS 消息并统计类型分布。参数说明-Y 是显示过滤器-T fields 指定输出字段_ws.col.Info 是 Wireshark 解析后的消息摘要。输出结果里你可以看到 Attach Request、Attach Accept、TAU Request 等消息的出现次数。如果某条消息的数量异常多说明该流程可能有问题。6.2 用 tshark 统计 Attach 流程的时延Attach 流程的时延是衡量网络质量的重要指标。从 Attach Request 到 Attach Complete 的时间差反映了 UE 从入网到可用的总耗时。用 tshark 可以快速统计这个时延。# 提取 Attach Request 和 Attach Complete 的时间戳 tshark -r s1ap_capture.pcap -Y s1ap.nas_pdu -T fields \ -e frame.time_epoch \ -e _ws.col.Info \ | grep -E Attach Request|Attach Complete # 输出示例 # 1690000000.123 Attach Request # 1690000000.456 Attach Complete # 时延 0.456 - 0.123 0.333 秒这段命令的逻辑是提取每条 NAS 消息的时间戳和消息类型然后手动计算 Attach Request 和 Attach Complete 的时间差。参数说明frame.time_epoch 是 Unix 时间戳精度到毫秒。如果你要批量统计可以用 awk 或 python 脚本处理输出结果。一般来说Attach 时延在 200ms 到 500ms 之间算正常超过 1 秒说明核心网侧有延迟。6.3 用 Wireshark 的 Flow Graph 看信令交互顺序Wireshark 的 Flow Graph 功能可以把 NAS 消息的交互顺序画成时序图。在 Statistics - Flow Graph 里选择 Display Filter 为 s1ap.nas_pdu然后点 OK。你会看到 UE、eNodeB、MME 之间的消息流向。这个图比逐条看消息更直观能快速发现哪一步卡住了。我一般会先用 Flow Graph 看整体流程再用 tshark 统计时延最后用 QXDM 看 UE 侧的详细 IE。这三步配合下来大部分 NAS 信令问题都能定位到具体原因。希望帮到你。本文还有配套的精品资源点击获取