简介一份详解LTE L3层NAS信令的PPT课件主要面向LTE网络优化工程师、通信专业学生及协议开发人员旨在帮助读者系统理解UE与MME之间的控制面信令交互。内容聚焦Attach、Handover、CSFB、Tracking Area Update四大核心流程并结合RRC Connection Request/Setup的实际报文逐字段解析ue-Identity、establishmentCause、radioResourceConfigDedicated、SRB配置及MAC主配置等关键参数清晰呈现从RRC建立到NAS消息传递的完整链路。资源为单个PowerPoint文档类型为PPT压缩包体积约2.31MB共1个文件图文并茂适合直接阅读或二次编辑。目前已有333人学习下载可用于LTE信令入门、网络故障排查、考研复试或工程培训等场景。整体内容由浅入深既讲流程机制也拆解具体信令字段是兼顾理论与实操的参考资料。1. LTE 的 L3 层里RRC 只是入场券NAS 信令才是 MME 的官方语言抓 RRC 的用户经常看到一个现象手机在RRCConnectionSetupComplete里夹带一段DedicatedInfoNAS后面的调度、测量、切换全是无线侧的事这段“小字”才是终端真正要说给核心网的话。LTE 的 L3 层分接入层AS和非接入层NASRRC 负责把空口资源理顺NAS 信令负责和 MME 谈移动性、谈承载、谈认证。你要定位“附着失败、TAU 频繁、默认承载没建立、VoLTE 注册不上”这类问题把 NAS 信令按流程读对才是前提。这篇按一线排查习惯从协议栈定位、消息结构、主干流程到避坑点拆出一套能直接复用和复现的读法。2. NAS 在 L3 中的定位与消息封装从协议栈分工到字节级结构NAS 最容易被误解的一点是它虽然叫“层”但你在空口抓包里从来不会单独看到一条 NAS 消息。它被封装在 RRC 消息里面从 UE 穿过 eNB 再到 MME反过来MME 下发的 NAS 消息也是通过 eNB 用 RRC 容器转给手机。对 eNB 来说这段内容就是需要透传的黑匣子。理解这个运输关系比背一百个消息名都重要。2.1 协议栈分工RRC 管接入NAS 管移动性与会话在 LTE 控制面协议栈里RRC 位于 L3 的接入子层主要负责连接建立、测量配置、切换控制和系统消息下发NAS 同样属于 L3但它在 RRC 之上负责 UE 与 MME 之间的对话。RRC 解决“能不能连接到这个小区”NAS 解决“能不能使用这个网络”。两者分工可以这么记RRC 断了手机还能继续驻留NAS 出了问题手机可能已经在小区里待得好好的却既不能发起业务也收不到寻呼。实际开发排查中我一般先看 NAS 消息方向再往下查。上行 NAS 会出现在ULInformationTransfer、RRCConnectionSetupComplete或者专用控制信道里下行则装在DLInformationTransfer、RRCConnectionReconfiguration这些消息里。不要把 eNB 当成 NAS 的终点eNB 只是搬运工真正的处理方在核心网 MME。2.2 EMM 和 ESM为什么拆成两个子层NAS 内部又分成 EMMEPS 移动性管理和 ESMEPS 会话管理两个子层。EMM 管的是“我在哪里、我是否被网络承认”附着、去附着、TAU、认证、安全模式、服务请求都属于 EMMESM 管的是“我能用什么通道上网”默认承载建立、专用承载建立、承载修改与释放、PDN 连接管理都是 ESM。为什么一定要拆因为移动性管理和会话管理是两套生命周期。手机附着成功之后EMM 进入 EMM-REGISTERED 状态但此时如果默认承载没建立ESM 仍然处于 BEARER CONTEXT INACTIVE。反过来专用承载被网络释放不代表终端要整体掉线EMM 状态可以不受影响。把两层混在一起看很容易得出“承载释放等于断网”这种错误结论。排查时我的习惯是画两张状态机EMM 一张、ESM 一张不要合并。2.3 NAS 消息头前两个字节就能定位一条信令一条 NAS EPS 消息的最前面是必选头结构很固定第一字节的高半字节是安全头类型低半字节是协议鉴别符第二字节是消息类型。比如最常见的一条上行消息0x07 0x00 0x41低半字节0x7表示 EPS 移动性管理消息安全头类型0表示没有安全保护消息类型0x41是 Attach Request。安全头类型值得重点记0表示不保护1表示只做完整性保护2表示完整性和加密都做了3表示使用新安全上下文。如果某条 NAS 消息的第一字节变成0x17或者0x27说明这已经是安全模式命令之后的消息直接看第二字节是0x7E——这是“受保护 NAS 消息”的容器真正的内容是密文。很多新手在抓包里看到整段 16 进制却不认识它就是因为没意识到自己正在看安全后的消息。提示ESM 消息与 EMM 消息共用同一套头结构但协议鉴别符往往是2。如果你解析出来的第一条消息 PD 是 2直接按 ESM 消息类型去查表。2.4 用 Python 快速解析 NAS 消息头一份能直接改用的脚本空口抓包导出的经常是十六进制字符串第一版协议定位不需要完整解码把消息头拆出来就可以判断方向。下面是我常用的解析脚本#!/usr/bin/env python3 import binascii, sys EMM_MSG { 0x41: Attach request, 0x42: Attach accept, 0x43: Attach complete, 0x48: TAU request, 0x49: TAU accept, 0x4a: TAU complete, 0x4d: Service request, 0x52: Identity request, 0x53: Identity response, 0x56: Authentication request, 0x58: Authentication failure, 0x5d: Security mode command, 0x5e: Security mode complete, 0x7e: Protected NAS message, } def parse(hexstring): b binascii.unhexlify(hexstring.replace( , )) if len(b) 2: raise ValueError(NAS头至少需要2字节) first b[0] sec_hdr first 4 pd first 0x0f msg_type b[1] if pd 7: pd_name EPS mobility management elif pd 2: pd_name EPS session management else: pd_name other print(f安全头类型: {sec_hdr}) print(f协议鉴别符: {pd} ({pd_name})) print(f消息类型: 0x{msg_type:02X} {EMM_MSG.get(msg_type, 非EMM表内消息)}) if __name__ __main__: parse(sys.argv[1])这个脚本只解析头不解析后面的信息元素目的是快速判断“这是谁发给谁、干什么用的”。调用方式是python3 nas_header.py 070041输出里能直接看到消息名。如果你在日志里看到第二字节是0x7E脚本会提示这是受保护消息你需要回到安全模式命令那条消息去核对参数而不是继续硬解析密文。参数说明第一行的sys.argv[1]接收的是无空格十六进制串如果你从 Wireshark 粘贴带冒号或者空格的字节脚本里的replace( , )只能去掉空格建议手工把冒号替换掉再传。实际生产中我会再包一层文件读取把整个流程的 NAS 消息批量解码后按消息类型排序这比一条条复制快很多。3. 把一次 Attach 拆到底从 Attach Request 到默认承载建立EMM 和 ESM 怎么接力Attach 流程是 NAS 信令的骨架也是所有后续流程的基础。它表面上只有四五条消息实际每条消息里都叠着 EMM 和 ESM 两层信息尤其是第一条 Attach Request从它开始就要忍着“同时看两层”的冲动按外层 EMM、内层 ESM 的顺序拆。3.1 Attach Request 的关键信元IMSI 还是 GUTIAttach Type 和 ESM 容器UE 发 Attach Request 时身份标识字段有两种选择有可用的旧 GUTI 就用 GUTI没有就用 IMSI。实际抓包里两种都常见。首次开机、跨 PLMN、GUTI 被网络判为无效时终端会用 IMSI从之前附着过的小区回来则会携带旧 GUTI 让 MME 能去原 MME 拉取上下文。判断网络能不能识别这个身份看后续有没有Identity Request就行——网络认不出来就会主动向 UE 要身份。Attach Type 字段也要看常见的值是 EPS attach、combined EPS/IMSI attach、emergency attach。支持 CSFB 或者 VoLTE 的终端往往会选 combined attach在附着 EMM 的同时顺带把电路域位置更新一起做完。在商用网络里如果一句话概括“为什么这个手机能打电话却上不了网”多半就要回到这条路看 attach type 和订阅数据是否匹配。嵌套在这条消息里的 ESM 容器通常存放 PDN Connectivity Request里面带着 APN、PDN type、请求类型和 PCO 协议配置选项。注意这个 ESM 容器不是独立信令它只是 Attach Request 的一个信息元素但它的结果直接决定后续是继续走默认承载建立还是干脆来一段 Activate Default EPS Bearer Context Request。顺序上外层 EMM 先做身份确认内层 ESM 再讨论承载参数读完这条要分成两层去登记。3.2 认证与安全模式为什么流程会突然停在半路等网络发牌Attach Request 之后MME 不一定会直接回 Attach Accept中间经常插着两条安全相关流程。先看认证MME 向 HSS 要认证向量然后下发 Authentication Request里面带 RAND、AUTNUE 侧要校验 AUTN 的 MAC 是否和根密钥推演结果一致。校验失败时 UE 回 Authentication Failure并带上 AUTS 参数网络侧看到 AUTS 就要重新做再同步避免因为序列号不一致导致后续加密全部错位。认证通过后MME 下发 Security Mode Command选择完整性算法和加密算法同时带上 NAS-MAC 参数。这条消息很重要因为从它之后所有 NAS 消息都会进入保护状态也就是上一章说的安全头类型从 0 变成 1 或 2。你如果在跟进一个空口日志发现从这个时间点开始 NAS 全是密文不要慌那是正常的真正的异常是 Security Mode Command 之后 UE 回了 Security Mode Reject这种大多是指算法支持不一致。我在一线排障遇到过一个很隐蔽的坑UE 收到了 Authentication Request但 SIM 卡里的密钥没写好导到鉴权直接失败终端表现为“信号满格附着完成不了”。这类问题靠无线侧看永远看不出来必须连到核心网侧把鉴权响应拿出来对比看看失败原因到底是 MAC failure 还是 sync failure。3.3 Attach Accept外层给移动性合法身份内层给默认承载参数Attach Accept 也是一条双消息EMM 部分携带 GUTI、TAI list、T3412 周期性 TAU 定时器、EMM cause内层 ESM 部分则可能直接包含 Activate Default EPS Bearer Context Request。这里最容易被忽略的是 GUTI 重分配——MME 在 Accept 里下发了一个新 GUTIUE 必须在 Attach Complete 里做确认网络侧只有收到这个确认才算完成身份更新。默认承载参数通常在 ESM 那一段里包括 APN、PDN type、IP 地址、QCI、ARP、AMBR。其中 PDN type 是 IPv4、IPv6 还是 IPv4v6直接决定终端能不能拿到想要的地域地址APN 是否被允许也决定这条承载能不能建立成功。排障时如果看到 Attach Accept 带了默认承载上下文但 UE 后续没有上网流量先回去核对这部分参数。3.4 用 tshark 拉出附着过程的骨架抓包文件拿到手之后我习惯先用 tshark 把 NAS 消息类型单独抽出来列成表格。这样能把几十条 RRC 消息压缩成一眼能看懂的流程骨架tshark -r lte_attach.pcap -Y nas-eps -T fields \ -e frame.number -e frame.time_relative \ -e nas_eps.nas_msg_emm_type -e nas_eps.nas_msg_esm_type \ -e nas_eps.epc.emm.cause字段说明nas_eps.nas_msg_emm_type输出 EMM 消息类型比如 65 是 Attach Request66 是 Attach Acceptnas_eps.nas_msg_esm_type只在消息里包含 ESM 容器时才有值所以你会看到很多行走 EMM 类型后有内容、ESM 类型为空这是正常现象。最后的nas_eps.epc.emm.cause用来显示 reject 或 accept 里携带的原因值定位附着被拒时优先看这一列。如果抓包里 NAS 已经进入受保护状态这一条过滤会输出很多0x7E或者直接解不出内容那就得回到安全模式命令之前去找明文。这也是我为什么强调要在无线侧完整抓包不能从中间某个 RRC 重配置事件开始抓否则刚好错过安全上下文建立后面的 NAS 全部变密文。4. TAU、Service Request 与去附着移动性管理信令里最容易出事的三个流程附着只是开始。真正影响现网体验的往往是附着之后发生的周期性 TAU、Service Request 和隐式去附着。这几个流程都发生在 EMM-REGISTERED 状态下消息结构相比 Attach 简单但触发场景复杂。4.1 周期性 TAUT3412 设太小会成为信令风暴温床周期性位置更新的定时器 T3412 由网络在 Attach Accept 或者 TAU Accept 里下发终端在这一段时间内如果没有别的信令就会主动发起 TAU Request告诉 MME“我还活着”。周期性 TAU 对网络是有意义的它让 MME 能清理已经失联的 UE也能让寻呼范围不至于无限扩大。但这套机制有代价。T3412 设置得太小比如现网某些为了测试快速释放而配的几分钟周期会让大量终端像心跳一样反复建连、发 TAU、等 Accept、又释放空口被无效信令占满MME 的处理器占用也全线飘高。反过来T3412 设太大又会导致 MME 没法及时发现失联 UE下行数据来临时会在过大的 TAI 范围内反复寻呼寻呼失败率升高。这个矛盾的平衡点一般在 30 分钟到 60 分钟区间具体要看终端驻留场景连续覆盖的密集城区可以偏大高铁场景因为跨 TAI 频繁反而要结合 TAI list 的设计一起调。排查 TAU 风暴时我会先在 MME 网管上按 TAU Request 次数聚合IRAT 之后定位 CMG 的路由把这个数据跟 Attach 后下发的 T3412 做对照。4.2 TAU 携带上下文跨 MME 时旧身份是怎么样被“追回来”的TAU Request 里常见的身份标识是 GUTI还有 UE network capability、last visited TAI 等参数。如果 UE 从旧 MME 覆盖区移到了新 MME 覆盖区新 MME 需要根据 GUTI 解析出旧 MME 的地址然后向其发起 Context Request索要 UE 的安全上下文、EPS bearer 上下文和移动性管理状态。这个过程在端到端信令里表现为 MME 之间的交互NAS 层本身看不见但最终会影响 TAU Accept 是否及时下发。TAU Accept 里也会携带新的 GUTI如果网络做了 TAI list 重分配还会附带更新后的 TAI list。UE 收到后要回 TAU Complete流程才算走完。跨 MME 场景最容易出的问题就是 GUTI 不可路由终端拿着旧的 MME 标识访问新核心网新 MME 又找不到旧 MME最后只能回 Identity Request 重新要 IMSI整个流程时间会多出不少。4.3 Service Request用户面资源被网络挂起之后怎么“一键叫醒”UE 在 RRC 空闲状态下要发上行数据时不会直接再发一个完整附着而是发起 Service Request。这条 NAS 消息很短通常会带 TMSI status、service type、UE 侧承载状态等参数。它真正的作用是触发网络侧把用户面承载重新建立起来也就是从空闲态转换到连接态。如果这条消息被网络拒绝终端会收到 Service Reject里面带 EMM cause。这里的 cause 很关键比如#7表示 EPS 服务不允许#9表示 UE 身份不能由网络辨识。排障时不要只盯无线侧 RRC 重建切到核心网看用户面上下文是否已经释放、PGW 侧的默认承载是否还在活跃状态往往能直接定位问题。4.4 去附着、隐式去附着和寻呼失效的区别网络侧下发 Detach Request 是很直接的切断方式终端收到后要回 Detach Accept然后清除 EPS 承载上下文。还有一种情况是 MME 在长时间联系不上 UE 后在移动性可达定时器超时后执行隐式去附着终端并不知道自己被去附着直到下次发数据时被网络要求重新附着才能发现。这张表把三个容易混淆的流程放在一起对比流程触发方式关键参数失败表现周期性 TAUT3412 超时GUTI、TAI、UE network capabilityTAU Reject 后按退避定时器重试Service Request上行数据触发TMSI status、service type网络侧重新寻呼或直接拒绝隐式去附着MME 定时器超时无显式消息下次业务时收到 Attach Required实际排障里隐式去附着最常被误判成“终端掉网”因为 RRC 层面看起来信号没断但一旦有上行数据MME 会要求 UE 重新附着整个链路恢复时间会明显拉长。这个要在核心网侧查 EMM 状态和 last activity time无线侧是查不出来的。5. 避坑与排查NAS 信令落地时常见的四个问题以下是日常用这套流程排障时反复踩过的四个真实问题。每一条都按现象、原因、解决的方式记录方便直接对照。5.1 现象Attach Reject 带 cause #19但 RRC 全能建立成功现象终端显示有信号发起附着后网络直接回 Attach RejectEMM cause 是 #19EPS services not allowed。无线侧一切正常RRC 连接建立成功调度也正常。原因问题不在无线侧而在核心网签约数据或网络策略。最常见的是该用户的签约数据不允许 EPS 业务或者用户刚好被策略限制在某个 APN 之外。MME 收到 Attach Request 后去 HSS 查签约发现不支持就直接拒绝。解决去 HSS/HLR 侧核对用户签约的 EPS 订阅、APN 配置和网络允许标志同时看 MME 的用户追踪日志确定拒绝发生在哪个流程步骤。不要花时间调无线参数这是典型的“射箭靶子在核心网”。5.2 现象周期性 TAU 每隔几分钟一次小区信令负载暴涨现象某个区域的小区 RRC 连接次数异常升高功耗和调度都告警后台统计一看是周期性 TAU 请求太多。原因Attach Accept 下发的 T3412 太小。有些现网为了快速测量终端失联把 T3412 改成 6 分钟或者更短结果大量终端同一时段周期触发 TAU形成信令风暴。还有一种情况是终端侧 EMM 定时器没有按网络下发的值执行持续用出厂默认短周期。解决先在 MME 上按 TAU Request 来源聚合确认是集中性还是散发性再把 T3412 恢复到常规值比如 30 分钟或 60 分钟。如果问题在终端需要拉终端日志对比网络下发的 T3412 和实际使用的定时器时长这往往是终端实现 bug。5.3 现象Wireshark 里 NAS 全是密文按消息类型过滤也找不到一条明文现象抓包文件从某个时间点开始NAS 层全是Protected NAS message解出来的内容是一串不可读字节后续流程完全没法跟踪。原因抓包位置在安全模式命令之前没有完整接入或者抓包工具没有拿到完整性保护和加密所需要的密钥也可能你从 PDCP 层开始解析时没有把安全上下文关联正确。密文本身不是故障是你丢了“钥匙”。解决换一个更靠近端侧或者核心网侧的抓包点重新抓一次如果是实验室环境确保能在 Security Mode Command 前开始抓包并配置好完整性算法和密钥参数。现场排障没有密钥时不要在密文上浪费时间直接去 MME 侧追踪 IMSI 对应的 EMM 状态变化。5.4 现象把 EMM 和 ESM 状态画在同一条时间轴上定位变成一团乱麻现象分析一个“附着成功但业务建立失败”的问题时同时盯着 EMM 状态和 ESM 状态结论越分析越乱无法判断是移动性管理还是会话管理出的错。原因EMM 和 ESM 本来就是两条独立的状态机。Attach 流程里看起来消息是嵌套的但后续的 TAU 完全不带 ESM 消息而专用承载释放也完全不影响 EMM。把两种事件放在同一张图里主次容易被淹没。解决两套状态分开看。排移动性问题只看 EMM 消息和状态排承载问题只看 ESM 消息和状态。定位到具体流程后再考虑两者之间的先后关系而不是把信令事件直接叠在一起比较。6. 把 NAS 信令理解沉淀成手册从抓包到验证的闭环做法最后分享一个我自己坚持的落地习惯把 NAS 信令的排查发现收集进一套卡片式手册每个流程一张图并按真实抓包数据来验证。我一般会先在 Wireshark 里打开一整套完整的附着流程把 Attach Request、Authentication Request、Security Mode Command、Attach Accept、Attach Complete 五条关键消息抽出来按消息名和方向排成骨架再在每个骨架节点下附上关键参数比如身份标识用的是 GUTI 还是 IMSI、EMM cause 有没有值、ESM 容器里带的是哪种承载类型。手册里只留一个流程一篇的篇幅不做全面科普树上放一张带注释的抓包截图和对应十六进制片段就够了。验证这套理解有没有偏差最有效的办法是拿一条新流程走一遍用相同的过滤条件从 pcap 里提取消息序列自己先写出预期的下一条消息类型和方向再和实际抓包比对。这个动作我在每次接手新项目时都会做看起来笨却能快速发现以前认知里的盲区。比如我就是在类似验证里才发现自己一直以为 TAU Accept 之后一定需要 TAU Complete实际某些实现并不强制后续。这些积累下来的脚本、过滤器和流程骨架最终才是团队里最能复用的资产。希望这套拆解能帮你在面对那一堆十六进制字节时不再对着密文空转而是很快找到信令真正的眉目。本文还有配套的精品资源点击获取