Patent Description:
A wireless mesh network, WMN, comprises a plurality of mesh nodes organized in a mesh topology. Here, each mesh node is also some sort of provider by forwarding data to the next mesh node. The network infrastructure is decentralized because each mesh node only needs to be able to transmit to a neighbouring mesh node. Such wireless mesh networks could allow people living in remote areas and small businesses operating in rural neighbourhoods to connect their networks together for affordable internet connections.

Wireless mesh network can be implemented with various wireless technologies including <NUM>, <NUM>, cellular technologies and Bluetooth. Bluetooth mesh networking is standardized by the Bluetooth Special Interest Group, SIG, and the first release of Bluetooth Mesh was released in July <NUM>. The solution is based on flooding using broadcasting over a set of shared channels referred to as the advertisement channels.

A node acting as a relay in a Bluetooth mesh network scans the advertisement channels for mesh messages. When a Mesh message is detected and received, the node checks to see if it is the destination of the message. If the node is not the destination of the node, the node checks if it has already received and forwarded the message. If yes, the message is discarded. If not, the message is forwarded in the mesh network by re-transmitting it over the advertisement channels so that the neighbours of the node can receive it. Typically some random delay is introduced before forwarding the message to avoid collisions. By means of this distributed mechanism, the message is forwarded from node to node in the network so that the message arrives at the destination.

In a flooding network like Bluetooth Low Energy mesh, all relay nodes may forward a received mesh message if it is valid and is received for the first time. Eventually, all relays will receive every message transmitted within the same network. Hence, this method is considered to consumes a lot of unnecessary bandwidth. In order to limit this, a Time to Live (TTL) value is included in every mesh package to limit number of hops that a message can be relayed in the network. The value of TTL is reduced by <NUM> when it is relayed. A message with TTL equals to <NUM> shall not be relayed. If a message is not supposed to be relayed, the message can also be generated with TTL value set to <NUM>. The maximum TTL value is <NUM> and the maximum number of hops is <NUM>. In a large and dense network, it is crucial to choose a proper TTL value when a sender transmits a message.

A publish-subscribe paradigm is specified for exchanging application data in a BLE mesh network. The message sender, i.e., message publisher, sends the message to the destination address called a publish address. Meanwhile, one or more receivers, i.e. subscribers, subscribe the publish address to receive the message. When a publisher sends a multicast message, the TTL value of the message is determined based on the distance, i.e. number of hops, towards a subscriber that requires most number of hops.

For example, publisher A may send a multicast message to group address GA which is subscribed by node B, node C and node D. According to the topology, node B is one hop away from node A. Node A needs at least two hops to reach node C and at least three hops to reach node D. As a result, in order to reach all nodes that subscribe to GA, the publisher needs to send the mesh message with minimum TTL value equal to three. In practice, the TTL is always set a little bit higher than the minimum value.

In order for the publisher to figure out a proper TTL value when sending unicast or multicast messages to the destination(s), the Mesh specification specifies the so-called Heartbeat Procedure and the corresponding states in the foundation model. A Configuration Client, for example a Smart Phone which acts as a Provisioner, running a configuration client model configures a Configuration Server, typically a mesh node, running a configuration server model with Heartbeat states using Heartbeat Publication messages.

The heartbeat message is sent from the publisher to the group address that all subscribers are listening to. In the transport PDU part of the mesh message, the heartbeat message carries the initial TTL value set by the publisher. Once the subscriber receives the heartbeat message, it can calculate the actual TTL utilized to traverse between the publisher and itself by subtracting the initial TTL with the remaining TTL received in the message network layer.

For example, node A is the publisher, and node B is one of the subscribers. The mesh specification defines the heartbeat publish state and the heartbeat subscribe state which are used to control the heartbeat operation and retrieve heartbeat TTL measurement result. These states are defined in the foundation model which could only be accessed by using a device key of each node. In this case, the configuration client, which in most of the case the provisioner will do the corresponding configuration of each node. Firstly, the configuration client configures each subscriber to receive the upcoming heartbeat message from the specific publisher. Secondly, the configuration client configures the publisher to start sending heartbeat messages. Meanwhile, the configuration client can optionally start a timer to keep track of the heartbeat TTL measurement process time. During this period, the publisher sends heartbeat messages periodically to the preconfigured group address. Once the heartbeat message is received by the subscriber node, the measured TTL is recorded in the local node. When this procedure is finished, the configuration client contacts each subscriber to collect the test results. By summarizing the received test results, the configuration client can configure the publisher to use a reasonable TTL value to publish message to the group address so that all the subscribers have a good chance to receive the message.

One of the drawbacks of the above is that the configuration client is always required during the TTL discovery phase. In order to access the heartbeat, publish state and heartbeat subscription state, the device keys for each device is needed which are usually stored by the provisioner. Also, due to the usage of the device, the TTL discovery result has to be collected subscriber by subscriber via unicast. Furthermore, the specification also enforces the node behaviour so that concurrent TTL discovery procedures are not allowed for a single node. Since this procedure needs to be measured for each publisher, it might take very long time to optimize the TTL for a big network.

The dependency of the configuration client on TTL configuration increases the chance of single point of failure. In some cases, the provisioner only present during the network deployment / provisioning phase. This make it impossible to reuse the current TTL discovery procedure to update the TTL during the network operation time.

Another drawback is that like many other radio systems, the radio environment in a BLE mesh network is not always stable. The TTL value that was initially configured during the TTL discovery procedure might not always work or optimized along the time. In some cases, a temporally breaks down of critical relay might cause the configured TTL not big enough to reach all subscribers. On the other hand, if the network is redeployed, e.g., by adding more relays, the initial configured TTL might be too big for the current network topology, simply because there is a new path available due to the newly added relays. Although the communication still works, it generates a lot of unnecessary message transmissions since the TTL configured is too high than needed. Document <CIT> discloses adapting the length of a broadcast storm, such as by reducing it. Document <CIT> discloses power saving in wireless networks where every wireless device has a hop count indicating hops away from a central wireless device.

<FIG> schematically illustrates a mesh network <NUM>. A publish-subscribe paradigm may be specified for exchanging the application data, i.e., data in Foundation layer or Model layer. The message sender, i.e., message publisher, <NUM> sends the message to the destination address called a publish address. Meanwhile, one or more receivers, or subscribers <NUM>, <NUM>, <NUM> subscribe to the publish address to receive the message. When a publisher mesh node <NUM> sends a multicast message, the number of hops, i.e. the Time To Live, TTL, value of the message is determined based on the distance towards a subscriber mesh node <NUM>, <NUM>, <NUM> that requires most number of hops. As shown in <FIG>, publisher mesh node A <NUM> sends a multicast message to group address GA which is subscribed by subscriber mesh node B <NUM>, subscriber mesh node C <NUM> and subscriber mesh node D <NUM>. According to the topology, subscriber mesh node B <NUM> is one hop away from subscriber mesh node A <NUM>. Subscriber mesh node A <NUM> needs at least two hops to reach subscriber mesh node C <NUM> and at least three hops to reach subscriber mesh node D <NUM>. As a result, in order to reach all nodes that subscribe to group address GA, publisher mesh node <NUM> needs to send the mesh message with minimum TTL value equal to three. In practice, the TTL is typically set a little bit higher than the minimum value.

<FIG> schematically illustrates a method <NUM> of determining the TTL according to the prior art. In <FIG>, node A <NUM> is the publisher mesh node, and node B <NUM> is one of the subscribers. The mesh specification defines a heartbeat publish state and a heartbeat subscribe state which are used to control the heartbeat operation and retrieves heartbeat TTL measurement result. These states are defined in a foundation model which could only be accessed by using the device key of each node. In this case, the configuration client <NUM>, which in most of the case a provisioner will do the corresponding configuration of each node. Firstly, the configuration client <NUM> configures <NUM> each subscriber <NUM> to receive the upcoming heartbeat message from the specific publisher <NUM>. Secondly, the configuration client configures <NUM> the publisher <NUM> to start sending heartbeat messages. Meanwhile, the configuration client can optionally start a timer <NUM> to keep track of the heartbeat TTL measurement process time. During this period, the publisher <NUM> sends heartbeat messages <NUM>, <NUM>, <NUM> periodically to the preconfigured group address for updating the heartbeat subscription state <NUM>. Once the heartbeat message <NUM>, <NUM>, <NUM> is received by the subscriber node <NUM>, the measured TTL is recorded in the local node <NUM>. When this procedure is finished, the configuration client <NUM> contacts <NUM> each subscriber <NUM> to collect <NUM> the test results. By summarizing the received test results <NUM> the configuration client <NUM> can configure <NUM> the publisher <NUM> to use a reasonable TTL value to publish message to the group address so that all the subscribers have a good chance to receive the message.

Note that the procedure described in <FIG> is only for one group address. In case there are multiple publisher - subscribe relationships configured in the mesh network, this procedure is to be repeated for each publisher.

During the provisioning, the subscriber mesh node can be informed with the publishers' network address and the message periodicity. Thus, the subscriber knows when to expect the upcoming application message, i.e. a periodic message, from the publisher mesh node. The publisher mesh node can also get the information about the subscriber's network address per group address. In this case, the publisher knows the addresses of the nodes that has subscribed to the group address.

An internal data structure, called subscriber TTL list, can be used by the publisher mesh node to store such information. The purpose of this table is to record the TTL of each subscriber mesh node per group address that they subscribe from. An example of this data structure is shown below. The group address field and the element address field stores all the subscribers network address of the corresponding group address. The TTL fields records the number of hops away from the publisher to each subscriber.

From the subscriber's <NUM> point of view, the Publisher TTL information table can be used to store the relationship between the publisher <NUM> and the subscriber <NUM> and the corresponding TTL. The table below shows one example of the data structure format. The publisher <NUM> address and the subscriber <NUM> address fields saves the relationship of the publisher <NUM> and the group address. The initial TTL is the TTL that used by the publisher <NUM> to send the application message. The remaining TTL is the network TTL value of the application message when received.

<FIG> schematically illustrates a method <NUM> according to the present disclosure. More specifically, <FIG> shows a typical message transaction when a subscriber mesh node <NUM> recognizes that it is receiving periodic messages from a publisher mesh node <NUM>. The subscriber mesh node <NUM> recognizes that a publisher mesh node <NUM> sends periodic application messages, AppMessage, <NUM>, <NUM> to a group address which it subscribes. The TTL field of the message is set using initial TTL set as nwkTTL_1.

In one embodiment, a parameter can be defined to set the maximum interval for the application message periodicity. If the application message interval is higher than the defined maximum interval, the application is considered as sending messages sporadically. The purpose of this parameter is to keep the minimum sensitivity of the network communication status.

For a subscriber mesh node <NUM>, a timer can be started to keep track of the time when messages are expected from the publisher mesh node. Once a message <NUM>, <NUM> is received, the timer is reset and keep counting for the next upcoming message.

If an expected message is not received <NUM> within an estimated time window, the subscriber <NUM> will send <NUM> a ttl_probe message <NUM>, i.e. a probe message in accordance with the present disclosure, to the publisher mesh node <NUM> using unicast address in the destination field.

In an embodiment, the subscriber mesh node <NUM> can set its own threshold which is used to decide when to send <NUM> the ttl_probe message <NUM>. For example, a subscriber mesh node <NUM> can send <NUM> the ttl_probe message <NUM> if the first expected message is not received <NUM>. Alternately, the threshold can be set so that the ttl_probe message <NUM> will only be sent <NUM> if three application messages <NUM> are missed consecutively, for example.

In the network layer of the ttl_probe message <NUM>, the SRC field may be set with the network address of the subscriber mesh node, the destination address is set as the network address of the publisher mesh node. The network TTL is set as the same nwkTTL_1 that used by the publisher mesh node <NUM>. The same nwkTTL_1 value is carried in the transport layer PDU as well so, once the message is received by the publisher mesh node <NUM>, it will know the initial TTL value used by the subscriber <NUM>.

In an embodiment, the provisioner can tell the subscriber <NUM> about the TTL value that was set to the publisher mesh node <NUM> during the TTL discovery phase as described previously.

In another embodiment, the subscriber mesh node <NUM> can use the TTL value received from the publisher mesh node <NUM> when it transmits the heartbeat value. Specifically, the maximum TTL value defined in the foundation model, heartbeat subscription state.

In another embodiment, the subscriber mesh node <NUM> can use the value saved in its internal memory data structure.

Once the ttl_probe message <NUM> is sent <NUM>, the subscriber mesh node expects a ttl_status message <NUM> within certain time. If the ttl_status message <NUM> is not received on time, the subscriber mesh node may increase <NUM> the TTL value and send <NUM> a new ttl_probe message <NUM>. The subscriber mesh node <NUM> may keep increasing <NUM> the TTL value of the new sent ttl_probe message <NUM> until a ttl_status message <NUM> is received <NUM>.

In one embodiment, it is recommended to have a reasonable TTL increase step <NUM> when sending a new ttl_probe message, for example, by adding <NUM> or <NUM> extra hop every time.

In another embodiment, it is also possible to set an upper limit of number of retries <NUM> when sending the ttl_probe message <NUM>. If the ttl_status message is not received <NUM> when the subscriber mesh node reaches the upper transmission limitation, the communication is considered broken for the moment.

From the publisher's <NUM> perspective, it may receive a ttl_probe message <NUM> due to two reasons. In the first case, the communication between the subscriber <NUM> and publisher <NUM> is not reachable using the current TTL and it needs to be increased. In the second case, the application message <NUM>, <NUM> sent by the publisher mesh node <NUM> is lost in the network not because of a shorter TTL value. To identify these two cases, the publisher mesh node <NUM> needs to compare <NUM> the initial_TTL value carried in the ttl_probe message and its local TTL value used for message publishing.

If the initial_TTL is smaller than the current TTL, the publisher mesh node <NUM> may send the ttl_status <NUM> using the current TTL. Otherwise, the publisher mesh node may use the initial_TTL value contained in the ttl_probe as the TTL value for the out-going ttl_status message. Meanwhile, the network TTL value for the next application message is also increased to the new TTL value, i.e., nwkTTL_2.

Once the subscriber mesh node <NUM> receives <NUM> the ttl_status, it may stop sending ttl_probe message <NUM> and wait for the next incoming application message <NUM>. Once the ttl_status message is sent <NUM> from the publisher mesh node <NUM>, and the TTL increases, the corresponding TTL field in the publishers <NUM> internal data structure is also updated. The TTL field of the Subscriber TTL list data structure is updated to the latest TTL per group address that the subscriber <NUM> listens to and the network address of the subscriber mesh node <NUM>. When the subscriber mesh node <NUM> receives <NUM> the ttl_status message, the internal data structure, Publisher TTL information table, is also updated. The entry is first searched by using the publisher address and subscriber address as key. The Initial TTL field is updated according to the initial_TTL value carried from the ttl_status message. The remaining TTL field is assigned with the network TTL value when the message is received.

The mesh network topology and communication status might be changed due to redeployment or network extension, e.g., adding new relays. In some cases, the TTL value that was originally configured to the publisher mesh node might become more than necessary. In this case, it is good to reduce the TTL in order to reduce the unnecessary channel occupancy. The TTL decrement procedure comprises of two phases, the discovery phase and the adjusting phase. These two phases are described separately in this section.

Once the subscriber mesh node <NUM> receives an application message <NUM>, <NUM>, <NUM> from the publisher <NUM>, the remaining TTL is typically accessible in the TTL field from the network layer. The remaining TTL indicates how many extra hops that the message may further relayed in the mesh network. From the publisher mesh node <NUM> point of view, a publisher mesh node <NUM> may need to set the application message TTL according to the furthest subscriber mesh node.

In order to discover the TTL changes, the subscriber mesh node <NUM> may need to keep track of either sudden change or the gradually changed TTL value of the received application message. In <FIG>, i.e. the method as indicated with reference numeral <NUM>, and <FIG>, i.e. the method as indicated with reference numeral <NUM>, a subscriber mesh node <NUM> is defined such that it has a TTL value of <NUM> - i.e. an application message sent by the publisher mesh node <NUM> may need at least three hops to reach the subscriber mesh node <NUM>.

Additionally, a TTL variation threshold, TH, may be defined as being three. The threshold, TH, serves the purpose of increasing the system sensitivity to a changing TLL value. Referring to both <FIG>, it is assumed that due to some changes in the mesh network, the TTL value is being increased by the subscriber mesh node. For example, a first application message <NUM> sent by the publisher mesh node has a RemainingNwkTTL of <NUM> when the application message reaches subscriber mesh node <NUM>. The second application message <NUM> has a RemainingNwkTTL of <NUM> when the message reaches the subscriber mesh node <NUM> and the third application message <NUM> has a RemainingNwkTTL of <NUM> when the message reaches subscriber mesh node <NUM>.

In one embodiment, a TTL variation threshold can be defined to trigger <NUM> the sending of a ttl_probe message. The subscriber mesh node may store the previous TTL value that triggers the ttl_probe message. If the TTL value in the received application message, i.e., Remaining TTL - Stored TTL > threshold, the ttl_probe message may be sent from the subscriber mesh node. An example is shown in <FIG> the first two AppMessage <NUM>, <NUM> with RemainingNwkTTL <NUM> and <NUM> does not pass the threshold defined by TH (<NUM>). However, the third AppMessage <NUM> triggers <NUM> the ttl_probe message because RemainingNwkTTL(<NUM>) - TTL (<NUM>) = <NUM> which is larger than the defined TH (<NUM>).

In one embodiment, the ttl_probe message can be sent <NUM> periodically to urge the publisher mesh node to update the TTL. In another embodiment, the ttl_probe can be sent <NUM> after every received application message <NUM>, <NUM>, <NUM> in order to reduce the possible network congestion in a busy mesh network.

The subscriber mesh node <NUM> may send <NUM> a ttl_probe message to decrease the TTL of the publisher mesh node. In the network part of the message, the SRC field is set as the network address of the subscriber mesh node. The DST field is set as the network address of the publisher mesh node. The network layer TTL is set as the value that the subscriber mesh node <NUM> would like to optimize. For example, if the publisher TTL value saved in the subscriber mesh node <NUM> is <NUM>, a reasonable TTL value for the ttl_probe message <NUM> could be <NUM> or <NUM>. The same TTL value is included in the initialTTL field of the transport layer PDU of the sent ttl_probe message <NUM>.

In order to properly decrease the TTL from the publisher mesh node <NUM> side, the publisher mesh node <NUM> may need to check the Subscriber TTL list data structure before it responds <NUM> with the ttl_status message. Once a ttl_probe message is received <NUM>, the publisher mesh node <NUM> may first need to identify if the message aims at increasing or decreasing the TTL. If the ttl_probe message:.

The ttl_status message <NUM> is configured as the following. In the network layer, the SRC fields is set as the network address of the publisher mesh node. The DST address is set as the group address for multicast. The network layer TTL is set as the select TTL as shown in this section. The same TTL value is included in the initialTTL field of the transport layer.

In one embodiment, the network TTL field could still be set as the previous TTL that used by the publisher mesh node. The purpose is to increase the possibility for all subscriber mesh nodes <NUM> to receive the ttl_status message <NUM>. In another embodiment, the publisher mesh node <NUM> may send the ttl_status message <NUM> multiple times to increase the chance that all subscriber mesh nodes <NUM> can receive this message to update the TTL.

When the ttl_status message is received <NUM> by the subscriber mesh node <NUM>, the subscriber mesh node <NUM> may stop sending the ttl_probe message. Since the ttl_status is a multi-cast message, all the subscriber mesh nodes that receive the message collect the remaining TTL value from the ttl_status network layer and update the Publisher TTL information table.

The sporadic message publisher TTL optimization procedure is similar as the case of periodic message publisher mesh node. Only the difference is highlighted here. In one embodiment, the publisher mesh node <NUM> that is considered as sporadic message publisher mesh node may need to periodically send the ttl_status message to the subscriber's mesh node <NUM> group address. The ttl_status message interval may be known by all subscriber mesh nodes <NUM> during the provisioning phase. The subscriber mesh nodes <NUM> may use the ttl_status message to detect the existence and hop count of the publisher.

In another embodiment, subscriber mesh nodes <NUM> can be configured to send ttl_probe message periodically. Once the ttl_probe message is received, the publisher mesh node <NUM> may respond with a ttl_status message. Different intervals can be configured which defines the ttl_probe message publishing speed. If a ttl_status message is received in time, the publisher mesh node <NUM> can choose to send the ttl_probe message using a relatively longer period. Otherwise, the subscriber mesh node <NUM> might choose to use a shorter interval to quickly trigger the ttl_status message. The remaining procedure for TTL increase and decrease are the same as described previously.

Once a ttl_probe message is received by the publisher mesh node <NUM>, it will search its internal data memory, Subscriber TTL list data structure, using the group address and the element address as the key. If no match found, the received ttl_probe message is discarded. Otherwise, the TTL field of the found entry may be used to compare with the initialTTL value of the ttl_probe message transport layer PDU. If the initialTTL value is bigger than the current TTL value used by the publisher mesh node, the ttl_probe message is considered as a TTL increasing request. Otherwise, if the ttl_probe message comes from the subscriber mesh node that has the largest TTL, and the initialTTL is smaller than the value saved in the table, the ttl_probe is requesting for TTL decreasing. Other cases are considered as neither TTL increase nor TTL decrease, the ttl_status message will be sent using the current TTL value.

As shown by the method <NUM> in <FIG> after provisioning, the publisher mesh node may know by itself if it is a periodic message publisher mesh node or a sporadic message publisher mesh node <NUM>. In case of a sporadic message publisher mesh node, the publisher mesh node <NUM> may check <NUM> whether it is time to publish a ttl_status message. If it is time, the publisher mesh node <NUM> may publish <NUM> ttl_status message to each group address periodically. Otherwise, the publisher mesh node may wait <NUM> for incoming ttl_probe message.

Once a ttl_probe message is received, the message purpose is analysed <NUM> using the Subscriber TTL list data structure. The ttl_status message is prepared according to the received ttl_probe message and the message is eventually sent <NUM> to the group address.

If however, the publisher mesh node <NUM> is a periodic message publisher, it checks <NUM> if a ttl_probe message has been received. Upon receiving a ttl_probe message, the publisher mesh node <NUM> may detect <NUM> the purpose of the received ttl_probe message - i.e. to increase or decrease the TTL. A ttl_status message is prepared according to the received ttl_probe message and the message is eventually sent <NUM> to the group address.

The internal data structure, Publisher TTL information table, is used to save the relationship of publisher mesh node and multicast address relationship, the TTL value that the publisher mesh node used to send the application message and the remaining TTL when the application message is received. The network layer TTL value of the received ttl_status is compared with the remaining TTL value of the table to decide if a ttl_probe message should be sent to the publisher mesh node to decrease the TTL. Once a ttl_status message is received by a subscriber mesh node, the initial TTL field is updated according to the initial_TTL value in the transport PDU part. The remaining TTL field is updated according to the network TTL field of the received ttl_status message. Once the subscriber mesh node decides to send a ttl_probe message, the network TTL value is set according to the value saved in the initial TTL field.

Referring now to the method <NUM> shown in <FIG>, The subscriber <NUM> decides <NUM> if a ttl_probe message should be sent to the publisher mesh node <NUM> either for TTL increase or decrease purpose. If a ttl_probe message needs to be sent, the subscriber mesh node <NUM> sends <NUM> the message and expects a corresponding ttl_status message in response. If <NUM> the message is received, the local storage is updated <NUM> as described above. Otherwise, the TTL value of the ttl_probe message is increased <NUM> and sent <NUM> to the publisher mesh node <NUM> again. Once the ttl_status message is received, the subscriber mesh node may stop sending the ttl_probe message.

This section shows a possible implementation of the idea described in this disclosure. The disclosure may be defined in terms of states which is compatible with the standard BLE mesh specification. Two states are defined to control the TTL update procedure, i.e., the TTL PROBE state and the TTL STATUS state. The TTL_PROBE states define the subscriber operation on sending the ttl_probe message while the TTL_STATUS state defines the operation that the publisher mesh node sends the ttl_status message. The behaviors upon state value change is also described in this section.

This state may be implemented in all application message subscribers. This state is a composite state and may contain the following sub-states.

This state is implemented in the publisher side to control the behaviour of the ttl_status sending if the publisher is a sporadic application message publisher.

A model may be defined to contain the instances of TTL_PROBE state, TTL_STATUS state, ttl_probe message and ttl_status message. The model may also specify the functions to operate the procedures of optimizing the TTL value by using the defined states and messages. In one embodiment, the model is a Bluetooth SIG adopted model that extends an existing model such as the Heartbeat model. In another embodiment, the model is a Bluetooth SIG adopted model that is a root model which does not extend any other models. In yet another embodiment, the model is a vendor model that extends an existing model such as the Heartbeat model. In yet another embodiment, the model is a vendor model that is a root model which does not extend any other models.

One potential problem of the present disclosure is that it might require extra memory to handle the replay protection. The replay protection mechanism is one of the security procedures that is applied by the Bluetooth Low Energy, BLE, mesh to protect the network from replay attack. It requires a destination node to remember the signature of the last message that was sent to it from all the source nodes. For example, a destination node can use the network source address (<NUM> bytes) and the network sequence number (<NUM> bytes) of the source node as the signature. In this case, to keep track each source node, it requires <NUM> bytes for replay attack protection. Since the proposal according to the present disclosure potentially might require all the message subscribers to send ttl_probe message to the message publisher, it implies that the replay protection memory consumption of the publisher is dependent on the number of its subscribers. However, the replay protection buffer servers a general purpose of message transmission, and the proposal according to the present disclosure will only consume extra memory for replay protection if the relationships between the publisher and the subscriber(s) fulfil all the following conditions.

To solve this potential problem, the inventors propose two possible solutions.

<FIG> illustrates a possible message format of a ttl_probe message according to the present disclosure. The ttl_probe message <NUM> is sent from application message subscribers to one or more application message publishers. It is a unicast message with source address, SRC, <NUM> field in the network layer set as the subscriber's network address and the destination address, DST, <NUM> field in the network layer as the publisher network address. The ttl_probe message <NUM> is a message sent by the application message subscriber to the application message publisher asking for TTL update. The message format of the ttl_probe message is shown in <FIG>. In the network layer, the SRC field <NUM> is set as the network address of the subscriber element. The DST field <NUM> is set as the network address of the application message publisher. The value of TTL <NUM> is set by the application.

In one embodiment, the ttl_probe message <NUM> is defined as one of Transport Control messages which are generated by upper transport layer and only encrypted/authenticated at the network layer. In another embodiment, the ttl_probe message <NUM> is defined as an access message which are generated by a model and encrypted/authenticated at the upper transport layer and the network layer.

In either of the above embodiments, the ttl_probe message contains opcode <NUM> and parameters <NUM>, <NUM>. The opcode <NUM> that identifies the message can be defined as a Bluetooth SIG opcode or a vendor opcode. The parameters consist of a "Initial TTL" field <NUM> and "Sub-Address" field <NUM>. The initial TTL field <NUM> is set with the TTL value used by the message publisher when sending this message. The Sub-address field <NUM> is set with the group address that the node is subscribed with.

<FIG> illustrates a possible message format of a ttl_probe message according to the present disclosure. The ttl_status message <NUM> is sent from the application message publisher to the application message subscribers. It is a multicast message with source address <NUM> set as the publisher network address and the destination address <NUM> as the group address that subscribed by the subscribers. The ttl_status message <NUM> is sent from the message publisher once it receives a ttl_probe message <NUM>. The message format of the ttl_status message <NUM> is shown in <FIG>. In the network layer, the SRC field <NUM> is set as the network address of the ttl_status message <NUM> sender, i.e., the application message publisher. The DST field <NUM> is set as a group address that subscribed by the application message subscribers. The value of TTL <NUM> is set by the application.

In one embodiment, the ttl_status message <NUM> is defined as one of Transport Control messages which are generated by upper transport layer and only encrypted/authenticated at the network layer.

In another embodiment, the ttl_status message is defined as an access message which are generated by a model and encrypted/authenticated at the upper transport layer and the network layer.

In either of the above embodiments, the ttl_status message <NUM> contains opcode <NUM> and parameters <NUM>. The opcode <NUM> identifies that the message can be defined as a Bluetooth SIG opcode or a vendor opcode. The parameters consist of a "Initial TTL" field <NUM>. The initial TTL field <NUM> is set as the TTL value that is set by the ttl_status message <NUM> sender.

It is possible to define the ttl_probe message <NUM> and ttl_status message <NUM> as either transport control message or access layer message. In either case, the message should contain the fields defined above.

Claim 1:
A method of enabling a publisher mesh node (<NUM>) to update a number of hops that is to be used for communication between said publisher mesh node (<NUM>) and a subscriber mesh node (<NUM>, <NUM>, <NUM>) in a wireless mesh network, wherein said method comprises the steps of:
- periodically receiving, by said subscriber mesh node, (<NUM>) broadcasted messages from said publisher mesh node, wherein said broadcasted messages comprise a number of hops that said broadcasted messages may traverse in said mesh network;
- determining, by said subscriber mesh node, (<NUM>) that one or more periodically broadcasted messages have not been received by determining that a broadcasted message has not been received in case a predefined amount of time has lapsed since a particular broadcasted message that was received;
- transmitting, by said subscriber mesh node, (<NUM>) in reply to said determination that one or more periodically broadcasted messages have not been received, a probe message to said publisher mesh node, wherein said probe message comprises a number of hops taken by a periodically broadcasted message that was previously received by said subscriber mesh node. (<NUM>)