WO2018099806A1

WO2018099806A1 - Relaying messages of unreachable nodes via the neighbor network to target mesh network

Info

Publication number: WO2018099806A1
Application number: PCT/EP2017/080258
Authority: WO
Inventors: Antonie Leonardus Johannes KAMP
Original assignee: Philips Lighting Holding B.V.
Priority date: 2016-12-02
Filing date: 2017-11-23
Publication date: 2018-06-07

Abstract

A method of relaying messages to a node of a target wireless mesh network that is currently unreachable within the target network, wherein the target network and a neighbouring wireless mesh network are connected to an intermediary network via respective gateways, the gateways being registered with a portal system of the intermediary network, the method comprising, at a relaying node of the neighbouring network: receiving from the unreachable node of the target network, via a wireless link, a discovery message broadcast by the unreachable node, thereby detecting the unreachable node; causing a notification request to be transmitted from the registered neighbouring network gateway to the portal system via the intermediary network, the notification request comprising an identifier of the target network gateway and an identifier of the unreachable node, thereby causing the portal system to transmit a notification of said detection to the registered target network gateway; receiving from the portal system, via the intermediary network and the neighbouring network gateway, at least one message generated at the target network to be relayed to the unreachable node of the target network; and relaying the at least one message from the relaying node of the neighbouring network, via the wireless link, to the unreachable node of the target network.

Description

RELAYING MESSAGES OF UNREACHABLE NODES VIA THE NEIGHBOR

NETWORK TO TARGET MESH NETWORK

TECHNICAL FIELD

The present invention relates to the relaying of messages in wireless mesh networks. BACKGROUND

US 2004/0264435 discloses a method and an apparatus for providing a client access to a wireless system. The method includes a first wireless access node detecting a client seeking access to the system. After obtaining client information, the first wireless node provides the client a communication path to and from a destination.

A wireless mesh network is a network in which messages are communicated wirelessly, e.g. as RF (radio frequency) signals, between nodes of the network, and in which at least some of those nodes act as routers i.e. operate to route messages between other nodes of the network. That is, a wireless network having a mesh topology. Such networks are also referred to sometimes as ad-hoc networks in certain contexts.

The network may operate according to a mesh networking protocol, such as

ZigBee, Thread etc. ZigBee is a dynamic routing protocol, in that the topology is determined dynamically, and can be autonomously adapted in response to changing network conditions, e.g. to determine new routing paths as nodes are deactivated or change location.

Wireless mesh networks have a variety of applications, for example to provide connected systems such as connected lighting systems, connected sensor systems etc., and increasingly other applications for example in the context of IoT (Internet of Things).

Connected home lighting systems in particular are becoming increasingly popular. Connected lighting refers to a class of lighting system in which the lights can be controlled based on the communication of data between the lights and a controlling device (such as a smartphone, tablet, smart-switch etc.) using network technology, according to at least one network communications protocol.

Connected lighting systems are often based on a wireless mesh network, where each of the lights can operate as a router being able to route messages through the light network (although not all of the lights need necessarily operate as a router at any given time). Because lights are often regularly distributed throughout the house, this allows the range of the network to be extended considerably (as compared with, say, a conventional Wi-Fi network with a single Wi-Fi router), e.g. throughout an entire house.

At least one of the nodes of a wireless mesh network may comprise a gateway, via which the wireless mesh network is connected to another network operating according to a different protocol stack. For example, a TCP/IP network such as a local area network, which may be based on Wi-Fi, Ethernet or a combination of both (for example). To allow communication between the two networks, the gateway may implement some form of protocol conversion, for example between TCP/IP and ZigBee, Thread etc. This can for example allow nodes of the wireless mesh network to be controlled using an external device (i.e. which it not part of the wireless mesh network), such as a smartphone, tablet, smart- switch etc., which communicates with the gateway via the other network.

In order to extend this functionality to remote control outside of the home, a "portal system" (portal) can be provided. The concept of a portal is generally known in the present context, and accordingly the term portal system refers herein to a computer system that provides regulated access to a wireless mesh network via an external network, e.g. the Internet. For example, a known application of a portal system is to allow a user to control his lights, in a connected lighting system, remotely via the Internet. To implement this functionality, the user registers the gateway of his lighting system according to a pre- determined, secure process. Once registered thus, the portal allows the user to control his lights remotely, subject to successful user-authentication. One example of such a portal is the Philips Hue Internet portal, wherein a user first creates a user account for the portal, and can then link a gateway (Hue Bridge) to the portal to allow lights connected to that portal to be controlled via the Internet.

SUMMARY

Various aspects of the present invention pertain to a wireless mesh network (target network) comprising a gateway, and in particular address the issue of one or more nodes becoming unreachable within the target network. Although the use of a mesh topology can extend the range of the wireless network considerably, nodes of the network can still become unreachable within the target network, in that it is not currently possible to communicate messages between that node and the gateway of the target network via the target network. This can occur for example if the node is physically moved out of range of any other nodes of the target network, or if a node relied upon to route messages on behalf of that node is moved or disconnected (and no other node is available that can take its place, where the network implements dynamic routing).

This issue is addressed by using one or more nodes of a neighbouring network (relay nodes) to relay messages from the gateway of the target network to the unreachable node of the target network.

The messages are relayed from the target network to the neighbouring network and, from there, to the unreachable node of the target network via a specific route: the target network gateway and a gateway of the neighbouring network connect their respective mesh networks to a common external network (intermediary network), preferably the Internet, and a portal system of the kind described above relays the messages between the target and neighbouring mesh networks. The gateways are pre-registered with the portal system, for example by users of those networks via a Web interface provided by the portal system. For example, by the users linking their respective gateways to respective user accounts within the portal system.

Because the gateways are pre-registered with the portal, there exists a respective trust relationship between each of the gateways and the portal system.

Beneficially, this means that no direct trust relationship between the two gateways is required to implement the present technology in a secure manner: all messages are relayed via the trusted portal system, which can be implemented to provide whatever security functions are considered appropriate in a given context. Another advantage is that it allows the gateway of the target network to reach the otherwise-unreachable target node via the portal system even when the gateways of the two networks are unable to communicate with each other either directly or via one or more reachable nodes of the target and/or the neighbouring mesh network.

A first aspect of the present invention is directed to a method of relaying messages to a node of a target wireless mesh network that is currently unreachable within the target network, wherein the target network and a neighbouring wireless mesh network are connected to an intermediary network via respective gateways, the gateways being registered with a portal system of the intermediary network, the method comprising, at a relaying node of the neighbouring network: receiving from the unreachable node of the target network, via a wireless link, a discovery message broadcast by the unreachable node, thereby detecting the unreachable node; causing a notification request to be transmitted from the registered neighbouring network gateway to the portal system via the intermediary network, the notification request comprising an identifier of the target network gateway and an identifier of the unreachable node, thereby causing the portal system to transmit a notification of said detection to the registered target network gateway; receiving from the portal system, via the intermediary network and the neighbouring network gateway, at least one message generated at the target network to be relayed to the unreachable node of the target network; and relaying the at least one message from the relaying node of the neighbouring network, via the wireless link, to the unreachable node of the target network.

In embodiments, the portal system may comprise a gateway registration component configured, for each of the target and neighbouring network gateways, to register that gateway with the portal system in response to a gateway registration instruction received from a user of that network.

The gateway registration instruction may be received from a user device operated by that user and comprise an identifier of the gateway to be registered; wherein the registration of the gateway may be conditional on the portal system receiving a confirmation message from the identified gateway.

The confirmation message may be transmitted by the gateway in response to that user physically interacting with that gateway.

The registration of the gateway may be conditional on the confirmation message being received within a time limit.

That gateway may be registered with the portal system by storing, in a user account database accessible to the portal system, an identifier of that gateway in association with a user account of that user.

The portal system may comprise a user authentication component, which validates at least one user credential received from that user; wherein the registration of that gateway by the gateway registration component may be conditional on the user

authentication component determining that the at least one user credential is valid.

The portal system may transmit the notification to the target network gateway in response to determining that both the target network gateway and the neighbouring network gateway are currently registered with the portal system.

The method may comprise, at the portal system: in response to receiving the notification request, accessing a permission setting associated with the target network gateway; and transmitting the notification to the identified target network gateway in response to determining that the target network permission setting permits message relaying via neighbouring networks. The permission setting may be part of the user account of the user of the target network.

The node of the target network may, in response to determining that it is unreachable, repeatedly attempt to contact the target network gateway via the target network, wherein the target network gateway may stop relaying messages to that node via the neighbouring network if it is successfully contacted by that node via the target network.

Alternatively or in addition, in response to receiving the notification from the portal system, the target network gateway may repeatedly attempt to contact the unreachable node via the target network, wherein the target network gateway may stop relaying messages to that node via the neighbouring network if it successfully contacts that node via the target network.

Messages generated within the target network and relayed from the target network via the neighbouring network may be assigned a lower priority within the neighbouring network than messages generated within the neighbouring network (that is, "native" messages in the neighbouring network), causing the relayed messages to be dropped in favour of the messages generated within the neighbouring network when a bandwidth limit of the neighbouring network is reached.

A second aspect of the present invention is directed to a computer program product comprising code stored on a computer readable storage medium and configured, when execute on a relaying node, to implement the method of the first aspect or any embodiment thereof.

A third aspect of the present invention is directed to a relaying node for a wireless mesh network neighbouring a target wireless mesh network, the relaying node for relaying messages to a node of the target network that is currently unreachable within the target network when the target network and a neighbouring wireless mesh network are connected to an intermediary network via respective gateways registered with a portal system of the intermediary network, the relaying node comprising: a network interface configured to receive from the unreachable node of the target network, via a wireless link, a discovery message broadcast by the unreachable node, thereby detecting the unreachable node; a notification component configured to cause a notification request to be transmitted from the registered neighbouring network gateway to the portal system via the intermediary network, the notification request comprising an identifier of the target network gateway and an identifier of the unreachable node, thereby causing the portal system to transmit a notification of said detection to the registered target network gateway; and a relaying component configured to receive from the portal system, via the intermediary network and the neighbouring network gateway, at least one message generated at the target network to be relayed to the unreachable node of the target network, and relay the at least one message from the relaying node of the neighbouring network, via the wireless link, to the unreachable node of the target network.

In embodiments, the relaying node may be configured to implement any of the method steps of any embodiment of the first aspect.

A fourth aspect of the present invention is directed to a message relaying system comprising: a target wireless mesh network; a neighbouring wireless mesh network; and a portal system of an intermediary network, the mesh networks comprising respective gateways registered with the portal system and connected to the intermediary network;

wherein the neighbouring wireless mesh network comprises a relaying node according to the third aspect, or any embodiment thereof, for relaying messages to a node of the target network that is currently unreachable within the target network.

BRIEF DESCRIPTION OF FIGURES

For a better understanding of the present invention, and to show how embodiments of the same may be carried into effect, reference is made by way of example to the following figures in which:

Figure 1 shows a schematic block diagram of a message relaying system according to embodiments of the present invention;

Figure 2 shows a schematic block diagram of a gateway for a wireless mesh network;

Figure 3 shows a schematic block diagram of a network device for a wireless mesh network;

Figure 4 shows a signalling diagram for a process of detecting, at a neighbouring wireless mesh network, an unreachable node of a target wireless mesh network;

Figure 5 shows a signalling diagram for a process of relaying a message to an unreachable node of a target wireless mesh network via a portal system and a neighbouring wireless mesh network; and

Figure 6 shows a functional block diagram of a portal system.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS Example embodiments of the present invention will now be described in the context of wireless mesh lighting networks, comprising network devices in the form of illumination devices (also referred to as luminaires or lights). However, as will be appreciated, the described techniques can be readily extended to other forms of wireless mesh network.

In a conventional, wireless, connected home lighting systems, a key requirement is that every light is reachable within the network so that it can be controlled. This is because the lights are generally only able to communicate within their own network. Often a mesh network is used to optimize this reachability. Nevertheless, as noted, it can be that sometimes a light is too far away from any other router node in the network.

The inventor of the present invention has recognized however that, as more and more households are equipped with connected lighting systems, the likelihood increases that such an unreachable light is actually in reach of a node from a neighbouring network, even if it is not currently reachable within its own network.

The unreachable light autonomously detects this situation, negotiates with the neighbouring network and sets up a secure tunnel through an intermediary network, via a portal system of the intermediary network. This improves the chances that lights can be controlled, without requiring any user interaction, even though it is currently not reachable within its own mesh network. This increases the likelihood that people are able to control all their lights in various network configurations.

For example, a light could be so far away from any other router in the network such that it becomes unreachable. This can arise, for example, where the unreachable light is re-located to the back of a long garden. Interestingly, in this scenario, it may be more likely that the unreachable light is actually in range of at least one neighbouring connected lighting network. Because the network bandwidth required to receive a light control message is negligibly small, it may be acceptable to use the neighbouring network to tunnel the message through to the unreachable light, without any perceptible detriment to the performance of the neighbouring network.

To implement this, each light in the wireless mesh network periodically and autonomously checks if it can be reached from the gateway of that network within that network. If not, the light broadcasts a relay request (discovery message) towards any neighbouring network(s). If the message is detected by a cooperative neighbouring network, it is forwarded via a central portal system to the gateway of the original network. Now that this gateway knows it can reach this light via a neighbouring network, it will relay any control commands through this new route via a secure tunnel (using only leftover

bandwidth). The periodic reachability check continues and if it turns out the light can be reached via the 'normal' route again (i.e. via its own network), it will switch back.

One example scenario of use is where a user has a connected light in the back of his garden. Normally that can be controlled with his system because it can be reached with a hop via the lamp in his living room closest to the garden. However, currently that lamp is powered off, which breaks this link. When he uses his switch or app (application) to turn on his garden light in the evening, it will still go on normally like there is nothing wrong. This is because the control messages are being relayed via the lighting network of his neighbour, which is most closely situated to the back of his garden - this having been arranged autonomously by the lighting systems, without the user needing to be aware of it.

Figure 1 shows a schematic block diagram of a system 100 for relaying messages between a first wireless mesh network, WMl, and a second wireless mesh network, WM2, of the system 100. Mesh networks WMl and WM2 are lighting networks in the described examples, wherein at least some of the nodes are luminaires. Each of the mesh networks WMl, WM2 is a personal area network (PAN), localized within a relatively small area, say, in the vicinity of a user's home.

In addition to the mesh networks WMl, WM2, the system 100 also comprises a third network 102 (intermediary network). A portal system 104 of the intermediary network 102 is shown. The portal system 104 comprises at least one processor 106. The at least one processor 106 is configured to execute portal software, so as to carry out the functionality of the portal system 104 that is described below. The portal system 104 has access to a user account database 108, in which user account data for respective users Ul, U2 of the mesh networks WMl, WM2 is held.

Each of the mesh networks WMl, WM2 comprises a plurality of nodes. At least one of the nodes in each network WMl, WM2 comprises a gateway (bridge) - denoted GW1 and GW2 respectively - via which that mesh network is connected to the intermediary network 102. The intermediary network 102 is the Internet in this example. In some cases one or both of the gateways GW1, GW2 can for example be connected to the intermediary network 102 via one or more respective further networks (not shown), such as a Local Area Network (LAN), e.g. a home Wi-Fi/Ethernet networks, a mobile network (e.g. 3G, 4G, LTE, GSM etc.).

This allows messages to be transmitted and received between the mesh networks WMl, WM2 and the portal system 104, via GW1 and GW2 respectively and the intermediary network 102. In particular, it allows messages to be relayed between the wireless mesh networks WMl, WM2 via the portal system 104 as described in further detail below.

The wireless mesh networks WMl, WM2 operate according to a wireless mesh networking protocol, which is ZigBee in the examples described below, to allow messages to be communicated between the gateway GW1/GW2 and the other nodes (network devices) of the network WM1/WM2, shown as circles, including the nodes labelled Nl in network WMl and N2 in network WM2. The network devices are luminaires in this example, which emit controllable illumination according to commands received from the gateway of its network.

The gateway GW1/GW2 could be a component of one of the lighting devices of the network WM1/WM2; however in the examples described herein they are separate devices, i.e. dedicated gateways. The gateways GWl and GW2 are also referred to as central controller nodes of the mesh networks WMl and WM2 respectively.

Possible routing paths traversed by messages within each mesh network WM 1 ,

WM2 are shown as lines to illustrate possible topologies of these networks, though as we be apparent these are purely exemplary. As indicated, for at least one nodes of each network WMl, WM2, messages are routed between that node and the gateway GW1/GW2 via at least one other node of that network.

By contrast, the intermediary network 102 is, in this example, an IP network; that is, an internetwork (internet) operating according to the TCP/IP Protocol Suite, such as the (public) Internet (capital I). Accordingly the gateways GWl, GW2 implement both types of protocol, in order to allow them to communicate with both the intermediate network 102 and with WM1/WM2 respectively.

Figure 2 shows a schematic block diagram of a gateway GW, such as GWl or

GW2, for a wireless mesh network, such as WMl or WM2. The gateway GW comprises a first network interface 202 configured to connect to the IP network and a second network interface 204, which is a wireless (e.g. RF) interface for communicating with other nodes of the wireless mesh network. The gateway GWl also comprises a processor 206 and a memory 208. The processor 206 is connected to the network interfaces 202, 204 and to the memory 208. The processor 206 executes gateway software (not shown) so as to implement the gateway functionality described herein, though in other implementations at least part of this functionality may be implemented by dedicated hardware of the gateway GW, such as an application- specific integrated circuit, FPGA etc. Figure 3 shows a schematic block diagram of a network device N for the wireless mesh network, such as node Nl or N2 in figure 1. The network device N comprises a network interface 302 adapted for communication with other nodes of the network, such as the gateway GW or other network device having equivalent functionality. The network device N also comprises a processor 306 and a memory 308, with the processor 306 connected to the network interface 302 and the memory 308. In the described examples, the processor 306 executes functional software (not shown) so as to implement the network device functionality described herein, though in other implementations at least part of this functionality may be implemented by dedicated hardware of the network device N, such as an application-specific integrated circuit, FPGA etc.

The network device N also comprises at least one functional component 304 connected to the processor 306, and which is controllable by the processor 306 according to commands received as messages at the network interface 302. As indicated, in this example, the network device N is a luminaire, and the functional component 304 is a lamp (for example an LED lamp formed of one or more LEDs, an incandescent or filament bulb etc.) which can be controlled by the processor 306 to emit light having one more adjustable characteristics (e.g. intensity, colour etc.) according to one or more commands received at the processor 306 via the mesh network. However, alternatively to in addition, the network device N could comprise another type of functional component 304, such as a sensor that outputs sensor data to the processor 306 for transmission via the wireless mesh network.

Returning briefly to figure 1, the wireless mesh networks WM1 and WM2 are neighbouring in that at least one node Nl of network WM1 and at least one node N2 of network WM2 are located in space sufficiently close to one another that it is possible for wireless messages to be transmitted between Nl and N2 directly.

Techniques will now be described which allow messages to be relayed from the gateway GW1 of the wireless mesh network WM1 to node Nl of WM1 - via the portal system 104 of the IP network 102, the gateway GW2 of wireless mesh network WM2, and node N2 of WM2 - in the event that node Nl becomes unreachable to the gateway GW1 within its own mesh network WM1. In this context, WM1 is referred to at the target network, WM2 as the neighbouring network, and N2 as a relaying node.

The terminology of the ZigBee protocol is used for convenience, though as noted the techniques can be extended straightforwardly to other wireless mesh networking protocols, such as Thread, etc. With reference to figure 4, each light in the target mesh network WMl periodically transmits attribute reporting messages 402 to the bridge GWl of the target network WMl, so as to periodically update the bridge GWl with its current state (referred to as "attribute reporting"). That is, in operation, each node repeatedly attempts to contacts its own gateway GWl via its own mesh network WMl . Each attribute reporting message requests a "default response" from the bridge GWl , which denotes successful receipt of the attribute reporting message at the gateway GWl .

As illustrated in figure 1 for light Nl, if the response from bridge GWl to light Nl has timed out a certain number of times (consecutively), i.e. no response is received within a time limit, light Nl concludes that the connection to bridge GWl is broken. The light Nl will then start to periodically broadcast a special request (discovery message, 404) to attempt find neighbouring networks which can relay its connection. These discovery messages are so-called 'interPAN' messages which can communicate between different mesh networks. The discovery message 404 comprises information about the light Nl, and in particular an identifier of the light Nl within the target mesh network WMl (such as its network address within WMl), and information about the target mesh network, and in particular an identifier of the target mesh network WMl (such as a network PAN ID of network WMl, and/or a network address of the gateway GWl on the intermediary network 102, such as its IP address etc.). Multiple discovery messages are sent by cycling through different channels of a wireless link available to the light NW1 and the light Nl monitors the wireless link for a reply to any of these. Note the term "wireless link" refers to any wireless communication medium or media that might available to the light Nl for wireless

communication, which can for example comprise any portion(s) of the electromagnetic spectrum.

If a light of a neighbouring network which supports this functionality detects this request - light N2 of the neighbouring network WM2 in this example - in response the detecting light N2 replies to light N2 with a confirmation request 406 transmitted via the wireless link.

Light Nl then determines whether or not to use light N2 as a relay node. For example, it may have received multiple confirmation requests from different lights, and select one of these based on one or more suitable criteria, such as relative signal strength.

Assuming light N2 is selected by light Nl for use as a relay node, light Nl responds to light N2 with a confirmation response 408, indicated that it has chosen to use light N2's connection. In response, light N2 forwards the request to its own bridge GW2 (that is, the bridge GW2 of the neighbouring network WM2), which in turn forwards the request to the portal system 104 as a notification request 410.

In the meantime, light Nl monitors the relevant channel of the wireless link for a confirmation from its bridge GWl , to be relayed by light N2.

In response to the notification request 410, the portal system 104 contacts the original bridge GWl using the identifier of the network WMl in the request, to inform it that light Nl, as identified in the notification request 410, can be reached via an alternative route through the IP network 102 and portal system 104. That is, the portal system 104 transmits a notification 412 to the gateway GWl of the target mesh network WMl, to notify it that light LI is reachable via a neighbouring network.

In response to the notification 412, bridge GWl sends a confirmation message 414 via the portal system 104 and the neighbouring network WM2 to light Nl . This is received at gateway GW2, routed to light N2, and in turn relayed from light N2 to light Nl via the channel being monitored by light Nl . This causes light Nl to stay on this channel, i.e. continue monitoring it for commands from its own gateway GWl and relayed via the portal system 104 and light N2.

With reference to figure 5, if bridge GWl needs to send a light control command 502 to light LI, it sends it via the portal system 104 and neighbouring network WM2 (i.e. via bridge GW2 and light N2). To do this, the payload can be packed in a tunnel message and sent to the light N2 via said route, which will unpack it and then repack and forward as an interPAN message 504.

Tunnelling allows communication between networks operating according to different protocol stacks - e.g. TCP/IP vs. ZigBee in this context. It works by effectively "wrapping up" the protocol stack of one network inside the protocol stack of another other - so that the payload of (say) an IP packet(s) sent from GWl over IP network 102 via the portal system 104 to tunnel into the neighbouring network WN2 network can include not only the 'actual' payload data intended for the ultimate recipient LI, but also ZigBee header data for the neighbouring network. However, the techniques are not limited to this form of tunnelling, and the header data can alternatively be generated at the neighbouring network WM2 itself, for example.

Preferably, the command is encrypted and signed by the gateway by the gateway GWl, to provide security comparable with relaying via the target mesh network WMl in the conventional manner. Security- wise there is little difference with the normal route since the command is encrypted and signed with the network in exactly the same way as if it was send directly over its own network WM1.

Once this new "detour" connection has been established between LI and GWl - via portal system 104, GW2, and MW2 - periodic reporting continues via this new detour connection, to check if that it still alive. If this connection breaks, light LI will search for new connection possibilities. First it will check if it can again reach bridge GWl via its own network WM1, and if not it will look for other potential neighbours in the same manner as described above. If no new connection possibilities are found, it will resume listening on its own network, and may retry after a suitably long timeout.

To make sure that the detour connection is used only when necessary, light LI will periodically attempt to send a report to bridge GWl via its own network WM1 even after the detour connection has been established. If and when bridge GWl reports to light LI that it has received this report, the network WM1 will immediately revert back to working as normal, i.e. with communication between GWl and light LI confined to the target mesh network WM1 itself. Alternatively or in addition, the gateway GWl can repeatedly attempt to contact light Nl via the target mesh network WM1, and the system can switch if the gateway GWl successfully contacts the light Nl .

To make sure the neighbouring network WM2 is not negatively impacted by this, preferably only leftover bandwidth of WM2 is used. This is rendered possible by allocating the tunnelled messages a lower priority than all other messages in the neighbouring network WM2, and dropping messages according to priority if there are too many (i.e. if as a whole the bandwidth requirement of the messages across WM 2 exceeds available bandwidth). For example, by setting a priority level in header data of those messages. That is, so as to cause messages generated at the target network WM1 and being relayed via the neighbouring network WM2 to be dropped by the neighbouring network WM2 in favour of messages generated within the neighbouring network WM2 itself if a bandwidth limit of the neighbouring network WM2 is reached.

Although normal light control typically requires only minimal bandwidth, there are cases where more bandwidth is needed like when streaming light effects to synchronize with media (games/movies/music etc.). That means that if bridge GWl is streaming, it will break the connection with lamp LI in the event that the streaming would negatively impact the neighbouring network WM2, due to the lower priority messages from WM1 being dropped within WM2. Each of the steps described above can be implemented by functional components of the relevant node or system, such as code modules executed on processor 106, 206 or 306 as applicable, and/or dedicated hardware, such as an application- specific integrated circuit, FPGA etc.

Portal Architecture:

As is well known in the art, the IP network 102 has a plurality of network layers, including an application layer, a transport layer below the application layer, and an internet layer below the transport layer.

The network layer provides basis routing between individual networks of the internet 102, by routing IP packets between those networks. Among other things, the IP network 102 comprises a plurality of IP routers (103, figure 1) which operate to perform this routing within the IP network 102, and in particular to route messages between the gateways GWl, GW2 and the portal system 104. In performing this message routing, the operation of the IP routers 103 is restricted to the network layer and below i.e. the routers do not operate at the transport layer or above in performing this message routing function.

By contrast, the transport layer provides so-called "end-to-end" connectivity between different devices of the IP network 102, and in particular between the portal system 104 and each of the gateways GWl, GW2. End-to-end is a well-established concept in the field of network technology, and refers to the fact that application-specific features reside only in devices operating at the transport layer and above.

The portal system 104 is a server-entity i.e. a system comprising one or more servers in which the processor(s) 106 are embodied. As such, the portal system 104 operates at the application layer of the IP network 102, wherein messages received/transmitted at/from the portal system 104, including messages to be relayed between the two wireless mesh networks WM1, WM2, are processed by the portal system 104 at the application layer of the IP network 102 after reception/prior to transmission.

In order to communicate with the portal system 104, each of the gateways GWl, GW2 has respective end-to-end connectivity with the portal system i.e. at a transport layer of the intermediary network, below the application layer. For example, in order to communicate with each gateway GWl, GW2, a TCP connection (or another form of end-to- end, transport layer connection) may be established between that gateway and the portal system. The end-to-end connection can for example be secured using, say, TLS or another suitable cryptographic, transport layer protocol. That is, at the application layer, the end-to-end connectivity between the portal system 104 and each of the gateways GW1, GW2 is used to provide service-to-service commination between the portal system 104 and each of the gateways GW1, GW2.

Figure 6 shows an exemplary functional block diagram of the portal system 104. The portal system 104 is shown to comprise a user authentication component 602 and a gateway registration component 604. These represent functionality implemented, at the application layer of the IP network 102, by the portal software when executed on the at least one processor 106 of the portal system 104.

Prior to performing the steps of figures 4 and 5, each of the gateways GW1, GW2 is registered with the portal system 104, by the gateway registration component 604 in a manner that will now be described.

The gateway registration component 604, in response to a gateway registration instruction 606 received from a user (U1/U2) of a wireless mesh network (WM1/WM2), registers a gateway GW (GW1/GW2) of that mesh network identified thereby. In this example, the gateway registration instruction is received from a user device 608 operated by that user and comprises an identifier of the gateway GW to be registered, such as its IP address on the IP network 102. The user device 608 and gateway GW can communicate via e.g. a wireless channel between them, allowing the user device 608 to obtain any information about the gateway needed to send the registration instruction 606.

To provide additional security, preferably the registration of the gateway, by the gateway registration component 604, is conditional on the portal system 104 receiving a confirmation message 614 from the identified gateway GW itself. For example, in response to the registration instruction 606, the gateway registration component 604 may transmit a confirmation request 610 to the identified gateway GW, to which the confirmation message 614 is sent in response. Preferably, the confirmation message 614 is only sent if the user physically interacts with the gateway GW by providing a specified user input 612 directly to the gateway (e.g. pressing a physical button on the gateway, or otherwise actuating a user interface of the gateway GW that requires him to be in physical proximity to the gateway GW) within a certain amount of time of the confirmation request 610 being received at the gateway GW. This ensures that the gateway GW can only be registered by a user at the same physical location of the gateway GW.

For example, the registration of the gateway GW by the gateway registration component 604 may be conditional on the confirmation message 614 being received within a time limit of the confirmation request 610. The gateway GW is registered with the portal system 104 by storing, in the user account database 108, an identifier of that gateway in association with a user account of the user registering the gateway GW, thereby linking that gateway GW to that user account in the user account database 108.

In order to implement this functionality, before registering the gateway GW, the user is required to authenticate himself to the gateway system 104, by providing at least one user credential 616 to the user authentication component 602, such as a user identifier (e.g. user name, email address etc.) and associated password. The user authentication component 602 validates the at least one user credential 616, and allows the user to log in to the portal system 104 only if the user credential(s) is valid. The portal system 104 will only allow the user to link a gateway to his account once logged in, which in turn requires him to provide valid user credential(s) beforehand.

The operations of the portal system 104 described above with reference to figures 4 and 5, including the transmitting and receiving of messages 410, 412, 414 and command 502 are all implemented at the application layer of the IP network 102, with those messages being processed at the application layer upon reception at the portal system 104 or prior to transmission form the portal system 104 as applicable. Preferably, the performance of these operations is conditional on both gateways GW1, GW2 being currently registered with the portal system in the user account database 108. That is, on those gateways having been successfully linked to the respective user accounts of the users Ul , U2 of the mesh networks WM1, WM2 respectively, within the user account database 108.

Preferably, each of the user accounts also comprises a permission setting, which the user of that account can set as he wishes in order to activate or deactivate relaying via neighbouring mesh networks, allowing him to choose whether or not to make use of this available functionality. In this case, when the notification request 412 is received at the portal system 104, the portal system 104 accesses the permission setting associated with the target network gateway GW1 in the user account of user Ul . The notification 414 is transmitted to GW1 only if that permission setting permits message relaying via

neighbouring networks.

The portal system can for example be provided by a cloud-computing platform

(the cloud), in which the computing resources of a plurality of processors of the cloud platform are allocated to back-end services based on hardware virtualization. For example, the portal software may run on one more virtual machines, which in turn run on one or more physical processors of the cloud platform. As indicated, all description herein relating to lighting networks and lights applies equally to other types of network devices in other types of wireless mesh network, such as sensor networks. The target and neighbouring mesh networks WM1, WM2 need not be of the same type - for example commands from a lighting network can be relayed via a sensor network and vice versa.

It will be appreciated that the above embodiments have been described by way of example only. Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. Any reference signs in the claims should not be construed as limiting the scope.

Claims

CLAIMS:

1. A method of relaying messages to a node (Nl) of a target wireless mesh network (WMl) that is currently unreachable within the target network (WMl), such that it is not possible to communicate messages between that node (Nl) and the gateway (GWl) of the target network (WMl) via the target network (WMl), wherein the target network (WMl), and a neighbouring wireless mesh network are connected to an intermediary network via respective gateways (GW1,GW2), the gateways being registered with a portal system (104) of the intermediary network; wherein the portal system comprises a computer system that provides regulated access to a neighbouring wireless mesh network (WM2) via the intermediary network; the method comprising, at a relaying node of the neighbouring network (WM2):

receiving from the unreachable node (Nl) of the target network (WMl), via a wireless link, a discovery message (404) broadcast by the unreachable node (Nl), thereby detecting the unreachable node (Nl);

causing a notification request (410) to be transmitted from the registered neighbouring network gateway (GW2) to the portal system (104) via the intermediary network, the notification request (410) comprising an identifier of the target network gateway (GWl) and an identifier of the unreachable node (Nl), thereby causing the portal system (104) to transmit a notification (412) of said detection to the registered target network gateway (GWl);

receiving from the portal system (104), via the intermediary network and the neighbouring network gateway (GW2), at least one message generated at the target network (WMl) to be relayed to the unreachable node (Nl) of the target network (WMl); wherein the portal system (104) comprises a user authentication component (602), which validates at least one user credential received from that user network from a user device (608) operated by that user;

and wherein the portal system (104) further comprises a gateway registration component (604) configured, for each of the target and neighbouring network gateways (GW1,GW2), to register that gateway with the portal system (104) in response to a gateway registration instruction (606) received from a user of that network from a user device (608) operated by that user and the registration of that gateway is conditional on the user authentication component determining that the at least one user credential is valid;

and

relaying the at least one message from the relaying node of the neighbouring network, via the wireless link, to the unreachable node (Nl) of the target network (WMl).

2. A method according to claim 1 , wherein the gateway registration instruction (606) is received from a user device (606) operated by that user and comprises an identifier of the gateway to be registered;

wherein the registration of the gateway is conditional on the portal system

(104) receiving a confirmation message (614) from the identified gateway.

3. A method according to claim 2, wherein the confirmation message (614) is transmitted by the gateway in response to that user physically interacting with that gateway.

4. A method according to claim 2 or 3, wherein the registration of the gateway is conditional on the confirmation message (614) being received within a time limit.

5. A method according to any of claims 1 to 4, wherein that gateway is registered with the portal system (104) by storing, in a user account database (108) accessible to the portal system (104), an identifier of that gateway in association with a user account of that user.

6. A method according to any preceding claim, wherein the portal system (104) transmits the notification (412) to the target network gateway (GWl) in response to determining that both the target network gateway (GWl) and the neighbouring network gateway (GW2) are currently registered with the portal system (104).

7. A method according to any preceding claim, comprising, at the portal system (104):

in response to receiving the notification request (410), accessing a permission setting associated with the target network gateway (GWl); and

transmitting the notification to the identified target network gateway (GWl) in response to determining that the target network permission setting permits message relaying via neighbouring networks (WM2).

8. A method according to claims 5 and 7, wherein the permission setting is part of the user account of the user of the target network (WMl).

9. A method according to any preceding claim, wherein the node (Nl) of the target network (WMl), in response to determining that it is unreachable, repeatedly attempts to contact the target network gateway (GW1) via the target network (WMl), wherein the target network gateway (GW1) stops relaying messages to that node (Nl) via the neighbouring network (WM2) if it is successfully contacted by that node (Nl) via the target network (WMl); and/or

wherein in response to receiving the notification (412) from the portal system

(104), the target network gateway (GW1) repeatedly attempts to contact the unreachable node (Nl) via the target network (WMl), wherein the target network gateway (GW1) stops relaying messages to that node via the neighbouring network (WM2) if it successfully contacts that node (Nl) via the target network (WMl).

10. A method according any preceding claim, wherein messages generated within the target network (WMl) and relayed from the target network (WMl) via the neighbouring network (WM2) are assigned a lower priority within the neighbouring network (WM2) than messages generated within the neighbouring network (WM2), causing the relayed messages to be dropped in favour of the messages generated within the neighbouring network (WM2) when a bandwidth limit of the neighbouring network (WM2) is reached.

11. A computer program product comprising code stored on a computer readable storage medium and configured, when execute on a relaying node (N2), to implement the method of any preceding claim.