第2章：协议栈总体架构：3GPP协议栈分层模型、控制面与用户面协议栈、NAS与AS层功能划分
各位同学，大家好。上一章我们聊了NB-IoT的来龙去脉，这一章咱们得把协议栈的骨架搭起来。说白了，就是搞清楚NB-IoT这个通信系统到底是怎么一层层叠起来的。
我刚开始接触NB-IoT协议栈时，看着3GPP那几千页的规范文档，说实话，头都大了。但后来我发现，只要抓住几个核心概念，整个框架就清晰了。今天我们就来拆解这三个关键点：分层模型、控制面与用户面、NAS与AS的划分。
2.1 3GPP协议栈分层模型
NB-IoT的协议栈，本质上是一套通信规则。它把复杂的通信过程拆成了几个层次。每一层只管自己的事，层与层之间通过标准接口通信。
嗯，这里要注意，NB-IoT的协议栈和传统LTE很像，但做了大量裁剪。毕竟NB-IoT的目标是低成本、低功耗、低速率的物联网场景。
我习惯把协议栈分成三层来看：
- 物理层（L1）：负责最底层的信号收发。比如调制解调、信道编码、射频处理。NB-IoT的物理层带宽只有180kHz，和LTE的一个资源块一样宽。
- 数据链路层（L2）：包含MAC、RLC、PDCP三个子层。MAC管调度和重传，RLC管分段和重组，PDCP管加密和完整性保护。
- 网络层（L3）：主要是RRC层和NAS层。RRC负责连接管理、系统消息广播，NAS负责会话管理和移动性管理。
你想想看，这种分层设计有什么好处？每一层都可以独立演进。比如物理层升级了调制方式，上层完全不用改。我在项目中就遇到过这种情况——芯片厂商换了射频方案，但上层协议栈代码几乎没动。
核心要点：NB-IoT协议栈的分层模型，本质上是把复杂问题简单化。每一层只暴露标准接口，内部实现可以千差万别。
2.2 控制面与用户面协议栈
这是很多初学者容易搞混的地方。控制面和用户面，其实是两条并行的数据通路。
控制面（Control Plane）：负责信令交互。比如设备注册、连接建立、资源分配。这些消息不承载用户数据，但决定了通信能不能正常进行。
用户面（User Plane）：负责真正的数据传输。比如传感器上报的温度值、水表读数。这些数据才是用户关心的。
我给大家画个简单的对比：
| 对比项 | 控制面 | 用户面 |
|---|---|---|
| 主要功能 | 信令传输 | 数据传输 |
| 协议栈路径 | NAS → RRC → PDCP → RLC → MAC → PHY | IP/Non-IP → PDCP → RLC → MAC → PHY |
| 典型消息 | Attach Request, TAU Request | CoAP数据包, MQTT消息 |
| 可靠性要求 | 极高（丢一条信令可能断连） | 较高（可重传） |
我记得有一次调试设备，发现设备总是注册不上网络。抓包一看，控制面的RRC连接建立成功了，但NAS层的Attach消息一直没发出去。这就是典型的控制面问题。后来发现是PDCP层的加密配置错了。
实战技巧：排查NB-IoT通信问题时，先判断是控制面还是用户面问题。控制面问题通常表现为设备无法入网，用户面问题表现为能入网但发不了数据。
2.3 NAS与AS层功能划分
这个划分是NB-IoT协议栈里最核心的概念之一。NAS和AS，说白了就是「管核心网的」和「管接入网的」。
NAS（Non-Access Stratum，非接入层）：
- 负责终端和核心网之间的信令交互
- 包括会话管理（SM）和移动性管理（MM）
- 典型消息：Attach、TAU、Detach、PDN连接请求
- NAS消息对无线接入网是透明的——基站只管转发，不解析内容
AS（Access Stratum，接入层）：
- 负责终端和基站之间的通信
- 包括RRC、PDCP、RLC、MAC、PHY
- 典型功能：小区搜索、随机接入、RRC连接管理、数据传输
- AS层需要处理无线环境的变化，比如信号强度、干扰、重传
为什么会这样划分？我个人的理解是：核心网和接入网是两套独立的系统。核心网关心的是「你是谁」「你能干什么」，接入网关心的是「信号好不好」「怎么传」。把这两者分开，核心网升级时不用动基站，基站升级时不用动核心网。
避坑指南：我曾经在移植协议栈时，把NAS层的定时器配置错了。结果设备在信号不好的地方频繁发起TAU，导致功耗飙升。记住，NAS层的参数（比如T3412、T3402）直接影响设备的待机功耗，一定要根据实际场景调整。
2.4 协议栈各层之间的交互
层与层之间怎么通信？通过SAP（Service Access Point，服务接入点）。每个SAP定义了一组原语（Primitive），比如请求、指示、响应、确认。
举个例子，RRC层要发一条系统消息给物理层：
- RRC层调用MAC层的服务原语
- MAC层再调用PHY层的服务原语
- PHY层把数据编码后发出去
反过来，物理层收到数据后，逐层向上传递，直到RRC层解析出系统消息。
这种设计的好处是：每一层只需要知道怎么调用下层接口，不需要关心下层怎么实现。我在做协议栈移植时，经常只需要改PHY层和MAC层的驱动代码，上层基本不用动。
总结一下：
- 分层模型让协议栈可维护、可扩展
- 控制面管信令，用户面管数据，两条路并行
- NAS管核心网交互，AS管无线接入，各司其职
下一章，我们会深入RRC层，看看NB-IoT的连接管理到底是怎么做的。到时候我会分享一个实际项目中RRC状态机调优的案例，很有意思。
好了，这一章就到这里。记住，理解协议栈的总体架构，是后续所有移植和优化工作的基础。如果你在项目中遇到协议栈相关的问题，欢迎随时交流。