1.3 协议栈分层架构：双层标准如何拼成一个整体

1.3 协议栈分层架构

本节摘要：把协议栈按分层模型拆开，标清哪些层来自底层电气标准、哪些由联盟定义，讲清服务原语与帧封装的衔接方式，并解释"为什么这样切"。这是后续逐章深入前的总骨架图，第三章到第七章都能在本文的分层图上找到自己的坐标。

一张图先立起来

从下往上是：物理层、媒体访问控制层（这两层合称底层电气标准的领地）、网络层、应用支撑子层，以及最顶端的应用层——但 Zigbee 的"应用层"不是一个整块，而是拆成应用框架、设备对象与集群库三件套。这个拆法是它最有辨识度的架构决策，值得单独讲。

图：协议栈分层与两大标准体的分工

二、两层领地的边界在哪

物理层与媒体访问控制层由学会标准定义，联盟从未越界改动——它在这两层只做"选择与配置"：挑哪些频段、设哪些参数。这个纪律让 Zigbee 栈可以直接跑在任何通过底层标准认证的芯片上，也让后来者（比如线程协议）能在同一种芯片上另起炉灶。反过来说，网络层往上的所有层都是联盟的造物：网络层的组网与路由（第三章）、应用支撑子层的绑定与分片（第四章）、设备对象的网络管理（第五章）、集群库的语义（第七章）、安全体系（第六章，贯穿网络与应用支撑两层）。

⚠️ 常见坑：把"应用支撑子层加密"与"网络层加密"混为一谈。两级加密是两把钥匙、两个作用域——网络密钥加密每一跳的整帧，链路密钥只在端到端的密钥协商与敏感命令上使用。第六章会把这套双轨制讲透，这里先埋个锚点。

三、服务原语：层与层怎么打交道

分层模型里相邻层不共享内存、不直接调用，只靠四种原语对话：上层发"请求"，下层干完活回"确认"；对端事件发生时，下层向上层发"指示"，上层处理后回"响应"。举个完整例子——应用想让某节点报告温度：

上层向应用支撑子层发数据请求原语，附上目标端点与簇；应用支撑子层查绑定表、决定走哪个端点，把数据交给网络层并收到确认；网络层选路由、经媒体访问控制层逐跳外发；对端沿反方向逐层"指示"上去，应用层收到数据指示后取走温度值。四类原语 + 逐层封装，就是这套栈的全部通信语法。

数据请求原语示例（概念格式）：
APSDE-DATA.request(
  DstAddr      = 0x1C88,     目标短地址
  DstEndpoint  = 0x01,       目标端点：温控应用
  ProfileId    = 0x0104,     应用规范标识
  ClusterId    = 0x0402,     温度测量簇
  SrcEndpoint  = 0x01,       源端点
  asduLength   = 4,          载荷长度
  TxOptions    = 0x02,       要求应用层重传
)
→ 执行结果经 APSDE-DATA.confirm 返回，状态码成功即已交网络层
​

四、为什么应用层要拆三件套

单看分层图，最反直觉的是顶部的拆法。设计动机来自第一节的教训："单网容量按百计"意味着栈必须服务多种设备类型，而不同设备的"业务逻辑"差异极大。于是联盟把应用层切成：应用框架（提供端点、定义 manufacturers 自定义空间）、设备对象（端点零上专门干网络级杂活——入网、发现、绑定管理）、集群库（把"开关""调光""测温"这些跨厂商语义标准化成可复制的簇）。三者职责互不重叠：框架管容器，设备对象管家政，集群库管词汇。第四章与第七章分别展开。

本节要点回顾

• 纵向分工：下两层属学会标准，网络层及以上属联盟规范，边界纪律保证了芯片与栈的解耦；
• 应用层三件套：应用框架（容器）、设备对象（总管家，住端点零）、集群库（标准词汇），拆分动机是设备多样性；
• 层间语法：请求、确认、指示、响应四类原语，配合逐层加头封装；
• 双轨加密：网络密钥逐跳护帧，链路密钥端到端护密钥与敏感命令，第六章展开；
• 本节坐标：第三到第七章自下而上依次展开本图的每一块。

骨架立毕。下一章进入学会标准的领地，先看物理层如何把"低功耗"变成频段、信道与调制方式上的具体数字。

延伸：分层图的两个读法

这张分层图有两种读法，对应两种工程视角。纵向读（自底向上）是实现视角：数据封装逐层加头，服务原语逐层交付，适合排障时定位"问题出在哪层"。横向读（跨层切片）是演化视角：底两层属于学会标准，二十余年只做过兼容性增强；中间三层属于联盟规范，经历了增强版的大改；顶部三件套是统一版的主战场。两张视图叠加，你会得到一个重要判断：这套协议的可变性集中在上半部，稳定性沉淀在下半部——所以买芯片不必担心过时，选生态却要盯住上半部的版本动向。

常见问题

端点零为什么留给设备对象而不是某个业务应用？

因为网络级杂活必须有固定的、全网统一的落点。发现服务要找"谁管这台设备的入网状态"，绑定管理要找"谁维护控制关系表"——这些请求不能依赖业务端点的存在与否。固定零号，等于给行政服务留了永久窗口。

速查：分层职责一句话表

排障时先答这问题属于哪一行，再进对应章节。

补分层设计的排障应用：分层架构最大的实用价值是"故障层位定位"。一套 Zigbee 系统的问题可以按层归因：物理层问题（金属遮挡、同频干扰）表现为信号强度与重传率异常——用抓包看 RSSI 与重传定位；MAC 层问题（信道拥塞）表现为退避加剧与 CSMA 失败计数上升——2.4GHz 频段被 Wi-Fi 挤压时的典型症状；NWK 层问题（路由失效、地址冲突）表现为定向消息丢失而广播正常——抓包看路由请求；APS/ZCL 层问题（绑定丢失、cluster 不匹配）表现为设备在线但控制无效果——抓包看应用层命令有没有发出去与应答。四层四类症状的对应表，是所有 Zigbee 排障的第一张速查卡：先看现象属于哪层的症状，再去那一层找证据——盲目的"重启网关"式排障，在分层协议面前只是一种祈祷。

再补一个分层架构的实践观察：Zigbee 的分层在国产芯片生态里的实现分化。协议栈的每一层都有标准文本与实现自由度的分层——PHY 与 MAC 的实现必须严格符合标准（否则无法互通），NWK 的部分行为（路由选择算法的细节）有实现弹性，APS 以上（ profile 的实现质量）则完全取决于厂商。这个分层自由度对开发者的含义：选芯片 SDK 时，底层兼容性看芯片认证，上层实现质量看厂商的应用层成熟度（设备类型支持、cluster 覆盖、边界行为处理）——同一颗射频芯片，不同厂商 SDK 的产品表现差异可以很大。分层架构的知识因此在选型时的用法是：把哪些层是标准的、哪些层是厂商的分清楚，测试与验收的重心放在厂商自由度大的层上——这是分层知识在工程采购中的变现方式。