Joke Collection Website - Blessing messages - Analysis of Bluetooth mesh Network Layer and Network PDU

Analysis of Bluetooth mesh Network Layer and Network PDU

The network layer defines the network PDU format, allowing the bearer layer to transmit PDUs of the lower transport layer. It decrypts and authenticates the input message received by the input interface and forwards it to the upper layer and/or the output interface, encrypts and authenticates the output message and forwards it to the output network interface.

The network layer defines four address types, and the address length is 16 bits.

As shown in the figure below:

Unicast addresses range from 0x000 1 to 0x7FFF, and there can be 32,767 unicast addresses.

Virtual addresses range from 0x8000 to 0xBFFF, and there can be 16384 virtual addresses.

Multicast addresses range from 0xC000 to 0xFFFF, and there can be 16384 multicast addresses. Multicast addresses include 256 fixed multicast addresses and 16 128 dynamically assignable multicast addresses.

Bluetooth mesh has no concurrency restrictions or restrictions on nodes.

When used with low-power Bluetooth transmission, there are no topological restrictions or constraints in this specification.

What does this mean? As many unicast addresses can be assigned, as many devices can be assigned. Virtual address, multicast address and unicast address can coexist, so the number of devices can only be calculated by unicast address. For example, a device can belong to both group 1 and group 2, and the device also has a unicast address. Use three addresses at a time, but only one device. Therefore, there can be 32,767 effective addresses in a network.

The significance of unassigned address is that you can disable message publishing of the model by setting the publishing address of the model to unassigned address. Then there is a problem. What does the network layer do when it finds a message with an unassigned address? Is the message with unassigned address intercepted at the network layer or the bearer layer? meshNetworkManager。

Unicast addresses can be used in the source address field or the destination address field of the message. Messages sent to unicast addresses can only be processed by at most one element. In the network allocation phase, the network distributor will allocate unicast addresses to each element of the network node during its life cycle. The address can be reassigned by the network allocator to allow reuse.

A virtual address represents a set of destination addresses. Each virtual address logically represents a tag UUID with a value of 128 bits, which does not need centralized management. One or more elements can be configured to publish or subscribe to the same tag UUID. The tag UUID will not be sent and should be used as an additional data field of the message integrity check value in the upper message layer. Virtual address involves the calculation of hash value. There is no need to do too much research on virtual addresses here, and it will be clear later. )

The multicast addresses of 0xFF00 to 0xFFFF are reserved for fixed purposes, and the multicast addresses of 0xC000 to 0xFEFF can be used for other purposes. Multicast addresses can only be used in the destination address of a message. Messages sent to a multicast address will be received by all model entities subscribing to the multicast address.

Is this correct, then any BLE device can join the mesh network? How to interpret it?

The network layer supports sending and receiving messages through multiple carriers. An operator may have multiple instances. Each instance of the bearer can be connected to the network layer through a network interface. For example, a node may have three carriers: a broadcast carrier and an interface of two GATT carriers.

What happens if there are two distributors in a network? One-click distribution network and multi-network distributor are two concepts.

The interface input filter determines whether the incoming network message is transmitted to the network layer for further processing or deleted.

The interface output filter decides whether to pass the message to the bearer layer or delete it. The interface output filter deletes all messages with TTL value of 1.

Local network interfaces allow messages to be sent between elements within the same node. Each node should implement a local network interface. After receiving messages through the local network interface, all messages should be sent to all elements of the node for processing.

The network interface of the broadcast bearer, which allows the broadcast bearer to be used to send messages. The APP side does not do research.

The relay function is used to relay the network PDU received by the node or the forwarding node through the broadcast bearer. This feature is optional, and if it is supported, it can be enabled and disabled separately. If proxy function is supported, GATT bearer and broadcast bearer must be supported.

Proxy function means that nodes relay or forward network layer PDU between GATT bearer network and broadcast bearer network, and realize message intercommunication between GATT bearer network and broadcast bearer network. This feature is optional, and if it is supported, it can be enabled and disabled separately. If the proxy function is supported, both GATT and broadcast bearer are supported.

After receiving the message from the bearer layer, the node checks whether the NID field value matches one or more known NIDs. If the value of the NID field does not match the known NID, the message will be ignored. If the value of the NID field matches a known NID, the node will verify the message according to each known matching network key. If the message does not verify any known network keys, the message will be ignored. If the message is indeed authenticated according to the network key, the SRC and DST fields are considered valid, and the message is not in the network message cache, the message will be processed by the lower transport layer.

When a message is retransmitted, it is defined as follows. The IV index used in retransmission should be the same as that used in reception.

If the network layer of a node receives the message distributed by the broadcast bearer and passes the verification, and reports it to the lower transport layer for processing, if the node enables the relay function, the TTL field value is 2 or greater, and the target address of the element is not any unicast address of the node, the TTL field value should be reduced by 1, and the network layer PDU should be marked as a relay PDU and forwarded to all network interfaces connected to the broadcast bearer layer. It is suggested to set a small random delay between receiving network PDU and relaying network PDU to avoid the conflict caused by receiving multiple relaying messages of the same network PDU at the same time.

If the network layer of a node receives a message from a GATT bearer (if it is a broadcast bearer) and passes the verification, and reports it to a lower transport layer for processing, if the node supports the proxy function and the proxy function is turned on, and the TTL field value is 2 or greater, and the target address is not the unicast address of any element of the node, then the TTL value of the message is set to minus one, and the message is forwarded to all network layer interfaces (all network layer interfaces connected to the GATT bearer).

Refer to the network layer PDU format to generate data packets, and then call the bearer layer for transmission.

Network message cache

In order to reduce unnecessary security check and excessive relay, the node should include the network message cache of all recently seen network PDUs. If the received network PDU is already in the network message cache, it will not be processed (that is, it will be discarded immediately). If a network PDU is received and it is not in the network message cache, it can be processed (for example, checked according to network security), and if it is a valid network PDU, it should be stored in the network message cache.

Nodes do not need to cache the entire network PDU, but can only cache a part for tracing, such as NetMIC, SRC/SEQ or other values. As long as the same network PDU cannot be processed multiple times under the limitation of equipment capacity, the filtering conditions can be customized.

When the network message cache is full and a new network PDU needs to be cached, the new network PDU will replace the oldest network PDU in the network message cache.

The network message cache should be able to store at least two network PDUs, although it is strongly recommended that the size of the network message cache is suitable for the expected network density. The details of the incoming message handling process are still implemented by the developers.

Copy "-0x003ebb5242c5f1E3 fdfb18251c5942bfe8ec25cc767d1e1AE1FDD 9c73cc0".

Network key: F9B024F55B 95EFA75F6b8B8D3A3F5C

network PDU . PDU = 0x 3 ebb 5242 C5 f 1 E3 fdfb 1825 1c 5942 bfe 8 EC 25 cc 767d 1e 1ae 1 FDD 9 c 73 cc 0

ivi==== 0

NID = = = 0x3e( 10 decimal 62)

key Private key in disambiguation: a 212c7601572f72c15eba9179775d9d0.

Iindex when disambiguating 0: 0

Result of disambiguation: 050000030003

===ctl:0,

===ttl:5,

= = = Sequence: 3,

= = = Source: III.

===netMicSize:4

= = = mi offset:25,

= = = destAndTransportPdu:fdfb 1825 1c 5942 bfe 8 EC 25 cc 767d 1e 1ae 1FD,

===mic:D9C73CC0

= = = = nonce:00050000030003000000000000000000,

keys . encryption key:da33d 708 b9d 25 ede 5 FDE 26 BBC 1ec 848 a

Decrypted data: 0001800008034458 CCC 398 FD 700 CF 04 E7C05,

Destination: 1,

Transport PDU: 800008034458 CCC 398 FD 700 CF 04 E7C05

Copy "-0x003edc3eefd43c51766ae52ce58bd0969f312c144a14753c9b28a5b8b"

Network key: F9B024F55B 95EFA75F6b8B8D3A3F5C

network PDU . PDU = 3 EDC 3 eefd 43 c 5 1766 AE 52 ce 58 BD 0969 f 3 12c 144 a 14753 c 9 b 28 ea 5bb 8 b

ivi==== 0

NID = = = 0x3e( 10 decimal 62)

key Private key in disambiguation: a 212c7601572f72c15eba9179775d9d0.

Iindex when disambiguating 0: 0

Result of disambiguation: 050000040003

===ctl:0,

===ttl:5,

= = = Sequence: 4,

= = = Source: III.

===netMicSize:4

= = = mi offset:25,

= = = destAndTransportPdu:766 AE 52 ce 58 BD 0969 f 3 12c 144 a 14753 C9 b 28,

===mic:EAA5BB8B

= = = = nonce:00050000040003000000000000000,

keys . encryption key:da33d 708 b9d 25 ede 5 FDE 26 BBC 1ec 848 a

decrypted data:000 180000823 1 CDC 2 fcb 23 CD 2 EB 4c 47 D8 be 8,

Destination: 1,

transport PDU:80000823 1 CDC 2 fcb 23 CD 2 EB 4c 47 D8 be 8