目录
4.2.3 Subscription List （订阅列表）
4.2.14 Key Refresh Phase（Key刷新阶段）
4.2.16 Health Fast Period Divisor
4.2.17 Heartbeat Publication（心跳发布）
4.2.17.1 Heartbeat Publication Destination（心跳发布目的地）
4.2.17.2 Heartbeat Publication Count（心跳发布数量）
4.2.17.3 Heartbeat Publication Period Log
4.2.17.4 Heartbeat Publication TTL
4.2.17.5 Heartbeat Publication Features
4.2.17.6 Heartbeat Publication NetKey Index
4.2.18.1 Heartbeat Subscription Source
4.2.18.2 Heartbeat Subscription Destination
4.2.18.3 Heartbeat Subscription Count
4.2.18.4 Heartbeat Subscription Period Log
4.2.18.5 Heartbeat Subscription Min Hops
4.2.18.6 Heartbeat Subscription Max Hops
4.2.19.1 Network Transmit Count
4.2.19.2 Network Transmit Interval Steps
4.2.20 Relay Retransmit4.2.21 PollTimeout List
4.3.1 Supplemental parameter requirements
4.3.2.46 Config Model App Bind
4.3.2.47 Config Model App Unbind
4.3.2.49 Config SIG Model App Get
4.4.1 Configuration Server model
4.4.2 Configuration Client model
Foundation Models定义访问层的状态、消息和模型，这些是在配置和管理一个mesh网络时所需要到的。
4.2 状态定义
通过一个或多个状态定义来定义一个节点（Node）的状态。本节定义贯穿于整个profile Spec的状态。
4.2.2 Models Publication
Model Publication状态是一个复合状态，用来控制Model发布的消息的参数。Model Publication状态包含发布地址、发布周期、发布TTL、发布重传次数等等。在一个元素之内，每个Model都有分隔的Model Publication状态实例。强烈建议高层spec定义的Models使用Model Publication状态实例来控制消息的发布。
4.2.3 Subscription List （订阅列表）
订阅列表状态是一个组播地址和label UUID的列表。
订阅列表是在一个Model接收Access messages时使用的。强烈建议：被上层Spec定义的Models使用订阅列表实例，来控制消息接收。
4.2.4 Netkey List
Netkey List是一个Netkeys的索引列表。
Netkey List的每一个实例都持有最多两个key值：旧的Key值和新的key值。旧的Key值和新的key值的使用在Key Refresh procedure中有详细描述。
Netkey List应该包含至少一个Netkey。
4.2.5 AppKey List
AppKey List是一个AppKeys的索引列表。
AppKey List的每一个实例都持有最多两个key值：旧的Key值和新的key值。旧的Key值和新的key值的使用在Key Refresh procedure中有详细描述。
4.2.6 Model to AppKey List
Model to AppKey List状态是一个Models和AppKeys之间关系的列表。一个Model可能被一个或多个AppKeys关联。
4.2.7 Default TTL
Default TTL状态定义了发送message时的TTL值。若非应用程序指定一个TTL值，Access Layer将使用Default TTL值。
4.2.8 Relay（中继）
Relay状态表明节点是否支持Relay特点；如果支持Relay特点，也表明是否Relay特点是否使能。
4.2.9 Attention Timer
Attention Timer状态定义是否Attention Timer状态的开着的还是关着的。一般来说，它是用来允许一个element吸引人注意。用在Provisioning过程中。
5.4.2.2中有描述：Provisioner向Provisionee发送的Provisioning Invite PDU中包含Attention Timer值，期望Provisionee通过某种方式（比如灯光闪烁、speaker输出响声等）标识自己，持续时长为Provisioner指定的Attention Timer 值。
Provisionee一旦接收到来自Provisioner的Provisioning Start PDU之后，就应该设置Attention Timer为0.
4.2.10 Secure Network Beacon
Secure Network Beacon状态决定一个节点Node是否正在周期性广播Secure Network Beacon消息。
4.2.11 GATT Proxy（GATT代理）
GATT proxy状态表明节点是否支持Proxy特点；如果支持Proxy特点，GATT Proxy状态还表明和控制Proxy特点 是否使能。
4.2.12 Node Identity
Node Identity状态决定是否一个节点使用Node Identity消息来广播。在使用Proxy feature中使用到。
4.2.13 Friend（好友）
Friend状态表明对Friend特点的支持。如果支持Friend特点，Friend状态还表明和控制Friend特点是否使能。
4.2.14 Key Refresh Phase（Key刷新阶段）
Key Refresh Phase状态表明和控制Key刷新阶段NetKey List中的每个NetKey。包括3个阶段：Normal operation （0x00）、Key Refresh Procedure的第一个阶段（0x01）、Key Refresh Procedure的第二阶段（0x02）。
4.2.15 Health Fault（健康故障）
Health fault状态是一个复合状态，代表一个元素element的警告或错误状况。
4.2.16 Health Fast Period Divisor
N/A
4.2.17 Heartbeat Publication（心跳发布）
Heartbeat Publication状态是个复合状态，用来控制 "周期性的心跳传输控制消息" 的发送。
在3.6.5.10中有讲述：节点发送心跳消息（Heartbeat Meaasge）来让其他节点决定子网的拓扑结构。心跳消息的参数包含InitTTL、Features，其中InitTTL指定发送心跳消息的初始化的TTL值，Features指定节点当前使用的feature情况（比如Realy中继、Proxy代理Friend好友、Lower Power低功耗）。Heartbeat Message（心跳消息）是同 Friend request、Friend offer、Friend Pool等一样的Transport Control message,opcode为0x0A。
4.2.17.1 Heartbeat Publication Destination（心跳发布目的地）
Heartbeat Publication Destination状态定义了心跳消息的目的地址，目的地址应该是一个unassigned address（未分配的地址）、单播地址或者组播地址，所有其他值均是禁止使用的。
Note：如果Heartbeat Publication Destination设定为未分配的地址，那么心跳消息不应该被发送。
4.2.17.2 Heartbeat Publication Count（心跳发布数量）
Heartbeat Publication Count状态是一个16 Bit的值，用来控制周期性的心跳传输控制消息的发送数量。当设置为0xFFFF时，发送每一个心跳消息之后，它不会减小；当设置为0x0000时，心跳消息不被发送；当设置为0x0001~0小FFFE中的一个值时，发送完每个心跳消息之后它会减小。
Heartbeat Publication Count Log是Heartbeat Publication Count状态值的表现形式。Heartbeat Publication Count Log的值0x00等同于Heartbeat Publication Count的值0x0000；Heartbeat Publication Count Log的值0xFF等同于Heartbeat Publication Count的值0xFFFF；Heartbeat Publication Count Log的值（在0x01和0x11之间）代表2的(n-1)次方的最小值，在这里2的(n-1)次方大于或等于Heartbeat Publication Count的值。例如，如果Heartbeat Publication Count的值为0x0579，那么Heartbeat Publication Count Log的值将为0x0C （备注：十六进制的0x579是十进制的1401，所以n-1为11，n为12，即0x0C）。
4.2.17.3 Heartbeat Publication Period Log
Heartbeat Publication Period Log状态是一个8-bit的值，用来控制周期性心跳传输控制消息的节奏。以2的(n-1)次方的形式表示心跳消息发布周期，单位为秒（seconds）。例如，Heartbeat Publication Period Log为0x04表示心跳消息的发布周期为8秒，Heartbeat Publication Period Log为0x07表示心跳消息的发布周期为64秒。（Note：这里也算是个小技巧，如果直接使用Heartbeat Publication Period，那么使用一个字节肯定表示不到很大的数值，所以使用它的对数形式来表示）
4.2.17.4 Heartbeat Publication TTL
Heartbeat Publication TTL状态决定了发送心跳消息时的TTL值。
4.2.17.5 Heartbeat Publication Features
Heartbeat Publication Features状态决定了节点的Features，当它变化时将触发心跳消息的发送。
4.2.17.6 Heartbeat Publication NetKey Index
Heartbeat Publication NetKey Index状态决定了用于发送心跳消息的NetKey的全局NetKey list.
4.2.18 Heartbeat Subscription
Heartbeat Subscription状态是个复合状态，用来控制周期性的心跳传输控制消息的接收。
4.2.18.1 Heartbeat Subscription Source
Heartbeat Subscription Source状态决定了一个节点应该处理的心跳消息的源地址。Heartbeat Subscription Source应该是未分配的地址或者是一个单播地址，所以其他的地址将被禁止。
如果Heartbeat Subscription Source被设置为未分配的地址，那么收到的心跳消息不应该被处理。
4.2.18.2 Heartbeat Subscription Destination
Heartbeat Subscription Destination状态决定了心跳消息的目的地址。Heartbeat Subscription Destination状态可以被节点用于配置proxy filter来允许它接收心跳消息，例如，节点被GATT bearer连线或者在一个friendship中（也就是说，Heartbeat Subscription Destination状态在Proxy节点或者Friend节点中会使用到。） Heartbeat Subscription Destination应该是个未分配的地址、节点的primary单播地址或者组播地址，其他所有值都是禁止的。
4.2.18.3 Heartbeat Subscription Count
Heartbeat Subscription Sount状态一个16-bit的计数器，用来控制自从接收到最近一次Config Heartbeat Subscription Set消息后接收到的心跳传输控制消息的数量。计数器值到达0xFFFF时停止计数。
Heartbeat Subscription Count Log是Heartbeat Subscription Count值的表现形式。
4.2.18.4 Heartbeat Subscription Period Log
Heartbeat Subscription Period 状态是个16-bit的值，用来控制处理周期性传输控制消息的周期。当Heartbeat Subscription Period设置为0x0000时，心跳消息不被处理。当Heartbeat Subscription Period设置为大于或等于0x0001时，心跳消息会被处理。
Heartbeat Subscription Period Log是Heartbeat Subscription Period值的表现形式。
4.2.18.5 Heartbeat Subscription Min Hops
Heartbeat Subscription Min Hops状态决定当接收到心跳消息时的最小跳数值 （自从接收到最近一次Config Heartbeat Subcription Set消息之后）
4.2.18.6 Heartbeat Subscription Max Hops
Heartbeat Subscription Max Hops状态决定当接收到心跳消息时的最大跳数值 （自从接收到最近一次Config Heartbeat Subcription Set消息之后）
4.2.19 Network Transmit
Network Transmit状态是个复合状态，用于控制由节点发起的Network PDU重传的数量和时间点。
这个状态包含一个Network Transmit Count域和一个Network Transmit Interval Steps域。
对于节点来说，有一个Network Transmit状态实例。（不像有的状态，比如Models Publication状态，节点的元素中每个Model都有一个单独的Models Publication状态实例）
4.2.19.1 Network Transmit Count
Network Transmit Count域是一个3-bit值，控制由节点发起的Network PDU的重传的数量。重传的数量为（Network Transmit Count + 1）。比如，0b000代表重传1次，0b111代表重传8次。
4.2.19.2 Network Transmit Interval Steps
Network Transmit Interval Steps域是个5-bit值，代表节点发起的Network PDU重传之间的间隔。Transmission interval使用下面的公式计算：
Transmission interval = （Network Retransmit Interval Steps + 1） * 10
每次重传应该使用一个0到10 ms之间的随机数扰乱。
例如，0b10000代表重传间隔在170 ms到180 ms之间
4.2.20 Relay Retransmit
4.2.21 PollTimeout List
PollTimeout List状态是个列表
4.3 Message definitions
本节定义整个 mesh profile spec都会用到的消息。每个消息都有一个opcode和0个或多个参数，定义如下：
4.3.1 Supplemental parameter requirements
4.3.2 Configuration messages
Configuration messages用于控制状态（这些状态决定了节点网络相关的行为）、操作NetKey和AppKey，而且执行其他需要提升安全级别的操作。每一个Configuration message应该使用DevKey进行加密和授权。
因为DevKey对于每一个节点是唯一的，因此configuration message应该只被发送到单播地址。
4.3.2.12 Config Relay Get
Config Relay Get消息用于获取节点当前的Relay状态和Relay Retransmit状态。
4.3.2.13 Config Relay Set
Config Relay Set消息用于设置节点当前的Relay状态和Relay Retransmit状态。
4.3.2.37 Config AppKey Add
Config AppKey Add消息用于向节点的AppKey List中增加一个AppKey，并且把它bind（绑定）到由NetKeyIndex指定的NetKey上面。增加的AppKey只能够被节点与指定的NetKey一起使用。
4.3.2.41 Config AppKey Get
Config AppKey Get消息用于获取bind（绑定）到特定NetKey上的所有的AppKey。
4.3.2.46 Config Model App Bind
Config Model App Bind消息用于将一个AppKey绑定（Bind）到一个Model上。
4.3.2.47 Config Model App Unbind
Config Model App Unbind消息用于解除一个AppKey和一个Model的Bind（绑定）。
4.3.2.49 Config SIG Model App Get
Config SIG Model App Get消息用于获取Bind（绑定）到特定SIG Model上的所有AppKeys。
4.3.2.53 Config Node Reset
Config Node Reset消息用于将一个节点（除Provisioner外）复位，并将其从mesh网络中移除。
4.4 Model definitions
Configuration Model messages使用DevKey进行加密；
Health Model Messages使用AppKey进行加密。
4.4.1 Configuration Server model
This model is used to represent a mesh network configuration of a device.
The model shall be supported by a primary element and shall not be supported by any secondary elements. The application-layer security on the Configuration Server model shall use the device key established during provisioning
4.4.2 Configuration Client model
The model is used to represent an element that can control and monitor the configuration of a node.
Configuration Client messages shall be secured using a DevKey.
4.4.3 Health Server model
This model shall support model publication (see Section 4.2.2) and model subscription (see Section 4.2.3).
This model is used to represent a mesh network diagnostics of a device.
The model shall be supported by a primary element and may be supported by any secondary elements.
The application-layer security on the model is using application keys.
4.4.4 Health Client model
If supported, the Health Client model shall be supported by a primary element and may be supported by any secondary elements. The application-layer security on the model is using application keys.