NETWORK CONFIGURATION

A method of configuring a network, the network comprising a plurality of devices capable of operating according to a wireless communications protocol, each device having a device type, each device communicating directly with one or more local devices of a local group, the local devices being those devices of the network with which the device is in direct communications range, the method comprising: storing a device configuration for each device; at a device: detecting that a first local device having a first device type has left the local group, and detecting that a further device having the first device type has entered the local group; determining that the further device is a replacement for the first local device; and applying the stored configuration for the first local device to the further device.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
CROSS REFERENCE TO RELATED APPLICATIONS

This non-provisional patent application claims priority to Great Britain applications: GB 1412722.9, filed Jul. 17, 2014; GB 1405790.5, filed Mar. 31, 2014; GB 1403314.6, filed Feb. 25, 2014; GB 1405785.5, filed Mar. 31, 2014; GB 1405786.3, filed Mar. 31, 2014; GB 1405789.7, filed Mar. 31, 2014; GB 1403312.0, filed Feb. 25, 2014; GB 1405791.3, filed Mar. 31, 2014; GB 1405797.0, filed Mar. 31, 2014.

TECHNICAL FIELD

This invention relates to configuring the devices of a network, for example configuring the devices of a mesh network.

BACKGROUND

There is an increasing need for a variety of objects to be equipped with the ability to send and receive messages. In the case of the home, for example, it may be desirable for multiple devices to be able to communicate with each other, and also potentially with the internet or cloud, in order to allow for more automated control of the home. For example, a home may contain a lighting system, heating appliances and sensor devices. By allowing these devices to communicate with each other certain controls can be automated, such as turning on the lights and the heating when the sensor detects that a person has entered a room.

To enable arbitrary objects to communicate, they can be equipped with communication devices. As many of these objects may not have access to, or require, power themselves (for example a window or a door), there may be a desire that the communication devices be battery-powered devices that consume very little power.

Low-powered communications equipment may not have sufficient communication range to communicate directly with other equipment located in the network. A suitable network for such devices to adopt may be a mesh network, in which a device can communicate with a remote device outside its communication range via one or more intermediary devices. In this arrangement the intermediary devices function to relay a received message.

FIG. 1 shows such a mesh network. The network comprises a number of devices 101, 102, 103 and 104. Each device can communicate wirelessly with other devices that are in effective range of it by means of an incorporated wireless communications device 101a, 102a, 103 and 104a. Communication devices 102a and 104a may manage operation of lights 102b and 104b, respectively, and communication device 101a may monitor a sensor to determine if window 101b is open or closed. The communications devices cooperate to propagate signals between them. The communication range of device 101a is bounded by boundary 105. The communication range of device 104a is bounded by boundary 106. If communications device 101a transmits a signal, that signal can be received by devices 102a and 103 which are within range of device 101a. Device 104a is out of range of device 101a. However, device 103 can relay the signal received from device 101a so that it can be received by device 104a. This method of communication allows devices to communicate even though they are out of direct range of each other.

In order for the operation of appliances connected in such a mesh network to be automated based on a predetermined schedule and/or the state of other devices in the network, the appliances and the network may first be configured accordingly by the network user. Every time a new appliance is added to the network, that appliance and the network may be re-configured to cause the appliance to operate automatically in the desired manner. This is particularly burdensome in the case that the new appliance is a replacement for another appliance, for example in the case that a light bulb has blown and been replaced by an equivalent light bulb. In this situation, for every light bulb that is replaced, the user may have to manually configure the light bulb to communicate with the mesh network according to the mesh network communications protocol, and also manually configure the lighting operation of the light bulb, i.e. when it is to turn on and off.

There is a need for an improved way of reconfiguring a network of devices when a replacement device is introduced in a network.

SUMMARY OF THE INVENTION

According to one aspect of the invention there is provided a method of configuring a network, the network comprising a plurality of devices capable of operating according to a wireless communications protocol, each device having a device type, each device communicating directly with one or more local devices of a local group, the local devices being those devices of the network with which the device is in direct communications range, the method comprising: storing a device configuration for each device; at a device: detecting that a first local device having a first device type has left the local group, and detecting that a further device having the first device type has entered the local group; determining that the further device is a replacement for the first local device; and applying the stored configuration for the first local device to the further device.

Suitably, the further device is associated with an appliance supplementary to its wireless communications function, and applying the stored configuration to the further device configures functionality of the appliance.

Suitably, applying the stored configuration to the further device configures the further device to communicate over the network according to the wireless communications protocol.

Suitably, the method comprises at each device: storing identities of the local devices of the local group of that device in a store; from each local device, receiving an identifier message comprising an identity of the local device and an instruction not to retransmit the identifier message; and updating the store with the identities of the local devices of the local group.

Suitably, the identifier message comprising the identity of the local device specifies the device type of the local device.

Suitably, each local device transmits an identifier message in response to receiving a trigger message from the device.

Suitably, each local device transmits an identifier message in response to receiving a trigger message from a central network entity.

Suitably, the trigger message and the identifier message are both transmitted in a low or no security mode such that a device which is not yet associated with the network can successfully receive the trigger message and transmit the identifier message.

Suitably, each device periodically reports the identities of the local devices in the local group of that device to a central network entity.

Suitably, each device reports the identities of the local devices in the local group of that device to a central network entity only if the identities of the local devices in the local group have changed since the device last reported the identities of the local devices in the local group to the central network entity.

Suitably the method comprises, at the central network entity, determining that the further device is a replacement for the first local device if more than one device reports to the central network entity that: the identities of the local devices no longer include the first local device's identity; the identities of the local devices include the further device's identity; and the first local device and the further device have the same device type.

Suitably the method comprises, at the central network entity, determining that the further device is a replacement for the first local device if each of the devices which were local devices of the first local device reports to the central network entity that: the identities of the local devices no longer include the first local device's identity; the identities of the local devices include the further device's identity; and the first local device and the further device have the same device type.

Suitably, the device configurations of each device are stored at a central network entity.

Suitably, the device configurations of each device are stored in a distributed manner across the devices of the network.

Suitably, the network is a mesh network.

Suitably, the devices operate according to the Bluetooth Low Energy protocol.

According to another aspect of the invention there is provided a network comprising: a plurality of devices capable of operating according to a wireless communications protocol, each device having a device type, each device communicating directly with one or more local devices of a local group, the local devices being those devices of the network with which the device is in direct communications range; wherein each device is configured to: detect that a first local device having a first device type has left the local group, and detect that a further device having the first device type has entered the local group; wherein the network is configured to: store a device configuration for each device, determine that the further device is a replacement for the first local device, and apply the stored configuration for the first local device to the further device.

Suitably, the further device is associated with an appliance supplementary to its wireless communications function, and the further device is configured to apply the stored configuration to the appliance.

Suitably, each device comprises a store for storing the identities of the local devices of the local group of that device, and each device is configured to update the identities stored in the store on receiving identifier messages from the local devices, each identifier message including an identity of the local device that sent the identifier message.

According to another aspect of the invention there is provided a method of determining the topology of a network, the network comprising a central network entity and a plurality of devices capable of operating according to a wireless communications protocol, each device communicating directly with one or more local devices of a local group, the local devices being those devices of the network with which the device is in direct communications range, the method comprising: at each device, from each local device, receiving an identifier message comprising an identity of the local device and an instruction not to retransmit the identifier message; at each device, reporting the identities of the local devices in the local group of that device to the central network entity; and at the central network entity, determining the topology of the network by collating the identities of the local devices in the local groups of each device.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described by way of example with reference to the drawings. In the drawings:

FIG. 1 illustrates a mesh network;

FIG. 2 illustrates a further mesh network;

FIG. 3 illustrates a wireless communications device;

FIG. 4 illustrates a message format;

FIG. 5 illustrates a method of updating a store of the identifies of the local devices in the local group of a device; and

FIG. 6 illustrates a method of determining that a device of the network has been replaced by another device and configuring that other device.

DETAILED DESCRIPTION

FIG. 2 shows a mesh network comprising a plurality of devices 201, 202, 203, 204, 205, 206 and 207. Each of these devices has an integrated wireless communications unit which is capable of communicating with the other devices of the mesh network using a wireless communications protocol. The devices communicate with each other using the same wireless communications protocol. That could be a relatively short-range protocol. For example, the effective range of each device may be less than 25 m. That characteristic may permit the devices to use less power for transmitting and/or receiving than would be expected in a longer range protocol. Examples of such wireless communications protocols are Bluetooth Low Energy, Zigbee, IEEE 802.11 and Zwave. The devices communicate in an ad hoc manner in order to transfer data between each other.

One or more of the devices is associated with an appliance supplementary to its wireless communications function. The appliance may be mains powered, for example a light fitting. Suitably, the integrated wireless communications units associated with the mains powered appliance is also mains powered. Alternatively, the appliance may be battery-powered, for example a door alarm. Suitably, the integrated wireless communications unit associated with the battery-powered appliance is also battery powered.

Each device in the network has a device type. Examples of device type are light bulb, light switch, door, window, motion sensor, heat sensor, radiator, fridge, mobile phone, tablet computer, etc.

Each device can communicate wirelessly with other devices that are in effective range of it. The communications coverage area of device 201 is bounded by boundary 208 in FIG. 2. Device 201 is able to communicate directly with devices 202, 203, 204 and 205 which are within communications range 208 of device 201. In other words, device 201 is able to receive communications signals which are transmitted within its coverage area 208. Similarly, device 201 is able to successfully transmit communications signals to other devices which are located within its coverage area 208. No intermediary device is needed to relay signals between device 201 and any other devices located within the area 208. Devices within coverage area 208 are referred to herein as local devices of device 201's local group. Thus, devices 202, 203, 204 and 205 are local devices of device 201's local group. The communications coverage area of device 205 is bounded by boundary 209. Thus, devices 201 and 204 are local devices of device 205's local group. The communications coverage area of device 206 is bounded by boundary 210. Thus, devices 204, 205 and 207 are local devices of device 206's local group.

FIG. 3 shows the architecture of one of the devices 201, 202, 203, 204, 205, 206 and 207 for communicating in the mesh network. The device 300 comprises an antenna 301, a radio frequency (RF) front end 302 and a baseband processor 303. The baseband processor 303 comprises a microprocessor 304 and a non-volatile memory 305. The non-volatile memory 305 stores in non-transitory form program code that is executable by the microprocessor to cause the baseband processor to implement the communications protocol of the network and the methods described herein with reference to FIGS. 5 and 6. Memory 305 comprises local device identity store 306 and keystore 307.

In order to transmit signals into the mesh network the processor 303 can drive the RF front end 302, which in turn causes the antenna 301 to emit suitable RF signals. Signals received at the antenna 301 from the mesh network can be pre-processed (e.g. by analogue filtering and amplification) by the RF front end 302, which presents corresponding signals to the processor 303 for decoding. The processor can respond to those signals in various ways, as will be described in more detail below.

The device also comprises a clock 308, which can be turned on or off by the microprocessor 304 in order to save power, and optionally an external connection 309 suitable for exchanging information with the device's associated appliance if it has one. Suitably, this external connection 309 is wired. This information may include sensing external events (e.g. the operation of an associated user interface device such as a switch) or issuing control signals to associated appliances (e.g. to turn a light bulb on or off). The device also comprises a power source 310, which may be a battery. The device may also be mains-powered.

The RF front end 302 and the baseband processor 303 could be implemented on one or more integrated circuits.

The mesh network operates by communicating data packets among the devices of the network. FIG. 4 shows a suitable format for one of the packets. The packet 400 comprises a header made up of a source address 401, a destination address 402 and a sequence number 403, a payload 404, an authentication field 405 and a trailer comprising a time to live (TTL) field 406. The payload is optionally encrypted using an encryption key that is specific to a particular set of nodes in the network. When such a payload is successfully decrypted, as illustrated at 407, it comprises a plaintext payload 408 and optionally a checksum field 409.

Each device is assigned an identity which is unique within the network. Suitably, this identity specifies the device type of the device. When composing an original packet for transmission, a device inserts its identity in the source address field 401. The identity could be assigned at manufacture or when the network is being configured. The device also specifies the destination device in the destination address field 402. If the message is intended for a single device, then the identity of that single device is inserted into the destination address field 402. If the message is intended for a group of devices then the group identity of that group is inserted into the destination address field 402.

Each device keeps a count of original packets it has composed. Each time it composes a new original packet it increments the count and inserts the new count into the sequence number field 403. The length of the sequence number field can be set to be sufficient that a combination of fields 401 and 403 uniquely identify within the network any packet that would be expected to be currently circulating in the network.

Each device has a keystore 307 where it stores in non-volatile fashion one or more network keys, for example encryption and/or authentication keys. When a device composes a message for use in a certain mesh network it forms a payload 408 including the traffic data it wishes to convey and optionally generates a checksum 409 for that payload using a predefined checksum algorithm. It then concatenates the payload and the checksum and either:

    • (a) uses that concatenated string as the payload 404 for the new packet or
    • (b) encrypts the concatenated string using a predefined encryption algorithm which takes as input the concatenated plaintext payload 408 and the encryption key that corresponds to the mesh network in question and uses the output of the encryption step as the payload 404. In the latter case, the encryption key is selected to be one that is shared with a device that is intended to action the payload.

A device composing an original packet defines an original TTL for that message. The original TTL depends on the expected characteristics of the network, as will be discussed below, but could, for example, be a number such as 8.

Once the original packet is fully composed the originating device transmits it one or more times.

When one of the devices is participating in a mesh network it listens for mesh packets. It may listen continually or, to save power, intermittently. When it receives a mesh packet it attempts to authenticate the packet using one or more of the authentication keys it has stored. If the device has successfully authenticated the packet it can pass the received payload for processing. The payload might be decrypted by means of an encryption key stored by the device. The payload is processed by the device. The payload may be intended to control the internal operation of the device. For example, the payload may control the device to adapt its wireless communications operation. As another example, the payload may indicate that the device should perform some test function. Alternatively, the payload may be intended to control the operation of an appliance attached to the device (if it has one). For example, the payload may indicate that the device should issue a control signal to an appliance via external connection 309.

An important feature of the mesh network is that a device can also re-transmit a packet it has received. Each device may be configured either to retransmit all mesh packets it receives irrespective of whether it can authenticate them, or only those mesh packets it can successfully authenticate.

A device in the mesh network may be configured to not re-transmit certain mesh messages so as to suppress the possibility of mesh messages circulating indefinitely. One way to do this is for the device to be configured to store a record of messages it has already re-transmitted (e.g. by storing their source and sequence numbers) and to not re-transmit those messages if it receives them again. Another way to do this is by the device making a determination as to whether to re-transmit a received message in dependence on the message's TTL field.

When a device retransmits a packet the device transmits the packet with data content identical to the content of the packet as it received it, except that it decrements the TTL value, e.g. by one. The system can be designed so each device is configured not to retransmit any mesh packets if the decremented TTL value is zero. In that way the TTL serves to prevent messages circulating indefinitely in the mesh network. Configuring each device not to re-transmit a message whose identity matches one it has received and re-transmitted before can also help to suppress redundant message transmission. With this behaviour in mind, the original value of the TTL can be set to reflect the propagation properties of the network. A large or unreliable network may suit a larger initial TTL value than a smaller, more reliable network.

Packets can be transmitted adventitiously among the devices participating in a mesh network. A device can transmit an original packet into the network, other devices participating in the network can serve as a transport for that message to reach another device that is out of direct range of the originating device. The devices need not be fixed in location: they could be mobile. The devices could participate in the network continually or from time to time.

Each device has a store 306 of the identities of the local devices in its local group. FIG. 5 is a flowchart illustrating an exemplary method for updating the store 306.

At step 501 of FIG. 5, a trigger message is received by the devices in the network. Suitably, this trigger message is generated and sent by a device of the network. It may be sent by a device acting as a central network entity. The central network entity may, for example, be a server. The central network entity may perform one or more of the following roles in the network: sense the network by sending out requests for information to the devices in the network; collate information from reports received from the devices of the network about the local environments of those devices; determine the topology of the network from the collated information; determine changes to make to the operation of the devices in the network; instruct the devices of the network to change their operation.

Suitably, incorporated into the trigger message is an instruction to retransmit the trigger message. This may be achieved, for example, by setting the TTL field of the trigger message to be greater than 0. For example, the TTL field may be 8. Each device that receives a trigger message decrements the value of the TTL field by 1 in the trigger message that it retransmits. Any device which receives a trigger message with a TTL>1 retransmits the trigger message. If a device receives a trigger message with a TTL=0 or TTL=1 it does not retransmit the trigger message.

An example of sending the trigger message will be described with reference to FIG. 2. Consider the case in which device 207 is the central network entity. Device 207 sends a trigger message with a TTL value of 4. Device 206 receives this trigger message, decrements the TTL value to 3, and retransmits the trigger message. Device 204 receives the trigger message with a TTL value of 3. Device 204 decrements the TTL value to 2, and retransmits the trigger message. Devices 201 and 205 receive the trigger message with a TTL value of 2. These devices decrement the TTL value to 1, and retransmit the trigger message. Devices 202 and 203 receive the trigger message sent by device 201. Because the TTL value is 1, devices 202 and 203 do not retransmit the trigger message. Thus, the trigger message is distributed to all the devices in the mesh network of FIG. 2.

Suitably, the destination address of the trigger message is set to a group identity. Each device in the network interprets the group identity as addressing itself. Thus, each device in the network responds to the trigger message.

The trigger message may be sent periodically. Alternatively, the trigger message may be generated and sent in response to some stimulus in the network. For example, the central network entity may sense a bottleneck in the network, and in response send out a trigger message to determine the current topology of the network.

At step 502 of FIG. 5, the devices that received the trigger message at step 501 respond by transmitting an identifier message. The identifier message includes the identity of the device that sent it. Suitably, incorporated into the identifier message is an instruction not to retransmit the identifier message. For example, this may be achieved by setting the TTL field of the identifier message to 0. Thus, an identifier message is not retransmitted by any device in the network. Thus, only devices within direct communications range of the device which sends the identifier message receive the identifier message. In other words, only the local devices of the local group of a device receive its identifier message. In the example of FIG. 2, only devices 204 and 201 would receive an identifier message transmitted by device 205. Suitably, the identifier message includes the device type of the device that sends it. This device type may be incorporated into the identity of the device. Alternatively, the device type may be incorporated into a separate field of the message, for example the payload.

In the case that the mesh network is designed such that devices do not retransmit packets for which the decremented TTL value is zero, then all retransmitted packets received by a device have TTL≧1. A device does not receive any retransmitted packets that have TTL=0 because if another device had decremented the TTL value to zero, it would not have retransmitted the packet. Thus, a device can distinguish between packets which have been routed via one or more relays (those packets received with TTL≧1), and those which have been sent directly by a local device in that device's local group (those packets received with TTL=0).

Thus, by means of steps 501 and 502 of FIG. 5, each device receives an identifier message from each local device of its local group. The device extracts the identity and device type (which may form part of the identity) and updates identity store 306 with the identities at step 503.

In an alternative implementation, the trigger message of step 501 of FIG. 5 is generated and sent by a device of the network which is to receive the identifier messages sent in response to the trigger message. So, for example, a device sends the trigger message to local devices in its local group, and those local devices respond by sending identifier messages which are received by the device that sent the trigger message. In this case, the trigger message may have an instruction incorporated into it not to retransmit the trigger message. For example, this may be achieved by setting the TTL field to 0. Thus, only the local devices of the local group of a device receive the trigger message it sends. In this case, the destination address may be a group identity which identifies solely the devices in the local group of the device.

Suitably, both the trigger message and the identifier message are sent in a promiscuous mode. In other words, these messages are sent with low or no security. This may be achieved, for example, by sending these messages such that they can be decoded using a public network key. Alternatively, this may be achieved by sending these messages such that no network key is needed to decode them. Thus, devices which have not yet fully entered the network can successfully receive the trigger message and are able to transmit an identifier message which can be successfully received. This may be the case, for example, if a device has not yet authenticated with the network. As another example, the device may not yet have associated with the network.

At step 504 of FIG. 5, the device that has updated its identity store at step 503 reports the identities of the local devices in its local group to the central network entity. Step 504 is not necessarily carried out following every instance of step 503. A device may periodically report the identities of the local devices in its local group to the central network entity. A device may report the identities of the local devices in its local group to the central network entity every time it updates its identity store at step 503. A device may report the identities of the local devices in its local group to the central network entity only if the set of identities has changed since the device last reported the identities of the local devices in its local group to the central network entity. A device may report the identities of the local devices in its local group to the central network entity only if an identity has left the set of identities of the local group since the device last reported the identities of the local devices in its local group to the central network entity. A device may report the identities of the local devices in its local group to the central network entity only if an identity has joined the set of identities of the local group since the device last reported the identities of the local devices in its local group to the central network entity. The device may report all of the identities of the local devices in its local group to the central network entity. Alternatively, the device may only report the identities of the devices that have left or joined its local group to the central network entity. The device may report the identity and the device type of the local devices in its local group to the central network entity.

Thus, the central network entity receives from each device a list of the identities of the local devices in that device's local group. The central network entity may thus determine the topology of the mesh network by collating these identity lists along with knowledge of the identities of the devices that sent the lists. Thus, the central network identity determines the relative arrangement of the devices in the mesh network. The greater the density of the devices in the network, the more accurate that determination of the relative arrangement is.

In an alternative method for updating the store 306 of the local device identities of a device's local group, there is no step 501. In other words, there is no trigger message which is sent to trigger devices to generate the identifier messages. In this case, each device may be configured to periodically transmit identifier messages with an incorporated instruction not to retransmit.

The configuration of at least one device of the network is stored in the network other than at that device. Suitably, the configuration of each device of the network is stored in the network other than at that device. Suitably, the configuration is stored at the central network entity. Alternatively, the configuration is stored in a distributed manner across the devices of the network. At one extreme, each device of the network may store the configurations of all the other devices of the network. More suitably, the whole or partial configuration of a device in the network is stored in a subset of the devices of the network. For example, devices which are mains powered may store the whole or partial configuration of one or more other devices of the network. Devices which have surplus memory may store the whole or partial configuration of one or more other devices of the network. The configuration of a device may be stored partially at one device of the network and partially at another device of the network.

The configuration of a device which is stored in the network may be a configuration which configures the functionality of the appliance with which the device is associated. For example, in the case of a device which is associated with a light bulb, the configuration may specify, for example, the times that light bulb switches ON and OFF, that the light bulb is to switch ON if a sensor of the network detects that a person has entered the room that the light bulb is in, that the light bulb is to switch OFF if the sensor detects that the person has left the room that the light bulb is in, and so on.

Additionally, or alternatively, the configuration of the devices which is stored in the network may be a configuration which configures the wireless communications functionality of the device. For example, the configuration may include network keys, such as one or more authentication keys and encryption keys, which enable the device to communicate with the network using the mesh protocol.

Additionally, or alternatively, the configuration of a device which is stored in the network may be a configuration which configures the functionality of a device acting as a relay node. For example, the configuration may define the types of messages that the device retransmits.

FIG. 6 illustrates a method of determining that a device of the network has been replaced by another device and configuring that other device in the same manner as the replaced device.

At step 601, the updated identity list of local devices in the local group of a device is received by the processor which is to perform steps 602, 603 and 604 of the method of FIG. 6. The processor accesses the currently stored identity list of local devices in the local group. The processor compares the two lists.

At step 602, the processor assesses if an identity on the stored list is not on the updated list. If this is the case, then this is indicative of a local device having left the local group. If all the identities on the stored list are also on the updated list, then the method returns to step 601. If an identity on the stored list is missing from the updated list, then the method proceeds to step 603.

At step 603, the processor assesses if an identity on the updated list is not on the stored list. If this is the case, then this is indicative of a new device having entered the local group. If all the identities on the updated list are also on the stored list, then the method returns to step 601. If an identity on the updated list is missing from the stored list, then the method proceeds to step 604.

At step 604, the processor compares the device type of the local device whose identity is on the stored list but missing from the updated list with the device type of the new local device whose identity is on the updated list but missing from the stored list. If the device types are different, then the method returns to step 601. If the device types are the same, then it is determined that the new local device is a replacement device for the device that has left the local group. Thus, if the device types are the same, the method proceeds to step 605. At step 605 the configuration of the device that has left the local group is extracted from the configuration store and transmitted to the replacement device, where that configuration is applied to the replacement device.

The configuration applied to the replacement device at step 605 may be a configuration which configures the functionality of the appliance with which the device is associated. This type of configuration is described above. If the configuration applied at step 605 only configures the appliance, then the replacement device separately associates with the wireless network as normal using the mesh association protocol. For example, the replacement device may associate with the mesh network by exchanging its unique identity with a configuring device of the network such as the central network entity. This process is user initiated, for example by the user scanning a QR code on the replacement device. In response to exchanging its unique identity with the network, the configuring device of the network sends the network key(s) to the replacement device, thereby enabling it to communicate with the network fully according to the network communications protocol.

The configuration applied to the replacement device at step 605 may be a configuration which configures the wireless communications functionality of the device. This type of configuration is described above. If the configuration applied at step 605 only configures the wireless communications operations of the device, then the appliance functionality of the replacement device is separately configured by the user. For example, the user may configure the appliance functionality through a user interface on the appliance.

The configuration applied to the replacement device at step 605 may both configure the functionality of the associated appliance and configure the wireless communications functionality of the device.

Suitably, the configuration that is applied to the replacement device automatically by the network on determining that the device is a replacement for an old device that has left the network depends on the device type. For example, if the device type is one deemed to be a low security risk, for example a light fitting, then the configuration that is applied to it automatically may be chosen to configure the operation of the appliance and the wireless communications operation of the device. If the device type is one deemed to be a medium security risk, for example a proximity sensor, then the configuration applied to it automatically may be chosen to configure the operation of the appliance but not the wireless communications operation of the device, such that the device still associates with the network in order to fully integrate with the network. If the device type is one deemed to be a high security risk, for example a door alarm, then it may be deemed that no configuration is to be automatically applied by the network and it is to be manually configured instead. Suitably, the security settings of the devices in the network, and the configurations to be automatically applied by the network on determining that a device has been replaced, are user-configurable. Standard security settings of devices in the network may be set during manufacture.

The method steps of FIG. 6 may be carried out solely at the central network entity. This may be the case if (i) the central network entity holds a central store of the configuration of the devices in the network, and (ii) the central network entity receives an updated list of the identities of the local devices in a device's local group. Alternatively, the method steps of FIG. 6 may be carried out solely at the device which receives the identifier messages from the local devices in its local group. This may be the case if the device stores the configurations of the local devices in its local group. Alternatively, the method steps of FIG. 6 may be carried out partially at the device which receives the identifier messages and partially at the central network entity. For example, the device which receives the identifier messages may determine that a device has been replaced by carrying out steps 601, 602, 603 and 604, but the central network entity extracts the configuration and applies it to the replacement device by carrying out step 605. Alternatively the steps of FIG. 6 may be carried out partially at the device which receives the identifier messages and partially in a distributed manner across the network. For example, the device which receives the identifier messages may determine that a device has been replaced by carrying out steps 601, 602, 603 and 604, but the configuration is extracted from one or more other devices across the network and applied to the replacement device by carrying out step 605. Alternatively, the method steps of FIG. 6 may be carried out partially at the central network entity and partially in a distributed manner across the network. For example, the central network entity may determine that a device has been replaced by carrying out steps 601, 602, 603 and 604, but the configuration is extracted from one or more other devices across the network and applied to the replacement device by carrying out step 605.

In the example of FIG. 6, the configuration of an old device that has left the local group is applied to a replacement device that has entered the local group with the same device type as the old device that left, if both the old device left the local group and the replacement device entered the local group since the last time the identity list was updated.

In a further example, the configuration of an old device that has left the local group is applied to a replacement device that has entered the local group with the same device type as the old device that left, even if the old device had already left the local group the last time the identity list was updated. In this example, the step 602 in FIG. 6 is not performed. A store of the identities of devices that have recently left the local group is maintained, along with their device types. If the new identity that is in the updated identity list but not the stored identity list has the same device type as any of the devices that are in the store of recently departed device identities, then the new identity is determined to belong to a replacement device for the recently departed device having the same device type. Suitably, there is a maximum elapsed time between a device leaving a local group and another device entering the local group in which the device that has entered it can be deemed to be a replacement for the device that has left. This maximum elapsed time could be applied, for example, by storing the identities of departed devices for a set period of time. After this period of time, the identities of the departed devices are discarded.

The determination that a new device that has entered a local group is a replacement for an old device that has recently departed the local group in accordance with FIG. 6 and the further examples described above, may be taken based on the identifier messages received by a single device whose local group included the device that has departed and includes the new device. Alternatively, this determination may be made based on the identifier messages received at more than one device. In accordance with step 504 of FIG. 5, the central network entity receives reports from the devices in the network. Each report may list the identities of the local devices in the local group of the device that sent the report. Thus, the central network entity knows which devices are in the local group of each device. By collating the local group identities of each device in the network, the central network entity is able to determine the topology of the whole network. The central network entity may determine the local group of the departed device which has been reported as having left the local group of another device. The central network entity may determine this based on a report received from the departed device prior to its departure which lists the identities of the local devices in its local group. Alternatively, the central network entity may determine the local group of the departed device to include all the devices which have reported that the departed device is within their local group.

The central network entity may determine that the new device is a replacement for the departed device if more than one device in the departed device's local group receives identifier messages which indicate that the departed device has been replaced by the new device having the same device type as the departed device.

The central network entity may determine that the new device is a replacement for the departed device if a threshold number or a threshold proportion of the devices in the departed device's local group receive identifier messages which indicate that the departed device has been replaced by the new device having the same device type as the departed device.

The central network entity may determine that the new device is a replacement for the departed device if all of the devices in the departed device's local group receive identifier messages which indicate that the departed device has been replaced by the new device having the same device type as the departed device.

By utilising the methods described herein, when devices in a mesh network are replaced with other devices, the mesh network can respond by configuring the replaced devices with the same configurations as the devices that they are replacing without the need for the network user to manually perform the configuration.

The operations described above for the baseband processor could be carried out by other devices. For example, there could be a dedicated processor for implementing the protocol described above, or some of the operations could be carried out by the baseband processor and some by another processing entity.

The mesh network may employ a wired communications protocol.

The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

1. A method of configuring a network, the network comprising a plurality of devices capable of operating according to a wireless communications protocol, each device having a device type, each device communicating directly with one or more local devices of a local group, the local devices being those devices of the network with which the device is in direct communications range, the method comprising:

storing a device configuration for each device;
at a device: detecting that a first local device having a first device type has left the local group, and detecting that a further device having the first device type has entered the local group;
determining that the further device is a replacement for the first local device; and
applying the stored configuration for the first local device to the further device.

2. The method as claimed in claim 1, wherein the further device is associated with an appliance supplementary to its wireless communications function, and wherein applying the stored configuration to the further device configures functionality of the appliance.

3. The method as claimed in claim 1, wherein applying the stored configuration to the further device configures the further device to communicate over the network according to the wireless communications protocol.

4. The method as claimed in claim 1, further comprising, at each device:

storing identities of the local devices of the local group of that device in a store;
from each local device, receiving an identifier message comprising an identity of the local device and an instruction not to retransmit the identifier message; and
updating the store with the identities of the local devices of the local group.

5. The method as claimed in claim 4, wherein the identifier message comprising the identity of the local device specifies the device type of the local device.

6. The method as claimed in claim 4, wherein each local device transmits an identifier message in response to receiving a trigger message from the device.

7. The method as claimed in claim 4, wherein each local device transmits an identifier message in response to receiving a trigger message from a central network entity.

8. The method as claimed in claim 6, wherein the trigger message and the identifier message are both transmitted in a low or no security mode such that a device which is not yet associated with the network can successfully receive the trigger message and transmit the identifier message.

9. The method as claimed in claim 4, wherein each device periodically reports the identities of the local devices in the local group of that device to a central network entity.

10. The method as claimed in claim 4, wherein each device reports the identities of the local devices in the local group of that device to a central network entity only if the identities of the local devices in the local group have changed since the device last reported the identities of the local devices in the local group to the central network entity.

11. The method as claimed in claim 9, comprising, at the central network entity, determining that the further device is a replacement for the first local device if more than one device reports to the central network entity that:

the identities of the local devices no longer include the first local device's identity;
the identities of the local devices include the further device's identity; and
the first local device and the further device have the same device type.

12. The method as claimed in claim 9, comprising, at the central network entity, determining that the further device is a replacement for the first local device if each of the devices which were local devices of the first local device reports to the central network entity that:

the identities of the local devices no longer include the first local device's identity;
the identities of the local devices include the further device's identity; and
the first local device and the further device have the same device type.

13. The method as claimed in claim 1, comprising storing the device configurations of each device at a central network entity.

14. The method as claimed in claim 1, comprising storing the device configurations of each device in a distributed manner across the devices of the network.

15. The method as claimed in claim 1, wherein the network is a mesh network.

16. The method as claimed in claim 1, wherein the devices operate according to the Bluetooth Low Energy protocol.

17. A network comprising:

a plurality of devices capable of operating according to a wireless communications protocol, each device having a device type, each device communicating directly with one or more local devices of a local group, the local devices being those devices of the network with which the device is in direct communications range;
wherein each device is configured to: detect that a first local device having a first device type has left the local group, and detect that a further device having the first device type has entered the local group;
wherein the network is configured to: store a device configuration for each device, determine that the further device is a replacement for the first local device, and apply the stored configuration for the first local device to the further device.

18. The network as claimed in claim 17, wherein the further device is associated with an appliance supplementary to its wireless communications function, and wherein the further device is configured to apply the stored configuration to the appliance.

19. The network as claimed in claim 17, wherein each device comprises a store for storing the identities of the local devices of the local group of that device, and wherein each device is configured to update the identities stored in the store on receiving identifier messages from the local devices, each identifier message including an identity of the local device that sent the identifier message.

20. A method of determining the topology of a network, the network comprising a central network entity and a plurality of devices capable of operating according to a wireless communications protocol, each device communicating directly with one or more local devices of a local group, the local devices being those devices of the network with which the device is in direct communications range, the method comprising:

at each device, from each local device, receiving an identifier message comprising an identity of the local device and an instruction not to retransmit the identifier message;
at each device, reporting the identities of the local devices in the local group of that device to the central network entity; and
at the central network entity, determining the topology of the network by collating the identities of the local devices in the local groups of each device.
Patent History
Publication number: 20150244565
Type: Application
Filed: Oct 2, 2014
Publication Date: Aug 27, 2015
Applicant: Cambridge Silicon Radio Limited (Cambridge)
Inventors: Robin Heydon (Cottenham), Nicolas Guy Albert Graube (Barrington), Nicholas John Jones (Cambridge)
Application Number: 14/505,465
Classifications
International Classification: H04L 12/24 (20060101); H04W 76/02 (20060101);