Patent Description:
Wireless Mesh Networks, WMNs, Wireless Personal Area Networks, WPANs, or in general communication networks comprised of a plurality of communicatively interconnected devices. Such a network generally comprises multiple network end nodes, network relay nodes, such as bridges, switches and other electric infrastructure devices and equipment, and at least one network control or coordinator device which may provide access to other networks and the Internet, for example. Such a network control or coordinator device is generically called a gateway device.

Network protocols for exchanging data by networked devices or nodes are generally available and known as Bluetooth™, Bluetooth Mesh as well as Wi-Fi based protocols for wireless networks. Examples of communication devices are Customer-Premises Equipment, CPE, having communication capabilities, Internet of Things, loT, devices, and User Equipment, UE, for mobile telephone and data communication. In practice, the term network node device or in short node device or node is generic for all such devices having a unique network address or a unicast address in the network.

Bluetooth Mesh, for example, enables mesh networking for Bluetooth Low Energy, BLE, devices. Nodes that are part of a Bluetooth Mesh network can communicate with each other over the mesh, or with entities on the Internet via a gateway. Relaying of messages is used to facilitate communication between nodes in the mesh that are not within single-hop communication distance. Example of devices that may benefit from being part of such a mesh network includes lights and light switches, Heating, Ventilation, and Air Conditioning, HVAC, sensors and actuators, as well as ambient monitoring and presence sensors.

Bluetooth Mesh networking builds on link layer data broadcasting and networking based on managed message flooding. With managed flooding, the path from the source to the destination need not be known beforehand; instead, any relay node that receives a message helps to forward it to its neighbours. The flooding architecture is simple and robust, and flooding networks adapt well to topology changes.

Two features are used to prevent unlimited forwarding of messages, namely a message cache and a time-to-live, TTL, counter.

However, even with these forwarding constraints, messages are proliferated into large parts of the network, often for no good. Flooding mesh networks are hence wasteful of bandwidth and scales relatively poorly to larger deployments and higher throughputs.

The Bluetooth Mesh specifications define the Bearer, Network, Transport - lower and upper layers, Access layer, Foundation Model layer, and Model layer, and works on top of the Bluetooth Low Energy, BLE, core specification. The bearer layer defines how network messages, or network Protocol Data Units, PDUs, are transported between nodes, and there are two bearers defined in the Bluetooth Mesh Profile specification: the Advertising Bearer and the Generic Attributes, GATT, bearer. Additional bearers may be defined in the future and it is possible to utilize other link technologies as proprietary bearers. A node that supports both the Advertising Bearer and the GATT bearer is referred to as a proxy node, and may be used to include devices that do not yet support the Advertising Bearer, such as some smartphones, in a Bluetooth Mesh network.

Bluetooth Mesh implements a publish-and-subscribe message exchange model. Upon provisioning, every element in a Bluetooth Mesh network is assigned a mesh or a network address. It may also be understood that a single node device comprises several elements. When sending a unicast message to an element, the destination field in the network PDU header is set to the address of the element. By default, a node subscribes to, or listens to, messages sent to any of its element's addresses.

A node may further be configured to subscribe to one or several group addresses or virtual addresses defined in the network. Upon receiving a message sent to a group address or a virtual address to which the node subscribes, the node processes the message. Similarly, a node may be configured to publish messages to a specific group address or virtual address. To do this, a node simply sets the destination field in the network PDU to the corresponding group address or virtual address, and sends the message. In Bluetooth Mesh, the configuration of the publish-and-subscribe patterns are performed by the Configuration Client.

A Group Address, GA, is a multicast address which represents one or more elements. Group addresses are either defined by the Bluetooth Special Interest Group, SIG, and are known as SIG Fixed Group Addresses or they are assigned dynamically. Up to <NUM> SIG Fixed Group Addresses are allowed. A Virtual Address, VA, is an address which may be assigned to one or more elements, spanning one or more Nodes. It takes the form of a <NUM>-bit Universally Unique Identifier, UUID, value with which any element can be associated, and is much like a label.

For monitoring purposes, Bluetooth Mesh includes a message referred to as a heartbeat message. Nodes can be configured to send such heartbeat messages at regular intervals to a specific group address. Nodes that have interest in receiving heartbeat messages subscribe to the same group address. When receiving a heartbeat message, the receiving node can conclude that the node sending the heartbeat message is still active in the network. Furthermore, based on the content of the heartbeat message and the number of times the heartbeat message is received, the receiving node can estimate the reliability of the network from the node sending the heartbeat message, the distance to the node sending the heartbeat message, as well as the active features of the node sending the heartbeat message.

In a particular network, such as a Bluetooth Mesh network, a gateway may interface the network over a non-Bluetooth technology. Such a Bluetooth Mesh gateway may be used, for example, to provide connectivity between the mesh network and a backend server, or between mesh network segments that are geographically separated. To exemplify the latter, nodes in different buildings in a larger campus or industrial area, may still benefit from being part of the same mesh network even though it is not possible to inter-connect the network segments via the mesh itself.

The gateways, in a Bluetooth network, may implement two or three network interfaces over which messages can be sent and received. One interface may, for example, connect to the standardized Advertising Bearer and provide connectivity to other Bluetooth Mesh nodes in the mesh network segment. Another interface may connect to the gateway bearer, which may utilize for example User Datagram Protocol/Internet Protocol, UDP/IP, or Transmission Control Protocol/Internet Protocol, TCP/IP, transport, and may be carried over a cellular, Wireless Fidelity, Wi-Fi, or Ethernet link.

By means of the gateway bearer, mesh network PDUs are tunnelled from the gateway to the backend or between gateways. Accordingly, this solution maintains the mesh security intact end-to-end, at both network and application layer.

Note that it may also be possible to implement gateways using other architectural solutions. For example, when connecting to a backend server, the gateway could terminate the mesh protocol stack and send the data to the backend using some other protocol, such as the Lightweight Machine-to-Machine, LWM2M, protocol. These alternative solutions are not discussed further in this disclosure.

The Institute of Electrical and Electronics Engineers, IEEE, standard <NUM>, and specifically <NUM>. 1D specifies bridging Local Area Network, LAN, segments. In its simplest form, a bridge receiving a frame re-sends it on all interfaces except for the one the frame is received from.

In a more advanced form, the bridge sends the frame only on the interface where the destination node is located. It does so by keeping a database of which node source addresses are heard on which interface. A received frame's destination address is looked up in this table, and the frame is sent on its corresponding interface. If the destination address is not present in the table, the frame is sent on all interfaces, except for the one the frame is received from. Entries in the table are aged and thrown away if no message is heard from the node's address within a certain time. If a frame from a node is heard on an interface other than the one in the table, the new interface is registered from that node. This technique is called transparent bridging.

These two methods, i.e. bridging and transparent bridging, work well if the network of interconnected nodes and network segments is a directed graph. If there are loops in the network, more elaborate algorithms are used such as the IEEE <NUM>. 1D Spanning Tree Protocol, STP.

There are tools available to manage message flooding in Bluetooth Mesh networks. But for a gateway that processes an incoming message published to a group or a virtual address, none of the available tools can be used to determine over which interfaces the message should be forwarded.

By default, messages in a flooding mesh network are proliferated into all parts of the network, often for no good since it is typically only a sub-set of the nodes that have interest in a specific message. The network message cache and the TTL counter are Bluetooth Mesh tools that can be used to limit the forwarding of messages, however, these tools cannot be used to determine if it is useful to forward a message over a given interface, as is the case in a gateway.

Furthermore, the techniques used to limit message forwarding in IEEE <NUM> bridges can be used to control the forwarding of unicast messages, but it is not possible to directly apply these solutions to messages that are published to a group address or a virtual address, following the publish-and-subscribe paradigm employed in Bluetooth Mesh.

Patent document <CIT> discloses a method for unicast packet conversion.

Patent document <CIT> discloses a method for a unicast endpoint client to access multicast internet protocol session.

Patent document <CIT> & <CIT> discloses a method and apparatus for transmitting and receiving data in a mesh network using Bluetooth, that is, a short-distance technology, in a wireless communication system and, more particularly, to a method and apparatus for transmitting and receiving data by configuring a path having a tree structure in a Bluetooth mesh network based on a flooding method.

An object of the present disclosure is to reduce the number of messages being sent in a wireless mesh network, especially in network segments where the messages are proliferated for no purpose.

Another object of the present disclosure is to reduce the traffic over mesh gateway bearers and to limit the proliferation of messages published to group or virtual addresses to network segments in which there is at least one node subscribing to the message.

In a first aspect of the present disclosure, there is presented a method, performed by a gateway device, according to independent claim <NUM>. Further embodiments of the method are provided in dependent claims <NUM>-<NUM>.

In a second aspect of the present disclosure, there is presented a method, performed by a configuration client, according to independent claim <NUM>. A further embodiment of the method is provided in dependent claim <NUM>.

In a third aspect of the present disclosure, there is presented a gateway device arranged for supporting selective forwarding of messages published to one of a group address and a virtual address in a flooding mesh network of communicatively coupled communication devices each having a unique unicast address, according to independent claim <NUM>. Further embodiments of the gateway device are provided in dependent claims <NUM>-<NUM>.

In a fourth aspect of the present disclosure, there is presented a configuration client arranged for supporting selective forwarding of messages published to one of a group address and a virtual address in a flooding mesh network of communicatively coupled communication devices, each having a unique unicast address, serviced by a gateway device, according to independent claim <NUM>. A further embodiment of the configuration client is provided in dependent claim <NUM>.

According to a fifth aspect of the present disclosure, there is provided a computer program product, comprising a computer readable storage medium, according to independent claim <NUM>.

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings illustrating a Bluetooth Mesh system implementation. Other networks or systems and embodiments, operating with other communication protocols, however, are contained within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as limited to only the embodiments set forth herein. Rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

<FIG> schematically illustrates an exemplary Bluetooth Mesh system <NUM> comprising two Bluetooth Mesh network segments <NUM>, <NUM> and two Buetooth Mesh gateways <NUM>, <NUM>. The figure depicts how two Advertising Bearer Segments <NUM>, <NUM> and two Gateway Bearer Segments <NUM>, <NUM> are connected between the two gateways <NUM>, <NUM> and a configuration client <NUM>. The gateways <NUM>, <NUM> in the picture implement network interfaces <NUM>, <NUM>, <NUM>, <NUM> over which messages and/or network Protocol Data Units, PDUs, can be sent and received.

One interface <NUM> connects to the standardized Advertising Bearer <NUM>, <NUM> and provides connectivity to Bluetooth Mesh nodes <NUM> in the Bluetooth Mesh network segment <NUM>, <NUM>.

Another interface <NUM> connects to the Gateway Bearer Segment <NUM>, and interface <NUM> connects by the Gateway Bearer Segment <NUM> to the configuration client <NUM>. Both interfaces <NUM>, <NUM> may utilize, for example, User Datagram Protocol, UDP / Internet Protocol, IP, or Transmission Control Protocol, TCP/IP transport, and may be carried over a cellular Third Generation Partnership Project, 3GPP, Wireless-Fidelity, Wi-Fi, or Ethernet link, or the like.

The Network layer <NUM> in a gateway <NUM>, <NUM>, among others, handles message forwarding and supports sending and receiving messages via multiple bearers. Each instance of a bearer is connected to the Network layer <NUM> via a network interface <NUM> - <NUM>. A message received on the Network layer <NUM> over one interface will be forwarded over the other interface(s). The Network layer <NUM> also implements a dual-layer security scheme, for encrypting and authenticating messages in the Bluetooth Mesh network.

Since the Bluetooth Mesh networking standard is still under development, the gateway device <NUM>, <NUM> may also comprises additional interfaces <NUM> to connect to other nodes over bearers <NUM>, <NUM> to be specified in the future.

<FIG> schematically illustrates a method <NUM> according to the present disclosure. In a first step <NUM>, the gateway device <NUM>, <NUM>; <NUM> receives a message. For the sake of simplicity, the method is further elaborated with the assumption that gateway device <NUM>, associated with mesh network segment <NUM>, receives the message. The skilled person understands that the method is equally applicable when gateway device <NUM> or any other gateway device in the mesh network receives such a message. In step <NUM>, the gateway device <NUM> determines whether the destination address is a Group Address, GA, or a Virtual Address, VA.

A group address is a multicast address which represents one or more elements. Group addresses are either defined by the Bluetooth Special Interests Group, SIG, and are known as SIG fixed group addresses or they are assigned dynamically. Up to <NUM> SIG fixed group addresses are allowed, of which at the time of writing, only four have been defined. These are named All-proxies, All-friends, All-relays and All-nodes. A virtual address is an address which may be assigned to one or more elements, spanning one or more nodes. It takes the form of a <NUM>-bit Universally Unique Identifier, UUID, value with which any element can be associated, and is much like a label.

If it is determined that the destination address is not a group address or a virtual address, step <NUM> result 'No', the message may be processed as usual or may be forwarded in the network using transparent bridging <NUM>, <NUM>. This is not the scope of the present disclosure. The scope of the present disclosure concerns the situation when the gateway device <NUM> determines that the destination address of the received message is a group address or a virtual address, i.e. step <NUM> result 'Yes'.

Subsequently, in step <NUM>, the gateway device <NUM> checks whether the destination address is known to the gateway device. An unknown destination address can be due to, for example, an invalid address format or wrong network identification, ID. If the destination address is not known, i.e. step <NUM> result 'No', the message either may be discarded <NUM>, <NUM> or may be forwarded <NUM>, <NUM> over all interfaces other than the one over which it was received. If the destination address is known to the gateway device <NUM>, i.e. step <NUM> result 'Yes', the method <NUM> proceeds further with step <NUM>.

In this step <NUM>, the gateway device <NUM> retrieves the unicast addresses of all nodes subscribing to the group address or virtual address comprised by the message received by the gateway device <NUM>. It is noted that a unicast address identifies a single, specific element of a node. A Provisioner (not shown) manages the allocation of unicast addresses and ensures that no duplicates are allocated within a network. It is noted that not all unicast addresses need to be subscribed to a group or virtual address. Further, a particular unicast address may be subscribed to plural different group or virtual addresses.

According to a solution proposed by the present disclosure, the gateway device <NUM> may send a query message to the configuration client <NUM>; <NUM> with the received group address or virtual address, requesting the relevant unicast address information. Alternately, it may also be the situation that the configuration client <NUM>; <NUM> has already provided the gateway device <NUM> with mapping information for retrieving the respective unicast addresses. Such a provision by the configuration client <NUM>; <NUM> may occur periodically. In such a case, the mapping information may be stored at the gateway device in a table or in a database, for example. The unicast addresses may then be retrieved by the gateway device from this table or database.

In step <NUM>, the gateway device <NUM> checks whether all the retrieved unicast addresses relate to nodes serviced by the gateway device <NUM>. In other words, the gateway device <NUM> checks whether all the nodes subscribing to the respective group address or virtual address are part of network segment <NUM>. Upon successful determination, i.e. step <NUM> result 'Yes', the message is sent <NUM>, <NUM> by the gateway device <NUM> to all the nodes <NUM> over the respective interfaces over which they may be contacted.

If, however, it is determined that some nodes belong to another network segment <NUM>, for example, i.e. step <NUM> result 'No', the gateway device sends the received message over all interfaces other than the one over which it was received, step <NUM>, <NUM>.

<FIG> schematically illustrates a method <NUM> according to the present disclosure. The method <NUM> illustrates a method to support selective forwarding of messages published to a group address or a virtual address in a Bluetooth Mesh network. In a first step <NUM>, the configuration client <NUM>; <NUM> receives a request or query message from a gateway device <NUM>, <NUM>; <NUM> requesting unicast addresses of communication devices collectively addressed by a group address or a virtual address in a message received by the gateway device. The request or query message comprises the group address or the virtual address received by the gateway device <NUM>, <NUM>; <NUM>, or any other information referring to this group address or virtual address.

The person skilled in the art will appreciate that the configuration client <NUM>; <NUM> is aware of the requested information, as each communication device or node, at the time of registering itself in a mesh network, registers with the configuration client <NUM>; <NUM> and is assigned a unique address in the network by the configuration client, for example.

Furthermore, when a group of communication devices is identified, a unique group address is also assigned by or registered with the configuration client <NUM>; <NUM>. To this extent, the configuration client <NUM>; <NUM> may maintain a database or table. Such a table may, in a first column, contain the unicast address of each node and in a second or further columns contain the group address of the groups to which a particular communication device belongs.

In a second step <NUM>, the configuration client <NUM>; <NUM> forwards, to the requesting gateway device <NUM>, <NUM>; <NUM>, those unicast addresses of nodes that are collectively addressed by the group address or virtual address in the query or request message.

Alternately, a first column may contain a group address and the second and further columns may list the unicast addresses of the communication device belonging to the corresponding group.

In addition to or as an alternative option for steps <NUM>, <NUM>, the configuration client <NUM>; <NUM> may provide or configure <NUM> the gateway device <NUM>, <NUM>; <NUM> with mapping information, mapping unicast addresses of communication devices to group addresses or virtual addresses available to the configuration client <NUM>; <NUM>. This mapping information may be periodically provided by the configuration client <NUM>; <NUM> and stored at the gateway devices <NUM>, <NUM>; <NUM>. In the latter option, for retrieving unicast addresses, step <NUM> may be replaced by accessing the mapping information locally stored.

<FIG> schematically illustrates a gateway device <NUM> according to the present disclosure. The gateway device <NUM> comprises network interfaces <NUM>, <NUM>, <NUM>, <NUM> which are used by the gateway device <NUM> to communicate with other entities in the mesh network. The receive equipment <NUM> is arranged to receive messages or network PDUs. The processor <NUM>, among others, may perform or support steps such as determining that the destination address of a received message is a group address or a virtual address, whether the destination address is known with the gateway device, and transparent bridging, i.e. steps <NUM>, <NUM>, <NUM>, respectively, in <FIG>.

The retrieve equipment <NUM> is arranged to retrieve the unicast addresses of all network elements or nodes that subscribe to the group address or virtual address in the received message, i.e. step <NUM> in <FIG>. The retrieve equipment <NUM> may communicate with the configuration client <NUM>; <NUM> to obtain such information. To this end the retrieve equipment <NUM> may comprise respective transceiver equipment. Alternately, the configuration client <NUM>; <NUM> may periodically provide such information to the gateway device <NUM> through the retrieve equipment <NUM>, for example, which information, in turn, may be stored internally in a table or a database <NUM>. In that case, the retrieve equipment <NUM> obtains the relevant unicast addresses directly from the database <NUM>.

The determine equipment <NUM> is arranged for determining whether all the retrieved unicast addresses belong to nodes that are service by the gateway device <NUM>, i.e. step <NUM> in <FIG>. If it is determined that all the retrieved unicast addresses are of nodes <NUM> serviced by the gateway device, the received message is transmitted to the relevant node devices <NUM> over corresponding network interfaces <NUM> - <NUM> with the help of the transmit equipment <NUM>, i.e. step <NUM> in <FIG>. If at least one node device is not serviced by the gateway device <NUM>, the transmit equipment <NUM> forwards the received message over all interfaces <NUM>-<NUM> except for the one over which it was received, i.e. step <NUM> in <FIG>.

Discard equipment <NUM> is provided, which is arranged to either discarded a received message or to forward the message over all interfaces other than the one over which it was received using the transmit equipment <NUM> when a destination address in a received message is not known to the gateway device, i.e. steps <NUM> and <NUM> in <FIG>.

The gateway device further comprises a memory or other computer readable storage medium <NUM> arranged to store a set of processor executable instructions which when executed by the processor <NUM> cause the gateway device <NUM> to perform a method according to the present disclosure.

The internal components of the gateway device <NUM> communicate with one another using the internal bus <NUM>.

<FIG> schematically illustrates a configuration client <NUM> according to the present disclosure. The configuration client <NUM> comprises receive equipment <NUM> arranged to receive a query or request message from the gateway device <NUM>, <NUM>, <NUM>. i.e. step <NUM> in <FIG>. The query message comprises a group address or a virtual address and the query message requests the unicast addresses of all the nodes that subscribe to that group or virtual address. A mapping of the group addresses to the unicast addresses of nodes are maintained by the configuration client <NUM> in the form of a table or database <NUM>.

The processor <NUM> may obtain the required information from the database <NUM>. The forward equipment <NUM> then forwards the mapping of the unicast addresses to the gateway device <NUM> via the transmit equipment <NUM>, i.e. step <NUM> in <FIG>. Additionally, the configuration client <NUM> may also comprise configure equipment <NUM> which is arranged to periodically configure the gateway devices in the network with information mapping unicast addresses of node devices to group or virtual addresses to which they subscribe, i.e. step <NUM> in <FIG>.

The configuration client also comprises a memory or other computer readable storage medium <NUM> which is arranged to store a set of computer readable instructions which when executed by the processor <NUM> cause the configuration client <NUM> to perform a method according to the present disclosure.

The internal components of the configuration client <NUM> communicate with one another using the internal bus <NUM>.

Claim 1:
A method (<NUM>), performed by a gateway device (<NUM>; <NUM>; <NUM>), to support selective forwarding of messages published to one of a group address and a virtual address in a flooding mesh network (<NUM>) of communicatively coupled communication devices (<NUM>) each having a unique unicast address, said gateway device (<NUM>; <NUM>; <NUM>) comprising a plurality of network interfaces (<NUM>; <NUM>; <NUM>; <NUM>), each arranged for receiving and transmitting messages in respective mesh network segments of said mesh network (<NUM>) and for communicatively coupling to a configuration client (<NUM>; <NUM>), said configuration client (<NUM>; <NUM>) being arranged for maintaining unicast addresses of said communication devices (<NUM>) in said mesh network (<NUM>) and a mapping between unicast addresses and at least one of a group address and a virtual address of communication devices in said mesh network (<NUM>), said method comprising the steps of:
- receiving (<NUM>), by said gateway device (<NUM>; <NUM>; <NUM>), over a network interface (<NUM>; <NUM>; <NUM>), a message published to a group address or a virtual address
- retrieving (<NUM>), by said gateway device (<NUM>; <NUM>; <NUM>), based on said mapping by said configuration client (<NUM>; <NUM>), unicast addresses of all communication devices collectively identified by said group or said virtual address in said received message;
- keeping track, by said gateway device (<NUM>; <NUM>; <NUM>), of which communication devices are heard on which of said plurality of network interfaces (<NUM>; <NUM>; <NUM>; <NUM>);
- determining (<NUM>), by said gateway device (<NUM>; <NUM>; <NUM>), based on said retrieved unicast addresses, that all said communication devices are serviced by said gateway device (<NUM>; <NUM>; <NUM>), and determining over which of said interfaces the message should be forwarded;
- sending (<NUM>), by said gateway device (<NUM>; <NUM>; <NUM>), said received message on said determined interfaces (<NUM>; <NUM>; <NUM>) corresponding to said communication devices addressed by said retrieved unicast addresses.