写在前面： 本文参考Mesh Core Spec 翻译而来，翻译能力有限肯定有理解不到位之处，还请大家指出。欢迎广大蓝牙、mesh爱好者一起交流，本人QQ：993650814。
正文：
1、简介：
上层传输层（Upper Transport Layer）从访问层（Access layer） 获取访问层数据（access payload）或者上层传输层内部产生Upper Transport layer Control Message并将这些messages传给对端的上层传输层（Upper transport layer）。
对于访问层（access layer）的messages，使用application key对这些message加密和认证。这允许上层传输层（upper transport layer）来认证接收到的messages。
Transport Control messages 由upper transport layer 内部生成，并且只能在网络层（network layer）加密和认证。
2、Upper Transport Access PDU （上层传输访问PDU）
当Network PDU的CTL字段是0的时候，Upper Transport PDU包含的负载就称为Upper Transport Access PDU。
访问层的负载（access payload）使用app key或者device key来加密，经过加密的访问层负载（access payload）加上信息完整性检查消息被整合进Upper Transport Access PDU中。Upper Transport Access PDU的格式如下：
2.1 Entrypted access payload
访问层负载（access payload）由访问层（access layer）提供。如果TransMIC字段是32bits，则访问层的负载的长度范围是1~380个bytes，如果TransMIC是64bits，访问层负载（access payload）的长度是1~376个bytes。在upper transport layer，Entrypted Access Payload字段是不透明的，并且不能使用该字段内的信息。
2.2 TransMIC
传输信息完整性检查（Message Integrity Check for Transport -----TransMIC）是32bits或者64bits的，这个字段用来验证访问层负载（access payload）是否被更改过。对于SEG字段设置为1的分段的消息（segmented message），TransMIC的大小取决于Lower Transport PDU的SZMIC字段的大小。对于未分段的消息（unsegmented messages），TransMIC是32bits的。
3、 Upper Transport Control PDU（上层传输控制PDU）
当Network PDU的CTL 位是1的时候，Upper Transport PDU包含传输控制消息（transport control message）。传输控制消息（transport control message）包含7 bit的opcode来决定paramters的格式。Opcode 字段不包含在paramters字段内，但是包含在Lower Transport PDU Unsegmented Control message或者Segmented Control Message的每个段中。
Upper Transport Control PDU不是在上层传输层（upper transport layer）认证的，而是在网络层（network layer）认证的。所有的Upper Transport Control PDUs使用64 bit的NetMIC。
下层传输（lower transport layer）会将messages分割成好几个更小的PDUs来让网络层（network layer）传输。Transport Control PDU的payload 定义如下，这些值代表了paramter字段的最大有效值取决于Number of Packets。
Upper Transport Control PDU的最大值是256Bytes。
4、 Upper transport layer behavior（上次传输层的特征行为）
4.1 transmitting an access payload（传输访问层payload）
所有的访问层消息（access messages）都会包含application key或者device key。access payload 会被application key或者device key加密，TransMIC 用作信息完整性检查，定义在3.8.6中。Upper Transport PDU的处理过程定义在3.5.4.1中。
Sequence number（SEQ）要被分配在access payload消息中。下层传输层（lower transport layer）分段的（segmented message）消息的上下文中，SEQ等于SeqAuth值得低24位，SEQ值在receiver中用来解密和认证访问层消息（access message），定义在3.5.3.1章节中。
Lower Transport PDU的AFK和AID字段要根据application key或者device key来填充，用来加密和认证Upper Transport PDU。如果使用application key，AFK字段要被置1，AID字段要被设置成应用密钥标识符（AID）。如果使用device key，AFK字段要被置0，并且AID字段设置成0b000000.
上层传输层（upper transport layer）直到前一个Upper Transport PDU 发送到目的地址完成或者取消发送之后，才会传输一个新的segmented Upper Transport PDU给目的地址。
4.2 Receiving an Upper Transport PDU
当接受到Upper Transport Access PDU的时候，access payload 要被解密，并且要TransMIC要根据已知的application key或者device key匹配的AFK和AID字段来进行验证。如果Upper Transport Access PDU认证完并检查过重传攻击之后，会派送到访问层（access layer），送到访问层的时候会附带上上下文的信息例如：source address、destination address、解密和认证的key。
当接收到Upper Transport Control PDU的时候，PDU的目的地址会被检查是否跟node的元素的单播地址匹配，如果匹配会被进一步处理（3.6.6）章节。
如果node支持Friend feature 并且这个feature 使能了，这个node有个friendship关系跟LPN，收到这个消息的目的地址在LPN的Friend Subscription List 当中，这个消息要被存储到相关的Friend Queue当中。
5、Transport Control messages （传输控制消息）
可以使用一个单独的Unsegmented Control message或者是Segmented Control messages来传输Transport Control messages。每个消息中有个7-bit的opcode字段来决定paramters字段的格式。每个Transport Control Message要用尽可能少的Lower Transport PDUs来传送。
Table3.39 对Transport Control Message的opcode 做了总结，如下：
5.1 Friend Poll
LPN 发送Friend Poll消息来让Friend node发送它给LPN节点存储的消息。
Friend Poll message的paramters格式定义如下：
Transport Control message的Opcode 字段设为0x01
FSN：Friend Sequence Number，用来对前面接收到的Friend node给LPN node的 messages的应答。0或者1，参考3.6.6.4.2
这个message要设置Network PDU的TTL字段为0
这个message要用friendship的安全资料加密。
5.2 Friend Update
Friend Update message 由Friend 节点发送给LPN节点，来提示LPN节点网络的安全资料已经改变了或者正在改变或者Friend Queue 是空的。
Friend Update message的parameters字段定义如下：
Transport Control message 的Opcode字段是0x02.
Flags字段是8-bit的定义如下：
Key Refresh Flag指示 Key Refresh（密钥刷新）过程是否在进行。
IV Update Flag指示Iv Update 过程是否在进行。
IV Index字段 包含了当前的IV Index。
MD 字段指示了Friend Queue 是否是空的，定义如下：
Friend Update message的对于的Network PDU的TTL字段是0
这个消息使用friendship的安全资料来进行发送。
5.3 Friend Request
LPN 节点发送Friend Request message给所有friend group（all-friends group）来查找一个friend节点。
Friend Request message的paramters 定义如下：
Transport Control message的Opcode字段是0x03.
Criteria 字段格式定义如下：
RSSIFactor：由Friend node来计算RSSI值，并用作Friend Offer Delay 计算上。定义如下：
ReceiveWindowFactor：用在Friend Offer Delay 计算上。
MinQueueSizeLog：Friend node可以存储在Friend Queue里面的最小的message 数量。等于log2(N)，N的值定义如下：
ReceiveDelay：由LPN节点请求设置，这个字段需要设置在如下范围内：单位是毫秒
PollTimeout：初始值由LPN节点设置，有效数据范围如下： 单位100毫秒
PreviousAddress：设置为上一个Friend的单播地址，如果之前没有建立过友谊关系，这里设置为未分配地址（unassigned address）。
NumElements：这个字段设置为LPN的元素的个数。这个字段Friend 节点用来计算LPN单播地址的范围。定义如下：
LPNCounter：这个字段设置为LPN发送的Friend Request messages的数量。
Friend Request 的Network PDU的TTL字段是0.
Friend Request这个消息使用主安全资料加密。
5.4 Friend Offer
Friend Offer message是Friend节点发送的建立friendship 邀请的message。
Friend Offer message 的Paramters定义如下：
Transport Control message的Opcode是0x04
ReceiveWindow ：Receive Windows是Friend 节点所支持的接受窗口，定义如下：
QueueSize：这个字段包含了Friend 节点为LPN节点存储的消息的数量。
SubscriptionListSize：这个字段包含了订阅列表中Friend 节点支持的LPN节点的数目。
RSSI字段：8-bit的值，理解为接收到的信号强度值dBm。这个是Friend节点根据Friend Request消息测量计算的。如果信号强度指示不可用则这个字段设置为0x7F（127dBm）。
FriendCounter：这个字段设置为Friend节点发送过的Friend Offer messages的数量。
Friend Offer 消息的Network PDU的TTL字段设置为0.
Friend Offer 消息使用主安全信息资料加密。
5.5 Friend Clear
Friend Clear message 发送到Friend 节点来告知要解除friendship关系。
Friend Clear message 的paramters字段定义如下：
Transport Control message的Opcode字段是0x05.
LPNAddress字段设置为要移除的LPN节点的单播地址。
LPNCounter字段设置为用于建立关系的最新的Friend Request的LPNCounter。
这是一个需要确认的消息，并且发送节点期望收到Friend Clear Confirm message作为回应。如果Friend node 没有收到回应，Friend node会以两倍的时间间隔（2s、4s、8s、16s等）重新发送这个消息，直到收到回应或者达到LPN的Poll Timeout时间。
Friend Clear 消息 发送的时候需要主安全资料。
5.6 Friend Clear Confirm
旧的Friend 节点发送Friend Clear Confirm 消息作为Friend Clear message的回应来确认friendship关系被终止。如果接收到的Friend Clear消息的TTL是0，则Friend Clear Confirm消息的TTL也是0.
Friend Clear Confirm 的Paramters定义如下：
Transport Control message 的Opcode字段设置为0x06.
LPNAddress字段设置为要移除的LPN的单播地址。
LPNCounter字段设置为Friend Clear message相关的LPNCounter。
Friend Clear Confirm消息应该在前一个friend 的relationship的Poll Timeout内收到有效的Friend Clear message时被发送。在这个周期里面，会对每一个收到的Friend Clear message发送Friend Clear Confirm message。如果Friend Clear message的LPNCounter减去最开始建立friendship的Friend Request message的LPNCounter在0~255之间包括255就认为Friend Clear message是有效的。
Friend Clear message要用主安全资料加密。
5.7 Friend Subscription List Add
Friend Subscription List Add message由LPN发给Friend 节点，来指示为LPN存储的group address 和virtual address的列表。
Friend Subscription Lista Add message的Paramter 字段定义如下：
Transport Control message的Opcode字段设置为0x07.
TransactionNumber 字段用来区分每个单独的传输（3.6.6.4.3z章节）。
AddressList：这个字段包含了添加到Friend Subscription List 中的group address和virtual addresss。
注意：当Friend Subscription List Add消息作为Unsegmented Control message 发送的时候，AddressList字段不能多于5个地址。
这个消息的Network PDU中的TTL字段是0.
这个消息用friendship 安全资料加密。
5.8 Friend Subscription List Remove
Friend Subscription List Remove 消息是LPN 节点发送给Friend 节点的，用来指示从Friend Subscription List中移除的group addressed和virtual addresses。
Friend Subscription List Remove 消息的Paramters 字段定义如下：
Transport Control message 的Opcode是0x08.
TransactionNumber 字段用来区分每个单独的传输（3.6.6.4.3章节）
AddressList 字段要包含从Friend Subscription List中移除的group addresses和virtual addresses。
注意：当这个消息作为Unsegmented Control message发送时，AddressList字段不能多于5个地址。
这个消息对应的Network PDU的TTL字段是0.
这个消息用friendship的安全资料进行加密。
5.9 Friend Subscription List Confirm
Friend Subscription List Confirm 消息是Friend 节点发送给LPN节点，是对Friend Subscription List Add message或者Friend Subscription List Remove message的回复。
Transport Control Message的Opcode是0x09.
Friend Subscription List Confirm消息的paramters定义如下：
TransactionNumber 字段用来区分每个单独的传输。
这个消息对应的Network PDU的TTL字段是0.
这个消息要用friendship 安全资料进行加密。
5.10、Heartbeat
Heartbeat message有节点发送，来让其他节点确定子网的拓扑关系。
Heartbeat message Paramters定义如下：
Transport Control message的Opcode字段设置为0x0A。
InitTTL字段定义如下：
initTTL字段包含了发送消息初始TTL。
Features 字段包含了当前结点的现在拥有的features，定义如下：
5.11、 Summary of Opcodes
下表总结了Transport Control message的Opcode
6、 Friendship
友谊节点可以给LPN节点存储消息。
6.1 Functional overview
为了减小LPN的功耗，轮训机制用来减小LPN 的接收窗口。这允许LPN节点何时可以从Friend节点那里获取到更新的消息。
LPN和Friend节点存在友谊关系期间，Friendship 静态的决定了他们之间的定时参数。
Friendship中使用了三种定时参数：ReceiveDelay、ReceiveWindow、PollTimeout
ReceiveDelay 是LPN发送请求和监听响应之间的时间。这个delay允许Friend 节点准备响应的时间。
ReceiveWindow 是LPN监听响应的时间。当LPN收到Friend节点的消息的时候，就可以停止监听其他额外的消息了。
request可以是Friend Poll message、也可以是Friend Subscription List Add message、或者是 Friend Subscription List Remove message。给Friend Poll message回应的消息可以是Friend Update messahe或者是stored message。给Friend Subscription List Add message或者Friend Subscription List Remove message回应的是Friend Subscription List Confirm message。
定是参数解释如下图：
PollTimeout timer用来测量LPN节点发过来的两个连续的请求的时间。如果Polltimeout timer超期了但是Friend 节点没有收到请求，那么friendship关系将会认为终止。解释如下：
为了建立友谊关系，支持LPN feature的节点会发送Friend Request 给所有的all-friends address。只要是支持Friend feature 并且在radio 范围内的所有节点都会收到这个消息。
Friend Request 消息包含了几个参数，这些参数定义了此节点要求未来的Friend节点支持的要求。支持Friend feature并且可以满足Friend Request message 中的要求的所有节点都可以给这个LPN节点发送Friend Offer消息。这些offers中也包含了关于自身的一些额外的信息。这些允许LPN节点来决定选择哪一个offer。
LPN 发送Friend Poll 消息给他选择的Friend 节点，Friend节点发送Friend Update 消息作为回复。然后，friendship就建立起来了。过程如下图：
如果LPN节点之前和另外一个Friend节点建立了友谊关系，则新的Friend 节点会通知旧的Friend节点他现在和这个LPN节点建立了friendship关系。（3.6.6.3.1）
Friendship建立之后，Friend节为LPN存储了Friend Subscription List，这是LPN节点订阅的group 和virtual addresses的集合。这个列表允许Friend节点存储LPN订阅的消息。
已知的Netkey的IV index、IV Update flag、Key Refresh Flag称为安全参数（security paramters）。只要任何安全参数中的一个发生了更新，都可以称为安全更新（security updates）。
Friend节点的Friend Queue存储了LPN节点的所有消息，也包括给LPN更新的最近的安全更新。这些称之为消息存储（stored messages）。
为了获取存储的消息（stored messages），LPN节点发送Friend Poll messages，Friend node用存储的消息（stored message）回复。
存储在Friend Queue中的消息会按照顺序以回应的的方式分发给LPN.为了使能这个功能，Friend Sequence number 会被使用。这个值存储在LPN中并且在每个Friend Poll message 中被发送。当LPN节点收到给Friend Poll有效的回复的时候，LPN节点会改变Friend Sequence Number，目的是下次LPN节点轮询的时候，Friend节点会发送下一个消息。如果没有对Friend Poll message进行回复，LPN节点不会改变Friend Sequence Number，这时候Friend就会判断上一个消息没有接收成功并且重发上个消息。
6.2 Friendship security
当Friend节点和LPN建立friendship关系的时候，friendship安全材料（friendship security material）通过friendship 安全证书（friendship security credentials）创建的（3.8.6.3.1），所有的这两者之间的信息交换都会被安全材料加密。在Low Power Establishment 过程期间，友谊安全证书（friendship security credentials）会被交换（3.6.6.4.1）。
Friend Poll、Friend Update、Friend Subscription List Add/Remove/Confirm 消息，以及Friend 节点给LPN节点分发的存储消息（stored messages），都要通过友谊安全证书（friendship security credentials）来加密。Friend Clear 消息和Friend Clear Confirm 消息用主安全资料（master security credentials）来加密。
LPN节点发送消息的时候使用friendship security credentials还是master security credentials来进行加密取决于Publish Friendship
Credentials Flag（4.2.2.4）.
如下图，虚线部分展示了用friendship security credentials 加密的消息，实线部分展示了用master security credentials加密的消息。LPN开始通过使用master security credentials 加密的Friend Request message。Friend 节点同样使用master security credentials 加密的Friend Offer 消息作为回复。LPN和Friend都是用master security credentials，因为他们这时还没有彼此建立friendship关系，所以不会使用friendship security credentials。LPN接受friendship的邀请，并发送一个用friendship security credentials加密的Friend Poll以示确认。Friend节点用Friend Update消息作为回应。LPN节点现在可以通过Friend Subscription List Add message来配置友谊订阅列表，然后Friend节点使用Friend Subscription List Confirm message作为确认。这些消息的发送都是用friendship security credentials来加密。
一会之后，Friend 节点收到其他节点发来的需要分配给LPN的message（InMsg），friend 节点会将这个消息存储在Friend Queue之中。LPN发送一个使用friendship security credentials加密的Friend Poll 消息，Friend节点会用刚刚存储的InMsg回复给LPN。
LPN发送两个messages：OutMsg1和OutMsg2.OutMsg1用friend security credentials加密，因此只有Friend节点才可以接受和中继这个消息。当Friend节点中继OutMsg1的时候，这个消息会使用master security credentials 来进行加密后重传。OutMsg2使用master security credentials加密，因此Friend节点或者其他LPN传送范围内的中继节点都可以中继这个消息。当OutMsg2被中继的时候，会使用master security credentials进行加密。
6.3 Friend feature
Friend feature 定义了三个强制性的操作：友谊建立（friend establishment）、友谊消息（friend messaging）、友谊管理（friend management）。
由Friend 节点发起的所有传输控制消息应作为Unsegmented Control message发送，其中SRC字段设置为Friend节点的主元素的单播地址。
6.3.1 Friend establishment
支持Friend feature并使能了该特征的节点，当收到Friend Request消息的时候，并且满足了这个消息中制定的最基本的需求的时候，就可以发送Friend Offer 消息作为回应了。
如果Friend Requst message的source address是LPN的单播地址，但是这个LPN此时依旧跟Friend节点保持着friendship关系，这时候Friend节点依旧认为跟LPN存在的friendship关系需要被终止。
Freiend Offer message的destination address需要跟Friend Request message的source address 设置的相等，并且TTL设置为0.
节点需要保持一个Friend 节点的计数器（FriendCounter），这是一个两个字节的值初始化为0。这个值要在Friend Offer message中被发送，并且如果建立友谊关系，这个值将会派生friendship security material。每次发送Friend Offer message 的时候，FriendCounter会加1 .
从收到Friend Request message到发送Friend Offer message之间的时间叫做Friend Offer Delay。
Friend Offer Delay允许LPN从可选的Friend节点之间接受Friend Offer 消息，在次期间可以决定ReceiveWindows的大小或者是信号质量的强度。有的LPN节点倾向于Friend节点有更小的ReceiveWindow，因此ReceiveWindowFactor比RSSIFactor更重要。有的LPN节点更倾向于选择Friend节点有更高的信号强度，因此RSSIFactor比ReceiveWindowFactor更重要。这意味着从接收到的Friend Offers消息中更快的选择出合适的Friend节点来匹配LPN节点的需求，减少LPN寻找Friend节点时的功耗。
Local Delay 的计算公式如下：
Local Delay = ReceiveWindowFactor * ReceiveWindow - RSSIFactor * RSSI
ReceiveWindowFactor从Friend Request message中获取
ReceiveWindow从Friend Offer message中获取
RSSIFactor从Friend Request message中获取
RSSI 是Friend节点接收到Friend Request message的信号强度。
如果Local Delay的值大于100，则Friend Offer Delay值（单位毫秒）要设置成Local Delay 值。否则，Friend Offer Delay值要设置成100毫秒。
如果发送Friend Offer message之后的1s之内收到了Friend Poll message，friendship就建立起来了，并且要从Friend Poll message中存储下FSN字段。否则，friendship建立失败。
Friend节点收到LPN的Friend Poll message之后，在最小ReceiveDelay毫秒和ReceiveDelay + ReceiveWindows 毫秒之间回应Friend Update message。
下图阐述了很多具备Friend feature 特点以及使能了这一feature的节点收到相同的Friend Request message 时的行为。
Friendship建立之后，Friend节点会初始化Friend Subscription List为空，然后开始给LPN在Friend Queue中存储message。
Friendship建立之后，如果Friend Request message的PreviousAddress字段包含了一个有效的单播地址，并且这个单播地址不是当前Friend节点的单播地址，那么这个Friend节点要根据如下步骤发送Friend Clear messages给这个单播地址：
(1)、TTL字段要被设置为最大有效值。
(2)、第一个Friend Clear message要在friendship 刚建立的时候开始发送，同时，FriendClear Repeat timer要被开启，这个周期要被设置为1s。Friend Clear Procedure timer也要被开启，周期要等于2倍的Friend Poll Timeout值。
(3)、如果收到了Friend Clear message的回复消息Friend Clear Confirm message，以上两个timers都要 取消并且这个过程结束。
(4)、如果Friend Clear Repeat timer到了，新的Friend Clear message会被发送，timer需要被重启并且定时周期设置为之前的Friend Clear Repeat timer 周期的两倍。例如，第一次定时器到后，周期设置为2秒，下一次定时器时间到后，时间设置为4s，一次类推。
(5)、如果Friend Clear Procedure timer到时候，Friend Clear Repeat timer会取消并且整个过程结束。
下面就是这个过程的介绍，一旦friendship建立之后，friend节点会跟LPN节点按照定义的消息（Friend messaging）进行通讯，可能在Friend Management中进行管理。
6.3.2 Friend messaging
当Friend节点从LPN节点收到Friend Poll message但是这个FSN字段跟上次的Friend Poll message的FSN字段一样的时候，Friend节点会回复跟上次相同的数据，除非该消息已经被丢弃。如果先前的消息被丢弃了，则最先发送最早存到Friend Queue中的消息。
当Friend节点收到友谊LPN节点的Friend Poll message的时候，并且FSN字段跟上一个LPN发送的Friend Poll的FSN字段不相等的时候，应该发送Friend Queue中的最早存储的消息。
当发送存储的消息（stored message）给LPN节点的时候，要保持发送不变。如果Friend节点的IV index改变了，例如现在的节点在用新的IV index传输消息，则发送到LPN的消息Friend节点IV index的上下文中发送这些消息。
注意：LPN节点要至少在96小时内获取一次所有存储的消息（stored messages），否则在LPN接受消息之前Friend节点会丢弃这些存储的消息。
在收到LPN发送的Friend Poll message之后，message要在最小ReceiveDelay 毫秒和ReceiveDelay+ReceiveWindow毫秒之间发送给LPN。
如果PollTimeout 到期之后Friend节点没有收到Friend Poll、Friend Subscription List Add、或者Friend Subscription List Remove
message,friendship将会被终止，并且Friend 节点会丢弃所有Friend Queue中的消息。
当收到Friend Subscription List Add message或者Friend Subscription List Remove 消息的时候，Friend Subscription List Confirm message 要在最小的ReceiveDelay毫秒和ReceiveDelay+ReceiveWindows毫秒之间发送。
当Friend节点收到的Friend Clear message并且LPNAddress字段是建立友谊关系的LPN节点，并且LPNCounter在定义的合适的范围内（3.6.5.6），friendship将会被终止，并且Friend 节点会丢弃所有的Friend Queue中的数据。
6.3.3 Friend management
如果Friend 节点收到LPN发过来的Friend Subscription List Add message，Friend节点会将message包含的地址列表添加到Friend Subscription List中并且给LPN一个Friend Subscription List Confirm message的回复，message中的TransactionNumber字段要设置成跟收到的Friend Subscription List Add message中的一样。
如果Friend 节点收到LPN发过来的Friend Subscription List Remove message，Friend节点会从Friend Subscription List中删除message中的地址列表信息，并且用Friend Subscription List Confirm给LPN一个确认回复，message中的TransactionNumber字段要设置成接受到的Friend Subscription List Remove message中的一样。
当接收到LPN节点发过来的Friend Poll message之后，Friend节点要在最小ReceiveDelay毫秒和ReceiveDelay+ReceiveWindows毫秒之间给LPN回复Friend Update message。
6.4 Low Power Feature
支持Low Power feature的节点必须满足三个条件：低功耗建立(Low Power establishment)、低功耗消息（Low Power messaging）、低功耗管理（Low Power management）。
所有的transport control message由LPN生成，并以Unsegmented Control message的形式发送，SRC字段设置为支持LPN feature特性节点的首元素的单播地址。
6.4.1 Low Power establishment
Low Power establishment operation用来在支持Lower Power feature节点和Friend feature节点之间建立friendship关系。
这个operation 通过发送Friend Request message开始的。
Friend Request message 需要设置TTL字段为0，并且DST字段设置为all-friends address（0xFFFD）。LPN节点要有个Low Power node counter（LPNCounter），这是一个初始值为0的两个字节的数据。如果发送Friend Request message之后并且建立了友谊关系，LPNCounter会派生friendship security material。每个Friend Request message发送之后，LPNCounter的值会被加1.
LPN发送Friend Request 消息100毫秒之后，要停留1s左右来listen有没有潜在的Friend节点发送过来的Friend Offer messages，然后可以从这些中选择一个合适的作为Friend节点来建立friendship关系。LPN节点可以选择接收Friend Offer或者继续监听其他的Friend Offer message作为比较。
如果没有可用的Friend Offer message，节点可以继续发送一个新的Friend Request message。两个连续的Friend Request消息之间的间隔要大于1.1秒。
如果要跟一个收到Friend Offer message的潜在的Friend建立关系，LPN要将Friend Sequence Number设置为0，并且要在收到这个Friend Offer消息之后的1s之内给Friend节点发送Friend Poll消息。如果收到了Friend Update message作为回复，那么友谊关系就建立起来了。
几次尝试之后，如果没有收到Friend Update message，LPN就会重新开始Low Power Establishment的操作。
Low Power Establishment operation多次失败的原因可能是Low Power node 不再具有有效的IV Index然后就需要走初始化IV Index Recovery 步骤（3.10.6）.一旦友谊关系建立之后，LPN就可以与Friend节点按照定义的Low Power messaging（3.6.6.4.2）进行通信，并且按照Low Power management（3.6.6.4.3）的管理方式来管理friendship。
6.4.2 Low Power messaging
Low Power management operation 用来管理Friend 节点中的subscription list。
Low Power node会发送Friend Subscription List Add消息给Friend节点，消息中包含LPN订阅的group adresses和virtual address的列表。这种类型的消息会发生在LPN订阅内容改变的任何时候。
Low Power node 会发送Friend Subscription List Remove 消息给Friend节点，消息中包含LPN不再需要订阅的group addresses和virtual addresses。这种类型的消息会发生在LPN订阅内容改变的任何时候。
开始的时候Low Power node设置TransactionNumber值为0.每一次发送新的Friend Subscription List Add 或者Friend Subscription List Remove 消息TransactionNumber都会加1， TransactionNumber 值要跟Friend Subscription List Confirm 消息的TransactionNumber字段匹配。
6.5 Examples of segmentation and reassembly （分段和重组消息举例）
segmentation（分段）和reassembly（重组）的行为定义在3.5.3.3和3.5.3.4，同样适用于发送给LPN或者从LPN中发送的segmented messages。唯一的区别是，传进LPN的所有消息（incoming messages），都依赖于Friend Queue，包括 segments、segment acknowledgements，Friend节点会替LPN acknowledge segmented transactions。
本章提供两个LPN的segmentation 和 reassembly的两个例子。
6.5.1 Incoming segmented message
下图是直接发给LPN的一个segmented message的例子，LPN接收到所有的segments消息之后将其重组，在每个点上，friend节点将segments放到Friend Queue之中，然后将其分发给LPN。在传输的中间过程中，一个节点发给LPN一个unsegmented消息，这个消息会独自处理。
6.5.2 Outgoing segmented message
下图是LPN发送一个segmented message的一个例子。LPN接收消息依赖于Friend Queue，同样也需要轮询来应答消息。中间过程中收到一个节点的unsgemented message，需要单独处理。注意，unsegmented message不需要 acknowledge。
7、 Heartbeat
Heartbeat 用来检测nodes是否还存在网络中，并且可以发现他们距离彼此有多远。
7.1 Functional overview
为了检测节点是都仍然活跃的存在于网络中，有必要收到这个节点的消息。向mesh网络中的每个节点发送消息已得到他们的回应是非常浪费资源的，所以可以将每个节点配置为周期性的发送消息。这种消息叫做Heartbeat message。
Heartbeat message有两个主要功能：第一是判断这个节点是否活跃的存在于网络中；第二是判断这个节点距离自己有多远。
Heartbeat message是周期性发送的，可以被Configuration Server Model进行配置。Heartbeat message可以仅仅发送几次也可以周期性的被发送。Heartbeat message可以配置上目的地址，推荐group address 用来作为Heartbeat message的目的地址，心跳消息也可以被配置指定的TTL字段。
当接收到Heartbeat message之后，就可以计算一些东西了。通过节点发送的Heartbeat messages可以判断出这个网络分发消息的稳定性。
每一个Heartbeat message在初始化的时候都被设置TTL字段。接收Heartbeat message的设备可以判断出这个消息被重传了几次，最大最小的跳数，以及整个网络的可靠性。
Heartbeat message 可以决定出最佳的TTL。
Heartbeat message 同样包含这个节点当前的features。
7.2 Publishing Heartbeat messages
Publishing Heartbeat message是被Heartbeat Publication state（4.2.17）控制的。当Heartbeat Publication Destination address设置为unassigned address或者Heartbeat Publication Count state设置为0x0000的时候，Heartbeat messages 不会被published。
Heartbeat messages的DST字段要被Heartbeat Publication Destination state设置，TTL字段要被Heartbeat Publication TTL state设置。（4.2.17.4）
周期性的发布Heartbeat messages要被Heartbeat Publication Count state使能（4.2.17.2）.每次发布Heartbeat message之后，如果Heartbeat Publication Count counter 小于0xFFFF，Heartbeat Publication Count Counter就会减1.counter在0x0000的时候会停止。当Heartbeat Publication Period state被配置为周期性发布的时候，第一个Heartbeat message就会被发布。第二个Heartbeat message会在几秒后发布，这个时间定义在Heartbeat Publication Period state中（4.2.17.3）.
触发发布Heartbeat message，是被Heartbeat Publication Feature state 使能的：
(1)、如果Relay bit设置为1，当node的Relay state改变时，Heartbeat message 会被发布。
(2)、如果Proxy bit设置为1，当node的GATT Proxy state改变时，Heartbeat message会被发布。
(3)、如果Friend bit设置为1，当节点的Friend state 改变时，Heartbeat message会被发布。
(4)、如果Low Power bit设置为1，当节点建立或终止友谊关系(Friendship)的时候Heartbeat message会被发布。
7.3 Receiving Heartbeat messages
接受Heartbeat messages是被Heartbeat Subscription state控制的（4.2.18）.
Heartbeat Subscription Period state是个递减计时器，用来计算接收Heartbeat message的剩余秒数。当这个定时器减到零的时候，接受Heartbeat message就会被禁掉了。
如果Heartbeat message 的SRC字段是Heartbeat Subscription Source state之外的其他值或者DST字段是Heartbeat Subscription Destination state的其他值，将不会被处理。
当收到Heartbeat message的时候，Heartbeat Subscription Count state 会增加。当达到0xFFFF的时候，计数器停止计数。
当收到Heartbeat message的时候，可以从这个消息中的InitTTL值和接收到的Network PDU 的TTL字段（称为RxTTL）来计算 跳数（hops），计算公式： hops = InitTTL - RxTTL + 1.
注意：如果直接收到消息（例如，InitTTL和接收到的Network PDU 的TTL字段相同），那么hops就是1.如果消息用最大长度路径传送，InitTTL 字段设置为0x7F，并且接收到的Network PDU TTL字段设置为0x01，因此hops是0x7F。
如果hops值比Heartbeat Subscription Min Hops state小，则Heartbeat Subscription Min Hops state的值要被重新设置。如果hops的值比Heartbeat Subscription Max Hops state要大，则Heartbeat Subscription Max Hops state的值要被重新设置。
拍桌子，画重点，看了文章觉得有所收获的，请扫描以下二维码，金额不限，您的鼓励是我继续奋斗的动力，感谢！！！
