软工22级培养方案新增的课，成为了小白鼠。第一次开课肯定不完善的地方很多，实验会免费送我们硬件，代码是框架改的，反正我从头到尾没写明白过。整理一下理论部分。


一、概述

参考课件：ch1 IoT概述。教材为董玮、高艺、韩劲松《从创意到原型：物联网应用快速开发（第2版）》，科学出版社，2022。课程目标是掌握物联网「端—管—云」主流技术与开发工具，具备快速开发物联网应用的能力。评分：平时 10% + 实验 40% = 50%，期末闭卷 50%。


脉络

全课按一条「物怎么连上、数据怎么走、应用怎么做、安全怎么守」的主线展开。先记住这条链，再往下钻各章细节。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
物理世界
  │ 感知（传感 / RFID / 摄像头…）
  ▼
【端】硬件 + OS                          ← 第二、三章
  MCU/SoC · 传感器 · 能量（电池/采集/背向散射）
  Contiki / RIOT / AliOS / HarmonyOS …
  │ 驱动 · 调度 · 占空比 · 低功耗栈
  ▼
【管】短距 或 广域                       ← 第四、五章
  ┌─ 短距：802.15.4 → MAC(LPL/RI-MAC) → PRR/ETX
  │         → 6LoWPAN → CTP/RPL → Thread → Matter
  │         （物理层→谁占用信道→链路好不好→IPv6压缩→选路→家居互联）
  │         旁支：BLE / GATT / Mesh
  └─ 广域：NB-IoT（授权蜂窝）∥ LoRaWAN（免授权 CSS）
            PSM/eDRX · OTAA/ABP · Class A/B/C
            （怎么睡 · 怎么入网 · 下行窗口怎么开）
  │ 经网关 / 基站 / 网络服务器
  ▼
【云】连接 · 管理 · 规则 · 时序 · 认证 · 无服务器 · 边缘  ← 第六章
  MQTT / CoAP / HTTP · 设备影子 · IFTTT/编排 · TSDB
  │
  ▼
【一体】端云协同低代码                   ← 第七章
  TinyLink（自顶向下选型+云编译）
  IoT Studio（物模型 TSL + 服务编排）
  涂鸦（零/低/多代码）· 联合接入
  │
  ▼
【安】纵深防御贯穿端–管–云               ← 第八章
  攻击面（网络/硬件）→ PUF/TEE/沙盒
  → 无线密钥（BLE/ZigBee/LoRa/NB）
  → TLS/MQTT · 三元组/ID² · Matter DCL
章 在链上的位置 要解决的核心问题 下游依赖它的章
一 概述 总图 何为物联、端管云、挑战与供电/平台选型 全部
二 硬件 端 · 硅与板 选 MCU/模组、算能耗与接口 三（跑 OS）、四/五（射频）
三 系统 端 · 软件 调度、驱动、低功耗 API 四（Contiki 栈）、七（AliOS）
四 短距 管 · 局域多跳 15.4 调制、MAC、路由、BLE 一 Matter、七家居、八 ZigBee/BLE 安全
五 广域 管 · 远距稀疏 NB vs LoRa、覆盖增益、入网与 Class 六接入、八 LoRaWAN/NB 安全
六 云 云 · 中枢 协议字节、影子、规则冲突、时序/边缘 七编排、八认证
七 一体 端↔云工具链 物模型、云编译、编排、联合 八案例（TEE+MQTT）
八 安全 横切 攻防机制与可信开发 回扣一～七各层

一条数据怎么走（教室 PIR 座位统计例）： PIR@GPIO → TinyLink/aliyun-iot-sdk 读入 → Wi-Fi → MQTT（三元组 HMAC 或 TLS 8883）→ 阿里云 Topic thing.event.property.post → IoT Studio 编排（路径选择 / 钉钉）→ Web 看板。缺电则回看二/三占空比与休眠；丢包则回看四 PRR/ETX 或五 CE level；规则乱则回看六 IFTTT；被仿冒则回看八 DeviceSecret / TEE。

▸选型口诀（闭卷可默写）
  • 距离近、多跳、手机周边 → 短距（15.4 / BLE）；公里级、电池数年、稀疏上报 → NB 或 LoRa。
  • 要运营商覆盖与 QoS → NB-IoT；要自建网关、免授权 → LoRaWAN。
  • 设备在线可控 → 直接 API；离线也要改期望 → 设备影子。
  • 初学快速原型 → TinyLink；要物模型+可视化编排 → IoT Studio；消费品量产 → 涂鸦。
  • 密钥进片、防拆 → PUF/RoT/TEE；传信道 → TLS/MQTT 8883；跨厂认证 → Matter DCL。
▸图源

综合 ch1 IoT概述.pdf–ch8.pdf 目录自绘，课件无单页总链。上文章节「脉络」已有 ASCII 总图，下图为同一条链的框图。

1
2
3
4
5
6
7
8
9
10
11
12
13
物理世界 --感知--> 【端 硬件+OS】ch2/ch3
                 |
                 v
            【管 短距/广域】ch4 / ch5
                 |
                 v
            【云 连接/管理/规则】ch6
                 |
                 v
            【一体 低代码】ch7
                 |
                 v
            【安 纵深防御】ch8  （横切端-管-云）

术语

下文专有名词尽量写成「中文 / 缩写（English Full Name，中文全称）」；此处先集中列一版速查，闭卷默写前可过一遍。

▸怎么读括号

例：ETX（Expected Transmission Count，期望传输次数） = 缩写 + 英文全称 + 中文意思。看到不熟的缩写，先回本表，再回对应章节。

缩写 / 词 English 一句话
IoT Internet of Things 物联网：物带感知、计算、连接，接到网上
AIoT Artificial Intelligence of Things 人工智能 + 物联网，万物智联
端–管–云 Device–Pipe–Cloud（课件用语） 设备端 → 传输管道 → 云平台；「管」= 网络/协议这一段
MCU Microcontroller Unit 微控制器，单芯片里有 CPU+少量 RAM/Flash，物联网节点最常见大脑
SoC System on Chip 片上系统，比 MCU 更「整机」，常集成 Wi-Fi/BLE 等
OS Operating System 操作系统：管调度、驱动、内存
API Application Programming Interface 应用程序接口：别人写好的调用入口
SDK Software Development Kit 软件开发包：API + 文档 + 工具
GPIO General Purpose Input/Output 通用输入输出引脚，接灯、按键、传感器电平
UART Universal Asynchronous Receiver/Transmitter 异步串口，两根线 RX/TX 传字节
RFID Radio Frequency Identification 射频识别：阅读器问，标签答
WSN Wireless Sensor Network 无线传感器网络，多跳、自组织
占空比 $D$ Duty Cycle 工作时间占比；0.01 = 只醒 1% 时间，其余睡
Ambient Backscatter 环境后向散射 不自己发大功率射频，靠反射环境电磁波传信息
PHY Physical Layer 物理层：调制、频率、怎么变成电磁波
MAC Medium Access Control 介质访问控制：谁先说话、如何避免撞车
WPAN Wireless Personal Area Network 无线个域网，短距
LPWAN Low-Power Wide-Area Network 低功耗广域网，远、慢、省电
DSSS Direct Sequence Spread Spectrum 直接序列扩频：1 bit 扩成多 chip
O-QPSK Offset Quadrature Phase-Shift Keying 偏移正交相移键控，15.4 常用调制
LPL Low Power Listening 低功耗侦听：发送方拉长前导把睡眠的接收方叫醒
RI-MAC Receiver-Initiated MAC 接收方发起的 MAC：接收方先发 beacon
PRR Packet Reception Ratio 包接收率，成功收到的比例
RSSI Received Signal Strength Indicator 接收信号强度指示
LQI Link Quality Indicator 链路质量指示（芯片给出的质量分）
ETX Expected Transmission Count 期望传输次数：这条链路平均要发几次才成功
CTP Collection Tree Protocol 收集树协议：多节点数据汇到 Sink
RPL IPv6 Routing Protocol for LLNs 低功耗有损网的 IPv6 路由，建 DODAG
DODAG Destination-Oriented Directed Acyclic Graph 面向目的地的有向无环图（一棵「朝根」的树状图）
6LoWPAN IPv6 over Low-Power WPAN 让 IPv6 能跑在 15.4 这种小帧上（压缩头）
BLE Bluetooth Low Energy 低功耗蓝牙
GATT Generic Attribute Profile BLE 属性协议：服务里挂特征
TTL Time To Live 生存时间：Mesh 里每转发一次减 1
NB-IoT Narrowband Internet of Things 窄带物联网，运营商授权频谱
LoRa / LoRaWAN Long Range / LoRa Wide Area Network 扩频远距芯片技术 / 其上的广域网协议
CSS Chirp Spread Spectrum 啁啾扩频：频率扫上去表示符号
SF Spreading Factor 扩频因子，越大越慢越远
PSD Power Spectral Density 功率谱密度 = 功率/带宽，越大单位频率上越「狠」
PSM Power Saving Mode 省电模式：几乎休眠，不可寻呼
eDRX extended Discontinuous Reception 扩展非连续接收：隔很久醒一次听有没有下行
OTAA / ABP Over-The-Air Activation / Activation By Personalization 空中入网 / 预置密钥入网
NwkSKey / AppSKey Network / Application Session Key 网络会话钥（完整性）/ 应用会话钥（加密）
MQTT Message Queuing Telemetry Transport 发布订阅消息协议，经 Broker 转发
CoAP Constrained Application Protocol 受限应用协议，像「迷你 HTTP」，常跑 UDP
HTTP / HTTPS HyperText Transfer Protocol (Secure) 超文本传输协议（加 TLS 后为 HTTPS）
TLS Transport Layer Security 传输层安全，握手后加密通道
IFTTT If This Then That 「如果…那么…」规则自动化
TSDB Time Series Database 时序数据库，按时间戳存传感流
TSL Thing Specification Language 物模型描述语言（阿里云 JSON）
TEE Trusted Execution Environment 可信执行环境，安全世界里跑敏感代码
TA / CA Trusted / Client Application 可信应用（安全世界）/ 客户端应用（普通世界）
PUF Physical Unclonable Function 物理不可克隆函数，芯片「指纹」
RoT Root of Trust 信任根，安全信任链的起点
HSM Hardware Security Module 硬件安全模块
PKI Public Key Infrastructure 公钥基础设施（证书体系）
DAC / PAA / DCL Device Attestation Certificate / Product Attestation Authority / Distributed Compliance Ledger Matter：设备证明证书 / 产品证明机构 / 分布式合规账本

脉络图里的符号对照：MAC = 谁占用信道；PRR/ETX = 链路好不好、要重传几次；CTP/RPL = 多跳怎么选路；PSM/eDRX = 蜂窝怎么睡；OTAA/ABP = LoRa 怎么入网；TSL = 云端约定设备有哪些属性/事件/服务。


定义

物联网（IoT，Internet of Things）是由物理设备以及其他嵌入了电子器件、软件、传感器的物件组成的网络。这些物件具备三类能力，从而把物理世界更直接地集成到数字世界：

能力 含义 典型部件
感知（Sensing） 采集物理量、事件与状态 温湿度、PM2.5、IMU（Inertial Measurement Unit，惯性测量单元）、RFID（Radio Frequency Identification）标签
计算（Computing） 本地处理、滤波、推理或控制 MCU（Microcontroller Unit，微控制器）、边缘 SoC（System on Chip，片上系统）、轻量 ML（Machine Learning，机器学习）
连接（Connectivity） 把数据与指令送达网关/云/其他物件 BLE（Bluetooth Low Energy）、Wi-Fi、NB-IoT、LoRa、5G
▸三能力怎么记

没有传感器只会「瞎」；没有计算只会「传原始数」；没有连接只是「单机小仪器」。物联网 = 三者都有，并且连成网。

【此处插入：智慧家居界面与共享单车智能锁示意】

▸图源

ch1 IoT概述.pdf 第 7 页。智慧家居 App 界面与共享单车智能锁实物照。无法准确复绘。

▸ITU-T 标准定义（Y.2060 / Y.4000，2012）

ITU-T（International Telecommunication Union – Telecommunication Standardization Sector，国际电联电信标准化部门）将物联网定义为：面向信息社会的全球性基础设施，在现有及演进中的可互操作 ICT（Information and Communications Technology，信息通信技术）基础上，通过互连物理物与虚拟物提供高级服务。

  • 物（thing）：可被标识并接入通信网络的对象。
  • 物理物（physical thing）：可被感知、驱动与连接，如工业机器人、电气设备、环境本身。
  • 虚拟物（virtual thing）：可被存储、处理与访问，如多媒体、应用软件。
  • 一个物理物可映射为一个或多个虚拟物；虚拟物也可独立存在。

课件定义侧重「嵌入式物件 + 感知/计算/连接」；ITU-T 定义更强调标识、互操作与服务，二者互补。考试叙述以课件为准，辨析题可引用 ITU-T。


▸两类日常场景如何对应三能力
  • 智慧家居：灯、空调、门锁为物理物；手机 App 为虚拟物/客户端。光照与人体红外完成感知，本地规则或云端场景完成计算，Wi-Fi/BLE 完成连接。
  • 共享单车：车锁内加速度计/GPS（Global Positioning System，全球定位系统）感知位置与震动，MCU 判断是否落锁，蜂窝模组上报状态；扫码开锁是云端鉴权后的下行控制。

沿革

时间 事件 要点
1995 比尔·盖茨《未来之路》 提出物物互联的基本思想
2005 ITU《互联网报告 2005：物联网》 正式描绘「无所不在的物联网通信时代」
2008/2009 IBM「智慧地球」（Smarter Planet） 课件正文写 2009，时间轴图写 2008。IBM 于 2008-11 正式提出，2009 年在中国大力推广
2009 中国「感知中国」 温家宝在无锡考察传感网后提出建立中国传感信息中心
近年 AIoT（人工智能赋能物联网） 由万物互联走向万物智联

课件时间轴图中 IBM 节点标为 2008，正文条目标为 2009，二者并存。闭卷若考年份，优先记课件正文：2005 ITU、2009 智慧地球与感知中国。

▸图源

ch1 IoT概述.pdf 第 8 页。「物联网的起源和发展」。下图按课件结构复绘。

1
2
3
4
5
6
7
8
9
1995  《未来之路》物物互联
  |
2005  ITU《互联网报告 2005：物联网》
  |
2008  时间轴图：IBM「智慧地球」   ← 与正文 2009 并存
  |
2009  「感知中国」；正文亦写 IBM 2009
  |
近年  AIoT / 万物智联

ITU 报告中的日常图景：衣服告知洗衣机对颜色与水温的要求；公文包提醒主人忘带物品。其技术底座包括 RFID 标识、传感器测状态、嵌入智能把计算下沉到边缘，以及微纳化使更小物件也能连网。ITU 将物联网概括为在「任何时间、任何地点、任何人」之外再增加「任何物」这一新维度。


趋势

连接数

来源：IoT Analytics（2020-11）。非物联网连接指智能手机、笔记本、PC 等。

年份 物联网连接 非物联网连接 总连接 意义
2020 117 亿 100 亿 217 亿 IoT 首次超过非 IoT（约占 54%）
2025E 309 亿 约 103 亿 412 亿 IoT 约为非 IoT 的 3 倍；人均约 4 个 IoT 设备

2019 年总连接约 200 亿，2025 年预计约 412 亿，五年接近翻倍；增长几乎全部来自 IoT，非 IoT 市场接近饱和。课件柱状图中 2021–2025 带 E，表示基于 2020-11 数据的预测。

▸图源

ch1 IoT概述.pdf 第 9 页。「IoT Analytics 全球连接数（2020-11）」。下图按课件结构复绘。

来源标注：Total number of device connections 2019 = 20.0 Bn，2025E = 41.2 Bn；2021 起带 E。单位：十亿。

年 IoT 非 IoT 合计
2010 0.8 8.0 8.8
2011 1.1 8.7 9.7
2012 1.6 9.1 10.7
2013 2.1 9.5 11.6
2014 2.8 9.7 12.5
2015 3.6 9.7 13.3
2016 4.6 9.8 14.4
2017 6.1 9.9 16.0
2018 8.0 9.9 17.9
2019 10.0 10.0 20.0
2020 11.7 9.9 21.7
2021E 13.8 10.0 23.9
2022E 16.4 10.1 26.5
2023E 19.8 10.2 29.9
2024E 24.4 10.2 34.6
2025E 30.9 10.3 41.2

历史增速约 10%（2014–15），预测约 13%。2020 为 IoT 首次超过非 IoT 的交叉年。


产业阶段

发展主线可概括为三阶段：

  1. 传感网 / 早期物联网：节点、多跳组网、数据采集。
  2. 物联网操作系统 + 云平台：软件栈与云侧能力成为竞争焦点。
  3. 至今：端侧 OS、云平台、AIoT 与标准化并行。

2018–2021 典型事件（对应第二阶段）：

时间 主体 事件
2018.03 阿里巴巴 宣布全面进军物联网
2018.04 微软 投资 50 亿美元构建物联网生态
2018.09 中国三大运营商 NB-IoT 网络初步建成
2019.08 华为 发布面向物联网的鸿蒙操作系统
2019.09 腾讯 发布实时 IoT 系统 TencentOS Tiny
2021.02 涂鸦智能 赴美上市，估值近 80 亿美元
▸图源

ch1 IoT概述.pdf 第 10 页。「物联网发展趋势（三阶段）」。下图按课件结构复绘。

1
2
3
4
5
6
7
8
[传感网] --> [物联网 OS + 云平台] --> [至今：物联网]
                 ^
                 |  2018.03 阿里全面进军物联网
                 |  2018.04 微软投 50 亿美元
                 |  2018.09 三大运营商 NB-IoT 初建成
                 |  2019.08 华为鸿蒙（面向物联网）
                 |  2019.09 腾讯 TencentOS Tiny
                 |  2021.02 涂鸦赴美上市，估值近 80 亿美元

学术

研究热点：新型低功耗硬件、端侧基础软件、感知技术、无线网络、端侧 AI / 云端协同 AI、创新应用。

类型 名称
期刊 IEEE TMC；ACM TOSN；ACM TIOT；IEEE IoTJ；电子学会《物联网学报》
CSRankings 顶会 ACM MobiCom、MobiSys、SenSys
其他 IEEE INFOCOM；ACM IMWUT / UbiComp

架构

典型应用沿「端—管—云—用」展开，对应课程所说的端—管—云（Device–Pipe–Cloud）。

▸「管」到底是什么

「管」不是一根物理水管，而是数据怎么从设备送到云：短距多跳（15.4/BLE）、广域（NB-IoT/LoRa）、网关协议转换、蜂窝基站等，全算「管道」这一层。

层次 角色 课件表述
物联网设备（IoT Device） 终端感知 如 PM2.5 感知节点
网关（Gateway） 无线收数、有线/蜂窝上云 设备通常无线接入；网关无线接收后经有线（或蜂窝）传到云
物联网云平台（IoT Cloud Platform） 存、查、析、展；设备与网关接入管理；多重安全 数据面 + 管理面 + 安全面
客户端（Client） 各类用户端应用 Web / App / 小程序

设备↔网关常见无线：BLE 5.0、NB-IoT、Wi-Fi、GPRS（General Packet Radio Service，通用分组无线服务）。网关↔云、云↔客户端均经互联网，双向。

▸图源

ch1 IoT概述.pdf 第 13 页。「典型物联网应用架构」。下图按课件结构复绘。

1
2
3
4
物联网设备          网关              物联网云平台           客户端
(PM2.5 等感知)      无线收、有线出      存储/查询/分析/管理     用户端应用
        \  BLE 5.0 / NB-IoT / Wi-Fi / GPRS  /
         \______________ 互联网 ______________/
▸端管云与四层模型的对应

教材/产业常把物联网写成感知层、网络层、平台层、应用层。与课件四段的对应是：设备 ≈ 感知层；网关 + 接入协议 ≈ 网络层（「管」）；云平台 ≈ 平台层；客户端 ≈ 应用层。网关既是网络枢纽，也常承担边缘计算（Edge Computing），因此「管」与「边」在实现上经常重合。


部分常见设备、平台与软件：

层次 硬件形态 软件 / 平台
传感器 芯片式、柱状、模组、扣式探头等 —
开发板 Arduino、Intel Edison 等 Contiki、RIOT、Zephyr、RT-Thread、HarmonyOS
网络设备 工业网关、无线路由器 OpenWrt、EdgeX、KubeEdge
云服务 AWS、阿里云、Azure 开源：ThingsBoard；IoTSharp（集成 MQTT、InfluxDB、Grafana 等）

课件中 RIOT、ThingsBoard 以红色标出，实验/项目中更常直接接触。

▸图源

ch1 IoT概述.pdf 第 14 页。「部分常见的设备、平台与软件」。实物照片无法复绘；软件名单按下表整理。课件将 RIOT、ThingsBoard 标红。

层 课件实物 软件 / 平台
传感器 各类传感元件 / 模块照片 —
开发板 Edison 等开发板照片 Contiki、RIOT、Zephyr、RT-Thread、HarmonyOS
网络设备 交换机 / 无线路由照片 OpenWrt、EdgeX、KubeEdge
云服务 AWS / 阿里云 / Azure 标志 ThingsBoard、IoTSharp（MQTT、InfluxDB、Grafana 等）

挑战

物联网应用开发面临三类结构性挑战，每一类都对应明确机遇。


开发链

挑战 1：开发链长。 完整应用同时包含嵌入式开发、云平台开发、用户端开发，涉及嵌入式、前端、后端等不同技术栈，需要多类开发人员协作。IoT Analytics「2022 年 6 大 IoT 采纳趋势」将 IoT 项目复杂度仍是主要挑战列为第 6 条并重点标出。

机遇 1：低代码。 数字化场景落地需求爆发，低代码成为效能突破点。Gartner 预测：到 2024 年，75% 的应用程序将在低代码平台中开发。IEEE Computer Society 将低代码列为 2022 年 16 大技术趋势之一。

机遇 2：大模型。 使基于自然语言的开发成为可能（用自然语言描述逻辑，由模型生成/辅助生成端—云—端代码）。

▸图源

ch1 IoT概述.pdf 第 15 页。「6 IoT adoption trends for 2022」。下图按课件结构复绘。

# 趋势 课件强调
1 IoT adoption is accelerating 采纳加速
2 Use cases that focus on improving operations/assets are on the rise 运营/资产类用例上升
3 IoT initiatives are becoming more successful 项目成功率提高
4 The gap between adoption leaders and laggards is widening 领先者与落后者差距拉大
5 APAC is catching up to North America and Europe 亚太追赶欧美
6 The complexity of IoT projects remains the major challenge 课件红框：复杂度仍是主要挑战

终端

挑战 2：尚无固定终端类型。 PC 有 Windows / Linux / macOS 与相对稳定的整机形态；Mobile 有 Android / iOS 与手机这一主导形态；IoT 硬件则是大量异构开发板与模组，图中以「???」表示。

机遇：碎片化与异构性意味着没有独裁垄断。 不像 PC、Mobile 主要卷性能，IoT 硬件可向低功耗、小体积等多元化方向发展。

▸图源

ch1 IoT概述.pdf 第 16 页。「尚无固定终端类型」。下图按课件结构复绘。

1
2
3
4
5
6
7
+------------+------------+----------------+
|     PC     |   Mobile   |      IoT       |
| Windows    | Android    |      ???       |
| Linux      | iOS        | 异构开发板/模组 |
| macOS      | 手机形态   | 无单一标准终端 |
+------------+------------+----------------+
机遇：碎片化 = 无垄断；可走低功耗、小体积。

垂直一体化

挑战 3：应用开发架构仍属「垂直一体化」。 各行业方案从硬件、OS、传输、云到应用整条栈自建，跨生态复用困难。课件用两个「沙漏」刻画瓶颈：应用/算法 ↔ OS ↔ CPU/内存/存储；HTTP/MQTT/FTP ↔ TCP/IP ↔ Wi-Fi / 以太网 / 802.11。

三个垂直烟囱示例：

应用 云平台 传输 软件系统 硬件
Mosaic（空气质量地图） 阿里云 GPRS Arduino 定制监测节点
语音识别 腾讯云 Wi-Fi Debian 带散热的开发板
智能里程计 华为云 Cloud+ NB-IoT LiteOS（CLite） 智能仪表类终端

机遇：

  • Matter 协议利用区块链技术实现跨生态去中心化认证。
  • 开源云平台软件 ThingsBoard、IoTSharp 等，使「标准化」的物联网应用开发成为可能。
▸Matter 与分布式合规账本

Matter 由 CSA（Connectivity Standards Alliance，连接标准联盟）推动，目标是智能家居跨厂商互操作。去中心化认证的具体机制是 DCL（Distributed Compliance Ledger，分布式合规账本）：许可链上存放厂商、产品型号、认证状态以及 PAA（Product Attestation Authority，产品证明机构）根证书。设备入网（commissioning）时，Commissioner 从 DCL 拉取 PAA，校验设备 DAC（Device Attestation Certificate，设备证明证书）证书链，从而在不依赖单一厂商中心的前提下完成跨生态认证。DCL 基于 Cosmos SDK / CometBFT，公开可读、按角色受限写入。

▸图源

ch1 IoT概述.pdf 第 17 页。「垂直一体化与沙漏瓶颈」。下图按课件结构复绘。

课件左为两个沙漏（应用/算法 ↔ OS ↔ CPU/内存/存储；HTTP/MQTT/FTP ↔ TCP/IP ↔ Wi-Fi/以太网/802.11），右为三条行业烟囱：

层 Mosaic 语音识别 智能里程计
应用 地图查询 波形/语音 UI 仪表盘
云 阿里云 腾讯云 华为 Cloud+
传输 GPRS Wi-Fi NB-IoT
软件 Arduino Debian LiteOS
硬件 Arduino 节点 MCU 板 里程计传感

机遇：Matter（跨生态认证）、ThingsBoard / IoTSharp（开源云）使标准化开发成为可能。


▸思考题 1

问：典型物联网应用架构包括哪些部分？物联网开发与传统 PC 程序开发有何不同？

答： 典型架构包括物联网设备、网关、物联网云平台、客户端四段，经 BLE/NB-IoT/Wi-Fi/GPRS 等无线与互联网互联。与 PC 开发的差异至少有三点：（1）开发链覆盖嵌入式 + 云 + 用户端，而非单一桌面/Web 栈；（2）终端形态未收敛，硬件异构、功耗与体积约束强；（3）产业仍多垂直一体化，缺少 PC 那样稳定的水平分层与统一 OS/协议中枢，需依赖 Matter、开源云平台等推动标准化。


应用


鸿山

无锡鸿山物联网小镇地处无锡国家传感网创新示范区，是全国首个以物联网为产业特色的小镇，并入选江苏省首批特色小镇。阿里巴巴、华为、中电海康、西门子、中国移动、中国电信等入驻。

四个「全国第一」：第一个虚拟人文体验小镇；第一个千兆网络全覆盖小镇；第一个 NB-IoT/5G 小镇；第一个物联网创新小镇。

生活侧示例：垃圾桶感知满溢；红绿灯按路况变换；火灾感知后消防自动启动；土壤缺水时喷洒自动开关。土壤传感、洒水车、绿地浇灌器、中水处理站、天气预测组成互联信息平台，同时提升自然资源与人力资源利用效率。

基础设施： 针对环保、城管、公安、交通、教育、健康等示范项目优先布设传感器，形成五类传感群——智能交通、智能生态、智能能源、智能农业、公共服务。智能交通传感群设备包括：智能停车闸口、停车场传感器、单车停放点电子围栏、RFID 电子车牌、路口灯控、路口信号机、公交车位置传感器、公交车车载传感器等。

飞凤城市物联网平台： 云平台支持异构节点接入，是上层创新应用的基础。阿里云飞凤提供开发运行一站式服务（后演变为阿里云物联网平台），含四类开发：

能力 内容
硬件开发 设备、模组的开发集成管理
数据开发 接入、清洗、建模、加工
应用开发 网页控制台、移动应用
服务开发 服务构建及配套能力组件

智能楼宇： 室内外环境、烟感报警、工位监测与久坐提醒、饮水情况；能效评级与人均能耗、会议室温度设定、近一周用水用电能耗排名。

其他应用：

应用 机制
智能垃圾桶 监测容量，达阈值预警，环卫按需清运，避免沿线巡检
智能井盖 鸿山约 200 个；井盖下方传感器，倾斜超过 30° 自动报警；人为移动可及时监测
智能消防 传感器 + 边缘计算网关提早发现火情；提醒城管与交警疏散；水源感知系统实时调节消防栓水压

【此处插入：鸿山智能楼宇监测界面截图（环境/工位/能耗）】

▸图源

ch1 IoT概述.pdf 第 23–24 页。第 23 页室内环境/烟感/工位/饮水；第 24 页能效评级、人均能耗、会议室温度、近一周用水用电排名。无法准确复绘。


GIoTTO

CMU 在 Google 资助下开展 GIoTTO 智慧校园项目（IoT Expedition 的软件基础设施）。目标：让传感器、设备、楼宇互相通信，把校园变成 Living Lab；提供终端用户可开发自己物联网应用的工具；为非智能设备与环境添加物联网能力。名称借自文艺复兴画家乔托·迪·邦多纳（Giotto di Bondone），意在引领物联网革新。

三层架构：

层 组成 作用
应用程序服务层 IoT 应用 / 终端用户环境；应用开发环境 提供标准 API，方便用户开发
数据管理层 IoT 抽象 / ML；时序库与控制器；边缘分析与云；数据集成与中间件 中心部分：数据集成、云与边缘分析计算、数据控制、机器学习
数据产生层 传感器 / 执行器 大量传感器与执行器

四个主要特点：终端用户可编程；支持应用广泛部署；支持机器学习；安全与隐私保护。

▸图源

ch1 IoT概述.pdf 第 27 页。「GIoTTO 系统架构」。下图按课件结构复绘。

1
2
3
4
应用程序服务层  --标准 API-->  终端用户可编程
数据管理层      --集成/云边分析/ML/访问控制-->  中心
数据产生层      --大量传感器与执行器
四点：终端用户可编程 | 广泛部署 | 机器学习 | 安全与隐私

数据管理层内部：

编号 组件 技术 职责
1 中心服务器 MongoDB 数据管理层核心；托管传感器列表、用户列表、建筑物结构列表、访问控制列表（建筑及用户元数据）；经 HTTP 与应用程序交互
2 数据服务器 InfluxDB 存储与管理时间序列传感数据
3 连接器 BACnet、BLE、ZigBee 等 各类物联网设备与 GIoTTO 之间的通信；经 HTTP 写入数据服务器
4 机器学习层 分类器 / 虚拟传感器 帮助用户轻松处理传感数据
▸图源

ch1 IoT概述.pdf 第 28 页。「CMU GIoTTO 数据管理层」。下图按课件结构复绘。

1
2
3
4
            +-- 1 中心服务器 MongoDB（传感器/用户/建筑/ACL）
用户/应用 --+-- 2 数据服务器 InfluxDB（时序）
            +-- 3 连接器（设备 <-> GIoTTO）
            +-- 4 机器学习层（虚拟传感器）

机器学习层工作过程：

  1. 用户选择特定数据并打标签。
  2. ML 层训练分类器，得到虚拟传感器。
  3. 虚拟传感器实时分类，进行状态监测。

优势：向用户隐藏大量传感器细节；用户只需按常识选择可能适用的传感器，不必自行确定阈值等细节，降低开发难度。虚拟传感器把多路原始信号（运动、音频、视觉等）映射为高层事件（如「门开/关」）。

▸图源

ch1 IoT概述.pdf 第 29 页。「机器学习层」。下图按课件结构复绘。

1
2
用户打标签 --> 训练分类器 --> 虚拟传感器 --> 实时状态监测 --> 终端用户
物理传感器细节对用户隐藏，不必自定阈值。
▸安静且有空座的教室

已部署：声音传感器；每个座位的加速度计。

  1. 虚拟传感器 1（虚拟分贝计）：用声音数据训练，区分嘈杂 / 安静。
  2. 虚拟传感器 2（座位占用）：用椅上加速度计训练，区分有人 / 无人。
  3. 二者合取：检测安静环境下的空闲座位。

开发者操作的是「安静？」「有人？」两个逻辑量，而不是原始分贝波形或加速度阈值。

安全与隐私：

机制 作用
HTTPS 在 HTTP 基础上加密通信（用户端 ↔ 数据服务器 / 中心服务器）
OAuth 2.0 用户认证授权。用账户名、密码登录中心服务器后获得唯一 ID 与密钥；访问 GIoTTO 数据库前须用 ID+密钥换取 OAuth 令牌；令牌过期后必须重新生成
访问控制层 管理员：可访问全部传感器数据，并定义普通用户权限、制定 ACL。普通用户：仅按 ACL 访问
▸图源

ch1 IoT概述.pdf 第 31 页。「安全与隐私」。下图按课件结构复绘。

1
2
3
用户端 --HTTPS--> 中心服务器 --OAuth 2.0 令牌--> 数据访问
登录后得 ID+密钥；凭此换 OAuth 令牌；令牌过期须重签。
ACL：管理员 / 普通用户 两类。

Mosaic

空气质量指数 AQI 综合粒子浓度、臭氧、二氧化碳、二氧化硫等。颗粒物（PM）是重要因素：

  • PM2.5：粒子直径小于 2.5 µm
  • PM10：粒子直径小于 10 µm

传统监测：

方法 问题
卫星遥感 粗粒度，主要反映高层大气
地面监测站 造价与维护昂贵，部署稀疏

Mosaic：设计低成本监测节点，用先进校准方法，安装在移动车辆上，对城市空气质量做细粒度监测。相关工作包括 INFOCOM 2016 的 Mosaic 系统与 TOSN 上的两阶段校准论文（浙大董玮、高艺等）。

架构：

  • 应用层：微信、Web、手机 App；经 API 访问云。
  • 云服务层：阿里云。收集 Mosaic 原始传感数据、高精度空气监测站数据、较高精度 Dylos 手持设备数据。核心服务：云端数据校准。
  • 传输：室外侧重 GPRS（也可 Wi-Fi）；室内 miniMosaic 用蓝牙与手机通信。
  • 节点：Mosaic v1 / v2 用于室外；miniMosaic 用于室内。
▸图源

ch1 IoT概述.pdf 第 33 页。「Mosaic 架构」。下图按课件结构复绘。

1
2
3
4
5
6
7
用户端 Web / App
    ^
阿里云（校准；汇聚 Mosaic / 监测站 / Dylos）
    ^
GPRS & 蓝牙（室内 miniMosaic 走蓝牙）
    ^
节点 Mosaic v1/v2（室外） / miniMosaic（室内）

粒子传感器原理（光散射法）： 风扇向上提供稳定空气流；激光发射器发出一束红外激光；激光照射气流，被粒子反射（散射），由光传感器接收；根据反射强弱估计粒子浓度。光路通常经透镜聚焦到感应点，再经透镜收集到光电探测器。

传感器 光源 风扇 可测最小直径 / µm 价格 / 美元 准确性
PPD42NS LED 无 1 7 低
SDS011 激光 有 0.3 28 中
Dylos 激光 有 0.1 700 高

无风扇、LED、低价传感器噪声大、分辨率差；有风扇的激光传感器气流更稳、可测更小粒子。Dylos 精度高但成本高两个数量级，适合作为参考，不适合大规模车载部署。

▸图源

ch1 IoT概述.pdf 第 35 页。「粒子传感器测量原理」。下图按课件结构复绘。

1
2
3
风扇 -> 稳定气流
红外激光 -> 粒子散射 -> 光传感器  =>  反射强弱 ~ 浓度
对照表见上文 PPD42NS / SDS011 / Dylos（课件同页照片+表）。

节点数据预校准： 同环境下 PPD42NS、SDS011、Dylos 的 PM2.5 曲线趋势相近，但 PPD42NS 抖动极大，SDS011 整体偏低，Dylos 更平滑。原始读数不可直接互比，必须校准到统一参考。

【此处插入：Dylos / PPD42NS / SDS011 预校准对比曲线】

▸图源

ch1 IoT概述.pdf 第 36 页。三款传感器同环境 PM2.5 预校准曲线。无法准确复绘。

部署： 节点安装在公交等移动车辆上，用少量节点覆盖城市多 POI（论文在测试城区覆盖 70+ POI）。车载气流扰动是低成本光散射传感器的主要误差源之一，硬件上需设计气流结构，软件上常用 GPS 辅助滤波。

【此处插入：Mosaic 车载节点部署照片】

▸图源

ch1 IoT概述.pdf 第 37 页。车载 Mosaic 节点部署照片。无法准确复绘。

云端（运行时）多跳校准： 当 Mosaic 移动节点与另一高精度参考节点相遇，形成一个匹配点；多次相遇得到多个匹配点；移动节点用这些匹配点建立校准模型。参考站稀疏，移动节点可通过「先与参考站校准、再与其他移动节点相遇」形成多跳传递，故称在线多跳校准。

【此处插入：城市路网轨迹 + 参考节点（三角）匹配点示意图】

▸图源

ch1 IoT概述.pdf 第 38 页。路网轨迹与高精度参考节点（三角）相遇匹配点。无法准确复绘。

二阶段校准模型：

$$
Y = b_0 + b_1 x_1 + b_2 x_2 + \cdots + b_n x_n + \mathrm{RF}(x_1,\ldots,x_n)
$$

前半为多元线性部分，后半为随机森林拟合的残差（非线性部分）。

步骤 做法
特征提取 粒子传感器原始数据 + 温湿度、速度、人流密度、车流密度等
特征选择 AIC（Akaike Information Criterion，赤池信息准则）选出最相关特征，防止过拟合
第一阶段 多元最小二乘估计线性系数 $b_i$
第二阶段 随机森林拟合线性模型残差
▸为何不用一元线性校准

一元线性只用单一原始读数拟合真值，无法吸收湿度吸湿、车速气流、交通排放等协变量，也无力刻画传感器饱和、漂移等非线性。二阶段「线性主趋势 + RF 残差」在保持可解释主效应的同时补偿非线性；AIC 控制特征数目，避免把无关变量塞进线性部分。TOSN 论文报告相对既有方法，PM2.5 等级准确率约提升 16.4%。

▸图源

ch1 IoT概述.pdf 第 39 页。「二阶段校准」。下图按课件结构复绘。

1
2
3
4
特征（粒子+温湿度+速度+人/车流）--AIC 选择-->
第一阶段 MLS 线性  Y 的线性部分
第二阶段 RF 拟合残差
Y = b0 + b1 x1 + ... + bn xn + RF(x1..xn)

用户端： Mosaic App 提供路网点位图、网格热力图（AQI 色标 0–500）以及 PM2.5 时序曲线；可按节点（室内/室外）与日期筛选。示例：浙大玉泉则通楼室外，某日 11:00 PM2.5 = 80 µg/m³，温度 25°C，湿度 53%。

【此处插入：Mosaic App 地图 / 热力图 / 时序查询界面】

▸图源

ch1 IoT概述.pdf 第 40 页。Mosaic 用户端：地图、热力图、时序界面（多张截图）。无法准确复绘。


港珠澳

港珠澳大桥连接珠海、澳门、香港，全长 55 km。建设期已部署数千个不同类型传感器，属于大型结构健康监测（SHM）。

既有数字化局限：

局限 含义
数据异常，多源数据时间不对齐 模拟量 / 数字量 / 光信号 / 视频 / 定位 时钟不同步
有线传输，硬件部署、软件更新困难 桥路环网 + 岛隧环网，扩容与升级成本高
数据质量不高，特别是定位数据 高精度定位子系统精度与可用性不足

既有架构：管理局监控中心（数据处理与控制服务器、流媒体服务器、中心交换机）经桥路环网、岛隧环网连接各桥段/岛隧段工作站与 cRIO（CompactRIO，实时嵌入式工业控制器），再接采集设备与模拟量 / 数字量 / 光信号传感器，并含高精定位与高清监控子系统。

▸图源

ch1 IoT概述.pdf 第 42–43 页。「港珠澳结构健康监测既有架构」。下图按课件结构复绘。

1
2
3
4
5
6
管理局监控中心（处理/流媒体/中心交换）
    |  桥路环网 / 岛隧环网
各段工作站 + cRIO
    |
模拟量 / 数字量 / 光信号传感器 + 定位 + 高清监控
第 42 页为大桥全景照片，无法复绘。

新型物联网硬件平台（2019.11–2023.11）：

阶段 边缘计算板 传感器组合 要点
测试段 RK3399 IMU + 环境（485 环境百叶箱×2、雨雪、高精度 IMU） 实时北斗接入、5G 高速传输；11 类传感器（温湿度、雨雪、噪声等）；10 类接口（RS485、UART、USB、GPIO 等）
大规模部署 RK3588 IMU + 环境 + 音频（雨雪、百叶箱、光照、USB 麦克风阵列、高精度 IMU、风速风向） 算力约翻倍、国产化；环境耐久与三防加固；网状直连改为工业级 5G 路由器桥接

中间迭代包括天气传感器重选型与加固、IMU 重选型、核心板迭代与联调。

▸图源

ch1 IoT概述.pdf 第 44 页。「新型物联网硬件平台」。下图按课件结构复绘。

1
2
3
2019.11  RK3399 测试段（IMU+环境，5G，北斗）
   |     传感器/IMU 重选型与加固、核心板迭代
2023.11  RK3588 大规模（+音频；5G 路由器桥接）

部署： 小规模测试 + 大规模正式部署共 63 套，覆盖桥（青州桥、九州桥、江海桥）、岛（东、西人工岛）、隧全地形，运行稳定。西人工岛等处使用太阳能供电。

【此处插入：青州/九州/江海桥与东西人工岛、岛隧连接处现场部署照片】

▸图源

ch1 IoT概述.pdf 第 45 页。桥/岛/隧现场部署照片。无法准确复绘。

云边端融合软件平台： 基于 Edge-Native 基座（EdgeStack / KubeEdge）。版本演进：v1.0 共 16 个基础模块；v2.0 增加 13 个进阶模块；v3.0 凑齐 35 个模块，实现云边协同、安全传输、实时计算、时钟同步、数据缓存与压缩。

功能柱包括：① 自适应传输（5G 链路感知压缩与缓存、秒级带宽预测、RabbitMQ 控制/数据报文、fluentbit 缓存、SQLite 存储）；② 计算迁移与数据处理（多源多模态融合、基于注意力网络的异常检测、NTP 时钟同步、逻辑块自适应迁移、异构协议转换、数据标准化）；③ 轻量编排与实时性（边侧云边协同计算、细粒度资源分配、瓶颈与时延建模、cAdvisor 性能采集）；④ 边缘系统平台（EdgeHub、元数据、Event Bus、通用传感器协议 mapper、轻量运行时）。云侧含 KubeEdge 控制器、边缘数据可视化；业务侧含极端天气（风）预警、多路视频流分析、桥梁结构健康云边协同计算；安全含 RBAC、HTTPS/RTMPS、基于 eFuse 的可信镜像、CA 证书设备认证。

【此处插入：港珠澳云边端融合软件架构全图（v1.0/2.0/3.0 色块）】

▸图源

ch1 IoT概述.pdf 第 46 页。云边端融合软件平台全图（v1.0/2.0/3.0 色块模块，结构过密）。无法准确复绘。

结构健康监测应用： 5G IoT +「端—边—云」无线监测；北斗基准站 / 监测站高精度定位；监测数据实时计算、报警与关键指标展示；监测速报快速生成。引入流计算后：数据处理能力提升 850%，计算平均时延降低 98.1%。

【此处插入：5G 端边云部署、北斗测站、实时曲线与速报界面、850%/98.1% 指标】

▸图源

ch1 IoT概述.pdf 第 47 页。5G 部署、北斗测站、实时曲线/速报界面；数据处理 +850%、时延 −98.1%。无法准确复绘。


▸思考题 2

问 1：GIoTTO 如何保证安全性？机器学习层起什么作用？

答： 传输用 HTTPS；认证授权用 OAuth 2.0（登录中心服务器得 ID+密钥，再换令牌访问数据服务，令牌过期重签）；访问控制层用管理员 / 普通用户 + ACL。机器学习层把原始传感数据训练成虚拟传感器，向用户隐藏阈值与多传感器融合细节，降低应用开发难度，并支撑「安静空座教室」这类高层事件。

问 2：Mosaic 中 PM2.5 测量原理？一元线性校准有何缺陷？

答： 光散射法：风扇维持稳定上升气流，红外激光照射粒子，散射光由光电传感器接收，强度对应浓度。一元线性只用单一原始读数拟合真值，忽略温湿度、车速、人车流等协变量，也无法拟合非线性残差与漂移，移动场景下误差大。应采用 AIC 选特征 + 多元线性 + 随机森林残差的二阶段模型，并结合与高精度参考站相遇的多跳校准。


前沿

物联网学术前身与近邻领域：

领域 要点
RFID（Radio Frequency Identification，无线射频识别） 典型系统 = 一个有源阅读器 + 若干无源标签；应用：身份识别、供应链、仓储
普适计算（Pervasive / Ubiquitous Computing） 任何时间、地点都可计算；特别关注用户行为与所处环境，即上下文感知
WSN（Wireless Sensor Network，无线传感器网络） 集成计算、感知、通信的微型节点，多跳传输；二十余年已形成较完善软硬件体系

四条关注点及其演进：

方面 演进
供电与节能 电池 → 可再生能源 → 无源后向散射；持续研究中
节点平台 集成封闭 → 开放、组件更丰富：MicaZ、TelosB → Arduino、LinkIt One、树莓派
通信与组网 多跳 → 单跳：多跳 ZigBee → BLE、LoRa、NB-IoT
智能感知 简单温湿度/光照 → 精确手势、智能人机交互；计算方式变革：边缘计算
▸图源

ch1 IoT概述.pdf 第 51 页。「关注点及其前沿挑战」。下图按课件结构复绘。

方面 演进
供电与节能 电池 → 可再生能源 → 无源后向散射
节点平台 MicaZ/TelosB → Arduino/LinkIt/树莓派（更开放、组件更丰富）
通信与组网 多跳 ZigBee → 单跳 BLE / LoRa / NB-IoT
智能感知 简单阈值 → 更智能；计算下沉为边缘计算

供电


占空比

（Duty Cycle）

低工作占空比模式： 系统仅工作少量时间，其余大部分时间处于睡眠。

▸占空比直觉

把 100 秒看成一整段：若 $D=1%$，大约只「醒着干活」1 秒，其余 99 秒睡眠。射频一开往往是百 mA，睡眠可到 μA，所以拉低 $D$ 是物联网节点续航的第一手段。注意：睡眠电流不是 0，也不能无限把 $D$ 压到 0（还要采样、还要听有没有下行）。

节点生命周期（不考虑自放电）：

$$
T = \frac{C}{I_{\mathrm{avg}}}
$$

其中 $C$ 为电池容量（mAh），$I_{\mathrm{avg}}$ 为平均电流（mA），$T$ 单位为小时。

若工作电流 $I_{\mathrm{w}}$、休眠电流 $I_{\mathrm{s}}$、工作占空比 $D$（$0\le D\le 1$）：

$$
I_{\mathrm{avg}} = I_{\mathrm{w}} D + I_{\mathrm{s}}(1-D)
$$

▸课件例：占空比 10%

已知 $C=2800,\mathrm{mAh}$，$I_{\mathrm{w}}=20,\mathrm{mA}$，$I_{\mathrm{s}}=0.5,\mathrm{mA}$，$D=10%$。

若始终工作：$T=2800/20=140,\mathrm{h}$。

引入占空比：
$$I_{\mathrm{avg}}=20\times 0.1 + 0.5\times 0.9=2+0.45=2.45,\mathrm{mA}$$
$$T=2800/2.45\approx 1142,\mathrm{h}$$

寿命约为始终工作的 $1142/140\approx 8.2$ 倍。休眠电流并非 0，占空比再低，$I_{\mathrm{avg}}$ 也不会低于 $I_{\mathrm{s}}$。

▸思考题 3（占空比 1% + 自放电）

仍取 $C=2800,\mathrm{mAh}$，$I_{\mathrm{w}}=20,\mathrm{mA}$，$I_{\mathrm{s}}=0.5,\mathrm{mA}$。

（1）$D=1%$，不计自放电。

$$I_{\mathrm{avg}}=20\times 0.01 + 0.5\times 0.99=0.20+0.495=0.695,\mathrm{mA}$$
$$T=2800/0.695\approx 4028.8,\mathrm{h}\approx 167.9,\mathrm{d}$$

（2）$D=1%$，自放电为每天释放初始电量的 $0.5%$。

课件明确按初始容量的固定比例，而非剩余容量指数衰减：

  • 每日自放电：$0.005\times 2800=14,\mathrm{mAh/d}$
  • 每日电路消耗：$0.695,\mathrm{mA}\times 24,\mathrm{h/d}=16.68,\mathrm{mAh/d}$
  • 每日总消耗：$14+16.68=30.68,\mathrm{mAh/d}$
  • $$T_{\mathrm{day}}=2800/30.68\approx 91.3,\mathrm{d}\approx 2190,\mathrm{h}$$

自放电一项已与电路消耗同量级，低占空比节点必须把自放电计入，否则寿命会被高估约 $167.9/91.3\approx 1.84$ 倍。

若题目改成「每天释放剩余电量的 0.5%」，则需递推 $C_{k+1}=0.995 C_k-16.68$，或连续近似 $\mathrm{d}C/\mathrm{d}t=-0.005 C - 0.695$，闭式 $C(t)=C_0 e^{-0.005 t}-0.695/0.005$，令 $C(T)=0$ 求解。课件原题不是这种表述。

▸单位与常见错算
  • mAh 与 mA 相除得小时，不要把 2800 mAh 当成 2800 Ah。
  • $D$ 是工作时间比例，睡眠比例是 $1-D$，不要写成 $20\times 10%+0.5\times 10%$。
  • 「每天 0.5%」若未写明「初始」，考试应先按课件「初始电量」做常数漏电；若明确是剩余比例，再改用指数模型。

储能与无源

使用太阳能、风能等可再生能源时，常见两种储能：

储存能量技术 优点 缺点
充电电池 自放电较少，电能利用率比较高 充电效率较低，充电次数有限
超电容 充电效率高；充电次数可达万次；不易受温度、振动影响 自放电大，尤其接近满电容时；需设计能量自适应机制，确保两次充电之间正常工作

无源后向散射： 区别于 RFID，实现 tag 与 tag 之间的通信。代表：环境后向散射（ambient backscatter，Liu et al., SIGCOMM 2013）。

对比 传统 RFID 后向散射 环境后向散射
载波来源 专用阅读器发射约 1 W 连续波 环境中已有的 TV / 蜂窝等射频
通信对象 标签只与阅读器通信，标签之间互不可见 Alice 标签 ↔ Bob 标签 直接通信
功耗 阅读器接收链数百 mW；标签仍无源 标签收发均可无电池；接收链约 0.5 µW 量级
部署 必须安装阅读器基础设施 不额外消耗能量，不依赖专用供电设施
对原业务 — 对电视等原接收端表现为附加多径

调制方式：标签用开关在「反射 / 不反射」间切换，对入射波做开关键控；原型约 1 kbps、室外约 2.5 英尺、室内约 1.5 英尺。供电演进可记为：电池占空比节能 → 能量采集 + 电池/超电容 → 完全无源后向散射。

▸图源

ch1 IoT概述.pdf 第 54 页。「无源后向散射（Ambient Backscatter）」。下图按课件结构复绘。

1
2
3
4
5
TV 塔 ----环境电磁波---->  Alice（反射调制，作发送）
                         |
                         v
              Bob（接收）     电视（同时接收广播）
区别于 RFID：实现 tag–tag 通信，不自建大功率射频。

平台

区别于早期资源极度受限的 Things，智能硬件平台（如树莓派）扩展性与性能大幅提升，节点异构性进一步加剧。

特征 PC-Like Embedded Smart Things Things
市场规模 ~1 亿 ~8 亿 ~90 亿
例子 ATM、零售 POS PLC、边缘网关、恒温器 温度传感器、灯泡
典型硅片（BOM） Intel Core（$100+） ARM Cortex-A7、Intel Atom（$5–50） MCU（$0.50–5）
典型 OS Windows Embedded、Linux QNX、Wind River、Android Things FreeRTOS
典型运行时 Win32 Node.js、Python、C API C API
MSFT 产品 / 费用 Windows IoT Enterprise（$30–120 + 服务） Windows IoT Core（$0 + 服务） —

体积越大、单价越高、软件栈越重；出货量则相反。物联网同时覆盖这三档，因此不存在单一「标准终端」。

▸图源

ch2.pdf 第 5 页。「物联网硬件平台分类」。下图按课件结构复绘。

完整对照表已见上文「平台」节。课件原表还含 MSFT 产品价位；笔记表按课件字段整理。

构建通用传感器节点平台需要数十年经验才能同时满足感知、功耗、软硬件兼容性。——Prabal Dutta, SenSys 2008。

Microsoft .NET Gadgeteer： 模块化硬件（主板 + 编号插座 + 排线外设）+ 高层软件工具（C#，如 GTM.Button / GTM.MulticolorLED）+ 物理外观设计一体化，降低节点构建门槛。

【此处插入：.NET Gadgeteer 主板插座、外设模块与 C# API 截图】

▸图源

ch1 IoT概述.pdf 第 56 页。.NET Gadgeteer 主板插座、外设与 C# API。无法准确复绘。

TinyLink（Guan, Dong et al., ACM MobiCom 2017, Best Video Award；浙大）：整体化的物联网应用快速开发系统。核心思想是自顶向下：开发者用类 C 语言只写应用逻辑，不绑定具体硬件；系统自动生成硬件配置与目标平台可执行文件，并提供统一 TL_ API。

1
2
3
4
5
6
7
8
9
10
void setup() {
  TL_WiFi.init();
  TL_WiFi.join("SSID", "PASSWORD");
  TL_Light.setMeasuringRange(1, 30000, "LUX");
}
void loop() {
  TL_Light.read();
  TL_Soil_Humidity.read();
  // ...
}

系统分析用户代码后给出硬件连接图（如 Grove 光照 → A0，温湿度 → D2，土壤湿度 → A2，开发板 Arduino Uno）并交叉编译烧写。评价：平均减少约 52.58% 代码行；搜索更大硬件设计空间，配置优于既有方法；执行时间与程序存储开销可接受。支持 Arduino UNO、LinkIt One、BeagleBone Black、Raspberry Pi、Tiny BLE 等及 100+ 传感器。

▸图源

ch1 IoT概述.pdf 第 57 页。「TinyLink」流程。GUI/实物为截图与照片，结构按下图复绘。

1
写 TL_* 应用代码 --> 云端分析+交叉编译 --> 硬件连接图/BOM --> 组装 --> 烧写

组网

按「覆盖（短距 / 长距）」×「网络性能要求」划分：

区域 技术
高带宽 + 长距 5G、LTE-V 等
中等性能 + 短距 Wi-Fi、UWB
低性能 + 短距 Bluetooth、ZigBee
长距低功耗（LPWA） 上半：eMTC；下半：NB-IoT、LoRa、Sigfox

低功耗短距离： ZigBee / IEEE 802.15.4、蓝牙（含 BLE）。

LPWAN（Low-Power Wide-Area Network，低功耗广域网）：

NB-IoT LoRa
技术根基 基于 LTE 改进 专有物理层（CSS），需自建/共建基站
部署 技术成熟，可复用已有蜂窝基站 需部署 LoRa 基站
开放度 运营商蜂窝体系，二次开发受约束较多 技术开放程度更高，容易二次开发

组网形态从 WSN 时代的多跳 ZigBee 转向 BLE / LoRa / NB-IoT 等单跳或星型，降低路由复杂度与能耗。

▸图源

ch1 IoT概述.pdf 第 59 页。「通信与组网（性能 × 覆盖）」。下图按课件结构复绘。

1
2
3
4
5
6
性能 ^
高   |  5G / LTE-V                    
中   |  Wi-Fi / UWB     |  eMTC       
低   |  BLE / ZigBee    |  NB-IoT/LoRa/Sigfox   ← LPWA
     +------------------+------------------> 覆盖
         短距离              长距离

感知

智能感知计算的三个典型特征：

  1. 新的感知手段与感知场景不断涌现。
  2. 特别关注与人的交互。
  3. 催生新的通信与计算模式：边缘计算。

边缘

课件定义（与边缘计算产业联盟 ECC《边缘计算参考架构》一致）：边缘计算是在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的开放平台，就近提供边缘智能服务。

相对纯云：云路径时延常 >100 ms，边缘路径可 <10 ms。图中强调数据融合（去冗余）、实时应用（靠近应用端完成计算）、端与边缘协同以提升体验。

三大收益：降低传输；降低延迟；增加隐私性（敏感数据少出本地）。

▸图源

ch1 IoT概述.pdf 第 60–61 页。「边缘计算」。下图按课件结构复绘。

1
2
3
纯云：节点 --------------------> 云     时延常 >100 ms
边缘：节点 --> 边缘(融合/实时) --> 云   时延可 <10 ms
收益：降传输、降延迟、增隐私。
▸边缘与相关术语
  • ECC 定义强调靠近物/数据源的开放平台，以及敏捷联接、实时业务、数据优化、应用智能、安全与隐私。
  • ETSI MEC（Multi-access Edge Computing）强调在移动网络边缘为应用提供 IT 环境与算力。
  • 课程后文的网关、KubeEdge、Azure IoT Edge 都是这一思想的落地，不必把「边缘」等同于某一种产品。

案例

案例 1：微软 Azure 与三星 Centaurus。

Azure 把流分析（Stream Analytics）与 Azure Functions 从云下沉到边缘后，云端只保留数据库；IoT 节点旁即可完成流处理与函数计算。

评测：智能手机步行检测，加速度计 10 Hz × 20 小时。Centaurus（边缘）：本地分类后只上传分类结果；Cloud-Only：上传全部原始数据，云端计算。

上传方式 方案 数据量 / Kb 能耗 / mJ 时延 / ms 能效 / (mJ·Kb⁻¹)
WLAN Centaurus 27 148 237 0.97
WLAN Cloud-Only 55 487 66 827 84 788 0.42
HSPA Centaurus 27 3 069 2 896 64
HSPA Cloud-Only 55 487 1 048 766 545 826 15

数据量降至 $27/55487\approx 1/2055$。WLAN 总能耗约降至 $1/451$，时延约降至 $1/358$；HSPA 总能耗约降至 $1/342$，时延约降至 $1/188$。单位 Kb 能效 Centaurus 反而更差，因为短包固定开销占比高；比较的应是总能耗与总时延，不能只看 mJ/Kb。蜂窝（HSPA）单位比特远贵于 WLAN，边缘减流量在移动网下收益更大。

▸图源

ch1 IoT概述.pdf 第 62 页。「Azure 流分析/函数下沉 + Centaurus」。下图按课件结构复绘。

1
2
3
4
Cloud-Only: 上传全部加速度数据，云端计算
Centaurus:  端上分类，只上传分类结果
例：步行检测，手机 20 h 加速度 @10 Hz
评测数字以课件表为准，此处不臆造毫秒值。

案例 2：运营商 Wi-Fi 路由器 → 智能网关。

自下而上：底层 SoC → 操作系统 → 四类功能模块：

模块 内容
连接 Wi-Fi、ZigBee、蓝牙、蜂窝数据
管理 基于 Web 的配置；配置网关及其管辖的物联网设备
安全 物联网设备认证；用户数据隐私保护
计算和存储（与传统路由的最大不同） 存储介质、资源管理、运行时

IoT 数据可存储在边缘网关上，网关同时支持复杂数据分析处理。这正是「管」侧设备从单纯转发升级为边缘节点的关键。

▸图源

ch1 IoT概述.pdf 第 63 页。「Wi-Fi 路由器 → 智能网关」。下图按课件结构复绘。

1
2
3
4
        [连接] Wi-Fi / ZigBee / BLE / 蜂窝
SoC -> OS -> [管理] Web 配置网关与下属设备
        [安全] 设备认证、用户隐私
        [计算和存储]  ← 与传统路由的最大不同

复习

主题 必记
定义 感知 + 计算 + 连接；物理世界接入数字世界
年份 1995《未来之路》；2005 ITU；2009 智慧地球 / 感知中国；AIoT → 万物智联
连接数 2020：117 亿 IoT > 100 亿非 IoT；2025E：309 亿 ≈ 3× 非 IoT
架构 设备—网关—云—客户端；软件：RIOT / KubeEdge / ThingsBoard 等
三挑战 开发链长 → 低代码 + 大模型；无固定终端 → 多元化；垂直一体化 → Matter DCL + 开源云
GIoTTO 三层；MongoDB 元数据 + InfluxDB 时序；虚拟传感器；HTTPS + OAuth2 + ACL
Mosaic 光散射 PM2.5；PPD42NS/SDS011/Dylos；多跳匹配点；AIC + 多元线性 + RF 残差
港珠澳 55 km；三局限；RK3399→RK3588；63 套；流计算 +850% 能力、−98.1% 时延
供电 $I_{\mathrm{avg}}=I_w D+I_s(1-D)$，$T=C/I_{\mathrm{avg}}$；自放电按初始容量；电池 vs 超电容；ambient backscatter ≠ RFID
平台 Things / Smart Things / PC-Like；TinyLink 自顶向下，−52.58% LoC
组网 短距 ZigBee/BLE；LPWAN 中 NB-IoT 复用基站，LoRa 更开放
边缘 近源开放平台；降传输、降时延、增隐私；Centaurus 看总能耗而非 mJ/Kb

二、硬件

参考课件：ch2 硬件平台。目录：概述 → 关键特性 → 常见平台 → 案例开发 → 学术进展。

▸本章在整条链上的位置

「端」的躯壳：选哪块板、哪个 MCU（Microcontroller Unit，微控制器）、怎么接传感器、电池能撑多久。选错板，后面 OS 和射频都白搭；算不清电流，占空比再低也续航翻车。


概述

生活中的燃气报警器、智能车锁、智能电表均属物联网硬件。课件预测：到 2025 年全球物联网设备达 270 亿（与第一章 IoT Analytics「约 309 亿连接」口径不同：此处偏「设备台数」预测，复习时分开记）。

发展趋势：体积越来越小、价格越来越低。计算硬件尺寸约每十年缩小 100 倍（巨型机 → 工作站 → PC → 笔记本 → 智能手机 → 智能物联网硬件 → 智能物联网芯片），渗透从「每企业一台」到「每人多台」。

【此处插入：1950–2020 硬件尺寸对数下降曲线（每十年 ×1/100）】

▸图源

ch2.pdf 第 4 页。硬件尺寸对数下降曲线（约每十年 ×1/100）+ 智能物联网芯片照片。无法准确复绘。


分类

与第一章三档一致，本讲给出更完整的处理器 / OS / 运行时对照：

属性 类 PC 嵌入式 ≈1 亿 智能物件 ≈8 亿 物件 ≈90 亿
典型处理器 Intel Core ARM Cortex-A7、Intel Atom MCU
典型 OS Windows Embedded、Linux Linux、Wind River、Android Things Contiki、RIOT、HarmonyOS
典型运行时 Win32、Linux Node.js、Python、C API C API
典型设备 ATM、零售服务点 PLC、边缘网关 温度传感器、智能灯泡
能力定位 「缩小版 PC」，功能强大 可执行较复杂智能运算 功能较弱

狭义与广义

范围 组成
狭义硬件平台 开发板 + 其上的微控制器
广义硬件平台 狭义平台 + 传感模块 + 执行模块 + 通信模块
  • Arduino UNO 常作为狭义平台举例：MCU ATmega328P，主频课件表为 16 MHz、8 位、RAM 2 KB、Flash 32 KB（第 6 页插图若标 32 MHz，与第 11 页表及官方 UNO 规格不一致，考试以对照表 16 MHz 为准）。
  • MicaZ 常作为广义平台举例：Atmel MCU + 温湿度/光照传感 + 速率 <100 kb/s 的无线通信，单板即「端侧小系统」。
▸图源

ch2.pdf 第 6 页。「物联网硬件平台」。UNO/MicaZ 为实物照；框图按下述复绘。插图若标 UNO 32 MHz，以第 11 页表 16 MHz 为准。

1
2
3
狭义：开发板 + MCU
广义：狭义 + 传感 + 执行 + 通信
例：UNO = 狭义；MicaZ = 广义（MCU+温湿度/光+无线）

特性

四条关键特性：低成本与微型化、功耗/能耗、运算速度与内存、接口类型。


成本

节点廉价、微型 → 更高部署密度。价格参考 2022-03 淘宝：

开发板 价格 / 元 尺寸（长×宽）/ mm
TelosB 850 63.75×32
Arduino UNO 130 68.8×53.4
Arduino GEMMA 90 27.94×27.94
STM32F103 268 130×100
树莓派 4B 735 88×58

GEMMA 体积最小、UNO 性价比突出；TelosB / 树莓派更贵。选型时价格与尺寸需和功耗、算力一起权衡，不能单看便宜。


功耗

原则：功耗越低，运行时间越长。每个模块（计算、通信等）单独记账。

开发板 MCU 供电电压 / V 睡眠 工作
TelosB MSP430 1.8～3.6 2.6 μA 0.5 mA
Arduino UNO ATmega328 1.8～5.5 0.1 μA 0.2 mA

第 9 页工作电流 0.2 mA 与第 40 页「1 MHz 下 0.1 μA～0.2 mA」同量级，对应低主频条件；ATmega328 在 16 MHz / 5 V 全速时数据手册常见十余 mA。闭卷按课件表计算。TelosB 睡眠电流第 9 页为 2.6 μA，第 25 页特点中写 5.1 μA，测量条件不同，引用时标明出处。

模块在时间 $\Delta t$ 内的能耗：

$$
\Delta E=\sum_{i=1}^{n}\Delta t_i, I_i, p_i
$$

  • $i$：能耗状态（工作、睡眠，或多种低功耗态）
  • $n$：状态个数
  • $\Delta t_i$：处于状态 $i$ 的时间
  • $p_i$：状态 $i$ 的功率（注意是 W，不是电流）
  • $I_i$：指示变量，$\Delta t_i>0$ 则 $I_i=1$，否则 $0$

功率 $p=UI$。能量单位为焦耳：$\mathrm{J}=\mathrm{W}\cdot\mathrm{s}$。

▸Arduino UNO 1 s 半睡半醒

电压恒定 5 V，总时间 1 s：0.5 s 睡眠，0.5 s 工作。

$$p_1=0.1,\mu\mathrm{A}\times 5,\mathrm{V}=5\times 10^{-7},\mathrm{W}$$
$$p_2=0.2,\mathrm{mA}\times 5,\mathrm{V}=1\times 10^{-3},\mathrm{W}$$

$$
\Delta E=0.5\times 1\times 5\times 10^{-7}+0.5\times 1\times 1\times 10^{-3}
=2.5\times 10^{-7}+5.0\times 10^{-4}
=0.50025\times 10^{-3},\mathrm{J}
$$

与课件结果一致。睡眠项比工作项小三个数量级，总能量几乎等于工作段；但占空比很低时睡眠项会主导（见思考题 1）。

▸功耗计算易错点
  • 睡眠电流单位是 μA，工作电流是 mA，必须先统一再乘电压。
  • 公式里是功率 $p_i$，不是直接把 mA 当能量。
  • $\Delta E$ 是能量（J），不是「总功耗」口语；课件标题写「总功耗」，算的是这段时间的能量。

算力

运算速度一般用 CPU 主频描述。

CMOS 动态功耗（课件写作 $P=CV^{2}FT$）：

$$
P \propto C V^{2} f
$$

标准形式为 $P=\alpha C V^{2} f$，其中 $C$ 为负载电容，$V$ 为供电电压，$f$ 为主频，$\alpha$（课件中的 $T$）为翻转活动因子。含义：降电压比降频率更「省电」（平方项）；提主频会线性抬高动态功耗。

指令吞吐：若一条指令需 20 个时钟周期，16 MHz 的 Arduino MCU 在 1 s 内有 $16\times 10^{6}$ 个周期，可执行 $16\times 10^{6}/20=8\times 10^{5}$ 条该指令。

开发板 MCU 主频 位数 RAM Flash
TelosB MSP430 8 MHz 8 10 KB 48 KB
Arduino UNO ATmega328 16 MHz 8 2 KB 32 KB
STM32F103 Cortex-M3 72 MHz 32 64 KB 512 KB
树莓派 4B BCM2711 1.5 GHz 64 1/2/4/8 GB 由外接 SD 卡决定

RAM：存数据，易失。Flash：存程序，非易失，断电后程序仍在。树莓派程序与根文件系统在 SD 卡上，片上 Flash 不按 MCU 那套计量。

▸思考题 1
MCU 工作电压 / V RAM / KB Flash / KB 工作 / mA 睡眠 / μA
Msp430F2618 1.8～3.6 8 116 0.5 1.1
Msp430F5437 1.8～3.6 16 256 0.28 1.7

（1） char buf[10240]; 需要 10240 B ≈ 10 KB RAM。2618 仅 8 KB，放不下；应选 F5437。局部数组还占栈，10 KB 已超过 8 KB 上限，即使 Flash 足够也不能选 2618。

（2） 电压恒定 3 V，总时间 $T=10,\mathrm{s}$。能量 $E=V T\bigl(I_w D+I_s(1-D)\bigr)$，比较 $I_{\mathrm{avg}}$ 即可。把睡眠电流换成 mA：$1.1,\mu\mathrm{A}=0.0011,\mathrm{mA}$，$1.7,\mu\mathrm{A}=0.0017,\mathrm{mA}$。

$D=80%$：
$$I_{2618}=0.5\times 0.8+0.0011\times 0.2=0.40022,\mathrm{mA}$$
$$I_{5437}=0.28\times 0.8+0.0017\times 0.2=0.22434,\mathrm{mA}$$
F5437 更省（工作电流更低，高占空比时主导）。

$D=0.1%$：
$$I_{2618}=0.5\times 0.001+0.0011\times 0.999\approx 0.001599,\mathrm{mA}$$
$$I_{5437}=0.28\times 0.001+0.0017\times 0.999\approx 0.001978,\mathrm{mA}$$
F2618 更省（睡眠电流更低，极低占空比时主导）。

结论：高占空比比工作电流，低占空比比睡眠电流；不能只看「谁工作更省电」。


接口

物理接口

方式 连接 风险
引脚 + 杜邦线 逐针插拔 过程复杂、易接错；接错可导致程序不工作，甚至烧坏外设与主板
Grove port / 连接套接口 Grove 线 接入快、不易接错

【此处插入：杜邦线引脚 vs Grove port 对比照片】

▸图源

ch2.pdf 第 13 页。杜邦线引脚 vs Grove port。无法准确复绘。

通信协议（主板↔外设常见 6 种）

协议 全称 要点
Analog 模拟信号 连续模拟量，需 ADC 数字化
Digital 数字信号 离散电平序列
PWM Pulse-Width Modulation，脉冲宽度调制 基于数字脉冲，用占空比等效模拟量（调光、调速）
UART Universal Asynchronous Rx/Tx 异步、逐位、全双工
I2C Inter-Integrated Circuit（Philips） 两线串行总线，多从设备
SPI Serial Peripheral Interface 高速、全双工、同步

UART 缓存与波特率

课件约定：每帧 11 位 = 8 位数据 + 2 位标识（起始+停止）+ 1 位校验。接收缓存只存数据位。忽略接收响应时间，中断处理时间 $t_{\mathrm{isr}}$ 内到达的比特数为 $B\cdot t_{\mathrm{isr}}$（$B$ 为波特率，单位 Bd/s，即 bit/s）。

$$
N_{\mathrm{byte}}=\left\lceil\frac{B\cdot t_{\mathrm{isr}}}{11}\right\rceil
\quad\text{（因 } \frac{B t_{\mathrm{isr}}\times 8/11}{8}=\frac{B t_{\mathrm{isr}}}{11}\text{）}
$$

当 $t_{\mathrm{isr}}=1,\mathrm{ms}=10^{-3},\mathrm{s}$，$B=9600$：

$$
N_{\mathrm{byte}}=\left\lceil\frac{9600}{11000}\right\rceil=\lceil 0.873\rceil=1
$$

与课件「$B/11000$，向上取整为 1 字节」一致。

▸思考题 2

$B=9600,\mathrm{Bd/s}$，$t_{\mathrm{isr}}=2,\mathrm{ms}$。
$$N_{\mathrm{byte}}=\left\lceil\frac{9600\times 0.002}{11}\right\rceil=\left\lceil\frac{19.2}{11}\right\rceil=\lceil 1.745\rceil=2$$
接收缓存应至少 2 字节。相对 1 ms 例题，中断加倍则到达数据约加倍。

业界更常见的是 8N1（1 起始 + 8 数据 + 1 停止 = 10 位、无校验）。本题必须用课件的 11 位帧，不要改成 10。

▸换波特率：115200 Bd、1 ms

$$N=\left\lceil\frac{115200\times 0.001}{11}\right\rceil=\lceil 10.47\rceil=11$$

相对 9600 Bd 约快 12 倍，1 ms 内到达的数据字节也大约变成 12 倍。缓存按「最坏到达量」取整，宁可多留 1 B，不可算成向下取整。若误用 10 位帧：$\lceil 115200\times0.001/10\rceil=12$，答案会偏大——考试必须跟课件 11 位。

可扩展性：开发板对外接设备种类与数量的支持程度；接口数量与接口类型是主要指标。

平台 Digital Analog PWM UART I2C SPI
树莓派 4B 28 0 2 6 6 5
BeagleBone Black 65 7 8 4 2 2

树莓派 无原生 Analog；BBB 数字口与模拟口都更多。课件结论：BeagleBone Black 可扩展性优于树莓派（就片上接口种类/数量而言）。树莓派可通过 GrovePi+ 等盾板补 Analog，那是板级扩展，不是 SoC 原生接口。


平台

平台类型 分类 厂商 说明
传感节点 物件 加州大学伯克利分校等 高度集成，专为低功耗 WSN
STM32 物件 ST（意法半导体） Cortex-M，从低功耗到高性能，外设与工具链丰富
ESP32 物件 乐鑫 Espressif 集成 Wi-Fi + 蓝牙，双核，低功耗
Arduino 物件 Arduino Srl 等开源生态 编程简单、社区大，适合教学与原型
树莓派 智能物件 树莓派基金会 ARM 单板计算机，完整 OS，算力较高
Jetson 智能物件 NVIDIA GPU 边缘 AI，CUDA / OpenCV 等

传感节点

【此处插入：野外大规模节点部署航拍 + 多跳拓扑（汇聚节点标红）】

▸图源

ch2.pdf 第 20–21 页。传感网野外部署航拍与多跳拓扑（汇聚节点标红）。无法准确复绘。

无线传感器研究约始于 20 世纪 90 年代，早期两条主线：

主线 机构 / 项目 节点
低功耗集成 UCLA LWIM；后与 Rockwell 合作 WINS LWIM 节点、WINS
微型化 UCB SmartDust 1999 WeC，其后 Mica、Mica2、Mica2Dot、MicaZ

发展缓慢的三个原因：技术发展不均衡；功耗制约；成本制约。

三代代表：

代 代表节点 主频 位数 RAM Flash
第一代 Mica、MicaZ 4 MHz 8 4 KB 128 KB
第二代 TelosB 4 MHz（表内；第 11 页另一处写 MSP430 8 MHz，型号/配置不同） 16 10 KB 48 KB
第三代 Firestorm 48 MHz 32 64 KB 512 KB
第三代 Imote2 104 MHz 32 256 KB 32 MB
第三代 Hamilton 48 MHz 32 32 KB 256 KB

主要特点：低功耗（TelosB 睡眠约 μA 级）；体积小（TelosB 63.75 mm×32 mm，源自军事探测隐蔽需求）；集成度高（MCU + 温湿度/光照 + 无线）；低成本（Hamilton 单价约 6.75 美元）。

▸micaZ 能否声明 4100 字节数据

micaZ RAM = 4 KB = 4096 B。4100 > 4096，不能在 micaZ 上运行该数据对象（即便忽略栈与全局其它占用）。


STM32

ST：1987 年意大利 SGS 与法国 Thomson 半导体合并，1998-05 更名意法半导体，长期位列全球十大半导体公司。STM32 为 ARM Cortex-M 内核 32 位 MCU（及部分 MPU）产品族。内核分 Cortex-M0 / M3 / M4 / M7，每类再分主流、高性能、低功耗。十余年约 10 大产品系列、700+ 款。

CPU / MCU / MPU

缩写 全称 要点
CPU Central Processing Unit，中央处理器 运算与控制核心，程序最终执行单元
MCU Micro Controller Unit，微控制器 CPU+内存+I/O+时钟等集成单芯片；低功耗，适电池与长时运行
MPU Micro Processing Unit，微处理器 相对 MCU 更侧重高性能与复杂任务：更高主频、更大内存、更强算力

开发板典型组成：主控芯片、USB 电源、扩展接口、电源接口、下载接口、复位按键。

命名规则（例：STM32F103VET6）

字段 例 含义
家族 STM32 32 位 MCU
产品类别 F A 汽车级 / F 基础 / L 超低功耗 / S 标准 / T 触摸 / W 无线 等
型号功能 103 051 入门；103 基础型；303 为 103 升级（DSP+FPU）；407 高性能（DSP+FPU）；152 超低功耗
引脚数 V V = 100 pin（另：C≈48、R≈64、Z=144 等，课件有完整字母表）
Flash E 4=16 KB … 8=64 KB，B=128，C=256，D=384，E=512 KB
封装 T T=LQFP；H=BGA；U=VFQFPN；Y=WLCSP64
温度 6 6：−40～85°C；7：−40～105°C
▸图源

ch2.pdf 第 28 页。「STM32 命名规则」。下图按课件结构复绘。

1
2
3
4
STM32  F103  V   E    T    6
意法   系列  100 512KB LQFP 工业温
              pin Flash 封装  −40~85°C
字母脚数另见课件：C≈48、R≈64、Z=144 等。
▸解码 STM32F103C8T6

与上表最小系统板一致：F=基础型，103=主流 Cortex-M3，C≈48 pin，8=64 KB Flash，T=LQFP，6=工业温区。对照 VET6：V=100 pin、E=512 KB Flash，其余字段相同。看到型号先拆 7 段，再对 Flash/引脚，不要把 C8 的 64 KB 写成 512 KB。

三种低功耗模式（以 STM32F103 为例）

模式 行为 电流量级 典型用途
睡眠 内核停，外设仍跑 视时钟，见下表 mA 级 等待外设中断时降耗
停机 全部时钟停 约 20 μA 更深睡、可较快唤醒
待机 时钟全关，且关闭 1.2 V 域电源 约 2 μA，最低 最长续航

睡眠模式下电流（外部时钟）随「是否使能所有时钟」和主频、温度变化，例如使能全部时钟、72 MHz、85°C 约 30 mA；关闭多余时钟后同频约 7.5 mA。

扩展接口数量举例：

接口 STM32F103C8T6 STM32F103VET6
Digital 32 100
PWM 6 14
UART 3 3
I2C 2 2
SPI 2 2

常见开发板：

板型 MCU / MHz Flash/RAM / KB UART/I2C/SPI 尺寸 / mm 电源
STM32 最小系统板 F103C8T6 / 72 64/20 3/2/2 53×23 5 V
野火指南者 F103VET6 / 72 512/64 5/2/3 130×100 5 V
正点原子精英 F103ZET6 / 72 512/64 5/2/3 115×117 5 V

主要特点：库文件模块化开发，串口即可烧写；接口含 I2C、USART、SPI、CAN、USB 2.0 FS；调试支持 20 脚 JTAG 与 Cortex-M3 SWD（Serial Wire Debug，串行单线调试）；睡眠/停机/待机在低功耗、短启动、多种唤醒之间折中。


ESP32

乐鑫（无晶圆厂，2008，上海张江）：2013 ESP8089 → 2014 ESP8266EX（物联网 Wi-Fi SoC）→ 2016 ESP32（Wi-Fi + Bluetooth SoC）→ 2018 Wi-Fi MCU 全球领先 → 2023 IoT 芯片出货破 10 亿。

ESP32：集成 2.4 GHz Wi-Fi + 蓝牙双模 的单芯片方案。

项目 规格
CPU 低功耗 Xtensa LX6 32-bit 单/双核，最高 240 MHz，16/24-bit 指令集
片上存储 448 KB ROM + 520 KB SRAM
数字外设 34 GPIO；3 组 SPI（SPI/HSPI/VSPI）；2×I2C、2×I2S；1×Slave SDIO/SPI；3×UART；TWAI（汽车双线）；8 路 RMT；电机/LED PWM 等
模拟外设 2×12-bit SAR ADC；2×8-bit DAC；10 个触摸传感器
安全加速 SHA、RSA、AES、RNG
▸图源

ch2.pdf 第 34–35 页。「ESP32 CPU/存储/无线」。下图按课件结构复绘。

1
2
3
4
Wi-Fi 2.4G + BT/BLE RF  <->  Xtensa LX6 单/双核 <=240 MHz
448 KB ROM + 520 KB SRAM
外设：GPIO/SPI/I2C/I2S/UART/ADC/DAC/RMT/PWM ...
ULP + PMU 支撑 Modem-sleep / Light / Deep / Hibernation

能耗模式

模式 谁在跑 电流量级
Active 射频工作 Wi-Fi 发 180～240 mA；收 95～100 mA；BT/BLE 发约 130 mA（0 dBm），收 95～100 mA
Modem-sleep CPU 跑，Wi-Fi/BT 基带与射频关 双核 240 MHz 约 30～68 mA；80 MHz 约 20～31 mA
Light-sleep CPU 暂停；RTC 存储器/外设/ULP 仍跑；定时或外部中断唤醒 约 0.8 mA
Deep-sleep CPU 与大部分外设掉电 ULP 工作 150 μA；RTC timer+memory 10 μA
Hibernation 关 8 MHz 振荡器与 ULP 仅 RTC timer，约 5 μA
Off CHIP_PU 拉低 约 1 μA

射频一开就是百 mA 级，Deep-sleep 掉到 μA，占空比与是否关射频决定续航。

▸ESP32：1 s 周期、发 50 ms

粗算只分两态：Active 发 200 mA，其余 Deep-sleep 10 μA，电压 3.3 V。占空比 $D=0.05$。

$$I_{\mathrm{avg}}=200\times 0.05+0.010\times 0.95=10.0095,\mathrm{mA}$$
$$E=3.3\times 10.0095\times 10^{-3}\times 1\approx 33.0,\mathrm{mJ}$$

若改成 Modem-sleep（CPU 仍跑、射频关，取 40 mA）填满其余 950 ms：$I_{\mathrm{avg}}=10+38=48,\mathrm{mA}$，能量约 5 倍。结论：关射频（Deep-sleep）比「只降 CPU 主频」对续航贡献大一个数量级。

多协议芯片对比：

芯片 / 平台 BLE Wi-Fi 802.15.4 / Zigbee / 6LoWPAN LoRa / 其它
ESP32 √ √ ×（需外挂） ×
TI CC2650 类 √ × √ ×
专用 LoRa/Sigfox/NFC 模组 视模组 视模组 视模组 √

Wi-Fi 与蓝牙共享射频时用分时共存：两栈脉冲合并，重叠处会发生冲突，需仲裁，不是两套射频真正无冲突并行。

▸图源

ch2.pdf 第 35 页。「ESP32 无线：Wi-Fi/BT 共存」。下图按课件结构复绘。

1
2
3
ESP32: BLE√ Wi-Fi√  15.4×  LoRa×
Wi-Fi 与 BT 共享射频 = 分时脉冲合并；重叠处冲突，需仲裁。
对照表见上文「多协议芯片对比」。

主要特点：−40～+125°C；自校准动态调压；高度集成（天线开关、RF balun、PA、LNA、滤波、电源管理）；面向移动/可穿戴/物联网的时钟门控与省电模式；可作独立系统，或经 SPI/SDIO、I2C/UART 给主机 MCU 当 Wi-Fi/BT 从设备。


Arduino

2005 年第一块 Arduino 问世，名称来自意大利酒吧。不仅是开发板，还包括软件、团队、开源社区与设计理念。板组成：MCU、USB 串口、扩展插座、电源。

MCU 为 AVR 体系 Atmega。AVR 由挪威理工 Alf-Egil Bogen 与 Vegard Wollan 提出，属 RISC；存储为哈佛结构（程序空间与数据空间分离）。

参数 ATmega328 ATmega2560
时钟 / MHz 0～20 0～16
RAM / KB 2 8
Flash / KB 32 256
能耗（1 MHz） 0.1 μA～0.2 mA 3 μA～0.8 mA

盾板（Shield） 大幅扩展功能与接口。UNO vs Mega2560：

接口 UNO Mega 2560
Digital 14 54
Analog 6 16
PWM 6 14
UART 1 4
I2C / SPI 1 / 1 1 / 1

其它板型（睡眠/工作电流为课件值）：

型号 / MCU 主频 / MHz Flash/RAM / KB D/A/PWM/UART/I2C/SPI 尺寸 / mm 睡眠 / 工作
MICRO / ATmega32U4 16 32/2.5 14/12/7/1/1/1 48×17.7 0.35 mA / 1.1 mA
NANO / ATmega328 16 32/2 14/8/6/1/1/1 45×18 0.1 μA / 0.2 mA
ZERO / ATSAMD21G18 48 256/32 14/6/6/1/2/1 68×53 4.06 μA / 3.37 mA
LilyPad / ATmega168 8 16/1 14/6/6/1/0/0 27.94×27.94 0.1 μA / 250 μA
GEMMA / ATtiny85 8 8/0.5 3/1/2/1/0/0 27.94×27.94 0.1 μA / 300 μA

开源：可在 Arduino 技术上改版发布，但须声明 Arduino 团队贡献。UNO / Mega2560 为意大利 Smart Projects 官方产品；亦有 SparkFun LilyPad 等。个人可用面包板 + AVR 自搭简易板。授权方式为 CC（Creative Commons，知识共享）。

特点：底层封装高，上手易；多板统一 API，便于移植；盾板可扩展；主频远低于树莓派 / BBB，故更低功耗；开源与社区是其「灵魂」。


树莓派

定位：微型计算机（智能物件）。沿革：2006 原型 ATmega664、22.1 MHz、约 25 美元 → 2011 HDMI/USB/以太 → 2012 二代 BCM2836 → 2016 三代 BCM2837 + Wi-Fi/BLE → 2019 四代 BCM2711 + BLE 5.0。

组成：微控制器、扩展接口、USB 电源、SD 卡、HDMI、音频、以太、USB。接电源、键鼠、显示器即可当电脑用。

型号 主频 / GHz RAM
1B 0.7 512 MB
2B 0.9 1 GB
3B 1.2 1 GB
3B+ 1.4 1 GB
4B 1.5 1/2/4/8 GB

高功耗：4B 标准 5 V，空载约 760 mA，单核满载 900 mA，双核 1000、三核 1100、四核 1200 mA（约 6 W）。对比 MCU 的 mA～μA，树莓派不适合小电池长续航。

4B 接口：Digital 28，Analog 0，PWM 2，UART 6，I2C 6，SPI 5。

盾板补 Analog：

盾板 功能
GrovePi+ 扩展 Grove port，兼容 Pi 2/3/4/Zero；经 I2C 与 Pi 通信，Analog Grove 口采集后再转发给 Pi
Grove Base HAT 扩展 Grove port，兼容 Pi 2/3/4

其它型号：

型号 SoC / 主频 RAM / GB 数/模引脚 集成 尺寸 / mm 场景
2B BCM2836 0.9 GHz 1 40/0 以太、HDMI 85×56 教育
3B+ BCM2837B0 1.4 GHz 1 40/0 以太、Wi-Fi、BLE、HDMI 85×56 教育
4B BCM2711 1.5 GHz 1/2/4/8 40/0 以太、Wi-Fi、BLE 5.0、HDMI 88×58 教育
Zero W BCM2835 1 GHz 0.5 24/0 Wi-Fi、BLE、Mini HDMI 65×30 可穿戴

特点：支持 C / Python / JavaScript；接键鼠显示器即用；Cortex-A、最高 1.5 GHz + 8 GB + HDMI/USB/以太，配置接近普通电脑。


Jetson

NVIDIA 嵌入式 AI 平台，用于边缘计算与人工智能，已用于制造、物流、零售、服务、农业、智慧城市、医疗与生命科学。

型号 AI 性能 GPU 显存 存储 功耗
Nano 472 GFLOPS 128 核 Maxwell 4 GB LPDDR4 16 GB eMMC 5–10 W
TX2 1.26–1.33 TFLOPS 256 核 Pascal 4/8 GB LPDDR4 16/32 GB eMMC 7.5–20 W
Xavier NX 21 TOPS 384 核 Volta 8/16 GB LPDDR4x 16 GB eMMC 10–20 W
AGX Xavier 30/32 TOPS 512 核 Volta 32/64 GB LPDDR4x 32/64 GB eMMC 10–40 W
Orin Nano 20/40 TOPS 512/1024 核 Ampere 4/8 GB LPDDR5 SD/NVMe 7–15 W
Orin NX 70/100 TOPS 1024 核 Ampere 8/16 GB LPDDR5 NVMe 10–25 W
AGX Orin 200/248/275 TOPS 1792/2048 核 Ampere 32/64 GB LPDDR5 64 GB eMMC 15–75 W

算力单位

单位 全称 含义
TOPS Tera Operations Per Second $10^{12}$ 次操作 / 秒，通常默认 INT8
TFLOPS Tera Floating-point Operations Per Second $10^{12}$ 次浮点运算 / 秒，通常 FP32
GFLOPS Giga FLOPS $10^{9}$ 次浮点 / 秒

故 1.3 TFLOPS ≈ 每秒 $1.3\times 10^{12}$ 次浮点运算（FP32 语境）。TOPS 与 TFLOPS 不可直接换算，精度与是否稀疏、Tensor Core 不同。

GPU 架构演进（能效 Perf/W）：Tesla → Fermi → Kepler → Maxwell → Pascal → Volta / Turing → Ampere（7 nm，Tensor Core 3.0、TF32、结构化稀疏、MIG 等）。

端侧大模型对照（课件）：

板 显存 可部署量级 TOPS 功耗 价格
Orin Nano 8 GB Llama-7B 40 7–15 W $299
Orin NX 16 GB Llama-13B 100 10–25 W $599
AGX Orin 32 GB Llama-33B 200 15–40 W $899
AGX Orin 64 GB Llama-70B 275 15–60 W $1599

特点：算力跨 GFLOPS 到数百 TOPS；Nano 约 5 W 适无人机/机器人；TX2 约名片大小；支持 TensorFlow、PyTorch、Caffe/Caffe2、Keras、MXNet 等。

▸图源

ch2.pdf 第 53 页。「GPU 架构与能效」。下图按课件结构复绘。

1
2
3
Tesla -> Fermi -> Kepler -> Maxwell -> Pascal
      -> Volta / Turing -> Ampere (7nm, Tensor Core 3.0, TF32, MIG)
纵轴：Perf/W 上升。

▸思考题 3 要点
  • Things：传感节点、STM32、ESP32、Arduino。Smart Things：树莓派、Jetson。
  • RAM vs Flash：RAM 易失存数据；Flash 非易失存程序。
  • 4100 B @ micaZ：RAM 仅 4096 B，不能。
  • Atmega：AVR RISC + 哈佛结构（程序/数据空间分离）。
  • STM32 低功耗：睡眠 / 停机 / 待机，待机最低（约 2 μA）。
  • 盾板：扩展接口与功能；Arduino Shield、树莓派 HAT / GrovePi+。
  • ESP32 无线：Wi-Fi + 蓝牙（含 BLE）。可双模工作，但射频分时共存，冲突时段需仲裁，并非两套射频完全并行。
  • Jetson：边缘 AI，强算力、相对低功耗、小体积、多框架；制造/物流/城市/医疗等。
  • 1.3 TFLOPS：每秒 $1.3\times 10^{12}$ 次浮点运算。

开发

原生环境 vs 可另装 OS：

硬件平台 原生开发环境 亦可支持
传感节点（MicaZ、TelosB） TinyOS Contiki 等
STM32 STM32CubeMX（图形化配置，生成 C 初始化代码） RIOT、Zephyr
ESP32 ESP-IDF（默认集成 FreeRTOS） RIOT、Contiki、Zephyr、RT-Thread
Arduino Arduino IDE（编写、编译、烧录） Zephyr
树莓派 Raspbian + 配套工具 Windows 10 IoT Core
Jetson NVIDIA SDK / 库 Ubuntu 及其它 Linux

案例目标：室内环境监测，周期采集温湿度，每 3 s 打印到控制台或串口。分别在 Arduino 与树莓派 4B 上实现。


Arduino 案例

  1. 硬件：UNO 仅有 MCU 与板载 LED，无传感，外接 DHT11。
  2. IDE：Arduino IDE（库、交叉编译、烧写、串口；Windows / macOS / Linux）。
  3. 编程：setup 只执行一次（初始化），loop 反复执行。
1
2
3
4
5
6
7
8
9
10
11
12
13
#include "DHT.h"
DHT dht(2, DHT11); // 数据脚接 D2
void setup() {
  Serial.begin(9600);
  dht.begin();
}
void loop() {
  float h = dht.readHumidity();
  float t = dht.readTemperature();
  Serial.print("Humidity: "); Serial.println(h);
  Serial.print("Temperature: "); Serial.println(t);
  delay(3000);
}

DHT11 库：Seeed Grove Temperature And Humidity Sensor

  1. 交叉编译：工具 → 开发板 → Arduino UNO，再「验证」。
  2. 烧写。
  3. 测试：打开串口，波特率 9600，查看温湿度。

【此处插入：UNO+DHT11 接线图、IDE 验证/烧写、串口输出截图】

▸图源

ch2.pdf 第 60–65 页。UNO+DHT11 接线、IDE 验证/烧写、串口输出。无法准确复绘。


树莓派案例

  1. 硬件：4B 有 Wi-Fi/BLE/以太，无片上温湿度，外接 DHT11（通常经 GrovePi+）。
  2. 系统 / 库：Raspbian Stretch with desktop。常用库：WiringPi（GPIO 的 C++ 库）与 GrovePi（GrovePi / GrovePi+ 驱动，多语言）。本例选 GrovePi + Python。WiringPi 提供 pinMode / digitalRead / analogRead / serialOpen 等；GrovePi 提供 dht(pin, module_type)、acc_xyz() 及 I2C 块读写。
  3. SSH 远程登录后编写：
1
2
3
4
5
6
7
8
9
10
11
import grovepi, math, time
sensor = 2   # DHT 接 2 号脚
blue = 0
while True:
    try:
        temp, humidity = grovepi.dht(sensor, blue)
        if math.isnan(temp) == False and math.isnan(humidity) == False:
            print("temperature = %.02f C\nhumidity =%.02f%%" % (temp, humidity))
        time.sleep(3)
    except IOError:
        print("Error")
  1. 运行：python indoorEnv.py，示例输出约 27°C / 95% RH。

对比：Arduino 是交叉编译 + 烧写 + 串口；树莓派是本机 Python 解释执行 + SSH 终端。前者无 OS、实时循环靠 delay；后者跑完整 Linux，用 time.sleep。

【此处插入：Pi+GrovePi++DHT11 接线与 SSH 运行截图】

▸图源

ch2.pdf 第 67–69 页。Pi+GrovePi+DHT11 接线与 SSH 运行。无法准确复绘。


前沿

两条趋势：

高性能。 边缘计算与端侧 AI 要求更强处理能力；工艺进步使算力升、单位功耗降（MCU → 应用处理器 → Jetson 类 GPU SoC）。

模块化。 提高可定制性（按应用选模块）与可重用性（避免重复设计相同电路）。

  • SenSys’08：节点拆为控制、供电、存储、通信、传感等模块，标准数据接口互连，按需组装。
  • IPSN’18 Signpost：面向城市感知的模块化节点，可更换某一模块以匹配应用。
▸硬件前沿怎么背

一句话两条：算力往边缘走（AI 推理要更强 SoC），板子往积木化走（换传感/通信模块而不重画整板）。Signpost / 模块化论文是例子，不必背细节，能举「可换模块」即可。

【此处插入：Signpost 模块化城市感知节点照片】

▸图源

ch2.pdf 第 71 页。Signpost 模块化城市感知节点。无法准确复绘。


复习

主题 必记
狭义/广义 板+MCU vs 再加传感/执行/通信
能耗公式 $\Delta E=\sum \Delta t_i I_i p_i$，$p=UI$；μA/mA 单位
占空比交叉 高 $D$ 比 $I_w$，低 $D$ 比 $I_s$
$P=CV^{2}FT$ 动态功耗 ∝ $C V^{2} f$
RAM/Flash 数据易失 / 程序非易失；buf[10240] 看 RAM
UART 缓存 11 位帧，$N=\lceil B t_{\mathrm{isr}}/11\rceil$；2 ms@9600 → 2 B；115200@1 ms → 11 B
可扩展 BBB > Pi（原生 Analog）；Pi 靠盾板补
三代节点 Mica/MicaZ → TelosB → Firestorm/Imote2/Hamilton
STM32 模式 睡眠 / 停机 ≈20 μA / 待机 ≈2 μA 最低；命名 STM32F103VET6
ESP32 LX6 双核 240 MHz；448 KB ROM + 520 KB SRAM；Wi-Fi+BT 分时共存
Arduino AVR RISC + 哈佛；setup/loop；盾板；CC 开源
树莓派 智能物件、高功耗（4B 空载 ~760 mA）、无原生 ADC
Jetson TOPS≈INT8，$10^{12}$ ops/s；TFLOPS≈FP32；边缘大模型
案例 DHT11 + 3 s；Arduino IDE vs GrovePi Python

三、系统

参考课件：ch3 操作系统。目录：概述 → 关键特性 → 典型系统 → 案例 → 学术前沿。

▸本章在整条链上的位置

「端」的灵魂：OS（Operating System，操作系统）把硬件差异藏起来，给应用统一 API。物联网 OS 往往只有几十 KB，还要管休眠、射频协议栈和 OTA——和装 Windows 不是一类问题。


概述

物联网操作系统是支撑大规模部署的核心软件：屏蔽硬件差异，提供统一编程接口与多应用运行时，降低开发成本与时间。硬件抽象（Hardware Abstraction）是其核心功能之一。现状：数量众多、百家争鸣。

相对传统 OS（Windows / Linux）的三点差异：

维度 传统 OS 物联网 OS
存储占用 Windows ~GB、Linux ~百 MB 一般仅几十 KB（TinyOS / Contiki 等更小）
内存管理 有 MMU（Memory Management Unit，内存管理单元），虚拟地址 常 无 MMU，物理地址直接访问
特权模式 用户态 / 内核态隔离 许多 MCU 无 CPU 特权级，任何指令可访问全部硬件 → 有 Bug 的程序可不受 OS 约束地占满 CPU
▸无 MMU 意味着什么

PC 上进程互相踩内存会被 OS 拦住；很多 MCU 没有这层「围墙」，一个野指针就能把整个节点搞死。所以物联网 OS 更强调轻量调度、仔细用 RAM，有的方案用软件沙盒 / Wasm 补隔离。

【此处插入：Flash–RAM 双对数散点图（Windows/Linux vs TinyOS/Contiki/AliOS/LiteOS）】

▸图源

ch3.pdf 第 4 页。传统 OS 与物联网 OS 的 Flash–RAM 占用双对数散点。无法准确复绘。

系统构成：

类别 组件 要点
嵌入式 OS 任务调度 事件驱动 / 多线程
动态加载 模块热加载，利于软件更新
存储管理 RAM（数据）+ Flash（程序）
资源抽象 专用 / 虚拟化 / 共享
传感器接口 统一读数 API
无线网络 协议栈 底层：射频配置、MAC、队列；上层：TCP、收集与分发
AI TinyML TensorFlow Lite、Split Computing

两个重要概念：

▸Library OS 与微内核 / 宏内核

Library OS（库操作系统）：把部分 OS 功能做成库，由应用直接调用，而非经系统调用进独立内核。减少用户态↔内核态切换，并可按应用定制。

微内核（Microkernel）：内核只保留任务/线程、内存、IPC；文件系统、驱动、协议栈作为用户态进程，经消息传递通信。模块可独立增删换，不必改整核。RIOT 属此路线。

宏内核（Monolithic Kernel）：大量功能打进同一内核态，如 Linux。性能路径短，但故障隔离弱、裁剪难。


特性

七条：编程模型、调度、I/O、内存分配、软件更新、网络服务、AI 支持。


模型

按程序结构

类型 含义 例子
非模块化 应用作为整体设计、测试、调试 单文件裸机
模块化 功能拆成可互换模块 编码层：TinyOS 组件；二进制层：SOS 模块（可动态加载）

TinyOS：多组件组合，编译后成单一二进制映像，组件边界消失。SOS：编译后仍保留模块信息，可动态加载；模块头含 mod_id、state_size、订阅/提供函数、平台与 MCU 类型、module_handler 等。

按执行逻辑

类型 含义 特点
事件驱动 应用由多个事件处理函数构成，实时响应事件 实时性、响应性好；代码易被「切片」得碎
多线程 一个线程对应一个逻辑任务 减少由分片带来的额外代码量

同一「周期采样并无线发送」：事件模型拆成 timer_fired → sensor_readDone → post sendTask → radio_sendDone；线程模型则是 while(TRUE){ read…; send…; sleep; }。

▸图源

ch3.pdf 第 9–10 页。「编程模型：TinyOS / SOS；事件 vs 线程」。下图按课件结构复绘。

1
2
3
4
TinyOS: 组件图 -> 编译后单一镜像，不再保留组件信息
SOS:    模块头 SOS_MODULE_HEADER，编译后仍可动态加载
事件驱动: timer_fired / 高响应
多线程:  send_thread 对应逻辑任务

调度

方式 规则
抢占式 高优先级可打断低优先级
非抢占式 一旦把 CPU 给某就绪线程，一直跑到完成或阻塞
协作式 仅当线程主动 yield() 才交出 CPU
时间片轮转 各线程默认相同时间片；用完即使未完成也必须让出

对共享变量 x 的「读改写 + 写外存」如何保证 RAM 与外存一致：

调度 做法
非抢占式 { x++; write(x); } 整块不会被打断，天然原子
协作式 x++ 与 write(x) 之间禁止 Yield；整段完成后再 Yield
抢占式 / 时间片 必须 mutex：lock → x++; write(x); → unlock
▸思考题 1（a=10 s，b=20 s，c=30 s）

（1）非抢占，t=0 按 a→b→c 顺序启动。
a 完成 10 s；b 完成 30 s；c 完成 60 s。

（2）抢占，优先级 c>b>a；就绪时刻 a=1 s，b=2 s，c=15 s。

区间 运行 说明
0–1 空闲 尚无就绪
1–2 a a 跑 1 s，剩余 9
2–15 b b 抢占 a，跑 13 s，剩余 7
15–45 c c 抢占 b，跑满 30 s，c 完成 45
45–52 b 剩余 7 s，b 完成 52
52–61 a 剩余 9 s，a 完成 61

（3）RR，时间片 10 s；启动 a=0，b=10，c=20。

约定：时间片用完排到队尾；同一时刻新到达进程先入队。

区间 运行 结果
0–10 a a 完成 10
10–20 b b 剩余 10；c 于 20 到达
20–30 c 队列 [c,b]
30–40 b b 完成 40
40–60 c c 完成 60

若改成「用完时间片的进程先回队、新进程后入队」，则 b 于 20–30 跑完（完成 30），c 仍于 60 完成。答题写清假设。

▸抢占题易错：0～1 s 的空闲

（2）里 a 在 t=1 s 才就绪，0～1 s 必须画空闲，不能让 a 从 0 开始跑。若漏画空闲，后续所有完成时刻都会提前 1 s（会错成 a=60、b=51、c=44）。优先级只在同时就绪时比较；无人就绪就空转。


I/O

阻塞式 I/O 分阶段 I/O
语义 调用直到完成才返回 调用与完成分成两阶段（send / sendDone）
编程 简单：if (send()==SUCCESS) sendCount++; 冗长，但可在等待期间做其它事
响应 / 并发 调用期间卡住 高响应、并发更灵活

TinyOS 风格：call SubSend.send() 为 call 阶段，event sendDone(error_t err) 为完成阶段。


内存

静态（如 TinyOS） 动态（如 SOS）
时机 编译期确定 运行期 malloc / free
布局 .bss（未初始化）+ .data（已初始化）；另有中断向量表 堆
实现 常用静态数组 堆分配器
优点 效率高、无碎片 按需申请
缺点 不能按需 碎片、安全隐患（UAF、溢出）

Flash 典型布局还含 Bootloader（BL）区，见更新一节。

▸图源

ch3.pdf 第 15–16 页。「静态内存与 Bootloader 布局」。下图按课件结构复绘。

1
2
Flash:  [中断向量] [.data] [.bss 运行时在 RAM] [Bootloader] [应用镜像]
OTA: 有线(串口/以太) 或 Wi-Fi；BL 负责装载后再跳转。

更新

途径：有线（串口、以太）或 OTA（Over The Air，空中下载，如 Wi-Fi）。

Bootloader：上电后第一段代码；初始化 CPU 与硬件后把 OS/固件装入内存并跳转。

更新步骤：（1）OS 启动前 BL 查找升级文件；（2）擦除 Flash 旧文件；（3）写入新文件；（4）校验，正确则重启加载，否则重烧，部分设备可回滚。

三种粒度：

方法 做法
整镜像 更新软件全部
模块化 只更新需要的模块
差分 新旧做差得到补丁；可对整镜像或对模块差分

差分指令（课件编码）：

指令 格式 大小
COPY COPY <n> <old addr> 5 B
ADD ADD <n> <BYTE₁…BYTEₘ> 3+m B

例：旧 A B C D E A C B C（9 B），新 W A B C D E A C B C（10 B）→ ADD 1 <W> + COPY 9 0 = 4+5=9 B（补丁几乎等于新文件，本例收益小）。

影响补丁大小的两因素：差分算法（求最小补丁，如 bsdiff、xdelta3、HDiffPatch）；相似性保持（不改功能前提下让新旧更像）。课题组 MDiffPatch（INFOCOM 2024）利用多相似性空间做移动应用增量更新。

▸思考题 2

旧：A B C D E A C B C（下标 0–8）。新：W A B C D E A C B C X D E A C B。

两种合法编码均为 18 B：

  1. ADD 1 <W>（4）+ COPY 9 0（5）+ ADD 1 <X>（4）+ COPY 5 3（5）=18
    （COPY 5 3 取旧文件从下标 3 起 5 字节 D E A C B）
  2. ADD 1 <W>（4）+ COPY 9 0（5）+ ADD 6 <X D E A C B>（9）=18

头部插入函数 vs 尾部插入：头部差分包通常更大。 头部插入会使后续机器码整体移位、重定位，COPY 长匹配被破坏；尾部插入可整段 COPY 旧镜像再 ADD 新函数。

▸头插 vs 尾插（同长度新函数）

旧镜像 9 B：A B C D E A C B C。在尾部加 1 B Y：COPY 9 0（5）+ ADD 1 <Y>（4）= 9 B。

在头部加 1 B Y：只能 ADD 1 <Y>（4）+ COPY 9 0（5）= 9 B（本例碰巧一样）。若头部插入的是一段会改后续重定位的机器码，长 COPY 被拆成许多短 COPY/ADD，补丁趋近新文件全量。课件结论记：同等功能变更，头插差分 ≥ 尾插差分。


网络

传统 WSN：关注多跳自组织，多基于 IEEE 802.15.4；典型服务含数据收集、分发、时间同步（如 CTP）。

物联网：协议变多（BLE、ZigBee、Wi-Fi HaLow、LoRaWAN、NB-IoT）；学术关注干扰共存、异构互联。课件 TinyNet：2.5 层抽象 uniMAC，关键模块为邻居发现与通信调度。

▸图源

ch3.pdf 第 23 页。「TinyNet」。下图按课件结构复绘。

1
2
3
4
应用/网络
  2.5 层 uniMAC 抽象
  关键模块：邻居发现 | 通信调度
链路/PHY（多协议）

TinyML

TinyML：把机器学习部署到 MCU 等低功耗边缘设备。特征：低延迟、保护隐私、精度稍低、低功耗、高可靠、内存小。场景：音频/视频推理、穿戴、健康监测传感器。

框架：

框架 目标设备
TensorFlow Lite 嵌入式 Linux（如树莓派）
TensorFlow Lite for Micro MCU（如 ESP32）
PyTorch Mobile Android / iOS

优化：

手段 做法
剪枝 按阈值去掉不重要权重，再微调
量化 32/64-bit 浮点 → 8-bit 或更低定点
知识蒸馏 大教师模型 → 小学生模型
高效架构 如 MobileNetV2
硬件加速 用 MCU 上 DSP 等
▸图源

ch3.pdf 第 28 页。「TinyML 模型压缩」。下图按课件结构复绘。

1
2
3
(a) 剪枝: 阈值去掉不重要连接 -> 微调
(b) 量化: FP32/64 -> INT8/更低定点
(c) 蒸馏: 教师大模型 -> 小学生模型

系统

OS 开发者 要点
TinyOS UC Berkeley WSN；事件驱动；低功耗小型化；IPv6/6LoWPAN；nesC 组件
Contiki 瑞典皇家理工 / SICS 多任务事件驱动；IPv6、6LoWPAN、RPL、CoAP；protothread；Flash 小文件系统
RIOT 柏林自由大学 微内核；优先级抢占实时多线程；IPv6/6LoWPAN/UDP/RPL/CoAP；LoRa/Sigfox/LoRaWAN
Zephyr Linux 基金会 可扩展 RTOS；蓝牙/LoRa/LTE/以太/Wi-Fi；安全启动与加密；组件管理
RT-Thread 熊谱翔，2006 极低内存；实时；802.15.4/LoRa/Wi-Fi；软件包生态
HarmonyOS 华为 全场景分布式；一次开发多端；确定时延引擎、高性能 IPC
AliOS Things 阿里云 轻量；LoRaWAN/NB-IoT；连阿里云；设备身份与加密

课件后文对 Contiki、RIOT、AliOS Things、HarmonyOS 展开（TinyOS/Zephyr/RT-Thread 以总表为准）。


Contiki

开源、高可移植、多任务；面向内存很少的 MCU / WSN。历程：2002 Adam Dunkels（SICS）→ 2004 v2.0（Cooja 模拟器、Rime 栈）→ 2011 Contiki RPL、ContikiMAC → 2012 Thingsquare 维护 → 2015-08 v3.0。

特性 描述
编程 protothreads（多线程风格）+ 多栈库 mt_thread
调度 优先级事件驱动、protothreads、mt_thread
内存 静态 + 动态
更新 模块化
网络 Contiki RPL、uIP、6LoWPAN
AI 官方不支持，社区可适配 TFLite
其它 Shell 交互

Protothreads（Dunkels, 2006）：协作式（Cooperative）、单栈（Single-stack）、不能使用局部变量（状态靠 static / 全局）。骨架：

▸Protothread 为啥省内存

普通线程每线程一截栈，RAM 吃紧的 MCU 扛不住。Protothread 用宏把「跑到哪」记在一个整数里，大家共用一个栈；代价是：不能依赖函数局部变量跨阻塞点存活，必须自己 yield（主动让出），高优先级也插不进来（非抢占）。

1
2
3
4
5
6
7
8
PROCESS(name, strname);
AUTOSTART_PROCESSES(&name);
PROCESS_THREAD(name, ev, data) {
  /* 先初始化变量 */
  PROCESS_BEGIN();
  /* C 语句，可用 PROCESS_WAIT_EVENT_UNTIL(...) 让出 */
  PROCESS_END();
}

实现机理：宏展开成 switch((process_pt)->lc)，在 WAIT 处记录行号 lc 并 return（yield）；再次调度从该 case 恢复。故局部自动变量在 yield 后丢失，必须 static。

例：hello_one 每 1 s、hello_two 每 2 s 打印，协作单栈，输出交错为 Hello one / one / two / one / one / two …

mt_thread：多栈；支持协作 yield 与系统抢占。API：mt_init / mt_start / mt_exec / mt_exit / mt_stop。

网络：

服务 协议 能力
精简 TCP/IP uIP TCP、UDP、ICMP、IP（最小功能集，省内存）
IPv6 适配 6LoWPAN 分片重组、IPv6/UDP 头压缩
收集/分发 RPL 低功耗有损网 IPv6 距离矢量

RPL vs CTP：CTP 仅多对一；RPL 支持一对多（分发）、多对一（收集）、一对一（P2P）。

课件 uIP 例：服务器听 45 端口，收到数据回 ok；客户端连 192.168.0.1，成功后发 hello。

Shell（sky-shell）：sense / txpower / rfchannel 等；可注册自定义命令（如 echo2 把参数输出两遍）。make TARGET=sky sky-shell.upload 后 make login。

▸图源

ch3.pdf 第 35、38–39 页。「Contiki：protothread / uIP / RPL」。下图按课件结构复绘。

1
2
3
protothread: PROCESS_THREAD 展开为 switch + 静态 lc；协作式、单栈、禁局部变量
uIP 例: 服务器听 45 端口回 ok；客户端连 192.168.0.1 后发 hello
RPL: 一对多分发 | 多对一收集 | 一对一点对点   （CTP 仅多对一）

RIOT

面向 IoT 的实时多线程 OS；微内核，时钟、协议栈、网络服务均独立线程。柏林自由大学；2008 开源社区；课件数据：293 贡献者，67 种处理器、237 款开发板。

三点：开发者友好（C/C++，gcc/gdb，Linux/Win/macOS；应用多硬件无关；SAUL 统一传感/执行器）；资源低（可裁剪；每线程通常 <25 B 内核对象）；网络好（传/网/链各层 + Shell、加密原语）。官方兼容 TFLite。

多线程近似桌面：

1
2
3
4
5
kernel_pid_t pid = thread_create(
  thread_stack, 1024,
  8,  /* 优先级 0–15，数值越大优先级越低 */
  THREAD_CREATE_STACKTEST,
  thread_func, NULL, "thread name");
Flag 含义
THREAD_CREATE_SLEEPING 创建后立刻休眠
THREAD_CREATE_WOUT_YIELD 不立刻跑，等调度
THREAD_CREATE_STACKTEST 立刻执行并测栈占用

模块化：目录即模块；Makefile 中 USEMODULE += dht、USEMODULE += xtimer。移植新板主要补 CPU 模块。

GNRC（Generic Network Stack）：应用层用 socket；完整 6LoWPAN，上承 IPv6/UDP/TCP；最底层 gnrc_netdev 抽象各链路，换无线不必改栈。每层一线程，底层优先级高于高层（MAC 最高，应用最低）。

SAUL（Sensor Actuator Uber Layer）：设备用 saul_reg_t 链表（next/dev/name/driver）；驱动 saul_driver_t 含统一 read/write 与 type；数据用 phydat_t。遍历 saul_reg 即可读遍板上传感器。

▸图源

ch3.pdf 第 46–48 页。「RIOT GNRC 与 SAUL」。下图按课件结构复绘。

1
2
3
GNRC: socket 应用 > IPv6/UDP/TCP > 6LoWPAN > gnrc_netdev > 各链路
      每层一线程，底层优先级更高
SAUL: saul_reg 链表 --read/write--> phydat_t

AliOS

AliOS Things：面向小型 IoT 基础设备（智家、智城）；目标「驱动万物智能」——极致性能、极简开发、云端一体、丰富组件、安全防护。

维度 要点
开发 C / JavaScript；IDE；GDB / Valgrind / Perf
性能 内核 ROM <2 KB；空闲 CPU 模式；多种调度
服务 多种接入、自组网、深度定制协议栈
更新 FOTA；独立 / 多 bin / 差分 / 乒乓；OTA HAL

架构分层：应用 / Profile（感知节点、协议网关、边缘计算）→ 中间件（Link Kit/Voice/Vision、传感器框架、AI SDK、时序库）→ 网络（LwIP、uMesh、无线）→ 系统与 HAL → 基础 OS（Rhino、uContainer、嵌入式 Linux、TEE、ID2）→ Cortex-A/R/M、IA、C-Sky、Xtensa。工具链含 AliOS Cube、Studio、远程实验室 uDevice Center / Hacklab。

特性 描述
编程 Rhino：模块化 + 事件 + 多线程；异步框架 Yloop；阻塞与分阶段 I/O
调度 优先级抢占 + 时间片轮转（都先跑最高优先级）
内存 静态 + 动态；固定块 / 可变块 / 多内存区
更新 整镜像 / 模块 / 差分
网络 Wi-Fi、LoRa、BLE、蜂窝；LwIP、uMesh、LoRaWAN
AI 官方 TFLite
安全 TEE、安全传输、可信身份

Rhino：小 FootPrint、低功耗、实时多任务。空闲时 ARM 用 WFI、IA32 用 HLT；还可进 C1/C2/…（C0 为活跃），并在预计空闲窗口内屏蔽 tick，到时再唤醒——比「空转 WFI」更省。

网络：uMesh 自组织、自修复、多跳，适大规模；SAL（Socket Abstraction Layer）加速不同连接 MCU 的开发；LwIP（Lightweight IP）含 IPv4/6、TCP/UDP、ICMP、ARP；LoRaWAN 支持 Class A / Class C。

安全：系统级 + 芯片级。Link TEE、Link ID²（Internet Device ID）：一芯一密、不可伪造/篡改、全球唯一；设备↔云双向认证与链路加密。

▸图源

ch3.pdf 第 51、54、56 页。「AliOS Things 架构 / 网络 / ID²」。下图按课件结构复绘。

1
2
应用/Profile -> 中间件 -> 网络(LwIP,uMesh) -> HAL -> Rhino/TEE/ID2
ID2: 一芯一密；分发中心签发 -> 认证中心挑战应答 -> 设备<->云

鸿蒙

华为全场景分布式 OS。1+8+N：1=手机；8=车机、音箱、耳机、手表/手环、平板、大屏、PC、AR/VR；N=其它 IoT。面向消费者（能力互补、资源共享）；面向应用开发者（与设备形态解耦）；面向设备开发者（组件化裁剪）。

特性 描述
编程 线程模型；POSIX + CMSIS-RTOS；多语言 API；阻塞 / 分阶段 I/O
调度 时间片轮转
内存 动态
网络 丰富；含星闪 NearLink
AI TFLite、MindSpore Lite
其它 多内核、分布式软总线

四层：内核 / 系统服务 / 框架 / 应用，可裁剪。

内核 适用 MMU
Linux 手机等 有
LiteOS-A 标准设备，参考内存 ≥128 MB 有，虚拟内存映射；POSIX；HDF 统一驱动
LiteOS-M 微设备 ≥1 MB、迷你 ≥128 KB 无；最小功能集 + KAL + 可选组件；HAL；Cortex-M3/M4/M7、RISC-V

分布式四件套：

能力 含义
分布式软总线 类比硬件总线，在 1+8+N 间建「无形」总线：自发现、自组网、高带宽、低时延；支撑设备虚拟化、跨设备调用、多屏协同、文件分享
分布式数据管理 数据与单设备解绑，逻辑与存储分离，跨设备无缝
分布式任务调度 发现/同步/注册/调用；远程启动、调用、绑定、迁移；按能力/位置/状态/习惯选设备
分布式设备虚拟化 周边设备成为手机能力延伸，组成超级虚拟终端
▸图源

ch3.pdf 第 57、59–62 页。「HarmonyOS 1+8+N 与双内核」。下图按课件结构复绘。

1
2
3
1 手机  +  8（车机/音箱/耳机/手表/平板/大屏/PC/ARVR）  +  N IoT
分布式软总线：自发现/自组网/高带宽/低时延
LiteOS-A: >=128MB, 有 MMU；  LiteOS-M: 无 MMU, Cortex-M/RISC-V

▸思考题 3
  • protothread vs 传统线程：协作式、单栈、不能用自动局部变量、无独立抢占；传统线程多栈、可抢占、有局部栈帧。
  • RPL vs CTP：CTP 仅多对一；RPL 还有一对多、一对一。
  • GNRC 链路抽象层：gnrc_netdev。
  • SAUL：设备 = saul_reg_t；数据/控制参数 = phydat_t。
  • AliOS 内核：Rhino；小 FootPrint、低功耗（空闲 CPU/Cx）、实时多任务。
  • 自组网 / 轻量 TCP/IP：uMesh / LwIP。
  • LiteOS-A vs M：A 给 ≥128 MB、有 MMU 的标准设备；M 给无 MMU 的微/迷你设备。
  • 软总线：1+8+N 上的虚拟总线，自发现自组网，承载跨设备分布式业务。

案例

AntiTheft：每 1 s 内以 100 Hz 采加速度（窗口 10 点，间隔 10 ms），算方差，若 $\mathrm{var}>4\times 10$ 则判被盗，点亮红 LED。Contiki@TelosB+mts300；RIOT@ESP32+mts300。

关键常量（课件代码）：ACCEL_SAMPLES=10，ACCEL_INTERVAL=CLOCK_SECOND/100（10 ms），CHECK_INTERVAL=CLOCK_SECOND（1 s）。满窗时 sample_move()：前 9 点前移，新样点入尾（滑动窗）。阈值：var > 4 * ACCEL_SAMPLES，即相对均方偏差阈值 4（不是「方差>40」的别解，而是与样本数相乘的写法）。Contiki：双 AUTOSTART_PROCESSES + etimer；RIOT：thread_create + ztimer_sleep。

方差：$\mathrm{avg}=\frac{1}{n}\sum x_i$，$\mathrm{var}=\sum(x_i-\mathrm{avg})^2$，阈值比较用 var > 4 * ACCEL_SAMPLES（即均方偏差 >4）。

▸窗口方差手算

$n=10$，阈值 $4n=40$。静止窗全为 $10$：$\mathrm{avg}=10$，$\mathrm{var}=0$，不报警。

被拿起：前 9 点仍为 $10$，末点 $30$。$\mathrm{avg}=12$，

$$\mathrm{var}=9\times(10-12)^2+(30-12)^2=36+324=360>40$$

判被盗。代码里的 var 是平方和不是除以 $n$ 的样本方差；改成除以 $n$ 再比 4，阈值语义会变，答题跟课件比较式。

Contiki：Instant Contiki 虚拟机（用户 username / user）。两 protothread：accel_sample_process 填滑动窗口；antitheft_process 每秒 checkAccelation()。TARGET=sky，motelist 找 /dev/ttyUSB0 后 make … upload。桌面静止再拿起，观察红灯。

RIOT：git clone + ESP32 工具链。两 thread_create（栈 1024、优先级 8）；ztimer_sleep。USEMODULE += ztimer；BOARD=esp32-wroom-32；make … flash。RIOT 版方差超限亮灯，否则关灯。

对照：Contiki 用事件定时器 + 协作 protothread；RIOT 用抢占多线程 + ztimer。算法窗口相同。

【此处插入：TelosB+mts300 / ESP32 接线与红灯测试照片】

▸图源

ch3.pdf 第 65–76 页。AntiTheft 案例：TelosB+mts300 / ESP32 接线与红灯（案例页组图）。无法准确复绘。


前沿

方向 要点 代表
低代码 大模型辅助端侧开发；LLM as an OS —
高安全 无人值守易被俘获；安全语言 + TEE Tock：Rust 类型安全内核，隔离错误、内存保护；SOSP’17 Multiprogramming a 64 kB Computer Safely and Efficiently
高扩展 多语言、多协议；课题组 WAIT、TinyNet FireStorm：Cortex-M4 低功耗硬件 + TinyOS 新软件 + Lua 可扩展 + 多协议；IPSN’16
环境自适应 Intermittent Computing（间歇计算）：环境能量采集，电尽则 CPU/RAM/寄存器清零，须在断电前把状态写入非易失内存以便恢复 InK：感知能量，耗尽前保存，保证内存一致性；SenSys’18 InK: Reactive Kernel for Tiny Batteryless Sensors

【此处插入：Tock / FireStorm / InK 系统结构图】

▸图源

ch3.pdf 第 79–81 页。Tock（SOSP’17）、FireStorm（IPSN’16）、InK（SenSys’18）论文结构图。无法准确复绘。


复习

主题 必记
vs 传统 OS 几十 KB、常无 MMU、常无特权级
Library OS / 微内核 库化少切换；微内核只留调度+内存+IPC
编程 TinyOS 组件编译丢边界；SOS 二进制可加载；事件 vs 线程
调度+原子 非抢占整块；协作勿在临界区 Yield；抢占用 mutex
RR/抢占题 写清甘特图；c>b>a 时完成时刻 61/52/45
I/O 阻塞易写；分阶段高响应
差分 COPY=5 B，ADD=3+m；头插大于尾插
TinyML 剪枝/量化/蒸馏；TFLite vs Micro
Contiki protothread 单栈协作无局部变量；uIP/6LoWPAN/RPL；RPL≠CTP
RIOT 微内核；gnrc_netdev；saul_reg_t + phydat_t；优先级数字越大越低
AliOS Rhino；uMesh + LwIP；ID² 一芯一密
鸿蒙 1+8+N；LiteOS-A/M；软总线
案例 100 Hz 窗口 10，var>4n（平方和）；例 360>40 亮灯
前沿 Tock/Rust；FireStorm/Lua；InK 间歇计算

四、短距

参考课件：Ch4 低功耗短距离通信。学习目标：常见短距技术与关键特性；IEEE 802.15.4 调制解调；低功耗 MAC 及优缺点；PRR 计算与估计；CTP 与 ETX；BLE 协议栈与链路层流程；BLE Mesh 数据包路由。


目标

目标 深度
短距技术与关键特性 了解
802.15.4 调制 / 解调 掌握
低功耗 MAC 及优缺点 了解
链路 PRR 计算与估计 掌握
CTP 工作原理与 ETX 掌握
BLE 协议架构与链路层 掌握
BLE Mesh 路由 掌握

概述

物联网「万物互联」依赖无线、低速、低功耗短距通信。发射功率与距离近似 $P \propto d^{n}$（$n$ 为路径损耗指数，室内常取 2～4）。功率受限时只能缩短单跳距离，再靠多跳覆盖。

技术 定位
IEEE 802.15.4 低速 WPAN（Wireless Personal Area Network，无线个域网）的 PHY（Physical Layer，物理层）+ MAC（Medium Access Control，介质访问控制）标准
ZigBee（紫蜂） 在 802.15.4 之上定义 NWK（Network，网络层）/ APL（Application，应用层）
传感网协议 S-MAC、LPL（Low Power Listening）、RI-MAC（Receiver-Initiated MAC）、CTP、RPL 等开放研究栈
BLE（Bluetooth Low Energy，低功耗蓝牙） 手机生态友好
Wi-Fi HaLow / 802.11ah 低于 1 GHz 的长距 Wi-Fi，课件仅点名
RFID / NFC / Thread 识别、近场、IPv6 mesh
▸PHY 和 MAC 差在哪

PHY：比特怎么变成无线电（频率、调制、扩频）。MAC：多个节点共用空气时，谁先发、怎么确认收到、怎么睡醒对齐。ZigBee 不重做 PHY/MAC，只在上面加「组网与应用」。

▸图源

ch4.pdf 第 4–6 页。第 4–5 页智慧家居短距互联照片；第 6 页 $P\propto d^{n}$。照片保留对照课件；关系如下。

1
2
发射功率 P 与距离 d：P ∝ d^n （n 为路径损耗指数）
短距低功耗：802.15.4 / ZigBee / BLE / Wi-Fi HaLow

IEEE 802.15.4

（Institute of Electrical and Electronics Engineers 802.15.4，低速无线个域网）

2003-10 发布，只覆盖 PHY 与 MAC。后续修订（课件时间轴 + IEEE 官方）：

版本 年份 要点
802.15.4 2003 初始 PHY + MAC
802.15.4b ~2006 PHY/MAC 技术改进
802.15.4a ~2007 精密测距 / 定位，更高吞吐
802.15.4c / 4d 2009 中国 779～787 MHz（习称 780 MHz）；日本 950 MHz
802.15.4e 2010 MAC TDMA + 信道跳频，面向工业
802.15.4f ~2012 RFID 与定位
802.15.4v ~2017 欧洲 870～876 MHz 等区域频段
▸课件年份笔误

课件正文写「2001 年 3 月 802.15.4c」，同页时间轴落在 2009 附近。IEEE 正式标准为 802.15.4c-2009（Board 2009-03-19，出版 2009-04），频段含 314–316 / 430–434 / 779–787 MHz。考试若填空，按课件时间轴「约 2009、中国 780 MHz」叙述；辨析可指出 2001 为笔误。


ZigBee

（紫蜂）

2004 诞生；2007 ZigBee PRO；2011 ZigBee RF4CE（遥控更灵活）。PHY/MAC = 802.15.4，NWK/APL = ZigBee 联盟。特点：低功耗、低速率、低成本、组网灵活。小米等智能家居常用。


传感网协议

大量低功耗节点组成的无线自组织多跳网，实时感知、处理并传输覆盖区内对象信息。802.15.4 高度开放，催生大量研究。

年代 方向 代表
2002 同步 MAC S-MAC
2004 发送方发起异步 LPL-MAC、Wise-MAC
2008 接收方发起异步 RI-MAC
2010 异步改进 A-MAC
2009 多对一收集 CTP（SenSys）
2010 IETF ROLL RPL（多对一 / 一对多 / 一对一）

早期射频如 CC1000：38.4 kbps、FSK。近期栈多建在 802.15.4 上。典型部署：Great Duck Island 生态监测、火山监测、绿野千传森林火灾。


BLE

（Bluetooth Low Energy，低功耗蓝牙）

1994 爱立信提出蓝牙；2010 蓝牙 4.0 引入低功耗，称 BLE；2016-06-16 SIG 公布蓝牙 5；2017-07-18 把多跳功能与模型并入 5.0，使家居多设备互连成为可能。


其它

技术 要点
RFID 射频识别；调谐电磁场从标签读出数据，自动辨识与追踪
NFC 近场通信；2004 飞利浦半导体 / 诺基亚 / 索尼；13.56 MHz，约 20 cm；由 RFID 演变
Thread 面向 802.15.4 的 IPv6 栈；角色分 Router 与 End Device

特性

五个维度：功耗、距离、频带与数据率、安全性、非技术特征。


功耗

最大发射功率对照（课件）：

协议 最大发射功率 dBm（$D=10\lg P_{\mathrm{mW}}$）
802.15.4 100 mW 20 dBm
BLE 10 mW 10 dBm
802.11b 1 W = 1000 mW 30 dBm
▸dBm 换算

$D=10\lg P$，其中 $P$ 以 mW 计。$100,\mathrm{mW}\Rightarrow 20,\mathrm{dBm}$；$10,\mathrm{mW}\Rightarrow 10,\mathrm{dBm}$；$1,\mathrm{W}=10^3,\mathrm{mW}\Rightarrow 30,\mathrm{dBm}$。反向：$P_{\mathrm{mW}}=10^{D/10}$。

CC2420（符合 15.4）：工作电压 2.1～3.6 V，典型 3.0 V。TX 8.5～17.4 mA，RX 18.8 mA，CCA 0.426 mA。两节 750 mAh 电池、最大功率不停发送：$1500/17.4\approx 86,\mathrm{h}$。

PA_LEVEL 与输出功率（TI 数据手册 Table 9；课件 OCR 把 19 读成 11、9.9 读成 1.1，下表按手册）：

PA_LEVEL 电流 (mA) 输出 (dBm)
31 17.4 0
27 16.5 −1
23 15.2 −3
19 13.9 −5
15 12.5 −7
11 11.2 −10
7 9.9 −15
3 8.5 −25

TelosB 上 CC2420 可占总能耗 81%。CC2420 最大发送 17.4 mA，MSP430 @1 MHz 仅 330 μA，通信远贵于计算。降低占空比是主手段：

$$
D=\frac{T_{\mathrm{active}}}{T_{\mathrm{total}}},\qquad
P_{\mathrm{avg}}=D,P_{\mathrm{on}}+(1-D),P_{\mathrm{sleep}}
$$

▸占空比 0.1%

活跃 10 mW，休眠 10 μW，$D=0.1%=0.001$。

$P_{\mathrm{avg}}=0.001\times 10,\mathrm{mW}+0.999\times 10,\mu\mathrm{W}=10,\mu\mathrm{W}+9.99,\mu\mathrm{W}=19.99,\mu\mathrm{W}$。

相对一直活跃，平均功耗降约 500 倍。

▸图源

ch4.pdf 第 15–16 页。「CC2420 功耗与占空比」。下图按课件结构复绘。

1
2
3
PA_LEVEL 31 -> 17.4 mA @ 0 dBm（课件表）
TelosB 上 CC2420 约占通信能耗 81%
占空比 D = 活跃时间/总时间；活跃 10、睡眠 10 量级时 D 决定均值

距离

协议 课件最大距离
802.15.4 ~100 m
BLE ~300 m（对比页也写 ~100 m，视版本 / 编码 PHY）
802.11b ~140 m

对数距离路径损耗：

$$
\mathrm{PL}(d)=\mathrm{PL}(d_0)+10n\log_{10}!\Bigl(\frac{d}{d_0}\Bigr)+X_{\sigma}
$$

其中 $d_0$ 常取 1 m，$n$ 为衰减指数，$X_{\sigma}$ 为高斯阴影。接收强度：

$$
\mathrm{RSSI}=P_{\mathrm{tx}}+G_{\mathrm{tx}}+G_{\mathrm{rx}}-\mathrm{PL}(d)
$$

最远距离定义为 RSSI 等于接收机灵敏度。多跳可在单跳功率受限时扩大覆盖。

▸最远距离 76.4 m

忽略天线增益与 $X_{\sigma}$。$P_{\mathrm{tx}}=0,\mathrm{dBm}$，灵敏度 $=-85,\mathrm{dBm}$，$\mathrm{PL}_0=28.5,\mathrm{dB}$，$n=3$，$d_0=1,\mathrm{m}$。

边界处 $\mathrm{RSSI}=-85=0-\mathrm{PL}(d)\Rightarrow\mathrm{PL}(d)=85$。

$85=28.5+30\log_{10}d\Rightarrow\log_{10}d=56.5/30=1.8833\Rightarrow d=10^{1.8833}\approx\mathbf{76.4,m}$。

▸图源

ch4.pdf 第 17 页。路径损耗模型。曲线为课件图，公式如下；多跳示意见同页。

1
2
PL(d) = PL(d0) + 10 n log10(d/d0) + Xσ
单跳距离有限；多跳扩大覆盖（能量黑洞见 ch5）。

频带

授权频段需许可证（如 AM/FM）。ISM（Industrial, Scientific and Medical）对工业 / 科学 / 医学开放，通常无需许可证。常见：2.45 GHz、5.8 GHz、915 MHz。2.45 GHz ISM 为 2.400～2.4835 GHz。

协议 中心频率 频宽 最高数据率
802.15.4 全球 2.45 GHz 2 MHz 250 kbps
802.15.4 北美 915 MHz — 40 kbps
802.15.4 欧洲 868 MHz — 20 kbps
BLE 2.45 GHz 2 MHz 2 Mbps（5.0 的 2M PHY）
802.11b 2.45 GHz 22 MHz 11 Mbps

2.45 GHz 信道划分：802.15.4 16×2 MHz；BLE 40×2 MHz；802.11b 14×22 MHz（互相重叠，易干扰）。

实际速率低于峰值。802.15.4 发送前随机退避 $\mathrm{initial}\in[0,\mathrm{CW}]$，课件称实际速率常约峰值的 1/3。传输效率

$$
\eta=\frac{T_{\mathrm{payload}}}{T_{\mathrm{backoff}}+T_{\mathrm{header}}+T_{\mathrm{payload}}},\qquad R_{\mathrm{real}}=\eta R_{\max}
$$


安全

层次 机制
芯片 CC2420 硬件 AES-128
802.15.4 MAC 向上提供帧安全：保密性（AES-128）；完整性（附加 MIC）
蓝牙 跳频 + 应用层加密；上层还有 SMP 密钥生成与分发

非技术

维度 802.15.4 / ZigBee BLE
芯片厂商 TI、Freescale、Ember、Atmel TI、CSR、Broadcom、Nordic、锐迪科
模组价（课件） TI 官网约 3 USD 同左量级
终端 小米等 ZigBee 家居 手机、共享单车、手表
标准化 ZigBee 联盟 Bluetooth SIG
开放性 IEEE 802.15.4 与 BLE 规范均公开 同左

对照总表（课件 p.24；距离在对比页统一写 ~100 m，功耗 ZigBee/BLE ~10 mW、Wi-Fi ~1 W）：

802.15.4 / ZigBee BLE 802.11b
距离 ~100 m ~100 m ~100 m
功耗 ~10 mW ~10 mW ~1 W
频带 868 / 915 MHz，2.4 GHz 2.4～2.5 GHz 2.4～2.5 GHz
数据率 250 kbps 2 Mbps 11 Mbps
包长 127 B 265 B 2304 B

PHY

传感网典型场景是自组织无线多跳。协议栈自下而上：802.15.4 PHY → 低功耗 MAC → 链路质量估计 → 6LoWPAN → CTP / RPL → Thread → Matter。

▸图源

ch4.pdf 第 27 页。「传感网协议架构」。下图按课件结构复绘。

1
2
3
4
5
应用 / Matter
Thread / RPL / CTP
6LoWPAN
低功耗 MAC（S-MAC / LPL / RI-MAC）
IEEE 802.15.4 PHY+MAC

物理层把比特流变成 RF：DSSS 扩频 → O-QPSK 调制 → 脉冲成形 → DAC 与发射。


DSSS

（Direct Sequence Spread Spectrum，直接序列扩频）

▸扩频在干什么

本来 1 个信息 bit 只占很短时间；DSSS 把它换成一串更密的 chip（码片） 序列再发出去。带宽被「摊开」，抗干扰、可与他人部分重叠共存。接收端用同一序列做相关，把信号「收拢」回来。802.15.4 常用：4 bit → 32 chip 的映射表，再经 O-QPSK（Offset Quadrature Phase-Shift Keying，偏移正交相移键控）调制到载波上。

每 4 bit 符号映射为 32 chip。Chip rate 2 Mchip/s，数据率 $2\times10^6/32=250,\mathrm{kb/s}$。符号按 $(b_0,b_1,b_2,b_3)$ 查表（IEEE 802.15.4 2.4 GHz O-QPSK）：

符号 $(b_0 b_1 b_2 b_3)$ 码片 $(c_0\cdots c_{31})$
0000 11011001110000110101001000101110
1000 11101101100111000011010100100010
0100 00101110110110011100001101010010
1100 00100010111011011001110000110101
0010 01010010001011101101100111000011
1010 00110101001000101110110110011100
0110 11000011010100100010111011011001
1110 10011100001101010010001011101101
0001 10001100100101100000011101111011
1001 10111000110010010110000001110111
0101 01111011100011001001011000000111
1101 01110111101110001100100101100000
0011 00000111011110111000110010010110
1011 01100000011101111011100011001001
0111 10010110000001110111101110001100
1111 11001001011000000111011110111000

相邻符号的码片序列是循环移位关系，利于相关解调与抗窄带干扰。


O-QPSK

（Offset Quadrature Phase-Shift Keying，偏移正交相移键控）

32 chip 拆到 I/Q：

  • I 相位：偶数 chip $c_0,c_2,\ldots,c_{30}$
  • Q 相位：奇数 chip $c_1,c_3,\ldots,c_{31}$

每相位 chip rate $=C/2=1,\mathrm{Mchip/s}$，每 chip 持续 1 μs。O = Offset：Q 相对 I 延迟 0.5 μs（半码片），避免 I/Q 同时跳变，包络更平滑、PA 更省。

脉冲成形：半正弦，上半正弦 = 1，下半正弦 = 0。

▸图源

ch4.pdf 第 31 页。「O-QPSK：I/Q 半码片偏移」。下图按课件结构复绘。

1
2
3
I: c0  c2  c4 ... c30    每码片 1 μs
Q:   c1  c3  ... c31    offset = 0.5 μs
半正弦脉冲成形后再 DAC/发射（同节工作流程页）。

帧

PPDU = 物理头 + MPDU（即 PSDU）。

层 字段 长度 作用
PHY SHR Preamble 4 B 码元 / 位同步
PHY SHR SFD 1 B 帧定界，标志前导结束、数据开始
PHY PHR（Frame Length） 1 B PSDU 长度
PHY PSDU 0～127 B = MPDU
MAC MHR Frame Control 2 B 帧控制
MAC MHR Sequence Number 1 B 序列号
MAC MHR Address 4～20 B 地址
MAC MSDU Payload $n$ 载荷
MAC MFR FCS 2 B 帧校验（不是长度；长度在 PHR）

PPDU 总长 $=11+(4\sim 20)+n$。课件有一处把 MFR 写成「PSDU 长度」，与 PHR 混淆，以本表为准。

▸图源

ch4.pdf 第 32–33 页。「PPDU = PHY 头 + MPDU」。下图按课件结构复绘。

字段表已见上文「帧」节（SHR/SFD/PHR/PSDU；MHR/MSDU/FCS）。课件把 MFR 写成 PSDU 长度时以笔记表为准。


▸思考题：数据流 `10111110` 的 I/Q

约定：按书写顺序从左到右作为 $(b_0 b_1 b_2 b_3)$（与课件符号表一致）。

  1. 拆符号：1011 与 1110。
  2. 查表得 chip：
    • 1011 → 01100000011101111011100011001001
    • 1110 → 10011100001101010010001011101101
  3. 偶数为 I、奇数为 Q（每符号 16 chip）：

符号 1011

  • I：$0,1,0,0,0,1,0,1,1,1,1,0,1,0,1,0$
  • Q：$1,0,0,0,1,1,1,1,0,1,0,0,1,0,0,1$

符号 1110

  • I：$1,0,1,0,0,1,0,0,0,1,0,1,1,1,1,0$
  • Q：$0,1,1,0,0,1,1,1,0,0,0,0,1,0,1,1$

Q 再整体右移 0.5 μs 后脉冲成形、DAC、上变频。若改按「整字节 LSB 先发」解读 10111110，符号变为 0111 再 1101，I/Q 会不同；答题写清约定。

▸再练：`00001111`

符号 0000、1111。查表：

  • 0000 → 11011001110000110101001000101110
  • 1111 → 11001001011000000111011110111000

符号 0000：偶下标为 I、奇下标为 Q（16+16）：

  • I：$1,0,1,0,1,0,0,1,0,0,0,1,0,1,1,1$
  • Q：$1,1,0,1,1,0,0,1,1,1,0,0,0,0,1,0$

步骤不变：拆 4 bit → 查 32 chip → 偶 I 奇 Q → Q 再偏 0.5 μs。换数据流只换查表，算法不换。


MAC

设计目标：压通信能耗。浪费来源：

原因 含义
空闲侦听 主因：收发机开着却无数据
冲突 重叠导致双方都解不出
偷听 收下不是给自己的包
控制开销 包头、RTS/CTS、Beacon 等

传统 CSMA（Carrier Sense Multiple Access）：发前侦听，空闲则发，否则退避。问题是接收方必须一直在线，WSN 不可接受。

降功耗靠低占空比（活动 / 睡眠交替）。核心困难：收发双方找到共同「醒着」的汇合点。

类别 做法 代价
同步 MAC 对齐活动窗口 同步开销
异步 · 发送方发起 前导码 / 数据包列唤醒接收方（LPL） 发送方占信道久
异步 · 接收方发起 接收方周期性 Beacon，发送方听 Beacon 再发（RI-MAC） 发送方可能空听

S-MAC

邻居同步醒睡，只在 listen 窗口传数据。冲突避免类似 802.11：

  1. 虚拟载波侦听：包内带持续时间，写入 NAV 并递减；NAV≠0 则等待。
  2. 物理载波侦听：听信道能量。
  3. RTS/CTS：缓解隐藏 / 暴露终端，也减少无关节点空听。

优点：比一直 CSMA/CA 省。缺点：空闲时仍要集体醒来等第一个包；同步开销；RTS/CTS 开销。

▸图源

ch4.pdf 第 38–39 页。「S-MAC」。下图按课件结构复绘。

1
2
3
Period: [listen][睡眠][listen][睡眠]  邻居对齐
RTS -> CTS -> DATA -> ACK；NAV 虚拟载波侦听
空闲时全员先醒着，同步开销 + RTS/CTS 开销仍在。

LPL

（Low Power Listening，低功耗侦听）

发送方发起。发送足够长的探测列（LPL 直接用数据包当 preamble（前导））；接收方周期性 CCA（Clear Channel Assessment，空闲信道评估：短采样信道能量），超阈值则醒来收包。

▸LPL 像敲门

接收方大部分时间在睡，偶尔「探头」看信道吵不吵（CCA）。发送方必须把「敲门声」（数据包列）拉得足够长，保证接收方醒来时一定能撞上。代价：发送方耗电、占信道久。

CS（Carrier Sense，载波侦听） CCA
相同 看能量是否过阈值，判断附近有没有人在发 同左
不同 发现 → 退避（等会儿再发） 发现 → 唤醒接收
默认阈值 约 −77 dBm 同左
阈值偏高 漏检 → 冲突 漏检 → 漏收
阈值偏低 噪声也退避 噪声也误醒
  • 单播：ACK 可提前截断数据包列。
  • 广播：$T_{\mathrm{train}}\ge T_{\mathrm{sleep}}$，课件例中广播开销约单播的 两倍。
  • 自适应：收完 ACK 后 delay after receive，以便连续包不用再拉长 preamble。

误唤醒：Wi-Fi / BLE 与 15.4 共用 2.4 GHz，能量 CCA 会把异系统当成 ZigBee。可用 RSSI 指纹在 CCA 阶段判别，是 ZigBee 才醒：

协议 突发时长 包间隔 峰均比 RSSI 会低于噪声？
ZigBee [576, 4256] μs 2.8 ms 或 192 μs ≤ 1.3 FALSE
Wi-Fi [194, 542] μs ≥ 28 μs ≥ 1.9 FALSE
Bluetooth 366 μs NA ≤ 1.3 FALSE
Microwave 10 ms 10 ms ≥ 2.9 TRUE

LPL 比同步 MAC 更省（不必全员先醒），但发送方持续占信道，邻节点无法通信。

▸图源

ch4.pdf 第 41–51 页。「LPL MAC」。下图按课件结构复绘。

1
2
3
4
5
发送方: 足够长数据包列当 preamble
接收方: 周期 CCA；能量过阈则醒来收包
单播: ACK 可截短序列；广播: Ttrain >= Tsleep
RSSI 指纹区分 ZigBee vs Wi-Fi（广播时间/间隔/峰均比/是否低于噪声）
波形与指纹图见课件第 43、45、47–52 页原图。

RI-MAC

（Receiver-Initiated MAC，接收方发起的 MAC）

▸和 LPL 反过来

LPL：发送方拼命敲门，接收方偶尔探头。RI-MAC：接收方定期喊「我醒了」（Beacon，信标），发送方一直听，听到再发数据。发送方空听可能更久，但一旦对上，空口占用往往更干净。

发送方有数据则一直侦听，直到收到接收方 Beacon 再发；接收方周期性醒来发 Beacon，若无数据则再睡。冲突用二进制指数退避（Binary Exponential Backoff）。

对比：发送方发起（LPL）用长 preamble 占死信道；接收方发起信道占用短（B–D–A），邻居可穿插。代价是发送方可能长时间空听。

▸图源

ch4.pdf 第 53–55 页。「RI-MAC」。下图按课件结构复绘。

1
2
3
4
接收方周期醒并发 Beacon；发送方听 Beacon 后再 Data
LPL: D D D D D D A   长时间占信道
RI : B D A           占信道短
双发送方: 冲突 -> 二进制指数退避

估计

路由依赖链路质量。指标分两层：

层 指标
PHY RSSI（Received Signal Strength Indicator，接收信号强度指示）、SNR（Signal-to-Noise Ratio，信噪比）、LQI（Link Quality Indicator，链路质量指示）
链路 PRR（Packet Reception Ratio，包接收率；最终判据）
▸为啥最终看 PRR

RSSI/LQI 是「感觉信号强不强」；PRR 是「到底有百分之几的包真正到了」。路由选路最终要对着 PRR（或由它推出来的 ETX）负责，感觉好但老丢包的链路不能用。


RSSI

（Received Signal Strength Indicator，接收信号强度指示）

度量接收总能量。CC2420：对 8 个 symbol（128 μs） 求平均，写入 RSSI_VAL。

$$
P_{\mathrm{dBm}}=\mathrm{RSSI_VAL}+\mathrm{RSSI_OFFSET},\quad \mathrm{RSSI_OFFSET}=-45,\mathrm{dBm}
$$

即 $P=\mathrm{RSSI_VAL}-45$。可按字节读寄存器，或按包在 SFD 后 8 symbol 计算。经验范围约 −95～−55 dBm。

与 PRR（发送功率 0 dBm 与 −7 dBm 两条曲线趋势一致）：

RSSI PRR 含义
$> -87,\mathrm{dBm}$ $>85%$ 好链路
$< -92,\mathrm{dBm}$ $<50%$ 差链路
$-92\sim -87,\mathrm{dBm}$ 剧烈抖动 灰色区域，难预测

问题：灰色区测不准；阈值随接收机灵敏度变化。

【此处插入：RSSI–PRR 曲线（0 dBm / −7 dBm）与灰色区域】

▸图源

ch4.pdf 第 59 页。RSSI–PRR：RSSI>−87 dBm 则 PRR>85%；<−92 dBm 则 PRR<50%；中间灰色区不稳定。分 0 dBm / −7 dBm 两张。无法准确复绘。


SNR

（Signal-to-Noise Ratio，信噪比）

$$
\mathrm{SNR}=10\log_{10}(S/N)\quad(\mathrm{dB})
$$

802.15.4 芯片通常没有直接读 SNR 的接口。CC2420 做法：不收包时 RSSI ≈ 噪声底 −98 dBm；收包时 RSSI 为信号。例：RSSI = −75 dBm → $\mathrm{SNR}=-75-(-98)=23,\mathrm{dB}$。经验 SNR 3～43 dB。SNR–PRR 呈饱和曲线（高 SNR 后 PRR 接近 1）。


LQI

（Link Quality Indicator，链路质量指示）

SFD 之后 8 个 symbol 的相关值 / 码元错误率。课件：

$$
\mathrm{LQI}=(\mathrm{CORR}-a)\cdot b
$$

CORR 为 8 symbol 平均 correlation，范围 0～255；$a,b$ 为经验系数。LQI 经验 50（最差）～110（最好）。CTP 视 LQI > 105 为高质量链路。

单个 LQI 与 PRR 相关性差（LQI=85 时 PRR 可从 10% 到 100%）；平均 LQI 与 PRR 相关性高。

【此处插入：单次 LQI vs PRR 散点；平均 LQI vs PRR】

▸图源

ch4.pdf 第 61 页。单次 LQI–PRR 散点相关性差；平均 LQI–PRR 相关性高。CTP 视 LQI>105 为好链路。无法准确复绘。


PRR

（Packet Reception Ratio，数据包接收率）

成功接收率（不含重传），链路质量的最终指标。估计：一段时间成功数 / 发送总数。

方法 做法 缺陷
Beacon 用信标统计 包长与数据包不同，预测偏
数据包 + receiver feedback 接收方回报 需额外反馈
ACK 计数 窗口内 ACK 数 / 发送数 标准做法

EWMA（Exponentially Weighted Moving Average，指数加权移动平均）：

$$
\mathrm{PRR}\leftarrow \alpha\cdot\mathrm{PRR}_{\mathrm{win}}+(1-\alpha)\cdot\mathrm{PRR}
$$

可调：窗口 $W$、权重 $\alpha$。课件例：$W=3$，$\alpha=0.9$。若窗口 PRR=0.67 且旧值也是 0.67：

$$
0.67\times 0.9+0.67\times 0.1=0.67
$$

若按逐包更新，成功样本为 1、失败为 0：$\mathrm{PRR}\leftarrow\alpha\cdot s+(1-\alpha)\cdot\mathrm{PRR}$，$s\in{0,1}$。

▸EWMA 两窗（$W=3$，$\alpha=0.9$）

初值 $\mathrm{PRR}0=1$。窗 1 发 3 收 2，$\mathrm{PRR}{\mathrm{win}}=2/3\approx 0.667$：

$$0.9\times 0.667+0.1\times 1=0.700$$

窗 2 全成功，$\mathrm{PRR}_{\mathrm{win}}=1$：

$$0.9\times 1+0.1\times 0.700=0.970$$

$\alpha$ 大则更信当前窗，链路变好/变坏都跟得快；$\alpha$ 小则平滑、迟钝。CTP 用它避免单次突发误判。


4-bit

跨层 4-bit 链路估计（TinyOS / CTP 常用）：

位 层 含义
White PHY 1 bit 1 = 各符号误码率很低；LQI < 105 则置 0
Ack L2 1 bit 1 = 收到 ACK，上一包发送成功
Pin 网络 1 bit 路由表钉住该链路，估计器不得删除，直至清零
Compare 网络 1 bit 来包链路是否优于表中一条或多条

适配

6LoWPAN

（IPv6 over Low-Power Wireless Personal Area Network）

在 802.15.4 MAC 与 IPv6 之间加适配层，使海量节点无缝进互联网。两类关键技术：分段重组、头部压缩。

802.15.4 MAC 帧最长 127 B，网络有效载荷约 80～100 B；IPv6 MTU 1280 B，必须分段。

字段 作用
Size 原 IPv6 报文大小，每个分片都带
Tag 同一报文的分片 Tag 相同
Offset 在原报文中的位置；首片省略，后续片必带

IPv6 头 40 B + UDP 头 8 B，压缩重点是 32 B 的源 / 目的地址：利用 链路层地址 ↔ IPv6 IID 的直接映射。地址结构：64 bit 前缀 + 64 bit IID。本地链路单播以 FE80:: 开头；另有若干全球单播前缀。Version、PayloadLen 等可从 MAC 头推导或取常见取值编号，从而省略。

▸图源

ch4.pdf 第 66–71 页。「6LoWPAN」。下图按课件结构复绘。

1
2
3
IP 网 -- 边界路由器 -- LoWPAN 扩展网
IPv6 1280 B 分片 -> 802.15.4 <=127 B；字段 Size/Tag/Offset
IPv6 40 B 头压缩：链路层地址映射 IID；Version/PayloadLen 可省

CTP

（Collection Tree Protocol，收集树协议）

多对一收集；距离向量，选「到根代价最小」的路径；跑在 CSMA 或 LPL 之上，依赖链路估计器。SenSys’09 / TOSN，TinyOS 默认收集协议。


ETX

（Expected Transmission Count，期望传输次数）

链路 ETX：该链路上成功送达一包所需的传输次数

$$
\mathrm{ETX}_f=\frac{1}{d_f\cdot d_r}\approx\frac{1}{d_f}
$$

$d_f$：数据包到达接收方的概率（forward delivery ratio）；$d_r$：ACK（Acknowledgement，确认）回到发送方的概率。ACK 短、成功率常更高，故常近似 $1/d_f$。

▸ETX 怎么理解

若一条链路平均发 2 次才成功（含重传），则 ETX≈2。ETX 越小越好。选父节点时：看「到根的路径 ETX」= 沿途各段链路 ETX 相加（在有逐跳重传的前提下），选总和最小的那条路。

路径 ETX：路径上成功送达一包所需传输次数。根的 ETX = 0；节点 ETX = 父节点 ETX + 到父的链路 ETX。选父时取 ETX 最小者。

▸路径 ETX = 各链路 ETX 之和（证明）

设 $n$ 跳路径，第 $i$ 跳成功（含 ACK 往返）概率为 $p_i$，链路层独立重传至成功。第 $i$ 跳传输次数 $X_i\sim\mathrm{Geometric}(p_i)$，$\mathbb{E}[X_i]=1/p_i=\mathrm{ETX}_i$。

端到端总传输次数 $X=\sum_{i=1}^n X_i$（逐跳交付）。线性性不要求独立：

$$
\mathrm{ETX}{\mathrm{path}}=\mathbb{E}[X]=\sum{i=1}^n\mathbb{E}[X_i]=\sum_{i=1}^n\mathrm{ETX}_i
$$

这就是 CTP / RPL 把路径代价写成链路 ETX 之和的根据。若没有链路层重传、只在源端重传整条路径，则 $\mathrm{ETX}=1/\prod p_i$，不可加——与 CTP 假设不同。

数值例：$d_f=0.8$，$d_r=0.9$ → $\mathrm{ETX}=1/(0.72)\approx 1.39$；近似 $1/0.8=1.25$。两跳 ETX 1.39 与 1.50，路径 ETX ≈ 2.89。

▸三跳选路

链路 PRR（含 ACK）分别为 $0.9$、$0.8$、$0.5$，各段独立、链路层重传到成功。

$$\mathrm{ETX}=1/0.9+1/0.8+1/0.5\approx 1.11+1.25+2.00=\mathbf{4.36}$$

若改走两跳、每跳 PRR=$0.6$：$1/0.6+1/0.6\approx 3.33$，两跳更差的链路仍可能优于三跳更好的链路——这就是 CTP 不按跳数、按 ETX 之和选父的原因。无逐跳重传时不可加，不能用这一套。


建树

Sink S 的 path ETX = 0，广播 beacon。邻居把「下一跳 = S、开销 = 链路 ETX」写入表。A 再广播自己的 path ETX；B 若发现经 A 更优则改父为 A。扩散直至收敛。

课件拓扑边权（链路 ETX，示意）：S–A=1，S–B=3，A–B=1，A–C=1，A–D=1，B–C=1，C–E=1，D–F=1，E–F=1，另有 S–E=3、C–D=2、B–F 等。逐步路由表：

步 1：S 广播 beacon（path ETX=0）

节点 下一跳 开销（path ETX）
A S 1
B S 3
C / D / E / F （尚未挂上或仅听到远处） —

步 2：A 广播 beacon（path ETX=1）

节点 下一跳 开销 说明
A S 1 不变
B A 2 原经 S 为 3；经 A：1+1=2，改父
C A 2 新挂
D A 2 新挂
E （可经 S=3 或后续经 C）
F （待定）

步 3：继续扩散后的典型收敛（课件终态量级）

节点 优选下一跳 path ETX 备选例
A S 1 —
B A 2 S(3)
C A 2 B(3)
D A 2 B(3)
E C 3 D(4)、S(3) 等
F E 或 D 4～6 取最小

原则：始终保留 path ETX 最小 的父；多候选时表中可并存，转发只用最优。与「路径 ETX = 链路 ETX 之和」证明直接对应。

▸图源

ch4.pdf 第 75–77 页。「CTP 建树三步」。下图按课件结构复绘。

1
2
3
S 广播 beacon -> A,B 填父=S
A 广播 -> B 改父为 A（ETX 更优）；C,D 更新
重复至全网 path ETX 收敛（拓扑 S/A/B/C/D/E/F 见课件三页）

帧

路由帧（beacon）

字段 含义
P 路由请求；置位则邻居应发 beacon 更新
C 拥塞；置位表示上一 CTP 包丢失 / 拥塞
Parent 发送者的父节点
ETX 发送者的 path ETX

数据帧：P、C 同上；THL（Time Has Lived）生成时为 0，每跳 +1；ETX 为发送者 path ETX；Origin 源 ID；SeqNo 序列号。


回路

原因：路由信息陈旧。发现：沿正确梯度，包内 ETX 应逐跳减小；若收到包的 ETX 低于自己的 ETX，说明回路。课件数字例：某节点 ETX=4.6，却收到 ETX=8.1 与 3.2 的矛盾比较。

解决：

  1. 广播 beacon，修复不一致（datapath validation）。
  2. 包内 ETX 超过阈值则丢弃不再转发。

Beacon

Beacon 太密：ETX 准但开销大；太疏：路由过时。Adaptive beaconing：间隔由小增大；检测到不一致（如回路）立刻把间隔重置为最小。

▸图源

ch4.pdf 第 81 页。「Adaptive beaconing」。下图按课件结构复绘。

1
2
3
间隔: 小 --Increasing--> 大
检测到回路/不一致: Reset 回最小间隔
锯齿波形见课件原图。

RPL

（IPv6 Routing Protocol for Low-Power and Lossy Networks，低功耗有损网络 IPv6 路由）

6LoWPAN 解决「IPv6 如何跑在 15.4 上」；RPL 解决「如何路由」。组网形态：DODAG（Destination-Oriented Directed Acyclic Graph，面向目的地的有向无环图），单一根。通信模式：

模式 含义
MP2P 多对一，数据收集
P2MP 一对多，数据分发
P2P 点对点 = 上行 + 下行组合

目标函数（OF）：用跳数、时延、ETX 等度量算 Rank，加约束，选 Rank 最低路径。

建立：

  1. 上行：根向下广播 DIO（含 ID、Rank）；节点按 OF 决定是否加入 / 换父。
  2. 下行：沿已建上行，节点向父发 DAO（带路由前缀）。

课件逐步（边权为 ETX，OF = 最小化到根的 ETX）：LBR-1 发 DIO → A/B/C 以 LBR 为父加入 → C 发 DIO，B 把 C 列为备父，E 加入（距离 3）→ A 发 DIO，B 发现 A 更优并改挂 A → 直至 G/H/I 全部加入。

▸RPL vs CTP

CTP 只做 MP2P 收集；RPL 另支持 P2MP 与 P2P，且原生跑在 6LoWPAN/IPv6 上。Ch3 Contiki 栈用的是 RPL，不是 CTP。

▸图源

ch4.pdf 第 83–89 页。「RPL DODAG / DIO」。下图按课件结构复绘。

1
2
3
4
ROOT/LBR-1
  A B C     DIO 向下广播 Rank/ETX；选 Rank 最低路径
  F D E     DAO 沿上行回根，建下行路由
  G H I     逐步加入见课件第 85–89 页

Thread

面向 802.15.4 的 IPv6 mesh，开放标准，可把上百设备互连并直连云。Google / Nest 的 Jonathan Hui 负责产品实现并维护 OpenThread。强调可靠、安全、可扩展、低功耗与自组织。角色二分：Router / End Device；细分为：

大类 子类 含义
FTD Full Thread Device Router 路由
REED Router Eligible End Device 有资格升为路由的端设备
FED Full End Device 全功能端设备（不路由）
MTD Minimal Thread Device MED Minimal End Device 精简端设备
SED Sleepy End Device 可睡眠端设备
▸图源

ch4.pdf 第 91–93 页。「Thread / OpenThread」。下图按课件结构复绘。

1
2
3
FTD: Router | REED | FED
MTD: MED | SED（可睡）
角色二分 Router / End Device；拓扑见第 92–93 页原图。

Matter

（前身 CHIP = Connected Home over IP）

亚马逊、苹果、谷歌与 Zigbee 联盟发起的基于 IPv6 的智能家居互联协议。工作在 OSI 传输层以上，依赖 IPv6。与 BLE / Thread / Wi-Fi / 以太网等「能跑 IP」的链路配合，把分散传感网协议收成商用融合架构。Node 是 fabric 中 CHIP 设备在 IP 网上的一个实例。

拓扑 要点
单一网络 全部 CHIP 设备在同一逻辑网：Thread/15.4，或 Wi-Fi，或以太网；Wi-Fi/以太网可跨多段，只要链路层桥接
星形 多个外围网经中心枢纽（通常是家庭 Wi-Fi/以太网）互联；外围必须经一个或多个 Border Router 接到枢纽

星形图例缩写：AP = Wi-Fi AP；BR = Border Router；ED = Thread End；R = Thread Internal Router；SED = Sleepy End；STA = Wi-Fi Station。

▸图源

ch4.pdf 第 97–98 页。「Matter 组网」。下图按课件结构复绘。

1
2
3
单一网络: 全部 CHIP 节点在同一逻辑网（Thread 或 Wi-Fi/以太桥接）
星形: 家庭 Wi-Fi/以太为枢纽，外围网经 Border Router 接入
AP / BR / ED / R / SED / STA 见图注。

BLE

场景

经典 BLE 组成 piconet 星型：1 个 master + 多个 slave；master 协调，slave 只与 master 通信；同一 piconet 内各 slave 用不同信道。一设备可同时是某 piconet 的 slave、又是另一 piconet 的 slave 或 master（散射网）。

Mesh 多跳角色：

角色 能力
普通节点 边缘，无 relay
转发节点 收到立即转发
朋友节点 特殊转发，可暂存数据
低功耗节点 向朋友查询，不必一直听
朋友（未启用） 具备能力但未开功能
▸图源

ch4.pdf 第 100–101 页。「BLE piconet 与 Mesh 角色」。下图按课件结构复绘。

1
2
piconet: 1 master + 多 slave；同网不同信道（图中同色=同信道）
Mesh: 普通 | 转发 | 朋友（缓存） | 低功耗（问朋友） | 朋友未启用

栈

层 要点
PHY 40 跳频信道：37 数据 + 3 广播（37/38/39）
LL 周期醒睡；CRC、白化、状态机、连接事件
L2CAP 分割 / 重组；重传
ATT / GATT 服务检索与数据结构
SMP 密钥生成与分发

物理

2.400～2.480 GHz，每信道 2 MHz，编号 0～39；37、38、39 为广播，其余为数据。跳频抗干扰：

  • 基础跳频：每对 master/slave 用同一伪随机序列；下一信道由 gMap、$c$、hop 决定。
  • 自适应跳频：双方维护信道质量图 ChM；gMap 按 ChM 标记更新可用信道。

调制：GFSK（Gaussian Frequency-Shift Keying）。相对裸 FSK，高斯滤波后再调频，频谱旁瓣更小、邻道干扰更低。课件以比特 101 对比 FSK（红）与 GFSK（黑）波形。

物理帧：

字段 规则
Preamble 0/1 交替；首 bit 与 Access Address 首 bit 相同；1 Mbps 模式 8 bit 10101010
Access Address 广播固定 0x8E89BED6；数据包在建连时确定，每条链路唯一
PDU 广播 6～37 B；数据 2～257 B
▸图源

ch4.pdf 第 104–105 页。第 104 页 40 信道；第 105 页 GFSK vs FSK 波形/频谱为原图。

1
2
2.400–2.480 GHz，40×2 MHz；37/38/39 广播，其余数据
GFSK=高斯滤波后再 FSK，旁瓣更小。

链路

发送流程：CRC 校验 + 数据白化。CRC 多项式

$$
x^{24}+x^{10}+x^9+x^6+x^4+x^3+x+1
$$

（24 次，余式 3 B，与物理帧 CRC 字段长度一致。）

白化：与 7 bit 伪随机序列异或，避免长 0/1 不利于时钟恢复。

▸为何要白化

若 PDU 连续很多 0，GFSK 频偏几乎不变，接收端难锁比特边界。与 7 bit LFSR 异或后 0/1 交替变密，频谱更平，也减轻对固定 AA 的长游程。CRC 在白化前算（课件顺序：先 CRC 后白化），接收端先解白化再验 CRC。

链路层状态机：

状态 行为
扫描 轮流扫广播信道 37/38/39
准备（Standby） 可切到其它状态的中间态
广播 纯广播或可被连接
初始化 听指定设备，准备发连接响应
连接 由广播或初始化经 CONNECT_REQ 进入

数据包分广播包与数据包。广播 Header 中 PDU type（课件列 4 类交互）：

类型 可连接？ 配对 PDU
ADV_IND 可连接 ↔ CONNECT_REQ
ADV_DIRECT_IND 定向可连接 ↔ CONNECT_REQ
ADV_SCAN_IND 可扫描 ↔ SCAN_REQ / SCAN_RSP
ADV_NONCONN_IND 不可连接 无

TxAdd / RxAdd：0 = 厂商静态地址，1 = 自生成随机地址；RFU 保留。

CONNECT_REQ 载荷：

字段 含义
initA / AdvA 发起者 / 广播方地址
AA 建连后链路唯一标记
WinSize / WinOffset 多连接调度缓冲
Interval 连接事件间隔
Latency slave 可隔多少个事件再应答（省电）
Timeout 等待反馈超时
ChM 40 bit 信道可用图，对应 gMap
Hop 跳频增量

建连：Master 发 CONNECT_REQ → 等 1.25 ms + WinOffset（多连接 schedule）→ Master 发首个连接事件，slave 应答则成功。失败：① slave 在 WinSize 内未收到 Master 包；② Master 在 Timeout 内未收到 slave 反馈。

数据包 Header：

字段 含义
LLID 数据 or 控制
NESN 下一期望序号（停等，0/1）
SN 本包序号（0/1）
MD More Data，本事件是否还有后续
MIC 完整性校验

连接事件间隔 7.5 ms～4 s，且为 1.25 ms 整数倍。Master 发起每次事件，slave 应答；即使无业务也周期发空包保活。Slave 可设 Latency 跳过若干事件。同一事件内 slave 可连发多包（MD=1）。结束后立即休眠。

▸Interval 与 Latency

Interval=24 → $24\times 1.25=\mathbf{30,\mathrm{ms}}$ 一次连接事件。Latency=4：slave 最多连跳 4 个事件才必须应答一次，最坏醒来周期 $5\times 30=150,\mathrm{ms}$。Timeout 须大于这一最坏间隔，否则 Master 会判掉线。多 slave 时 Master 在一个 Interval 内用 0.625 ms slot 做 TDMA，slave 越多 Interval 往往越长。

邻居发现：先扫 37/38/39；例：A 在 38 发现 B，发扫描响应，再进入建连。

多连接维持：TDMA。跳频以 0.625 ms slot 同步。Master 在一个 Interval 内服务完所有 slave 并扫描；slave 越多，Interval 往往越长。

▸图源

ch4.pdf 第 109–117 页。「BLE 链路层」。下图按课件结构复绘。

1
2
3
4
扫描 <-> 准备 <-> 广播 / 初始化 --> CONNECT_REQ --> 连接
Interval 7.5ms–4s (1.25ms 倍)；Latency 可跳过事件；MD=还有后续
Master TDMA 服务多 slave；跳频 slot=0.625 ms
CONNECT_REQ 字段表见上文。

L2CAP

（Logical Link Control and Adaptation Protocol）

分割 / 重组。帧：Length、Channel ID、L2CAP SDU length（重组后总长）。每子帧最大 251 B。子帧无 Offset——因为 BLE 链路是停等，顺序固定。

▸90 B 分段

发送 90 B，CID = 0x4b，与对端协商的子帧最大 44 B（含头）。需拆成多段顺序发送；接收方按到达顺序拼接，不靠 Offset 字段。

头按 Length(2)+CID(2)=4 B；首帧再带 2 B L2CAP SDU length，故首帧净荷最多 $44-6=38$ B，后续帧 $44-4=40$ B。$38+40+12=90$，共 3 帧。第三帧未满 44 B 也照常发，Length 填实际值。

差错控制靠重传。信息帧两种模式：ACK 超时由 sender 重传；或 sender 等 receiver 通知再重传。监督帧反馈：成功 / 未成功 / 拒绝整包 / 拒绝部分。


GATT

（Generic Attribute Profile，通用属性配置文件）

概念 含义
ATT Attribute Protocol，如何检索 / 解析属性
GATT 服务存储的数据结构
Profile slave 提供的一组 Service
Service 一组功能
Characteristic 具体功能（值）

每特征唯一 Handle；UUID 标识服务 / 特征（标准或自定义）；Value；Permission（读 / 写等）。Primary Service 声明 UUID = 0x2800。

课件手机示例（设备名 + 温度）：

Handle UUID Value Permission 备注
0x0100 0x2800 UUID=0x1800 Read Generic Access [service]
0x0101 0x1800 UUID=0x2A00，handler=0x0102 Read, write 设备名 [characteristic]
0x0102 0x2A00 BLE device Read, write 名称值
0x0111 0x2A01 0x0100 Read 外观（手机）
0x0200 0x2800 UUID=0x1809 Read 温度计 [service]
0x0201 0x1809 UUID=0x2A1C，handler=0x0202 Read 温度特征声明
0x0202 0x2A1C 20 Read 读取温度
▸图源

ch4.pdf 第 122–124 页。「GATT」。下图按课件结构复绘。

1
2
3
Profile ⊃ Service ⊃ Characteristic
Handler / UUID / Value / Permission
服务以 UUID 0x2800 作起止；手机例见第 124 页表。

Mesh

四种 Bearer：

类型 用途
ADV (Not Relayed) 非转发节点的广播收发
ADV (Low power) 低功耗节点 ↔ 朋友节点
ADV Bearer 可按 mesh 收发并中继转发
GATT Bearer 无 mesh 能力的传统 BLE 设备也能进网

路由本质是带 TTL 的受控洪泛：每转发一次 TTL−1；TTL 减到不可再转则丢弃；DST 匹配则上层接收。朋友节点替睡眠的低功耗节点缓存。

▸J → E，TTL = 3（课件）
  1. J 把包发给朋友 P。
  2. P 将 TTL 改为 2 后广播 → A、Q、H 收到。
  3. 转发节点 Q 将 TTL 改为 1 再广播 → A、B、C、D、E、R 收到。
  4. E 发现 DST 是自己，接收；R 虽是转发节点，但 TTL 已为 1，不再转发（丢弃中继）。

图源：ch4.pdf 第 127 页「BLE Mesh TTL=3（J→E）」。下图按课件结构复绘。

1
2
3
4
J -> 朋友 P (TTL 3→2 广播) -> A,Q,H
转发 Q (TTL 2→1 广播) -> A,B,C,D,E,R
E 匹配 DST 接收；R 见 TTL=1 不再转发
拓扑节点标号见课件原图。

▸思考题：E → L，TTL = 3

与 J→E 对称，按课件拓扑（E 侧经转发节点到 R，再一跳到 L；L 可为低功耗节点、由朋友缓存）：

  1. E 发出，DST=L，TTL=3；邻近 relay（或朋友）收下。
  2. 该 relay 将 TTL 改为 2 后 ADV 广播 → 中间节点（含 R 等）听到。
  3. R（转发）将 TTL 改为 1 再广播 → L（或其朋友）覆盖内收到并投递；此时 TTL=1，任何转发节点都不得再中继。

若 TTL 初始只有 2，而 E→L 实际要 3 跳物理中继，则 L 永远收不到——这就是「TTL 必须 ≥ 源到目的转发跳数」的考试点。答题：标角色 → 每跳写 TTL 递减 → 强调 TTL=1 只投递不转发 + 朋友替 SED 缓存。


5.x

2016 蓝牙 5.0，至课件时点（2021）已到 5.3。5.0 相对 4.2 三点：

① 2M PHY：物理层最高 2 Mbps（约翻倍），利于 OTA。

② LE Coded PHY（远距离）：同样硬件上用编码提高等效灵敏度、拉远距离。两步：

  • FEC 卷积前向纠错：1 bit → 2 bit。
  • Pattern mapping：FEC 输出再映成 P 符号。
FEC 输入 S=2 S=8
0 0 0011
1 1 1100

S=2 不扩展 FEC 输出；S=8 把 2 bit 扩成 8 bit，抗干扰更强，速率仅为 S=2 的 1/4。

③ 扩展广播：主广播信道仍是 37/38/39，发 ADV_EXT_IND（几乎无数据，AuxPtr 指出下一信道）；接收机跳到次要广播信道（其余 37 个）收 AUX_ADV_IND 及后续，从而突破旧广播 31 B 载荷限制。

后续版本（课件）：

版本 要点
5.1（2019） 室内定位 / 测向，精度到厘米级；GATT 性能、配对与传输加快
5.2（2020） EATT；功耗管理；LE Isochronous 支持多路音频
5.3（2021） Connection subrating：高 / 低占空比实时切换；周期广播可用 ADI（AdvDataInfo）
▸图源

ch4.pdf 第 131–132 页。「蓝牙 5：Coded PHY 与扩展广播」。下图按课件结构复绘。

1
2
3
LE Coded: FEC 1bit->2bit；模式映射 S=2 或 S=8
主广播 37/38/39 发 ADV_EXT_IND（无数据）+ AuxPtr
接收机跳到次要信道收真实载荷

案例

智能灯泡远程控制：PC 命令经 Internet → RPL Border Router → 把 IPv6 转为 802.15.4 帧 → LED 节点亮灭。打通「公网 IPv6 ↔ 传感网」。

部件 硬件 软件职责
边界路由 Raspberry Pi 3 + CC2538SF53 Pi：Internet + RPL/6LoWPAN；CC2538：15.4 射频
LED 节点 CC2538SF53 按 15.4 包控制灯

OS：Contiki-NG。应用层 MQTT：Broker = 边界路由；Subscriber = LED 节点；Publisher = PC。客户端在 Contiki-NG 示例里；Broker 装在树莓派上。

步骤：

  1. Pi 上跑 examples/rpl-border-router（native）。
  2. CC2538 烧 examples/slip-radio；Pi 配串口指向 SLIP radio，绑定 15.4 并生成 IPv6。
  3. MQTT 客户端 project-conf.h 把 Broker 写成边界路由的 IPv6 Global；订阅话题 iot-2/cmd/led/fmt/json；mqtt-client.c：参数 1 开红灯，0 关。
  4. 编译烧写 LED 节点，PC 发布命令验证。
▸图源

ch4.pdf 第 135–140 页。第 135–136 页框图可复绘；接线与红灯为第 138–140 页照片。

1
PC --Internet--> Pi3 (native BR) + CC2538 slip-radio --15.4--> LED 节点

前沿

论文 会议 要点
Oppcast IPSN’16 城市场景抗动态干扰的收集协议；空间多样性（机会路由）+ 信道多样性（多信道跳频），增加可用稳定链路
WEBee MobiCom’17 Wi-Fi→ZigBee 跨技术通信（CTC）：在 Wi-Fi 端精心选择发送符号，使 ZigBee 接收机能解出；约 126 kbps、PRR>99%
RT-BLE INFOCOM’23 BLE 实时多连接调度：建模 + 冲突树时间资源分配 + 基于子速率的快速重调度；相对 SOTA 重调度时延最多降 86.25%，容量升 4.33×
BTrack INFOCOM’24 利用频率合成器硬件缺陷的 TDF（Transient Dynamic Fingerprint，瞬态动态指纹） 追踪 BLE；同型号也唯一，热环境稳定；比 CFO 方法精度高 35.38%～57.41%

【此处插入：Oppcast 机会+跳频示意；WEBee 物理层仿真；BTrack TDF 指纹】

▸图源

ch4.pdf 第 142–145 页。Oppcast（IPSN’16）、WEBee（MobiCom’17）、RT-BLE（INFOCOM’23）、BTrack（INFOCOM’24）论文图。无法准确复绘。


复习

主题 必记
需求 无线 / 低速 / 低功耗；$P\propto d^n$；多跳补距离
标准年 15.4=2003；4c 中国 780 MHz 实为 2009；4e=2010 TDMA+跳频；BLE 4.0=2010
ZigBee vs 15.4 PHY/MAC=15.4；NWK/APL=ZigBee
dBm $D=10\lg P_{\mathrm{mW}}$；100 mW→20；10 mW→10；1 W→30
占空比 $P_{\mathrm{avg}}=D P_{\mathrm{on}}+(1-D)P_{\mathrm{sleep}}$；0.1% → 19.99 μW
路径损耗 $\mathrm{PL}=\mathrm{PL}_0+10n\log(d/d_0)$；例 76.4 m
15.4 速率 2.4 GHz 250 kbps；实际约 1/3；帧 127 B
DSSS 4 bit→32 chip；2 Mchip/s
O-QPSK 偶 I 奇 Q；offset 0.5 μs；半正弦 1 上 0 下
调制题 10111110→符号 1011 / 1110，写出 I/Q
能耗浪费 空听 > 冲突 / 偷听 / 控制
S-MAC 同步窗口；NAV+RTS/CTS；仍有空听与同步开销
LPL 发送方数据包列 + 接收方 CCA；单播 ACK 截断；误唤醒用 RSSI 指纹
RI-MAC 接收方 Beacon；信道占用短；发送方可能空听
RSSI $P=\mathrm{VAL}-45$；>−87 dBm 则 PRR>85%；灰色区 −92～−87
SNR 无直接接口；噪声底 ≈−98；−75 → 23 dB
LQI $(CORR-a)b$；50～110；CTP：>105 高质量；要平均才跟 PRR 相关
PRR / EWMA $\alpha\cdot\mathrm{win}+(1-\alpha)\cdot\mathrm{old}$；W=3, α=0.9；两窗例 0.700→0.970
4-bit White / Ack / Pin / Compare
6LoWPAN 分段 Size+Tag+Offset（首片无 Offset）；地址用链路层映射压缩
ETX $1/(d_f d_r)\approx 1/d_f$；路径可加（链路层重传假设）
CTP 只 MP2P；回路：ETX 应逐跳降；自适应 beacon
RPL DODAG；DIO 上行 / DAO 下行；MP2P+P2MP+P2P
Thread FTD（Router/REED/FED）与 MTD（MED/SED）
Matter CHIP；IP 应用层；单一网 vs 星形+BR
BLE PHY 40×2 MHz；37/38/39 广播；GFSK；AA 广播 0x8E89BED6
BLE LL 状态机；CONNECT_REQ；Interval=24→30 ms；Latency 可跳事件；TDMA 0.625 ms
GATT 0x2800=Primary Service；Handle+UUID+Value+Perm
Mesh TTL 洪泛；朋友缓存；TTL=1 不转发；四类 Bearer
5.0 2M PHY；Coded S=2/8；扩展广播 AuxPtr
案例 Pi+CC2538 边界路由；Contiki-NG；MQTT 话题 iot-2/cmd/led/fmt/json
前沿 Oppcast；WEBee CTC；RT-BLE；BTrack TDF

五、广域

参考课件：ch5 低功耗广域网。学习目标：LPWAN 与短距的区别；LPWAN 关键特性；了解 NB-IoT；掌握卷积码编解码；掌握 LoRaWAN 覆盖增强计算；理解 LoRaWAN 调制。


目标

目标 深度
LPWAN vs 短距 了解
LPWAN 关键特性 了解
NB-IoT 了解
卷积码编码 / 维特比译码 掌握
LoRaWAN 覆盖增强计算 掌握
LoRaWAN 调制 理解

概述

短距靠多跳拉距离，会遇到通信不可靠与 energy hole（能量黑洞）：靠近 sink（汇聚节点）的节点转发负担重、先耗尽。GreenOrbs、CitySee 即此类。

▸能量黑洞

多跳网里，大家都把数据往 sink「倒」。离 sink 最近的几跳节点既要传自己的数据，又要转发别人的，电池最先空 → 整网瘫痪。LPWAN 用单跳远距躲开这个问题（代价是速率低、或要运营商/网关）。

LPWAN（Low-Power Wide-Area Network，低功耗广域网）用单跳做低功耗长距。NB-IoT（Narrowband IoT，窄带物联网）单跳约 10～30 km。2017-06-19 工信部发文全面推进 NB-IoT；中国移动 / 电信 / 华为大力建设。2021-12 LoRaWAN 获 ITU 国际标准。

▸图源

ch5.pdf 第 4–6 页。「短距多跳 vs LPWAN」。下图按课件结构复绘。

1
2
3
短距多跳: 不可靠 + 能量黑洞（GreenOrbs/CitySee）
LPWAN 单跳: 10–30 km（NB-IoT / LoRaWAN）
第 6 页为短距/长距技术对照图。

协议族

协议 要点
NB-IoT Narrowband IoT；3GPP。2014 沃达丰+华为 NB-M2M；高通 NB-OFDMA → NB-CIoT；2015 爱立信等 NB-LTE；二者融合，2016-06 成 NB-IoT
LoRa / LoRaWAN 2013-08 Semtech Chirp 芯片 LoRa；2015-03 LoRa 联盟（课件：290+ 成员，中国 35，含阿里、腾讯）；2015-06 LoRaWAN v1.0（MAC + 网络架构）
Sigfox 法国运营商 2009；超窄带 100 Hz；课件称覆盖 30+ 国
eMTC LTE enhanced MTC；3GPP 2016-06 裁剪 LTE。相对 NB-IoT/LoRa/Sigfox：支持移动性、基站定位、漫游/切换、语音
EC-GSM Extended Coverage GSM；复用 GSM PHY，与 2G 共载波，旧基站扩覆盖、带更多终端
LTE Cat.1 3GPP Rel-8（2009）M2M；无缝进现有 LTE，基站不用大改。下行 10 Mbps / 上行 5 Mbps，快于 NB-IoT，常用于穿戴

技术对照（课件 p.12；覆盖同时给距离与 MCL）：

Wi-Fi BLE ZigBee Pro Sigfox LoRa eMTC EC-GSM NB-IoT 5G
覆盖 17–30+ m 1–10+ m 1–100+ m <12 km / 160 dB <10 km / 157 dB <10 km / 156 dB <15 km / 164 dB <15 km / 164 dB <12 km / 160 dB
频谱 2.4G 未授权 2.4G 2.4G 未授权 ~900M / 100 Hz 未授权 ~900M / <500 kHz 授权 7–900M / 1.4 MHz 授权 8–900M 授权 7–900M / 200 kHz 授权
速率 150 Mbps+ 1 Mbps 250 kbps <100 bps <10 kbps? 课件写 <10 bps 偏保守，PHY 峰值约 5.5 kbps <1 Mbps 10 kbps <50 kbps <1 Mbps
模组价 2016→2020 4$ 4$ 3$ 4$→2.64$ 4$→2.64$ 5$→3.3$ 4.5$→2.97$ 4$→2–3$ <2$
网络重构 无 无 无 大 大 小 中（复用 LTE） 小–中 需 5G

特性

维度：距离、功耗、数据率、频段、基站部署、非技术。


距离

拉远四板斧：

手段 原理 NB-IoT LoRa
提高 PSD 单位频谱能量越大，越远 ✓ PSD 相对 GSM 还略降
重传 多次接收融合，欧氏距离 ×√n，等效功率 ×n ✓ —
多接收天线 融合提高 SINR ✓ —
扩频 冗余换抗干扰 / 解调成功率 DSSS 类比 CSS（主手段）

PSD（Power Spectral Density，功率谱密度）$=\mathrm{功率}/\mathrm{带宽}$。相对 GSM（Global System for Mobile Communications，约 2 W / 200 kHz = 10 mW/kHz）：

▸PSD 为什么能「拉远」

同样总功率，带宽压得越窄，单位频率上的能量越高，接收机更容易从噪声里把信号抠出来 → 覆盖更远。NB-IoT 把上行挤到 3.75 kHz 单音，所以相对 GSM 有约 7 dB PSD 增益；LoRa 带宽 125 kHz 较宽，PSD 反而不占优，主要靠 CSS 扩频换距离。

技术 功率 带宽 PSD (mW/kHz) 相对 GSM
NB-IoT 200 mW 3.75 kHz 53.33 5.33
LoRaWAN 1000 mW 125 kHz 8 0.8

$$
\Delta_{\mathrm{NB}}=10\log_{10}5.33\approx \mathbf{7,dB},\qquad
\Delta_{\mathrm{LoRa}}=10\log_{10}0.8\approx \mathbf{-0.96,dB}
$$

NB-IoT 上行带宽可选 3.75 / 15 kHz，越窄 PSD 越大、覆盖增益越大。

重传：任意信道可重传；上行最多 128 次，下行最多 2048 次。重传 $N$ 次理论增益 $10\lg N$；上行 128 次 $\approx\mathbf{21,dB}$（课件写 20 dB）。顾及效率，工程常取 12 dB。

▸$10\log_{10}N$（dB）
$N$ 1 2 4 8 16 32 128
增益 / dB 0 3.0 6.0 9.0 12.0 15.1 21.1

工程取 12 dB 对应大约 16 次有效合并，而不是理论上行上限 128。欧氏距离叙述：重复 $N$ 次相当于幅度 $\sqrt{N}$、功率 $\times N$。

多天线：1T$m$R 相对 1T1R 增益 $10\lg m$。1T2R → 3 dB。课件给 0～3 dB。

扩频：DSSS / CSS / FHSS。CSS：用宽带线性调频脉冲编码，降对 SNR 的要求。

  • Chirp：频率随时间升（up-chirp）或降（down-chirp）；不同起始频率表示不同数据。
  • 码片：约 $2^{\mathrm{SF}}/\mathrm{SF}$ 个 chip 表示 1 个信息 bit，SF = spreading factor。
  • 解调：接收 chirp 点乘 down-chirp 再 FFT，在起始频率处出峰；能量在频域累积，不易被噪声淹没。
▸思考题：增强距离的技术？NB-IoT / LoRa 各用哪些？

四种：PSD、重传、多天线、扩频。

  • NB-IoT：PSD（~7 dB）+ 重传（工程 ~12 dB，理论上行 128 次 ~20 dB）+ 多天线（1T2R 3 dB）。
  • LoRaWAN：主要 CSS 扩频；PSD 相对 GSM 无增益（约 −0.96 dB）。
▸图源

ch5.pdf 第 16、20 页。第 16 页 PSD 表可复绘；第 20 页 chirp 波形/谱为原图。

功率 带宽 PSD (mW/kHz) vs GSM
NB-IoT 200 mW 3.75 kHz 53.33 5.33 (~+7 dB)
LoRaWAN 1000 mW 125 kHz 8 0.8 (~−1 dB) 
1
CSS: up-chirp / down-chirp；不同起始频率编码；dechirp+FFT 出峰。

功耗

发送 空闲 接收 睡眠
NB-IoT @3.6 V +26 dBm，120 mA 1 mA 50 mA 5 μA
LoRa @3.3 V +20 dBm，120 mA 1.5 μA 12 mA 0.2 μA

NB-IoT

机制 含义
PSM Power Saving Mode 深度睡，UE 不能被寻呼访问，~5 μA
Idle 周期寻呼，可被访问，~1 mA
eDRX extended DRX 加长非连续接收；默认 DRX 寻呼周期 1.28 s，eDRX 最长 2.92 h。下行稀时跳过大部分寻呼

TAU（Tracking Area Update）：Idle 寻呼中发现 tracking area id 变化，向基站发 TAU 更新参数。

PSM / eDRX 同属 3GPP，NB-IoT 与 eMTC 都适用。eDRX 更实时、更耗（1 mA）；PSM 更省（5 μA）。课件：每天发一次 200 B，5 Wh 电池约 12.8 年。中国移动现网试点 PSM 必选。

▸12.8 年从哪来

$5,\mathrm{Wh}$、工作电压按 3.6 V：$C=5/3.6\approx 1.39,\mathrm{Ah}=1390,\mathrm{mAh}$。$12.8,\mathrm{a}\times 365\times 24\approx 1.12\times 10^{5},\mathrm{h}$，反推

$$I_{\mathrm{avg}}\approx 1390/1.12\times 10^{5}\approx 12.4,\mu\mathrm{A}$$

略高于 PSM 的 5 μA，差额就是每天一次 200 B 突发（120 mA 级、毫秒～秒级）摊薄后的均值。结论：寿命由睡眠电流主导，发送次数不能密。

LoRaWAN：Class A / B 为低功耗 MAC；另有严格 duty cycle。例：某信道发 0.5 s，1% DC → 须再等 49.5 s 才能在同信道再发（周期 50 s）。

▸1% DC 再算一遍

空口占用 $T_{\mathrm{on}}$，最小发送间隔 $T_{\mathrm{on}}/D$。$T_{\mathrm{on}}=0.5,\mathrm{s}$，$D=0.01$ → 周期 $50,\mathrm{s}$，其中等待 $49.5,\mathrm{s}$。若 SF12 把同一包拉到 $T_{\mathrm{on}}=1.2,\mathrm{s}$，则须再等 118.8 s。DC 限制的是每信道，换信道可另算一份配额。

▸图源

ch5.pdf 第 22–26 页。「NB PSM 电流色与 LoRaWAN Class」。下图按课件结构复绘。

1
2
3
4
红=发送 120mA；黑=空闲 1mA；灰=PSM 5μA；蓝=接收 50mA
Class A: 上行后 RX1 (>=1s) + RX2 (+1s)
Class B: + beacon 对齐的 ping 槽
Class C: RX2 常开（本占位兼第 26 页）

数据率

面向时延不敏感场景（远程抄表）。

PHY 峰值 实际常用
NB-IoT 上行 250 kbps ~62.5 kbps
NB-IoT 下行 226.7 kbps ~27.2 kbps（基站发完后 UE 至少隔 12 ms 才能 ACK/NACK）
LoRaWAN 上下行 最高 5.470 kbps 1% DC → 仅 54.7 bps

频段

LoRaWAN 非授权。中国 CN470～510：上行 470.3～489.3 MHz（课件一处写 30 个，后文 CN470 写 96 个上行信道）；下行 500.3～509.7 MHz（48 个）；信道标称 200 kHz，LoRa 调制实际 125 kHz + 保护带。

NB-IoT 授权。系统带宽 200 kHz，传输带宽 180 kHz。

上行 下行 运营商
824～849 MHz 869～894 MHz 中国电信
880～915 MHz 925～960 MHz 中国移动、联通

NB-IoT 三种部署：

方式 做法
独立 Stand-alone 用 LTE 未用的 200 kHz，常占一个 GSM 载波（GSM 200 kHz > NB 180 kHz）
保护带 Guard-band LTE 边缘保护带里未用的 180 kHz RB
带内 In-band 占 LTE 1 个 PRB；LTE 1.4 MHz 不支持 IB；任何带宽 IB 都要避开中间 6 个 PRB（LTE 同步 + MIB）；中心频点须落在 100 kHz 栅格（UE 只在 100 kHz 倍数上搜）
▸图源

ch5.pdf 第 29–30 页。「NB-IoT 三种部署」。下图按课件结构复绘。

1
2
3
4
SA: 独立 200 kHz（常占 GSM 载波）
GB: LTE 保护带中 180 kHz
IB: 占 1 个 PRB；避开中心 6 PRB（LTE 同步+MIB）；100 kHz 栅格
LTE 1.4 MHz 不支持 IB

基站

架构：终端 → 基站/网关 → 网络服务器 → 应用服务器。

效率 覆盖深度 数据暴露 代表
复用现有 LTE 高 可能有盲区 公网第三方风险 NB-IoT 公网
自建基站 成本高、慢 可按需深覆盖 私网更可控 LoRaWAN 私网

非技术

NB-IoT LoRaWAN
开放 闭源 开源（github.com/Lora-net）
学术 较少顶会 PHY 黑客 Sigcomm 等常见（PLoRa、Choir…）
ITU 2020，进 5G 2021
成本路径 前向兼容、不重建网；LTE 全双工裁成半双工（射频从两套变一套） 开源吸企业资金铺产业链

NB-IoT

场景：城市垃圾桶满溢、家庭水箱泄漏等广域低频上报。

架构：

实体 职责
UE 终端
BS 接入、小区管理；空口到核心网多为有线
MME 移动性；NB 参数（如头压缩协商）、切换
SGW 转发速率控制
PGW 数据转发
IoT 平台 汇聚各接入网数据，按类型交给应用
应用服务器 最终处理；多由运营商 / 华为等提供

基站可复用 GSM/LTE，也可独立建站。研究热点多在空口承载、交互、加密。

▸图源

ch5.pdf 第 37–38 页。「NB-IoT 网络架构」。下图按课件结构复绘。

1
UE --空口--> BS --有线--> MME/SGW/PGW --> IoT 平台 --> 应用服务器

物理

方向 带宽 子载波间隔 多址
下行 180 kHz = 12 × 15 kHz 15 kHz OFDM
上行 180 kHz 15 kHz 或 3.75 kHz SC-FDMA

时域：slot = 0.5 ms / 7 symbol；subframe = 1 ms = 2 slot（基本调度单元）；frame = 10 ms = 10 subframe。

信号 vs 信道：信号不承载信息 bit；信道传 data。

种类 名称 作用
下行信号 NPSS 时频同步；每帧 子帧 #5，周期 10 ms；最后 11 个 OFDM 符号 × 最低 11 子载波；IB 时避开 LTE CRS
NSSS 小区 ID（PCI 0～503）+ 80 ms 内帧定时；偶数帧子帧 #9，周期 20 ms；11×12=132 RE
NRS 下行信道估计；除 NPSS/NSSS 外，凡有 NPBCH/NPDCCH/NPDSCH 的下行子帧无论有无业务数据都发；每子帧每天线口 8 个 RE，最多 2 天线口。作用：① 测路损做上行功控；② 判 CE level 以定 NPRACH 格式
下行信道 NPBCH MIB-NB（含部署方式）；每帧 子帧 #0
NPDCCH DCI：资源分配等控制
NPDSCH 下行业务、寻呼、RAR
上行 DMRS 信道估计；按 NPUSCH 格式每 slot 1 或 3 个 SC-FDMA 符号
NPRACH 随机接入，跳频；Preamble 单音 + 3.75 kHz
NPUSCH 上行数据 + 控制，可多载波

偶帧子帧占用（课件）：#0 NPBCH；#5 NPSS；#9 NSSS；其余 NPDCCH/NPDSCH。奇帧无 NSSS。

ZC 序列（Zadoff-Chu）：NPSS/NSSS 用。长度 $N_{\mathrm{ZC}}=11$（复数，I/Q 两路）；根索引 $q=5$。性质：恒模（落在单位圆上）、零自相关。NSSS：先生成 131 点根序列，循环扩展到 132 填满 RE。

▸ZC 公式（$N=11$，$q=5$）

$$
x(m)=\exp\Bigl(-j\pi q\frac{m(m+1)}{N_{\mathrm{ZC}}}\Bigr),\quad m=0,1,\ldots,N_{\mathrm{ZC}}-1
$$

$m=0$ 时 $x=1$（I=1，Q=0）。恒模 $\lvert x(m)\rvert=1$；循环移位后与原序列相关为冲激，利于小区搜索时对齐。考试若问「为何用 ZC」：恒模 + 零自相关，不必默写每个样点。


上行资源

频域仍锁在 180 kHz，两种子载波划分：

间隔 子载波数 模式
15 kHz 12 single-tone 或 multi-tone
3.75 kHz 48 仅 single-tone
模式 含义 支持间隔
single-tone 1 用户占 1 子载波 15 kHz 与 3.75 kHz
multi-tone 1 用户占多个子载波 仅 15 kHz

课件图注：相对 multi-tone（$N\times 15,\mathrm{kHz}$），Single-Tone 3.75 kHz 的 UL-PSD 约升 36× ≈ 17 dB（功率集中到更窄载波），覆盖增益显著——与前文「相对 GSM 的 7 dB PSD」同一思路。

时域：

间隔 slot 帧
15 kHz 0.5 ms 10 ms = 20 slot
3.75 kHz NB-slot = 2 ms 10 ms = 5 NB-slot

频域间隔 3.75 = 15 的 1/4，时域 slot 2 ms = 0.5 ms 的 4 倍，等效保持符号能量关系。

RU（Resource Unit，资源单元）：时–频二维最小可调度单位，用来映射一个 TB。3GPP / 课件在 15 kHz 下给四种 RU（子载波数 × 时长）：

RU 频域 时域 备注
① 12 SC 1 ms multi-tone 最「宽短」
② 6 SC 2 ms
③ 3 SC 4 ms 后文编码题「每 RU 占 3 SC × 8 slot」属此类量级
④ 1 SC 8 ms single-tone @15 kHz

补充（3GPP TS 36.300，课件未列表）：single-tone @3.75 kHz 的 Format-1 RU 时长为 32 ms（16×NB-slot）；ACK/NACK 用的 Format-2 更短。基站用 DCI 指定分配的 RU 个数与重复次数 $N_{\mathrm{REP}}$（后文「8 个 RU、$N_{\mathrm{REP}}=4$」即此）。

▸为何要 RU 而不是 LTE RB

LTE 资源块固定「12 SC × 0.5 ms」。NB-IoT 要把同一 180 kHz「切细」给海量低速终端：既可以 12 SC 并行，也可以 1 SC 拉长时间换覆盖。RU 把「带宽 × 时长」做成可调度原子，才出现 single/multi-tone 与 CE 重复的组合拳。

▸图源

ch5.pdf 第 41–51 页。NB-IoT PHY 多页原图（栅格/ZC/NRS/RU）。要点如下。

1
2
3
下行 12×15 kHz OFDM；子帧 1 ms；NPSS 每帧 #5；NSSS 偶帧 #9
ZC: 恒模+零自相关；NB 中 N=11, q=5
上行 single-tone / multi-tone；15 kHz 四种 RU；3.75 kHz 单音 PSD 更高

卷积

P. Elias，1955。有记忆：当前 $n$ 个输出既依赖本拍 $k$ 个输入，也依赖前 $L-1$ 组。三元组 $(n,k,L)$，码率 $R=k/n$。$L$ 为约束长度 / 记忆深度。

课件样例：(2,1,2)，两个移位寄存器，初态 00。与样例及 Trellis 一致的生成关系（输入 $u$，状态 $(s_1,s_0)$，$s_1$ 为最新已存 bit）：

$$
y_1=u\oplus s_1\oplus s_0,\qquad y_2=u\oplus s_0,\qquad
\text{下一状态}=(u,s_1)
$$

从 $u$ 到 输出
00 0 00 00
00 1 10 11
10 0 01 10
10 1 11 01
11 0 01 01
11 1 11 10
01 0 00 11
01 1 10 00
▸编码 `0110`

初态 00。

输入 输出 新状态
0 00 00
1 11 10
1 01 11
0 01 01

码字 00 11 01 01（与课件完全一致）。另一例：$u=[1,1,0,1]\Rightarrow V=[11,01,01,00]$。

▸再编 `1010`

初态 00。

输入 输出 新状态
1 11 10
0 10 01
1 00 10
0 10 01

码字 11 10 00 10。与 0110 对照：同一套状态转移表，只换输入。

维特比（Viterbi Algorithm，维特比算法）：在 Trellis（网格图）上按汉明距（Hamming Distance，硬判决下两串 bit 不同位的个数）保留每状态幸存路径，最后取总度量最小者。

▸维特比在干什么

卷积码有「记忆」，接收串可能被噪声翻了几位。维特比不是猜单个 bit，而是在所有合法路径里找与接收串差得最少的那条，从而同时完成纠错与译码。考试题通常给短序列，用手算网格即可。

▸思考题：收 $[00\,10\,01\,01]$，初态 00，维特比

逐步（度量 = 累计汉明距）：

  1. $R_1=00$：00→00 出 00，度量 0，路径 0；00→10 出 11，度量 2，路径 1。
  2. $R_2=10$：00 度量 1 路径 00；01 度量 2 路径 10；10 度量 3 路径 11；11 度量 4 路径 11。
  3. $R_3=01$：00 度量 2 路径 000；10 度量 2 路径 001；01 度量 4 路径 110；11 度量 3 路径 111。
  4. $R_4=01$：11 度量 2 路径 0011（最优）；00/10/01 均为 3。

译码结果 0011。对应真实码字 00 00 11 01（与接收的汉明距恰好为 2）。若强制回到 00，则次优 0000 / 码字全 0，度量 3。

图源：ch5.pdf 第 55–56 页「卷积码 Trellis / 思考题网格」。下图按课件结构复绘。

1
2
课件例 u=[1 1 0 1] -> V=[11 01 01 00]；错 1 bit 的下图对照
本题收 [00 10 01 01] 逐步度量见 callout；最优路径 0011

TBCC（Tail-Biting Convolutional Code，咬尾卷积码）：输入 $c_0\cdots c_{k-1}$；寄存器初值用块尾 $S_0\cdots S_5=c_{k-1},\ldots,c_{k-6}$；编完最后一 bit 后寄存器回到初态。NB-IoT 下行用 TBCC。

Turbo：LTE 主流；交织使码重合理、降相关、增大最小汉明距，逼近 Shannon 限，纠错强于 TBCC；迭代译码复杂、时延大，更适长包。NB-IoT 上行实例用 1/3 Turbo。


接入

竞争随机接入四步 + RRC（Radio Resource Control，无线资源控制：分配无线资源并带齐建立/修改/释放 L2/PHY 所需参数）。

消息 方向 要点
Msg1 UE→BS Preamble，single-tone，间隔 3.75 kHz，默认跳频。NPRACH 重复 ${1,2,4,\ldots,128}$ 做覆盖增强。开环功控：$\mathrm{P}=\mathrm{P}_{\mathrm{init}}+(\mathrm{counter}-1)\times\mathrm{STEP}$，$\mathrm{STEP}\in{0,2,4,6}$ dB
Msg2 RAR BS→UE 走 NPDSCH，位置由 NPDCCH 指。含 preamble id、定时提前、Msg3 UL grant、Temp C-RNTI。窗内无响应则重发 preamble
Msg3 UE→BS 按 grant 在 NPUSCH 发；开环功控类似 Msg1。初始接入 = RRC 连接请求；重建 = RRC 重建请求；否则至少带 C-RNTI
Msg4 BS→UE 竞争解决：NPDCCH 上 C-RNTI 或 NPDSCH 上 contention ID。定时器内看到自己的 C-RNTI → 成功；否则退避重试，超最大次数则失败

CE level（Coverage Enhancement）：用下行 RSRP 等估计；在对应 NPRACH 资源上做 RA；RAR missing 则 提升 CE 等级 再试。

▸图源

ch5.pdf 第 59–64 页。「随机接入 Msg1–4 与 CE level」。下图按课件结构复绘。

1
2
Msg1 preamble -> Msg2 RAR -> Msg3 RRC -> Msg4 竞争解决
RSRP -> 定 CE level -> 用该级 NPRACH；RAR missing 则升 CE 再试

网络

STM32 NB-IoT 板经 AT 命令 提供 IP/UDP。

命令 作用
AT+NBAND=n 频段；n=5/8/20 → 850/900/800 MHz
AT+CSCON=? 连接状态；1 连接 / 0 Idle
AT+CGPADDR=? 查 IP
AT+NSOCR=DGRAM,17,3000,1 UDP socket，端口 3000，可收下
AT+NSOST=0,IP,3000,len,hex 发 UDP；最大 512 B

上行实例（BC95）：AT+NBAND=5 → AT+CGATT 附着 → 建 UDP → AT+NSOST 发 20 B → AT+NUESTATS=ALL 看功率/时延/块数。

协议头：UDP +8 B；IP +20～40 B；L2 头压缩到 1～2 B 再加 1～4 B。课件假设 20 B payload 经各层后变成 25 B。

▸信道编码后长度

25 B + 3 B CRC = 28 B = 224 bit。1/3 Turbo → $224\times 3=\mathbf{672\ bit}=84\ \mathrm{B}$。

之后速率匹配、分段（例：DCI 给 8 个 RU，分成 BL1/BL2）、QPSK、映射到 RU；重复次数 $N_{\mathrm{REP}}$ 由 DCI 指定（例 =4）。

▸图源

ch5.pdf 第 66–68 页。AT 为串口截图；资源映射为示意。

1
AT+NBAND / CGATT 附着后发 20 B；编码后分 BL1/BL2 映射到 8 个 RU，可重复 NREP

LoRa

LoRa = Semtech PHY（CSS）；LoRaWAN = 联盟 MAC + 星型架构。终端与一个或多个网关 单跳，网关作中继。Sub-GHz 未授权：433 / 868 / 915 MHz 等。

四特性：长距（数 km～数十 km）、低功耗、CSS 抗干扰、低成本。链路预算课件：20 dBm（100 mW）→ 162 dB。

$$
\mathrm{LB}=P_{\mathrm{tx}}+G_{\mathrm{tx}}+G_{\mathrm{rx}}-P_{\mathrm{sens}}
$$

忽略天线时 $P_{\mathrm{sens}}\approx 20-162=\mathbf{-142,dBm}$ 量级。


调制

关键参数：

符号 含义
BW（Bandwidth，带宽） 中国常用 125 kHz；美国 125 或 500 kHz
SF（Spreading Factor，扩频因子） 7～12；一个 chirp（啁啾符号）携带 SF bit
$T_s$ 符号（一个 chirp）时长 $T_s=2^{\mathrm{SF}}/\mathrm{BW}$
▸SF 越大怎么又远又慢

SF=7：一个符号里塞 7 bit，时间短、速率高、难「听远」。SF=12：一个符号 12 bit，但符号时间变成 $2^{12}/BW$，长很多，能量摊在更长时间上，接收机好解调 → 更远、更慢、更耗空口时间。不同 SF 近似正交，像「不同口音」，可同频并存。

数据靠 chirp 起始频率偏移（频率偏移 ≡ 时间偏移）。同一信道 不同 SF 近似正交，6 个用户用 SF 7～12 可并发。

▸覆盖增强 / 处理增益（考试必算）

处理增益常用

$$
G_p=10\log_{10}(2^{\mathrm{SF}})\quad(\mathrm{dB})
$$

或按 chip/bit：$G_p’=10\log_{10}(2^{\mathrm{SF}}/\mathrm{SF})$。课件码片叙述用后者。

SF $2^{\mathrm{SF}}$ $G_p=10\lg(2^{\mathrm{SF}})$ $G_p’$ $T_s$（BW=125 kHz）
7 128 21.1 dB 12.6 dB 1.024 ms
8 256 24.1 dB 15.1 dB 2.048 ms
9 512 27.1 dB 17.5 dB 4.096 ms
10 1024 30.1 dB 20.1 dB 8.192 ms
11 2048 33.1 dB 22.7 dB 16.38 ms
12 4096 36.1 dB 25.3 dB 32.77 ms

SF +1 ≈ $T_s$ 加倍、速率约减半、灵敏度约改善 2.5～3 dB。

灵敏度粗算：

$$
P_{\min}\approx -174+10\log_{10}(\mathrm{BW})+\mathrm{NF}+\mathrm{SNR}_{\min}
$$

其中 $\mathrm{SNR}{\min}$ 随 SF 变负（可在噪声底之下解调）。链路预算 $\mathrm{LB}=P{\mathrm{tx}}-P_{\min}$（加天线增益）。20 dBm + 162 dB ⇒ $P_{\min}\approx-142,\mathrm{dBm}$。

调制例：SF=8，BW=125 kHz，数据 [0, 0, 50] → 三个 chirp 起始偏移 $0/256,T_s$、$0/256,T_s$、$50/256,T_s$（$2^8=256$ 个可能起点）。

▸空中时间粗算

只算数据符号、忽略前导：$T_{\mathrm{data}}=n_{\mathrm{sym}}T_s$。SF=7、BW=125 kHz，$T_s=1.024,\mathrm{ms}$。若编码后约 50 个符号：$T_{\mathrm{data}}\approx 51,\mathrm{ms}$。

SF 每加 1，$T_s$ 加倍；同样 bit 数符号数还略增（每符号多 1 bit，但符号更长占主导）→ 空口时间近似 翻倍，1% DC 下等待也翻倍。这就是「SF12 更远但更慢、更易撞 DC 上限」。

包结构：Preamble = 若干 up-chirp；同步字 = 2 个 up-chirp；SFD = 2.25 个 down-chirp；然后数据。

CN470 信道：上行 96 个（470.3～489.3），LinkADRReq 的 ChMaskCntl 0～5 各管 16 信道，6=全开，7 保留；下行 48 个（500.3～509.7），RXParamSetupReq 设频点。

▸图源

ch5.pdf 第 74–77 页。「LoRa PHY」。下图按课件结构复绘。

1
2
3
chirp: 频率线性扫；offset = 符号 / 2^SF * Ts
SF 7–12 互相正交，同信道可并发
包: Preamble(up) + Sync(2 up) + SFD(2.25 down) + 数据

入网

方式 做法
OTAA Over-The-Air Activation 空中协商地址与会话密钥
ABP Activation By Personalization 出厂烧好地址 / 密钥

入网前：JoinEUI（8 B，入网服务器）、DevEUI（8 B 设备）、NwkKey / AppKey（各 AES-128）。

入网后：DevAddr（4 B）；FNwkSIntKey / SNwkSIntKey（MIC）；NwkSEncKey（MAC 指令加解密）；AppSKey（应用数据加解密）。

OTAA：设备用 AppKey 发 Join-request（MType=000：JoinEUI、DevEUI、DevNonce 每次 +1）→ 网关 Join-accept（MType=001：DevAddr、Home_NetID、DLSettings=RX1/RX2 速率、RxDelay、CFList 上行信道、JoinNonce）→ 派生会话密钥 → ReKey / RekeyConf。

MType：000 入网请求；001 入网许可；010/011 无确认上/下行；100/101 需确认上/下行。

重放：网关若新 Join-request 的 DevNonce 不大于上次则拒；设备对 Join-accept 的 JoinNonce 同样单调检查。

▸图源

ch5.pdf 第 78–79 页。「OTAA」。下图按课件结构复绘。

1
2
3
Join-request(MType=000, DevNonce++) -> Join-accept(MType=001, JoinNonce)
派生 NwkSKey / AppSKey
网关拒非递增 DevNonce；设备拒非递增 JoinNonce

三类

Class 定位 下行机会
A 默认，最省 每次上行后仅 RX1、RX2
B 降下行时延 A 的窗口 + 与网关 beacon 同步的 ping slot
C 供电、最费 除发射和 RX1 外几乎一直 RX2

Class A：想发即发（信道/速率入网时由网关指定）。RXDelay1 / RXDelay2 默认上行结束后 1 s / 2 s。RX1 频点与速率跟上行相关；RX2 由网关指定。网关在窗口起始发。窗口至少能检出 5 个 symbol；无则睡，有则解调 + 地址 + MIC。RX1 成功则不开 RX2。网关若有下行，只能等设备先上行。

  • 无确认上行 MType=010，只开 RX1/RX2。
  • 需确认上行 MType=100；ACK 可在 RX1 或 RX2；未收到则 FCntUp 不变，换信道，随机退避，重试次数 [1,15]。
  • 无确认下行 MType=011，塞进随后窗口。
  • 需确认下行 MType=101：设备可立刻空负载 ACK，或下次上行捎带。

Class B：先 A 入网；搜到 beacon 后上行把 Class B 位置 1，再切 B。设备定 ping 周期，网关定 ping 信道/速率。多网关同时 beacon，设备收最强；NS 按 RSSI 选下行网关。2 小时收不到 beacon → 退回 A。支持单播/多播（多播共享地址与会话密钥；多播帧无 MAC 指令、无下行 ACK）。暂时丢 beacon 时逐渐加大接收窗抗钟漂。

Class C：不在发、不在 RX1 时一直按 RX2 收。RX1 到且网关仍在发则停当前收。因上行窗短，网关不能频繁发需确认下行；Timeout 或收到上行 ACK 后才能再发确认下行；其间可发任意无确认下行。

FPending=1：网关还有更多下行。A：设备随后再开窗；B：立刻发空帧以开 RX1/RX2；C：本来就在听，不触发额外行为。

▸图源

ch5.pdf 第 26 页。「LoRaWAN Class A/B/C」。下图按课件结构复绘。

1
2
3
A: 上行后仅开 RX1、RX2
B: 额外 beacon 同步 ping 槽
C: RX2 几乎常开

帧

MHDR.MType 区分入网 / 数据。FPort：0 = FRMPayload 为 MAC 指令（如 LinkADRReq）；≠0 = 应用数据；空 = 无 payload。FOpts 与 FRMPayload 不能同时放 MAC 指令；FOpts 非空时 FPort≠0。多条指令可同帧，接收方按序回；回不下 FOpts 则改走 FRMPayload；MAC 优先于应用数据。

FCtrl 下行：ARD（让设备用更高速率、更小功率）；FPending；ACK；FOptsLen。FCtrl 上行：ADR；ADRACKReq（确认网关是否还能听到自己）；ACK；Class B 标志。

FCnt（Frame Counter，帧计数器）：上行 FCntUp；下行分 NFCntDown（MAC 指令，网络服务器）与 AFCntDown（应用数据，应用服务器）。OTAA（Over-The-Air Activation，空中激活）入网清 0，ABP（Activation By Personalization，个性化预置激活）不重置。

▸FPort / FOpts 别混
  • FPort=0：这一帧的 FRMPayload 全是给网络层的 MAC 指令（调速率、信道等），不是 App 业务数据。
  • FPort≠0：FRMPayload 是应用数据；若还要捎 MAC 指令，只能放进更短的 FOpts，二者不能同时在 FRMPayload 里塞 MAC。
  • 记忆：应用口（FPort） 与 选项口（FOpts） 分工，MAC 回复优先。
▸OTAA 和 ABP 差在哪

OTAA：设备带着根密钥 AppKey「申请入网」，双方现场算出会话钥 NwkSKey/AppSKey，计数器清零，更安全。ABP：出厂就把会话钥和地址写死，简单但密钥长期不变、FCnt 也不因入网清零，重放风险更大。考试优先会 OTAA。

▸思考题：SX1301 vs SX1276/8 容量

SX1301 = 8 通道 8 解调器；SX1276/8 = 单通道单解调器。ADR 后 SX1301 容量再提高 232.6%（变为原来的 $1+2.326=3.326$ 倍）。

若单通道容量为 $C$，无 ADR 的 8 通道 $=8C$；带 ADR 的 SX1301 $=8C\times 3.326=\mathbf{26.608},C$。

前者约是后者的 26.6 倍（未假设单通道也享同一 ADR 增益；若两者都 ADR，倍数退回 8，与题面「采用 ADR 后的 SX1301」强调不符）。


前沿

方向 内容
性能分析 NB-IoT 市区/郊区、SA/IB 覆盖与连接数、功耗与安全；LoRaWAN 架构/安全/电池/容量/时延/距离对比
优化仿真 NB 编解码与 duty cycle 自适应；LoRa 同 SF 大规模节点建模
应用 智慧城市/家居/农业/穿戴；Semtech + Arduino / Pi 原型

代表论文：

论文 会议 要点
NELoRa SenSys’21 超低 SNR：DNN 滤波提 chirp 特征 + 谱图 DNN 解码
CoLoRa INFOCOM’20 用冲突包时间偏差做 多包接收，提吞吐
LMAC MobiCom’20 用 CAD 做 CSMA；相对 ALOHA 吞吐约 ×2
Seirios MobiCom’21 多信道 CSI + 多锚点超分辨，LoRa 室内外定位
UbiComp’20 — LoRa 穿墙感知，相位–运动模型，30 m 外走势能检
WiRa INFOCOM’22 Wi-Fi→LoRa CTC；小 RU 仿真 LoRa；~40 kbps，SER<0.1
LigBee INFOCOM’23 LoRa→ZigBee 符号级 CTC（课件摘要误写成 Wi-Fi→ZigBee）；BER~$10^{-3}$，FRR 70～80%，>300 m
ChirpTransformer MobiSys’24 四种新 chirp 特征（空中时间、可选起始频率、重复、符号跳变）增强覆盖/吞吐/能效

【此处插入：NELoRa 谱图解码；CoLoRa 冲突分解；WiRa RU 仿真】

▸图源

ch5.pdf 第 119、120、124 页。NELoRa（SenSys’21）、CoLoRa（INFOCOM’20）、WiRa（INFOCOM’22）论文图，无法准确复绘。


案例

智能垃圾桶：压力 → LoRa 节点 → 网关 → IoT 服务器。

部件 型号
终端 LoRa Shield + Arduino UNO + HX711 压力
网关 Dragino LG01
云 TTN（The Things Network）LoRaWAN

步骤：① TTN 注册；② Console 建 Gateway；③ 建 Application + register device，激活选 ABP；④ LG01 网线入网，10.130.1.1 配 LoRa radio 与 TTN 地址/端口/Gateway ID；⑤ Arduino IDE 烧节点（LMIC：NWKSKEY / APPSKEY / DEVADDR；setFrequency(433e6)；LMIC_setDrTxpow(DR_SF7,14)）；⑥ 烧网关收转发；⑦ 串口看发送成功，TTN 网页看 ASCII 上行。

【此处插入：Shield+HX711+LG01 实物；TTN Console；串口 “发送成功”】

▸图源

ch5.pdf 第 129–137 页。LoRa Shield+HX711+LG01 实物、TTN Console、串口发送成功。无法准确复绘。


复习

主题 必记
vs 短距 多跳有能量黑洞；LPWAN 单跳 10～30 km
年表 NB-IoT 2016-06；LoRa 芯片 2013；联盟/WAN 2015；ITU：NB 2020、LoRaWAN 2021
eMTC 移动性+语音；Cat.1：10/5 Mbps
拉距 PSD / 重传 / 多天线 / 扩频；NB=前三，LoRa=CSS
PSD NB $10\lg5.33\approx7$ dB；LoRa $10\lg0.8\approx-0.96$ dB
重传 $10\lg N$；128→~20 dB；工程 12 dB；1T2R=3 dB
功耗 PSM 5 μA 不可寻呼；eDRX 最长 2.92 h；5 Wh≈12.8 年
DC 0.5 s @1% → 再等 49.5 s；SF↑ 则 $T_{\mathrm{on}}$↑、等待↑；LoRa 实际可到 54.7 bps
NB 部署 SA / GB / IB；IB 避中心 6 PRB + 100 kHz 栅格；1.4 MHz 无 IB
公私网 NB 公网复用 LTE；LoRa 自建私网
NB PHY 下行 12×15 kHz OFDM；上行 15/3.75 SC-FDMA；帧 10 ms
上行 RU single/multi-tone；15 kHz 四种 RU；3.75 单音 PSD≈+17 dB
NRS 除 NPSS/NSSS 外每下行子帧发；8 RE/天线口；路损+CE level
同步 NPSS #5 每 10 ms；NSSS 偶帧 #9 每 20 ms；PCI 0–503
卷积 $(n,k,L)$，$R=k/n$；0110→00 11 01 01；1010→11 10 00 10
维特比题 收 00 10 01 01 → 译 0011，真码字 00 00 11 01
TBCC / Turbo 下行咬尾；上行长包 Turbo 1/3
RA Msg1–4；P=P0+(c−1)×STEP；CE level+RSRP
编码长度题 25 B+3 B CRC →×3 = 672 bit
LoRa 参数 $T_s=2^{\mathrm{SF}}/\mathrm{BW}$；SF 7–12；不同 SF 正交
覆盖增强 $G_p=10\lg(2^{\mathrm{SF}})$；LB=162 dB @20 dBm
调制例 SF8 数据 0,0,50 → offset 0,0,50 / 256 Ts
OTAA vs ABP Nonce 防重放；OTAA 清 FCnt，ABP 不清
Class A 仅 RX1/2；B beacon+ping；C 常开；FPending 对 C 无动作
ADR 题 8×3.326≈26.6 倍
案例 UNO+HX711+LG01+TTN ABP；433 MHz SF7 14 dBm
前沿 NELoRa / CoLoRa / LMAC / Seirios / WiRa / LigBee / ChirpTransformer

六、云平台

参考课件：ch6 物联网云平台。学习目标：与传统云的区别；主要功能 7 块（连接、管理、IFTTT/规则、时序+流、安全认证、无服务器、边缘；课件有时称「8 项」）；掌握 HTTP / MQTT / CoAP 传输模型与报文；掌握 IFTTT 规则冲突判定；了解 AWS IoT、Azure IoT、阿里云 IoT 与开源选型。


目标

目标 深度
作用及 vs 传统云 了解
主要功能 了解
HTTP / MQTT / CoAP 模型与报文 掌握
IFTTT 规则冲突判定 掌握
AWS / Azure / 阿里云关键特性 了解

概述

云是物联网应用的关键一环。城市大脑：汇聚海量异构数据，优化运行（交通信号）、预防破坏（火情、人脸追踪）、辅助决策。共享单车：车辆管理、远程解锁、计费、用户管理；终端常走 MQTT/CoAP → 连接管理平台 → 云基础设施；手机 App 走 MQTT/HTTP。

▸图源

ch6.pdf 第 4–5 页。第 4 页城市大脑为场景照片+数据流；第 5 页共享单车栈可复绘。

1
2
城市大脑: 海量异构数据 -> 智能算法/存储 -> 信号灯/预警/决策
单车: 车锁 --MQTT/CoAP--> OneLink CMP --云基础设施--> App(MQTT/HTTP)

区别

维度 传统云 物联网云
连接 服务器 / 浏览器为主 轻量协议，异构设备
管理 虚机 / 容器 海量、多状态终端
存储 通用 OLTP / 对象 时序为主
安全 账号 / TLS 设备更易被攻，需更强认证
计算 批 + 交互 高并发流式

玩家：运营商（移动 OneLink）；设备商（庆科云、海尔优家）；互联网（AWS IoT、阿里云 IoT）；创业（涂鸦、AbleCloud）。


四类

按服务逻辑，可重叠：

类型 全称 做什么 代表
CMP Connectivity Management Platform（连接管理平台） 网络资源、SIM、资费、套餐、用量、账单、故障 爱立信 DCP、沃达丰 GDSP、移动 OneLink
DMP Device Management Platform（设备管理平台） 配置/重启/恢复/OTA、现场数据查询、告警、生命周期 Watson、Predix、三一根云、海尔 U+
AEP Application Enablement Platform（应用使能平台） 开发工具、中间件、逻辑引擎、API、应用服务器 阿里云 IoT、AWS IoT、涂鸦
BAP Business Analytics Platform（业务分析平台） 结构/非结构数据 → 预测、认知分析；尚不成熟 Azure IoT、阿里云+西门子 MindSphere
▸四类云怎么分

CMP 管「卡和流量」；DMP 管「设备活着吗、升级了吗」；AEP 管「开发者怎么快速做出应用」；BAP 管「数据里挖出业务洞察」。同一厂商产品往往跨多类。

OneLink 例：共享单车物联网卡；接口含在线状态、网络定位、流量（算网络成本）。U+ 例：洗衣机按材质/颜色设模式；空气管家按室内外空气调温净化；热水器峰谷闲时加热。Link Develop：端–云–移动一站式 + 可视化编排。


连接

弱设备：轻量协议 → 网关协议转换 → 云。强设备：本地 HTTP 栈直连。


HTTP

（Hypertext Transfer Protocol）

传 Web 文档。请求：方法 URI 版本\r\n + 首部行 + 空行 + 体。应答：版本 状态码 短语\r\n + 首部 + 空行 + 体。

方法 含义
GET 读页面
POST 提交表单 / 上传附加数据
DELETE 删指定资源
状态码 含义
1xx 通知（已收到 / 处理中）
2xx 成功
3xx 重定向
4xx 客户端错（404、语法）
5xx 服务器错

上传温度 25℃ 课件例：HTTP 体 824 B + TCP 头 20+12=32 B。

弱点：① 无状态，每次独立，先建立 TCP；② 仅客户端主动，下行控制要设备自建 Web Server；③ 头重，短消息低频场景过重。

▸图源

ch6.pdf 第 18–21 页。「HTTP 报文与温度上报体积」。下图按课件结构复绘。

1
2
3
请求: 方法+URL+版本 | 首部行 | 空行 | 体
应答: 版本+状态码 | 首部 | 空行 | HTML 体
温度 25℃: HTTP 824 B + TCP 32 B

CoAP

（Constrained Application Protocol）

面向资源受限节点的 M2M 协议，语义贴近 HTTP。

模型 行为
非确认 Non-confirmable Request/Response 只发一次，无 ACK；任一方丢则失败
确认 Confirmable 任一方丢则重传；ACK 与数据作为 Response 同时到请求端；停等 + 指数退避

报文：Ver=01；Token 0～8 B（Client 生成，匹配并发请求）；Message ID 去重，ACK/RST 回同一序号。

Type (2 bit) 含义
00 CON 需确认；停等+指数退避
01 NON 不需确认
10 ACK 正确处理的确认
11 RST 错误 / 拒绝

Code：0.00 空；0.01～0.31 请求；2.xx～5.xx 响应（类 HTTP）；1.xx / 6–7 保留。

温度 25℃：8 + 32 B（CoAP+UDP/下层）vs HTTP 32+824 B。

特点：头短；无中间代理，节点可直连；有 GET/POST/DELETE；CON/NON + 方法可组合；仍是主动请求——B 要拿 A 的数据，须先向 A 发 Request。

▸图源

ch6.pdf 第 23–28 页。「CoAP」。下图按课件结构复绘。

1
2
3
4
CON: 停等+指数退避；ACK 可捎带 Response
NON: 只发一次
Ver=01 | Type | TKL | Code | Message ID | Token | Options | Payload
温度例 8+32 B vs HTTP 32+824 B

MQTT

（Message Queuing Telemetry Transport，消息队列遥测传输）

极轻量 发布 / 订阅（Publish / Subscribe）。Broker（代理服务器）转发。特点：头短；话题（Topic）一对多广播；两话题可做 Client 双向；三种 QoS（Quality of Service，服务质量）。

▸MQTT 像微信群

设备往某个 Topic「发朋友圈」，订阅了该 Topic 的人都能收到。中间站着 Broker，发布者和订阅者不必直连、也不必同时在线（配合保留消息等机制）。对比 HTTP：HTTP 像「打电话点餐」，每次都是客户端主动问；MQTT 更适合「传感器一有数据就推」。

类型 值 方向 含义
CONNECT / CONNACK 1 / 2 C→S / S→C 连接及确认
PUBLISH / PUBACK 3 / 4 双向 发布及 ACK
SUBSCRIBE / SUBACK 8 / 9 C→S / S→C 订阅及确认
DISCONNECT 14 C→S 断开
Reserved 0 / 15 — 保留

PUBLISH Flag：Bit3 DUP（1=重传）；Bit2–1 QoS 0～2；Bit0 RETAIN（1=Broker 保留给后来订阅者）。

QoS 语义
0 最多一次（fire-and-forget）
1 至少一次
2 恰好一次

温度 25℃：MQTT 32+20 B vs HTTP 32+824 B。

固定头：1 B 类型+Flag + 剩余长度 Remaining Length（1～4 B 可变编码）。剩余长度 = 变长头 + 载荷字节数，不含编码自身所用字节。编码：每字节低 7 bit 存数据，最高 bit=1 表示后续还有字节；最大表示 $268,435,455$。

▸剩余长度编码
  • $64$ → 单字节 0x40。
  • $321=65+2\times128$ → 两字节：首字节 65|0x80=193（0xC1），次字节 2。
  • 算法：do { b=X%128; X/=128; if(X) b|=0x80; emit b; } while(X);
▸PUBLISH 字段怎么设
  • 保留给后来订阅者且恰好一次：QoS2，retained=true，dup=false。
  • 清空某话题保留消息：QoS0，retained=true，空 payload。
  • 至少一次、不保留：QoS1，retained=false。
  • 最低代价：QoS0，retained=false。
  • 重传：dup=true（通常配合 QoS1/2）。

云平台协议支持（课件）：

HTTP HTTPS MQTT CoAP
AWS IoT √ √ √ ×
Azure IoT √ √ √ ×
阿里云 IoT √ √ √ √
IBM Watson √ × √ ×
▸思考题：MQTT / CoAP / HTTP 对照
MQTT CoAP HTTP
OSI 应用层 应用层 应用层
传输层 TCP UDP TCP
可靠 QoS0/1/2 可选 CON+ACK；NON 不可靠 靠 TCP
传输代价 低 最低 高
多播 话题一对多（经 Broker） UDP 可多播；无 Broker 基本无
受限设备双向 易（双话题 pub/sub） 须对端先 Request 下行需设备当 Server
中间代理 必须 Broker 无 可选反向代理，非必须
温度示例（B） 32+20 8+32 32+824
▸图源

ch6.pdf 第 30–40 页。「MQTT」。下图按课件结构复绘。

1
2
3
4
Client ==publish/subscribe==> Broker <==> 其他 Client
固定头 + 变长头 + 剩余长度(1–4 B) + 载荷
QoS0 最多一次；QoS1 PUBLISH-PUBACK；QoS2 四步握手
温度例 TCP32 + MQTT 约 20 B 量级（课件对照 HTTP）

管理

属性 含义 对应
deviceId 设备 ID 标识
status 启用 / 禁用 生命周期
connectionState 已连 / 断开 在线状态
version 当前固件 版本跟踪
updateList OTA 包地址+版本 固件更新

对象：终端 + 智能网关（聚合、ZigBee↔Wi-Fi 等协议转换、本地/远程单设备控制；管理变多层）。

方式 模式 离线
直接管理（Direct Method） 请求–响应，要立即确认 可能失败
设备影子（Device Shadow，亦称物影子 Thing Shadow） 云上持久虚拟副本；比较「期望 desired vs 最近上报 reported」并收敛 可先写期望，上线再生效
▸影子像「云上的遥控器备忘录」

设备关机时，App 仍可把「期望温度=26℃」写进影子。设备下次上线，云把 desired 与 reported 一比，发现不一致，就下发，直到两边对齐。这样不用设备一直在线也能改配置。

OTA（Over-The-Air，空中下载升级）：启动时上报版本（不必周期）；云比较当前 vs 最新；升完再报新版本以确认。差分同 Ch3：COPY cost=5，ADD=3+n；R3diff 最差 $O(n^3)$、平均 $O(n^2)$、空间 $O(n)$。百度评估：95% 不保护升级包；90% 不防 MITM（Man-in-the-Middle，中间人攻击）；61% 可被降级。对策：签名、双向认证、包加密、通道防护。

▸图源

ch6.pdf 第 47–49 页。「设备影子与 OTA」。下图按课件结构复绘。

1
2
用户写 desired；设备上报 reported；云对齐差异
OTA: 启动上报 version -> 云比较 -> 下发 -> 升级后再报新版本

规则

IFTTT

（If This Then That，「如果这样那么那样」）

云端条件语句，解耦设备代码与应用逻辑，支持多设备联动。例：soil≤θ → 灌溉；temp≥θ1 ∧ humidity≤θ2 → 告警。

▸IFTTT 冲突怎么判

两规则「吵起来」要同时满足：① 条件有可能一起为真（时间/传感器区间有交集）；② 对着同一设备下了相反动作（一个开一个关）。只条件能同时真但动作相同 → 不叫冲突；动作相反但条件永远碰不上 → 也不冲突。

问题：规则冲突；实时 vs 能耗；公平；逻辑与执行耦合 → 规则引擎（Rule Engine）。

冲突充要：① IF 条件可能同时真；② 控制同一设备且动作相反。

例：

  • light>10000 → off 与 light<500 → on：区间不交，无冲突。
  • light>10000 → off 与 light<20000 → on：$(10000,20000)$ 可同时真，冲突。
  • light>10000 → off 与 light<20000 → off：区间可交，但动作相同，不冲突。
  • light>10000 → off 与 time∈[19:00,24:00] → on：19:01 且 15000 lux 可同时真，冲突。

检测：指示变量 $x_i=1\Leftrightarrow\mathrm{cond}_i$ 真，问 $\bigwedge$ 冲突动作的条件是否可满足（SAT / SMT，如微软 Z3）。同一传感器上若 $\mathrm{cond}_1\cap\mathrm{cond}_3=\varnothing$，则含 $x_1=x_3=1$ 的赋值不可行。

▸思考题：灯规则是否冲突

R1：IF time∈[07:00,17:00] ∨ light>10000 THEN turnOff

R2：IF light<1000 ∨ sound>55 dB THEN turnOn

冲突。反例：light=999 lux 且 time=07:01（sound 任意）：R1 因时间成立要关灯，R2 因 light<1000 要开灯，同一灯相反动作。

实时 vs 能耗：轮询密 → 实时好、耗电；疏 → 省电、关窗可能来不及（雨淋进屋）。RT-IFTTT：接近阈值加密询，远离则疏；语法加 WITH time<60 and missratio<0.01。

公平：某应用规则过多/过频会饿死其它；调度尚无很好方案。


TAP

（Trigger-Action Program）

Condition（状态布尔约束）+ Trigger（事件 / 状态迁移）+ Action。例：白天(C) 小米灯被关(T) → 语音(A)；任意时刻灯开 1 min(T) → 自动关(A)。利好非技术用户。

三类干扰：

类型 含义
动作干扰 两规则同时触发，对同一执行器下相反命令（下雨且 T>30℃ 时开电视触发「开窗/关窗」），终态不可预测
触发干扰 一动作意外成为另一规则的 Trigger（远程开电视连带开窗，给窃贼窗口）
条件干扰 一 Action 破坏另一规则的 Condition（睡眠模式关落地灯 → 入侵检测失效，假阴性）

检测：统一规则表示 + 符号执行抽规则、匹配干扰模式。

▸图源

ch6.pdf 第 54–66 页。IFTTT 相交为示意可复绘；TAP 三类为漫画原图；Z3 为代码页。

1
2
3
冲突 = 条件可同真 AND 同设备反动作（lux 区间相交）
TAP: 动作干扰 / 触发干扰 / 条件干扰
SMT/Z3 把条件编码为可满足性查询

时序

时序数据 = 带 timestamp 的序列（如工厂每秒温度）。TSDB 专管此类。传统 RDB：写入吞吐低、压缩差、维护贵、查询弱。

TSDB 特点：基本无更新（插 / 查 / 删）；高并发写（LSM：先内存再顺序落盘）；低延迟高并发查（分布式 + 预聚合）；分级存储（内存 / SSD / HDD）+ 高压缩。

开源：InfluxDB、KairosDB、OpenTSDB、Beringei、TimeScaleDB。云：AWS Timestream、阿里云 TSDB。InfluxDB 三特性：Time Series 函数、Metrics 实时聚合、Events。

流计算：严格 = 对数据流一遍扫描算特征；一般 = 每元素短时间少量运算、省内存。例：高速路由特征、金融实时分析。

▸1～100 缺 2 个数

流式一遍：维护 $S=\sum x_i$、$Q=\sum x_i^2$。令缺 $a,b$，则 $a+b=5050-S$，$ab=((a+b)^2-(Q_{\mathrm{full}}-Q))/2$，解二次方程。$O(n)$ 时间 $O(1)$ 额外空间。

对照算法：布尔数组 / bitset 标记出现，$O(n)$ 时间 $O(n)$ 空间；或排序后线性扫相邻差，$O(n\log n)$。课件要求编程比两种耗时比。XOR 一次只能找 1 个缺失；找 2 个需按某一 bit 分组再 XOR，也是 $O(n)/O(1)$，可作第三种流式。

▸缺两数的 XOR 算法

全集 ${1,\ldots,n}$，出现序列异或后再与 $1\oplus 2\oplus\cdots\oplus n$ 异或，得 $a\oplus b$（记 $x$）。因 $a\neq b$，$x$ 至少有一位为 1，取最低置位 mask = x & -x。

把出现的数按该 bit 分成两组，各组再异或（并分别与该组应有的全集异或），得到 $a$、$b$。

例：$n=5$，缺 $2,5$，出现 $1,3,4$。$1\oplus3\oplus4\oplus(1\oplus2\oplus3\oplus4\oplus5)=2\oplus5=7$。mask=1（最低位）。奇数侧 ${1,3}$ 与全集奇数 ${1,3,5}$ 再异或得 5；偶数侧得 2。

相对平方和：不涉及大整数平方溢出；仍 $O(n)$ 时间、$O(1)$ 额外空间。中位数没有这种 $O(1)$ 空间一遍算法（需选分位数结构）。

框架：Flink、Spark Streaming、Kafka 等。

▸图源

ch6.pdf 第 70–75 页。LSM 路径可复绘；InfluxQL/时序图为第 72–74 页截图。

1
2
写: WAL/MemTable -> flush SSTable（LSM）
流式: 一遍扫描求 Σ、Σ²；中位数则难

认证

（课件「安全认证」功能块；与第八章机制互补——此处站在云平台能力视角）

设备比浏览器更易被物理接触与克隆，云必须在「连接点」完成设备身份校验，未通过则不交换业务数据。


对称

云与设备预共享一把对称密钥。添加设备时平台生成密钥，开发者写入固件。建连时设备用该密钥对「设备标识 + 随机数/时间戳」加密（或 HMAC）生成令牌，平台验令牌。优点：实现轻、适 MCU。缺点：密钥要安全灌装与轮换；一设备一密，泄露面随规模线性增。阿里三元组的 DeviceSecret 即此路线（见第七章 HMAC 例、第八章）。


非对称

设备持私钥签名，云用公钥验。公钥靠 X.509 + PKI 分发。证书可记为

$$
P_B\ \Vert\ D_{\mathrm{CA}}(\mathrm{SHA}(P_B))
$$

人人已知 CA 公钥 $E_{\mathrm{CA}}$，可验 CA 对 $P_B$ 的签名块。

▸Trudy 攻 X.509 为何失败（课件）
  1. 挂假证书 $P_T\Vert D_{\mathrm{CA}}(\mathrm{SHA}(P_T))$：Alice 一看主体是 Trudy，直接拒绝冒充 Bob。
  2. 把 Bob 证书里的 $P_B$ 改成 $P_{B2}$（塞进 Trudy 公钥）：Trudy 无法伪造 $D_{\mathrm{CA}}(\mathrm{SHA}(P_{B2}))$，因为没有 CA 私钥。Alice 验签时 $\mathrm{SHA}(P_{B2})\neq E_{\mathrm{CA}}(D_{\mathrm{CA}}(\mathrm{SHA}(P_B)))$，发现篡改。

AWS IoT 设备侧默认走 X.509；另有 SigV4、客户令牌。


IBC

（Identity-Based Cryptograph，基于身份的密码）

把设备标识本身当作公钥。云已知设备 ID，不必再维护一套 PKI 证书树；私钥由 PKG（Private Key Generator）生成并安全下发。特点：免证书存储与吊销链；通常只覆盖「设备 ↔ 本云」，不直接替代互联网泛在 HTTPS 的 CA 体系。与 Link ID²（标识即身份）思路同族。


权限

身份认证通过后，还要授权：账号密码会话，或令牌（内含权限策略名 + 用权限密钥算出的签名字段）。AWS 把 IoT policy / IAM 绑到证书；阿里把 Topic 读写权限绑到产品/设备。

▸图源

ch6.pdf 第 79–83 页。「设备认证」。下图按课件结构复绘。

1
2
3
4
对称: 云发密钥 -> 设备用密钥做令牌 -> 云验令牌
X.509: 证书 PB || DCA(SHA(PB))；人人知 CA 公钥
Trudy: ① 放自己证书 Alice 会发现是 Trudy；② 改 PB 却签不出
IBC: 设备标识即公钥，无需 PKI

无服务器

（Serverless Computing）

全托管：用户只写并上传代码；事件驱动；云自管资源；带日志与监控。

传统 PaaS 做缩略图：买/管主机、运行时依赖、对象存储+DB、写逻辑、手配 AutoScaling。Serverless：对象存储+DB + 写函数，自动弹性。

Serverless PaaS
语言 较少 丰富
运行时 自动 手搭
依赖 受限 可任意装
运维 无 要管
计费 按代码运行时间 按实例存活（空闲也可能计费）

课件数据：业界服务器利用率常 <30%（「70%+ 未充分利用」）；Serverless 通常可再省 10%～90% 成本（视负载脉冲程度）。

语言 Azure Functions AWS Lambda 阿里函数计算 GCP
JavaScript / Node √ √ √ √
Python √ √ √ √
Java √ √ √ √
C# / .NET √ √ √ √
PHP · √ √
Go / F# 等 F#√ Go√ √

三类常见问题：供应商锁定（触发器/API 绑定云）；冷启动（久未调用的实例唤醒延迟，IoT 突发上报敏感）；工具链相对传统 PaaS 仍在成熟中。

四类用法：① HTTP 触发做无服务器 API；② 对象存储事件（上传图 → 缩略图）；③ 定时（如微博情感分析）；④ 静态资源放对象存储 + 函数做动态后端。

▸图源

ch6.pdf 第 87–92 页。「PaaS vs Serverless」。下图按课件结构复绘。

1
2
3
PaaS: 多实例 + 手动 AutoScaling
Functions: 事件到则拉起，按运行时间计费
冷启动: 久未调用 -> 唤醒延迟

边缘

无服务器下沉。定义：在近用户端提供无线接入网上的 IT / 云能力。

下沉 特点
RPC 轻，但服务代码须预置
容器 轻，依赖宿主机内核；Azure IoT Edge / AWS Greengrass / 阿里 Link Edge
虚机 分发量大，更灵活，屏蔽 OS 异构
OTA 整机更新，开销大

传统：节点 → 云上流分析 / 函数 / DB。边缘：初步分析放路由或设备。优势：实时、省骨干带宽、数据不出户、断网仍可分析。

下沉锚点 = 函数所依赖功能的 最近公共父节点。例：规则与 8、9 相关 → 锚在 E；与 7、9 → C；与 1、9 → 无法下沉（公共父已是云）。

平台 公司 时间 中国区 计费 底层 AI
Greengrass 亚马逊 2016.12 否 按设备 容器 ML Interface
Azure IoT Edge 微软 2017.5 是 免费 容器 AI Toolkit
Watson IoT Edge IBM 2016.7 是 按流量 容器 AI 工具包
Link Edge 阿里 2018.3 是 免费（限设备/消息数） 容器 AI 能力
▸图源

ch6.pdf 第 95、98 页。「边缘路径与 LCA 下沉」。下图按课件结构复绘。

1
2
3
云模式: 节点 -> 云流分析/函数/DB
边缘:   节点 -> 边侧分析 -> 云
规则依赖功能的最近公共父；1 与 9 的公共父已在云则无法下沉

厂商

AWS IoT

时间线：AWS 云 2002 起；IoT 2015-10 公测、2015-12 商用。设备通信：MQTT、WebSockets、HTTP 1.1（无 CoAP）。认证：SigV4、X.509、客户令牌；未验证则永不交换数据。注册表为每设备统一身份与元数据。设备影子（Device Shadow，亦称物影子）存最新状态，离线也可被应用读写。规则引擎评估入站消息，按业务规则变换并送到其它设备或云服务。边缘：Greengrass。Lambda 例：Kinesis 收访客流 → Lambda 轮询处理 → 写 DynamoDB → 可视化。


Azure IoT

连接：MQTT、HTTPS、AMQP（高级消息队列：重量、SASL+TLS、C/S 对等；MQTT 轻量、不自带与 AMQP 同级的强制安全、C/S 不对称）。管理：直接 + 影子 + 智能网关。存储：传统库 + Cosmos / MySQL / PostgreSQL / MariaDB。认证：应用层设备身份；传输 HTTPS；网络 VPN。无服务器：Azure Functions。边缘：ML/分析/AI 推向网关或设备（自动驾驶、AR）。另：机器学习服务 + 认知服务（情绪/视频、人脸语音视觉、语音语言理解）。


阿里云 IoT

架构口号：云–网–边–端。通信：MQTT / CoAP / HTTPS。管理：直接+影子；网关子设备；OTA。时序：TSDB。规则引擎可转发到 RDS/表格存储/TSDB、DataHub 流/离线计算、函数计算、另一 Topic（M2M）、MQ。函数计算语言含 Python/PHP/Java/.NET/Go；计费≈调用次数+执行时间+公网流量。边缘 Link Edge：设备接入、边缘函数、消息路由（规则下沉）、断网续传。特色：ID² 设备身份 + IoT Studio 全链路（见第七、八章）。


开源

Home Assistant：HA OS / Container / Core / Supervised；OS 最全。内核四件：① Event Bus；② State Machine（state_changed）；③ Service Registry（call_service）；④ Timer（每秒 time_changed）。安装：下载 HA OS 镜像 → 写入存储介质 → 启动 → 浏览器 http://IP:8123。用例：Dark Sky precip_intensity——下雨且有人在家且 14:00–23:00 开客厅灯；雨停且日落前 1 h 内关灯（YAML：trigger / condition / action）。

ThingsBoard：开源收集/处理/可视化/设备管理；MQTT/CoAP/HTTP；云或本地；可扩到百万设备。架构：传输层、核、规则引擎、Web UI。Transport 微服务提供三协议 API；Node 处理 REST、WebSocket 订阅、规则、在线监控；Web UI 用 Express 托管静态页。可对接 NB-IoT / LoRaWAN / Sigfox 等专用 payload。

规则引擎三件套：消息 / 规则节点 / 规则链。另有 Scheduler：到点生成规则引擎消息 → 进根规则链。社区三件套：Gateway（遗留/第三方接入）、Edge（边缘过滤后上云）、Mobile（Flutter 跨平台）。

▸DHT22 温度规则链（课件）

打开 Root Rule Chain → 加过滤器节点（如温度 ∈ [−40, 80] ℃）→ True 出口接「保存遥测」，False 出口接「日志」。终端发 temp=99 → 走日志；发 temp=24 → 落库。用来理解「规则链 = 消息在节点间路由」。


选型

课件总表（√/× 以课件 p138 为准；「可视化」指设备托管侧的可视化）：

平台 存储 可视化 MQTT CoAP HTTP 统一 API 接入 SDK 交互 SDK Drag-Drop 前端接入 SDK 前端统一 API IFTTT 后台统一 API
AWS IoT √ × √ × √ × √ × × √ × √ ×
Azure IoT √ √ √ × √ × √ × × √ × √ ×
中移 OneNet √ √ √ × √ × × × √ × × √ ×
IBM Watson √ √ √ × × × √ × × √ × √ ×
SmartThings × × × × × × × × × × √ × √
ARM Mbed × × × √ × √ × × × √ × × ×
阿里 Link √ √ √ √ √ × √ × × × × √ ×

读表：要 CoAP → 阿里或 Mbed；要 拖拽前端 → OneNet；要 capability/插件式 App → SmartThings；要 端侧统一 API → Mbed；要 IFTTT 式规则 → AWS/Azure/OneNet/Watson/阿里。

▸思考题：五平台功能一句话

AWS：影子+规则+Greengrass，设备多用 X.509。Azure：AMQP+Functions+认知/ML，边缘强。阿里：MQTT/CoAP+TSDB+ID²+Studio，云网边端。HA：本地智能家居事件总线与自动化。ThingsBoard：开源规则链+多协议+可自托管。

▸图源

ch6.pdf 第 101–138 页。架构/控制台多为截图；对照与选型表按课件整理。

1
2
3
4
5
6
AWS: 影子+规则+Lambda/Greengrass+X.509
Azure: Functions+AMQP+IoT Edge
阿里: MQTT/CoAP+TSDB+ID2+Studio
HA: Event Bus / State / Service / Timer；YAML 下雨自动化见第 123 页
ThingsBoard: 传输层 / Core / 规则引擎 / Web UI（第 125 页）
选型总表第 138 页

复习

主题 必记
vs 传统云 轻量异构连接、海量状态、时序、更强认证、高并发流
四类 CMP/DMP/AEP/BAP；OneLink / U+ / Link Develop / MindSphere
HTTP 无状态、只客户端主动、头重；温度 32+824 B
CoAP UDP；CON/NON/ACK/RST；Token 匹配；8+32 B；无 Broker
MQTT TCP；Pub/Sub+Broker；QoS0/1/2；DUP/RETAIN；32+20 B；剩余长度 1–4 B
对照题 填 OSI/传输/可靠/代价/多播/双向/代理/字节
云支持 仅阿里标配 CoAP；Azure 有 AMQP
影子 vs 直接 离线可写期望；直接要在线确认
OTA 启动上报版本；COPY=5，ADD=3+n
IFTTT 冲突 条件可同真 ∧ 同设备反动作；同动作不冲突；999 lux@07:01
TAP 干扰 动作 / 触发 / 条件
TSDB 无更新、LSM、分级压缩；InfluxDB
缺两数 Σ+Σ² 解方程；XOR 分组；bitset/排序
认证 对称令牌；X.509（Trudy 两招失败）；IBC 标识即公钥；权限令牌
Serverless 按运行时间；冷启动；语言表；四类用法
边缘锚点 依赖功能的 LCA；1 与 9 无法下沉
三朵云 AWS 影子+规则+Greengrass+X.509；Azure Functions+AMQP+认知；阿里 CoAP+TSDB+ID²
开源 HA：Event Bus/State/Service/Timer；TB：规则链+Gateway/Edge/Mobile
选型表 CoAP→阿里/Mbed；Drag-Drop→OneNet；IFTTT→AWS/Azure/阿里等

七、一体

参考课件：ch7 云端一体开发平台。学习目标：了解概念与主流平台；掌握 TinyLink 开发流程；掌握 IoT Studio 物模型与服务编排；掌握 TinyLink 与 IoT Studio 联合开发。


目标

目标 深度
云–端一体概念 了解
主流平台 了解
TinyLink 开发流程 掌握
IoT Studio 物模型 + 服务编排 掌握
TinyLink × IoT Studio 联合 掌握

概述

完整物联网应用横跨嵌入式、网络协议、云、Web、移动，技术栈碎片化、标准不统一。空气质量监测：传感网（嵌入式）→ Wi-Fi/BLE/GPRS → 云 API → Web/App/小程序。共享单车：BLE/NB-IoT + Azure（摩拜）+ App。

一体平台目标：覆盖设备–云–应用全链路。代表：三星 SmartThings、阿里 IoT Studio（原 Link Develop）、涂鸦 Tuya、浙大 TinyLink（MobiCom’17）。

▸图源

ch7.pdf 第 4–8 页。「技术栈碎片 vs 一体平台覆盖」。下图按课件结构复绘。

1
2
3
4
应用层 Web/App
云服务层
传感器网络层 + Wi-Fi/BLE/GPRS
一体平台覆盖: 设备端 | 云服务 | Web/移动 | 三端集成

功能

四块：设备端开发、云服务开发、Web/移动应用、三端集成简化。


设备端

方式 要点 代表
本地编译 + SDK SDK=API+文档+工具；统一接入/开发接口，屏蔽硬件 涂鸦 MCU SDK
物联网 OS 统一接口 + 调度/资源/OTA AliOS Things
云端编译 本地不搭工具链 TinyLink（自顶向下）
解释型 易跨平台，设备上要跑解释器 IoT Studio 在线 JavaScript；MicroPython（machine / network）
可视化流 Node-RED（Node.js 事件非阻塞）；Pi / Docker / Arduino / 云 推文 #LED → Trigger → GPIO 闪灯

传统自底向上：先定功能（PM2.5/温/光）→ 选 Arduino+SDS018+DHT11+光照 → 对引脚写驱动。痛点：要懂硬件兼容、各平台驱动、换板几乎重写。

平台对照（设备端）：

本地编译 云编译 解释型
TinyLink × √ 自顶向下 ×
IoT Studio √（多语言 SDK / AliOS） √ √ JS
Tuya √ MCU SDK × ×

MicroPython（课件 ch7 第 16–21 页）：面向 MCU 的 Python 3 实现。支持 ESP8266 / ESP32 / STM32 / pyboard / WiPy 等；驱动覆盖 GPIO、SPI、I2C、ADC、DAC、PWM。核心库：machine（硬件块）、network（网卡）、bluetooth（BLE 角色与 GATT）。与云编译相对：本地仍要在设备上跑解释器，换来跨平台与免交叉编译。

1
2
3
4
5
6
from machine import Pin
import time
led = Pin(2, Pin.OUT)
while True:
    led.value(not led.value())
    time.sleep(1)

下降沿中断：Pin(4, Pin.IN).irq(trigger=Pin.IRQ_FALLING, handler=handle_interrupt)。Wi-Fi STA：network.WLAN(network.STA_IF) 后 active(True)、connect(ssid, password)。

▸图源

ch7.pdf 第 16–21 页。「MicroPython」。板型照片为原图；库与示例如上。

IoT Studio 的在线工作台走 JavaScript 解释型；MicroPython 是同一类「设备上解释」路线的另一实现。Node-RED 则是可视化流，不是解释型语言本身。


云服务

特点：异构协议设备多；大量传感触发规则；存储/读取等逻辑可复用。路径：设备接入（发现 → 控制认证 → 注册分配 ID 并对接属性/控制）→ IFTTT 或 服务编排。

编排：每个服务节点是一个基础 API（查询、存储…）；组合并配置节点成业务。例：无人且灯开 → 关灯（摄像头判人慢，光照判灯快）。

IFTTT 编排
TinyLink √ ×
IoT Studio × √
Tuya √ ×

应用

方式 要点 代表
由设备代码生成框架 从 MQTT 下行 case / 上报字段自动出 Web/App 骨架 TinyLink、OneNet
可视化拖拽 组件 + 配置 IoT Studio 温度看板、Tuya
插件 / 传统 SDK 灵活、门槛高 Tuya、IoT Studio 传统开发

TinyLink：√ 框架生成。IoT Studio：√ 拖拽 + √ 传统。Tuya：拖拽 + 插件 + 传统。


集成

设备模型降低三端耦合。

模型 命名
TinyLink × TCP/IP
IoT Studio 物模型 TCP/IP
Tuya × TCP/IP
SmartThings 设备档案 JSON：设备⊃组件⊃ capability⊃(属性,命令)；只能用平台已有 capability（约 73 种） 另有 NDN 分层名

NDN 例：/MyHome/Bedroom/Lighting/sensing/Intense/202112311920；聚合前缀收全部光强；新设备兴趣包 /local/discovery/lighting/serial=123456，配置管理器赋 ID、前缀、功能集。

智能灯泡模型：开/关（云控）；光照、声强属性；属性上报事件。硬件实现开关；软件用虚拟设备按模型先做 App。

▸思考题：一体平台如何简化开发？

① 设备：SDK/OS/云编译/解释型，TinyLink 自顶向下先写功能再自动选型烧录。② 云：IFTTT 或可视化编排，少写胶水。③ 应用：代码生成框架或拖拽组件。④ 集成：物模型 / 设备档案统一属性–事件–服务，端云 App 按同一契约对接，换硬件不必改应用。

市场总表（课件 p.54）：

本地 云编译 解释 IFTTT 编排 拖拽 框架生成 插件 设备模型 命名
ARM Mbed √ √ √
OneNet √ √ √
TinyLink √ √ √ √
SmartThings √ √ √ √
Tuya √ √ √ √ √
LinkDevelop √ √ √ √ √ √ √
▸图源

ch7.pdf 第 25、32、38、43–45、52、54 页。「能力矩阵与设备模型」。下图按课件结构复绘。

1
2
3
4
四块: 设备端开发 | 云服务 | Web/移动 | 三端集成简化
SmartThings: 设备>组件>capability（只能用平台已有）
IoT Studio 物模型: 属性 / 事件 / 服务，可自定义
平台对比表见课件第 25/32/38/52/54 页。

EmNets：2017-03 1.0 软硬一体（MobiCom’17 Guan/Dong）；2017-12 2.0 加上云规则与手机端。


流程

自顶向下：写与板无关的 setup/loop + TL_* API → 上传云 → 输出硬件配置 + 二进制 → 按清单组装 → 客户端一键烧录。站点：http://tinylink.emnets.org。

室内环境监测例（对比传统 Arduino 引脚代码）：

1
2
3
4
5
6
7
8
9
10
void setup() {
  TL_WiFi.init();
  TL_WiFi.join("SSID", "PASSWORD");
  TL_Light.setMeasuringRange(1, 30000, "LUX");
}
void loop() {
  TL_Light.read();
  TL_Soil_Humidity.read();
  /* … */
}

云端给出：Arduino Mega2560 + Mega Shield；SDS018 UART D14/D15；Grove Light 模拟 A0/A1；Grove 温湿度数字 D2/D3。推荐系统可列出数十种等价 BOM，其中可编译的约 8 种。

特点：自动接 Watson / OneNet；可按价格 / 功耗优化；编程即 Arduino 风格。客户端 69 MB vs Arduino+LinkIt 包 420 MB、Pi/BBB 交叉链 266/302 MB。

支持板：UNO/Mega/DUE、LinkIt One/7688、Pi 2/3、BBB、TinyBLE、AliOS MK3060 等；Grove 系列传感器 + SDS018 等。

▸图源

ch7.pdf 第 64–73 页。五步可复绘；连接图/客户端截图为原图。体积：客户端 69 MB vs Arduino+LinkIt 420 MB。

1
①写 TL_*  ②上传云编译  ③硬件配置  ④组装  ⑤一键烧写

硬件生成

库表记录每件的成本、提供/占用的模拟/UART/… 端口与功能（LED/WiFi/Light…）。

用户约束：功能覆盖。例：含 WiFi 的模块数 ≥1（主板 LinkIt One ∪ WiFi Shield ∪ Grove UART WiFi…）。

接口约束：对 Analog、UART、I2C、SPI、USB… 每类

$$
\sum \text{提供 Port}\ \ge\ \sum \text{消耗 Port}
\quad(\text{主板}\cup\text{扩展}\cup\text{外设})
$$

规约：在主板/扩展/外设中选子集，min 价格 s.t. 用户约束 + 硬件约束。约 210 条，经典 线性规划，lp_solver。

▸三条约束长什么样

变量 $x_i\in{0,1}$ 表示是否选用第 $i$ 件。室内环境监测至少要光照、温湿度、联网：

  1. 功能：$\sum_{i\in\mathrm{WiFi}}x_i\ge 1$（LinkIt One 主板、WiFi Shield、Grove UART WiFi 任一即可）。
  2. 接口：$\sum$ 提供的 Analog port $\ge\sum$ 消耗的 Analog port（Grove 光照占模拟口，UNO 提供 6 路模拟，盾板再贡献 Grove 口）。
  3. 目标：$\min\sum c_i x_i$。

互斥：同一功能不要叠两块同类传感（可加 $\sum_{i\in\mathrm{DHT}}x_i=1$）。这就是课件「约 210 条线性约束」的缩小版。

▸图源

ch7.pdf 第 77–81 页。「TinyLink 硬件生成 = 线性规划」。下图按课件结构复绘。

1
2
3
4
库表: 成本 + 提供/占用端口 + 功能
用户约束: 功能覆盖（如 WiFi 模块数>=1）
接口: Σ提供 Port >= Σ消耗 Port
min 价格 s.t. 约束；约 210 条；lp_solver

软件生成

从 116 个公开 IoT 项目抽 225 个常用 API，实现 24 类（LED、温湿度、显示、WiFi…）；覆盖约 89.8% 项目 API / 67.2% 项目可完整用 TinyLink 实现。

调试：#REQUIRE DBGPrint; → 必加 UART 打日志；#REQUIRE DBG; → 仅选支持交互调试的板（Pi/BBB 用 gdb，并给源码）。


2.0

设备：领域宏/类型、任务、高层 API 封装 1.0、LoRa、并发。云：规则 → JSON，条件+REST 成后缀式；事件触发 / 时间触发；三线程 + Redis FIFO（消息 / 规则 / 命令）。移动：@Client 微应用 → AST → JS，混合模板 WebView。

关键：微应用模型（传感、事件、对外服务，屏蔽传报/调用）；隐式交互（跨微应用查接口数据，自动维持一致）；云定义节点行为（增强 IFTTT + 任务时刻）；虚拟传感器（多源自动学推理模型）。


Studio

2018-06 Link Develop 2.0 → 2019-01 更名 IoT Studio → 2021-03 3.0（Web/移动可视化、业务逻辑、数据分析）。

设备：SDK / AliOS / 在线 JS；本地+云编译+解释。云：可视化编排工作台（服务管理、编辑区、节点配置）。应用：拖拽。集成：物模型抽象。


物模型

（Thing Model；阿里云用 TSL = Thing Specification Language，物规格语言，JSON 描述）

设备开发者与服务开发者共同定义一类设备的功能。

▸物模型像「设备说明书的标准填空」

不关心板子是 ESP32 还是 STM32，只约定：有哪些属性（能读的状态，如温度）、事件（会主动喊的事，如高温报警）、服务（能被调用的动作，如开机）。端、云、App 都按同一份说明书对接，换硬件也不必改应用逻辑。

类型 含义 例
属性 Property 运行时状态 温度、湿度
服务 Service 可被外部调用的方法；同步 / 异步 turnOn / turnOff
事件 Event 需被外部感知的通知 故障、任务完成、属性上报

骨架：schema、link、profile.productKey（平台生成）+ properties[] + events[] + services[]。

属性字段：identifier（产品内唯一）、name、accessMode（r / rw）、required、dataType.type（int/float/double/text/bool/array）、specs（min/max/unit/unitName/step/size/item）。

事件：type ∈ {info, alert, error}；outputData；method 由 identifier 生成，如 thing.event.TemperatureAlarm.post。

服务：identifier、inputData/outputData、method=thing.service.xxx、callType sync/async。

智能空调例：属性 temp float −40～50 ℃ step 0.1 只读；事件 TemperatureAlarm 输出枚举 0 正常 / 1 高温（>30℃），type=alert；服务 open 同步，返回 bool。

三类 Topic（{pk}=ProductKey，{dn}=deviceName，{id}=功能 identifier）：

方向 Topic method 例
属性上报 /sys/{pk}/{dn}/thing/event/property/post thing.event.property.post
事件上报 /sys/{pk}/{dn}/thing/event/{id}/post thing.event.TemperatureAlarm.post
服务调用（云→端） /sys/{pk}/{dn}/thing/service/{id} thing.service.open

属性上报 body 骨架：{"id":"123","version":"1.0","params":{"temp":30},"method":"thing.event.property.post"}。事件把 params 换成事件输出（如 AlarmType）。服务调用 params 为入参，端侧应答另有 reply Topic（平台文档约定）。

▸思考题：空气盒子 TSL

属性：Temp float −40～50 ℃ step 0.1 只读；Humi float 0～100 % step 0.1 只读。事件 PropPost：输出两属性，method=thing.event.prop.post。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "properties": [
    {"identifier":"Temp","name":"温度","accessMode":"r","required":false,
     "dataType":{"type":"float","specs":{"min":"-40","max":"50","step":"0.1","unit":"℃","unitName":"摄氏度"}}},
    {"identifier":"Humi","name":"湿度","accessMode":"r","required":false,
     "dataType":{"type":"float","specs":{"min":"0","max":"100","step":"0.1","unit":"%","unitName":"百分比"}}}
  ],
  "events": [{
    "identifier":"PropPost","name":"属性上报","type":"info","required":false,
    "method":"thing.event.prop.post",
    "outputData":[
      {"identifier":"Temp","name":"温度","dataType":{"type":"float"}},
      {"identifier":"Humi","name":"湿度","dataType":{"type":"float"}}
    ]
  }],
  "services": []
}

▸图源

ch7.pdf 第 103–116 页。「物模型 TSL」。下图按课件结构复绘。

1
2
3
属性 Property | 事件 Event | 服务 Service
空调例: temp float | temp_alert | open 同步
上报 Topic: /sys/{pk}/{dn}/thing/event/property/post

编排

拖拽节点连成：属性查询、转储、推送；自定义脚本做复杂逻辑。

案例：温度 >30℃ → 钉钉群。四节点：设备触发 → NodeJS 脚本 → 路径选择 → 钉钉机器人。

逐步配置（课件）：

  1. 画布放入上述四节点并连线。
  2. 设备触发：选产品/设备，条件为属性变化或定时。
  3. NodeJS（示意）：
    1
    2
    3
    4
    module.exports = async function (payload, node, query, context) {
      const t = payload.props.temperature.value;
      return { temperature: t };
    };
  4. 路径选择：temperature ≥ 30 → 钉钉分支，否则结束（最多 10 分支）。
  5. 钉钉机器人：填 access_token，模板引用上游温度字段。
  6. 部署后改设备温度验证群消息。

节点类别（课件全表）：

类 节点
触发 空间 / 设备 / 定时 / HTTP 请求 / MQTT 订阅
输出 HTTP 返回
功能 路径选择、Python 2.7.9、条件判断、数值计算、Node.js 6.10
识别 人脸 / OCR / 图像识别
通知 短信 / 钉钉 / 移动推送 / MQTT 发布
API 自定义 / 云市场 / 项目内
数据 变量、表格存储、RDS MySQL、KV、数据分析
设备 产品结点（设属性、调服务、查快照/历史）
▸图源

ch7.pdf 第 118–126 页。画布/连线为工作台截图；节点分类表已见上文。

1
设备触发 -> NodeJS -> 路径选择(>=30℃) -> 钉钉机器人

涂鸦

2016 全球化平台；可进 Alexa / Google / HomeKit / SmartThings。课件 2021-07：37.4 万开发者，200+ 国家。

设备：① 零代码——电工/照明/传感等标准品，可视化配功能+模组，自动出固件；② 低代码——带 MCU，用 MCU SDK；③ 多代码——网关/摄像头等复杂设备 SDK。云：脚本规则。应用：可视化 + SDK。工业方案较成熟。

▸涂鸦在一体课里的位置

TinyLink / IoT Studio 偏「自己搭端+云」；涂鸦偏「厂商级交钥匙」：标准品甚至可零代码出固件，再挂上 Alexa 等语音生态。考试记住三档开发深度（零 / 低 / 多代码）与「云规则 + 应用可视化」即可，细节不如 TinyLink 流程考得细。


联合

TinyLink 做设备端（含按物模型接入）；IoT Studio 做云编排 + Web/App。关键：TinyLink 按 TSL Topic/JSON 上报。Studio 设备端硬件例：ESP32、STM32F/L4、EMW3060/3080、STM32F103/F7 等；不足是板型仍偏少、不少路径仍自底向上——故与 TinyLink 联合。


座位

智能教室座位统计（课件九步压缩）：

步 内容
1 Studio 建项目 / 产品
2 自定义属性 deviceID、motionState
3 硬件：Pi 4B + PIR；接线 5V/GND/GPIO18 ↔ VCC/GND/D1
4 装 aliyun-iot-device-sdk + Pigpio（或改用 TinyLink TL_PIR）
5 postProps 每 10 s 上报；on('connect') 后启动定时器
6–9 可视化 Web：指示灯/文本/时钟绑数据源 → 预览

签名

MQTT 接入参数：securemode 2=TLS / 3=TCP；signmethod ∈ {hmacSha1, hmacSha256, hmacMd5}；

$$
\mathrm{password}=\mathrm{sign}_{hmac}(\mathrm{deviceSecret},\ \mathrm{content})
$$

content 拼接顺序（课件）：clientId{id}deviceName{dn}productKey{pk}timestamp{ts}。

▸HMAC 数值例（可验算）
字段 值
clientId 12345
deviceName device
productKey pk
timestamp 789
signmethod hmacsha1
deviceSecret secret
  • clientName = 12345|securemode=3,signmethod=hmacsha1,timestamp=789|
  • userName = device&pk
  • password = hmacsha1("secret","clientId12345deviceNamedeviceproductKeypktimestamp789").toHexString() = FAFD82A3D602B37FB0FA8B7892F24A477F851A14
  • serverName = pk.iot-as-mqtt.cn-shanghai.aliyuncs.com，port 1883（TCP 模式）
  • Topic = /sys/pk/device/thing/event/property/post

TinyLink loop 中拼 JSON：params 含 deviceID、motionState=TL_PIR.read()，method=thing.event.property.post，再 mqtt.publish。

三平台小结：

设备 服务 应用 特点
TinyLink 硬件无关语言 + 云编译 IFTTT 由设备代码生成框架 最简，适初学
IoT Studio / Link Develop SDK / AliOS / JS 可视化编排 可视化搭建 方式多、更灵活
Tuya 零/低/多代码 脚本规则 可视化 + SDK（含 React Native 面板、OEM App） 方案成熟、工业支持多；另有边缘网关 Docker
▸图源

ch7.pdf 第 135–152 页。接线/控制台为截图；架构与表可复绘。第 152 页三平台总结表。

1
2
3
TinyLink 端 --MQTT 1883 HMAC--> 阿里云 -- 物模型 --> IoT Studio Web
座位: Pi GPIO18 + PIR；属性 deviceID / motionState
HMAC 例见课件第 147–148 页参数表

复习

主题 必记
为何一体 栈碎、标准乱；覆盖端–云–应用
TinyLink vs 传统 自顶向下 vs 先选型再写引脚
TL 五步 写 TL_* → 上传 → 配置+bin → 组装 → 一键烧
硬件 LP 功能覆盖 + 每类 Port 供需；min 价；~210 约束；lp_solve
软件 225 API / 24 类；DBGPrint / DBG
2.0 微应用、隐式交互、云定义行为、虚拟传感器
物模型 属性/事件/服务；TSL JSON；accessMode r/rw
空气盒子题 Temp/Humi + PropPost thing.event.prop.post
Topic 三件套 property/post；event/{id}/post；service/{id}
编排 触发→NodeJS→路径→钉钉；路径≤10；节点全表
SmartThings capability 只能用平台已有；Studio 可自定义
联合 座位：deviceID+motionState；GPIO18；10 s 上报
HMAC 例 content=clientId…timestamp789；密码=FAFD82A3…
对照表 TinyLink：云编译+IFTTT+框架生成；Studio：编排+物模型+JS；MicroPython：设备端解释

八、安全

参考课件：ch8 物联网安全。目录：概述 → 攻击面与安全机制 → 典型开发框架 → 温度监控（TEE+MQTT TLS）案例 → 学术前沿。物联网部署广、场景杂，攻击面远大于传统 IT 网。


概述

2016-06 央视：家庭摄像头被扫出 IP 后即可偷窥，已成地下生意。智能电表：反工程破解账号与读数；截获空口包实时监视用电；发假包改计量。端侧无物理边界、无线信道开放、固件可拔、云侧账号可撞，任意一层失守即可连坐。

【此处插入：摄像头偷窥示意；电表天线+假包路径】

▸图源

ch8.pdf 第 4–5 页。家庭摄像头偷窥新闻图；智能电表天线与假包攻击路径。无法准确复绘。


攻击

分网络层与硬件层。被动式多在合法用户无觉察下完成；主动式会改系统或信息，同时伤机密性、完整性、可用性。


网络

类型 手段 目标
被动 嗅探、扫描、窃听 端口、信道、潜在漏洞；不改数据
主动 假冒 / Sybil、篡改、重放、DoS/DDoS、干扰、恶意软件 完整性 + 可用性；常伴随泄密

被动三项：

  • 嗅探：监听链路上流经的包。
  • 扫描：对端口发探测，由响应推断服务与漏洞，再入侵。
  • 窃听：无线是开放介质，持合适射频设备即可收，难发现。

主动六项：

  • 假冒 / Sybil：截获、伪造或篡改合法身份后冒充；Sybil 进一步用多个伪造身份同时出现，破坏投票、路由、信誉。
  • 篡改：删/换部分或全部载荷后再转发给原接收者。
  • 重放 Replay：把合法包存下来，隔一段时间再投递（电表「已缴费」、门锁「已开」）。
  • DoS / DDoS：耗尽目标资源，使其无法向合法节点提供服务。
  • 干扰 Jamming：发干扰射频，破坏无线物理层。
  • 病毒 / 恶意软件：破坏节点或让节点按攻击者指令运行。
▸电表重放 vs 假包

截获「当前读数 120 kWh」上报帧，稍后重放 → 云端时间序列被污染（重放）。自造「读数 80 kWh」并仿合法 MIC/CRC → 计量被改（假冒+篡改）。仅嗅探不上报 → 被动监视用电习惯。

▸图源

ch8.pdf 第 6–7 页。「网络层攻击」。下图按课件结构复绘。

被动 主动
手段 嗅探、扫描、窃听 假冒/Sybil、篡改、重放、DoS 等
觉察 通常不引起察觉 改数据/可用性，易被发现
目标 端口、信道、漏洞情报 完整性、可用性、身份

硬件

四类，针对 MCU / SoC / Flash，不依赖网络协议栈。


故障注入

引入外部扰动使运算出错，再由错误状态反推密钥，常见于攻加密实现。手段：激光打 MCU/无线 SoC；拉低或干扰供电；改时钟频率与触发电平。错误可能让受保护寄存器被「打开」，机密直接读出。


接口植入

量产板常保留调试口（UART / JTAG / I2C）。UART RX/TX 用电平转换接到 PC，SecureCRT / Xshell 设波特率后上电，启动日志与 shell 即可出。JTAG 可停核、读寄存器与 Flash。量产应熔断调试或至少关默认 shell。


逆向

固件 = 只读存在器件里的数据/指令。拆摄像头 PCB → 定位 Flash → 夹具+编程器读出 → 改固件再刷回，设备按攻击者逻辑跑（后门、关日志、改密钥）。


侧信道

（Side Channel Attack，SCA）

加密运算附带声、热、功耗、电磁。SPA（Simple Power Analysis，简单功耗分析）采一条功耗曲线即可推断密钥位，适用于密钥相关跳转且功耗差大的算法（RSA、ECC：模幂平方-乘的分支）。DPA 则对多条曲线做统计。

【此处插入：激光故障注入；UART 接 shell；Flash 夹具读固件；SPA 功耗曲线】

▸图源

ch8.pdf 第 8–11 页。激光故障注入、UART 接 shell、Flash 夹具读固件、SPA 功耗曲线。无法准确复绘。


机制

五块：硬件、软件、无线、认证与传输、隐私。


硬件


熔断

对 MCU/CPU 特定引脚加高电平，电流烧断片内熔丝 → 程序只跑不可读写。仪器进步后暴力破解成本下降，近年逐渐少用，不能当唯一防线。


看门狗

（Watchdog Timer）

电子或软件定时器。正常路径必须定期喂狗（复位计数）；硬件故障或程序卡死导致超时 → 系统复位。防死锁、防部分故障注入后的挂起，不防逻辑被篡改。


PUF

（Physical Unclonable Function，物理不可克隆函数）

晶圆工艺偏差在片内留下不可复制的物理特征，等价于 IC 指纹。相同工艺再流一片，PUF 响应也不同。密钥在每次启动时再生，不落 Flash，抗直接读存储。


RoT

（Root of Trust，信任根）

密码学意义上「始终可信任」的基点。典型实现：HSM（Hardware Security Module，硬件安全模块）；也可落在安全元件 / TEE 的安全世界。上层认证、安全启动、密钥派生都挂在 RoT 上。


TEE

（Trusted Execution Environment，可信执行环境）

ARM TrustZone 把 SoC 软硬件划成安全世界（Secure World）/ 非安全世界（Normal World）。机密运算只在安全世界；其余在普通 OS。中间经 **Monitor 模式（Monitor Mode）**切换。

▸TEE 像「芯片里的保险箱」

普通 App（CA，Client Application）不能直接摸密钥；它只能敲门请保险箱里的 TA（Trusted Application，可信应用）代劳。两边通过共享内存递进递出结果。即便普通系统被攻破，安全世界里的私钥仍难被直接读走（还要防侧信道等，但门槛高很多）。

栈（两侧对称）：硬件 → ARM Trusted Firmware →（普通 OS / 安全 OS：内存、中断、IPC（Inter-Process Communication，进程间通信））→ TEE 标准 API → 普通 App / TA（Trusted App）。CPU 各有用户态与特权态；世界切换必须进 Monitor。

应用流：非安全侧 CA（Client Application）发起 → 调 TA → 切安全世界执行 → 完成后切回 → 结果经共享内存回 CA。

▸CA / TA / PTA

CA 跑在普通世界（如 Linux / Raspberry Pi OS）。TA 跑在 TEE OS（如 OP-TEE）用户态。PTA（Pseudo TA）跑在 TEE 特权侧，常用来挂安全外设驱动（案例里 DHT11）。调用链：CA → TA → PTA，会话都用 UUID 标识。

▸图源

ch8.pdf 第 15 页。「TrustZone / TEE」。下图按课件结构复绘。

1
2
3
普通世界 CA  --Monitor--> 安全世界 TA
完成后切回；经共享内存回传结果
机密放安全世界。

软件


存储与漏洞

设备存储：TEE + 数据加密。云存储：传统 ACL / 授权 / 审计 / 冗余之外，重点转向密文上计算（安全多方计算、隐私计算、加密数据库）。

漏洞：硬件、软件、协议实现或安全策略上的功能/安全逻辑缺陷。挖掘：符号执行等静态 + Fuzzing 等动态。分析：吃透已发现漏洞，为利用或补丁铺路。另有软件混淆与加密。


沙盒

给运行中的程序提供隔离环境。例：软件内存沙盒 Harbor；轻量虚机 WebAssembly。

无沙盒：内核模块与用户模块共享地址空间（0x0000–0x1000 量级示意），用户乱写可毁掉内核态 → 整机崩溃。

有沙盒：空间划成保护域。内核域可读写任意域；用户模块只住一个域且只能写自己的域。细粒度布局带所有权信息。

加固：

机制 作用
安全栈 存函数返回地址与跨域调用帧，防返回地址被改导致跳到恶意代码
栈界限 stack bound 限制被调函数可用栈范围，抑栈溢出
▸图源

ch8.pdf 第 17–18 页。「内存沙盒」。下图按课件结构复绘。

1
2
3
无沙盒: 用户乱写可毁内核
有沙盒: 内核域可写任意；用户域只能写自己
安全栈存返回地址；stack bound 限栈范围

OTA

（Over-the-Air，空中下载）

经无线/蜂窝在线升级，可及时补漏洞；过程本身也是攻击面（假包刷恶意固件、中间人降级）。需求：传输机密性、操作权限、更新完整性 + 回滚。


蜜罐

把感知、执行、网络等资源当诱饵，捕获并分析针对物联网设备的攻击。开源例：Potd。

架构：

模块 职责
重定向器 收 TCP 连接；DDoS 防护、限制并发；转到协议进程
协议进程 实现 SSH/HTTP 等，与攻击者握手；子进程+连接转监视器
监视器 初始化沙盒与伪终端上的 TCP 处理；采威胁数据并自保

诱饵环境 = 重定向器 + 协议进程；监视器负责取证。

▸图源

ch8.pdf 第 20 页。「蜜罐 Potd」。下图按课件结构复绘。

1
攻击者 -> 重定向器 -> 协议进程 -> 监视器（沙盒取证）

无线


蓝牙

内置安全模式 1～4，数字越大越强。以手机 App 连 BLE 设备为例：

  1. App 向 OS 发配对请求。
  2. 设备与手机直接交换配对信息（约定配对方案）。
  3. 认证+加密两步：① 交换公钥 → 生成对称密钥；② 按步骤 2 的方案互认。
  4. 认证通过后由对称密钥派生长期密钥 LTK。
  5. 建立加密通道，此后载荷均由 LTK 加密。

补充：模式 1 无安全；2 服务级（信道建立后）；3 链路级（建立前）；4 为 2.1+ 的安全简单配对（SSP，ECDH），现为默认高档。

▸图源

ch8.pdf 第 21 页。「蓝牙配对」。下图按课件结构复绘。

1
2
App -> OS 配对请求 -> 设备交换配对信息
换公钥得对称钥 -> 按约定方案互认 -> 派生 LTK -> 加密通道

ZigBee

每层都有安全设计。

机制 作用
刷新计数器 入/出 freshness counter；新密钥建立时复位，阻重放
完整性 课件写基于 CRC 防改包；标准 NWK/APS 更常用 AES-CCM MIC，CRC 偏检错
认证 网络层 + 设备层，防仿冒
加密 AES-128；三种密钥

三密钥：

密钥 范围
主密钥 Master 用于派生链接密钥
链接密钥 Link 两设备单播（APS）
网络密钥 Network 全网共享（NWK）

RFID


Hash-Lock

用 metaID = H(key) 代替真实 ID，意图防 ID 明文泄露。其中 $H$ 为哈希函数（Hash Function）：易算、难反推原像。

▸Hash-Lock 弱点一句话

标签先丢出一个「假名」metaID，看起来藏了真 ID；但后面仍把 key 和真 ID 明文在空中传来传去，又没有刷新 → 窃听一次就能重放、假冒、追踪。协议名字有 Hash，不等于整段对话都安全。

流程：Reader Query → Tag 回 metaID → Reader 用 metaID 查 DB 得 (key, ID) → Reader 把 key 明文给 Tag → Tag 校验 key 后把 ID 明文给 Reader → Reader 与 DB 中 ID 比对。

缺陷：无 ID/metaID 刷新；key 与 ID 均走不安全信道明文 → 极易重放、假冒；静态 metaID 可追踪。

▸Hash-Lock 数值

Tag 存 ID=0xA1B2，key=0x55AA，metaID=H(0x55AA)。攻击者一次嗅探即同时得到 key 与 ID：之后可一直回放同一 metaID，或用 key 解锁任意克隆标签；超市货架上 metaID 不变，可跟踪同一件商品。


随机化 Hash-Lock

询问–应答：Tag 生成随机数 (R)，回 (R) 与 (h(R\parallel ID))。Reader 向 DB 取全部 ID，对每个 (ID_i) 算 (h(R\parallel ID_i))，与收到的哈希比对直至命中，再把 (ID_j) 明文发回 Tag 校验。

优点：每次 (R) 不同，抗重放与假冒。缺点：最后一跳 ID 仍明文 → 仍可追踪；Reader 每次 (O(N)) 次哈希，库大时不可扩。

▸图源

ch8.pdf 第 23–24 页。「RFID Hash-Lock」。下图按课件结构复绘。

1
2
Hash-Lock: 查询->metaID->库查 ID+key->下发 key->标签验证（ID 固定，易追踪）
随机化: 标签发 R 与 h(R||ID)；读写器穷举 ID 验证

LoRaWAN

双向认证：每终端唯一 128 bit AES AppKey + EUI-64 DevEUI。由 AppKey 派生两把会话钥：

密钥 用途
NwkSKey 设备 ↔ 网络服务器；包完整性（MIC）
AppSKey 应用层加解密；设备 ↔ 应用服务器隐私

完整性+隐私：载荷加密之外，每帧还有帧计数器（防重放）、MIC、基于 AES 的 CMAC。

补充（v1.0 OTAA，课件未写公式）：Join-request 本身不加密，MIC 用 AppKey 做 AES-CMAC 的前 4 字节。双方知 AppKey 即完成互认。会话钥：

[
\begin{aligned}
\mathrm{NwkSKey}&=\mathrm{aes128_encrypt}(\mathrm{AppKey},;0x01\Vert\mathrm{AppNonce}\Vert\mathrm{NetID}\Vert\mathrm{DevNonce}\Vert\mathrm{pad16})\
\mathrm{AppSKey}&=\mathrm{aes128_encrypt}(\mathrm{AppKey},;0x02\Vert\mathrm{AppNonce}\Vert\mathrm{NetID}\Vert\mathrm{DevNonce}\Vert\mathrm{pad16})
\end{aligned}
]

v1.1 拆成 AppKey+NwkKey，并由 Join Server 持根钥，使网络服务器拿不到 AppSKey。ABP 预置会话钥、不换钥，弱于 OTAA。与第五章 OTAA/ABP、Class A/B/C 对照。

▸图源

ch8.pdf 第 25 页。「LoRaWAN 密钥」。下图按课件结构复绘。

1
2
3
AppKey + DevEUI 认证
会话: NwkSKey（完整性 MIC/CMAC） / AppSKey（载荷加密）
帧计数抗重放

NB-IoT

层 要点
无线 授权频段，干扰与窃听面小于免授权
终端 认证凭证在 SIM，经蜂窝长期考验
认证 3GPP AKA + 传输层安全；随机数与结果长度符合规范
密钥 加密/完整性钥由 HMAC 类 KDF 派生；网络层与传输层钥独立，一层失陷不直接拖垮另一层

认证


口令

注册：用户名 + 口令 + 系统随机 盐 salt（课件误写 solt）→ (\mathrm{Hash}(\text{口令}\Vert\mathrm{salt}))；库中只存散列值 + 盐，不存明文口令。

登录：按用户名取盐与旧散列 → 对提交口令加同一盐再哈希 → 相等则通过。

▸盐的作用

两用户都用口令 iot2024。无盐时库中散列相同，一份彩虹表即可批量撞。加盐 s7xQ / k2Lm 后散列不同；攻击者必须对每个盐重算表。盐须每用户随机且与散列一起存；盐本身不保密，保密的是「口令+盐」的原像。

登录：库中 salt=s7xQ，hash=H("iot2024"||"s7xQ")。提交 iot2024 再算同一式，相等则通过；提交 iot2025 则拒绝。读到盐仍要穷举口令。

▸图源

ch8.pdf 第 27 页。「口令认证」。下图按课件结构复绘。

1
2
注册: 口令 + salt -> Hash 入库（散列与盐分存）
登录: 再算 Hash 比对

设备

三元组（阿里云 IoT）：ProductKey + DeviceName + DeviceSecret，全球唯一。建连时用 DeviceSecret 加签设备信息，平台验签完成登录。与第七章 TinyLink MQTT 例一致：securemode=3,signmethod=hmacsha1，userName=device&pk，password= HMAC。

射频指纹：攻击者可立伪 AP，SSID/BSSID 仿真 AP。用功放非线性指纹 + 帧间时间分布等射频指纹区分真伪 AP。


TLS

前身 SSL。在传输层提供机密性与完整性。HTTP+TLS = HTTPS。独立于应用，HTTP/FTP 等可透明跑在其上（相对早期 SSL 绑定更灵活）。

两层：

层 协议 作用
低 记录协议 为高层提供基本安全服务
高 握手 / 改变密码规范 / 警报 管理 TLS 交换

握手四阶段（可互认并协商 MAC 与密钥）：

阶段 方向 报文
1 建安全能力 C→S client_hello；S→C server_hello 算法套件、随机数
2 服务器凭证 S→C certificate / server_key_exchange / certificate_request / server_hello_done 证书、可选要客户端证
3 客户端凭证 C→S certificate / client_key_exchange / certificate_verify 预主密钥等
4 启用套件 双方 change_cipher_spec + finished 此后用新密钥
▸图源

ch8.pdf 第 29–30 页。「TLS 握手」。下图按课件结构复绘。

1
2
3
4
1 client_hello / server_hello
2 certificate ... server_hello_done
3 client_key_exchange / certificate_verify
4 change_cipher_spec + finished

MQTT

三种角色：发布者、代理（常为服务器）、订阅者。三层安全：

层 措施
应用 ClientId + 密码，识别设备
传输 基于 TLS；单向（仅服务器证书）或双向（双方证书）；端口常见 8883 vs 明文 1883
网络 专线 / VPN

隐私


身份

假名 / 匿名：用户 A 对医院用假名 Alice 开诊断凭证，对保险公司用假名 Amy 交凭证报销。A 不向任何实体出示真实身份；医院无法把 A 与 Alice 关联；保险公司也无法把 Alice 与 Amy 关联（两机构无沟通）。关键是不可关联性，不是单点匿名。


位置

假位置：用户向 LBS 一次提交多个位置，其中仅一个真，其余假。服务端对每个位置给反馈（用户仍能用真位置结果），攻击者不知哪个是真。

▸图源

ch8.pdf 第 32–33 页。「身份/位置隐私」。下图按课件结构复绘。

1
2
医院见 Alice；保险见 Amy；两假名不可关联
LBS: 一次交 1 真 + k-1 假位置

框架


AWS

云侧：身份验证 + IAM 角色/策略。未通过认证则永不在设备与云之间交换数据。证书可映射角色/策略，授权或撤销设备/应用访问。

三种身份：

身份 典型客户端
X.509 证书 IoT 设备（IoT policy）
IAM 用户/组/角色 Web / 桌面 / 联合身份
Amazon Cognito 移动 App（认证提供方 token + IAM + IoT policy）

后端常接 Lambda、DynamoDB、Kinesis。与第六章 AWS 影子/规则/Greengrass 同一套认证门闸。

▸图源

ch8.pdf 第 35 页。「AWS IoT 认证」。下图按课件结构复绘。

1
2
设备 X.509  |  Web/桌面 IAM  |  移动 Cognito
未认证则设备与云之间永不交换数据

（IoT Device ID）

可信计算 + 密码学，为设备提供认证、安全连接、业务数据加密等端到端可信接入。

功能 要点
设备身份 每设备唯一 ID；双向认证，防篡改/仿冒
安全连接 兼容 TLS/DTLS 的轻量 iTLS / iDTLS（用 ID2 代替 X.509，握手流量可降约 70%）
业务数据 由设备可信根派生钥，护固件、业务数据、应用授权
密钥管理 生成、销毁、端到端安全分发

认证两种：挑战–应答 与 时间戳。挑战–应答三方：设备、业务服务端（厂商）、阿里云 ID² 认证服务端。

  1. 设备经业务端向 ID² 申请认证。
  2. ID² 回挑战随机数。
  3. 设备算认证码（可选额外参数）。
  4. 设备把认证码交业务端。
  5. 业务端把（认证码, 额外参数）问询 ID²。
  6. 成功后业务处理，结果回设备。

随机数一次性，抗重放；时间戳模式则靠时钟窗口。

▸图源

ch8.pdf 第 37 页。「Link ID² 挑战–应答」。下图按课件结构复绘。

1
2
3
设备 -> 业务端 -> ID2 申请
ID2 回挑战随机数 -> 设备算认证码 -> 业务端代验 -> 回结果
随机数一次性抗重放

函谷 HISK

百度，基于 GlobalPlatform。覆盖设备、边缘、云、移动 App 及链路。两档：① 基础服务——证书/密钥保护，唯一身份、认证、敏感数据传输；② PKI 证书服务——为设备签发数字证书，建 TLS 双向认证。


案例

目标：温度监控可信应用。节点在 TEE 中用 DHT11 采样，RSA 非对称加密后经 MQTT+TLS 上传；云侧在 TEE 中解密并打印。

项 选型
节点 树莓派 3B（BCM2837，4×A53 @1.2 GHz，1 GB RAM，40-pin GPIO）
云侧 PC / 笔记本
OS Raspberry Pi OS + OP-TEE 3.12.0
传感 DHT11，课件 GPIO 18
传输 mosquitto_pub，192.168.31.160:8883，双向证书
▸图源

ch8.pdf 第 40–41 页。第 41 页 Pi 3B 接口为原图；总体数据路径如下。

1
CA -- TEE 会话--> TA --PTA DHT11--> 加密 --> MQTT 8883 TLS --> 云 CA/TA 解密打印

环境

1
2
3
mkdir -p <optee-project> && cd <optee-project>
repo init -u https://github.com/OP-TEE/manifest.git -m rpi3.xml -b 3.12.0
repo sync -j4 --no-clone-bundle

文档：https://optee.readthedocs.io/en/latest/building/index.html


节点 CA

deviceCA_main.c：循环 Data_ReadandEncrypt() → Data_Send() → sleep(3)。

Data_ReadandEncrypt 调 TA 五步（GlobalPlatform TEE Client API）：

  1. TEEC_InitializeContext
  2. TEEC_OpenSession（TEEC_UUID = SECURE_LAB_UUID_ID）
  3. 准备 TEEC_Operation：最多 4 个参数。此处仅 params[0] = TEEC_MEMREF_TEMP_OUTPUT（TA→CA 共享内存），其余 TEEC_NONE；buffer=rsa_encryptData，size=rsa_encryptLen
  4. TEEC_InvokeCommand(..., CMD_RSA_ENC_PKCS1_OPER, ...)
  5. TEEC_CloseSession + TEEC_FinalizeContext

Data_Send：拼 mosquitto_pub -h ... -p 8883 -t data --cafile ca.crt --cert clientpub.crt --key clientpub.key -m "0x.., "，把密文字节以 hex 发出。8883 + 双向证书 = MQTT 传输层安全。


节点 TA / PTA

TA dht11_read_data：

  1. TEE_OpenTASession 打开 DHT11 PTA（PTA_RPI3DHT11_UUID）
  2. TEE_InvokeTACommand(..., DHT11_READ_DATA)；TEE_PARAM_TYPE_VALUE_OUTPUT ×2
  3. 课件取 pta_params[1].value.a/b 为温度整数/小数（PTA 侧见下）
  4. SetRsaPublicKey + RsaEncOper 后关闭 PTA 会话

公钥句柄：TEE_ATTR_RSA_MODULUS（N）+ TEE_ATTR_RSA_PUBLIC_EXPONENT（E）→ TEE_AllocateTransientObject(TEE_TYPE_RSA_PUBLIC_KEY) → TEE_PopulateTransientObject。

加密：TEE_AllocateOperation(TEE_ALG_RSAES_PKCS1_V1_5, TEE_MODE_ENCRYPT) → TEE_SetOperationKey → TEE_AsymmetricEncrypt。该 API 由 GlobalPlatform 定义，不同 TEE OS 接口一致。

PTA pta_Rpi3DHT11.c：按 DHT11 时序 bit-bang GPIO 18。

启动（单总线）：

1
OUT → 1 → udelay(4) → 0 → mdelay(25) → 1 → udelay(60) → IN

datasheet 要求主机拉低 ≥18 ms（课件 25 ms 满足），再拉高 20–40 μs 等从机响应；其后 40 bit：0 ≈ 50 μs 低+26–28 μs 高，1 ≈ 50 μs 低+70 μs 高。

40 bit 布局（标准，含校验）：

字节 含义
0 湿度整数
1 湿度小数
2 温度整数
3 温度小数
4 校验 = (0+1+2+3) mod 256

若 databuf 只装前 4 字节，则 (databuf>>24)&0xff 为湿度整数，(databuf>>8)&0xff 为温度整数。课件 PTA 注释把 >>24 写成「温度整数」，与 datasheet 不符，复习时以 datasheet 为准；printf("TMP:%d.%d", (databuf>>8)&0xff, databuf&0xff) 才是温度。

▸DHT11 拆字节

湿度 50.0%、温度 26.0℃ → 五字节 0x32 0x00 0x1A 0x00 0x4C（(0x32+0x00+0x1A+0x00=0x4C)）。32-bit databuf=0x32001A00：>>24=0x32=50（湿），>>8=0x1A=26（温）。

▸图源

ch8.pdf 第 43–49 页。代码截图保留对照；调用链如下。

1
2
CA: TEEC_InitializeContext/OpenSession/InvokeCommand
TA 调 PTA 读 DHT11 单总线；RSA 设公钥属性后加密

云侧

订阅 CA mqtt_sub：MQTTClient_create → 设回调 msgarrvd → SSL：trustStore=ca.crt，privateKey=clientsub.key，keyStore=clientsub.crt → MQTTClient_connect → 订主题。

msgarrvd → Data_Decrypt：打开解密 TA；params[0] MEMREF_INPUT（密文）、params[1] MEMREF_OUTPUT（明文）；CMD_RSA_DEC_PKCS1_OPER。

云 TA rsa_decrypt：先校验 param_types，否则 TEE_ERROR_BAD_PARAMETERS；SetRsaPrivateKey + RsaDecOper（TEE_MODE_DECRYPT + 私钥句柄）。公钥在节点 TA，私钥只在云 TA，普通世界 CA 只见密文。


编译烧录

1
2
3
4
cd <optee-project>/build && make -j2 toolchains && make -j4
mkfs.ext4 -L rootfs /dev/sdx2
mount /dev/sdx2 /media/rootfs
cd /media/rootfs && gunzip -cd .../rootfs.cpio.gz | sudo cpio -idmv

测试：网络与 DHT11 GPIO 正确时，云终端打印解密温度；Pi 侧 UART 看 OP-TEE 日志。

【此处插入：mosquitto 8883 双向证书；云 TA 解密打印；UART log】

▸图源

ch8.pdf 第 50–53 页。mosquitto 8883 双向证书、云 TA 解密打印、UART log。无法准确复绘。


前沿


dTEE

dTEE: A Declarative Approach to Secure IoT Applications Using TrustZone（IPSN’24，Sun/Li/Teng/Gao/Dong）。手写 TEE 须拆 CA+TA，外设进安全世界更难。dTEE 用声明式 D-lang：对已有 C 源声明敏感变量/函数（如 TZ_DATA_CONF gpsData，TZ_sign_rsa_sha1），静态分析出 PDG，按 dCFG 划分，源到源生成 CA+TA，并把驱动自动改成可信驱动。相对手写约减 90% LoC；比仅自动划分的方案多覆盖约 50% 应用；运行时开销 <6.6%。课件对比 WaTZ：整体 1050 ms vs 2160 ms，内存约 2.89 MB vs 12.10 MB；dCFG 优化把世界切换从 460 ms 降到 293 ms。

【此处插入：D-lang 声明 vs 原 C；dTEE 四段流水；与 WaTZ 表】

▸图源

ch8.pdf 第 55 页。dTEE（IPSN’24）：D-lang 声明、四段流水、与 WaTZ 对照表。无法准确复绘。


Wasm

课件并列两线：① WAIT（MobiSys’22，Bring WebAssembly to Resource-constrained IoT Devices）——云端编成 Wasm 模块，设备上 WAIT Runtime（AOT、二进制优化、编译期/运行期检查、端云 Agent），外设经 WAIT_readDigital 等 API；相对当时 AOT 运行时可降 RAM 约 84.8×，并保证沙盒。② WaTZ / MyTEE（课件写 MiTEE）：Wasm 跑进 TrustZone，补 TrustZone 缺省没有的远程证明；MyTEE（NDSS’23）则让嵌入式设备「拥有」自己的 TEE。Wasm 沙盒 + TEE 隔离 = 纵深。

▸图源

ch8.pdf 第 56 页。「WAIT / Wasm」。下图按课件结构复绘。

1
多语言源 -> 云端 Wasm -> 设备 WAIT Runtime（AOT+检查）-> WAIT_readDigital 等 API

Matter

2019 CHIP（Connected Home over IP，Google/Apple/ZigBee Alliance）→ 2021-05 更名 Matter，联盟更名 CSA（Connectivity Standards Alliance；课件拼写 connectity）→ 2022-10 发布 Matter 1.0。

去中心化设备接入与全生命周期安全：入网 commissioning 时，Commissioner 从 DCL（Distributed Compliance Ledger）拉取 PAA 根，校验设备 DAC 证书链，证明「这是经认证的合法型号」，不依赖单一厂商云做身份权威。相对 AWS/阿里「云发三元组/证书」的中心模式，Matter 把「谁有资格连我家」放到跨厂共享账本 + 本地 commissioning。协议栈与拓扑（单一网 vs 星形+BR）见第一章挑战、第四章 Matter 节。

▸图源

ch8.pdf 第 57 页。「CHIP → Matter」。下图按课件结构复绘。

1
2
3
2019 CHIP  ->  2021-05 Matter，联盟更名 CSA  ->  2022-10 Matter 1.0
commissioning: Commissioner 从 DCL 拉 PAA 根，校 DAC 链
不依赖单一厂商云做身份权威

复习

主题 必记
攻击面 被动：嗅探/扫描/窃听；主动：Sybil/篡改/重放/DoS/干扰/恶意软件
硬件攻 故障注入、UART/JTAG、固件逆向、SPA（RSA/ECC）
硬件防 熔断、看门狗、PUF（启动再生）、RoT/HSM、TrustZone CA/TA/Monitor
沙盒 分域；内核可写任意域；安全栈+stack bound；Harbor / Wasm
OTA 传输机密、权限、完整性+回滚
蜜罐 Potd：重定向器+协议进程+监视器
BLE 模式 1–4；公钥→对称钥→LTK
ZigBee freshness 计数；AES-128；Master/Link/Network
Hash-Lock metaID=H(key)；key/ID 明文；重放+假冒+追踪
随机 Hash-Lock (h(R\parallel ID))；抗重放；ID 仍明文；(O(N))
LoRaWAN AppKey+DevEUI；NwkSKey 完整性 / AppSKey 机密；FCnt+MIC+CMAC
NB-IoT 授权频段+SIM+3GPP AKA；NAS/AS 钥独立
口令 (\mathrm{Hash}(pw\Vert\mathrm{salt}))；盐随机不保密
三元组 PK+DN+DS；DS HMAC 加签
TLS 记录+握手；四阶段 hello→证书→密钥→CCS/finished
MQTT 安全 应用口令 / 传输 TLS(8883) 单向或双向 / 网络 VPN
隐私 假名不可关联；假位置混淆
AWS 未认证不交换数据；设备 X.509 / Web IAM / App Cognito
ID² iTLS；挑战–应答 vs 时间戳；设备–业务–ID² 三方
案例 OP-TEE；CA→TA→PTA(DHT11)；RSA PKCS1；MQTT 8883；私钥只在云 TA
DHT11 40 bit；校验=和 mod 256；课件 >>24 注释与 datasheet 湿/温易混
前沿 dTEE 声明式分区；WAIT Wasm AOT；Matter/CSA 1.0 去中心认证