GB2540178B - Method, system and building control centre for connecting smart devices in a building - Google Patents

Description

Description

Method, system and building control centre for connecting smart devices in a building

The present invention relates to a method system, a system and a building control centre for connecting smart devices in a building. More specifically, the present invention relates to the provision of access to personal area networks by smart devices arranged in a multiple dwelling unit.

The United Kingdom (UK) have mandated the rollout of smart gas and electricity meters and in-home displays (IHD) to all households. These devices are to be linked together at a home using ZigBee™ (in the following referred to as ZigBee) radio (operating at 2.4GHz), utilizing the Smart Energy Profile 1.x through a device called a communications hub (CH). The Medium Access (MAC) and Physical Radio (PHY) layers of ZigBee are defined in the IEEE 802.15.4 standard. In general, this standard specifies low-rate wireless personal area networks (LR-WPANs).

An example of the envisaged typical configuration is given in FIG 1, taken from "Smart Metering Implementation Programme: Prospectus", 27 July 2010, published by ofgem, ofgem E-Serve and the Department of Energy & Climate Change (http ://www.ofgem.gov.uk/e- serve/sm/Documentation/Documentsi/Smart%2 0metering%2 0-%20Prospectus.pdf).

Ofgem's proposal is based on smart metering components such as the above mentioned gas and electricity meters, in-home displays as well as other smart devices, for example provided by energy suppliers (energy providers, utility) to the individual household. The energy provider or utility will most likely also provide a communication hub to which the smart devices are either directly connected using wires or through a wireless home area network (HAN) using the ZigBee communication standard. The communication hub, referred to as WAN Module in FIG 1, also provides access to a wide area network (WAN) to which the energy providers as well as other authorised parties have access. The wide area network is planned to be managed by a central data and communications entity (DCC).

This approach should be suitable for the majority of households where gas and electricity meters as well as in-home displays are all within a limited distance or radio range of the communication hub. The UK Smart Metering Programme assumed that individual networks can be installed separately by energy retailers each time a smart meter is installed in a building (in line with assumptions for "normal" houses).

However, this approach will not be suitable for Multiple Dwelling Units (MDUs) where a larger number of dwellings reside within the same building, and where physical distance between smart devices, building material, interferences or physical space render individual setting up of home area networks required for every dwelling difficult. A proposal addressing the issue of providing a system that enables the implementation of smart metering in multiple dwelling units is disclosed in published patent applications no. GB 2515656 A. The present invention is based on the disclosure of this earlier patent application and specifically develops the operation of the building control centre BCC and corresponding processes further.

According to a first aspect of the present invention, a method for connecting smart devices in a building is provided, wherein a system is realised in the building which comprises at least two bridging devices, each arranged in relative proximity of at least one of a plurality of smart devices arranged at different locations within the building, wherein the at least two bridging devices communicate with the smart devices via wireless connections and with each other via a broadband network and a building control centre, wherein a first of the plurality of smart devices sends a broadcast message for joining an existing personal area network established by a second of the plurality of smart devices, a first of the at least two bridging devices receives the broadcast message sent by the first smart device and sends the broadcast message to the building control centre, the building control centre receives the broadcast message from the first bridging device, determines a second of the at least two bridging devices supporting the second smart device and sends the broadcast message to the second bridging device, and the second bridging device receives the broadcast message from the building control centre and sends the broadcast message to the second smart device.

According to a second aspect of the present invention, a building control centre for a system for connecting smart devices in a building is provided, wherein the system comprises at least two bridging devices, each arranged in relative proximity of at least one of at least two smart devices arranged at different locations within the building, wherein the at least two bridging devices communicate with the smart devices via a wireless connection and with each other via a broadband network and the building control centre, wherein the building control centre comprises at least one processor and at least one memory device, wherein the at least one memory device is used to store at least one routing table comprising at least long and/or short MAC addresses of the smart devices and identities of personal area networks the individual smart device is associated with, and wherein the at least one processor maintains and updates the at least one routing table stored in the at least one memory device.

An example of the system and processes according to the present invention will now be described with reference to the accompanying drawings in which: FIG 1 illustrates the typical smart metering configuration as mandated by ofgem, FIG 2 illustrates an exemplary embodiment of the system, FIG 3 depicts a conceptual component model for the building control centre BCC, FIG 4 illustrates a flowchart of a discovery process according to the invention. FIG 2 corresponds to FIG 5 of the above mentioned published patent application no. GB 2515656 A. FIG 2 illustrates a possible configuration of the system for connecting smart devices in a typical multi dwelling unit MDU. In the given example, connection to the wide area network WAN is realised through communication hubs CHI to CHn, wherein an exemplary routing device R connects the IP backbone network installed in the MDU to the communication hubs CHI to CHn via a bridging device ZBR. The communication hubs CHI to CHn connect to the wide area network WAN wirelessly, using for example well known radio communication standards such as the above mentioned GPRS or UMTS. Furthermore, connection of the IP backbone network to the wide area network WAN is realised via a gateway device GW and a WAN modem WM. Further details of the proposed system and individual components shown in FIG 2 can be found in application GB 2515656 A.

The bridging ZBR and routing devices R forward messages received from smart devices over the radio interface of the respective bridging device to other pairs of routing and bridging devices in the building via a central building control centre BCC, wherein the building control centre is realised as a routing server. This allows connection of the communication hubs CHI to CHn to smart devices, using the ZigBee protocol, even though these devices are not located within the radio communication range of the respective communication hubs. Smart devices are thereby for example Smart Energy Devices such as In-Home Displays IHD1 to IHDn, Gas Meters GM1 to GMn and Electricity Meters EMI to EMn deployed in the building as disclosed in FIG 2. One advantage of this is that, in general, no modifications are required to either the communication hubs or the smart devices as all these devices can continue to communicate with each other using their ZigBee communication standard interfaces.

The following description and examples focus on the responsibilities and functionalities of the building control centre BCC.

In general, the BCC manages a number of ZigBee bridges that are forwarding ZigBee standard based messages wrapped in UDP (User Datagram Protocol) datagrams to it via the IP backbone network which these ZigBee bridges received from smart devices. The BCC monitors these packets and makes routing decisions based on source and/or destination addresses of smart devices comprised in the packets, without having access to the content of the original messages.

The BCC discovers smart devices located somewhere in the building when these try to set up or join an existing ZigBee network, by monitoring broadcast messages received by ZigBee bridges and forwarded on to it via the IP backbone network.

The BCC furthermore maintains a central routing table for all smart devices in the building as these send and receive messages, thereby tracking which other smart devices the individual smart device is associated with, the PAN ID (Personal Area Network ID) of their network and their long and short MAC addresses, if available or used. This also requires monitoring of all ZigBee networks that exist in the building to keep track of the dynamically allocated and therefore transient short MAC addresses of the smart devices. The BCC routes ZigBee messages between ZigBee bridges using the central routing table, thereby effectively extending the range of a ZigBee network to any location in the building where smart devices are installed which are associated with the network.

The BCC also ensures that a smart device attempting to join an existing ZigBee network in the building is not overwhelmed with responses from different ZigBee bridges but joins through the correct ZigBee bridge with which it is being associated by the BCC.

The BCC may further be responsible for shaping the IP traffic over the building's IP backbone network. This is realised for example by mandating that all packets sent by ZigBee bridges over the IP backbone network are addressed to the BCC and subsequently forwarded by the BCC to the addressed smart device via an associated ZigBee bridge. The BCC may furthermore restrict the usage of the IP backbone network, for example by configuring ZigBee bridges to only forward messages to the BCC which cannot be dealt with locally, that is messages sent between two smart devices which are not in radio frequency range of each other or in the frequency range of the ZigBee bridges they are both associated with. As an exception, messages relating to the discovery process will always be forwarded to the BCC and not be dealt with locally, as will be described below in connection with FIG 4. The BCC may also forward on messages, in particular broadcast messages received from a smart device, only to ZigBee bridges associated with the smart device or its personal area network. Where possible, the BCC may also smooth out the IP traffic to minimise peaks in usage, without impacting or significantly delaying transmission of ZigBee messages, for example by prioritising the routing of packets.

Furthermore, the BCC may preferably be configured to remotely manage ZigBee bridges in the building, to allow the installation of only authorised ZigBee bridges, to control filters applied by ZigBee bridges to messages before these are being sent on to the BCC, to control ZigBee bridges to correctly buffer and retransmit messages, to control when MAC acknowledgements are sent by the ZigBee bridges, to allow logs from a ZigBee bridge to be viewed and cleared, if required, to provide and activate firmware upgrades for the ZigBee bridges, and to monitor the status of ZigBee bridges and smart devices supported by the ZigBee bridges. The BCC may also assist in overcoming radio saturation or interference issues by actively managing the radio channels used by ZigBee bridges. For the management of firmware updates, the BCC should preferably provide sufficient storage space to keep firmware images of all ZigBee bridges. The BCC may thereby update the firmware of a group of ZigBee bridges present in the network or of only individual ZigBee bridges. It can also schedule such a firmware update process, for example taking into account the current traffic on the IP backbone network.

The BCC may format and transmit service commands received from upstream systems such as a Network Management System NMS. The BCC may thereby serve as the single point of contact for all required configurations of ZigBee bridges present in the building. Following receipt of ZigBee bridge configuration requests and dependent on the received request type from the NMS, the BCC requests and collects the required data from the ZigBee bridges. Furthermore, based on the responses received from the ZigBee bridges, the BCC formats response packets and the reply back to the NMS.

The BCC may provide an interface for an external administration of the BCC, allowing for example remote updating of the central routing table, authorisation of ZigBee bridges as well as logging and firmware updates.

The BCC should also be capable of creating a backup of its configuration and constant data and of storing this backup for example in a remote backup at the NMS server, while it is then also capable of restoring its configuration data from the backup data stored at the NMS server. This feature may be used when replacement of the BCC in the building is required.

The main requirements of the BCC are broken down into sub components as shown in the exemplary diagram of FIG 3. Each of the components of the BCC is explained in the following, starting with the network functions.

Discovery. Before a smart device can join an existing ZigBee PAN in the building, the BCC needs to be made aware of the following information: The smart device and the ZigBee bridge through which it will communicate, the ZigBee bridge that supports the coordinator device of the PAN, and any other ZigBee bridges through which the smart device may need to communicate to reach other smart devices associated with the s ame PAN.

The function of the discovery component is initially to identify and subsequently to keep up to date the transient addressing data for all smart devices communicating over the building's IP backbone network. This transient addressing data consists of the respective PAN ID of every ZigBee network, the long MAC address and the assigned short MAC address of every smart device.

Smart devices are discovered by the BCC by intercepting ZigBee broadcast messages wrapped as UDP datagrams and forwarded by ZigBee bridges over the building's IP backbone network. The "join" messaging flow used by the smart device to discover the network it wants to join is described below with regard to FIG 4 and for the situation where the joining smart device is out of radio range of the coordinator device of the network.

Routing. The BCC's routing is realised by applying the central routing table obtained during the discovery process to all subsequent ZigBee messages the BCC receives via its IP interface. As mentioned above, all ZigBee messages received by ZigBee bridges are forwarded on to the BCC (with few exceptions). The BCC then reads the unencrypted header fields in the ZigBee message which comprise the destination address, and routes the message accordingly to the ZigBee bridge associated with the addressed destination smart device. The BCC may, however, also configure individual ZigBee bridges to directly route unicast ZigBee data frames to nominated other ZigBee bridge destinations for retransmission to the destination smart devices, thereby reducing its involvement in the routing.

Whenever a known smart device leaves or a known or unknown smart device joins an existing network in the building, it is the responsibility of the BCC to update the white list of the respective ZigBee bridge supporting this smart device and, if required, the white lists of all ZigBee bridges supporting smart devices associated with the same network if these are configured to store destination addresses in their respective white list. The white list maintained in a ZigBee bridge comprises all supported smart devices and is used to handle only those messages received from supported smart devices and to discard those received from smart devices not supported by the ZigBee bridge, for example based on the smart device's source and/or destination address. A single ZigBee bridge may support a plurality of smart devices, wherein each smart device can be part of a different PAN, resulting in a ZigBee bridge supporting multiple PANs.

Any broadcast message will contain a PAN ID which is used by the BCC to select the group of ZigBee bridges supporting the specific network PAN. The BCC forwards the received broadcast message to all ZigBee bridges for retransmission over their ZigBee radio interface. Preferably, however, the broadcast message is only forwarded to those ZigBee bridges which form part of the same one or multiple personal area networks the ZigBee bridge which received the original broadcast message supports. Furthermore, if for example the message is a unicast message, it will contain either a long MAC address or a PAN ID and short MAC address pair, all of which are listed in the BCC's central routing table, thereby enabling the BCC to identify and forward such message to only the relevant ZigBee bridges.

Since the BCC is aware of all PAN IDs of the personal area networks it is connected to via ZigBee bridges, it is possible for the BCC to identify any potential PAN ID conflicts and to prevent the conflict from occurring. This is done for example by extending the standard PAN ID resolution procedures or by responding proactively to any coordinator device that chooses a PAN ID already used elsewhere in the building with a fake PAN Identifier Conflict command message.

Packet Shaping. Because the BCC can be regarded as the central point of communication for all ZigBee bridges, it is capable of modifying how data is being transmitted across the network to minimise congestion on the IP backbone network. This can be achieved for example by delaying the transmission of low priority management messages, relating for example to firmware upgrades, from the BCC to individual ZigBee bridges to times when the load on the building's IP backbone network is low. The BCC can also prioritise the transmission of high-priority or time-bound messages (such as Beacons, Association Requests and Association Responses) involved in the 802.15.4 joining processes over general data frames.

Exemplary BCC Management Functions as shown in FIG 3 are the following.

Management Interface. The BCC is for example enabled to be managed by a single back office system, the Network Management System NMS, via an SNMPv3 interface or other protocol. The BCC also exposes a set of APIs (Application Programming Interfaces) to be used by the NMS. This allows the NMS to read and write configuration information to the BCC as well as providing the BCC with means to notify the NMS of significant events within the building.

This interface also supports the remote management of ZigBee bridges via the BCC. For example, the BCC receives commands on behalf of all ZigBee bridges and forwards these commands to the appropriate ZigBee bridges. Similarly, any notifications originating at a ZigBee bridge can be forwarded on to the NMS as necessary. The BCC thereby acts as a management proxy, ensuring that it is aware of any changes to ZigBee bridges initiated by the NMS. HTTP Interface. The BCC may also support a web-based interface using the HTTP/S protocol to permit an end user, for example an engineer, to access and configure it.

Routing Administration. The BCC may allow an administrator to record which ZigBee bridges each smart device is allocated to. It may also permit storing of details of the smart devices for tracking and other operational purposes.

Firmware Update. The BCC may be capable of updating its own firmware without an engineer needing to be physically present on site. It uses FTP to transfer the firmware in response to an SNMP command, validates the downloaded firmware image and applies it. Alternatively, other means of file transfer, such as HTTP may be used to provide the BCC with new firmware.

The BCC may furthermore be capable of updating the firmware of any ZigBee bridge connected to it via the building's IP backbone network. Again, it may use FTP to transfer the firmware in response to an SNMP command. Alternatively, other means of file transfer, such as HTTP may be used to provide the BCC with the new ZigBee bridge firmware. The BCC validates the downloaded firmware image for the ZigBee bridge, transfers it to the ZigBee bridge using for example the Trivial File Transfer Protocol (TFTP). Subsequently, the

ZigBee bridge validates the received firmware and activates it using SNMP.

ZigBee Bridge Management. The BCC allows an administrator to configure other aspects of a ZigBee bridge such as for example its channel setup, and it may also perform backups, restore the bridge and other operations. This facilitates replacement of a ZigBee bridge as configuration can be overwritten on the replacement device. The BCC can also assist ZigBee bridges to overcome any issues regarding radio saturation and interference for example by being actively involved in the radio channel management of the ZigBee bridges. The BCC physically connects to the NMS WAN modem WM as disclosed in the example of FIG 2 and acts as a support system for all ZigBee bridges present in the building and connected to the IP backbone network. As soon as a ZigBee bridge is connected to the IP backbone network, it is assigned an IP address and finds the BCC.

Log Management. The BCC may maintain a security, activity, exception and general event log, for example for maintenance purposes .

The discovery process mentioned above as one of the network functions of the BCC is now explained in more detail with reference to FIG 4. This figure shows an exemplary configuration of network components, namely two smart devices, two ZigBee bridges and a BCC, and the exchange of messages between these components. In FIG 2, this configuration may correspond to the smart device (802.15.4 Device) on the left of FIG 4 being the IHD1 device, whereas the smart device (802.15.4 Coordinator) on the right of FIG 4 is the EMI device in FIG 2, the latter having the role of the ZigBee coordinator of the PAN (Personal Area Network) which the smart device IHD1 intends to join. In the example of FIG 2, these two devices as well as smart device GM1 are associated with PAN "1" as indicated by index "1" added to the devices' reference signs in FIG 2. Communication hub CHI shown in FIG 2 may also be associated with this PAN and may also act as the coordinator of the PAN instead of the EMI device. The smart device GM1 as well as most other components shown in FIG 2 are, however, not specifically shown in FIG 4 or discussed in the following.

As the example of FIG 2 suggests, smart device IHD1 is not in radio frequency range of the coordinator device EMI, so no direct wireless communication between the two smart devices can be established. Instead, the two smart devices are connected to each other via ZigBee bridges ZBR (in FIG 4 the two 802.15.4 RF Bridge devices on the left and right of the building control centre BCC), IP routers R and the building's IP based backbone network. As described above, all communication between the smart devices is routed from the respective ZigBee bridge supporting the source smart device via the BCC to the ZigBee bridge that supports the destination smart device. Communication between smart devices and ZigBee bridges is realised via the IEEE 802.15.4 ZigBee radio interface (RF Network in FIG 4), while the communication between the ZigBee bridges and the BCC is effected via the IP based backbone network (via IP routers, not shown in FIG 4) installed in the building. The IP based backbone network can thereby be realised either as a wireless network, for example using WLAN/WIFI (standard IEEE 802.11) or as a wire based network, for example using mains already installed in the building for power line communication.

In order for a new smart device to join an existing ZigBee network, the installer, for example an on-site engineer, of the smart device opens a joining window on the coordinator device. A joining window is defined in the ZigBee standard and comprises of a predefined length of time slots allocated to facilitate new smart devices to join the network previously set up by the coordinator device. On the new smart device, the installer initiates the joining process, for example by pressing a corresponding button on the device.

Subsequently, as shown in FIG 4, the new smart device (802.15.4 Device) typically sends a broadcast Beacon Request message on each potential ZigBee radio channel. This Beacon Request message is received by the ZigBee bridge shown in FIG 4 to the right of the smart device, in FIG 2 for example the ZigBee bridge ZBR left of the IHD1 device, on the radio channel of that ZigBee bridge. ZigBee bridges typically operate on only one radio channel. The ZigBee bridge then forwards the Beacon Request message on to the BCC over the IP backbone network. No filtering based on the white lists maintained in the ZigBee bridge is applied to filter broadcast messages received from smart device, instead, all received broadcast messages are in general forwarded on to the BCC.

As described above, before a new smart device can join an existing ZigBee network in the building, the BCC is made aware of the new smart device's long MAC address and of the ZigBee bridge that supports the new smart device.

Furthermore, the BCC knows the ZigBee bridge which supports the coordinator device of the ZigBee network the new smart device attempts to join. The Beacon Request received from the ZigBee bridge supporting the new smart device is hence forwarded by the BCC to the ZigBee bridge supporting the coordinator device via the IP backbone network. In the example of FIG 4, the BCC forwards the Beacon Request on to the ZigBee bridge right of the BCC, corresponding to the ZigBee bridge ZBR left of the smart device EMI in FIG 2. Having received the message from the BCC, the ZigBee bridge supporting the coordinator device broadcasts the Beacon Request over its ZigBee radio interface.

All coordinator devices in the radio frequency range of the ZigBee bridge broadcasting the Beacon Request will, in response to having received such message, subsequently broadcast a Beacon signal comprising the individual PAN ID of their ZigBee network. This broadcast is received by all ZigBee bridges in the radio frequency range of the respective coordinator device which. The ZigBee bridges, in turn, on receipt of the Beacons will apply their respective white list to filter out all Beacons received from devices they don't support, and forward the one or several Beacons received from supported coordinator devices on to the BCC over the IP backbone network. This forwarding of the Beacon broadcast allows the BCC to update its routing table with the information which PAN IDs and coordinator devices are operating behind which ZigBee bridges, that is coordinator devices are in radio frequency range of the respective ZigBee bridge .

The BCC, on receipt of these Beacons from potentially several coordinator devices through potentially several ZigBee bridges, may determine those Beacons in which the so called Association Permit bit according to the ZigBee standard has not been set by the respective coordinator device. This bit indicates if a coordinator device allows any new device to join its existing network. Those Beacons of coordinator devices which do not allow new devices to join, that is where the Association Permit bit is not set, are filtered out by the BCC and are not forwarded on to the ZigBee bridge which received the original Beacon Request from the new smart device, while the remaining Beacons are forwarded by the BCC to this ZigBee bridge. In order to avoid any potential overload of the joining new smart device due to a large number of Beacons, the BCC may forward these in successive small groups to the ZigBee bridge supporting the new smart device .

On receipt of these Beacons forwarded by the BCC, the ZigBee bridge that received the original Beacon Request adds the PAN ID and short MAC address of each coordinator device the Beacons refer to to a temporary white list. The white list is subsequently used by the ZigBee bridge for decisions on sending MAC acknowledgements to the new smart device for messages received from this device and addressed to one of these coordinator devices. It also serves to identify those messages received from the new smart device that need to be forwarded to the BCC.

The new smart device buffers the Beacons received from the ZigBee bridge and one after the other attempts to associate itself with the corresponding ZigBee network. This association attempt is realised by the new smart device by sending a unicast Association Request message addressed to the coordinator device using the PAN ID and short MAC address comprised in the Beacon received from the respective coordinator device. The ZigBee bridge receiving the Association Request from the new smart device, after checking with the established temporary white list, forwards it to the BCC.

The extended MAC address of the new smart device comprised in the source address field of the Association Request message is used by the BCC to update its routing table with this address. The BCC then, using the information collected in the routing table, forwards the Association Request message to the ZigBee bridge supporting the addressed coordinator device, for subsequent transmission of the message to the coordinator device over the ZigBee bridge's radio interface.

The forwarding of the received Association Request message is followed up by the BCC by sending a further message to the ZigBee bridge, instructing it to issue MAC acknowledgements for any message sent by the coordinator device and addressed to the new smart device, and to forward any such message on to the BCC.

Following the sending of the Association Request message, the new smart device also sends a unicast Data Request message addressed to the coordinator device. Similar to the process for the Association Request message, this Data Request message is also forwarded by the ZigBee bridges and BCC to the coordinator device.

The coordinator device, in response to the received Association Request message addressed to it, sends a unicast Association Response message addressed to the new smart device. This Association Response message comprises a short MAC address which the coordinator device has assigned to the new device for use in the subsequent exchange of messages. The Association Response message is forwarded by the ZigBee bridges and BCC to the new smart device, the ZigBee bridges thereby using the established white lists for the forwarding of messages and issuing of MAC acknowledges.

The BCC analyses the Association Response message received from the ZigBee bridge supporting the coordinator device. If the association was successful, the BCC adds the short MAC address assigned to the new smart device to its routing table. Based on the BCC's knowledge of further smart devices that are associated with the same ZigBee network, using the same PAN ID, and with which the new smart device might exchange messages, in FIG 2 for example smart device GM1, the BCC determines all ZigBee bridges which support these further smart devices. These ZigBee bridges are then informed of the new device which has successfully associated with one of their supported ZigBee networks, for example by the BCC providing an updated white list or by updating their white list based on information received from the BCC.

The BCC also requests the corresponding ZigBee bridges to issue MAC acknowledgements to all messages received from supported smart devices that are addressed to the new smart device and to forward these messages to the BCC. Furthermore, the BCC informs the ZigBee bridge supporting the new smart device of any smart devices that are already associated with the same ZigBee network and which the new smart device may require to exchange messages with, again for example by providing the ZigBee bridge with an updated white list or by providing the ZigBee bridge with information based on which it updates its white list. This updated list of associated smart devices replaces the temporary white list previously established in the ZigBee bridge as described above. The list also triggers the ZigBee bridge supporting the new smart device to send MAC acknowledgements as required and to forward messages addressed to any of these associated smart devices to the BCC.

In the event that the association was not successful, the BCC will determine this from the Association Response sent by the coordinator device. Consequently, the BCC will reset its state and the state of all ZigBee bridges involved in the association process to the state immediately before the Association Request was send by the new smart device. The new smart device will then either evaluate the next Beacon it received in response to its broadcasting of a Beacon Request message or indicate to the installer that the network joining process has failed.

With the new smart device having successfully joined a ZigBee network, it can communicate with any smart device that is also associated with the same Zigbee network. Such communication is effected by messages, ZigBee Data Packets, comprising either the long MAC address or short MAC address of the addressed device together with the PAN ID of the ZigBee network. Based on its established routing table, the BCC will route any received messages to the ZigBee bridge supporting the smart device addressed in the message. In the example of FIG 4, the new smart device and the coordinator device exchange ZigBee data packets using the assigned short MAC address.

Also in the case where the new smart device is in radio frequency range of the coordinator device, the BCC still needs to be involved in the association process, even though in principle the association may be realised directly between the two devices without any interactions with the BCC. However, the BCC requires to be involved in the process so that it can determine the PAN ID and short MAC address of the new smart device attempting to join a network. As described above, this information is used by the BCC to configure ZigBee bridges, thereby allowing the new smart device to communicate with other smart devices associated with the same ZigBee network but located outside of the radio frequency range of the new smart device. The requirement of notifying the BCC is addressed by configuring all ZigBee bridges such that all broadcast messages received from smart devices are forwarded on to the BCC, and by establishing a temporary white list in the ZigBee bridge which receives the original Beacon Request from the new smart device, which enables the ZigBee bridge to forward subsequent association messages to the BCC, providing it thereby with the short MAC address as described above. However, once the association process has been completed successfully, the ZigBee bridge or ZigBee bridges supporting the new smart device and coordinator device may not forward any further messages exchanged directly between these two devices to the BCC. This approach also allows for smart devices initially to be joined locally to their network coordinator device, and to subsequently be moved to remote locations and connected to their network via a different, local ZigBee bridge.

As described above relating to the BCC's discovery network function, the BCC is aware of the long MAC address of the new smart device and the ZigBee bridge that should support it already before the new smart device attempts to associate itself with an existing ZigBee network. It is, however, possible that the Beacon Request messages broadcasted by the new smart device are also received by one or multiple ZigBee bridges other than the ZigBee bridge which is supposed to support the new smart device, because these one or multiple ZigBee bridges are also located in the radio range of the new smart device's broadcast transmissions and operate on the radio frequency channel selected by the new smart device.

If the new smart device first selects the radio channel of the ZigBee bridge that should support the device, the procedure is followed as explained above with respect to FIG 4. However, if the new smart device selects the radio channel of a different ZigBee bridge, the above described process continues up to the point where the BCC has gathered sufficient information to determine that this has happened. This state is for example reached when the BCC receives the unicast Association Request message from the new smart device via a ZigBee bridge that, according to the BCC's routing table, should not support the new smart device. The BCC resolves the situation by for example not forwarding the Association Request or any other message from the new smart device on to the ZigBee bridge supporting the coordinator device, but instead by sending a fake Association Response message back to the new smart device via its wrongly chosen supporting ZigBee bridge, the message thereby indicating that the association has failed. This then causes the new smart device to select a different radio channel and to start the process anew. The process is repeated until the new smart device has selected the radio frequency channel of the correct ZigBee bridge, that is the ZigBee bridge that should support the new ZigBee bridge according to the building control centre's configuration.

Claims (14)

Claims

1. Method for connecting smart devices in a building, wherein a system is realised in the building which comprises at least two bridging devices (ZBR, RF Bridge), each arranged in relative proximity of at least one of a plurality of smart devices (IHD1, EMI, Device, Coordinator) arranged at different locations within the building, wherein the at least two bridging devices communicate with the smart devices via wireless connections (RF Network) and with each other via a broadband network (IP Network) and a building control centre (BCC), wherein a first (IHD1, Device) of the plurality of smart devices sends a broadcast message (Beacon Request) for joining an existing personal area network established by a second (EMI, Coordinator) of the plurality of smart devices, a first (ZBR, RF Bridge) of the at least two bridging devices receives the broadcast message sent by the first smart device and sends the broadcast message to the building control centre, the building control centre receives the broadcast message from the first bridging device, determines a second (ZBR, RF Bridge) of the at least two bridging devices supporting the second smart device and sends the broadcast message to the second bridging device, and the second bridging device receives the broadcast message from the building control centre and sends the broadcast message to the second smart device.

2. Method according to claim 1, wherein before the first smart device attempts to join the existing personal area network, the building control centre is informed about the long MAC address of the first smart device and the first bridging device the first smart device will be supported by.

3. Method according to claim 2, wherein the building control centre is also informed about the bridging device that supports the second smart device and any other bridging device supporting further smart devices (GM1) of the plurality of smart devices associated with the same personal area network.

4. Method according to any of the preceding claims, wherein the second smart device is the coordinator of the personal area network.

5. Method according to any of the preceding claims, wherein the first and second bridging devices are identical.

6. Method according to any of the preceding claims, wherein a white list is maintained in every bridging device comprising supported smart devices and further devices associated with the same one or plurality of personal area networks the supported smart devices are associated with.

7. Method according to claim 6, wherein the white list is not applied to broadcast messages received from smart devices or the building control centre.

8. Method according to any of the preceding claims, wherein the first smart device is supported by the first bridging device .

9. Method according to claim 1, wherein in case the first bridging device does not support the first smart device, the building control centre will determine this when receiving an unicast message (Association Request) sent by the first smart device via the first bridging device, and not forward the unicast message to the second bridging device supporting the addressed second smart device, but send a message indicating that the association has failed to the first smart device.

10. Method according to any of the preceding claims, wherein at least one routing table is maintained in the building control centre.

11. Method according to any of the preceding claims, wherein the building control centre, on determining that an identical personal area network identifier (PAN ID) is being used in the building for more than one personal area network, informs the smart device choosing an already used identifier of the conflict.

12. Building control centre (BCC) for a system for connecting smart devices in a building, the system comprising at least two bridging devices (ZBR, RF Bridge), each arranged in relative proximity of at least one of at least two smart devices (IHD1, EMI, Device, Coordinator) arranged at different locations within the building, wherein the at least two bridging devices communicate with the smart devices via a wireless connection (RF Network) and with each other via a broadband network (IP Network) and the building control centre, wherein the building control centre comprises at least one processor and at least one memory device, wherein the at least one memory device is used to store at least one routing table comprising at least long and/or short MAC addresses of the smart devices and identities of personal area networks (PAN ID) the individual smart device is associated with, and wherein the at least one processor maintains and updates the at least one routing table stored in the at least one memory device.

13. Building control centre according to claim 12, wherein the at least one processor maintains and updates at least one white list for every bridging device connected to the broadband network.

14. System for connecting smart devices in a building, the system comprising at least two bridging devices (ZBR, RF Bridge), each arranged in relative proximity of at least one of at least two smart devices (IHD1, EMI, Device, Coordinator) arranged at different locations within the building, wherein the at least two bridging devices communicate with the smart devices via a wireless connection (RF Network) and with each other via a broadband network (IP Network) and the building control centre, wherein the system components implement the method according to claim 1.