WO2017160223A1

WO2017160223A1 - Methods and arrangements for supporting routing in a bluetooth® based mesh network

Info

Publication number: WO2017160223A1
Application number: PCT/SE2017/050262
Authority: WO
Inventors: Jingcheng Zhang; Per Elmdahl; Thomas Rimhagen; Wei Shen
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-03-18
Filing date: 2017-03-17
Publication date: 2017-09-21

Abstract

Embodiments support routing in a Bluetooth based mesh network (100) between a source node (121) and a destination node (124) via one or more intermediate nodes (122; 123). A first node (121; 122; 123) sends (901; 1001) a message to another, second node (122; 123; 124) of the mesh network (100), which second node (122; 123; 124) is neighbouring the first node (121; 122; 123) in said routing. The message being any one of the following: a unicast message being routed according to said routing, a group-cast message being routed according to said routing, and a route response, "RREP", message sent as part of creating a route for said routing. The first node (122; 123) listens (902; 1002) for a receipt acknowledging response sent by the second node (123; 124) in response to receipt of the sent message.

Description

METHODS AND ARRANGEMENTS FOR SUPPORTING ROUTING IN A BLUETOOTH®

BASED MESH NETWORK

TECHNICAL FIELD

Embodiments herein relate to methods and arrangements for supporting routing between a source node and a destination node of a Bluetooth®, such as a Bluetooth Low Energy (BLE), based mesh network.

BACKGROUND

Communication devices such as wireless communication devices, that simply may be named wireless devices, may also be known as e.g. User Equipments (UEs), mobile terminals, wireless terminals and/or Mobile Stations (MS). A wireless device is enabled to communicate wirelessly in a wireless communication network, which may also be referred to as a wireless communication system, or radio communication system. The wireless device may further be referred to as a mobile telephone, cellular telephone, laptop,

Personal Digital Assistant (PDA), tablet computer, just to mention some further examples. Wireless devices may be so called Machine to Machine (M2M) devices or Machine Type of Communication (MTC) devices, i.e. a device that is not necessarily associated with a conventional user, such as a human, directly using the device. A wireless device may be in principle any device or unit capable to wirelessly communicate over a radio link, e.g. in a wireless communication network. The wireless device may be, for example, portable, pocket-storable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data, with another entity, such as another wireless device or a server.

Bluetooth® is a wireless communication technology for exchanging data over short distances. Bluetooth Low Energy (BLE) is a wireless personal area network technology designed by the Bluetooth Special Interest Group (SIG) aimed at novel applications in the healthcare, fitness, security, and home automation industries. Compared to so called Classic Bluetooth, BLE is intended to provide considerably reduced power consumption and cost while maintaining a similar communication range. On the other hand, the amount of data being transmitted by BLE devices is much less than Classic Bluetooth devices. BLE is e.g. described in Bluetooth Core Specification 4.2, and is also marketed under the mark Bluetooth Smart. BLE is a wireless technology that may be used in so called Personal Area Networks (PAN). There is on-going work that aim at extending the network coverage of BLE network, known as BLE Smart Mesh. This technology uses the BLE Advertisement Channel for data communication so that any two nodes can communicate within the network without establishing a BLE connection based on a data channel.

As should be recognized by the skilled person, a mesh network is a network where each node of the network, which nodes may be referred to as mesh nodes, may be involved in relaying data, i.e. the mesh nodes may be considered to cooperate in delivery data in the network. There are two different message forwarding methods used in mesh networks, flooding and routing. When using flooding, all the mesh nodes participate in forwarding the mesh packets, while when using routing, a route is created between the source node and the destination node(s). Only nodes belong to the created route participate in the message forwarding.

Compared with flooding, routing reduces the number of messages being

retransmitted within the mesh network.

In a context of routing enabled mesh network, routes may be established between a source (SRC) node to a destination (DST) node. This may be compared with a flooding based network where each node simply forwards every received message.

In general it is of interest to increase robustness and reliability for forwarding of messages, and it is also of interest to improve performance, e.g. throughput, and to save energy.

SUMMARY

An object is to provide one or more improvements regarding routing in a BLE mesh network, i.e. in a routing enabled BLE mesh network.

According to a first aspect of embodiments herein, the object is achieved by a first method, performed by a first node of a Bluetooth based mesh network, for supporting routing in said mesh network between a source node and a destination node via one or more intermediate nodes. The first node sends a message to another, second node of the mesh network, which second node is neighbouring the first node in said routing. The message being any one of the following: a unicast message being routed according to said routing, a group-cast message being routed according to said routing, and a route response, "RREP", message sent as part of creating a route for said routing. The first node then listens for a receipt acknowledging response sent by the second node in response to receipt of the sent message. According to a second aspect of embodiments herein, the object is achieved by a computer program comprising instructions that when executed by a first node of a Bluetooth based mesh network causes the first node to perform the method according to the first aspect.

According to a third aspect of embodiments herein, the object is achieved by a computer readable medium comprising the computer program according to the second aspect.

According to a fourth aspect of embodiments herein, the object is achieved by a second method, performed by a second node of a Bluetooth based mesh network, for supporting routing in said mesh network between a source node and a destination node via one or more intermediate nodes. The second node receives a message from another, first node of the mesh network, which first node is neighbouring the second node in said routing. The message being any one of the following: a unicast message being routed according to said routing, a group-cast message being routed according to said routing, and a RREP message, sent as part of creating a route for said routing. The second node sends, in response to the received message, a receipt acknowledging response to the first node.

According to a fifth aspect of embodiments herein, the object is achieved by a computer program comprising instructions that when executed by a second node of a Bluetooth based mesh network causes the second node to perform the method according to the fourth aspect.

According to a sixth aspect of embodiments herein, the object is achieved by a computer readable medium comprising the computer program according to the fifth aspect.

According to a seventh aspect of embodiments herein, the object is achieved by a first node, configured to operate as a node in a Bluetooth based mesh network, for supporting routing in said mesh network between a source node and a destination node via one or more intermediate nodes. The first node is further configured to send a message to another, second node of the mesh network, which second node is neighbouring the first node in said routing. The message being any one of the following: a unicast message being routed according to said routing, a group-cast message being routed according to said routing, and a RREP message sent as part of creating a route for said routing. Moreover, the first node is configured to listen for a receipt acknowledging response sent by the second node in response to receipt of the sent message.

According to an eight aspect of embodiments herein, the object is achieved by a first node, configured to operate as a node in a Bluetooth based mesh network for supporting routing in said mesh network between a source node and a destination node via one or more intermediate nodes. The second node is further configured to receive a message from another, first node of the mesh network, which first node is neighbouring the second node in said routing. The message being any one of the following: a unicast message being routed according to said routing, a group-cast message being routed according to said routing, and a RREP message sent as part of creating a route for said routing. Moreover, the second node is configured to send, in response to the received message, a receipt acknowledging response to the first node.

Thanks to the receipt acknowledging response introduced for said messages and as described above, more robust routing is enabled and/or delays during routing can be avoided and energy be saved. For example, triplet messages and acknowledgements can be avoided to some extent, e.g. when not adding any value. A message of a triplet may e.g. be acknowledged whereby later messages of the triplet, i.e. message copies, and/or related acknowledgements can be stopped and avoided. Thereby another, new message may be sent sooner than else would be the case, i.e. throughput increase. Also time redundant signalling can be avoided and thereby further energy be saved.

BRIEF DESCRIPTION OF THE DRAWINGS

The various aspects of embodiments disclosed herein, including particular features and advantages thereof, will be readily understood from the following detailed description and the accompanying drawings, in which Figures 1-14 are shown.

Figure 1 schematically illustrates mesh message triplet transmissions on three advertisement channels.

Figure 2 schematically shows a unicast routing path example.

Figure 3 schematically shows a group-cast routing example.

Figure 4 schematically shows a route request propagation example. Figure 5 is a block diagram schematically depicting an example of a wireless communication network in which embodiments herein may be implemented.

Figure 6 schematically shows an example of implicit message acknowledgement according to some embodiments herein.

Figure 7 schematically illustrates advertising events and such that can be cancelled.

Figure 8 schematically shows an example of explicit acknowledgement for group- cast according to some embodiments herein.

Figure 9 is a combined signaling diagram and flowchart for describing some embodiments herein.

Figure 10 is a flowchart schematically illustrating a first method according to some embodiments herein.

Figure 11 is a functional block diagram for illustrating embodiments of a first node according to some embodiments herein and how it can be configured to carry out the first method.

Figure 12 is a flowchart schematically illustrating a second method according to some embodiments herein.

Figure 13 is a functional block diagram for illustrating embodiments of a second node according to some embodiments herein and how it can be configured to carry out the second method.

Figures 14a-c are schematic drawings illustrating embodiments relating to computer programs and computer readable media to cause the first node and the second node to perform the first and second method, respectively. DETAILED DESCRIPTION

Throughout the following description, similar reference numerals have been used to denote similar elements, units, modules, circuits, nodes, parts, items or features, when applicable. In the figures, features that appear only in some embodiments may be indicated by dashed lines.

In the following, embodiments herein are illustrated by exemplary embodiments. It should be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present in another embodiment and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments. As an introduction, problems generally indicated in the Background will first be further elaborated upon. Owing to reasons indicated in the Background, acknowledgement of messages is of particular interest when using routing, such as in a routing enabled mesh network. Mesh communication may use so called triplets for communication but which is neither efficient nor reliable in a noisy environment. In a BLE mesh network, a node thereof, which may be referred to as a mesh node or simply node, uses so called "advertisement triplets" for sending one mesh packet or message.

Figure 1 schematically illustrates mesh message triplet transmissions on three advertisement channels. As shown in Figure 1 , each message is sent using 3 advertising events. During each advertising event, the message, e.g. a mesh packet, is sent in three, i.e. typically all, advertisement channels. In total, a message thus needs to be repeated, i.e. transmitted, 9 times before a next message can be started to be sent. However, it is obvious that if an acknowledgement can be received from a peer node, e.g. next hop node, after the mesh node has finished a first advertising event, the mesh node can immediately start sending another, second message. From the number of packets point of view, a mesh node can e.g. save the energy for sending the following 6 messages for two advertising events. More importantly, from the time point of view, this would increase the message sending rate of 66% by saving 2/3 of the message transmission time.

The original ideas of utilizing triplets for sending a mesh packet is to increase the chance for a successful message delivery via retransmission, however, such

retransmissions do not always help in a very noisy environment.

Figure 2 schematically shows a unicast routing path example, with an example of a created message route for unicast and will now be used to discuss an acknowledgement problem for unicast message routing. It will also be indicated a solution to this problem according to embodiments herein that will be further explained and discussed separately further below.

In the figure, a node A tries to send message to a single destination mesh node B. A message being forwarded along the path can be either a reliable message or an unreliable message, which is indicated by the message originator, i.e. source node, A. Upon receiving a reliable message, the destination node B will issue an application layer acknowledgement to the message originator; this is known as end to end acknowledgement. However, for an unreliable message, the message originator does not expect any application layer acknowledgement.

If a link between any two intermediate nodes is broken, for example, between M and N, the message will never be able to reach the destination until the link has recovered. However, by introducing a "peer to peer" acknowledgement between intermediate nodes, according to embodiments herein, not only the reliability can be increased significantly, but this may also accelerate a link recovery process.

Figure 3 schematically shows a group-cast routing example and will now be used for discussing an acknowledgement problem for group-cast message routing. It will also be indicated a solution to this problem according to embodiments herein that will be further explained and discussed separately further below.

Group-cast routing is used when a message needs to be sent to multiple destination nodes. In such a case, the destination address of the mesh packet is set to the group address which multiple devices subscribe to and thus are associated with. As shown in

Figure 3, a device, or node, A sends a message to a group address B which nodes P, Q,

X, Y, and Z subscribe to. Conventionally there are no acknowledgements used for group cast messages.

However, according to some embodiments herein, a mesh packet may be considered acknowledged only if the message sender receives the acknowledgements from all next hop nodes as the number of next hop devices. For example, when A first sends the message packet, it should receive three acknowledgement, from device Y, M and P.

Another example, when device N forwards the mesh packet, it is considered acknowledged if it receives an acknowledgement from device X.

Figure 4 schematically shows a route request propagation example and will now be used for discussing an acknowledgement problem during route discovery. It will also be indicated a solution to this problem according to embodiments herein that will be further explained and discussed separately further below.

Another problem related to acknowledgements happens during the so called route discovery process. According to a so called Ad hoc On-Demand Distance Vector (AODV) routing algorithm, a route is created by mainly using two kinds of messages, route request (RREQ) messages and route response (RREP) messages. As shown in Figure 4, a route request is broadcast to the whole network. Because of this, each node potentially receives multiple route requests, i.e. RREQs. For example, a node A may initiate a route request, i.e. a RREQ, that looks for a node B. In the shown example, node P receives in total 3 route request from nodes A, M, and E, and node Q receives 4 requests from nodes M, N, P, and F.

5 Upon receiving a RREQ, a mesh node responds by sending a unicast RREP to the node that sends the RREQ with the best metric. This metric can for example be a

Received Signal Strength Indicator (RSSI), or the shortest path to the RREQ originator. For example, when the mesh node Q receives a RREP, it should choose one of the following nodes, here M, N, P, F, as the intermediate node for a path being created.

10 However, for a low throughput network, such as BLE mesh network, a factor that cannot be neglected is the traffic load for each node. If a node is assigned too much traffic, it can easily be congested and the traffic throughput through that node decreases. Also, the load for one node changes dynamically and is hard to predict. This gives the route creation a lot of uncertainty from the route throughput point of view.

15 Moreover, conventionally, with no confirmation of RREP, a sender of a RREP

message is never able to know if the message has been received successfully or not. In this case, the sender has to wait until the timeout of the current route discovery before it can retry to establish the route again. However, if an acknowledgement mechanism is introduced for the route reply, the RREP sender can instead choose the next best

20 candidate in case the first candidate node does not respond.

Figure 5 is a block diagram schematically depicting a wireless communication network 100 comprising network nodes or simply nodes, such as a source node 121 , a first intermediate node 122, a second intermediate node 123 and a destination node

25 124, suitable for wireless communication with each other. Said nodes may e.g.

correspond to such nodes discussed above. The nodes may correspond to or be wireless communication devices, e.g. such wireless devices described elsewhere herein. Such wireless devices, and thus e.g. the nodes 121..124 may be configured to communicate according to one or more RATs, where at least one RAT should be Bluetooth, such as

30 BLE in particular, where the nodes then should be configured to be operative in a routing enabled BLE network, e.g. a so called mesh network.

The wireless communication network 100 is thus preferably a Bluetooth network, such as a BLE network and may in particular be a routing enabled BLE mesh network. In the wireless communication network 100 routes may be established between a source

35 node, e.g. the source node 121 , and one or more destination nodes, e.g. the destination node 124. There may be one or more intermediate nodes, e.g. intermediate nodes 122, 123, that a message pass through when being routed according to a route between the source node 121 and the one or more destination nodes, e.g. the destination node 124. A route may in general be between a source, or originating, node for a message and one or more destination, or target or final recipient, nodes for the message. The routing and/or the message may utilize and/or comprise only one layer of address, e.g. an address of the source node 121 and an address of the destination node 124. This may be inherent or given by the type of RAT that the nodes 121..124 operate according to in the wireless communication network 100, e.g. according to Bluetooth and/or BLE in a routing enabled mesh network.

The communication between the nodes 121..124 typically takes place of one or more wireless communication links, such as radio links, 115, 116, 117, that preferably are symmetric and may be common between one or more of the nodes 121..124. The one or more wireless communication links 115..117 may thus be Bluetooth links and may be low power, short range wireless communication links, such as used in BLE. That is, the radio links may be based on BLE or be BLE wireless communication links.

As used herein, by low power wireless communication link may generally be meant that there is an upper limit associated with, e.g. of allowed and/or specified for and/or that restricts, transmit power over the communication link, and that this upper limit is comparatively low, e.g. compared to allowable transmit power according to other wireless communication technologies than of the wireless communication link. For example, Bluetooth and BLE use low power wireless communication links that, as recognized by the skilled person, are associated with substantially lower transmit power than e.g. base stations and user equipments in conventional wireless communication networks for telecommunication, e.g. based on Long Term Evolution (LTE). For example, the upper transmit power limit associated with each of the wireless communication links 115..117 may be e.g. 10 dBm, although normally even lower transmit power is used.

As realized, the low power also restricts the communication range. However, communication range provided by a wireless communication link is also dependent on other factors associated with the wireless communication link, such as coding scheme, how communication errors are handled, interference and noise robustness, receiver sensitivity etc.

In any case, as used herein, by short range wireless communication link is generally meant that there is an upper communication range or distance associated with a satisfying or working communication over the wireless communication link, and that this range or distance is comparatively short, e.g. compared to communication ranges according to other wireless communication technologies than of the wireless

communication link. For example, Bluetooth and BLE have short communication range, as recognized by the skilled person, compared to communication ranges between base stations and user equipments in LTE. For example, the upper communication range associated with any of the wireless communication links 115... 1 17 may e.g. be in the magnitude of one or a few hundred meters, such as 500 m, possibly up to e.g. 1 km, such as when a highest allowable transmit power is used and there is more or less perfect environmental circumstances, line of sight etc.

Attention is drawn to that Figure 5 is only schematic and for exemplifying purpose and that not everything shown in the figure may be required for all embodiments herein, as should be evident to the skilled person. Also, a wireless communication network or networks that in reality correspond(s) to the wireless communication network 100 will typically comprise several further network nodes, such as further wireless communication devices, etc., as realized by the skilled person, but which are not shown in the figure for the sake of simplifying.

In the following description of embodiments herein, the embodiments are first split into three different groups. A first group of embodiments is about an implicit

acknowledgement mechanism for use in unicast message forwarding. A second group of embodiments is about an explicit acknowledgement mechanism for us in group-cast message forwarding. A third group of embodiments is about an acknowledgement mechanism for route creation, i.e. for use in the route discovery process. Implicit acknowledgement for unicast message routing

Implicit acknowledgement does not require the node who receives the message to send back any specific or explicit acknowledgement message. Instead, as long as the message sender hears that its sent message is being forwarded by the message receiver, the message sender considers the message to be acknowledged according to these embodiments. The implicit acknowledgement may be considered associated with the following assumptions on characteristics that may correspond to features that should be supported by the network comprising the nodes, such as the wireless communication network 100:

• The radio link between the sender and the receiver is symmetric, i.e., if a message sent from A and be received from B, then a message sent from B can be received by A as well. For example, if a message is sent from the source node 121 over the wireless communication link 1 15 and is received by the first intermediate node 122 that sends it further to the second intermediate node 123 over the wireless communication link 116, then the source node 121 can also hear the message being sent further.

· In a route created for unicast, there is always only one "next hop" node. For example, in a unicast route passing through the nodes shown in Figure 5, there is only one node next, i.e. node 122 after node 121 , node 123 after node 122 etc.

As recognized by the skilled person, a Bluetooth based mesh network that is routing enabled and as discussed above has these characteristics.

Figure 6 schematically shows an example of a mesh network 100a, e.g.

corresponding to the wireless communication network 100, that will be used to discuss and illustrate embodiments about implicit message acknowledgement, i.e. Figure 6 schematically illustrates a situation regarding implicit acknowledgement for unicast message routing. As shown in Figure 6, a unicast route exists between a node A, e.g. corresponding to the source node 121 , and a node B, e.g. corresponding to the destination node 124, via a node M, e.g. corresponding to the first intermediate node 122, and via a node N, e.g. corresponding to the second intermediate node 123. When node A wants to send a message to B, a message "MSG AM" is sent from node A and received by node M. Once node M receives this message, it will forward the message, as a message "MSG MN" in the figure, to node N. With a radio link being symmetric, "MSG MN" will typically also be received by node A. Once node A receives "MSG MN", it shall according to some embodiments consider the sent "MSG AM" as being acknowledged. Similarly, subsequent nodes performs similarly until the message reaches node B, i.e. the destination node 124 in this case. That is, in the example, node N forwards the message as a message "MSG NB" to node B.

As typically is the case in a mesh network for packets sent therein, and may even be required e.g. by a standard specification, a source address (SRC), e.g. of node A and/or the source node 121 , and a destination address (DST), e.g. of node B and/or the destination node 124, and any sequence number (SEQ) field, shall not be changed during message forwarding. The only difference between "MSG AM" and "MSG MN" may therefore e.g. be a Time To Live (TTL) field of a packet associated with the message, e.g. a packet that the message is comprised in. For example, the TTL value of "MSG MN" should be the TTL value of "MSG AM" minus 1. However, there should be an exception when the message is received by the destination node, i.e. node B in the example. Since node B here is the destination node, it would conventionally, when it receives message from A, not forward the message. However, in order for node N to be able to receive an implicit acknowledgement also in this case, node B should nevertheless, according to some embodiments herein, send out, i.e. forward, the received message but with TTL set to 0 meaning the message will and should not be forwarded further in any case. This "forwarding" by the destination node B is illustrated by a message "MSG BB" in Figure 5.

Once a node considers a message to be acknowledged, remaining advertising events, if any, may advantageously be cancelled.

Figure 7 schematically illustrates an example of this. A node in a mesh network, e.g. the node A and/or the source node 121 , starts sending a message using an advertisement event 0, and since there is no acknowledgement received, the same message is also sent by the same node using a next advertising event, an advertisement event 1. In the example, the message is acknowledged in an advertisement (ADV) channel (Ch) 0. Once the message is acknowledged, the node A can cancel any further message transmissions of this message, which transmissions else should follow e.g. in an ADV Ch 1 and in an ADV Ch 2. Moreover, node A can instead already start sending a new message in a subsequent advertisement event, e.g. an advertisement event 2, that else would have been used for the first message. In the example, this new message is acknowledged in ADV Ch 1 , and thus the node A can cancel further message

transmissions of the new message in coming advertisement events (not shown in the figure) and instead be ready to send yet another new message in these next

advertisement events etc. It is realized that this improves throughput and latency, as well as saves energy.

Explicit acknowledgement for group-cast message routing

In group routing, the above mentioned explicit acknowledgement mechanism is instead utilized. Once a node receives a sent message, it returns an acknowledgement message to the sender. To increase the success rate for the message sender to receive the acknowledgement, the acknowledgement is advantageously sent back after a random delay. Upon receiving the acknowledgements from all next hop nodes, i.e. the nodes that the message is sent to, the message may be considered acknowledged. The explicit acknowledgement may be considered associated with the following assumptions on characteristics that may correspond to functionality that should be supported by a network comprising the nodes, e.g. the wireless communication network 100:

• The message sender in each link should know, such as has information about, nodes, e.g. a node list, that it may expect acknowledgements from. • Once a message is received by an intermediate node on the path to the final destination, the intermediate node knows where the message comes from. This may e.g. be achieved by adding a previous hop, e.g. the preceding node, in a routing table.

Figure 8 schematically shows an example of a mesh network 100b, e.g.

corresponding to the wireless communication network 100, that will be used to discuss and illustrate embodiments about explicit acknowledgement for group-cast, i.e. Figure 8 schematically illustrates a situation regarding explicit acknowledgement for group-cast routing.

As shown in Figure 8, a node A', e.g. corresponding to the source node 121 , wants to send a message to a group address b that is associated with nodes X', Υ', Ζ', Ρ', and Q'. Each of these nodes thus corresponds to a destination node, i.e. may correspond to the destination node 124, and the nodes X', Υ', Ζ', P' and Q' have therefore in the figure been named destination nodes 124a-e, respectively. When node A' is to send a message to the group address b, node A e.g. sends a message "MSG A" and node A can know that there are three nodes that should receive this message, here nodes Υ', Μ', and Ρ'. In this case, node A' may only consider "MSG A" as acknowledged when it has received all acknowledgements, i.e. from all these nodes, which acknowledgements are named "ACK YA", "ACK MA" and "ACK PA" in the figure. In order to identify where each acknowledgement comes from, each acknowledgement, i.e. an explicit ACK in contrast to the implicit type of acknowledgement discussed above, can be sent as a new unicast message type, which e.g. may comprise fields as shown in Table 1 below.

It may be important to know the previous hop and next hop for the explicit acknowledgement and this information may be part of a routing table, see e.g. an exemplifying routing table of node M' shown in Table 2 below. Table 2 thus schematically shows a routing table example for explicit acknowledgement in group-cast. In this case, once node M' receives a message with a source address of node A', i.e. a source address addr(A'), and with a destination address b, it knows that the message comes from node A according the information from the previous hop. So it will send a unicast

acknowledgement message to A'. Moreover, when it retransmits the message, it expects two acknowledgements from node N' and Q', which are recorded in the next hop field.

Table 2 - Example of a routing table for node M'

Acknowledgement during route creation, i.e. for use in the route discovery process According to AODV, a routing entry is created when a RREP is received. AODV and RREP was explained above when Figure 4 was discussed. According to embodiments herein, AODV may be extended by making nodes send an acknowledgement which indicates successful reception of the RREP. A current node routing status may also be included in this acknowledgement. For this reason, the RREP acknowledgement may be sent as a broadcast message with TTL = 0. As a result, all the neighbor nodes that receive this acknowledgement, e.g. an acknowledgement message, should update the routing status of the node in question. If the RREP acknowledgement is broadcasted with TTL = 0 by a node, all neighbouring nodes should receive this information and be aware of the route update. The neighbouring nodes are thereby enabled to have better information when selecting the next hop for route creation in the future.

In conclusion, the above embodiments relate to acknowledgement mechanisms suitable for a routing enabled BLE mesh network. For unicast routing, an implicit acknowledgement mechanism is proposed. For group-cast routing, an explicit routing mechanism is proposed. During route creation another explicit acknowledgement mechanism is proposed that improves and enable optimizing the route selection and creation process.

In case of said implicit acknowledgement, a sent message may be considered acknowledged when the sender of a message has received the same message in response to that the message has been relayed by some other mesh node within the network. In case of said explicit acknowledgement mechanism, a message may be considered acknowledged when the sender has received an explicit acknowledgement from the receiver or receivers of the message, i.e. the succeeding node or nodes in the route.

The acknowledgement mechanism proposed for route creation may both increase the route creation reliability and also better balance the load of the whole network.

Additionally, whenever a node updates its routing status, this status should be

broadcasted to its neighbors. By doing this, the route can be created by utilizing the most up to date path information when deciding the route.

The following are examples of advantages associated with embodiments herein: By introducing one or more of the acknowledgement mechanisms described herein to a routing enabled network, e.g. a Bluetooth based mesh network as mentioned above, the reliability of such network can be increased.

Said implicit acknowledgement mechanism e.g. increases a peer to peer message reliability without introducing any extra message transactions. An exception is that it may require the destination node to broadcast its received message. However, the number of message retransmissions along the route should still be reduced compared to

alternatives. As a result, the network performance improves, and at the same time, a more reliable message transmission method can be provided.

Said proposed implicit and explicit acknowledgement mechanisms may e.g. be utilized to detect the link status between two nodes. If a message is not acknowledged, the link can be considered broken. As a result, a faster link broken detection can be achieved thanks to embodiments herein.

The proposed acknowledgement mechanism for route creation, i.e. with

acknowledgement of RREP, provides the possibility to balance the load of the network so that the load can be more evenly distributed over the network.

Figure 9 depicts a combined signalling diagram and flowchart, which will be used to discuss embodiments herein for supporting routing in a wireless communication network that may be exemplified by the wireless communication network 100 in the following, and/or by the mesh networks 100a and 100b when applicable for some embodiments, as should be recognized by the skilled person. The embodiments are relating to methods and actions performed by, and to, nodes for communication in the wireless

communication network that thus preferably is a BLE network, and preferably a mesh network that is routing enabled. In the wireless communication network, routes may be established between a source node, e.g. the source node 121 , and one or more destination nodes, e.g. the destination node 124 or the destination nodes 124a-e. There may further be one or more intermediate nodes, e.g. the first and second intermediate nodes 122, 123, that a message pass through when being routed according to a route between the source node and the one or more destination nodes. In other words, the route is between a source, or originating, node for message and one or more destination, or target or final recipient, nodes for the message. The routing and/or the message may utilize and/or comprise only one layer of address, e.g. an address of the source node and an address of the destination node.

More particularly, the following embodiments are exemplified in relation to a first node, e.g. any one of the nodes 121-123 and 124a, and a second node, e.g. any one of the node 122-124, 124a-e. It should be understood that the second node is a subsequent, or in some embodiments a preceding, node to the first node according to the routing, i.e. according to a route, between the source node and said one or more destination nodes. In other words, the first node and the second node are neigbouring each other in the routing. The second node may thus e.g. be a next hop node.

Note that shown actions may be taken in any suitable order and/or be carried out fully or partly overlapping in time when this is possible and suitable.

Action 901

The first node sends, in association with a route for routing of a message, the message to the second node that accordingly may receive the message. The second node may thus receive the message in association with a route for routing of a message.

Sending in association with the route may e.g. comprise or involve sending the message as part of routing of the message, or as part of finding, such as discovering or creating, the route for routing of the message. Similarly, receiving in association with the route may e.g. comprise or involve receiving the message as part of routing of the message, or as part of finding, such as discovering or creating, the route for routing of the message.

As already indicated above, the second node is a node that is succeeding or preceding the first node in the route, or in other words a node that according to the route follows directly after or directly before the first node. The second node may be referred to as a next hop node when it is succeeding the first node. The message may be sent by forwarding it after the first node has received the message from another node, or the first node may be the source node. The second node may be an intermediate node or the destination node.

In some embodiments, that may correspond to the first group of embodiments mentioned above, the message is a unicast message, i.e. a message for unicast. The message may hence be a message with a single destination node. The routing may be unicast message routing.

In some embodiments, that may correspond to the second group of embodiments mentioned above, the message is a group-cast message, i.e. a message for group casting. The message may hence be a message with multiple destination nodes, or in other words a message for receipt by a group of nodes. The routing may be group cast routing.

In some embodiments, that may correspond to the third group of embodiments mentioned above the message is a route response message, i.e. a RREP message, sent as part of finding said route.

Action 902

The first node listens for a response sent by the second node in response to receipt of the sent message in Action 901.

The response may have a predetermined meaning that may be specific for the first node, i.e. may have a specific meaning to the first node, and which meaning is that receipt of the message has been acknowledged by the second node. The response may thus correspond to an acknowledgement. However, the acknowledgement need not be explicit, it may be implicit, such as when the response may have another meaning than

acknowledgement for other nodes of the network, which may be other nodes associated with the route, including e.g. the second node.

In response to the sending of the message in Action 901 and in response to identification of a trigger, the first node may stop listening for the response. The trigger, e.g. lapse of a time period, may be predetermined and/or predefined. When the trigger is lapse of a time period, the time period may be based on when a response is no longer possible and/or not likely to occur and/or no longer relevant, e.g. no longer of any use. For example, the time period may be set based on that messages are sent in triplets with known timing, and/or the trigger may be receipt of a subsequent message of the triplet or acknowledgement of such message.

When the message is said unicast message and/or the routing is said unicast routing, the response may be the message being forwarded, i.e. being sent forward, as part of the routing, i.e. according the route, by the second node. For example, if the first node is the source node 121 and the second node is the first intermediate node 122 that forwards the message to a third node that is the second intermediate node 123, this forwarding of the message may be the response and an implicit acknowledgement for the source node 121 with a meaning that the message sent to first intermediate node 122 was received by the first intermediate node 122.

When or if the second node is the destination node, e.g. the second node is the destination node 124, the forwarded message should be configured so that it is thereafter not forwarded by any further node, e.g. by having a time to live value (TTL) that is zero. Note that in this case the message is thus forwarded by the second node despite that the second node is the destination node 124. This is different from conventional handling when a message is received by a destination node. This difference enables that the node preceding the destination node, e.g. the second intermediate node 123 preceding the destination node 124, is able to handle implicit acknowledgements the same way as the other relevant nodes of the route.

The second node is preferably sending the message using, such as over, a radio link that is symmetric and that may be common between the first node, the second node and/or the third node, e.g. radio links 1 15 and 1 16 that may be symmetric and common for communication between the source node 121 and the first intermediate node 122 and communication between the first intermediate node 122 and the second intermediate node 123. Note that the symmetric radio link may be inherent owing to the type of network and or radio access technology being used.

When the message is said group-cast message and/or the routing is said group cast routing, the response may be an acknowledgement message that is another message than the group cast message being acknowledged. In other words, said another message may be a specific and/or explicit acknowledgement message, e.g. for group-cast messages. The acknowledgement message is typically generated by the second node in response to receipt of the group cast message. The acknowledgement message is advantageously sent by the second node after a random delay, e.g. a random time period, i.e. before sending the acknowledgement message the second node may first wait said random time period. The random delay may be random within certain limits that typically are predetermined and/or predefined. For example, the delay may be randomized within a range of 0 to x s, where x is a predefined and/or predetermined number. If or when an upper limit of the delay, e.g. x, is known by the first node, it need of course not listen for the response after the delay has passed. When the message is said route response message, i.e. the RREP message, sent as part of finding said route, the response may be an acknowledgement message that is another message than the RREP message, in other words said another message may be a specific and/or explicit acknowledgement message, e.g. for RREP messages. The acknowledgement message should be broadcasted, e.g. sent as a broadcast message, by the second node and should be configured so that it is not forwarded by any further node, e.g. by having a TTL that is zero.

Action 903

The second node sends, in response to the received message in Action 901 , a response to the message, i.e. may send such a response that the first node is listening for in Action 902.

When the message is said unicast message and/or the routing is said unicast routing, the response may thus be that the second node forward the message, sending the message forward as part of the routing, i.e. according the route, e.g. to said third node. When or if the second node is the destination node, the forwarded message may be configured as described above. The second node is preferably sending the message over a radio link as also described above.

When the message is said group-cast message and/or the routing is said group cast routing, the response may be an acknowledgement message as described above. The acknowledgement message may be generated by the second node in response to receipt of the group cast message. The second node preferable sends the acknowledgement message after a random delay as described above.

When the message is said RREP message, sent as part of finding said route, the response may be an acknowledgement message as described above. The second node should broadcast the acknowledgement message, e.g. send it as a broadcast message, and it should preferably be configured so that it is not forwarded by any further node, e.g. by having a TTL that is zero. Action 904

The first node may identity, and may thus receive, the response that the first node is listening for and that was sent by the second node in Action 903.

Action 905 After the identification of the response in Action 904, the first node may then e.g. determine, based on the identified response, that the message sent in Action 901 was and has been received by the second node. That is, in other words, the first node may determine that it has been acknowledged that the message sent to the second node was received by the second node. When the message is said RREP message, the first node may, in response to the identification and/or determination, e.g. update routing status for the second node.

Thanks to embodiments herein, explicit and implicit acknowledgments as described above and associated with the routing are enabled and/or accomplished, and thereby more robust routing is enabled and/or delays during routing can be avoided, and energy be saved. For example, triplet messages and acknowledgements can be avoided to some extent, e.g. when not adding any value. A message of a triplet may be acknowledged whereby later messages of the triplet, i.e. message copies, and/or related

acknowledgements can be stopped and avoided. Thereby another, new message may be sent sooner than else would be the case, i.e. throughput increase. Also time redundant signalling can be avoided and energy thereby be saved.

Figure 10 is a flow chart schematically illustrating embodiments of a first method, performed by a first node of a Bluetooth based mesh network, e.g. of the wireless communication network 100, the mesh network 100a or the mesh network 100b. The method is for supporting routing in said mesh network between a source node, in the following exemplified by the source node 121 and a destination node, in the following exemplified by the destination node 124, via one or more intermediate nodes, e.g. the first intermediate node 122 and/or the second intermediate node 123. The first node may e.g. be the source node 121 , the first intermediate node 122 or the second intermediate node 123.

The method comprises the following actions, which actions may be taken in any suitable order and/or be carried out fully or partly overlapping in time when this is possible and suitable.

Action 1001

The first node sends a message to another, second node of said mesh network, which second node is neighbouring the first node in said routing. The second node may e.g. be the first intermediate node 122 when the first node is the source node 121 , be the second intermediate node 123 when the first node is the first intermediate node 122, or be the destination node 124 when the first node is the second intermediate node 123.

Further, the message is any one of the following:

a unicast message being routed according to said routing,

a group-cast message being routed according to said routing, and

a route response message, i.a. a RREP message, sent as part of creating a route for said routing.

This action may fully or partly correspond to action 901 as described above. Action 1002

The first node listens for a receipt acknowledging response sent by the second node in response to receipt of the sent message.

In some embodiments, the message is said unicast message, and said receipt acknowledging response is the message being sent forward by the second node as part of the routing to a third node of the mesh network. For example, it the second node is the first intermediate node 122, said receipt acknowledging response may be the message being sent forward by the first intermediate node 122 to the second intermediate node 123 as part of the routing. Alternatively, if the second node is the destination node 124, said receipt acknowledging response may be the message being sent forward by the destination node 124 and configured so that the message thereafter is not forwarded by any further node, e.g. by having a TTL value that is 0.

In some embodiments, the message is said group-cast message, and said receipt acknowledging response is a specific acknowledgement message for group cast messages that is generated by the second node to acknowledge receipt of said group- cast message. In these embodiments, the second node may advantageously send the specific acknowledgement message after a randomized delay that is random within certain predefined limits.

In some embodiments, the message is said RREP message and said receipt acknowledging response is a specific acknowledgement message for RREP messages that is generated by the second node to acknowledge receipt of said RREP message. In these embodiments, the specific acknowledgement message is preferably broadcasted and configured so that it is not forwarded by any further node.

This action may fully or partly correspond to action 902 as described above.

Action 1003 The first node may identify the receipt acknowledging response that the first node is listening for.

This action may fully or partly correspond to action 904 as described above. Action 1004

The first node may determine, based on the identified receipt acknowledging response, that the message has been received by the second node.

This action may fully or partly correspond to action 905 as described above. Figure 11 is a schematic block diagram for illustrating embodiments of a first node

1100, that may be the first node discussed above, e.g. be the source node 121 , the first intermediate node 122 or the second intermediate node 123, and how it may be configured to perform the first method and/or one or more related actions described herein. The first node 1100 is thus configured to operate as a node in said Bluetooth based mesh network and is for supporting routing in said mesh network between said source node, e.g. the source node 121 , and said destination node, e.g. the destination node 124, via one or more intermediate nodes, e.g. the first intermediate node 122 and/or the second intermediate node 123.. The first node 1100 may comprise:

A processing module 1101 , such as a means, one or more hardware modules, including e.g. one or more processors, and/or one or more software modules for performing said method and/or actions.

A memory 1002, which may comprise, such as contain or store, a computer program 1103. The computer program 1 103 comprises 'instructions' or 'code' directly or indirectly executable by the first node 1 100 so that it performs the said method and/or actions. The memory 1 102 may comprise one or more memory units and may be further be arranged to store data, such as configurations and/or applications involved in or for performing functions and actions of embodiments herein.

A processing circuit 1104 as an exemplifying hardware module and may comprise or correspond to one or more processors. In some embodiments, the processing module 1101 may comprise, e.g. 'is embodied in the form of or 'realized by' the processing circuit 1104. In these embodiments, the memory 1102 may comprise the computer program 1103 executable by the processing circuit 1104, whereby the first node 1 100 is operative, or configured, to perform said method and/or actions.

An Input/Output (I/O) module 1105, configured to be involved in, e.g. by performing, any communication to and/or from other units and/or nodes, such as sending and/or receiving information to and/or from other external nodes or devices. The I/O module 1105 may be exemplified by an obtaining, e.g. receiving, module and/or a sending module, when applicable.

The first node 1 100 may also comprise other exemplifying hardware and/or software module(s), which module(s) may be fully or partly implemented by the respective processing circuit. For example, the first node 1100 may further comprise a sending module 1106 and/or a listening module 1107 and/or an identifying module 1108. and/or a determining module 1109.

Hence, the first node 1 100 and/or the processing module 1101 and/or the processing circuit 1 104 and/or the I/O module 1105 and/or the sending module 1 106, are operative, or configured, to send said message to said another, second node.

Further, the first node 1 100 and/or the processing module 1101 and/or the processing circuit 1 104 and/or the I/O module 1105 and/or the listening module 1107, are operative, or configured, to listen for the receipt acknowledging response sent by the second node in response to receipt of the sent message.

Moreover, the first node 1 100 and/or the processing module 1101 and/or the processing circuit 1 104 and/or the identifying module 1108, may be operative, or configured, to identify the receipt acknowledging response that the first node is listening for.

Furthermore, the first node 1100 and/or the processing module 1 101 and/or the processing circuit 1 104 and/or the determining module 1109, may be operative, or configured, to determine, based on the identified receipt acknowledging response, that the message has been received by the second node. Figure 12 is a flow chart schematically illustrating embodiments of a second method, performed by a second node of a Bluetooth based mesh network, e.g. of the wireless communication network 100, the mesh network 100a or the mesh network 100b. The method is for supporting routing in said mesh network between a source node, in the following exemplified by the source node 121 and a destination node, in the following exemplified by the destination node 124, via one or more intermediate nodes, e.g. the first intermediate node 122 and/or the second intermediate node 123. The second node may e.g. be the first intermediate node 122, the second intermediate node 123 or the destination node 124. The method comprises the following actions, which actions may be taken in any suitable order and/or be carried out fully or partly overlapping in time when this is possible and suitable. Action 1201

The second node receives a message from another, first node of said mesh network, which first node is neighbouring the second node in said routing. The first node may e.g. be the source node 121 when the second node is the first intermediate node 122, be the first intermediate node 122 when the second node is the second intermediate node 123, or be the second intermediate node 123 when the second node is the destination node 124. Further, the message is any one of the following:

a unicast message being routed according to said routing,

a group-cast message being routed according to said routing, and

This action may fully or partly correspond to Action 901 as described above.

Action 1202

The second node sends, in response to the received message, a receipt acknowledging response to the first node.

In some embodiments, the message is said unicast message, and said receipt acknowledging response is the message being sent forward by the second node as part of the routing to a third node of the mesh network. For example, if the second node is the second intermediate node 123, said receipt acknowledging response may be the message being sent forward by the second intermediate node 123 to the destination node 124 as part of the routing. Alternatively, if the second node is the destination node 124, said receipt acknowledging response is the message being sent forward by the destination node 124 and configured so that the message thereafter is not forwarded by any further node, e.g. by having a TTL value that is 0.

In some embodiments, the message is said group-cast message, and said receipt acknowledging response is a specific acknowledgement message for group cast messages that is generated by the second node to acknowledge receipt of said group- cast message. In these embodiments, the second node may advantageously send the specific acknowledgement message after a randomized delay that is random within certain predefined limits. In some embodiments, the message is said RREP message and said receipt acknowledging response is a specific acknowledgement message for RREP messages that is generated by the second node to acknowledge receipt of said RREP message. In these embodiments, the specific acknowledgement message is preferably broadcasted 5 and configured so that it is not forwarded by any further node.

This action may fully or partly correspond to Action 902 as described above.

Figure 13 is a schematic block diagram for illustrating embodiments of a second node 1300, that may be the second node discussed above, e.g. be the first intermediate

10 node 122, the second intermediate node 123 or the destination node 124, and how it may be configured to perform the second method and/or one or more related actions described herein. The second node 1300 is thus configured to operate as a node in said Bluetooth based mesh network and is for supporting routing in said mesh network between said source node, e.g. the source node 121 , and a destination node, e.g. the destination node

15 124, via one or more intermediate nodes, e.g. the first intermediate node 122 and/or the second intermediate node 123. The second node 1300 may comprise:

A processing module 1301 , such as a means, one or more hardware modules, including e.g. one or more processors, and/or one or more software modules for performing said method and/or actions.

20 A memory 1302, which may comprise, such as contain or store, a computer program 1303. The computer program 1303 comprises 'instructions' or 'code' directly or indirectly executable by the second node 1300 so that it performs the said method and/or actions. The memory 1302 may comprise one or more memory units and may be further be arranged to store data, such as configurations and/or applications involved in or for

25 performing functions and actions of embodiments herein.

A processing circuit 1304 as an exemplifying hardware module and may comprise or correspond to one or more processors. In some embodiments, the processing module 1301 may comprise, e.g. 'is embodied in the form of or 'realized by' the processing circuit 1304. In these embodiments, the memory 1302 may comprise the

30 computer program 1303 executable by the processing circuit 1304, whereby the first node 1300 is operative, or configured, to perform said method and/or actions.

An Input/Output (I/O) module 1305, configured to be involved in, e.g. by performing, any communication to and/or from other units and/or nodes, such as sending and/or receiving information to and/or from other external nodes or devices. The I/O module 1305 may be exemplified by an obtaining, e.g. receiving, module and/or a sending module, when applicable.

The first node 1300 may also comprise other exemplifying hardware and/or software module(s), which module(s) may be fully or partly implemented by the respective processing circuit. For example, the second node 1300 may further comprise a receiving module 1306 and/or an sending module 1307.

Hence, the second node 1300 and/or the processing module 1301 and/or the processing circuit 1304 and/or the I/O module 1305 and/or the receiving module 1306, are operative, or configured, to receive said message from said another, first node.

Further, the second node 1300 and/or the processing module 1301 and/or the processing circuit 1304 and/or the I/O module 1305 and/or the sending module 1307, are operative, or configured, to send, in response to the received message, said receipt acknowledging response to the first node. Figures 14a-c are schematic drawings illustrating embodiments relating to a computer program that may be any one of the computer programs 1 103 and 1303, and that comprises instructions that when executed by the respective processing circuit 1104, 1304 causes the first node 1 100 or the second node 1300 to perform the respective method as described above.

In some embodiments there is provided a computer program product, i.e. a data carrier, comprising a computer-readable medium and the computer program stored on the computer-readable medium. By computer readable medium may be excluded a transitory, propagating signal and the computer readable medium may correspondingly be named non-transitory computer readable medium. Non-limiting examples of the computer- readable medium are a memory card or a memory stick 1401 as in Figure 14a, a disc storage medium 1402 such as a CD or DVD as in Figure 14b, a mass storage device 1403 as in Figure 14c. The mass storage device 1403 is typically based on hard drive(s) or Solid State Drive(s) (SSD). The mass storage device 1403 may be such that is used for storing data accessible over a computer network 1405, e.g. the Internet or a Local Area Network (LAN).

Each computer program 1103, 1303, may furthermore be provided as a pure computer program or comprised in a file or files. The file or files may be stored on the computer-readable medium and e.g. available through download e.g. over the computer network 1405, such as from the mass storage device 1403 via a server. The server may e.g. be a web or File Transfer Protocol (FTP) server. The file or files may e.g. be executable files for direct or indirect download to and execution on the node for carrying out the respective method, e.g. by the processing circuit 1104 or 1304, or may be for intermediate download and compilation to make them executable before further download and execution causing the node(s) to perform the respective method as described above.

Note that any processing module(s) mentioned in the foregoing may be

implemented as a software and/or hardware module, e.g. in existing hardware and/or as an Application Specific integrated Circuit (ASIC), a field-programmable gate array (FPGA) or the like. Also note that any hardware module(s) and/or circuit(s) mentioned in the foregoing may e.g. be included in a single ASIC or FPGA, or be distributed among several separate hardware components, whether individually packaged or assembled into a System-on-a-Chip (SoC).

Those skilled in the art will also appreciate that the modules and circuitry discussed herein may refer to a combination of hardware modules, software modules, analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in memory, that, when executed by the one or more processors make the first node and the second node to be configured to and/or to perform the above- described methods, respectively.

As used herein, the term "memory" may refer to a hard disk, a magnetic storage medium, a portable computer diskette or disc, flash memory, random access memory (RAM) or the like. Furthermore, the memory may be an internal register memory of a processor.

Also note that any enumerating terminology such as first node, second node, etc., that may have been used herein, as such should be considering non-limiting and the terminology as such does not imply a certain hierarchical relation. Without any explicit information in the contrary, naming by enumeration should be considered merely a way of accomplishing different names.

Identification by any identifier herein may be implicit or explicit. The identification may be unique in the wireless communication network 100 or at least in a part or some area thereof.

The term "device" or "wireless device" as used herein, may also be referred to as e.g. a wireless communication device or a radio communication device. Examples include: target devices, device to device UE, device for Machine Type of Communication (MTC), MTC device, machine type UE or UE capable of machine to machine (M2M) communication, low-cost and/or low-complexity UE, a sensor equipped with UE, a tablet device, a mobile terminal, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (loT) device, or a Narrowband loT (NB-IOT) device, Personal Digital Assistant (PDA), iPAD, Tablet, mobile terminals, smart phone, Laptop Embedded

Equipment (LEE), Laptop Mounted Equipment (LME), Universal Serial Bus (USB) dongles etc. While said terms may be used for convenience, or in the context of examples involving a certain nomenclature, it must be appreciated that the term as such is non- limiting and the teachings herein apply to essentially any type of wireless device.

The term "node" as used herein may as such refer to any type of network node or wireless device, such as described above.

Note that although terminology used herein may be particularly associated with and/or exemplified by certain cellular communication systems, wireless communication networks etc., depending on terminology used, such as wireless communication networks based on 3GPP, this should as such not be seen as limiting the scope of the

embodiments herein to only such certain systems, networks etc. For example, many details of examples above relate to BLE, i.e. are in a particular wireless technology context, and/or may have a specific meaning in such context, as recognized by the skilled person. However, embodiments herein are not limited to only such context(s) as used in the examples.

Claims

A method, performed by a first node (121 ; 122; 123) of a Bluetooth based mesh network (100), for supporting routing in said mesh network (100) between a source node (121) and a destination node (124) via one or more intermediate nodes (122; 123), wherein the method comprises: - sending (901; 1001) a message to another, second node (122; 123; 124) of the mesh network (100), which second node (122; 123; 124) is neighbouring the first node (121 ; 122; 123) in said routing, wherein the message is any one of the following:

a unicast message being routed according to said routing, a group-cast message being routed according to said routing, and a route response, "RREP", message sent as part of creating a route for said routing,

and

- listening (902; 1002) for a receipt acknowledging response sent by the second node (122; 123; 124) in response to receipt of the sent message.

The method as claimed in claim 1 , wherein the method further comprises:

- identifying (904; 1003), the receipt acknowledging response that the first node is listening for, and

- determining (905; 1004), based on the identified receipt acknowledging response, that the message has been received by the second node (122; 123; 124).

3. The method as claimed in any one of claims 1-2, wherein the message is said unicast message, and

said receipt acknowledging response is the message being sent forward by the second node (122; 123) as part of the routing to yet another, third node (123; 124) of the mesh network (100),

or, if the second node (122; 123; 124) is the destination node (124), said receipt acknowledging response is the message being sent forward by the destination node (124) and configured so that the message thereafter is not forwarded by any further node.

The method as claimed in any one of claims 1-2, wherein the message is said group-cast message, and said receipt acknowledging response is a specific acknowledgement message for group cast messages that is generated by the second node (122; 123; 124) to acknowledge receipt of said group-cast message.

The method as claimed in claim 4, wherein the second node (122; 123; 124) has sent the specific acknowledgement message after a randomized delay that is random within certain predefined limits.

The method as claimed in any one of claims 1-2, wherein the message is said RREP message and said receipt acknowledging response is a specific acknowledgement message for RREP messages that is generated by the second node (122; 123; 124) to acknowledge receipt of said RREP message.

The method as claimed in claim 6, wherein the specific acknowledgement message is broadcasted and configured so that it is not forwarded by any further node.

A computer program (1103) comprising instructions that when executed by a first node (1100; 121 ; 122; 123) causes the first node (1100; 121 ; 122; 123) to perform the method according to any one of claims 1-7.

A computer readable medium (1401 ; 1402; 1403) comprising the computer program (1103) according to claim 8.

A method, performed by a second node (122; 123; 124) of a Bluetooth based mesh network (100), for supporting routing in said mesh network (100) between a source node (121) and a destination node (124) via one or more intermediate nodes (122; 123), wherein the method comprises: - receiving (901; 1201) a message from another, first node (121 ; 122; 123) of the mesh network (100), which first node (121 ; 122; 123) is

neighbouring the second node (122; 123; 124) in said routing, wherein the message is any one of the following:

a unicast message being routed according to said routing, a group-cast message being routed according to said routing, and a route response, "RREP", message, sent as part of creating a route for said routing,

and

- sending (903; 1202), in response to the received message, a receipt acknowledging response to the first node (121 ; 122; 123).

The method as claimed in claim 10, wherein the message is said unicast message, and

The method as claimed in claim 10, wherein the message is said group- cast message, and said receipt acknowledging response is a specific acknowledgement message for group cast messages that is generated by the second node (122; 123; 124) to acknowledge receipt of said group- cast message.

The method as claimed in claim 12, wherein the second node (122; 123; 124) sends the specific acknowledgement message after a randomized delay that is random within certain predefined limits.

The method as claimed in claim 10, wherein the message is said RREP message and said receipt acknowledging response is a specific acknowledgement message for RREP messages that is generated by the second node (122; 123; 124) to acknowledge receipt of said RREP message.

15. The method as claimed in claim 14, wherein the specific

acknowledgement message is broadcasted and configured so that it is not forwarded by any further node.

A computer program (1303) comprising instructions that when executed by a second node (1300; 122; 123; 124) causes the second node (1300; 122; 123; 124) to perform the method according to any one of claims 10-15.

A computer readable medium (1401 ; 1402; 1403) comprising the computer program (1303) according to claim 16.

A first node (121 ; 122; 123), configured to operate as a node in a

Bluetooth based mesh network (100), for supporting routing in said mesh network (100) between a source node (121) and a destination node (124) via one or more intermediate nodes (122; 123), wherein the first node (121 ; 122; 123) is configured to:

send (901 ; 1001) a message to another, second node (122; 123; 124) of the mesh network (100), which second node (122; 123; 124) is neighbouring the first node (121 ; 122; 123) in said routing, wherein the message is any one of the following:

and

listen (902; 1002) for a receipt acknowledging response sent by the second node (122; 123; 124) in response to receipt of the sent message.

The first node (121 ; 122; 123) as claimed in claim 18, wherein the first node (121 ; 122; 123) is further configured to:

identify (904; 1003), the receipt acknowledging response that the first node is listening for, and

determine (905; 1004), based on the identified receipt

acknowledging response, that the message has been received by the second node (122; 123; 124).

The first node (121 ; 122; 123) as claimed in any one of claims 18-19, wherein the message is said unicast message, and said receipt acknowledging response is the message being sent forward by the second node (122; 123) as part of the routing to yet another, third node (123; 124) of the mesh network (100),

The first node (121 ; 122; 123) as claimed in any one of claims 18-19, wherein the message is said group-cast message, and said receipt acknowledging response is a specific acknowledgement message for group cast messages that is generated by the second node (122; 123; 124) to acknowledge receipt of said group-cast message.

The first node (121 ; 122; 123) as claimed in claim 21 , wherein the second node (122; 123; 124) has sent the specific acknowledgement message after a randomized delay that is random within certain predefined limits.

The first node (121 ; 122; 123) as claimed in any one of claims 18-19, wherein the message is said RREP message and said receipt

acknowledging response is a specific acknowledgement message for RREP messages that is generated by the second node (122; 123; 124) to acknowledge receipt of said RREP message.

The first node (121 ; 122; 123) as claimed in claim 23, wherein the specific acknowledgement message is broadcasted and configured so that it is not forwarded by any further node.

A second node (122; 123; 124), configured to operate as a node in a Bluetooth based mesh network (100), for supporting routing in said mesh network (100) between a source node (121) and a destination node (124) via one or more intermediate nodes (122; 123), wherein the second node (122; 123; 124) is configured to:

receive (901 ; 1201) a message from another, first node (121 ; 122; 123) of the mesh network (100), which first node (121 ; 122; 123) is neighbouring the second node (122; 123; 124) in said routing, wherein the message is any one of the following:

and

send (903; 1202), in response to the received message, a receipt acknowledging response to the first node (121 ; 122; 123).

The second node (122; 123; 124) as claimed in claim 25, wherein the message is said unicast message, and

The second node (122; 123; 124) as claimed in claim 25, wherein the message is said group-cast message, and said receipt acknowledging response is a specific acknowledgement message for group cast messages that is generated by the second node (122; 123; 124) to acknowledge receipt of said group-cast message.

The second node (122; 123; 124) as claimed in claim 27, wherein the second node (122; 123; 124) sends the specific acknowledgement message after a randomized delay that is random within certain predefined limits.

The second node (122; 123; 124) as claimed in claim 25, wherein the message is said RREP message and said receipt acknowledging response is a specific acknowledgement message for RREP messages that is generated by the second node (122; 123; 124) to acknowledge receipt of said RREP message.

The second node (122; 123; 124) as claimed in claim 29, wherein the specific acknowledgement message is broadcasted and configured so that it is not forwarded by any further node.