Mesh Protocol

In the development of a specification, the Bluetooth SIG has established the following conventions for use of the terms “shall”, “shall not”, “should”, “should not”, “may”, “must”, and “can”. In this Bluetooth specification, the terms in Table 1.1 have the specific meanings given in that table, irrespective of other meanings that exist.

Certain terms used in this specification have been updated and are no longer used by Bluetooth SIG. For a list of terms that have been updated and their replacement terms, see the Appropriate Language Mapping Tables [25].

Where a field in a packet, Protocol Data Unit (PDU), or other data structure is described as "Reserved for Future Use" (irrespective of whether in uppercase or lowercase), the device creating the structure shall set its value to zero unless otherwise specified in this specification. Any device receiving or interpreting the structure shall ignore that field unless otherwise specified in this specification; in particular, it shall not reject the structure because of the value of the field.

Where a field, parameter, or other variable object can take a range of values and some values are described as "Reserved for Future Use," a device sending the object shall not set the object to those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or it is specified to ignore unrecognized values.

When a field value is a bit field, unassigned bits can be marked as Reserved for Future Use and shall be set to 0. Implementations that receive a message that contains a Reserved for Future Use bit that is set to 1 shall process the message as if that bit was set to 0, except where specified otherwise in this specification.

The acronym RFU is equivalent to "Reserved for Future Use."

When a field value is an enumeration, unassigned values can be marked as “Prohibited.” These values shall never be used by an implementation, and any message received that includes a Prohibited value shall be ignored and shall not be processed and shall not be responded to, unless otherwise specified in this specification.

Where a field, parameter, or other variable object can take a range of values, and some values are described as “Prohibited,” devices shall not set the object to any of those Prohibited values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous, unless otherwise specified in this specification.

“Prohibited” is never abbreviated.

Unless otherwise stated, requirements that are in a table in this specification can be defined as "Mandatory" (M), "Optional" (O), "Excluded" (X), or "Conditional" (C.n). Conditional statements (C.n) are listed directly below the table in which they appear.

Where a cell in a table indicates an intended absence of a value or other content, the cell will contain “none” or a hyphen (i.e., a “minus” sign). Examples of this are:

An empty cell in a table indicates that there is no useful information that can be placed in that cell. Examples of this are:

Models are used to standardize the operation of typical user scenarios.

The model layer specifies the rules for allocating models on elements within a node.

The model layer also includes models which are defined in the Mesh Model specification [9] or in other higher-layer specifications.

The foundation model layer defines the states, messages, and models required to configure and manage a mesh network.

The access layer defines how higher layer applications can use the upper transport layer. It defines the format of the application data; it defines and controls the application data encryption and decryption performed in the upper transport layer; and it checks whether the incoming application data has been received in the context of the right network and application keys before forwarding it to the higher layer.

The upper transport layer encrypts, decrypts, and authenticates application data and is designed to provide confidentiality of Access messages. It also defines how Transport Control messages are used to manage the upper transport layer between nodes, including when used by the Friend feature and by directed forwarding functionality.

The lower transport layer defines how upper transport layer messages are segmented and reassembled into multiple Lower Transport PDUs to deliver large upper transport layer messages to other nodes. It also defines a single message to manage segmentation and reassembly (SAR).

The network layer defines how transport messages are addressed towards one or more elements. It defines the Network PDU format that allows Transport PDUs to be transported by the bearer layer. The network layer decides whether to relay/forward Network PDUs, accept them for further processing, or reject them. It also defines how a Network PDU is encrypted and authenticated.

The bearer layer defines how Network PDUs are transported between nodes. There are two bearers defined, the connectionless advertising bearer and the connection-oriented GATT bearer (for connections established between nodes known as a Proxy Server and a Proxy Client). Additional bearers may be defined in the future.

A mesh network consists of nodes sharing four common resources:

A network can have one or more subnets that facilitate ”area” isolation (e.g., isolated hotel room subnets within a hotel network). A subnet is a group of nodes that can communicate with each other at a network layer because they share a network key. A node may belong to one or more subnets by knowing one or more network keys. At the time of provisioning, a device is provisioned to one subnet and may be added to more subnets using the Configuration Model.

A node that belongs to multiple subnets may support subnet bridge functionality. A node supporting subnet bridge functionality may be configured to retransmit messages from nodes in a subnet to nodes in other subnets, while attempts to reach unauthorized addresses are blocked. The second subnet, the one on which the messages are retransmitted, is referred to as a bridged subnet.

There is one special subnet called the primary subnet, which is based on the primary NetKey (see Section 3.9.6.4). Nodes on the primary subnet participate in the IV Update procedure (see Section 3.11.5), and propagate IV updates to other subnets, while nodes on other subnets only propagate the IV Index updates to those subnets.

The network resources are managed by a node, known as the Configuration Manager (typically a smart phone or other mobile computing device), which implements the Configuration Client model and optionally implements any of the Remote Provisioning Client and Directed Forwarding Configuration Client models. The network resources are allocated to nodes at the time of configuration. In particular, a Provisioner manages allocation of addresses to make sure no duplicate unicast addresses are allocated, whereas a Configuration Manager generates and distributes network and application keys and makes sure that devices that need to communicate with each other share proper keys for both network and access layers. The Configuration Manager also knows device keys (see Section 3.9.6.1), which are used to secure communication with each individual node, including distributing updated network and application keys.

In the context of this specification, a device is a Bluetooth end product. A device that is not a member of a mesh network is known as an unprovisioned device. A device that is a member of a mesh network is known as a node. A device that is used to manage the transitions between an unprovisioned device and a node is known as a Provisioner.

An unprovisioned device cannot send or receive mesh messages; however, it advertises its presence to Provisioners. The process of authenticating and providing basic information, including unicast addresses (see Section 3.4.2.2) and a network key (see Section 3.9.6.3) to an unprovisioned device is known as provisioning (see Section 2.2.3). A Provisioner will provision an unprovisioned device into a mesh network, converting the unprovisioned device into a node.

A node that implements the Configuration Client model (see Section 4.4.2) can start acting as a Configuration Manager when the Provisioner provides the node with the device keys of the nodes on the network. The Configuration Manager can then configure the nodes by providing them application keys (see Section 3.9.6.2) and setting publish and subscribe addresses (see Section 2.3.9) so that the nodes can communicate with each other.

A Configuration Manager, which is the same physical device as the Provisioner, is known as a Mesh Manager. A Configuration Manager can remove a node from a mesh network, which reverts it back to an unprovisioned device.

A device may support multiple instances of a node by offering itself to be provisioned to another mesh network after already being provisioned to a mesh network. Each instance of a mesh network is determined by addresses and a device key obtained by the device during provisioning.

Devices are added to a mesh network by a Provisioner, at which point they become nodes. The provisioning of devices into a mesh network differs from the point-to-point bonding and pairing that is typically used in Bluetooth wireless technology. Provisioning of devices is enabled using either a simple advertising bearer or a point-to-point GATT-based bearer. A single provisioning protocol is used over both bearers. Provisioning over an advertising-based bearer is implemented by all devices. Provisioning over a GATT-based bearer allows devices such as legacy phones (i.e., devices that do not support provisioning over an advertising bearer natively) to be Provisioners.

To assist with provisioning of multiple devices, a device has an attention timer that can be set by a Provisioner. When set to a non-zero value, the device identifies itself using any means it can. For example, the device may flash a light, make a sound, or vibrate. When the attention timer expires, the device stops identifying itself. This allows a Provisioner to send a single message to a device to cause it to identify itself and the device automatically stops identifying itself after a given time.

The protocol to run over these two bearers is a derivative of the Security Manager protocol of v4.2 of the Bluetooth Core Specification to introduce the ability to authenticate devices that have a very limited user interface, such as a light or a switch. The Security Manager protocol requires a reliable bearer, something that cannot be guaranteed by the advertising provisioning bearer; therefore the protocol used in this specification is designed to enable reliable delivery of messages independent of the bearer. The similarity to the Security Manager protocol enables significant reuse of existing code on devices that have implemented such functionality.

Many current devices are unable to advertise or comprehend mesh messages without being updated. To enable these devices to communicate with a node in a mesh network without the need for an operating system update or similar hardware/software update, the specification enables the use of GATT connectivity for all existing devices.

The features within this specification enable many devices in the mesh network to be battery-powered or to use techniques such as energy harvesting. Such devices may be constrained in how they can function as a part of a mesh network (e.g., devices that only send data when interacted with). This specification does not require devices to coordinate transmissions, make connections, or restart security on every connection; thus facilitating low power operation. Devices needing low power support can associate themselves with an always-on device that stores and relays messages on their behalf, using the concept known as friendship (see Section 3.6.6). However, devices that relay messages will receive messages as well as forward messages a majority of the time and are likely to use significantly more power than could be provided by typical small batteries or capacitors.

A state is a value representing a condition of an element or a node. A state may be valid in the context of a subnet or of one or more models.

An element exposing a state is referred to as a server. For example, the simplest server is a Generic OnOff Server, representing that it is either on or off.

An element accessing a state is referred to as a client. For example, the simplest client is a Generic OnOff Client (a binary switch) that is able to control a Generic OnOff Server via messages defined by the Generic OnOff Model.

A state that is made of two or more states is known as a composite state. For example, a color-changing lamp can control color hue separately from color saturation and brightness.

When a state is bound to another state, a change in one results in a change in the other. Bound states may be from different models in one or more elements. For example, a common type of binding is between a Level state and an OnOff state: changing the Level to 0 changes the bound OnOff state to Off and changing the Level to a non-zero value changes the bound OnOff state to On.

All communication within a mesh network is accomplished by sending messages. There are two types of messages: Access messages and Transport Control messages.

Access messages operate on states. For each state, there is a defined set of Access messages that a server supports and a client may use to request a value of a state or to change a state. A server may also transmit unsolicited Access messages carrying information about states and/or changing states.

An Access message is defined as having an opcode, associated parameters, and behavior. An opcode may be a single octet (for special Access messages that require the maximum possible payload for parameters), 2 octets (for standard Access messages), or 3 octets (for vendor-specific Access messages).

A total Access message size, including an opcode, is determined by the underlying transport layer, which may use a SAR mechanism. To maximize performance and avoid the overhead of SAR, a design goal is to fit Access messages in a single segment. The lower transport layer provides up to 11 octets for a non-segmented message, leaving up to 10 octets that are available for parameters when using a 1-octet opcode, up to 9 octets available for parameters when using a 2-octet opcode, and up to 8 octets available for parameters when using a vendor-specific 3-octet opcode.

The lower transport layer provides a SAR mechanism capable of transporting up to 32 Access or Transport Control message segments. The maximum Upper Transport Access PDU size when using a SAR is 384 octets. This means that (excluding a TransMIC, see Section 3.9.7.1) up to 379 octets are available for parameters when using a 1-octet opcode, up to 378 octets are available for parameters when using a 2-octet opcode, and up to 377 octets are available for parameters when using a vendor-specific 3-octet opcode. The maximum Transport Control message size when using a SAR is 257 octets (including an opcode).

SAR effectively does not impose any extra overhead on the Access message per segment: a 10-octet Access message is transported as an unsegmented message, and a 20-octet message is transported as a segmented message that uses two segments.

Access message definitions contain tables of parameters. In a message payload, parameters follow an opcode, and parameter offsets are in octets unless otherwise specified.

Access messages are defined as acknowledged or unacknowledged. An acknowledged message requires a response whereas an unacknowledged message does not require a response.

Transport Control messages are associated with functionalities supported by the node. The Transport Control messages are transmitted and received by the upper transport layer. A Transport Control message is defined as having an opcode, associated parameters, and behavior. Transport Control messages use single-octet opcodes.

The lower transport layer provides a mechanism of SAR that is capable of transporting up to 32 segments of a Transport Control message.

Transport Control message definitions contain tables of parameters. In a message payload, parameters follow an opcode, and parameter offsets are in octets unless otherwise specified.

An element is an addressable entity on a node. Each node has at least one element, the primary element, and may have up to 254 additional secondary elements. The number and structure of elements is static and does not change throughout a term of a node (see Section 2.3.7).

The primary element is addressed using the first unicast address assigned to the node. Each additional secondary element is addressed using the subsequent addresses assigned to the node. The unicast element addresses allow nodes to identify which element on a node is transmitting or receiving a message.

If the number and structure of elements changes, for example due to a firmware update or a functionality being added by attaching a new physical component to the device, the current term of the node must end and a new term for the node must start, as required by Section 4.2.2.1.

Messages are dispatched within models based on opcodes and element addresses.

An element is not allowed to contain multiple instances of models that use the same message in the same way (for example, receive an “On” message). When multiple models within the same element use the same message, the models are said to “overlap.” To implement multiple instances of overlapping models within a single node (for example, to control multiple light fixtures that can be turned on and off), the node is required to contain multiple elements.

For example, a light fixture may have two lamps, each implementing an instance of the Light Lightness Server model and an instance of the Generic Power OnOff Server model. This requires that the node contain two elements, one for each lamp. When it receives an "On" message, the node uses the unicast address of the element to identify which instance of the Generic Power OnOff Server model the message is addressed to.

In another example, a dual-socket power strip contains two independent energy measurement sensors that can measure power consumed by an appliance connected to a socket. This would require that the node have two Sensor Data states, each in a separate element. The first element, the primary element, would be identified using the unicast address for the node and would include a state for the first energy sensor as well as states representing the configuration of the node. The second element, a secondary element, would be identified using a unicast element address and would include the state for the second energy sensor.

Each element has a GATT Bluetooth Namespace Descriptor [4] value that helps identify which part of the node this element represents. These namespace descriptor values use the same definitions as GATT. For example, the elements of the temperature sensor would use the values “inside” and “outside.”

An address may be a unicast address, a virtual address, or a group address. There is also a special value to represent an unassigned address that is not used in messages.

A unicast address is allocated to an element and always represents a single element of a node during a term. There are 32767 unicast addresses per mesh network.

A virtual address is a multicast address and can represent multiple elements on one or more nodes. Each virtual address logically represents a Label UUID, which is a 128-bit value that does not have to be managed centrally. Each message sent to a Label UUID includes the full Label UUID in the message integrity check value that is used to authenticate the message. To reduce the overhead of checking every known Label UUID, a hash of the Label UUID is used. There are 16384 hash values, each of which codifies a set of virtual addresses. While there are only 16384 hash values used in a virtual address, each hash value can represent millions of possible Label UUIDs; therefore, the number of virtual addresses is considered very large.

A group address is a multicast address and can represent multiple elements on one or more nodes. There are 16384 group addresses per mesh network. There are a set of fixed group addresses that are used to address a subset of all primary elements of nodes based on the functionality of those nodes. All other group addresses are known as dynamically assigned group addresses. There are 256 fixed group addresses and 16128 dynamically assigned group addresses.

A model defines the basic functionality of a node. A node may include multiple models. A model defines the required states (as described in Section 2.3.1), the messages that act upon those states (as described in Section 2.3.3), and any associated behavior.

A mesh application is specified using a client-server architecture communicating with a publish-subscribe paradigm. Due to the nature of mesh networks and the recognition that the configuration of behavior is performed by a Configuration Manager, an application is not defined in a single end-to-end specification such as a profile. Instead, an application is defined in a client model and a server model.

This specification defines two types of model: server models and client models:

A single device may include server models and/or client models. In addition, some models may contain both client and server functionality as described below.

This specification defines the following relationships among models:

This specification defines the following types of models:

For example, Figure 2.2 shows the element-model structure for a device that implements a server model (Device C) with a state and supporting messages R, S, T, X, Y, Z; and two devices that implement a client model, with Device A supporting messages X, Y, and Z and Device B supporting messages R, S, T, and Z.

Figure 2.2. Client-server model communication

In another example, Figure 2.3 shows the element-model structure of a device that implements a model that is itself a server model and also a client of some other server models. Device C can communicate with server models as a client (supporting messages X, Y, and Z and messages R, S, and T respectively) and can communicate with client models as a server (supporting messages A, B, and C).

Figure 2.3. Control model communication

A lighting control model is an example of a model that includes server functionality, client functionality, and control logic. A typical lighting control model needs to function as a client to sensors (e.g., to determine occupancy and/or the ambient light level by receiving relevant sensor status messages) and to function as a server to a settings client (such as a smartphone application that configures its parameters). Control logic in such a model may then control the lighting via defined state bindings if the model is included within a light source such as a lamp or other luminaire. In addition, if the lighting controller also acts as a client for one or more light sources, the lighting controller can be implemented in a separate node rather than necessarily being included within a light source.

Models can define functions of a device as a network node, such as key management, address assignment, and relaying of messages. Models also define physical behaviors of a device built around a network node, such as power control, lighting control, and sensor data collection. There may be nodes implementing only network-related functions, such as Relay nodes or Proxy nodes, while the majority of nodes are able to interact with the physical world by means of controlling electrical power, controlling light emissions, or sensing environmental data.

A message can be used by multiple different models. Message behavior is the same in each model, enabling a common understanding among client and server models because the behavior is consistent regardless of the models that send and process the message.

Model specifications are designed to be very small and self-contained. A model may, at the specification definition time, require other models to be instantiated within the same node. This is called extending, which means a model can extend other models.

Models that do not extend other models are referred to as root models.

Model specifications are immutable: it is not possible to remove or add behavior to a model, whether the desired behavior is optional behavior or mandatory. Models are not versioned and have no feature bits. If additional behavior is required in a model, then a new extended model is defined that exposes the required behavior and can be implemented alongside the original model.

Therefore, knowledge of the models supported by an element determines the exact behavior exposed by that element.

Additionally, models may support metadata that provide additional information about a specific instance of the model. For example, the lighting control model may expose information about the purpose of the light source in the physical device.

Models may be defined and adopted by Bluetooth SIG and may be defined by vendors. Models defined by Bluetooth SIG are known as SIG adopted models, and models defined by vendors are known as vendor models. Models are identified by unique identifiers, which can be either 16 bits, for SIG adopted models, or 32 bits, for vendor models.

For example, Figure 2.4 shows the element-model structure of a device that implements a root model with two bound states and a set of messages operating on each state. The root model is within the primary element and is extended by the extended model that adds another state on a secondary element. Messages are not capable of differentiating among multiple instances of the same state on the same element. Therefore, when more than one instance of a given state is present on a device, each instance is required to be in a separate element. In this example, the second instance of State X is required to be located on the second element because it is the same type of a state and thus has the same types of messages serving it.

Figure 2.4. Element-model structure of a device

This example structure can be multiplied for a composite device. For example, a composite device can have multiple instances of the same root model (or extended models), each on a separate element (or set of elements). Also, if a model (root or extended) needs more than one instance of a particular state, the states are distributed across several elements so that, at most, a single instance of any given state is on an element.

Figure 2.5 illustrates how the element-model structure of the device in Figure 2.4 might be implemented in a composite device. The element-model structure of the device is described by the Composition Data (see Section 4.2.1) that is read by a Configuration Manager after provisioning (see Section 5), using the Configuration Server model and the Configuration Client model (see Sections 4.4.1 and 4.4.2).

Figure 2.5. Element-model structure of a composite device

A term is a period in the lifetime of a node during which the structure of the node (i.e., the features, the elements and models) and the unicast addresses of the node’s elements do not change.

Starting a new term may be necessary to support a change in the hardware configuration of a physical device, such as the attachment of an auxiliary sensor, or to support a change in subsystem configuration on the node, such as the attachment of a new gear to an intra-luminaire network. The changes are indicated by the node by populating Composition Data Page 128 (see Section 4.2.2.4) and take effect when a new term starts.

The initial term of a node on a network starts when the node is provisioned on the network.

A term ends and a new term starts when a Node Address Refresh procedure or a Node Composition Refresh procedure is executed (see Section 3.11.8).

The last term of a node on a network ends when the node is removed from the network.

To help explain how the arrangement of models within elements determines the state and behavior of a device, we will use a dual-socket smart power strip device (shown in Figure 2.6) as an example. This device has a single radio that has the low energy feature of Bluetooth and two independent power sockets, each capable of controlling the power output. This example includes states, messages, and models defined in the Mesh Model specification [9].

Figure 2.6. Dual-socket smart power strip

The device has two elements (see Section 2.3.4) that represent each of the two power sockets. Each element has a unicast address assigned to it.

The functionality of each element is defined by the Generic Power Level Server model. The model defines a set of states on a server, as well as a set of messages that operate on the states.

A Generic Power Level Set message may be sent to the device to control the output power. The message is addressed to an element and carries the element’s address in the DST field (see Section 2.3.9).

The sockets can also be controlled by generic devices (such as a dimmer) that implement the Generic Level Client model (and do not know anything about power control). This model simply sets a desired level to zero, a maximum value, or a value in between. Power to the sockets is controlled through state binding. In each power socket, the Generic Power Actual state is bound to the Generic Level state. A Generic Level Client sends Generic Level messages to the Generic Level Server. The Generic Level state is changed, which in turn (via the defined binding) changes the Generic Power Actual state that controls the power output.

Elements can report states. In our example, each socket may report power level as well as the energy consumption of a device plugged into the socket. Energy consumption is reported using messages defined by the Sensor Server model. Each message has the element’s address, which identifies the socket, in its SRC field (see Section 3.4.4.6).

Figure 2.7 illustrates the element-model structure for the dual-socket device. Functionally, both elements of the device have identical features. The only difference is that the primary element handles the Configuration Server model, which is used for network management, in addition to the other models. Each element may have other models defined such as the Health Server model (see Section 4.4.4) or models defined in the Mesh Model specification [9].

Figure 2.7. Element-model structure for the example device

Publication and subscription of data within the mesh network is described as using a publish-subscribe paradigm. Nodes that generate messages publish the messages to a unicast address, group address, or virtual address. Nodes that are interested in receiving the messages will subscribe to these addresses.

Generated messages are sent to destination mesh addresses that can be unicast, pre-configured group addresses, or virtual addresses. Messages can be sent as replies to other messages or can be unsolicited messages. When an instance of a model is sending a reply message, it uses the incoming message originator’s source address as the destination address. When an instance of a model is sending unsolicited messages, it uses a model publish address as the destination address. Each instance of a model within a node has a single publish address.

On the receiving side, each instance of a model within a node can subscribe to one or more group addresses or virtual addresses. Whenever a message that is addressed to a group address or a virtual address on one of the model’s subscription lists arrives, it is processed by the node. A message is also processed when its destination address is the unicast address of a receiving element or when its destination address is a fixed group address that this device is a member of. If a node has multiple elements, then the message is processed once on each of the addressed elements.

Publish addresses and subscription lists for models defined by higher layer specifications use the Model Publication and Subscription List states that are managed by the Configuration Server Model.

A node can have multiple subscriptions per instance of a model’s element, although nodes may limit the number of subscriptions that are supported. Using multiple subscription addresses allows a node to respond to messages that are published to different groups. For example, a light may be subscribed to messages sent to the bedside light group, the bedroom group, the upstairs group, and the house group.

Each message is sent from a single unicast address (an element address) and sequenced using a unique sequence number to facilitate detection of and protection against replay attacks.

All messages are encrypted and authenticated using two types of keys. One key type is for the network layer communication, such that all communication within a mesh network would use the same network key. The other key type is for application data. Separating the keys for networking and applications allows different application keys for different purposes. This allows the creation of separate security domains for separate applications (e.g., one domain for access control to a building and another domain for ambient temperature sensing).

Directed forwarding is designed to help improve performance of a multi-hop network by selecting only a subset of nodes to relay a message from a source to a destination. This subset, including the source node and the destination node(s), constitutes a path, as defined by directed forwarding. A path is identified by a pair of addresses: a source address and a destination address. The destination address may be a unicast address, a group address, or a virtual address.

The source node of a path is the Path Origin, and each destination node of a path is a Path Target (see Section 3.6.8.1).

The Path Origin is configured to use managed flooding or directed forwarding when originating a message (see Section 3.7.3.1). Managed flooding and directed forwarding use different security materials, respectively the managed flooding security material and the directed security material, which are obtained from the same network key (see Section 3.9.6.3.1).

A directed forwarding node uses a forwarding table to store pairs of source and destination addresses for each path it is part of. There is a separate forwarding table for each subnet. When a message is received by a node that is configured to relay messages using directed forwarding, the node compares the source and destination addresses of the message against the entries in the table and retransmits the message only if there is a match. That restricts message forwarding only to nodes along an established path.

Nodes forming a path may be explicitly configured by a Configuration Manager or a path may be discovered and maintained following the request of a node that is originating messages. To help improve reliability and resilience, a path may have multiple lanes between source node and destination node(s) that take advantage of several relays overhearing a message relayed on each hop. Lanes of a path are discovered sequentially. The path discovery and maintenance policy of an originator is configured by the Configuration Manager and controls aspects such as path lifetime, verification and rediscovery cadence, the number of redundant lanes, and whether the paths are unidirectional or bidirectional.

Directed forwarding nodes, known as supporting nodes, may act on behalf of Low Power nodes or Proxy Client nodes, known as dependent nodes, to discover paths, to establish paths, and to provide path updates when the network topology changes. For more information on node dependence, see Section 3.6.8.3.

There is no limitation on the number of directed forwarding relays in a network (other than the total number of nodes). When using directed forwarding, the message forwarding load may be distributed among several nodes. Each node may function as a directed forwarding relay: the node will only relay a portion of overall traffic.

Friendship is used by Low Power nodes to limit the amount of time that they need to listen. If a node cannot receive continuously, then it is possible that it will not receive mesh messages that it should be processing. This includes security updates required for maintaining the security of the network as well as the normal mesh messages.

If the Low Power node does not receive such messages, then it may not operate as desired and it may also fail to keep up-to-date with the latest security state of the network and eventually drop off the network if this security is changed without its knowledge.

Friendship is a special relationship between a Low Power node and one neighboring Friend node. These nodes must be within a single hop of each other and in the same subnet, as required by Section 3.6.6.3.1.

Friendship is first established and initiated by the Low Power node; once established, the Friend node performs a number of actions that help reduce the power consumption on the Low Power node. The Friend node maintains a Friend Queue for the Low Power node, which stores all incoming messages addressed to the Low Power node. The Friend node delivers those messages to the Low Power node when requested by the Low Power node. Also, the Friend node delivers security updates to the Low Power node.

When friendship is established between a Low Power node and one Friend node, the two nodes are considered to be “friends”.

An example topology of a mesh network illustrating Friend nodes and Low Power nodes is shown and described in Section 2.3.14.

The capabilities of a node are determined by the features and functionality that the node supports. All nodes have the ability to transmit and receive mesh messages. Nodes can also optionally support one or more additional features, as defined by the Configuration Server model:

A node that supports a feature may have that feature enabled or disabled, and the feature, when enabled, may be or may not be in use.

A node supporting the Relay feature may have this feature disabled, but it would still support the Relay feature, it is just that it is not performing the functionality required by that feature. A node that supports the Relay feature and has the Relay feature enabled is known as a Relay node.

Proxy functionality is supported by nodes that support relaying/forwarding of Network PDUs received by a node between GATT and advertising bearers. A node supporting the Proxy feature may have this feature disabled, but it would still support the Proxy feature, it is just that it is not performing the functionality required by that feature. A node that supports the Proxy feature and has the Proxy feature enabled is known as a Proxy node.

A node supporting the Low Power feature cannot have this feature disabled and, as required by Section 3.6.6.3, must establish a friendship with another node supporting the Friend feature before it can use the Low Power feature to reduce receiver duty cycles. A node that supports the Low Power feature and has a friendship with a node that supports the Friend feature is known as a Low Power node.

A node supporting the Friend feature may have this feature disabled, but it would still support the Friend feature, it is just that it is not performing the functionality required by that feature. A node that supports the Friend feature, has the Friend feature enabled, and has a friendship with a node that supports the Low Power feature is known as a Friend node.

Other Foundation models support additional functionality. For example, the Directed Forwarding Configuration Server model (see Section 4.4.7) supports directed forwarding functionality. Directed forwarding can be performed only among nodes in a subnet that have directed forwarding functionality enabled. A node with directed forwarding functionality enabled in a subnet is known as a Directed Forwarding node in that subnet.

Additional functionalities can be enabled or disabled in Directed Forwarding nodes:

Directed relay functionality can be enabled or disabled in nodes that support directed forwarding. A Directed Forwarding node with directed relay functionality enabled in a subnet is known as a Directed Relay node in that subnet (see Section 3.6.8.1).

Directed proxy functionality is supported by nodes that support both the Proxy feature and directed forwarding functionality; otherwise, it is not supported. When directed proxy functionality is supported, it can be enabled or disabled. A Directed Forwarding node with directed proxy functionality enabled in a subnet is known as a Directed Proxy node in that subnet (see Section 3.6.8.1).

Directed friend functionality is supported by nodes that support both the Friend feature and directed forwarding functionality. When directed friend functionality is supported, it can be enabled or disabled. A Directed Forwarding node with directed friend functionality enabled in a subnet is known as a Directed Friend node in that subnet (see Section 3.6.8.1).

A Directed Forwarding node that supports the Low Power feature in a subnet can perform directed forwarding in that subnet if the node is not in a friendship in the same subnet, because the node behaves like a regular node while not in a friendship. If the node is in a friendship with a Directed Friend node, then directed forwarding can be performed by the Directed Friend node. If the node is in a friendship with a Friend node that does not have directed friend functionality supported and enabled, then directed forwarding cannot be performed.

Subnet bridging can be performed only by a node that has subnet bridge functionality enabled. A node with subnet bridge functionality enabled is known as a Subnet Bridge.

Private Proxy functionality is supported by nodes that support the Proxy feature, Private Network Identity advertising (see Section 7.2.2.2.4), and Mesh Private beacons (see Section 3.10.4); otherwise, Private Proxy functionality is not supported. When Private Proxy functionality is supported, it can be enabled or disabled.

On-Demand Private Proxy functionality is supported by nodes that support On-Demand Private Proxy Server model (see Section 4.4.13) and Solicitation PDU with Identification Type equal to 0x00 (see Section 6.9.1); otherwise, On-Demand Private Proxy functionality is not supported.

Node Identity functionality is supported by nodes that support exchange of Network PDUs between two nodes connected via GATT; otherwise, Node Identity functionality is not supported.

Private Node Identity functionality is supported by nodes that support Node Identity functionality and Advertising with Private Node Identity (see Section 7.2.2.2.5); otherwise, Private Node Identity functionality is not supported.

Nodes that support the various features described above can be formed into a mesh network. An illustration of a mesh network is shown in Figure 2.8 below.

Figure 2.8. Example topology of a mesh network

Figure 2.8 shows three Relay nodes: Q, R, and S. Although three nodes N, O, and P support the Friend feature, node N does not have any friendships, and therefore, only O and P are Friend nodes. There are five Low Power nodes: I, J, K, L, and M. Nodes I, J, and K have node P as their friend, while nodes L and M have node O as their friend. Node T is connected to the mesh network using a GATT bearer; therefore, node S retransmits all messages to and from node T.

For example, if a message is to be sent from T to L, then T will send the message to node S using the GATT bearer. Node S will retransmit this message using the advertising bearer. Nodes H, R, N, and O are within radio range of node S; therefore, they will receive this message. Node O, being the friend of node L will store the message, and if the message was a segmented message, node O will respond with an acknowledgment at the lower transport layer. Sometime later, L will poll node O to check for new messages, such that O will forward the message originally sent by T to L.

Figure 2.9. Example topology of a mesh network using directed forwarding between a source node M and a destination node H.

Figure 2.9 shows the same topology in Figure 2.8, used in the context of directed forwarding between a source node M and a destination node H. Node M is a Low Power node and is in friendship with node O. Node O implements directed friend functionality and establishes a 2-lane path on behalf of node M toward the destination node H. Nodes A, C, E, G, N, Q, R, and S support directed relay functionality, but only node R and node S are in the path between node M and node H. Therefore, regardless of the number of Directed Relay nodes, traffic is confined within the established paths. In this example, nodes E, G, N, and Q do not relay messages from node M to node H, even if they overhear them.

For the network layer, lower transport layer, upper transport layer, mesh beacons, and Provisioning, all multiple-octet numeric values shall be sent in big-endian, as described in Section 3.1.1.1.

For the access layer and Foundation Models, all multiple-octet numeric values shall be little-endian as described in Section 3.1.1.2.

Where network data structures are made of multiple fields, the fields are listed in the tables from top to bottom and they appear in the corresponding figures from left to right (i.e., the top row of the table corresponds to the left of the figure). Table 3.1 shows an example data structure made up of multiple fields.

In order to convert the data structure defined in a table into a series of octets in the layer that uses big-endian the following procedure is used. The binary number with N unassigned bits is created. The number of bits N in the number is equal to the sum of the number of bits of every field in the table. The most significant bits (MSbs) of the number are set to the value of Field 0 (first row of the table), then the number’s unassigned MSbs are set to the value of Field 1. This procedure is continued for consecutive fields of the table and ends when least significant bits (LSbs) of the number are set to value of last field of the table. As a final step the number is transmitted in big-endian format (i.e., most significant octet first). This is illustrated in Figure 3.1.

Figure 3.1. Field ordering example: big-endian

For example, the field 0 is 4 bits wide and has value of 0x6, field 1 is 12 bits wide and has value 0x987, and field 2 is 16 bits wide and has value of 0x1234. The value of the binary number is 0x69871234 and shall be transmitted as 0x69, 0x87, 0x12, 0x34.

In order to convert the data structure defined in a table into a series of octets in the layer that uses little-endian the following procedure is used. The binary number with N unassigned bits is created. The number of bits N in the number is equal to the sum of the number of bits of every field in the table. The LSbs of the number are set to the value of Field 0 (first row of the table), then the number’s unassigned LSbs are set to the value of Field 1. This procedure is continued for consecutive fields of the table and ends when MSbs of the number are set to the value of last field of the table. As a final step the number is transmitted in little-endian format (i.e., least significant octet first). This is illustrated in Figure 3.2.

Figure 3.2. Field ordering example: little-endian

For example, the field 0 is 4 bits wide and has a value of 0x6, field 1 is 12 bits wide and has a value of 0x987, and field 2 is 16 bits wide and has a value of 0x1234. The value of the binary number is 0x12349876 and shall be transmitted as 0x76, 0x98, 0x34, 0x12.

This specification establishes definitions for terminology related to one-shot timers. A one-shot timer counts down from an initial value and when the counter reaches zero, the timer expires. The timer value is defined as the current value of the counter.

Table 3.2 establishes the definitions for actions that can be performed on a timer.

When the timer value reaches zero, the timer countdown stops and the timer expires. The timer expiration is an event that may have a behavior defined in this specification.

Table 3.3 establishes the definitions for checking timer status.

When using the advertising bearer, a mesh packet shall be sent in the ADV_NONCONN_IND PDU (see [1]) using the Mesh Message AD type identified by «Mesh Message» as defined in [4].

The format of the Mesh Message AD type is defined in Table 3.4.

ADV_NONCONN_IND PDUs are used because there is no need to include the Flags AD Type in the advertising packets, thereby enabling two additional octets to be allocated to the Network PDU (see [5]).

To lower the probability of packet collisions on all advertising channels, the gap between consecutive packets within an Advertising Event (see [1]) and the sequence of the used primary advertising channels within an Advertising Event (see [24]) should be randomized.

A device supporting only the advertising bearer should perform passive scanning with a duty cycle as close to 100 percent as possible in order to avoid missing any incoming mesh messages or Provisioning PDUs.

All devices shall support both the Observer and Broadcaster roles, which are defined in the Generic Access Profile (GAP) [1].

The GATT bearer is provided to enable devices that are not capable of supporting the advertising bearer to participate in a mesh network. The GATT bearer uses the Proxy protocol (see Section 6) to transmit and receive Proxy PDUs between two devices over a GATT connection.

The GATT bearer uses a characteristic to write to and receive notifications of mesh messages using the attribute protocol.

The GATT bearer defines two roles: a GATT Bearer Client and a GATT Bearer Server.

The GATT Bearer Client shall be a GATT Client and shall support the Proxy Client role (see Section 6.2.1). The GATT Bearer Server shall be a GATT Server and shall support the Proxy Server role (see Section 6.2.1).

The GATT Bearer Server shall instantiate one and only one Mesh Proxy Service, as defined in Section 7.2.

The GATT Bearer Client shall support the Mesh Proxy Service.

The GATT Bearer Client shall perform primary service discovery using either the GATT Discover All Primary Services sub-procedure or the GATT Discover Primary Services by Service UUID sub-procedure to discover the Mesh Proxy Service.

As required by the GATT profile defined in Volume 3, Part G of the Core Specification [1], the GATT Bearer Client must be tolerant of additional optional characteristics in the service records of services used with the GATT profile.

The GATT Bearer Client shall use either the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover Characteristics by UUID sub-procedure to discover the characteristics of the service.

The GATT Bearer Client shall use the GATT Discover All Characteristic Descriptors sub-procedure to discover the characteristic descriptors, which are described in the following sections.

The GATT Bearer Client shall discover the Mesh Proxy Data In characteristic, Mesh Proxy Data Out characteristic and its Client Characteristic Configuration descriptor. Once the Client Characteristic Configuration descriptor has been discovered, it shall enable notifications using this characteristic.

To send a Proxy PDU (see Section 6.3), the GATT Bearer Client shall use the Write Without Response sub-procedure to write the Proxy PDU to the GATT Bearer Server by writing to the Mesh Proxy Data In characteristic.

To receive a Proxy PDU, the GATT Bearer Client shall be able to receive multiple notifications of the Mesh Proxy Data Out characteristic. Each notification contains a single Proxy PDU.

Figure 3.3 illustrates the GATT Bearer Server and network layer (see Section 3.4) interactions.

Figure 3.3. GATT Bearer Server and network layer interactions

All multiple-octet numeric values in this layer shall be sent in big-endian, as described in Section 3.1.1.1.

The network layer defines four basic types of addresses: unassigned, unicast, virtual, and group.

Addresses are 16 bits in length and are encoded as defined in Table 3.5 below.

3.4.2.1. Unassigned address

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.

3.4.2.2. Unicast address

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.1. Unicast address range format

A range of unicast addresses may be used in a message, for example, to communicate all the unicast addresses used by a node. In this case, the unicast address range format can be used to efficiently pack the range of unicast addresses. In the unicast address range format, the 15 least significant bits of the starting unicast address of the range and the number of addresses in the range are formatted as in Table 3.6.

Field Name	Bits	Description	Req.
LengthPresent	1	Indicates the presence or absence of the RangeLength field.	M
RangeStart	15	15 least significant bits of the starting unicast address	M
RangeLength	8	Number of addresses in the range (0x02 – 0xFF)	C.1

Table 3.6. Unicast address range format

C.1:

If the LengthPresent field value is 1, the RangeLength field shall be present; otherwise, the RangeLength field shall not be present.

The LengthPresent field indicates whether the address range contains a single address or multiple addresses. The LengthPresent field value shall be set to 1 when the number of addresses in the range of unicast addresses is greater than 1; otherwise, the LengthPresent field value shall be set to 0.

The RangeStart field shall contain the 15 least significant bits of the starting unicast address of the range of unicast addresses. The RangeStart field value shall not be 0.

If present, the RangeLength field shall contain the number of addresses in the range of unicast addresses. The valid values for the RangeLength field are 0x02 to 0xFF. The values of 0x00 and 0x01 are prohibited.

The sum of the RangeStart field value and the RangeLength field value shall not exceed 0x8000.

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

3.4.2.2.3. Matching an address to the unicast address range format

To check for the presence of a specific unicast address within the unicast address range format, the node shall convert the RangeStart field to the range start address by setting the 15 least significant bits of the range start address to the RangeStart field value and setting the most significant bit of the range start address to 0. If the LengthPresent field value is 1, the node shall compute the range end address by adding the RangeLength field value to the range start address; otherwise, the node shall increment the range start address by 1 to derive the range end address. A unicast address is matched to the unicast address range format if it is greater than or equal to the range start address and less than the range end address.

3.4.2.2.4. Converting to and from the unicast address range format

This section specifies the derivation of the primary element address and the number of secondary elements (i.e., the secondary elements count of a node) from the unicast address range format and, conversely, the derivation of the unicast address range format from the primary element address and secondary elements count.

Conversion to the unicast address range format

To derive the unicast address range format from the primary element address and the number of secondary elements, the node shall use the following procedure:

• If the node has secondary elements, the LengthPresent field value shall be 1; otherwise, the LengthPresent field value shall be 0.

• The RangeStart field shall be the 15 least significant bits of the primary element address of the node.

• If the node has secondary elements, the RangeLength field value shall be the number of secondary elements plus 1; otherwise, the RangeLength field shall not be present.

For example, if a node has 5 secondary elements and the primary element address is 0x1234, then the value of the binary number of the unicast address range of the elements of the node and the sequence of octets for its transmission depend on the used endianness as follows:

• If big-endian is used (e.g., when sending a Transport Control message), the value of the binary number is 0x923406 and is transmitted as 0x92, 0x34, 0x06.

• If little-endian is used (e.g., when sending an Access message), the value of the binary number is 0x062469 and is transmitted as 0x69, 0x24, 0x06.

Conversion from the unicast address range format

To derive the primary element address and the number of secondary elements from the unicast address range format, the node shall use the following procedure:

• If the LengthPresent field value is 0, the number of secondary elements is 0; otherwise, the number of secondary elements is equal to RangeLength – 1.

• The 15 least significant bits of the primary element address of the node are equal to the RangeStart field. The most significant bit of the unicast address is always 0.

For example, if the unicast address range of a node is 0x1234, the node’s primary element address is 0x1234 and there are no secondary elements on the node.

3.4.2.3. Virtual address

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.

SALT=s1("vtad")

hash=AES-CMACSALT (Label UUID) mod 214

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

Note

Note: When factoring in a 32-bit MIC and the size of the hash, there is only a 1/2⁴⁶=1.42×10^-14 likelihood that two matching virtual addresses using the same application key but different Label UUIDs will collide.

3.4.2.4. Group address

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.

Values	Fixed Group Address Name
0xFFF9	all-ipt-border-routers
0xFFFA	all-ipt-nodes
0xFFFB	all-directed-forwarding-nodes
0xFFFC	all-proxies
0xFFFD	all-friends
0xFFFE	all-relays
0xFFFF	all-nodes

Table 3.7. Fixed group addresses

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.

Table 3.8 shows which address types are valid for use in the SRC field and the DST field.

A fixed group address defined as Reserved for Future Use in Section 3.4.2.4 is a valid group address for the purposes of Table 3.8.

Table 3.9 shows which address types are valid for use with device keys and application keys.

The mesh Network PDU format is defined in Table 3.10 and illustrated in Figure 3.9 below:

Network PDUs are secured using keys derived from a single network key, as identified by the NID field.

Figure 3.9. Network PDU format

Certain functionalities defined in this specification may require that a Network PDU be tagged with additional metadata. For example, tagging a Network PDU as relay is used to control the number of retransmissions of the Network PDU by the Advertising Bearer Network Interface (see Section 3.4.5.4).

The network layer supports sending and receiving Network PDUs via multiple bearers. Multiple instances of a bearer may be present. Each instance of a bearer is connected to the network layer via a network interface. To allow sending Network PDUs between elements within the same node the local interface is used.

For example, a node may have three interfaces: one used to send and receive Network PDUs via an advertising bearer and two interfaces to a GATT bearer, one for each client connected via a GATT connection.

Interfaces provide input and output filters. Filters may be configured using bearer-specific PDUs or internally by services exposed on a node, such as the Mesh Proxy Service (see Section 7.2).

All multiple-octet numeric values in this layer shall be sent in big-endian, as described in Section 3.1.1.1.

The Lower Transport PDU is used to transmit Upper Transport PDUs to another node.

The most significant bit of the first octet of the Lower Transport PDU is the SEG field, which is used to determine if the Lower Transport PDU is formatted as a segmented or unsegmented message.

There are four formats used, depending on the value of the CTL field in the Network PDU and the SEG field in the Lower Transport PDU as defined in Table 3.15 below.

The SEG field values are defined in the Table 3.16.

3.5.2.1. Unsegmented Access message

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

Field	Size (bits)	Description	Req.
SEG	1	Set to Unsegmented Message	M
AKF	1	Application Key Flag	M
AID	6	Application key identifier	M
Upper Transport Access PDU	40 to 120	The Upper Transport Access PDU	M

Table 3.17. Unsegmented Access message format

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.

3.5.2.2. Segmented Access message

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

Field	Size (bits)	Description	Req.
SEG	1	Set to Segmented Message	M
AKF	1	Application Key Flag	M
AID	6	Application key identifier	M
SZMIC	1	Size of the TransMIC field	M
SeqZero	13	Least significant bits of SeqAuth	M
SegO	5	Segment Offset number	M
SegN	5	Last Segment number	M
Segment m	8 to 96	Segment m of the Upper Transport Access PDU	M

Table 3.18. Segmented Access message format

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.

3.5.2.3. Unsegmented Control message

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

Field	Size (bits)	Description	Req.
SEG	1	Set to Unsegmented Message	M
Opcode	7	Set to Opcode of the Upper Transport Control PDU	M
Parameters	0 to 88	Parameters for the Upper Transport Control PDU	M

Table 3.19. Unsegmented Control message format

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].

Values	Description
0x00	Reserved
0x01 - 0x7F	Opcode of the Upper Transport Control PDU

Table 3.20. Opcode field of the Unsegmented Control message values

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.

3.5.2.4. Segmented Control message

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

Field	Size (bits)	Description	Req.
SEG	1	Set to Segmented Message	M
Opcode	7	Opcode of the Upper Transport Control PDU	M
RFU	1	Reserved for Future Use	M
SeqZero	13	Least significant bits of SeqAuth	M
SegO	5	Segment Offset number	M
SegN	5	Last Segment number	M
Segment m	8 to 64	Segment m of the Upper Transport Control PDU	M

Table 3.22. Segmented Control message format

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.

To transmit Upper Transport Access PDUs larger than 15 octets, or shorter Upper Transport Access PDUs to be sent as single segment, or Upper Transport Control PDUs larger than 11 octets, or shorter Upper Transport Control PDUs to be sent as single segment, the lower transport layer segments and reassembles Upper Transport PDUs. These segments are delivered to the peer lower transport layer using a block acknowledgment scheme to minimize the number of messages that need to be transmitted by the lower transport layer.

Figure 3.16. Example of segmentation and reassembly for a two-segment PDU

Figure 3.16 illustrates an Access message being sent that has a single-octet opcode, 3 octets for the NetKeyIndexAndAppKeyIndex field, and 16 octets for the AppKey. This means that when encrypted and authenticated with an application key, the Upper Transport Access PDU is 24 octets. This is segmented by the lower transport layer into two segments, Segment 0 and Segment 1. Each segment has a header that identifies the segment number and is then passed to the network layer, where the complete Network PDU is computed. The network layer then encrypts the Network PDU using the sequence number for that Network PDU and then obfuscates those messages so that only the NID and IVI fields are visible in clear text. Therefore, the single Access message can be delivered securely using two Network PDUs.

The process of segmentation for Upper Transport Access PDUs and Upper Transport Control PDUs is identical, and the description below considers these two PDU types to be identical except where explicitly stated.

The Friend node shall have a Friend Queue for each friend Low Power node. The Friend Queue stores Lower Transport PDUs for a Low Power node. No field of the Lower Transport PDU shall be changed due to the message being in the Friend Queue. The CTL, TTL, SEQ, SRC, and DST fields shall be stored with the associated Lower Transport PDU.

When a Friend node receives a message on a subnet that was used for friendship establishment and that is destined for a Low Power node (i.e., the destination of the message is a unicast address of an element of the Low Power node or in the Friend Subscription List), and the TTL field has a value of 2 or greater, then the message shall be processed as follows: If the Friend Queue already contains a message with the same SEQ and SRC field values as in the received message, or if the SRC field of the received message is a unicast address of an element of the Low Power node, then the message shall not be stored in the Friend Queue. Otherwise, the TTL field value shall be decremented by 1, and the message shall be stored in the Friend Queue.

If the message is a Segmented Access message or a Segmented Control message, then the message shall only be stored into the Friend Queue after the complete Upper Transport PDU has been successfully reassembled and the Friend node has acknowledged the reception of all segments.

If the Friend Queue is full and a new message needs to be stored that is not a Friend Update message, the oldest entries other than a Friend Update message shall be discarded to make room for the new message.

If the message that is being stored is a Segment Acknowledgment message and the Friend Queue contains another Segment Acknowledgment message that has the same source and destination addresses, and the same SeqAuth value, but a lower IV Index or sequence number, then the older Segment Acknowledgment message shall be discarded.

When a Friend node becomes aware of a security update, for example by receiving a valid Secure Network beacon or a Mesh Private beacon, or as a result of a change in the Key Refresh Phase state, the Friend node shall add a Friend Update message to the Friend Queue.

When the Low Power node requests a message from the Friend Queue, the oldest entry shall be sent. Once that message has been acknowledged by the Low Power node, that entry shall be discarded.

If the Friend node is polled for a message from a Low Power node using a Friend Poll, and the Friend Queue for that node is empty, then the Friend node shall generate a new Friend Update message and add that message to the Friend Queue before sending the response, so that this Friend Update message can be sent in response to the Friend Poll message.

All multiple-octet numeric values in this layer shall be sent in big-endian, as described in Section 3.1.1.1.

The Upper Transport PDU is called the Upper Transport Access PDU, when the CTL field in the Network PDU is 0. The Upper Transport Access PDU contains an Access message.

The Access message is encrypted using an application key or device key, and the encrypted Access message and associated message integrity check value are combined into an Upper Transport Access PDU. The Upper Transport Access PDU fields are shown in Table 3.25 and illustrated in Figure 3.17.

Figure 3.17. Upper Transport Access PDU format

The Upper Transport PDU is called the Upper Transport Control PDU when the CTL field in the Network PDU is 1. The Upper Transport Control PDU contains a Transport Control message (see Section 3.6.5). A Transport Control message has a 7-bit opcode that determines the format of the parameters. This Opcode field is not included in the parameters field, but is included in the Unsegmented Control message or in each Segmented Control message.

The Upper Transport Control PDU is not authenticated at the upper transport layer and instead relies upon the authentication performed by the network layer. All Upper Transport Control PDUs use a 64-bit NetMIC field.

The lower transport layer may segment messages into smaller PDUs for delivery over the network layer. It is therefore recommended to keep Transport Control PDU payload size as reflected in Table 3.26, where the values represent the maximum useful parameter field sizes depending on the number of packets.

The maximum size of an Upper Transport Control PDU is 256 octets.

Transport Control messages are transmitted using Upper Transport Control PDUs that can be transmitted either as a single Unsegmented Control message or as a sequence of Segmented Control messages. Unsegmented Control messages or Segmented Control messages have a 7-bit opcode field that determines the format of the parameters field. Each Transport Control message shall be sent using the smallest number of Lower Transport PDUs possible.

Opcode 0x00 is terminated at the lower transport layer as defined in Section 3.5.3 and shall not be sent by the upper transport layer. All other Transport Control messages are terminated at the upper transport layer.

When transmitting a Friend Poll, Friend Update, Friend Request, Friend Offer, Friend Subscription List Add, Friend Subscription List Remove, or Friend Subscription List Confirm message, the message shall be tagged as a friendship PDU.

The list of Transport Control messages, and their opcodes are defined in the Assigned Numbers document [4].

3.6.5.3. Friend Request

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.

Field	Size (octets)	Description	Req.
Criteria	1	The criteria that a Friend node should support in order to participate in friendship negotiation	M
ReceiveDelay	1	Receive Delay requested by the Low Power node	M
PollTimeout	3	The initial value of the PollTimeout timer set by the Low Power node	M
PreviousAddress	2	Unicast address of the primary element of the previous friend	M
NumElements	1	Number of elements in the Low Power node	M
LPNCounter	2	Number of Friend Request messages that the Low Power node has sent	M

Table 3.32. Friend Request message parameters

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

Field	Size (bits)	Description	Req.
RFU	1	Reserved for Future Use	M
RSSIFactor	2	The contribution of the received signal strength indicator (RSSI) measured by the Friend node used in the Friend Offer Delay calculation	M
ReceiveWindowFactor	2	The contribution of the supported Receive Window used in the Friend Offer Delay calculation	M
MinQueueSizeLog	3	The minimum number of messages that the Friend node can store in its Friend Queue	M

Table 3.33. Criteria field format

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.

Value	RSSI Factor
0b00	1
0b01	1.5
0b10	2
0b11	2.5

Table 3.34. RSSIFactor field values

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.

Value	Receive Window Factor
0b00	1
0b01	1.5
0b10	2
0b11	2.5

Table 3.35. ReceiveWindowFactor field values

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.

Value	Description
0b000	Prohibited
0b001	N=2
0b010	N=4
0b011	N=8
0b100	N=16
0b101	N=32
0b110	N=64
0b111	N=128

Table 3.36. MinQueueSizeLog field values

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

The ReceiveDelay field values are defined in Table 3.37.

Value	Description
0x00–0x09	Prohibited
0x0A–0xFF	Receive Delay in units of 1 millisecond

Table 3.37. ReceiveDelay field values

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.

Value	Description
0x000000–0x000009	Prohibited
0x00000A–0x34BBFF	PollTimeout in units of 100 milliseconds
0x34BC00–0xFFFFFF	Prohibited

Table 3.38. PollTimeout field values

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.

Value	Description
0x00	Prohibited
0x01–0xFF	Number of elements

Table 3.39. NumElements field values

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