3、IoT通信协议栈：物理层、MAC层、网络层、传输层、应用层协议对比
说实话，做IoT这行这么多年，我见过太多人一上来就选协议。问为什么选这个？答：大家都用。嗯，这可不是个好习惯。
你想想看，一个智能水表和一个智能灯泡，它们对通信的需求能一样吗？水表可能一天传一次数据，电池要用五年；灯泡呢，你得随时开关，延迟高了用户就骂娘。所以，搞懂协议栈每一层在干什么，比背几个参数重要得多。
这一章，我就带你把这五个主流协议——Zigbee、BLE、WiFi、LoRa、NB-IoT——从物理层到应用层扒一遍。咱们不搞死记硬背，而是从「为什么这么设计」的角度去理解。
3.1 物理层：谁在「说话」，用什么「语言」
物理层解决的是最底层的问题：比特流怎么在空气里跑。说白了，就是用什么频率、怎么调制、发射功率多大。
我当年做第一个Zigbee项目时，就被物理层坑过。产品在实验室测得好好的，一放到客户工厂，死活连不上。后来发现，工厂里有台老旧的电机，正好在2.4GHz频段上产生强干扰。嗯，从那以后，我选型时第一件事就是看频段。
| 协议 | 工作频段 | 调制方式 | 典型速率 | 最大发射功率 |
|---|---|---|---|---|
| Zigbee | 2.4GHz (全球), 868/915MHz | O-QPSK, BPSK | 250kbps (2.4G) | +20dBm (100mW) |
| BLE | 2.4GHz | GFSK | 1Mbps / 2Mbps | +10dBm (10mW) |
| WiFi | 2.4GHz, 5GHz, 6GHz | OFDM, QAM (多种) | 最高数Gbps (WiFi6) | +20dBm (100mW) |
| LoRa | Sub-1GHz (470-510MHz CN) | CSS (扩频) | 0.3kbps - 50kbps | +20dBm (100mW) |
| NB-IoT | 授权频段 (B1/B3/B5/B8等) | QPSK, BPSK | 200kbps (下行) | +23dBm (200mW) |
3.2 MAC层：怎么「排队」说话，避免「吵架」
物理层把比特发出去了，但如果多个设备同时发，信号就撞车了。MAC层就是管这个的——谁先说话，谁后说话，撞车了怎么办。
这里有个关键区别：竞争型和非竞争型MAC。WiFi用的CSMA/CA是典型的竞争型——先听再讲，听到有人讲就等。Zigbee和BLE则用了更精细的时隙机制。
我记得有个做智能照明的客户，用了WiFi做灯控。结果50盏灯同时开，MAC层碰撞导致有些灯延迟了3秒才亮。用户体验极差。后来换成Zigbee，时隙机制保证每盏灯都有固定的通信窗口，延迟降到200ms以内。
- Zigbee (CSMA/CA + 时隙)：信标使能模式下，协调器分配时隙，设备只在指定时隙发送。非信标模式则用CSMA/CA。适合确定性要求高的场景。
- BLE (跳频 + 自适应)：BLE用40个信道，3个广播信道，37个数据信道。每次通信前先跳频，避开干扰。MAC层还支持连接事件，设备只在约定时间醒来。
- WiFi (CSMA/CA + RTS/CTS)：经典的载波监听。隐藏节点问题严重时，可以用RTS/CTS握手机制。但节点多了，碰撞概率指数上升。
- LoRa (纯ALOHA + LBT)：LoRaWAN的MAC层很简单，设备想发就发（ALOHA），或者先听再发（LBT）。适合低负载场景，高负载下碰撞率很高。
- NB-IoT (蜂窝调度)：由基站统一调度资源，设备不能乱发。这是蜂窝网络的优势——MAC层效率极高，但代价是设备必须和基站保持同步。
3.3 网络层：数据怎么「找到路」
网络层解决的是路由问题。一个数据包从设备A到设备B，中间可能经过多个跳点，怎么走最省电、最可靠？
这里有个有意思的对比：Zigbee支持Mesh网络，数据可以在节点间多跳转发；而BLE和WiFi通常是星型拓扑，所有设备都连到中心节点。LoRa和NB-IoT则是终端直连网关/基站。
| 协议 | 网络拓扑 | 路由协议 | 最大节点数 | 典型覆盖范围 |
|---|---|---|---|---|
| Zigbee | Mesh, 树型, 星型 | AODV (按需距离矢量) | 理论65535 | 10-100m (单跳) |
| BLE | 星型 (经典), Mesh (5.0+) | 泛洪 (Mesh模式) | 经典7, Mesh数千 | 10-100m |
| WiFi | 星型 (基础架构) | 无 (AP转发) | 典型200-500 | 30-100m (室内) |
| LoRa | 星型 (终端-网关) | 无 (单跳) | 数千/网关 | 2-15km (郊区) |
| NB-IoT | 蜂窝 (终端-基站) | 蜂窝网络路由 | 5万/小区 | 1-10km (城区) |
我个人习惯是：需要自组网、覆盖大空间（比如智能楼宇），首选Zigbee Mesh。BLE 5.0的Mesh虽然也能用，但泛洪机制在大规模网络下效率堪忧。WiFi的Mesh？嗯，功耗太高，不适合电池设备。
3.4 传输层：保证数据「完整到达」
传输层在IoT里经常被忽略。很多IoT协议直接基于UDP，因为TCP的握手和重传太耗电了。但UDP不保证可靠，丢了就丢了。
Zigbee和BLE在传输层都做了自己的可靠机制。Zigbee的APS层有确认和重传，BLE的L2CAP层也支持流控和重传。WiFi则用TCP/UDP，看应用层怎么选。LoRaWAN和NB-IoT通常用UDP + 应用层确认。
3.5 应用层：数据「长什么样」
应用层定义了数据格式和交互逻辑。这一层最五花八门，每个协议都有自己的「方言」。
- Zigbee (ZCL + Zigbee Profiles)：定义了设备描述和属性。比如一个灯，有开关、亮度、色温等属性。设备间互操作性好，但学习成本高。
- BLE (GATT + Profiles)：通过Service和Characteristic暴露数据。心率计有心率Service，温度计有温度Service。简单灵活，但Profile碎片化严重。
- WiFi (HTTP/MQTT/CoAP)：WiFi设备通常直接跑IP协议栈，应用层用HTTP、MQTT、CoAP等。生态最丰富，但协议栈开销大。
- LoRa (LoRaWAN MAC层之上)：LoRaWAN定义了MAC层和应用层之间的接口，但应用层数据格式由用户自定义。通常用JSON或二进制编码。
- NB-IoT (CoAP/UDP + LwM2M)：3GPP定义了LwM2M协议，用于设备管理和数据上报。适合运营商级IoT部署。
3.6 综合对比：一张表看懂怎么选
好了，五层都过了一遍。最后我整理了一张综合对比表，方便你快速决策。
| 维度 | Zigbee | BLE | WiFi | LoRa | NB-IoT |
|---|---|---|---|---|---|
| 功耗 | 低 (电池年级) | 极低 (纽扣电池) | 高 (需供电) | 超低 (电池年级) | 低 (电池年级) |
| 速率 | 250kbps | 1-2Mbps | 高 (Mbps-Gbps) | 0.3-50kbps | 200kbps |
| 覆盖 | 短距 (10-100m) | 短距 (10-100m) | 中距 (30-100m) | 长距 (2-15km) | 长距 (1-10km) |
| 组网 | Mesh (自组网) | 星型/Mesh | 星型 | 星型 (终端-网关) | 蜂窝 (运营商) |
| 成本 | 中 ($2-5) | 低 ($1-3) | 中 ($3-8) | 中 ($5-10) | 高 ($8-15 + SIM) |
| 典型场景 | 智能家居, 楼宇自控 | 穿戴, 健康, 信标 | 摄像头, 大屏, 网关 | 水表, 农业, 资产追踪 | 电表, 市政, 车联网 |
选型时，我一般先问三个问题：电池能用多久？数据量多大？距离多远？ 答案出来了，协议也就定了。别被厂商的宣传带偏，回到物理层和MAC层的本质去思考。