4、数据传输流程：数据从应用层到物理层的封装过程、NAS与AS层交互
各位同学，咱们今天聊点实在的。数据从应用层一路跑到物理层，这个过程到底经历了什么？说白了，就是数据怎么穿上各种“马甲”，最后变成空口上的比特流。
我刚开始接触NB-IoT协议栈时，总觉得这层封装太繁琐。后来在项目中调试一个终端频繁掉线的问题，才真正体会到——每一层封装都有它的道理。少一层，数据就可能在传输中“裸奔”。
4.1 数据封装：从应用层到物理层的“穿衣打扮”
数据从应用层产生，到最终通过天线发射出去，要经历四层封装。我习惯把这比作寄快递：应用层是货物，NAS层是快递单，AS层是包装箱，物理层是运输车。
具体流程是这样的：
- 应用层（APP）：产生原始数据，比如传感器采集的温度值“25.6℃”。
- NAS层（非接入层）：加上NAS头部，包含会话管理、移动性管理等信息。这层负责和核心网沟通。
- AS层（接入层）：加上RRC头部、PDCP头部、RLC头部、MAC头部。每一层都有自己的职责。
- 物理层（PHY）：最终编码、调制，映射到物理资源块上发射出去。
关键点：每一层封装都会增加开销。NB-IoT本身带宽窄，数据量小，所以协议栈在设计时尽量压缩头部长度。比如RLC层的UM模式，头部只有1-2个字节。
4.2 NAS与AS层的交互：谁负责什么？
NAS层和AS层的分工，我举个例子你就明白了。
NAS层：相当于“外交官”。它负责和核心网（EPC）打交道，处理附着、TAU（跟踪区更新）、PDN连接建立等事务。NAS消息对终端来说是透明的，终端只知道“我要附着”，至于怎么附着，那是NAS层的事。
AS层：相当于“本地警察”。它负责空口上的具体操作，比如小区搜索、随机接入、无线资源分配。AS层收到NAS层的指令后，会通过RRC信令在空口上执行。
我在项目中遇到过一个问题：终端附着成功后，突然无法发送数据。排查了半天，发现是NAS层的PDN连接请求没有正确传递给AS层。AS层不知道要建立数据无线承载（DRB），结果数据一直卡在NAS层。嗯，这种问题很隐蔽。
4.3 数据封装的具体过程（以用户面数据为例）
咱们一步步拆解。假设应用层要发送一个IP包，长度100字节。
步骤1：应用层 → NAS层
应用层数据通过IP协议栈封装成IP包。然后交给NAS层。NAS层会判断这个数据属于哪个PDN连接，加上NAS头部（通常5-10字节）。
NAS PDU = NAS头部 + IP包
= 8字节 + 100字节
= 108字节步骤2：NAS层 → AS层（RRC层）
NAS PDU通过RRC层的信令无线承载（SRB）或数据无线承载（DRB）传递。如果是用户面数据，走DRB。RRC层会加上RRC头部（通常1-2字节）。
我的经验：RRC层在建立DRB时，会配置PDCP、RLC、MAC的参数。这些参数直接影响重传效率。比如PDCP的discardTimer，设得太短会导致数据频繁丢弃，设得太长又会占用缓存。我一般建议根据业务类型动态调整。
步骤3：PDCP层
PDCP层负责加密、完整性保护（控制面）和头压缩（RoHC）。NB-IoT支持RoHC，但实际项目中用得不多，因为数据量太小，压缩收益有限。
PDCP PDU = PDCP头部 + 加密后的NAS PDU
= 2字节 + 108字节
= 110字节步骤4：RLC层
RLC层负责分段/重组。如果PDCP PDU太大，超过MAC层分配的传输块大小（TBS），RLC会把它切成小段。
举个例子：MAC层分配的TBS只有50字节，那RLC会把110字节的PDCP PDU切成3段：
- 段1：50字节
- 段2：50字节
- 段3：10字节
每一段加上RLC头部（UM模式2字节，AM模式3字节）。
注意：RLC分段是重传机制的关键。如果某个段丢失了，只需要重传那个段，而不是整个PDCP PDU。我在项目中遇到过RLC缓存溢出导致丢包的问题，后来调整了RLC窗口大小才解决。
步骤5：MAC层
MAC层负责复用、HARQ重传。它会从多个RLC实体（比如信令和数据的RLC实体）中取出数据，复用到一个MAC PDU中。然后加上MAC头部（包含LCID、定时提前等）。
MAC PDU = MAC头部 + RLC段1 + RLC段2 + RLC段3
= 3字节 + 50字节 + 50字节 + 10字节
= 113字节步骤6：物理层
物理层拿到MAC PDU后，进行CRC添加、信道编码（Turbo码或卷积码）、速率匹配、加扰、调制（BPSK/QPSK）、资源映射。最终通过天线发射出去。
4.4 NAS与AS层交互的典型场景：附着流程
咱们以终端附着为例，看看NAS和AS怎么配合。
| 步骤 | NAS层动作 | AS层动作 |
|---|---|---|
| 1 | 发起附着请求（Attach Request） | 执行小区搜索、随机接入 |
| 2 | 等待核心网响应 | 通过RRC建立SRB1，传递NAS消息 |
| 3 | 收到Attach Accept | 建立DRB，配置PDCP/RLC/MAC参数 |
| 4 | 发送Attach Complete | 确认DRB建立完成 |
这里有个坑：NAS层发起附着请求后，AS层需要先完成随机接入。如果随机接入失败（比如前导码冲突），NAS层会一直等。我曾经遇到一个场景，终端在弱信号下反复随机接入失败，NAS层超时后直接进入“受限服务状态”。
避坑指南：我曾经在调试时发现，NAS层的T3411定时器（附着请求重传定时器）和AS层的随机接入重传次数需要配合好。如果T3411设得太短，AS层还没完成随机接入，NAS层就重传了，会导致信令冲突。我一般建议T3411设为10秒，随机接入最大重传次数设为8次。
4.5 数据封装中的重传机制
数据封装过程中，每一层都有自己的重传机制：
- NAS层：端到端重传，比如附着请求、TAU请求的重传。超时未收到响应就重传。
- RLC层：AM模式下的ARQ重传。接收端收到数据后发送状态报告，发送端根据报告重传丢失的段。
- MAC层：HARQ重传。快速重传，最多4次，每次重传使用不同的冗余版本（RV）。
这三层重传是嵌套的。MAC层HARQ重传失败后，RLC层ARQ会接手。RLC层重传失败后，NAS层会触发端到端重传。说白了，就是层层兜底。
我记得有一次测试，终端在移动场景下频繁丢包。分析日志发现，MAC层HARQ重传了4次都失败，RLC层ARQ重传了3次也失败，最后NAS层触发TAU流程才恢复连接。嗯，这种场景下，优化物理层的覆盖比调整重传参数更有效。
4.6 小结
数据从应用层到物理层的封装过程，说白了就是一层层加头、分段、加密、复用。NAS层负责和核心网沟通，AS层负责空口执行。两者配合得好，数据传输就顺畅；配合不好，就会出现各种奇怪的问题。
下一章咱们聊聊重传机制的参数配置，比如T3411、T300、T301这些定时器怎么设。到时候我会分享一些实际项目中的调优经验。