文章目录

一、SIG Mesh Models Layer
- 1.1 MESH Model communication
- 1.2 MESH State transition
- 1.3 Overview of SIG Mesh Models
- - 1.3.1 Generic Models
  - 1.3.2 Sensor Models
  - 1.3.3 Time and Scene Models
  - 1.3.4 Lighting Models
二、Foundation Model Layer
- 2.1 Configuration Client / Server model
- 2.2 Health Client / Server model
三、Transport Access messages
- 3.1 Upper Transport Layer
- 3.2 Lower Transport Layer
更多文章：

前篇博文BLE MESH 各层报文是如何设计的介绍了BLE MESH Advertising Bearer 和GATT Bearer 、Network Layer、Transport Layer 报文格式分别是如何设计或定义的？这些报文各字段如何实现MESH 各协议层设计的功能？比如如何实现MESH Provisioning Process、Key Refresh procedures、IV Update procedure、Network addressing process、Encrypted/Obfuscated process、Segmentation and reassembly process 等？本文主要介绍SIG 设计或定义了哪些MESH Models？一个Model 通常定义了哪些 states、messages、behavior / procedure？MESH client model 与MESH server model 之间传输的messages 如何由Access Layer 承载、Transport Layer 加解密认证和分段重组的？

一、SIG Mesh Models Layer

博文BLE MESH 如何定义并传递消息已经简单介绍了State、Message、Model 的定义以及它们之间的关系。简单来说，一个BLE MESH 设备经过Provisioning Process 入网后就成为一个MESH Node，一个Node 设备可能包含多个独立的子设备Elements（每个元素一个单播地址，作为寻址的依据），每个Element 可能包含多个Models（每个模型定义元素的一个基本功能）。

1.1 MESH Model communication

MESH Model 采用Client – Server 架构通信，Server Model 定义了一组 States、作用于这些状态的Messages、响应这些消息的Behaviors 等，Client Model 则通过作用于状态的Messages 获取或者更改特定的State value。Client Model 通过特定的Messages 访问或更改Server Model 定义的特定State 的过程如下：

Client Model 向Server Model 发送的Messages 主要有两种：一种是查询Server Model 上特定的State 信息；另一种是设置Server Model 上特定的State 信息。Server Model 向Client Model 发送的Messages 主要也有两种：一种是用Present State 响应来自Client Model 的查询消息；另一种是按照预设条件（比如当前状态发生改变时，或周期性时间间隔耗尽时）向该模型订阅者发送Present State 消息。

从上图可以看出，Client Model 向Server Model 发送的消息主要有Get message 和Set message 两种。Server Model 向其它节点发送的消息都是 Status message，一种是用来响应Client Model 的，另一种是在状态发生改变或者周期性定时间隔超时时发送给该模型订阅组的（上图省略了周期性发布消息图示）。假如Client Model 也是Server Model Publish Group 中的一员，Client Model 向Server Model 发送Set message 后将收到至少两个同样的 Status message，为了降低对MESH 网络资源的占用，Set message 定义为Acknowledged set 和Unacknowledged set 两种。

Client Model 与Server Model 之间交互的 messages 主要是用来传递Present State 信息或Target State 信息的。State 可能就是一个数值（比如开关状态可以用一个布尔值表示，亮度或速度状态可以用一个整数表示等），也可能是由多个数值组合成的Composite state（比如彩色灯光状态可以由色调、饱和度、亮度三种状态组合而成），多个State 之间也可能定义了略复杂的绑定关系（Bound state 表示绑定关系中的一个状态发生变化，可能会引起另一个状态的联动变化）。

与GATT Profiles / Services 类似，SIG 也提供了一些标准的SIG Model，比如Configuration Server/ Client model、Health Server / Client model 等Foundation models，比如Generic OnOff Server / Client model、Generic Level Server / Client model、Sensor Server / Client models 等SIG models。每个Model 都有一个唯一的Model ID（每个SIG Model ID 都由 2 个字节唯一标识，限于篇幅只列出部分作为示例）：

SIG Model ID	Model Name
0x0000 0x0001	Configuration Server Configuration Client
0x0002 0x0003	Health Server Health Client
0x1000 0x1001	Generic OnOff Server Generic OnOff Client
0x1002 0x1003	Generic Level Server Generic Level Client
…	…
0x1100 0x1101 0x1102	Sensor Server Sensor Setup Server Sensor Client
…	…

考虑到现实应用场景中，可能有很多功能超出了SIG 定义的标准模型的范畴，SIG 也允许Vendor 在SIG Models 无法满足需求的情况下自己定制Vendor Models。Vendor Model ID 使用两个字段32 位标识（由Company ID 和vendor-assigned model ID 构成）：

Client Model 与Server Model 之间交互的 messages 主要由Opcode 和Parameters 两部分构成，每个消息都有一个唯一的Opcode（不同model 的message opcode 都不同，可仅通过opcode 知道该message 属于哪个model）。与Model 类似，Message 也分为SIG Message 和Vendor Message，SIG Message 使用 1 字节或 2 字节的Opcode，Vendor Message 使用 3 字节的Opcode（后两个字节是Company ID，也即下图中的“zzzzzzzz”）。

SIG 可使用的Opcode 一共有 2⁷ - 1 + 2¹⁴ = 16511 个，足够使用了。每个Company ID 可供使用的Opcode 只有 2⁶ = 64 个，如果不够用还需要再申请Company ID。

下面给出几个SIG Message Opcode 作为示例：

Opcode	Message Name
0x00 0x80 0x00 0x80 0x01 0x80 0x02 0x80 0x03 0x01	Config AppKey Add Config AppKey Delete Config AppKey Get Config AppKey List Config AppKey Status Config AppKey Update
…	…
0x80 0x3D 0x80 0x3E 0x80 0x3F	Config Model App Bind Config Model App Status Config Model App Unbind
…	…
0x82 0x01 0x82 0x02 0x82 0x03 0x82 0x04	Generic OnOff Get Generic OnOff Set Generic OnOff Set Unacknowledged Generic OnOff Status
…	…

MESH Message 中的Parameters 跟具体模型的具体状态相关，由于Message 是作用于State 的，想了解某个Message 的Parameters 需要先了解其查询或设置的具体State。

1.2 MESH State transition

以比较简单的Generic OnOff state 为例，使用布尔值就可以描述状态信息，比如0x00 表示Generic Off state、0x01 表示Generic On state。Generic Level state 则使用 16 位有符号整数值就可以描述状态信息，比如0x0010 可以表示电机转速或灯光亮度为16。State 表示相对简单，如何表示State 变更或转换过程呢？

Generic Level state 状态的变化不可能瞬时发生，从Initial State 到Target State 一般需要一个转换时间 transition time，SIG 定义的state transition 过程如下：

Server Model 收到来自Client Model 的Set message 后，会延迟一段时间Delay time（比如多个LED 灯可通过设置不同延迟时间实现顺序点亮效果）后才开始状态转换，从Initial State 转换到Target State 需要的时间称为Transition Time，状态转换过程中的状态为Present State，从Present State 转换到Target State 需要的时间称为 Remaining Time。

前面也谈到，MESH Message 是作用于State 的，以Generic OnOff messages 为例，Generic OnOff Set 的Opcode 是0x82 0x02，Parameters 如下：

State value Filed 是OnOff，占用 1 个字节，有些状态值占用更多字节，比如 Level 占用两个字节。

TID Filed (Transaction Identifier) 用来标识该消息是一个新的消息还是旧的重传消息，为了保证Set Message 能正确送达，Client Model 通常在一定时间内未收到响应消息会重新发送该消息，Server Model 通过TID 字段来区分收到的消息是否是重发的，对于重发的消息不重复响应。

Transition Time 和Delay 都是步进的（而且是可选的），Delay 以 5 ms 为单位，最长延时为 (2⁸ - 1) * 5 = 1275 ms。Transition Time 由 2 位的 Transition Step Resolution 字段和 6 位的Transition Number of Steps 字段构成，Transition Time 是二者的乘积，最长转换时间为 620 minutes（Step Resolution 选择 10 minutes）：

Transition Time Field	Size (bits)	Value	Description
Transition Number of Steps	6	0x00 0x01–0x3E 0x3F	Transition Time is immediate. The number of steps. The value is unknown.
Transition Step Resolution	2	0b00 0b01 0b10 0b11	Step Resolution is 100 ms. Step Resolution is 1 second. Step Resolution is 10 seconds. Step Resolution is 10 minutes.

Server Model 对Generic OnOff Set message 的响应Generic OnOff Status message 的Opcode 为0x82 0x04，Parameters 如下：

Server Model 会向Client Model 或Publish Group 发送Generic OnOff Status message，包含Present State、Target State、Remaining Time 三个字段的信息。如果状态转换是瞬时的，Present State 也即Target State，后两个字段就不需要了。

1.3 Overview of SIG Mesh Models

目前SIG 定义了如下standard mesh models：

1.3.1 Generic Models

SIG MESH Generic Models 提供了一组通用的、普遍适用的功能，有 22 个Generic Models 和 8 个Generic States：

Generic OnOff Client / Server Models：使一个设备可以打开或关闭其它设备，包含 Generic OnOff State（布尔值0x00 / 0x01）。OnOff Client 可以向OnOff Server 发送 Generic OnOff Get / Set (Unacknowledged) Message 查询或设置OnOff State，OnOff Server 处理接收到的消息并响应Generic OnOff Status Message；
Generic Default Transition Time Client / Server Models：决定了从当前状态转换到新状态需要的时间（可以是瞬时的或渐进的），包含Generic Default Transition Time State（由Default Transition Number of Steps 和Default Transition Step Resolution 两个字段构成，上文介绍过了）。Generic Default Transition Time Get / Set (Unacknowledged) / Status Message 作用同上；
Generic Level Client / Server Models：允许对其它设备的Level 进行调控，比如灯光的亮暗、房间的温度等，包含Generic Level State（16-bit signed integer，补码表示）。Generic Level Messages 提供了三种更改Generic Level State 的方法，分别是通过Generic Level Set (Unacknowledged) Message 将状态更改为绝对值、通过Generic Delta Set (Unacknowledged) Message 将状态在此基础上叠加一个相对值（可以是正值或负值）、通过Generic Move Set (Unacknowledged) Message 以给定的速度正向或负向更改当前的状态值（转换速度配合Transition Time可知目标状态值），Generic Level Get / Status Message 作用同上；
Generic Power OnOff Client / Server / Setup Server Models：可以配置一个设备在上电后当即所处的初始状态，比如配置设备上电后处于On State，包含Generic OnPowerUp State（0x00 – 表示设备上电后处于Off State，0x01 – 表示设备上电后处于On State 并使用 default state values，0x02 – 表示设备上电后恢复到断电前的状态或继续进行断电前的状态转换）。Generic Power OnOff Server 扩展了Generic OnOff Server Model（OnPowerUp State 与OnOff State 相关），Generic Power OnOff Setup Server 则是扩展了Generic Power OnOff Server model 和Generic Default Transition Time Server model（当OnPowerUp State 值为 0x02 且断电前正在进行状态转换，则上电后需要继续进行状态转换，因此跟Generic Default Transition Time Server 相关）；
Generic Power Level Client / Server / Setup Server Models：允许对其它设备的功率进行调控，比如一个智能插座的输出功率，Generic Power Level state 是一个复合状态（包含Generic Power Actual state – 设备元素的实际功率等级，Generic Power Last state – 设备元素存储记录的上一个非零功率等级，Generic Power Default state – 设备元素默认的功率等级，Generic Power Range state – 设备元素可以输出的最大和最小功率等级等四个状态，均使用 32 位无符号整数表示，State value 除以65535 可知相对最大功率的百分比）。Generic Power Level state 通常与Generic Level state、Generic OnOff state、Generic OnPowerUp state、Generic Power Range state 等状态绑定，Generic Power Level Server 扩展了Generic Power OnOff Server 和Generic Level Server model，Generic Power Level Setup Server 则是扩展了Generic Power Level Server 和Generic Power OnOff Setup model；
Generic Battery Client / Server Models：允许监测一个设备电池的使用状态，比如充放电时间、电量、是否可拆卸等状态信息，Generic Battery state 也是一个复合状态（包含Generic Battery Level – 电池电量，Generic Battery Time to Discharge – 放电过程剩余时间，Generic Battery Time to Charge – 充电过程剩余时间，Generic Battery Flags – 是否可拆卸 / 低电量 / 正充电 / 需维修等四个状态）。Battery Client 可以向Battery Server 发送Generic Battery Get message 查询电池状态，Battery Server 处理接收到的消息并响应Generic Battery Status Message；
Generic Location Client / Server / Setup Server Models：可以查询其它设备元素的位置信息（比如经纬度、海拔、楼层等），Generic Location state 由一系列字段构成（Global Coordinates – Latitude / Longitude / Altitude 以米为单位，Local Coordinates – North / East / Altitude 以分米为单位，Floor number – 楼层编号，Uncertainty – 指示该节点为固定位置或自上次位置更新以来移动的时间等字段）。Generic Location Server 是一个只读模型，可以接收处理Generic Location Global / Local Get message 并响应Generic Location Global / Local Status message，Generic Location Setup Server 则可以接收处理Generic Location Global / Local Set (Unacknowledged) message；
Generic Property Client / Server Models：提供了一种无需更改模型就可以广泛适用不同data values 和 types 的通用数据存储和通信机制，Property 允许将同一模型用于多种数据类型，比如任何类型的传感器数据都可以使用一组属性描述或解释传感器的类型和数值格式。Generic Property states 按照访问权限可以分为Generic User Properties、Generic Admin Properties、Generic Manufacturer Properties 三种（每一种都包含Property ID、User Access、Property Value 三个字段），每个属性都由Property ID 标识。Generic User / Admin / Manufacturer Property Server 分别接收处理对应的Property Get / Set (Unacknowledged) message 并响应相应的Status message，Generic Client Property Server 则允许应用程序（比如provisioning or configuration application）找到能够使用或处理特定属性的客户端（比如可以显示特定温度属性用户界面的设备）。

1.3.2 Sensor Models

传感器是物联网设备的一大类，许多自动化场景中执行设备的触发都需要传感器采集的信号，比如根据环境光传感器报告的环境光信息动态调整房间内灯光的亮度。

SIG 为传感器定义了一组Sensor Models，这组模型为BLE MESH 网络中的传感器操作提供了一种通用方法，并允许任何类型的传感器将Sensor data 传送到MESH 网络中的其它节点。

Sensor Models 为了让同一模型适用任何类型的传感器，为Sensor state 定义了大量的Property，这些属性描述或解释了传感器的类型和数据格式等信息。

Sensor state 是一个很复杂的复合状态，主要包含Sensor Descriptor state – 描述传感器数据的属性（比如正负公差、采样函数、测量周期、更新间隔等）、Sensor Setting state – 控制传感器的配置参数（比如访问权限、原始设置等）、Sensor Cadence state – 控制传感器的发布节奏 / 频率（比如快节奏周期除数、状态触发类型及增量、状态最小间隔、快节奏的高低限值等）、Sensor Data state – 传感器的原始采样数据（可以是单个传感器测量值或组织成数组的Sensor Series Column）等。

Sensor server models 可以接收处理Sensor Descriptor / Date Get message 并响应Sensor Descriptor / Date Status message，Sensor Setup Server 则可以接收处理Sensor Settings / Cadence Set (Unacknowledged) message 并响应Sensor Settings / Cadence Status message。

1.3.3 Time and Scene Models

Time Client / Server / Setup Server Models

很多智能设备都有定时或预约功能，比如设定日落时间开灯、设定早上六点播放唤醒音乐等。SIG 为了让BLE MESH 设备具有时间概念，就定义了Time state 和Time Models。

我们常见的时间是用年月日时分秒等结构表示了，计算机为了处理方便通常使用从某个时间起点以来的秒数来表示当前时间。比如Linux 系统使用从UTC (Universal Coordinated Time) 起点1970-01-01 00:00:00 之后的秒数来表示时间（也即POSIX 时间戳）。UTC 时间虽然基于International Atomic Time (TAI)，但需要引入不规则的闰秒来抵消地球自转变慢的影响，何时插入闰秒是不可预测的，需要通过网络从国家授时中心获取。

SIG 为了简化时间的表示，使用 International Atomic Time (TAI) 表示BLE MESH 的时间，TAI 时间每分每秒都有很高的稳定性和连续性（也即间隔一致、没有闰秒或跳秒），SIG BLE MESH 使用从TAI 起点2000-01-01 00:00:00 之后的秒数来表示时间（时间精度为 1/256 秒）。

为了允许MESH 设备参考UTC 或 local 时间，Time state 除了包含TAI Seconds 和Subsecond 字段外，还包含TAI-UTC Delta（TAI 和UTC 之间的秒数差，方便将TAI 时间转换为UTC 时间）和 local time zone offset（本地时区偏移量，以15 分钟为单位，方便将UTC 时间转换为Local 时间）字段。Time state 包含的时间信息，可以方便的转换为我们熟悉的年月日时分秒形式。

为了方便时间信息在多个BLE MESH 设备间传输或同步，SIG 还定义了Time Role states，Time Role 定义了一个元素是否参与或如何参与MESH 网络中Time state 的传播？

Mesh Time Authority Role 只能生产发布Time Status messages，Mesh Time Relay Role 可以中继Time Status messages，Mesh Time Client Role 只能接收消费Time Status messages。

Time Server Model 可以接收处理Time Get message 并响应Time Status message，Time Setup Server model 则可以接收处理Time (Role) Set message 并响应 Time (Role) Status message。

Scene Client / Server / Setup Server Models

Scene 实际上是MESH 网络中一个或多个设备上存储的State 或状态组合，Scene 调度则是从多个设备上存储的一组状态切换到另一组状态的过程。比如当一个人走进房间后，灯光打开、空调打开、电视打开等一系列设备的执行，这多个设备处于打开状态的集合就可以看作一个Scene，人离开房间后上述设备都转换到关闭状态，这些设备处于关闭状态的集合可以看作另一个Scene。

SIG MESH 设备元素中每个Scene 都由一个 16 位的Scene Number 唯一标识（SIG MESH 最多可定义2¹⁶ - 1 个场景），每个Scene Number 都对应一个 state container，包含与该场景相关的所有状态及其值的集合。MESH 网络中具有相同Scene Number 的所有节点元素共同构成一个唯一的Scene，当MESH 网络场景切换时具有相同Scene Number 的所有元素内同时进行该场景下所有状态的转换。

上例中当人体感应器感应到有人进入房间后，切换到 Scene Standby13 打开灯光、将亮度设置为最高亮度、灯光颜色设置为蓝色等；当感应到人离开房间后，切换到Scene 10 关闭灯光，上述状态切换是同时进行的。

Scenes state 是一个复合状态，包含Scene Register state（由一系列Scene Number 组成的数组，单个元素可以存储最多 16 个不同的场景及其状态集合）、Current Scene state（当前活动场景的Scene Number）、Target Scene state（正在进行场景转换的目标场景编号）这三种状态。

Scene Client model 可以通过Scene Get / Store / Delete / Recall Messages 查询、存储、删除、调用场景状态，Scene Server 接收处理Scene (Register) Get 或Scene Recall (Unacknowledged) Messages 并响应Scene (Register) Status Messages，Scene Setup Server 接收处理Scene Store / Delete (Unacknowledged) Messages。

Scheduler Client / Server / Setup Server Models

场景切换或者调度通常是需要特定条件触发的，可以是设定的某个时间点或者发送的某个消息等，比如早上七点自动煮咖啡、设定人体感应器感应到人进屋后开灯等。

Scheduler (Setup) Server Models 包含Schedule Register state（单个元素最多可以存储 16 组调度数据或状态），该状态除了包含年月日时分秒等时间信息外，还包含Action（0x0 – Turn Off，0x1 – Turn On，0x2 – Scene Recall）、Scene Number 等字段。

Scheduler Client Model 可以通过Scheduler (Action) Get 或Scheduler Action Set (Unacknowledged) Messages 查询或设置调度器状态或行为，Scheduler Server 接收处理Scheduler (Action) Get Message 并响应Scheduler (Action) Status Message，Scheduler Setup Server 接收处理Scheduler Action Set (Unacknowledged) Message。

1.3.4 Lighting Models

可以使用前面介绍的Generic OnOff Models 和Generic Level Models 来控制灯光亮度，但人眼对灯光的感知方式更复杂，如果使用Generic Level Models 线性控制灯光亮度，人眼感知到的灯光亮度变化则是非线性的，因此SIG 为商业照明专门提供了一组模型。

BLE MESH 在商业照明领域比较流行，商业照明对灯光的控制要求比较高，比如控制灯的亮度、色温、颜色等，包含 16 个Lighting Client / Server Models 和 2 个Lighting Control Models。

Light Lightness Client / Server / Setup Server Models

Light Lightness state 是一个复合状态（跟Generic Power Level state 有点类似），包括Light Lightness Linear state（测得的光照强度作为灯光亮度的线性标度，16位无符号整数值表示）、Light Lightness Actual state（由Light Lightness Linear value 计算而来且处于Light Lightness Range Min / Max value 范围内）、Light Lightness Last state、Light Lightness Default state、Light Lightness Range state等。Light Lightness state 通常与Generic OnOff state、Generic Level state、Generic OnPowerUp state 等状态绑定。

Light Lightness Server Model 扩展了Generic Power OnOff Server 和Generic Level Server，Light Lightness Setup Server 则扩展了Light Lightness Server 和Generic Power OnOff Setup Server。

Light CTL Client / Server / Setup Server Models

我们通常使用的LED 灯除了可以调整亮度外，有些还可以调整色温，比如冷色光或暖色光。光源的色温是人眼对光源颜色的感知，与物体辐射的光的温度有关，色温较低的光源我们描述为暖色，色温较高的光源我们描述为冷色。色温还能影响人的情绪，比如暖色可以让我们更放松，冷色可以让我们更专注。

照明中色温可调的灯光我们称为Color-Tunable Light (CTL)，它允许通过color temperature 和lightness 两个维度来控制。其中color temperature 又可以使用CIE u’-v’ diagram 中correlated color temperature 和Delta UV 两个变量表示一个色温点。

Light CTL state 也是一个复合状态，除了包含Light CTL Temperature state（16 位无符号整数值表示，开尔文白光的色温范围0x0320–0x4E20）、Light CTL Temperature Default state、Light CTL Temperature Range state、Light CTL Lightness state（等于Light Lightness Actual state）外，还包含Light CTL Delta UV state（16 位有符号值表示，0x0000 表示可调白光，正值偏暖、负值偏冷）、Light CTL Delta UV Default state 等状态。Light CTL state 通常与Generic Level state、Generic OnPowerUp state、Light Lightness Actual state 等状态绑定。

Light CTL Server Model 扩展了Light Lightness Server，Light CTL Setup Server 则扩展了Light CTL Server 和Light Lightness Setup Server。如果对灯光色温控制要求不是很高，SIG 还提供了比较简单的Light CTL Temperature Server model，该模型仅扩展了Generic Level Server。

Light HSL Client / Server / Setup Server Models

商业照明灯具除了可调色温的CTL 灯光外，还有变色灯，它通常需要三个维度来控制。比如 HSL 灯光模型就是由Hue、Saturation、Lightness 这三个维度控制的，CIE1931 Color Space 使用 x、y 坐标表示色彩（Lightness 单独表示）。HSL 和CIE1931 Color Space 的色彩表示模型如下（只包含色彩表示，不包含亮度表示）：

HSL 色彩模型在控制器中比较容易实现，只需要在控制器 UI 界面显示的Hue/Saturation 色轮上选择色彩、使用线性滑块选择亮度即可，SIG MESH 选择HSL 作为其默认的变色光控制模型。对于专业的彩色光控制程序，也可以使用CIE1931 Color Space 设置灯光的颜色，这个色彩空间是第一个用数学定义的颜色坐标。

Light HSL 与Light xyL 比较相似，主要是表示色彩的方式不一样，前者通过Hue / Saturation color wheel 表示色彩、后者通过CIE1931 Color Space 表示色彩，本文以Light HSL Models 为例简单介绍变色灯控制原理。

Light HSL state 是一个复合状态，包含Light HSL Hue、Light HSL Hue Default、Light HSL Saturation、Light HSL Saturation Default、Light HSL Lightness states（前面介绍过了，也是复合状态）等。Light HSL state 通常与Generic Level state、Generic OnPowerUp state、Light Lightness Actual state 等状态绑定。

Light HSL Server model 扩展了Light Lightness Server，Light HSL Setup Server 则扩展了Light HSL Server 和Light Lightness Setup Server。

Light LC Client / Server / Setup Server Models

商业照明的灯光功能更复杂了，对自动化控制的需求也更高了，比如通过光线传感器或人体感应器控制开关与亮度。SIG 为了满足对商业照明复杂的自动化控制需求，设计并提供了 lighting control (LC) models。

SIG MESH Light controllers 完全基于软件，可以使用传感器数据或用户消息作为照明控制的触发或驱动信号，受控制的灯光亮度变化由一系列可配置的时序参数控制、可以让用户感觉很自然。

Light LC models 使用有限状态机定义了整个Light controllers 的工作方式，Light LC state machine 的输入主要有Light LC states（包括LC Mode、LC Occupancy Mode、Light OnOff、LC Occupancy、LC Ambient LuxLevel 等，后两个是传感器模型给出的信息）和Light LC Property states（Time Fade On、Time Run On、Time Fade、Time Prolong…）两类。Light controllers 的输出是Light LC Linear Output state，该线性输出状态有条件的绑定到Light Lightness Linear state。Light controllers 的状态机模型或结构如下：

Light LC models 除了包含Light LC Server model（包含Light LC states，LC Client 可通过相应消息查询或设置该状态）和Light LC Setup Server model（包含Light LC Property states，LC Client 可通过相应消息查询或设置该状态），通常还包含Sensor Client model，通过Sensor Data 控制灯光的状态变化。Light Lightness controller 控制灯光状态转换的示例如下（在时间轴上涉及 8 个状态的顺序转换，及其每个状态的亮度变化）：

二、Foundation Model Layer

Foundation Model 也属于SIG Model 的一部分，前面介绍SIG Model ID 和SIG Message Opcode 时也谈到过。Foundation Model 之所以单独一层，主要有两个原因：一个是Foundation Model 主要服务于MESH 网络通信（Model Layer 的SIG Model 主要服务于应用场景），另一个是Foundation Model 在每个节点主元素上是强制要求实现的（Model Layer 的SIG Model 根据功能需求可选）。

Foundation Model 主要定义了两组模型：一组是Configuration Client / Server model，为MESH 节点设备提供各种配置能力（比如配置发布消息时的目的地址和TTL、模型的订阅地址、设备节点可能扮演的Relay/Friend/Low Power/Proxy 角色等）；另一组是Health Client / Server model，为MESH 节点设备提供各种故障报告和诊断能力（比如当前故障、注册故障等）。每个MESH 节点的 Primary element 都需要实现Configuration Server model 和Health Server model，用户可通过实现了Configuration Client model 或Health Client model 的设备（比如智能手机或平板电脑等）获取或更改特定设备节点的Configuration Server States 或Health Server States。

2.1 Configuration Client / Server model

Configuration Server States 比较多，每个状态都可以看作一个配置项，Configuration Client 可通过作用于特定状态的消息查询或更改Configuration Server 包含的States。

本文以Model to AppKey List State 和Model Publication State 这两个比较常用的状态为例简单介绍Foundation Configuration Model，前者主要用于Model 与AppKey 之间的绑定，后者主要用于消息发布。

前篇博文BLE MESH 如何保证通信安全也介绍了BLE MESH 定义了NetKey 和AppKey 两个层次的加密密钥，NetKey 用于加密认证网络层通信报文，AppKey 则用于加密认证Access 层通信消息。对于Configuration Client / Server model，专门设计了一类特殊的AppKey，也即DevKey（每个设备在启动配网后都被分配一个全网唯一的DevKey），用于加密认证Configuration Client 与节点设备之间交互的Configuration messages。

每个Model 在订阅地址或发布Access messages 时，都需要绑定到一个AppKey 或DevKey，保证在MESH 网络上传输的消息只能被其订阅者和发布者正确解密验证处理。模型间的消息要想在MESH 网络上传输，还需要相应的NetKey（每个子网都有一个NetKey），因此每个AppKey 都需要且只能绑定到一个单一的NetKey（DevKey 默认绑定到所有NetKey）。AppKey 或DevKey 绑定到NetKey 与Model 的图示如下：

Configuration Client 可通过Config AppKey Add message 新增AppKey 并将其绑定到特定的NetKey（可通过NetKeyIndex 唯一标识），可通过Config Model App Bind message 将某个AppKey 绑定到特定的Model（可通过ElementAddress 和Model ID 唯一标识某元素上特定的Model ）。

Client Models 与Server Models 主要是靠订阅-发布模型传递消息的，Configuration Client 可以通过Config Model Subscription Add message 添加某个model 的Subscribe Addresses，通过Config Model Publication Set message 配置某个model 的消息发布参数（比如PublishAddress、PublishTTL、PublishPeriod、PublishRetransmitCount、PublishRetransmitIntervalSteps 等）。

Config Model Publication Set message 中的Publish Period 字段包含Number of Steps 和Step Resolution 两个字段（与前文介绍的Transition Time 字段类似），发布周期配置项可用于需要周期性向某个地址发布消息的场景（比如Sensor 通常需要周期性发布传感数据）。

2.2 Health Client / Server model

Health Server States 主要包含Current Fault、Registered Fault、Health Period、Attention Timer 等状态，Health Client model 可通过作用于这些状态的消息查询或更改Health Server model 包含的States。

本文以比较常用的Current Fault State 为例简单介绍Foundation Health model，该状态主要用于Health Client model 查询最近执行自检时出现的当前故障或警告信息。

Health Server model 可通过Health Current Status message 向Health Client model 报告该元素的当前健康状态或者故障诊断信息，该消息使用AppKey 加密认证。

三、Transport Access messages

SIG Mesh Models 之间是通过Messages 相互传递信息的，上文也介绍了messages 主要由Opcode 和Parameters 两部分构成，每种message 都由唯一的Opcode 标识，Parameters 则根据不同模型要传递的信息不同而不同。

上表是Access Layer 的消息报文格式，Mesh Models Layer（包括Foundation Model Layer）的消息都需要通过Access Layer 传递，因此也称为Access messages（Control Message 在前文已介绍过了）。

有些Access messages 的payload 占用的字节比较多，单个Network PDU 最多只能承载 16 字节的TransportPDU，因此Access messages 也支持Segmentation and reassembly。除此之外，Access messages 也需要AppKey 或DevKey 进行加密认证，因此Transport Layer 分为了Upper Transport Layer 和Lower Transport Layer，前者主要进行Access PDU 的认证加密解密，后者主要进行Upper Transport PDU 的分段重组。下图以Config AppKey Add message 为例，展示Transport Layer 的认证加密和分段过程：

3.1 Upper Transport Layer

Access PDU 的认证加密过程跟Transport PDU 的认证加密过程类似，也是使用AES-CCM 认证加密算法。除了Configuration model messages 采用DevKey 认证加密外，其余Access messages 都采用AppKey 认证加密。

Using an application key:
EncAccessPayload, TransMIC = AES-CCM (AppKey, Application Nonce, AccessPayload)

Using a device key:
EncAccessPayload, TransMIC = AES-CCM (DevKey, Device Nonce, AccessPayload)

Upper Transport PDU = EncAccessPayload || TransMIC

加密Access PDU 的AppKey 或者DevKey 是与特定Model 绑定的，同一个Access messages 的Subscriber 和Publisher 应绑定相同的AppKey 或DevKey，保证某个模型发布的消息能够且只能被目的模型正确解密并处理。

3.2 Lower Transport Layer

由于单个Network PDU 可承载的Transport PDU 最大长度是 16 个字节，当Upper Transport PDU 不大于 15 字节（也即Access PDU 不大于11 字节）时不需要分段，否则应该对其进行分段处理。

Unsegmented Access Message 的格式如下：

Field	Size (bits)	Description
SEG	1	0 = Unsegmented Message
AKF	1	Application Key Flag，AKF = 1 表示使用AppKey 加密报文，AKF = 0 表示使用DevKey 加密报文（此时AID 应设为0b000000）
AID	6	Application key identifier，由AppKey 生成，标识加密Access PDU 所用的AppKey，若AKF = 0 则AID 值为0b000000
Upper Transport Access PDU	40 to 120	The Upper Transport Access PDU

AKF 和AID 两个字段标识了Access message 使用哪个AppKey 或DevKey 进行认证加密，若是Configuration model messages 则采用DevKey 认证加密（每个节点设备都有唯一的DevKey，不需要再标识使用哪个DevKey），否则采用AppKey 认证加密（通过AID 字段可知采用哪个AppKey）。

Segmented Access message 的格式如下：

Field	Size (bits)	Description
SEG	1	0 = Unsegmented Message
AKF	1	Application Key Flag
AID	6	Application key identifier
SZMIC	1	Size of TransMIC，SZMIC = 0 表示TransMIC 字段的长度为32 位，SZMIC = 1 表示TransMIC 字段的长度为64 位
SeqZero	13	Least significant 13 bits of SeqAuth，相当于消息第一个分段的SEQ 的低 13 位，同一个消息不同分段的SeqZero 值相同，用来标识某个特定的消息
SegO	5	Segment Offset number，表示当前报文的分段号（可以理解为当前报文是该消息的第几个分段，需要从0 开始计）
SegN	5	Last Segment number，该消息的最后一个分段号，同一个消息不同分段的SegN 值相同，用来表示该消息被分成了多少段
Segment m	8 to 96	Segment m of the Upper Transport Access PDU，承载接入消息的每个分段内容

与Segmented Control message 类似，也是通过SeqZero、SegO、SegN 三个字段实现分段重组功能的。一个Upper Transport Access PDU 最多可以分成 32 个Segments，每个Segmented Access message 最多只能承载 12 字节，因此Segmented Access messages 最多可以承载 384 字节的Upper Transport Access PDU。若TransMIC 长度为 32 位（Unsegmented Access Message 或SZMIC = 0 的Segmented Access message），则可以承载的Access PDU 最大长度为 380 字节，若TransMIC 长度为 64 位（SZMIC = 1 的Segmented Access message），则可以承载的Access PDU 最大长度为 376 字节。

如果Segmented Access messages 的DST 字段是单播地址，分段消息的接收者会回复Segment Acknowledgment message；如果Segmented Access messages 的DST 字段是组播或虚拟地址，为了减少网络资源占用，分段消息的接收者就不回复确认应答报文了。

Access messages 传递到MESH 协议更下层的Network Layer、Advertising Bearer 和GATT Bearer 是如何封装处理的，如何实现MESH Provisioning Process、Key Refresh procedures、IV Update procedure、Network addressing process、Encrypted/Obfuscated process 等可以参阅上篇博文：BLE MESH 各层报文是如何设计的(上)？

BLE 技术（九）--- SIG MESH Models 是如何设计的（下）？