目錄
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.