Mesh Protocol

When specification content indicates that there are multiple alternatives to satisfy specification requirements, if one alternative is explained or illustrated in an example it is not intended to limit other alternatives that the specification requirements permit.

It is the goal of Bluetooth SIG that specifications are clear, unambiguous, and do not contain discrepancies. However, members can report any perceived discrepancy by filing an erratum and can request a test case waiver as appropriate.

The number of Access messages that need to be sent to set up complicated nodes can easily be more than 100. Each response that acknowledges an Access message is delayed by a random value from 20 to 50 milliseconds (see Section 3.7.3). For 100 Access messages, this recommendation introduces an average delay of 3.5 seconds. Additional delay is introduced by round-trip time for each request and response message.

To speed up the configuration of a node on a mesh network, aggregation of Access messages is introduced in this specification. The aggregation of messages mechanism can significantly lower configuration time for a newly provisioned device, by reducing the number of Access messages that need to be acknowledged and the round-trip time for each request and response message.

Encrypting and authenticating messages at the upper transport layer and network layer is designed to secure communications within the mesh network against eavesdroppers and malicious attacks. Each layer maintains distinct keys to allow separation between application and network entities.

Splitting application keys from network keys enables secure relay transmission of messages: Relay nodes can authenticate messages at network level without accessing the application data. For example, a light bulb acting as a Relay node should not be able to unlock doors.

The application key is used directly along with an associated application key identifier (AID) that is used in certain contexts to identify the application used. However, the network key is always used through a key derivation function to generate other keys that are used directly. Examples of such keys include EncryptionKey and PrivacyKey. This allows a single network key to be changed and all the associated values that are derived from that key to be quickly derived. As with the application key, the network key is also used to derive a network key identifier (see Section 3.9.6).

The security model defines three separate keys (the device key (DevKey), the application key (AppKey), and the network key (NetKey)) to secure the messages. When a node is given a key, it is authorized to use that key. A key that is shared between multiple nodes enables any node with that key to transmit and receive messages using that key.

The device key facilitates confidentiality and authentication of key material between a Configuration Manager and a single node. The application key facilitates confidentiality and authentication of application data sent between intended nodes. The network key facilitates privacy, confidentiality, and authenticity of network messages. A node may have knowledge of a single device key, multiple application keys, and multiple network keys.

A device key is similar to an application key in that it is designed to secure information sent by an application in the upper transport layer. However, a device key is known only by the Provisioner, the Configuration Manager, and the single node. The Configuration Manager knows the device keys for all nodes, which allows the Configuration Manager to securely distribute keys to a set of nodes by sending these keys secured with the device key for each individual node, allowing a key distribution to be targeted at only those nodes that need to know. Use of a device key is designed to protect against the “trash-can” attack (a technique to retrieve information from a disposed device that can be used to carry out an attack on a network) by allowing the distribution of new network and application keys to selected devices only.

The network key and the device keys for the nodes on the network constitute the ownership of the network. Ownership of the network may be changed by executing any of the Node Provisioning Protocol Interface procedures for every node on the network (see Section 3.11.8) and executing the Key Refresh procedure (see Section 3.11.4).

An application key can only be used with a single network key. This implies that a network key has one or more application keys associated with it. This association is known as the key binding.

The granularity of access layer security is on a per-model basis. Each server model has a set of application keys bound to it, defining the possible keys that should be used to encrypt and authenticate a message to be processed by the model. This allows multiple entities to operate certain node functions. Up to 251 application keys can be bound to a model. For example, a Light Lightness Server Model has three keys bound to it because the admin, user, and guest can all switch on a light. However, only the admin can configure the lamp, so the Configuration Server Model has only the admin application key bound to it.

The network security model utilizes a privacy mechanism called obfuscation that utilizes the Advanced Encryption Standard (AES) to encrypt the source address, sequence numbers, and other header information using a PrivacyKey. The intent for obfuscation is to make tracking nodes more difficult.

A node may have multiple network or application keys.

By using a key identifier, it is possible to identify which subset of keys are used to secure the message. For example, instead of checking 20 keys, a node may only need to check two keys that have the same least significant bits of the key identifier. If a message is received with a key identifier that is not known, then the node can immediately discard it.

The key identifier is generated from the network or application key using a key derivation function.

This specification defines a separate identifier for the network key and application key. A network key identifier is transmitted in each Network PDU using a 7-bit value, while the AID is transmitted in each Lower Transport PDU using a 6-bit value.

A Network PDU contains a 24-bit sequence number that allows an element to transmit 16,777,216 Network PDUs. The sequence number is used in the security nonce to provide uniqueness; therefore, the sequence number cannot wrap. If an element is transmitting a new message at 2 Hz, then these sequence numbers would be exhausted after 97 days. To enable a mesh network to operate for longer periods of time than the sequence number space allows, an additional 4-octet value called the IV Index is defined that is included in the security nonce. For example, using the same 2 Hz message frequency would measure the lifetime of the network using the IV Index in billions of years.

To enable a gradual transition from one IV Index to the next, each Network PDU includes the least significant bit of the IV Index that was used to transmit the message. A node can also use an IV Update procedure to signal to peer nodes that it is updating the IV Index. This procedure takes a minimum of eight days to transition from the old IV Index to the new IV Index, thereby limiting the frequency that a node can transmit messages to 24 Hz. However, a node should not send more than 100 Network PDUs in any 10 second window, so this would typically take approximately 19 days to exhaust.

When multiple-octet values are defined as sent in big-endian (also known as “network byte order”), the conventions in this section apply. For example, the value 0x123456 shall be transmitted as 0x12, 0x34, and 0x56 (most significant octet first).

When multiple-octet values are defined as sent in little-endian, the conventions in this section apply. For example, the value 0x123456 shall be transmitted as 0x56, 0x34, and 0x12 (least significant octet first).

An unassigned address is an address in which the element of a node has not been configured yet or no address has been allocated. The unassigned address shall have the value 0x0000 as shown in Figure 3.4 below. This may be used, for example, to disable message publishing of a model by setting the publish address of a model to the unassigned address.

Figure 3.4. Unassigned address format

An unassigned address shall not be used in the SRC field or the DST field of a Network PDU.

A unicast address is a unique address allocated to each element. A unicast address has bit 15 set to 0. The unicast address shall not have the value 0x0000, and therefore can have any value from 0x0001 to 0x7FFF inclusive as shown in Figure 3.5 below.

A unicast address is allocated to each element of a node for a term of the node on the network. The address allocation for the initial term is performed by a Provisioner during provisioning as described in Section 5.4.2.5. The address may be changed by executing the Node Address Refresh procedure (see Section 3.11.8.5) or the Node Composition Refresh procedure (see Section 3.11.8.6). The address may be unallocated by a Provisioner to allow the address to be reused using the procedure defined in Section 3.11.7.

Figure 3.5. Unicast address format

A unicast address shall be used in the SRC field of a Network PDU and may be used in the DST field of a Network PDU. A Network PDU sent to a unicast address shall be processed by at most one element.

3.4.2.2.2. Unicast address range list

A message may contain multiple unicast address range values. For example, a unicast address range list can be used to communicate all the element addresses of Low Power nodes of a Friend node.

The values shall be serialized as shown in Figure 3.6. The length of each unicast address range value is either 2 or 3 octets depending on the LengthPresent field value within each unicast address range value.

Figure 3.6. Unicast address range list example

A virtual address represents a set of destination addresses. Each virtual address logically represents a Label UUID, which is a 128-bit value that does not have to be managed centrally. One or more elements may be programmed to publish or subscribe to a Label UUID. The Label UUID is not transmitted and shall be used as the Additional Data field of the message integrity check value in the upper transport layer (see Section 3.9.7.1).

The virtual address is a 16-bit value that has bit 15 set to 1, bit 14 set to 0, and bits 13 to 0 set to the value of a hash. This hash is a derivation of the Label UUID such that each hash represents many Label UUIDs.

When an Access message is received to a virtual address that has a matching hash, each corresponding Label UUID is used by the upper transport layer as additional data as part of the authentication of the message until a match is found.

Transport Control messages cannot use virtual addresses.

Label UUIDs may be generated randomly as defined in [6]. A Configuration Manager may assign and track virtual addresses; however, two devices can also create a virtual address using some out-of-band (OOB) mechanism. Unlike group addresses, these could be agreed upon by the devices involved and would not need to be registered in the centralized provisioning database, as they are unlikely to be duplicated.

A disadvantage of virtual addresses is that a multi-segment message is required to transfer a Label UUID to a publishing or subscribing node during configuration.

A virtual address can have any value from 0x8000 to 0xBFFF as shown in Figure 3.7 below.

Figure 3.7. Virtual address format

A group address is an address that is programmed into zero or more elements. A group address has bit 15 set to 1 and bit 14 set to 1, as shown in Figure 3.8 below. Group addresses in the range 0xFF00 through 0xFFFF are reserved for Fixed Group addresses (see Table 3.7), and addresses in the range 0xC000 through 0xFEFF are generally available for other usage.

Figure 3.8. Group address format

A group address shall only be used in the DST field of a Network PDU. A Network PDU sent to a group address shall be delivered to all the instances of models that subscribe to this group address.

There are two types of group addresses; those that can be assigned dynamically and those that are fixed. The fixed group addresses are defined in Table 3.7 below.

This specification does not define any special behaviors related to values from 0xFF00 to 0xFFF8, all-ipt-border-routers, and all-ipt-nodes fixed group addresses.

The IVI field contains the least significant bit of the IV Index used in the nonce to authenticate and encrypt this Network PDU (see Section 3.9.2.11).

The NID field contains a 7-bit network identifier that allows for an easier lookup of the EncryptionKey and PrivacyKey used to authenticate and encrypt this Network PDU (see Section 3.9.6.3.1).

The NID value is derived from the network key in conjunction with the EncryptionKey and PrivacyKey. It is derived differently for Network PDUs using managed flooding security material, Network PDUs using directed security material, and Network PDUs using friendship security material (see Section 3.9.6.3.1).

The CTL field is a 1-bit value that is used to determine if the Network PDU is part of a Transport Control message or an Access message, as illustrated in Table 3.11.

If the CTL field is set to 0, the NetMIC is a 32-bit field and the Lower Transport PDU contains an Access message.

If the CTL field is set to 1, the NetMIC is a 64-bit field and the Lower Transport PDU contains a Transport Control message.

The TTL field is a 7-bit field. The TTL field values are defined in Table 3.12.

The initial value of this field is set by the transmitting layer (lower transport layer, upper transport layer, access, foundation model, model) or an application and used by the network layer when operating as a Relay node or as a Directed Relay node.

The use of the TTL value of zero allows a node to transmit a Network PDU that it knows will not be relayed, and therefore the receiving node can determine that the sending node is a single radio link away. The use of a TTL value of one or larger cannot be used for such a determination.

The SEQ field is a 24-bit integer. The combined SEQ field, IV Index field, and SRC field (see Section 3.4.4.6) shall be a unique value for each new Network PDU that this element originates.

The SRC field is a 16-bit value that identifies the element that originated this Network PDU. This address shall be a unicast address.

The SRC field is set by the originating element and untouched by nodes operating as a Relay node or as a Directed Relay node.

The DST field is a 16-bit value that identifies the element or elements that this Network PDU is directed towards. This address shall be a unicast address, a group address, or a virtual address.

The DST field is set by the originating node and is untouched by the network layer in nodes operating as a Relay node or as a Directed Relay node.

The TransportPDU field, from a network layer point of view, is a sequence of octets of data. When the CTL field value is 0, the TransportPDU field shall be a maximum of 128 bits. When the CTL field value is 1, the TransportPDU field shall be a maximum of 96 bits.

The TransportPDU field is set by the originating lower transport layer and shall not be changed by the network layer.

The NetMIC field is a 32-bit or 64-bit field (depending on the value of the CTL field) that authenticates that the DST and TransportPDU fields have not been changed.

When the CTL field value is 0, the size of the NetMIC field shall be 32 bits. When the CTL field value is 1, the size of the NetMIC field shall be 64 bits.

The NetMIC field value is set by the network layer at each node that transmits or relays this Network PDU.

The interface input filter determines whether an incoming Network PDU is delivered to the network layer for further processing or it is dropped.

A feature or a protocol in this specification may define an input filter. For example, the Proxy Protocol defines filters (see Section 6.4).

The input filter of the interface connected to the GATT bearer shall drop all Network PDUs that have been secured using the friendship security credentials.

The interface output filter determines whether an outgoing Network PDU is delivered to a bearer or it is dropped.

A feature or a protocol in this specification may define an output filter. For example, the Proxy Protocol defines filters (see Section 6.4).

The output filter of the interface connected to advertising or GATT bearers shall drop all Network PDUs with the TTL field value set to 1 unless they contain a Network PDU that is tagged as relay.

The output filter of the interface connected to the GATT bearer shall drop all Network PDUs secured using the friendship security credentials.

A Local Network Interface allows sending Network PDUs between elements within the same node.

A node shall implement a Local Network Interface.

Upon receiving a Network PDU by a Local Network Interface, the Network PDU shall be delivered to all elements of the node.

When transmitting a Network PDU that is tagged as friendship, the Advertising Bearer Network Interface shall transmit the Network PDU over the advertising bearer only once.

When transmitting a Network PDU that is not tagged as friendship, the Advertising Bearer Network Interface shall transmit the Network PDU over the advertising bearer using the following configuration:

When transmitting a Network PDU that is tagged as relay, the start time of the transmission should be randomized by a small interval to avoid collisions between multiple relays that have received the Network PDU at the same time. If the DST field value of the Network PDU is the all-directed-forwarding-nodes fixed group address (see Section 3.4.2.4), the start time of the transmission should be additionally randomized by an interval from 0 to 100 milliseconds.

The Relay feature is used to relay/forward Network PDUs received by a node over the advertising bearer. This feature is optional and if supported can be enabled and disabled. If the Proxy feature is supported, then both GATT and advertising bearers shall be supported.

The Proxy feature is used to relay/forward Network PDUs received by a node between GATT and advertising bearers. This feature is optional and if supported can be enabled and disabled. When this feature is supported, the Advertising with Network ID (see Section 7.2.2.2.2) shall be supported and the Mesh Proxy Service (see Section 7.2) shall be contained in the GATT Server on a node; otherwise, the Mesh Proxy service may be contained in the GATT Server.

A Network PDU is delivered from a bearer to the network layer via a network interface. The interface shall apply filtering rules defined by its input filter (see Section 3.4.5.1). If the Network PDU passes through the input filter, it is delivered to the network layer for further processing.

Upon receiving a Network PDU, the node shall check whether the NID field value matches one or more known NIDs. If the NID field value does not match a known NID, then the Network PDU shall be ignored. If the NID field value matches a known NID, the node shall attempt to authenticate the Network PDU using the security credentials derived from each known network key that matched. If the Network PDU does not authenticate against any known network key, then the Network PDU shall be ignored. If the Network PDU does authenticate against a network key, and the SRC and DST fields are considered valid (see Section 3.4.3), and an entry corresponding to the Network PDU is not in the Network Message Cache (see Section 3.4.6.5), then the Network PDU shall be processed by the lower transport layer.

When the Network PDU is processed by the lower transport layer, and the TTL field has a value of 2 or greater, and the destination is not a unicast address of an element on this node, then the Network PDU shall be evaluated against retransmission conditions for incoming Network PDUs as defined in Table 3.13. For a Network PDU, there may be more than one matching row in Table 3.13. If there is no row that matches the retransmission conditions, then the Network PDU shall not be retransmitted.

For each row in Table 3.13, if the Network PDU is delivered from the bearer identified in the Inbound Bearer column, and is secured using the security material identified in the Inbound Security Material column, and all conditions in the Conditions column are met, then the actions in the Additional Actions column, if present, shall be executed, and the Network PDU shall be retransmitted to network interface(s) identified by the Outbound Bearers column using the security material identified in the Outbound Security Material column. The IV Index used when retransmitting the Network PDU shall be the same IV Index as in the received Network PDU. The TTL field value of the retransmitted Network PDU shall be equal to the TTL field value of the received Network PDU decremented by 1. The network key used when retransmitting the Network PDU depends on whether the node is a Subnet Bridge node.

If the node is not a Subnet Bridge node, the network key used when retransmitting the Network PDU shall be the same network key used to secure the received Network PDU.

If the node is a Subnet Bridge node, the node shall check all the Bridging Table state entries to determine whether the Network PDU is to be bridged to different subnets.

For a given Bridging Table state entry (see Section 4.2.42), the Network PDU shall be retransmitted using the NetKey identified by NetKeyIndex2 of the entry if all the following conditions are met:

The Network PDU shall be retransmitted using the NetKey identified by NetKeyIndex1 of the Bridging Table state entry if all the following conditions are met:

The following paragraphs define the requirements associated with each column of Table 3.13.

Inbound Bearer. The entries in the Inbound Bearer column of Table 3.13 identify the type of bearer from which the Network PDU was delivered:

Inbound Security Material. The entries in the Inbound Security Material column of Table 3.13 identify the type of security material used to secure the incoming Network PDU (see Section 3.9.6.3.1):

Conditions.Table 3.14 defines the requirements for the conditions in the Conditions column of Table 3.13.

Additional Actions. The entries in the Additional Actions column of Table 3.13 define actions, if any, to be taken in addition to retransmitting the inbound Network PDU:

Outbound Bearers. The entries in the Outbound Bearers column of Table 3.13 define the network interfaces to which the Network PDU will be retransmitted:

Outbound Security Material. The entries in the Outbound Security Material column of Table 3.13 identify the type of security material used to secure the retransmitted Network PDU:

Figure 3.10 illustrates an example of processing steps for an incoming Network PDU.

Figure 3.10. Example of Network PDU processing steps

Network PDUs are transmitted by an element in the context of a mesh subnet, which is identified by a unique network key.

The IVI field shall be set to the least significant bit of the IV Index value being used to transmit for the mesh subnet.

The NID field shall be set to the NID value associated with the EncryptionKey and PrivacyKey used for encryption and obfuscation.

The CTL field shall be set by a higher layer.

The TTL field shall be set by a higher layer.

The SEQ field shall be set by the network layer to the sequence number of the element. The sequence number shall then be incremented by one for every new Network PDU.

The SRC field shall be set by the network layer to the unicast address of the element that is sending this Network PDU.

The DST field shall be set to a unicast address, a group address, or a virtual address to identify the destination element or elements and shall be set by the lower transport, upper transport, or access layer.

The TransportPDU field shall be set by a higher layer.

The NetMIC field shall be set as defined in Section 3.9.7.2.

If the Network PDU security material is not set by the network layer or any higher layer, the Network PDU shall be secured using the managed flooding security credentials.

If the Network PDU is tagged with the immutable-credentials tag (see Section 3.7.3.1), and the Network PDU is secured using the friendship security credentials, the Network PDU shall be delivered to the advertising bearer network interface.

If the Network PDU is tagged with the immutable-credentials tag (see Section 3.7.3.1), and the Network PDU is not secured using the friendship security credentials, the Network PDU shall be delivered to all network interfaces.

If the Network PDU is not tagged with the immutable-credentials tag, and directed forwarding functionality is supported and enabled in the subnet over which the Network PDU is transmitted, and the DST field is set to a unicast address, and a path from the SRC field value to the DST field value exists (see Section 3.6.8.5.1), then the Network PDU shall use the directed security credentials (see Section 3.9.6.3.1) and shall be delivered to all network interfaces connected to the bearers indicated in all the Forwarding Table entries corresponding to the path (see Section 3.6.8.5.1).

If the Network PDU is not tagged with the immutable-credentials tag, and directed forwarding functionality is supported and enabled in the subnet over which the Network PDU is transmitted, and the DST field is set to a group address or a virtual address, and a path from the SRC field value to the DST field value exists (see Section 3.6.8.5.1), and the Path_Not_Ready field (see Section 4.2.29.2) in the Forwarding Table entry for the path is set to 0, then the Network PDU shall use the directed security credentials (see Section 3.9.6.3.1) and shall be delivered to all network interfaces connected to the bearers indicated in all the Forwarding Table entries corresponding to the path (see Section 3.6.8.5.1).

Each network interface shall apply filtering rules defined by its output filter (see Section 3.4.5.2). If the Network PDU passes through the output filter, it shall be transmitted on a bearer.

In order to reduce unnecessary security checks and excessive relaying, a node shall include a Network Message Cache that stores details of all recently seen Network PDUs. If a Network PDU is received that corresponds to an entry already in the Network Message Cache, then the Network PDU shall not be processed (i.e., it shall be immediately discarded). If a Network PDU is received and that Network PDU has no corresponding entry in the Network Message Cache, then the Network PDU can be processed (e.g., checked against network security), and if it is a valid Network PDU, a corresponding entry for it shall be added in the Network Message Cache.

The node is not required to store the entire Network PDU contents in a cache entry and may store only a part of it for tracking, such as values for the SRC and SEQ fields, or others. However, this is left to the implementation as long as the condition of not processing the same Network PDU more than once is achieved within the limits of the device capabilities.

Because the TTL field value is decremented when a Network PDU is relayed, a node shall not consider the TTL field value when determining whether the Network PDU already has a corresponding cache entry. Also, because the NetMIC field value is derived using the TTL field value, a node shall not consider the NetMIC field value when determining whether the Network PDU already has a corresponding cache entry.

When the Network Message Cache is full and an entry for an incoming new Network PDU needs to be cached, an entry for the incoming new Network PDU shall replace the entry for the oldest Network PDU that is already in the Network Message Cache.

The Network Message Cache shall be able to store entries for at least two Network PDUs, although it is highly recommended to have a Network Message Cache size appropriate to the anticipated network density. The details of the incoming Network PDU processing procedure are left to the implementation.

The Private Proxy functionality is used to relay/forward Network PDUs received by a node between GATT and advertising bearers. This functionality is optional and if supported can be enabled and disabled. When this functionality is supported, the Proxy feature (see Section 3.4.6.2), the Private Network Identity advertising (see Section 7.2.2.2.4), the Mesh Private Beacon Server model (see Section 4.4.11), and Mesh Private beacons (see Section 3.10.4) shall be supported.

The Node Identity functionality is used to exchange Network PDUs between two nodes connected via GATT. This functionality is optional. When this functionality is supported, the Mesh Proxy Service (see Section 7.2) shall be exposed and the Advertising with Node Identity (see Section 7.2.2.2.3) shall be supported.

The Private Node Identity functionality is used to exchange Network PDUs between two nodes connected via GATT. This functionality is optional. When this functionality is supported, the Node Identity functionality (see Section 3.4.6.7), the Mesh Private Beacon Server model (see Section 4.4.11), and the Advertising with Private Node Identity (see Section 7.2.2.2.5) shall be supported.

The On-Demand Private Proxy functionality is used to start Advertising with Private Network Identity (see Section 7.2.2.2.4) using the Solicitation PDU (see Section 6.9.1). This functionality is optional. When this functionality is supported, the Private Proxy functionality (see Section 3.4.6.6), On-Demand Private Proxy Server model (see Section 4.4.13), Solicitation PDU RPL Configuration Server model (see Section 4.4.17), and Solicitation PDU with Identification Type set to Proxy Solicitation with Replay Protection (see Section 6.9.1) shall be supported.

The Unsegmented Access message is used to transport an Upper Transport Access PDU that fits into a single Network PDU. Figure 3.11 shows an illustration of an Unsegmented Access message, and Table 3.17 shows the fields for this message.

Figure 3.11. Unsegmented Access message

The SEG field shall be set to Unsegmented Message.

The AKF and AID fields shall be set by the upper transport layer according to the application key or device key used to encrypt the Access message (see Section 3.6.4.1).

The Upper Transport Access PDU is supplied by the upper transport layer.

This message does not have a SZMIC field. The TransMIC field in the upper transport layer shall be a 32-bit field, as if the SZMIC field has the value 0.

The Segmented Access message is used to transport a complete Upper Transport Access PDU or a segment of an Upper Transport Access PDU. Figure 3.12 shows an illustration of a Segmented Access message, and Table 3.18 shows the fields for this message.

Figure 3.12. Segmented Access message

The SEG field shall be set to Segmented Message.

The SZMIC field indicates the size of the TransMIC field in the Upper Transport Access PDU. If the SZMIC field is set to 0, the TransMIC is a 32-bit field. If the SZMIC field is set to 1, the TransMIC is a 64-bit field.

The AKF and AID fields shall be set by the upper transport layer according to the application key or device key used to encrypt the Access message (see Section 3.6.4.1).

The SeqZero field shall be set by the upper transport layer.

The SegO field shall be set to the segment number (zero-based) of the segment m of this Upper Transport PDU.

The SegN field shall be set to the last segment number (zero-based) of this Upper Transport PDU.

The Segment m field, with the segment number m, shall be set to the subset of octets from the Upper Transport Access PDU. For all segments except the last segment, Segment m is octet 12*m to 12*m+11. In the last segment, Segment m is octet 12*m through the end of the message.

Every Segmented Access message for the same Upper Transport Access PDU shall have the same values for AKF, AID, SZMIC, SeqZero, and SegN fields.

The Unsegmented Control message is used to transport either a Segment Acknowledgment message or an Upper Transport Control PDU. Figure 3.13 shows an illustration of an Unsegmented Control message, and Table 3.19 shows the fields for this message.

Figure 3.13. Unsegmented Control message

The SEG field shall be set to Unsegmented Message.

The Opcode field values are defined in Table 3.20 and shall be set to the appropriate opcode defined in the Assigned Numbers document [4].

The Parameters field is set according to the requirements of the opcode.

3.5.2.3.1. Segment Acknowledgment message

The Segment Acknowledgment message is used by the lower transport layer to acknowledge segments received by a peer lower transport layer. The Segment Acknowledgment message is illustrated in Figure 3.14 and defined in Table 3.21.

Figure 3.14. Segment Acknowledgment message

Field	Size (bits)	Description	Req.
SEG	1	Set to Unsegmented Message	M
Opcode	7	Set to 0x00	M
OBO	1	Friend on behalf of a Low Power node	M
SeqZero	13	SeqZero of the Upper Transport PDU	M
RFU	2	Reserved for Future Use	M
AckedSegments	32	Acknowledgment for segments	M

Table 3.21. Segment Acknowledgment message format

The SEG field shall be set to Unsegmented Message.

The Opcode field shall be set to 0x00.

The OBO field shall be set to 0 by a node that is directly addressed by the received message and shall be set to 1 by a Friend node that is acknowledging this message on behalf of a Low Power node.

The SeqZero field shall be set to the value of the SeqZero field of the upper transport layer message being acknowledged.

The AckedSegments field shall be set to indicate the segments received. The least significant bit, bit 0, shall represent segment 0; and the most significant bit, bit 31, shall represent segment 31. If bit n is set to 1, then segment n is being acknowledged. If bit n is set to 0, then segment n is not being acknowledged. Any bits for segments larger than the SegN field value of the upper transport layer message being acknowledged shall be set to 0 and ignored upon receipt.

If the received segments were sent with the TTL field set to 0, it is recommended that the corresponding Segment Acknowledgment message is sent with the TTL field set to 0.

The Segmented Control message is used to transport a complete Upper Transport Control PDU or a segment of an Upper Transport Control PDU when the Upper Transport Control PDU will not fit into a single Network PDU. Figure 3.15 shows an illustration of a Segmented Control message, and Table 3.22 shows the fields for this message.

Figure 3.15. Segmented Control message

The SEG field shall be set to Segmented Message.

The Opcode field shall be set by the upper transport layer as defined in Table 3.20 to indicate the format of the Parameters field. The value 0x00 is Reserved and shall not be transmitted and ignored upon receipt.

The SeqZero field shall be set by the upper transport layer.

The SegO field shall be set to the segment number (zero-based) of the Upper Transport PDU contained within this message.

The SegN field shall be set to the last segment number (zero-based) of this Upper Transport PDU.

The Segment m field shall be set to the subset of octets from the Upper Transport Control PDU. Segment m is octet 8*m to 8*m+7, except for the last segment where it is octet 8*m to the end of the message.

Every Segmented Control message for the same Upper Transport Control PDU shall have the same values for the Opcode, SeqZero, and SegN fields.

Segmentation is performed by the lower transport layer of the transmitting node. The lower transport layer checks if an Upper Transport PDU fits into a single Lower Transport PDU. If the Upper Transport PDU fits, it is sent in a single Lower Transport PDU. If the Upper Transport PDU doesn’t fit, the lower transport layer divides the Upper Transport PDU into two or more Lower Transport PDUs.

Delivery of a segmented message is acknowledged by the lower transport layer of the receiving node. Delivery of an unsegmented message is not acknowledged. An Upper Transport PDU that fits into one Lower Transport PDU can be sent as a single-segment segmented message when acknowledgment by the lower transport layer is required.

Example: Using a single-segment segmented message can decrease the air traffic, for example, in a situation when a long multi-segment message (e.g., an Upper Transport PDU which was divided into many Lower Transport PDUs) has been transmitted, but the application acknowledgment message sent as a response to this multi-segment message was lost. Sending the application acknowledged message as a single segmented message can improve the reliability of delivery and can remove the risk associated with retransmitting the whole, long multi-segment message.

Each segment of an Upper Transport Access PDU shall be 12 octets long with the exception of the last segment, which may be shorter.

Each segment of an Upper Transport Control PDU shall be 8 octets long with the exception of the last segment, which may be shorter.

Example: When using a 32-bit TransMIC field, if an Upper Transport Access PDU is 42 octets long, then the first 12 octets, octets 0 to 11, are in segment 0; the second set of 12 octets, octets 12 to 23, are in segment 1; the third set of 12 octets, octets 24 to 35, are in segment 2; and the remaining 6 octets, octets 36 to 41, are in segment 3.

Example: If an Upper Transport Control PDU is 42 octets long, then the first 8 octets, octets 0 to 7, are in segment 0; the second set of 8 octets, octets 8 to 15, are in segment 1; the third set of 8 octets, octets 16 to 23, are in segment 2; the fourth set of 8 octets, octets 24 to 31, are in segment 3; the fifth set of 8 octets, octets 32 to 39, are in segment 4; and the remaining 2 octets, octets 40 to 41, are in segment 5.

Each segment of an Upper Transport PDU is identified by the SegO field value. The total number of segments is identified by the SegN field value. The SegO field value of the first segment equals 0. The SegO field value of the last segment equals the SegN field value.

Lower Transport PDUs derived from the same Upper Transport PDU are linked together by the common SeqAuth value. The SeqAuth value is composed of the IV Index and the sequence number of the first segment. The size of the SeqAuth value is 7 octets, where the IV Index is the four most significant octets and the sequence number is the three least significant octets. All Lower Transport PDUs from the same Upper Transport PDU shall be sent using the same IV Index from the common SeqAuth.

The least significant 13 bits of the SeqAuth value constitute the SeqZero field value. The SeqZero field is included in the segmented message and Segment Acknowledgment message to identify the Upper Transport PDU. Upon reassembling a complete Upper Transport PDU from the segments, the SeqAuth value can be retrieved from the IV Index, SeqZero, and SEQ fields included in any of the segments. The common SeqAuth value is the largest SeqAuth value for which the SeqZero field value is between SEQ – 8191 and SEQ inclusive, and the IV Index is the same.

Example: If the SEQ field value of a received message was 0x647262, the IV Index was 0x58437AF2, and the received SeqZero field value was 0x1849, then the SeqAuth value is 0x58437AF2645849.

Example: If the SEQ field value of a received message was 0x647262 and the received SeqZero field value was 0x1263, then the SeqAuth value is 0x58437AF2645263. For an Upper Transport PDU, the SeqAuth value is used to identify it.

Because of the limited size of the SeqZero field, it is not possible to send a segmented message when the SEQ field value is 8192 greater than the SeqAuth value. If a segmented message has not been acknowledged by the time that the SEQ field value is 8192 greater than the SeqAuth value, then the transmission of the Upper Transport PDU shall be canceled. Lower Transport PDUs are delivered to the network layer.

Reassembly is performed by the lower layer of the receiving node. When the Low Power node feature is in use, reassembly is performed by a Friend node and the Low Power node does not send any Segment Acknowledgment messages.

Upon receiving a segment from a Segmented message, the lower transport layer retrieves the SeqAuth value from the IV Index, SeqZero, and SEQ fields of this segment to check if the Upper Transport PDU has already been received.

The lower transport layer stores upcoming segments to complete the whole Upper Transport PDU. The value of the SegO field is used to determine the offset of the Lower Transport PDU within the Upper Transport PDU. The maximum size of the complete Upper Transport PDU is determined by the value of the SegN field and the size of the segment.

The lower transport layer sends Segment Acknowledgment messages to either report missing segments or report complete delivery of the Upper Transport PDU.

When all segments of the Upper Transport PDU for a given SeqAuth have been received, the Upper Transport PDU is delivered to the upper transport layer.

This section only applies when the Low Power feature is not in use.

The lower transport layer stores one or more pairs of values, consisting of an AckedSegments value, which indicates segments that have already been received for a particular SeqAuth, and a Sequence Authentication value. Each such pair is associated with a source address and a destination address. The initial value for the AckedSegments is a value that indicates that no segments have been received. The initial value for the Sequence Authentication value is 0.

When the lower transport layer receives a segment of a segmented message, it shall process the segment message against the conditions in Table 3.24. Conditions are evaluated one by one starting from the first line in the table. When the condition is met, the processing ends with the Processing Result corresponding to the value in the Condition column.

When the Processing Result is Message Rejected and the message is destined to a unicast address, the lower transport layer shall respond with a Segment Acknowledgment message with the AckedSegments field set to 0x00000000.

When the Processing Result is First Segment and the destination is a group address or a virtual address, the reassembly of a new segmented message is initiated. If another reassembly is pending for the same source address and for the same destination address, the pending reassembly shall be discarded and the SAR Discard timer shall be stopped. The lower transport layer shall set the Sequence Authentication value to the SeqAuth derived from this message. Then, the lower transport layer shall set the AckedSegments value for this SeqAuth to indicate that only this segment has been received and shall start the SAR Discard timer for this SeqAuth from the initial value. The initial value of the SAR Discard timer is the discard timeout value indicated by the SAR Discard Timeout state (see Section 4.2.49.4).

When the Processing Result is First Segment and the destination is a unicast address, the reception of a new segmented message is initiated. If another reassembly is already pending for the same source address and for the same destination address, the pending reassembly shall be discarded and the SAR Discard timer and SAR Acknowledgment timer shall be stopped. The lower transport layer shall set the Sequence Authentication value to the SeqAuth derived from this message. The lower transport layer shall set the AckedSegments value for this SeqAuth to indicate that only this segment has been received and shall start the SAR Discard timer and SAR Acknowledgment timer for this SeqAuth from the initial values. The initial value of the SAR Discard timer is the discard timeout value indicated by the SAR Discard Timeout state (see Section 4.2.49.4). The initial value of the SAR Acknowledgment timer is calculated using the following formula:

The acknowledgment delay increment value and the segment reception interval value are indicated by the SAR Acknowledgment Delay Increment state (see Section 4.2.49.2) and the SAR Receiver Segment Interval Step state (see Section 4.2.49.5), respectively.

When the Processing Result is Next Segment and the destination is a group address or a virtual address, the lower transport layer shall store the received segment, shall start the SAR Discard timer from the initial value, and shall set the AckedSegments value for the SeqAuth derived from this message to indicate that the segment identified by the SegO field has been received.

When the Processing Result is Next Segment and the destination is a unicast address, the lower transport layer shall store the received segment, shall start the SAR Acknowledgment timer and the SAR Discard timer from the initial values, and shall set the AckedSegments value for the SeqAuth derived from this message to indicate that the segment identified by the SegO field has been received.

When the Processing Status is SeqAuth Error or Repeated Segment, the lower transport layer shall ignore the message.

When the Processing Result is Most Recent SeqAuth, the lower transport layer shall send a Segment Acknowledgment message with the AckedSegments field set to indicate that all segments have already been delivered for that SeqAuth. The lower transport layer shall not send more than one Segment Acknowledgment message for the same SeqAuth in a period of:

The acknowledgment delay increment and the segment reception interval are indicated by the SAR Acknowledgment Retransmissions Interval state and the SAR Receiver Segment Interval Step state (see Section 4.2.49.5), respectively.

When the Processing Result is Last Segment, the transfer of the segmented message is complete. The lower transport layer shall send a Segment Acknowledgment message with the AckedSegments field set to indicate that all segments have been delivered for the Sequence Authentication value. The Segment Acknowledgment message shall use the same NetKey as the first received segment of the segmented message, and the DST field shall have the same value as the SRC field of the first received segment of the segmented message. The lower transport layer shall stop the SAR Discard timer and the SAR Acknowledgment timer and shall send the reassembled message to the upper transport layer. The lower transport layer shall store the SeqAuth and the AckedSegments value for complete transactions to be able to acknowledge a transaction when repeated segments are received. The values for the most recent transaction shall be stored, and an implementation may store the values for other recent transactions. The number of additional transactions for which values are stored is an implementation detail.

If the segments are Segmented Access messages, then the reassembled message shall be processed as defined in Section 3.6.4.2.

If the segments are Segmented Control messages, then the reassembled message shall be processed as defined in Section 3.6.5.

When the SAR Acknowledgment timer expires, the lower transport layer shall send a Segment Acknowledgment message with the AckedSegments field set to the AckedSegments value for the identified SeqAuth to indicate the segments have been delivered (see Section 3.5.2.3.1). The Segment Acknowledgment message shall use the same NetKey as the first received segment of the segmented message, and the DST field shall have the same value as the SRC field of the first received segment of the segmented message.

If the number of segments in the transmission indicated by the value of SegN field is greater than the value of the SAR Segments Threshold state (see Section 4.2.49.1), the lower transport layer shall retransmit Segment Acknowledgment messages using the value of the SAR Acknowledgment Retransmissions Count state (see Section 4.2.49.3). Each retransmitted message shall include a new value for the SEQ field. Between retransmissions, the lower transport layer shall introduce a delay indicated by the value of the SAR Receiver Segment Interval Step state (see Section 4.2.49.5).

When the SAR Discard timer expires, the reassembly of the Upper Transport PDU being received is considered failed. For the SeqAuth derived from this message, the lower transport layer shall stop the SAR Acknowledgment timer, stop the SAR Discard timer, remove the AckedSegments value and discard all stored segments.

The Segment Acknowledgment message shall use the same NetKey as the first received segment of a multi-segment message, and the DST field shall have the same value as the SRC field of the first received segment of a multi-segment message.

If the device is acting as a Friend node for a Low Power node, then it shall reassemble segmented messages destined for the Low Power node and act as described, except that it shall set the OBO field to 1 in the Segment Acknowledgment message. Otherwise, the OBO field shall be set to 0.

This section only applies when the Low Power feature is in use.

For each source address, the lower transport layer stores an AckedSegments value which indicates segments that have already been received for a particular SeqAuth and a Sequence Authentication value. The initial value for the AckedSegments is a value that shall indicate that no segments have been received. The initial value for the Sequence Authentication is 0.

When the lower transport layer receives a segment of a segmented message, it shall process the segment against the conditions in Table 3.24. Conditions are evaluated one by one starting from the first line in the table. When the condition is met, the processing ends with the Processing Result corresponding to the value in the Condition column.

When the Processing Result is First Segment, the reassembly of a new segmented message is initiated. If another reassembly is already pending for the same source address, the pending reassembly shall be discarded. Then, the lower transport layer shall set the Sequence Authentication value to the SeqAuth derived from this message and for this SeqAuth shall set the AckedSegments value to indicate that only this segment has been received.

When the Processing Result is Next Segment, the lower transport layer shall store the received segment and set the AckedSegments value for the SeqAuth derived from this message to indicate that this segment has been received.

When the Processing Status is SeqAuth Error, Repeated Segment, or Most Recent SeqAuth, the lower transport layer shall ignore the message.

When the Processing Result is Last Segment, the transfer of the segmented message is complete. The lower transport layer shall discard the AckedSegments value and shall send the reassembled message to the upper transport layer.

If the segments are Segmented Access messages, then the reassembled message shall be processed as defined in Section 3.6.4.2.

If the segments are Segmented Control messages, then the reassembled message shall be processed as defined in Section 3.6.5.

If the friendship is terminated (see Section 3.6.6.4.2), then any previous partially received multi-segment message shall be cancelled.

The Lower Transport PDU shall be delivered to the network layer for processing (see Section 3.4.6.4). TransportPDU field of the Network PDU shall be set to the Lower Transport PDU value.

If the Lower Transport PDU is a Segmented Access message, a Segmented Control message or a Segment Acknowledgment message, then it shall be processed as defined in Section 3.5.3.2.

If the Lower Transport PDU is an Unsegmented Access message or an Unsegmented Control message, then the Upper Transport PDU shall be processed as defined in Section 3.6.4.2.

When the lower transport layer receives a Segment Acknowledgment message that is not understood, then the Segment Acknowledgment message shall be ignored. A Segment Acknowledgment message that is not understood includes messages that have incorrect size.

The Access message is supplied by the access layer. The EncAccessMessage is an Access message encrypted and authenticated as defined in Section 3.9.7.1. If the TransMIC is a 32-bit field, the Access message can be from a single octet to 380 octets in length. If the TransMIC is a 64-bit field, the Access message can be from a single octet to 376 octets in length. At the upper transport layer, this field is opaque and no information within this field may be used.

The Message Integrity Check for Transport (TransMIC) is a 32-bit or 64-bit field that authenticates that the Access message has not been changed. For a Segmented Access message, where the SEG field is set to 1, the size of the TransMIC field is determined by the value of the SZMIC field in the Lower Transport PDU. For Unsegmented Access messages, the TransMIC field is a 32-bit field.

All Access messages are sent in the context of an application key or a device key. The Access message shall be encrypted using this application key or device key, and the TransMIC field shall be set to the message integrity check value, as defined in Section 3.9.6. The Upper Transport Access PDU shall then be delivered to the lower transport layer for processing as defined in Section 3.5.3.3

A sequence number shall be allocated to this message. In the context of a message segmented in the lower transport layer, this sequence number corresponds to the 24 lowest bits of SeqAuth, the sequence number used for authenticating and decrypting the Access message by the receiver, as defined in Section 3.5.3.1.

The AKF and AID fields of the Lower Transport PDU shall be set according to the application key or device key used to encrypt and authenticate the Upper Transport Access PDU. If an application key is used, then the AKF field shall be set to 1 and the AID field shall be set to the AID. If the device key is used, then the AKF field shall be set to 0 and the AID field shall be set to 0b000000.

An Upper Transport Control PDU shall be delivered to the lower transport layer for processing as defined in Section 3.5.3.3.

The upper transport layer shall not transmit a new segmented Upper Transport PDU to a given destination until the previous Upper Transport PDU to that destination has been either completed or cancelled.

Upon receiving an Upper Transport Access PDU, the Access message shall be decrypted, and the TransMIC field shall be authenticated against the device key or the Device Key Candidate (see Section 3.11.8.1) or the known application keys for which the AKF and AID fields match. If the Upper Transport Access PDU authenticates and it has been checked for replay attacks (see Section 3.9.8) then it is delivered to the access layer with the contextual information of this message such as the source address, destination addresses, and the keys used for decryption and authentication.

When the Device Key Candidate is available, and an Access message is decrypted using the Device Key Candidate that was delivered to the access layer, then the node shall revoke the device key, the Device Key Candidate shall become the device key, and the Device Key Candidate shall become unavailable.

Upon receiving an Upper Transport Access PDU, this PDU shall be delivered to the Access layer for processing (see Section 3.7.3.2).

Upon receiving an Upper Transport Control PDU, the destination address of the PDU shall be checked. The PDU shall be processed according to the Transport Control opcode (as defined in Sections 3.6.6, 3.6.7, and 3.6.8) if one of the following conditions is met:

When the upper transport layer receives a message that is not understood, then the message shall be ignored. A message that is not understood includes messages that met one or more conditions listed below:

Messages that are not following segmentation requirements (see Section 3.5.3.1) are also not understood and are ignored.

A Friend Poll message is sent by a Low Power node to ask the Friend node to send a message that it has stored for the Low Power node.

The Friend Poll message parameters are defined in Table 3.28.

The FSN field indicates the Friend Sequence Number that is used as defined in Section 3.6.6.4.2.

A Friend Update message is sent by a Friend node to a Low Power node to inform the Low Power node that the security parameters (see Section 3.6.6.1) for the network have changed or are changing, or that the Friend Queue is empty.

The Friend Update message parameters are defined in Table 3.29.

The Flags field format is defined in Table 3.30.

The Key Refresh Flag indicates whether the Key Refresh procedure is in progress (see Section 3.11.4).

The IV Update Flag indicates whether the IV Update procedure is in progress (see Section 3.11.5).

The IV Index field contains the current IV Index.

The MD field indicates whether the Friend Queue is empty or not, as defined in Table 3.31.

A Friend Request message is sent to the all-friends group address by a Low Power node to start to find a friend.

The Friend Request message parameters are defined in Table 3.32.

The Criteria field format is defined in Table 3.33 and in Figure 3.18.

Figure 3.18. Criteria field format

The RSSIFactor field indicates the contribution of the RSSI measured by the Friend node in the Friend Offer Delay calculation (see Section 3.6.6.3.1).

The RSSIFactor field values are defined in Table 3.34.

The ReceiveWindowFactor field indicates the contribution of the supported Receive Window used in the Friend Offer Delay calculation (see Section 3.6.6.3.1).

The ReceiveWindowFactor field values are defined in Table 3.35.

The MinQueueSizeLog field is defined as log₂(N), where N is the minimum number of maximum size Lower Transport PDUs that the Friend node can store in its Friend Queue.

The MinQueueSizeLog field values are defined in Table 3.36.

The ReceiveDelay field indicates the Receive Delay requested by the Low Power node.

The ReceiveDelay field values are defined in Table 3.37.

The PollTimeout field indicates the initial value of the Poll Timeout timer set by the Low Power node.

The PollTimeout field values are defined in Table 3.38.

The PreviousAddress field indicates the previous Friend’s unicast address or the unassigned address if no previous friendship was established.

The NumElements field indicates the number of elements of the Low Power node. The value is used by the Friend node to calculate the range of unicast addresses assigned to the Low Power node using the SRC field value of the Network PDU of this message.

The NumElements field values are defined in Table 3.39.

The LPNCounter field indicates the number of Friend Request messages that the Low Power node has sent to date.

A Friend Offer message is sent by a Friend node to a Low Power node to offer a friendship.

The Friend Offer message parameters are defined in Table 3.40.

The ReceiveWindow field indicates the Receive Window value supported by the Friend node.

The ReceiveWindow field values are defined in Table 3.41.

The QueueSize field indicates the number of messages that the Friend node can store for the Low Power node.

The SubscriptionListSize field indicates the number of entries in the Subscription List that the Friend node can support for the Low Power node.

The RSSI field contains a signed 8-bit value, and is interpreted as an indication of received signal strength measured in decibels above 1 milliwatt (dBm). This is measured by the Friend node upon receiving the Friend Request message. The value shall be 0x7F (127 dBm) if the received signal strength indication is not available.

The FriendCounter field represents the number of Friend Offer messages that the Friend node has sent.

A Friend Clear message is an acknowledged message sent to the previous Friend node of a Low Power node to inform the Friend node of the removal of a friendship. This message is sent by the current Friend node of the Low Power node.

The Friend Clear message parameters are defined in Table 3.42.

The LPNAddress field contains the unicast address of the Low Power node that is being removed.

The LPNCounter field contains the LPNCounter value of the latest Friend Request used to establish the relationship.

A Friend Clear Confirm message is sent by the previous Friend node in response to the Friend Clear message to confirm that the friendship has been terminated.

The Friend Clear Confirm message parameters are defined in Table 3.43.

The LPNAddress field contains the unicast address of the Low Power node that was removed.

The LPNCounter field contains the LPNCounter value of the corresponding Friend Clear message.

A Friend Subscription List Add message is sent by a Low Power node to a Friend node to add group addresses and virtual addresses to the Friend Subscription list (see Section 3.6.6).

The Friend Subscription List Add message parameter is defined in Table 3.44.

The TransactionNumber field is used to distinguish each individual transaction (see Section 3.6.6.4.3).

The AddressList field contains a list of group addresses and virtual addresses to add to the Friend Subscription List.

A Friend Subscription List Remove message is sent by a Low Power node to a Friend node to remove group addresses and virtual addresses from the Friend Subscription List (see Section 3.6.6).

The Friend Subscription List Remove message parameters are defined in Table 3.45.

The TransactionNumber field is used to distinguish each individual transaction (see Section 3.6.6.4.3).

The AddressList field contains a list of group addresses and virtual addresses to remove from the Friend Subscription List.

A Friend Subscription List Confirm message is sent by a Friend node to a Low Power node in response to a Friend Subscription List Add message or a Friend Subscription List Remove message.

The Friend Subscription List Confirm message parameters are defined in Table 3.46.

The TransactionNumber field is used to distinguish each individual transaction (see Section 3.6.6.4.3).

A Heartbeat message is sent by a node to let other nodes determine topology of a subnet.

The Heartbeat message parameters are defined in Table 3.47.

The InitTTL field contains the initial TTL field value used when sending the message.

The InitTTL field values are defined in Table 3.48.

The Features field contains a bit field indicating the features the node currently uses, as defined in Section 3.1.

The Features field format is defined in Table 3.49.

Features field bits values are defined in Table 3.50.

A PATH_REQUEST message is sent by a Path Origin or by a Directed Relay node to discover a path to a destination.

The PATH_REQUEST message parameters are defined in Table 3.51.

The On_Behalf_Of_Dependent_Origin field indicates whether or not the PATH_REQUEST message is originated by the Path Origin on behalf of a dependent node.

The Path_Origin_Path_Metric_Type field contains the value of the Path Metric Type state of the Path Origin that is stored in the Discovery Table (see Section 3.6.8.6.1).

The Path_Origin_Path_Lifetime field contains the value of the Path Lifetime state of the Path Origin that is stored in the Discovery Table (see Section 3.6.8.6.1).

The Path_Discovery_Interval field contains the value of the Path Discovery Interval state of the Path Origin that is stored in the Discovery Table (see Section 3.6.8.6.1).

The Path_Origin_Forwarding_Number field indicates the last forwarding number generated by the Path Origin, as defined in Section 3.6.8.4.

The Path_Origin_Path_Metric field indicates the path metric calculated starting from the Path Origin.

The Destination field indicates the intended destination. The value of the Destination field shall not be the unassigned address nor the all-directed-forwarding-nodes, all-nodes, or all-relays fixed group addresses.

The Path_Origin_Unicast_Addr_Range field indicates the unicast address range (see Section 3.4.2.2.1) of the Path Origin.

If present, the Dependent_Origin_Unicast_Addr_Range field indicates the unicast address range (see Section 3.4.2.2.1) of the dependent node of the Path Origin.

A PATH_REPLY message is sent by a Path Target or by a Directed Relay node to establish a path from a Path Origin to a Path Target.

The PATH_REPLY message parameters are defined in Table 3.52.

The Unicast_Destination field indicates whether or not the PATH_REPLY message is originated by a Path Target in response to a PATH_REQUEST message with a unicast address in the Destination field.

The On_Behalf_Of_Dependent_Target field indicates whether or not the PATH_REPLY message is originated by a Path Target on behalf of a dependent node.

The Confirmation_Request field indicates the Two Way Path state of the Path Target (see Section 4.2.31), if the Unicast_Destination field is 1.

The Path_Origin field indicates the primary element address of the Path Origin.

The Path_Origin_Forwarding_Number field indicates the forwarding number generated by the Path Origin, as defined in Section 3.6.8.4.

If present, the Path_Target_Unicast_Addr_Range field indicates the unicast address range (see Section 3.4.2.2.1) of the Path Target.

If present, the Dependent_Target_Unicast_Addr_Range field indicates the unicast address range (see Section 3.4.2.2.1) of the dependent node of the Path Target.

A PATH_CONFIRMATION message is sent by a Path Origin or by a Directed Relay node to confirm that a two-way path has been established from the Path Origin to a Path Target.

The PATH_CONFIRMATION message parameters are defined in Table 3.53.

The Path_Origin field indicates the primary element address of the Path Origin.

The Path_Target field indicates the primary element address of the Path Target.

A PATH_ECHO_REQUEST message is sent by a Path Origin to validate a path from the Path Origin to a destination. The response to a PATH_ECHO_REQUEST message is a PATH_ECHO_REPLY message.

The PATH_ECHO_REQUEST message has no parameters.

A PATH_ECHO_REPLY message is sent by a Path Target in response to a PATH_ECHO_REQUEST message in order to confirm that a path exists from a Path Origin to the destination.

The PATH_ECHO_REPLY message parameters are defined in Table 3.54.

The Destination field indicates the intended destination. The value of the Destination field shall not be the unassigned address nor the all-directed-forwarding-nodes, all-nodes, or all-relays fixed group addresses.

A DEPENDENT_NODE_UPDATE message is sent by a Path Origin or by a Directed Relay node to notify nodes in a subnet that element addresses of a dependent node of the Path Origin are to be added or removed from the Forwarding Table state.

A DEPENDENT_NODE_UPDATE message is also sent by a Path Target or by a Directed Relay node to notify nodes in a subnet that element addresses of a dependent node of the Path Target are to be added or removed from the Forwarding Table state.

The DEPENDENT_NODE_UPDATE message parameters are defined in Table 3.55.

The Type field indicates whether the dependent node address is added or removed. The values of the Type field are defined in Table 3.56.

The Path_Endpoint indicates the primary element address of the Path Origin or of the Path Target that notified the nodes about the update.

The Dependent_Node_Unicast_Addr_Range field indicates the unicast address range (see Section 3.4.2.2.1) of the dependent node.

A PATH_REQUEST_SOLICITATION message is sent by a Directed Forwarding node or a Configuration Manager to solicit the discovery of paths from other Directed Forwarding nodes.

The PATH_REQUEST_SOLICITATION message parameter is defined in Table 3.57.

The Addr_List field is a list of unicast addresses, group addresses, and virtual addresses that are destinations for the requested Directed Forwarding Initialization. The all-directed-forwarding-nodes, all-nodes, and all-relays fixed group addresses are Prohibited for the Addr_List field.

In order to optimize the power consumption of a Low Power node, a polling mechanism is used to minimize the Low Power node’s receive window. This allows a Low Power node to receive updates from a Friend node by indicating when it is available to receive messages.

Friendship defines timing parameters that are static for the duration of a friend relationship between a Low Power node and a Friend node.

The following timing parameters are used in a friendship:

The ReceiveDelay is the time between the Low Power node sending a request and listening for a response. This delay allows the Friend node time to prepare the response.

The ReceiveWindow is the time that the Low Power node listens for a response. When the Low Power node receives a message from its Friend node, it can stop listening for additional messages.

The request can be a Friend Poll message, a Friend Subscription List Add message, or a Friend Subscription List Remove message. The response to a Friend Poll message can be a Friend Update message or a stored message. The response to a Friend Subscription List Add message or a Friend Subscription List Remove message is a Friend Subscription List Confirm message.

The timing parameters are illustrated in Figure 3.19.

Figure 3.19. Friendship timing parameters

PollTimeout timer is used to measure time between two consecutive requests sent by the Low Power node. If no requests are received by the Friend node before the PollTimeout timer expires, then the friendship is considered terminated. This is illustrated in Figure 3.20.

Figure 3.20. Poll Timeout timer illustration

To establish a friendship, a node that supports the Low Power feature sends a Friend Request to the all-friends address. The message is picked up by all nodes within radio range of this node that support the Friend feature.

The Friend Request message includes a number of parameters that define the requirements that this node requires any future Friend node to support. Each of the nodes that support the Friend feature and that can support the requirements of the Friend Request message responds by sending back a Friend Offer message to the requesting node. The offers also include additional information about the capabilities of each of the offering nodes. This allows the Low Power node to determine which of these offers it will accept.

The Low Power node then sends a Friend Poll message to its chosen Friend node, and the Friend node responds with a Friend Update message. At this point, the friendship is established, as illustrated in Figure 3.21.

Figure 3.21. Establishment of a friendship

If the Low Power node was previously a friend of another Friend node, then the new Friend node informs the old Friend node that it is now the current friend of this Low Power node (see Section 3.6.6.3.1).

After a friendship is established, the Friend node stores a Friend Subscription List for the Low Power node, which is a collection of group and virtual addresses to which the Low Power node is subscribed. This list allows the Friend node to store the messages that the Low Power node is subscribed to.

The values of the IV Index, IV Update Flag, and Key Refresh Flag for a given NetKey are known as security parameters. Whenever at least one of the values of the security parameters is changed, the new security parameters are known as security updates.

The Friend node stores all messages for the Low Power node, and also the most recent security updates for the Low Power node, in the Friend Queue. Collectively these are known as stored messages.

To obtain stored messages, the Low Power node sends Friend Poll messages and the Friend node replies with stored messages.

Messages stored in the Friend Queue are delivered to the Low Power node with acknowledgment and in order. To enable this, a Boolean Friend Sequence Number is used. This value is stored on the Low Power node and is sent in each Friend Poll message. When the Low Power node receives a message in response to a Friend Poll, and this message has been successfully authenticated using the friendship security credentials, the Low Power node shall change this Friend Sequence Number. The next time this Low Power node polls, the Friend node can send the next message. If there was no response to the Friend Poll message, then the Low Power node does not change the Friend Sequence Number and the Friend node can then determine that the last message it sent was not received and resends it.

When a friendship has been established between a Friend node and a Low Power node, all Network PDUs from the Friend node to the Low Power Node are secured using the friendship security material derived from the friendship security credentials (see Section 3.9.6.3.1). The friendship security credentials are exchanged during the Low Power Establishment procedure (see Section 3.6.6.4.1).

The Friend Poll, Friend Update, and Friend Subscription List Add/Remove/Confirm messages, as well as stored messages that the Friend node delivers to the Low Power node, are always secured using the friendship security material. If the Friend node is a Directed Friend node (see Section 2.3.13), friendship security credentials are used for messages that the Low Power node sends to the Friend node to be forwarded along a path (see Section 3.6.8.3). The Friend Clear and Friend Clear Confirm messages are always secured using the managed flooding security material.

Depending on the value of the Publish Friendship Credentials Flag (see Section 4.2.3.4), the Low Power node model publishes messages using either the friendship security credentials or the managed flooding security credentials (see Section 3.9.6.3.1).

All other Network PDUs are sent using the managed flooding security credentials.

Figure 3.22 illustrates messages sent using the friendship security material (dashed lines) and using the managed flooding security material (solid lines). The Low Power node starts by sending the Friend Request message using the managed flooding security credentials. A Friend node responds with a Friend Offer message, again using the managed flooding security credentials. Both the Low Power node and the Friend node are using the managed flooding security credentials as neither device is in a friendship with the other and therefore cannot use the friendship security credentials. The Low Power node accepts the offer of friendship and sends a Friend Poll to confirm this using the friendship security credentials. The Friend node will respond to this using a Friend Update message. The Low Power node can now configure the friend subscription list by using the Friend Subscription List Add message, confirmed using the Friend Subscription List Confirm message from the Friend node. Both of these messages are sent using the friendship security credentials.

Sometime later, the Friend node receives a message (InMsg) from another device that needs to be delivered to the Low Power node, so it will store this message in the Friend Queue. The Low Power node sends a Friend Poll message, secured using the friendship security material, to which the Friend node will reply with the stored InMsg.

The Low Power node then decides to send two messages: OutMsg1 and OutMsg2. OutMsg1 is sent secured using the friend security material and therefore only the Friend node will receive and relay this message. When the Friend node relays OutMsg1, the message will be retransmitted using the managed flooding security credentials. OutMsg2 is sent using the managed flooding security credentials and therefore the Friend node and any other Relay node within range of the Low Power node can relay the message. OutMsg2, when it is relayed, will be retransmitted using the managed flooding security credentials.

Figure 3.22. Messages secured with friendship and managed flooding security material

The Friend feature defines three mandatory procedures: friend establishment, friend messaging, and friend management.

The Friend Update, Friend Offer, Friend Clear, Friend Clear Confirm, and Friend Subscription List Confirm messages originated by a Friend node shall be sent as Unsegmented Control messages with the SRC field set to the unicast address of the primary element of the Friend node.

3.6.6.3.1. Friend establishment

A node that supports the Friend feature and has the feature enabled, and that receives a Friend Request message (see Section 3.6.5.3), that fulfills the minimum requirements specified by the message parameters shall respond with a Friend Offer message (see Section 3.6.5.4).

If the source address of the Friend Request message is an address of a Low Power node that is currently in a friendship with the Friend node on the subnet over which the message was received, then the Friend node shall also consider the existing friendship with that Low Power node on that subnet terminated.

In the Network PDU of a Friend Offer message, the TTL field shall be set to 0 and the DST field shall be set to the SRC value in the Network PDU of the Friend Request message.

The Friend Offer message shall be sent using the managed flooding security credentials and shall be tagged with the immutable-credentials tag.

The node shall keep a Friend node counter (FriendCounter), which is a 2-octet value initialized to 0. This value shall be sent in the Friend Offer message and shall be used to derive the friendship security material if a friendship is established as a result of the Friend Offer message. After each Friend Offer message is sent, the FriendCounter value shall be incremented by 1. The FriendCounter may wrap.

The time between receiving the Friend Request message and sending the Friend Offer message is called the Friend Offer Delay and shall be computed based on the RSSIFactor field and the ReceiveWindowFactor field as defined in the Friend Request message on the supported ReceiveWindow and on the RSSI measured by the Friend node for the Friend Request message.

The Friend Offer Delay allows a Low Power node to receive Friend Offer messages from potential Friend nodes in order to determine how large the offered ReceiveWindow is, and how important the signal quality is. Some Low Power nodes will prefer Friend nodes with a very small ReceiveWindow and therefore set the ReceiveWindowFactor to be more important than the RSSIFactor. Other Low Power nodes will prefer Friends with a very good signal strength and therefore set the RSSIFactor to be more important than the ReceiveWindowFactor. This means that the Low Power node should receive Friend Offers from Friends quicker for those nodes that match the Low Power nodes requirements, reducing the power consumed by the Low Power node when searching for a Friend node.

To optimize power consumption by the LPN, the Friend Node should provide the smallest possible ReceiveWindow.

A Local Delay is computed with the formula:

Local Delay=ReceiveWindowFactor×ReceiveWindow-RSSIFactor×RSSI

	Where:
		ReceiveWindowFactor is a number from the Friend Request message ReceiveWindow is the value to be sent in the corresponding Friend Offer message RSSIFactor is a number from the Friend Request message RSSI is the received signal strength of the received Friend Request message on the Friend node

If the Local Delay value is greater than 100, then the Friend Offer Delay value in milliseconds shall be set to the Local Delay value. Otherwise, the Friend Offer Delay shall be set to 100 milliseconds.

If the node receives a Friend Poll message within 1 second after sending the Friend Offer message, the friendship is established and it shall save the FSN field value from this Friend Poll message; otherwise, the establishment has failed.

The Friend node shall respond with a Friend Update message after a minimum of ReceiveDelay milliseconds and before a maximum of the sum of ReceiveDelay and ReceiveWindow milliseconds, from the reception of the Friend Poll message from the Low Power node.

In the Network PDU of a Friend Update message, the TTL field shall be set to 0.

This Friend Update message shall be sent using the friendship security credentials and shall be tagged with the immutable-credentials tag.

Figure 3.23 illustrates a friendship establishment where multiple nodes with the Friend feature enabled receive the same Friend Request message.

Figure 3.23. Friend establishment example

After a friendship is established, the Friend node shall initialize a Friend Subscription List to a zero-length (empty) list and start storing messages for the Low Power node in the Friend Queue.

After a friendship has been established, if the PreviousAddress field of the Friend Request message contains a valid unicast address that is not the Friend node’s own unicast address, then the Friend node shall begin sending Friend Clear messages (see Section 3.6.5.5) to that unicast address according to the procedure below:

1. In the Network PDU of the Friend Clear message, the TTL field shall be set to 0x7F.

2. The Friend Clear message shall be sent using the managed flooding security credentials and shall be tagged with the immutable-credentials tag.

3. The first Friend Clear message shall be sent as soon as the friendship is established; at the same time, a Friend Clear Repeat timer shall be started with the period set to 1 second, and a Friend Clear Procedure timer shall be started with the period equal to two times the Friend Poll Timeout value.

4. If a Friend Clear Confirm message (see Section 3.6.5.6) is received in response to the Friend Clear message, both timers shall be stopped and the procedure is complete.

5. If the Friend Clear Repeat timer expires, a new Friend Clear message shall be sent and the timer shall be started from the initial value that is double the previous Friend Clear Repeat timer initial value. For example, after the first expiration, the period shall be set to two seconds; on the next expiration, it shall be set to four seconds, and so on.

6. If the Friend Clear Procedure timer expires, then the Friend Clear Repeat timer shall be stopped and the procedure is complete.

An example of this procedure is illustrated in Figure 3.24.

Once friendship has been established the Friend node shall communicate with the Low Power node as defined in friend messaging (see Section 3.6.6.3.2), and may be managed as defined in Friend Management (see Section 3.6.6.3.3).

Figure 3.24. Friend Clear procedure example

A node that supports the Low Power feature shall support the three mandatory procedures: Low Power establishment, Low Power messaging, and Low Power management.

The Friend Poll, Friend Request, Friend Subscription List Add, and Friend Subscription List Remove messages originated by a Low Power node shall be sent as Unsegmented Control messages with the SRC field set to the unicast address of the primary element of the node that supports the Low Power feature.

3.6.6.4.2. Low Power messaging

The Low Power messaging procedure is executed by a Low Power node to receive stored messages and security updates from the Friend node.

The procedure consists of asynchronous requests from the Low Power node to the Friend node and timed responses from the Friend node to the Low Power node.

A Low Power node that is in a friendship with a Friend node shall send a Friend Poll message to the Friend node before the PollTimeout timer expires.

As a general rule, the Low Power node should continue sending Friend Poll messages until it receives a Friend Update message with the MD field set to 0. This is illustrated in Figure 3.25.

The Low Power node may terminate friendship with a Friend by sending a Friend Clear. The Friend Clear message should be sent using a TTL field value set to 0.

Figure 3.25. Friend Update with security updates

The FSN field shall be set to the value of the Friend Sequence Number.

If the Low Power node receives a response from the Friend node, and the response is not a duplicate of the last received Lower Transport PDU, then the Low Power node shall toggle the Friend Sequence Number.

If the Low Power node does not receive a response within the ReceiveWindow, it should resend the Friend Poll message. It is recommended to resend this message 3 times, which assures a good balance between reliability and power consumption.

If no response has been received to multiple Friend Poll messages before the PollTimeout timer expires, the friendship is terminated. The Low Power node may repeat the Low Power establishment procedure.

If the Low Power node receives a Friend Update message, it shall process the Flags and IV Index fields using the same rules as if they had been received in a Secure Network beacon (see Sections 3.10.3.1, 3.11.4, and 3.11.5) or in a Mesh Private beacon (see Section 3.10.4).

The segmentation and reassembly behaviors defined in Sections 3.5.3.3 and 3.5.3.4 also apply to segmented messages sent to and from a Low Power node. The only difference is that since the Low Power node relies on the Friend Queue for all incoming messages, including segments and segment acknowledgments, the Friend node will acknowledge segmented transactions for the Low Power node.

This section provides two examples of segmentation and reassembly on the Low Power node.

3.6.6.5.1. Incoming segmented message

The message sequence chart (MSC) in Figure 3.26 is an example of a segmented message directed toward a Low Power node. The Friend node performs the reassembly separately and sends the acknowledgments needed until it receives all segments, at which point the Friend node places the segments in the Friend Queue so that they can be delivered to the Low Power node. An unsegmented message from another source is received in the middle of the transaction and is handled independently.

Figure 3.26. Example of incoming segmented message directed to a Low Power node

3.6.6.5.2. Outgoing segmented message

The MSC illustrated in Figure 3.27 shows an example of a segmented message sent by the Low Power node. Since the Low Power node relies on the Friend Queue for all incoming messages, it needs to poll for the acknowledgment as well. An unsegmented message from another source is received in the middle of the transaction and is handled independently.

Figure 3.27. Example of outgoing segmented message sent by a Low Power node

In order to determine if a node is still present and active within a mesh network, it is necessary to receive a message from this node. Sending a message to each and every node in the mesh network to elicit a response would be very wasteful of energy, and therefore each node can be configured to send a single message periodically. This message is called the Heartbeat message.

The Heartbeat message can be used for three main functions. The first function is the determination that a node is still active within a mesh network. The second function is the determination of how far a node is away. The third function is the determination that a feature of the node has been enabled or disabled.

Publishing of the Heartbeat messages is configured by the Configuration Server model. Periodic Heartbeat messages can be sent a limited number of times or they can be sent indefinitely. Heartbeat messages are sent to a configured destination, and it is recommended that a group address is used for sending Heartbeat messages. The messages can also be configured with a specific TTL value.

When Heartbeat messages are received, they are counted. The number of Heartbeat messages received can help determine the reliability of the mesh network for delivering messages from the node sending Heartbeat messages.

Each Heartbeat message includes the initial TTL value used when sending the original Heartbeat message. This allows a receiving device to determine the number of times this message was retransmitted, known as the number of hops, and a record of the minimum and maximum number of hops can also be used to determine how reliable the mesh network is.

The use of Heartbeat messages can therefore be used to determine the best TTL value to use to address a given node.

Heartbeat messages also include the features of a node that are currently in use. A node can be configured to publish a triggered Heartbeat message when various features are enabled or disabled. This allows the features available on various nodes within a mesh network to be determined.

Publishing of Heartbeat messages is controlled by the Heartbeat Publication state (see Section 4.2.18).

When the Heartbeat Publication Destination (see Section 4.2.18.1) address is set to an unassigned address, Heartbeat messages shall not be published. When the value of the Heartbeat Publication Count state (see Section 4.2.18.2) is 0x0000, periodic Heartbeat messages shall not be published.

Heartbeat messages shall be published with the DST field set to the value of the Heartbeat Publication Destination state and with the TTL field set to the value of the Heartbeat Publication TTL state (see Section 4.2.18.4).

Periodic publishing of Heartbeat messages is enabled by the Heartbeat Publication Count state (see Section 4.2.18.2). After publishing a periodic Heartbeat message, if the Heartbeat Publication Count counter is less than 0xFFFF, the Heartbeat Publication Count counter shall be decreased by 1. The counter shall stop at 0x0000. The first periodic Heartbeat message shall be published as soon as possible after the Heartbeat Publication Period state (see Section 4.2.18.3) has been configured for periodic publishing. The next periodic Heartbeat message shall be published after the number of seconds defined by the Heartbeat Publication Period state (see Section 4.2.18.3).

Triggered publishing of Heartbeat messages is enabled by the Heartbeat Publication Features state (see Section 4.2.18.5):

Receiving of Heartbeat messages is controlled by the Heartbeat Subscription state (see Section 4.2.19).

The Heartbeat Subscription Period state is a countdown timer identifying the number of seconds remaining for the period when Heartbeat messages are received. When the timer expires, the receiving of Heartbeat messages shall be disabled.

Heartbeat messages with the SRC field set to a value other than the Heartbeat Subscription Source state (see Section 4.2.19.1) or the DST field set to a value other than the Heartbeat Subscription Destination state (see Section 4.2.19.2) shall not be processed.

Upon receiving a Heartbeat message, the value of the Heartbeat Subscription Count state (see Section 4.2.19.3) shall be increased. The counter does not wrap. It stops counting at 0xFFFF.

Upon receiving the Heartbeat message, a hops value shall be calculated using the InitTTL value from the message, and the received Network PDU TTL field value, known as RxTTL, as follows:

If the hops value is lower than the Heartbeat Subscription Min Hops state, it shall be set as the new value of the Heartbeat Subscription Min Hops state. If the hops value is higher than the Heartbeat Subscription Max Hops state, it shall be set as the new value of the Heartbeat Subscription Max Hops state.

In order to initiate the discovery of a path, a Path Origin sends a PATH_REQUEST message indicating its intended destination address. This procedure is named Directed Forwarding Initialization (see Section 3.6.8.2.1).

Directed Relay nodes discover the path by re-generating and broadcasting the PATH_REQUEST message until it reaches all Path Targets. When a node receives a PATH_REQUEST, it stores information about discovered paths temporarily in the Discovery Table (see Section 3.6.8.6). This procedure is named Directed Forwarding Discovery (see Section 3.6.8.2.2).

The path is made available by unicasting, hop by hop, a PATH_REPLY from each Path Target back to the Path Origin. Each Directed Forwarding node that receives the PATH_REPLY message stores path information in the Forwarding Table state (see Section 3.6.8.5). This procedure is named Directed Forwarding Establishment (see Section 3.6.8.2.3).

A PATH_REPLY may trigger the Path Origin to send a PATH_CONFIRMATION message that is propagated, hop by hop, along the path from the Path Origin to a Path Target to confirm that the path is a two-way path. This procedure is named Directed Forwarding Confirmation (see Section 3.6.8.2.4). A two-way path can be used to forward messages from the Path Origin to the Path Target (along the Forward Path) and from the Path Target to the Path Origin (along the Backward Path).

A dependent node (see Section 3.6.8.3) can use a Path Origin or a Path Target to perform directed forwarding on its behalf. By sending a DEPENDENT_NODE_UPDATE message, a Path Origin or a Path Target notifies each node along the paths either to add the dependent node addresses to its Forwarding Table entry or to remove them. This procedure is named Directed Forwarding Dependents Update (see Section 3.6.8.2.5).

A path from a Path Origin to a Path Target can be monitored by using a PATH_ECHO_REQUEST message. The Path Target responds with a PATH_ECHO_REPLY message. This procedure is named Directed Forwarding Echo (see Section 3.6.8.2.6).

A Directed Forwarding node or a Configuration Manager can solicit the discovery of paths toward unicast addresses, group addresses, or virtual addresses by using a PATH_REQUEST_SOLICITATION message. This procedure is named Directed Forwarding Solicitation (see Section 3.6.8.2.7)

Directed forwarding functionality uses a control sequence number known as the forwarding number to distinguish Transport Control messages sent by a node in the context of different Directed Forwarding Initialization procedures. The forwarding number is separate from the sequence numbers used for the message caching and the replay protection procedures (that is, the SEQ field defined in Section 3.4.4.5). The forwarding number is increased when a node initiates the discovery of a new path to any destination (see Section 3.6.8.4).

3.6.8.1.2. Path metrics

Path metrics are used to measure, rank, and select the best lane of a path (for example, the lane with the lowest number of hops) that messages will traverse.

This specification uses a path metric based on the hop count between the Path Origin and the Path Target. The path metric also takes into account the number of lanes that traverse the node. In this way, a longer but disjointed lane (i.e., the lane uses different intermediate nodes than other lanes in that path) might be preferred to a shorter lane using one or more of the same intermediate nodes (see Section 4.2.27.1).

Figure 3.28 shows an example of a network composed a Path Origin (PO), a Path Target (PT), and Directed Relay nodes (identified by capital letters from A to J). The Path Origin initiates a path discovery toward the Path Target and is configured to discover two lanes (Figure 3.28 (a), (b) and (c)). In the Figure 3.28 (b) and Figure 3.28 (c), white circles represent nodes that are not chosen to be part of the path between the Path Origin and the Path Target, and blue circles represent nodes that are chosen to be part of the path. The transmission of a PATH_REQUEST message from a node is represented by arrows that connect the node with its neighbors. Before transmitting a PATH_REQUEST message, every node (say A) sets the Path_Origin_Path_Metric field in the message to the path metric value (POPM_A) that the node calculates as defined in Section 4.2.27.1, based on the Path_Origin_Path_Metric field in the Discovery Table (see Section 3.6.8.6), and the Lane_Counter field value (LC_A), if a Forwarding Table entry corresponding to the message exists. Figure 3.28 (a) and (b) show the lowest path metric values calculated by the nodes during the discovery of the first and second lanes, respectively. During the first lane discovery illustrated in Figure 3.28 (a), nodes PO, A, and B are selected as members of the lane. During the second lane discovery illustrated in Figure 3.28 (b), nodes PO, C, D, and E are selected as members of the lane. If the Path Origin is configured to discover three lanes, nodes PO, A, and B are selected again as members of the lane during the third discovery attempt that is illustrated in Figure 3.28 (c); this suggests that, in this example network topology and using the metric defined in this specification, using two lanes is a good compromise between path redundancy and traffic generated for path discovery.

Figure 3.28. Example of network with the discovery of two path lanes

This section defines the requirements for the directed forwarding procedures.

If the Directed Forwarding state (see Section 4.2.26.1) is disabled at a node in a subnet while a directed forwarding procedure is being executed in the context of that subnet, the procedure is canceled.

3.6.8.2.1. Directed Forwarding Initialization

The Directed Forwarding Initialization procedure is executed by a Path Origin to discover a new path or to add nodes to an existing path toward a destination in a given subnet.

Figure 3.29 shows the flow chart of the Directed Forwarding Initialization procedure.

Figure 3.29. Directed Forwarding Initialization procedure

First, the Path Origin shall check whether or not the number of executed Directed Forwarding Initialization procedures (i.e., the number of Discovery Table entries that store the primary element address of the node in their Path_Origin field) is equal to the Max Concurrent Init state value (see Section 4.2.28.2).

If the number of executed Directed Forwarding Initialization procedures is equal to the Max Concurrent Init state value, then the Directed Forwarding Initialization procedure shall fail. Otherwise, a new entry shall be added to the Discovery Table according to Section 3.6.8.6.1, a new instance of the Path Discovery timer shall be started from the initial value set to the duration indicated by the Path Discovery Interval state value (see Section 4.2.38.3), and a PATH_REQUEST message shall be prepared and sent.

The new PATH_REQUEST shall have the following field values:

• If the PATH_REQUEST is originated on behalf of a dependent node of the Path Origin (see Section 3.4.6.3), the On_Behalf_Of_Dependent_Origin field shall be set to 1, and the Dependent_Origin_Unicast_Addr_Range field shall be set to the unicast address range of the dependent node; otherwise, the On_Behalf_Of_Dependent_Origin field shall be set to 0.

• The Path_Origin_Path_Metric_Type field shall be set to the Path_Origin_Path_Metric_Type field value in the Discovery Table (see Section 3.6.8.6).

• The Path_Origin_Path_Lifetime field shall be set to the Path_Origin_Path_Lifetime field value in the Discovery Table (see Section 3.6.8.6).

• The Path_Discovery_Interval field shall be set to the Path_Discovery_Interval field value in the Discovery Table (see Section 3.6.8.6).

• The Path_Origin_Forwarding_Number field shall be set according to Section 3.6.8.4.

• The Path_Origin_Path_Metric field shall be set to 0.

• The Destination field shall be set to the unicast address, group address, or virtual address of the destination.

• The Path_Origin_Unicast_Addr_Range field shall be set to the unicast address range (see Section 3.4.2.2.1) of the Path Origin.

The Network PDU for the new PATH_REQUEST message shall have the following configuration:

• The DST field shall be set to the all-directed-forwarding-nodes fixed group address (see Section 3.4.2.4).

• The TTL field shall be set to 0.

The Path Origin shall send the message using the directed security credentials of the subnet over which the message is sent and shall tag the message with the immutable-credentials tag.

When the Path Discovery timer associated with a Discovery Table entry expires, the Path Origin shall perform the following actions:

• If the value of the Path_Not_Ready field (see Section 4.2.29.2) in the corresponding Forwarding Table state entry is 1, then the Path_Not_Ready field in the entry shall be set to 0.

• If the Lane Counter value in the corresponding Forwarding Table state entry has been instantiated or incremented and is less than the Wanted Lanes state value (see Section 4.2.30), a Lane Discovery Guard timer shall be started from the initial value indicated by Lane Discovery Guard Interval state (see Section 4.2.38.4).

  • When the Lane Discovery Guard timer expires, a new PATH_REQUEST message shall be prepared and sent, and the Path Discovery timer shall be started from the initial value indicated by the Path Discovery Interval state value (see Section 4.2.38.3). All the fields in the new PATH_REQUEST message shall be copied from the previous PATH_REQUEST message.

• If the Lane Discovery Guard timer is not running, the Discovery Table entry shall be removed, and the Directed Forwarding Initialization procedure shall complete with a success or a failure based on the comparison between the Lane Counter field value in the corresponding Forwarding Table state entry and the Wanted Lanes state value:

  • If the Lane Counter field value is greater than 0 and less than the Wanted Lanes state value (i.e., at least one lane of the path had already been established), the Directed Forwarding Initialization procedure is successful.

  • If the Lane Counter field value is equal to the Wanted Lanes state value (i.e., the last lane of the path has been established), the Directed Forwarding Initialization procedure is successful.

  • If the Lane Counter field value is 0 (i.e., no lane of the path had been established), the Directed Forwarding Initialization procedure fails.

3.6.8.2.2. Directed Forwarding Discovery

The Directed Forwarding Discovery procedure shall be executed by any Directed Forwarding node that receives a PATH_REQUEST message.

Figure 3.30 shows the flow chart of the Directed Forwarding Discovery procedure.

Figure 3.30. Directed Forwarding Discovery procedure

When a Directed Forwarding node receives a PATH_REQUEST message, the node shall check whether to process or discard the message.

The PATH_REQUEST message shall be discarded if any of the following conditions is met:

• The RSSI value measured for the PATH_REQUEST message is less than the sum of the Default RSSI Threshold state value (see Section 4.2.35.1) and the RSSI Margin state value (see Section 4.2.35.2).

• The node does not support the path metric type that is indicated in the PATH_REQUEST message Path_Origin_Path_Metric_Type field (see Section 4.2.27.1).

• A non-fixed Forwarding Table entry corresponding to the PATH_REQUEST message exists (see Section 3.6.8.5.2), and the Path_Origin_Forwarding_Number field value in the message is less than the Forwarding_Number value in the table entry. The comparison between the Path_Origin_Forwarding_Number and the Forwarding_Number shall follow the definitions in Section 3.6.8.4.

• Directed relay, directed friend, and directed proxy functionalities are all disabled, and the Destination field value of the PATH_REQUEST message is not an element address of the node or a group address or a virtual address that the node is subscribed to.

• Directed relay functionality is disabled; and either directed friend functionality, directed proxy functionality, or both are enabled; and the Destination field value of the PATH_REQUEST message is not an element address of the node or of a dependent node; and the Destination field value of the PATH_REQUEST message is not a group address or a virtual address that the node or a dependent node is subscribed to.

• A Discovery Table entry corresponding to the PATH_REQUEST message does not exist (see Section 3.6.8.6.2), and the number of Directed Forwarding Discovery procedures that are being executed in the subnet from which the PATH_REQUEST message is received (i.e., the number of non-empty Discovery Table entries in the subnet) is equal to the Max Discovery Table Entries Count state value (see Section 4.2.28.1) for the subnet.

• A Discovery Table entry corresponding to the PATH_REQUEST message exists, and the Path_Origin_Path_Metric field value in the message is not less than the Path_Origin_Path_Metric value in the table entry.

If the PATH_REQUEST message can be processed, and a Discovery Table entry corresponding to the PATH_REQUEST message does not exist, a new Discovery Table entry shall be added according to Section 3.6.8.6.2, and the corresponding instance of the Path Discovery timer shall be started. The Path Discovery timer initial value shall be set to the duration indicated by the value of the Path_Discovery_Interval field (see Section 4.2.38.3) in the PATH_REQUEST message.

If the PATH_REQUEST message can be processed, and a Discovery Table entry corresponding to the PATH_REQUEST message exists, the Discovery Table entry shall be updated according to Section 3.6.8.6.2. The corresponding instance of the Path Discovery timer is not restarted.

If the PATH_REQUEST message can be processed, the node checks whether it is or is not a Path Target for the PATH_REQUEST message.

The node shall be a Path Target for a PATH_REQUEST message if one of the following conditions is met:

• The Destination field value of the PATH_REQUEST message is either an element address of the node or one of the group addresses or virtual addresses that the node is subscribed to.

• The node has a list of dependent nodes, and the Destination field value of the PATH_REQUEST message is either an element address of one of the dependent nodes or is one of the group addresses or virtual addresses that any of the dependent nodes is subscribed to.

If the node is a Path Target for the PATH_REQUEST message, and the corresponding Discovery Table entry is added, the node shall start the Path Reply Delay timer for this entry. If the Destination field value in the PATH_REQUEST message is a unicast address, the Path Reply Delay timer initial value shall be set to the Path_Reply_Delay value. If the Destination field value in the PATH_REQUEST message is a group address or a virtual address, the Path Reply Delay timer initial value shall be set to the sum of the Path_Reply_Delay value and a random delay of 0 milliseconds to 500 milliseconds.

The node processing the PATH_REQUEST message shall start a Path Request Delay timer for the corresponding Discovery Table entry if all the following conditions are met:

• The Path Request Delay timer for the corresponding Discovery Table entry is inactive.

• The node is a Directed Relay node.

• One of the following conditions is met:

  • The node is not a Path Target for the PATH_REQUEST message.

  • The node is a Path Target for the PATH_REQUEST message, and the Destination field value in the PATH_REQUEST message is a group address or a virtual address.

When a Path Request Delay timer is started, it shall start from the initial value set to a random value in the interval [Path_Request_Delay, Path_Request_Delay + 30 ms].

When a Path Request Delay timer expires, the node shall prepare and send a new PATH_REQUEST message with the following field values:

• The On_Behalf_Of_Dependent_Origin, Path_Origin_Path_Metric_Type, Path_Origin_Path_Lifetime, Path_Discovery_Interval, Path_Origin_Forwarding_Number, Destination, and Path_Origin_Unicast_Addr_Range fields shall have the values of the corresponding Discovery Table entry (see Section 3.6.8.6.2).

• The Path_Origin_Path_Metric field value in the message shall be calculated from the Path_Origin_Path_Metric_Type and Path_Origin_Path_Metric values of the corresponding Discovery Table entry, according to Section 4.2.27.1.

• If the On_Behalf_Of_Dependent_Origin value in the corresponding Discovery Table entry is 1, the Dependent_Origin_Unicast_Addr_Range field shall be derived from the Dependent_Origin value and the Dependent_Origin_Secondary_Elements_Count value of the Discovery Table entry (see Section 3.4.2.2.4).

The Network PDU for the new PATH_REQUEST message shall have the following configuration:

• The DST field shall be set to the all-directed-forwarding-nodes fixed group address (see Section 3.4.2.4).

• The TTL field shall be set to 0.

The node shall send the message using the directed security credentials of the subnet over which the message is sent and shall tag the message with the immutable-credentials tag.

When a Path Discovery timer expires, the corresponding Discovery Table entry shall be removed.

3.6.8.2.3. Directed Forwarding Establishment

The Directed Forwarding Establishment procedure shall be executed by a Path Target when a Path Reply Delay timer expires; the procedure also shall be executed by any Directed Forwarding node that receives a PATH_REPLY message.

Figure 3.31 illustrates the Directed Forwarding Establishment procedure.

Figure 3.31. Directed Forwarding Establishment procedure

When a Path Reply Delay timer for a Discovery Table entry expires, the Path Target shall update the Forwarding Table state according to Section 3.6.8.5.3. If a new Forwarding Table entry is added, the node shall also start a Path Lifetime timer for the table entry. The Path Lifetime timer initial value shall be set to the Path_Origin_Path_Lifetime value in the Discovery Table entry.

After updating the Forwarding Table state, the node shall prepare and send a PATH_REPLY message with the following field values:

• If the Destination value in the Discovery Table entry is a unicast address, the Unicast_Destination field shall be set to 1, and the Path_Target_Unicast_Addr_Range field shall be set to the unicast address range (see Section 3.4.2.2.1) of the Path Target. Otherwise, the Unicast_Destination field shall be set to 0 and the Path_Target_Unicast_Addr_Range field shall not be present.

• If the Destination value in the Discovery Table entry is a unicast address, and the PATH_REPLY message is originated on behalf of a dependent node of the Path Target, the On_Behalf_­Of_­Dependent_­Target field shall be set to 1, and the Dependent_Target_­Unicast_­Addr_­Range field shall be set to the unicast address range of the dependent node. Otherwise, the On_Behalf_­Of_­Dependent_­Target field shall be set to 0, and the Dependent_Target_­Unicast_­Addr_­Range field shall not be present.

• If the Destination value in the Discovery Table entry is a unicast address, and a Forwarding Table entry corresponding to a path from the primary element address of the node to the Path_Origin value in the Discovery Table entry does not exist (see Section 3.6.8.5.1), the Confirmation_Request field shall be set to the Two Way Path state value (see Section 4.2.31); otherwise, it shall be set to 0.

• The Path_Origin field shall be set to the Path_Origin value in the Discovery Table entry.

• The Path_Origin_Forwarding_Number field shall be set to the Path_Origin_Forwarding_Number value in the Discovery Table entry.

The Network PDU for the PATH_REPLY message shall have the following configuration:

• The DST field shall be set to the Next_Toward_Path_Origin value in the Discovery Table entry.

• The TTL field shall be set to 0.

The node shall send the message using the directed security credentials of the subnet over which the message is sent and shall tag the message with the immutable-credentials tag.

When a node receives a PATH_REPLY message, the node checks whether to process or discard the message. If a Discovery Table entry that corresponds to the received PATH_REPLY message exists (see Section 3.6.8.6.3), the received PATH_REPLY message shall be processed; otherwise, the PATH_REPLY message shall be discarded.

If the PATH_REPLY message is processed, the node shall update the Forwarding Table state according to Section 3.6.8.5.4. If the Path Lifetime timer for the Forwarding Table entry corresponding to the processed PATH_REPLY message is not running, the node shall start it. The Path Lifetime timer initial value shall be set to the Path_Origin_Path_Lifetime value in the Discovery Table entry.

If this is the first PATH_REPLY processed after the Path Discovery timer of the corresponding Discovery Table entry started, and the Path_Origin field value in the PATH_REPLY message is the primary element address of the node, then a lane of the path is considered established for the purpose of the Directed Forwarding Initialization procedure (see Section 3.6.8.2.1).

If this is the first PATH_REPLY processed after the Path Discovery timer of the corresponding Discovery Table entry started, and the Path_Origin field value in the PATH_REPLY message is the primary element address of the node, and the Confirmation_Request field value of the PATH_REPLY message is 1, then the node shall execute a Directed Forwarding Confirmation procedure (see Section 3.6.8.2.4).

If this is the first PATH_REPLY processed after the Path Discovery timer of the corresponding Discovery Table entry started, the Path_Origin field value in the PATH_REPLY message is the primary element address of the node, the Unicast_Destination field value in the PATH_REPLY message is 1, and the Unicast Echo Interval state is greater than 0 (see Section 4.2.32.1), then the node checks whether or not a Path Echo timer for the corresponding Forwarding Table entry is running. If the Path Echo timer is not running, the node shall start the Path Echo timer from the initial value set as defined in Section 4.2.32.1.

If this is the first PATH_REPLY processed after the Path Discovery timer of the corresponding Discovery Table entry started, the Path_Origin field value in the PATH_REPLY message is the primary element address of the node, the Unicast_Destination field value in the PATH_REPLY message is 0, and the Multicast Echo Interval state is greater than 0 (see Section 4.2.32.2), then the node checks whether or not a Path Echo timer for the corresponding Forwarding Table entry is running. If the Path Echo timer is not running, the node shall start the Path Echo timer from the initial value set as defined in Section 4.2.32.2.

If this is the first PATH_REPLY processed after the Path Discovery timer of the corresponding Discovery Table entry started, and the Path_Origin field value in the PATH_REPLY message is not the primary element address of the node, then the node shall prepare and send a new PATH_REPLY message in which the field values are copied from the received PATH_REPLY message.

The Network PDU for the new PATH_REPLY message shall have the following configuration:

• The DST field shall be set to the Next_Toward_Path_Origin value in the Discovery Table entry corresponding to the received PATH_REPLY message.

• The TTL field shall be set to 0.

The node shall send the message using the directed security credentials of the subnet over which the message is sent and shall tag the message with the immutable-credentials tag.

When a Path Lifetime timer for a Forwarding Table entry expires, the Forwarding Table entry shall be removed and all timers corresponding to the entry shall be stopped.

3.6.8.2.4. Directed Forwarding Confirmation

The Directed Forwarding Confirmation procedure shall be executed:

• By a node that is the Path Origin indicated by the Path_Origin field in a received PATH_REPLY message with the Confirmation_Request field value of 1 after receiving the first PATH_REPLY message after the Path Discovery timer of the corresponding Discovery Table entry started.

• By any Directed Forwarding node that receives a PATH_CONFIRMATION message.

Figure 3.32 is a flow chart illustrating the Directed Forwarding Confirmation procedure.

Figure 3.32. Directed Forwarding Confirmation procedure

If the Path Origin receives a PATH_REPLY message with the Confirmation_Request field value of 1, the node shall prepare and send a PATH_CONFIRMATION message with the following field values:

• The Path_Target field shall be set to the Destination value in the Forwarding Table entry corresponding to the received PATH_REPLY message (see Section 3.6.8.5.4).

• The Path_Origin field shall be set to the primary element address of the Path Origin.

The Network PDU for the new PATH_CONFIRMATION message shall have the following configuration:

• The DST field shall be set to the all-directed-forwarding-nodes fixed group address (see Section 3.4.2.4).

• The TTL field shall be set to 0.

The Path Origin shall send the message using the directed security credentials of the subnet over which the message is sent and shall tag the message with the immutable-credentials tag.

When a Directed Forwarding node receives a PATH_CONFIRMATION message, the node checks whether to process or discard the message.

The PATH_CONFIRMATION message shall be discarded if any of the following conditions is met:

• A non-fixed Forwarding Table entry corresponding to the PATH_CONFIRMATION message does not exist (see Section 3.6.8.5.5).

• The Backward_Path_Validated value in the Forwarding Table entry corresponding to the PATH_CONFIRMATION message is 1, and the node is the Path Target indicated by the Path_Target field in the PATH_CONFIRMATION message.

• The node has already sent a PATH_CONFIRMATION message after starting the Path Discovery timer for the Discovery Table entry that has the same Path_Origin and Path_Origin_Forwarding_Number values as the Forwarding Table entry that corresponds to the PATH_CONFIRMATION message. Once true, this condition shall persist until the Path Discovery timer expires.

If the received PATH_CONFIRMATION message can be processed, and the Backward_Path_Validated value in the corresponding Forwarding Table entry is 0, the table entry shall be updated as defined in Section 3.6.8.5.5. Then, if the node is not the Path Target indicated by the Path_Target field in the received PATH_CONFIRMATION message, the node shall prepare and send a new PATH_CONFIRMATION message in which the field values are copied from the received PATH_CONFIRMATION message.

A random delay from 0 to 30 milliseconds should be introduced between preparing and sending the PATH_CONFIRMATION message, to avoid collisions with messages being sent by other nodes at the same time.

The Network PDU for the new PATH_CONFIRMATION message shall have the following configuration:

• The DST field shall be set to the all-directed-forwarding-nodes fixed group address (see Section 3.4.2.4).

• The TTL field shall be set to 0.

The node shall send the message using the directed security credentials of the subnet over which the message is sent and shall tag the message with the immutable-credentials tag.

3.6.8.2.5. Directed Forwarding Dependents Update

The Directed Forwarding Dependents Update procedure is executed in the following contexts:

• The procedure is executed by a Path Origin to notify the nodes along paths from that Path Origin that unicast addresses of its dependent nodes are to be added or removed from the corresponding Forwarding Table entries (see Section 3.6.8.3).

• The procedure is executed by a Path Target to notify the nodes along paths to that Path Target that unicast addresses of its dependent nodes are to be added or removed from the corresponding Forwarding Table entries (see Section 3.6.8.3).

The conditions that trigger the Forwarding Dependents Update procedure in the contexts above are defined in Section 3.6.8.3.

The procedure shall also be executed by any Directed Forwarding node that receives a DEPENDENT_NODE_UPDATE message.

Figure 3.33 is a flow chart of the Directed Forwarding Dependents Update procedure.

Figure 3.33. Directed Forwarding Dependents Update procedure

When the Directed Forwarding Dependents Update procedure starts, the node shall update all the Forwarding Table entries that correspond to paths with the node as a Path Origin or Path Target, as defined in Section 3.6.8.5.8.

If any Forwarding Table entries are updated, the node shall also prepare and send a DEPENDENT_NODE_UPDATE message with the following configuration:

• The Type field shall be set to 1 if one or more addresses of a dependent node are to be added to the Forwarding Table state. If one or more addresses of a dependent node are to be removed from the Forwarding Table state, the Type field shall be set to 0.

• The Path_Endpoint field shall be set to the primary element address of the Path Origin if the node is the Path Origin of any updated Forwarding Table entry. If the node is the Path Target of any updated Forwarding Table entry, the Path_Endpoint field shall be set to the primary element address of the Path Target.

• The Dependent_Node_Unicast_Addr_Range field shall be set to the unicast address range (see Section 3.4.2.2.1) of the dependent node that is to be added to or to be removed from the Forwarding Table state.

The Network PDU for the DEPENDENT_NODE_UPDATE message shall have the following configuration:

• The DST field shall be set to the all-directed-forwarding-nodes fixed group address (see Section 3.4.2.4).

• The TTL field shall be set to 0.

The node shall send the message using the directed security credentials of the subnet over which the message is sent and shall tag the message with the immutable-credentials tag.

When a node receives a DEPENDENT_NODE_UPDATE message, the node shall check whether the Forwarding Table state contains at least one entry that corresponds to the DEPENDENT_NODE_UPDATE message (see Section 3.6.8.5.8).

Each entry that corresponds to the DEPENDENT_NODE_UPDATE message shall be updated as defined in Section 3.6.8.5.8. The node shall then send a new DEPENDENT_NODE_UPDATE message in which the field values are copied from the received DEPENDENT_NODE_UPDATE message.

The Network PDU for the new DEPENDENT_NODE_UPDATE message shall have the following configuration:

• The DST field shall be set to the all-directed-forwarding-nodes fixed group address (see Section 3.4.2.4).

• The TTL field shall be set to 0.

The node shall send the message using the directed security credentials of the subnet over which the message is sent and shall tag the message with the immutable-credentials tag.

If there is no Forwarding Table entry that corresponds to the DEPENDENT_NODE_UPDATE message, the message shall be discarded.

3.6.8.2.6. Directed Forwarding Echo

The Directed Forwarding Echo procedure shall be executed by a Path Origin when an instance of the Path Echo timer expires or by a Path Target when it receives a PATH_ECHO_REQUEST message in order to validate a path between the two nodes.

Figure 3.34 is a flow chart of the Directed Forwarding Echo procedure.

Figure 3.34. Directed Forwarding Echo procedure

When the Path Echo timer corresponding to a Forwarding Table entry expires, the Path Origin shall send a PATH_ECHO_REQUEST message to the Destination value of the Forwarding Table entry in order to validate the path.

The Network PDU for the PATH_ECHO_REQUEST message shall have the following configuration:

• The DST field shall be set to the Destination value of the Forwarding Table entry.

• The TTL field shall be set to 0x7F.

The Path Origin shall send the message using the directed security credentials of the subnet over which the message is sent and shall tag the message with the immutable-credentials tag.

When the message is sent, an instance of the Path Echo Reply Timeout timer corresponding to the Forwarding Table entry shall be started from the initial value indicated by the default value of the Path Discovery Interval state (see Section 4.2.38.3).

When a Path Target receives a PATH_ECHO_REQUEST message, the node shall check whether a Forwarding Table entry that corresponds to the PATH_ECHO_REQUEST message exists as defined in Section 3.6.8.5.6.

If a Forwarding Table entry that corresponds to the PATH_ECHO_REQUEST message does not exist, the message shall be discarded. Otherwise, the Path Target shall prepare and send a PATH_ECHO_REPLY message to the Path Origin with the Destination field set to the DST field value of the PATH_ECHO_REQUEST message.

The Network PDU for the PATH_ECHO_REPLY message shall have the following configuration:

• The DST field shall be set to the primary element address of the Path Origin.

• The TTL field shall be set to 0x7F.

If the Backward_Path_Validated value in the Forwarding Table entry is 0, the Path Target shall send the message using the managed flooding security credentials of the subnet over which the message is sent; otherwise, the Path Target shall send the message using the directed security credentials of the subnet over which the message is sent.

When the Path Origin receives the PATH_ECHO_REPLY message, the node shall check whether a Forwarding Table entry that corresponds to the PATH_ECHO_REPLY message exists as defined in Section 3.6.8.5.7.

If the Forwarding Table entry that corresponds to the PATH_ECHO_REPLY message does not exist; or if the Forwarding Table entry that corresponds to the PATH_ECHO_REPLY message exists, and the corresponding Path Echo Reply Timeout timer is not running, then the PATH_ECHO_REPLY message shall be discarded.

If the Forwarding Table entry that corresponds to the PATH_ECHO_REPLY message exists, and the corresponding Path Echo Reply Timeout timer is running, then the Path Echo Reply Timeout timer shall be stopped, and the Directed Forwarding Echo procedure succeeds. In addition, if the destination is a unicast address and the Unicast Echo Interval state is greater than 0 (see Section 4.2.32.1), or if the destination is a group address or a virtual address and the Multicast Echo Interval state is greater than 0 (see Section 4.2.32.2), then the node shall start an instance of the Path Echo timer for the Forwarding Table entry from the initial value set as defined in Section 4.2.32.

When the Path Echo Reply Timeout timer expires, the Directed Forwarding Echo procedure fails.

When the Directed Forwarding Echo procedure fails, the Forwarding Table entry corresponding to the failed Directed Forwarding Echo procedure shall be deleted and the Forwarding Table Update Identifier state (see Section 4.2.29.1) shall be changed.

3.6.8.2.7. Directed Forwarding Solicitation

The Directed Forwarding Solicitation procedure is executed by a Directed Forwarding node or by a Configuration Manager to solicit the discovery of paths toward unicast addresses, group addresses, or virtual addresses.

The Directed Forwarding Solicitation procedure shall be executed by a Directed Forwarding node in any of the following contexts:

• The Subscription List state of the Directed Forwarding node has been updated with new addresses.

• The Directed Forwarding node receives a PATH_REQUEST_SOLICITATION message.

The procedure is also executed if the Directed Forwarding node is a supporting node, and it is notified of new group addresses or virtual addresses to which its dependent node is subscribed. The conditions that trigger the Directed Forwarding Solicitation procedure in this case are listed in Section 3.6.8.3.

The Directed Forwarding Solicitation procedure should be executed by a Path Target that may no longer be reachable via existing paths (e.g., because the device has been physically moved).

Figure 3.35 is a flow chart of the Directed Forwarding Solicitation procedure.

Figure 3.35. Directed Forwarding Solicitation procedure

When the Directed Forwarding Solicitation procedure starts, a PATH_REQUEST_SOLICITATION message shall be prepared and sent with the following configuration:

• The Addr_List field shall contain a list of unicast addresses, group addresses, and virtual addresses that are intended destinations of the path discovery.

The Network PDU for the PATH_REQUEST_SOLICITATION message shall have the following configuration:

• The DST field shall be set to the all-directed-forwarding-nodes fixed group address (see Section 3.4.2.4).

• The TTL field shall be set to 0x7F.

The Network PDU shall be sent using the directed security credentials of the subnet over which the message is sent and shall be tagged with the immutable-credentials tag.

When a node receives a PATH_REQUEST_SOLICITATION message, the node checks whether a non-fixed path entry in the Forwarding Table state that corresponds to the PATH_REQUEST_SOLICITATION message exists as defined in Section 3.6.8.5.9.

If a Forwarding Table entry that corresponds to the PATH_REQUEST_SOLICITATION message exists, the node shall delete the entry from the Forwarding Table state and shall create a Path Origin State Machine (see Section 4.4.7.2) for each of the destinations in the Addr_List field of the PATH_REQUEST_SOLICITATION message.

If a Forwarding Table entry that corresponds to the PATH_REQUEST_SOLICITATION message does not exist, the message shall be discarded.

3.6.8.2.8. Examples of Transport Control message exchange and updates to the Forwarding Table state

Figure 3.36 shows an example of the Transport Control message exchange and updates to the Forwarding Table state that are reported during Directed Forwarding Initialization, Directed Forwarding Discovery, and Directed Forwarding Establishment procedures between two nodes (Nodes A and B). Node A creates a Discovery Table entry for the path from Node A to Node B and transmits a PATH_REQUEST message. Node B receives the message, creates a Discovery Table entry for the path, and stores the address of Node A in the Next_Toward_Path_Origin field. After the Path Reply Delay timer expires, Node B creates a Forwarding Table entry for the path and transmits a PATH_REPLY message to Node A. When Node A receives the PATH_REPLY message, it creates a Forwarding Table entry for the path and starts using directed forwarding to transmit messages.

Figure 3.36. Example of directed forwarding procedures during the establishment of a path between two nodes

Similarly, Figure 3.37 shows an example of the exchange of Transport Control messages and updates to Forwarding Table states that are reported during the Directed Forwarding Initialization, Directed Forwarding Discovery, and Directed Forwarding Establishment procedures.

In this example, the Transport Control messages are exchanged among Node A and two other nodes (Nodes C and D), which are subscribed to group address G, via an intermediate node (Directed Relay B) in the following sequence:

1. Node A creates a Discovery Table entry for the path to group address G and transmits a PATH_REQUEST message.

2. Directed Relay B receives the message, creates a Discovery Table entry for the path, stores the address of Node A in the Next_Toward_Path_Origin field, and then forwards the PATH_REQUEST message.

3. Both Node C and Node D receive the PATH_REQUEST message and create a Forwarding Table entry associated with the path to group address G.

4. When the Path Reply Delay timer at Node C expires, Node C creates a Forwarding Table entry and transmits a PATH_REPLY message to Directed Relay B.

5. Directed Relay B creates a Forwarding Table entry and transmits a PATH_REPLY message to Node A.

6. When the Path Reply Delay timer at Node D expires, Node D creates a Forwarding Table entry and transmits a PATH_REPLY message to Directed Relay B.

Directed Relay B does not perform additional actions because it already stores a Forwarding Table entry for the path to group G.

Figure 3.37. Example of directed forwarding procedures for the establishment of paths via a Directed Relay node to two nodes that are subscribed to a group address

In directed forwarding, node dependence is a relationship between two nodes in a subnet, a dependent node and a supporting node. A supporting node performs the following actions on behalf of a dependent node:

A supporting node can have many dependent nodes.

Node dependence within a subnet includes the following scenarios:

Directed forwarding procedures at a supporting node can be initiated when a Network PDU is received from the dependent node, as described in Section 3.4.6.3.

If a Network PDU received from a dependent node is retransmitted by a supporting node (see Section 3.4.6.3), and a path to the destination does not exist (see Section 3.6.8.5.1), the supporting node shall create a Path Origin State Machine (see Section 4.4.7.2).

If the supporting node is a Directed Friend node, the following behaviors apply:

If the supporting node is a Directed Proxy node, the following behaviors apply:

If the supporting node is a Subnet Bridge node, the following behaviors apply:

3.6.8.3.1. MSC example

The MSC in Figure 3.38 illustrates message sequencing for a Directed Friend interacting with a Low Power Node. The friendship is established over subnet 1, and the illustrated Directed Friend is configured as a supporting node for the dependent node on the subnet 1.

Figure 3.38. Directed Friend and Low Power Node interaction example

Each node manages a forwarding number for each subnet. The forwarding number is used to distinguish Transport Control messages sent by a node in the context of different Directed Forwarding Initialization procedures. This enables discarding of outdated messages (with an old forwarding number), discovery of new lanes (with the same forwarding number), and creation of new paths (with a new forwarding number).

When a node is added to a subnet, the forwarding number for that subnet shall be set to 255. Before a Directed Forwarding Initialization procedure is executed, the forwarding number shall be set according to the following equation:

The following comparison shall be performed to determine whether one forwarding number is less than, equal to, or greater than another forwarding number:

For example, forwarding numbers 1 to 127 are greater than forwarding number 0, but forwarding numbers 128 to 255 are less than forwarding number 0.

A Forwarding Table stores pairs of source and destination addresses for each path that a Directed Forwarding node is part of. The node is part of a path if it is the Path Origin, the Path Target, or any intermediate Directed Relay node. The Forwarding Table is represented by the Forwarding Table state (see Section 4.2.29). The Directed Forwarding node stores a separate Forwarding Table for each subnet it belongs to. The Forwarding Table initially is empty when the node is added to a new subnet.

Each Directed Forwarding node filters Network PDUs to be retransmitted using the directed security credentials based on its Forwarding Table state (see Section 3.4.6.3). The Forwarding Table state can be updated by directed forwarding procedures that the node executes (see Section 3.6.8.1) and by configuration messages received from a Configuration Manager (see Section 4.3.5).

Section 3.6.8.5.1 defines the correspondence between a Forwarding Table entry and a path. This definition is valid for both fixed paths (i.e., the Fixed_Path value in the Forwarding Table entry is 1) and non-fixed paths (i.e., the Fixed_Path value in the Forwarding Table entry is 0).

Sections 3.6.8.5.2 through 3.6.8.5.9 describe how the processing of Transport Control messages and expiration of timers in directed forwarding results in the addition, modification, or deletion of non-fixed path entries in the Forwarding Table state.