Patent Application
20150244648
This invention relates to a communication device that is capable of relaying packets in a mesh network.
Many mesh networks send data using complex routing tables. The routing tables store routes from one network device to another so that messages can be propagated from source to destination via a series of hops. The topology of the network has to be known in order that routes between the various devices can be determined and stored. An alternative is flood routing. In this method messages do not travel from one device to another via a predefined route. Instead messages are broadcast and any device in range that receives a message retransmits it. A message thus propagates its way through the network, potentially reaching its destination via a number of different routes. Flood routing is very simple to implement and although it may appear inefficient has a number of advantages, particularly for ad hoc networks that may change their topology on a random basis.
Flood routing implies that all devices should listen continuously for signals from other devices in the network, otherwise there is a risk that data might not reach its destination. Continuous listening increases power consumption, in current mesh networks this is often unimportant because most mesh devices have access to a mains power source, which eliminates the requirement for power saving. It does, however, limit the range of devices that can form part of the network. There is a need to open up mesh networks to a wider range of devices, including those with severe power restrictions.
According to one embodiment, there is provided a communication device capable of communicating over a communication network that is configured such transport of packets through the network is provided by each communication device in the network listening for and relaying packets, the communication device comprising a relay unit configured to listen for packets and relay them over the network, a detection unit configured to identify other communication devices in the network that are also capable of acting as relay devices and a power controller configured to adjust the power that the communication device uses to listen for packets in dependence on the other devices identified by the detection unit.
The power controller may be configured adjust the power in dependence on the number of other devices identified by the detection unit.
The power controller may be configured adjust the power in dependence on receive parameters associated with the other devices identified by the detection unit.
The receive parameters may include one or more of a listening schedule, a power status and a receive range.
The power controller may be configured adjust the power in dependence on a mode of operation of a consumer device associated with the communication device.
The power controller may be configured adjust the power in dependence on whether its associated consumer device is active or non-active with respect to the network.
The power controller may be configured adjust the power in dependence on information received from the network about the current transport capabilities of the network.
The power controller may be configured to adjust the power in dependence on a power status associated with the communication device.
The power controller may be configured to control the rate at which it adjusts the power in dependence on a power status associated with the communication device.
The detection unit may be configured to identify the other devices using packets that have previously been relayed to it over the network.
The detection unit may be configured to identify the other devices using packets that it has been relayed multiple times.
The detection unit may be configured to identify the other devices using a lifetime value incorporated in packets that have previously been relayed to it over the network.
The power controller may be configured to adjust the power by controlling the amount of time that the relay unit listens for packets.
The power controller may be configured to control a period of time for which the relay unit listens continuously for packets.
The power controller may be configured to control a time interval between periods of time for which the relay unit listens continuously for packets.
The power controller may be configured to control the relay unit such that, the higher the number of devices identified by the detection unit, the less time that the relay unit listens for packets.
The power controller may be configured to adjust the power by controlling a receive range of the communication device.
The power controller may be configured to adjust the power by controlling the usage of receive circuitry in the communication device.
The relay unit may be configured to listen to packets asynchronously from other devices in the network.
According to a second embodiment, there is provided a method of communicating over a communication network that is configured such transport of packets through the network is provided by each communication device in the network listening for and relaying packets, the method comprising a communication device identifying other communication devices in the network that are also capable of acting as relay devices and adjusting the power that the communication device uses to listen for packets in dependence on the other devices identified by the detection unit.
The present invention will now be described by way of example with reference to the accompanying drawings. In the drawings:
a and 4b illustrate the transport of a packet through the distributed lighting system;
a and 7b illustrate an example of a communication device listening for packets for the maximum time available; and
In a wireless network data is transmitted via radio signals. In a wired implementation, data may be transmitted via electrical signals. Most commonly data will be arranged in “packets” incorporating payload data and some indication of the source device and the destination device. Packets take many different formats and the apparatus, network and method described herein are not limited to using a particular type of packet. The term “packet” is therefore used herein to denote any signal, data or message transmitted over the network.
There are three main reasons why it may be impractical for a communication device to spend significant amount of time listening for packets. The first is the cost in power. The second is the physical impossibility for many devices of receiving at the same time as transmitting. The third is the need to perform other functions outside of the network, which may not be possible while listening for packets. The challenge in a mesh network is to reconcile these drawbacks with each node's responsibility to relay data for the network.
For many nodes in a mesh network it is simply impossible to listen for packets all the time. This is because the communication devices that implement those nodes are incapable of listening at the same time as they transmit. So, packets that arrive while the device is transmitting are inevitably lost. Thus it is more realistic to aim at maximising the number of packets received by a device than to aim at having every device receive all packets.
This leads to two further insights. First, it is often the case that a device acting as a relay in a mesh network does not actually need to receive all packets because its role is only to relay those packets, not to alter its behaviour in dependence on the data that those packets contain. Consequently, not only is it technically impossible for a single device to listen continuously, it is also (at least from the perspective of that particular device) often unnecessary. Second, from the perspective of the network it does not matter which particular device relays each packet; it only matters that the packet is relayed. Thus it may be possible to have one relay device reduce its receive power, for example by reducing its range or deliberately not listening for packets at all, on the basis that any gaps in its listening will be covered by other devices in the vicinity. It becomes possible to trade listening power against the number of relay devices. For example, one device listening for N seconds can be traded against two or more devices listening for K seconds, with K<N.
A general example of a communication device is shown in
Typically the higher the number of relay devices detected within radio range of the communication device, the less power it will use on average listening for packets. This may be achieved by reducing the length of the windows for which the communication device listens and/or by increasing the interval between windows. The communication device might alter the duty cycle of its receive operations in dependence on the number of other devices it detects within radio range. The communication device might reduce the power consumed by a listening operation, e.g. by reducing its reception range. Conversely if the communication device detects a decrease in the number of other relay devices within range in the network, it suitably increases the amount of power it spends listening to packets to compensate. The overall effect is that a communication device with a local mesh density that is relatively high, e.g. because it is in the middle of a network with many other devices within range, will tend to use less receive power than a communication device with a local mesh density that is relatively low, e.g. because it is on the edge of a network with few other devices within range.
Time that a communication device saves by not listening for packets may be spent performing other functions or in a low power mode to conserve battery life. Any gaps between the device's listening windows are suitably filled by the other devices within radio range so that the performance of the network as a whole does not suffer. In fact, the performance of the network may improve as a consequence of fewer devices relaying the same packet. Communication devices within range of each other may coordinate their listening periods so at least one of them is listening at all times. An alternative is for the devices to be asynchronous so that largely continuous listening is achieved naturally due to random offsets between the device's own listening periods.
One advantage of this approach is that it enables battery-powered relay devices become possible, whereas previously only mains-powered relay devices could realistically be considered. This is a significant step in permitting flexible mesh deployment and ad-hoc arrangements. It also enables any device configured to operate in accordance with the mesh protocol to form part of the mesh whilst still allowing other “primary” (i.e. non-mesh) functions to be performed.
The structures shown in
An example of a network is shown in
The house contains other items of equipment that contain other wireless communication devices. For example, there is a tablet computer 310 which contains a wireless communication device 313, and a mobile phone 315 which contains a wireless communication device 316. There is also a sensor 320 for detecting the open/closed state of window 318, which contains communication device 319. Computer 310, phone 315 and sensor 320 are powered by batteries 314, 317 and 321 respectively.
Wireless communication devices 306 to 309, 312, 313, 316 and 319 operate according to the same wireless communication protocol. That could be a relatively short-range protocol. For example the effective range of each device could be less than 35 m. That characteristic can permit the devices to use less power for transmitting and/or receiving than would be expected in a longer range protocol. The protocol could be one that imposes no common time-base at or below the transport level, or below the application or presentation levels. In other words, the devices in the network operate asynchronously of each other. That characteristic can reduce the devices' power consumption by reducing their for need accurate clocks running continuously. In one example, the devices could operate according to the Bluetooth protocol, specifically the Bluetooth Low Energy (BLE) protocol. The devices could use other protocols, for instance IEEE 803.11.
Devices 306 to 309 are configured cooperatively in order that the light fittings 302 to 305 know to respond to signals from the light switch 301. This may be done by the devices 306 to 309 storing a common identification code in their respective non-volatile memories. The identification code may be stored in the light switch when it is manufactured, and stored in the light fittings at the time they are installed in the house. They may be stored in the light fittings by means of another device such as mobile phone 315 communicating with the wireless device of the light switch to read its identification code, and then communicating with the wireless devices of the light fittings to cause them to store that same identification code. This code may be a network key, and it may be used to sign all packets sent over the network.
The network is preferably also configured to implement flood routing, which is well suited to ad hoc networks. The phone 315 and the tablet computer 310 are both portable devices that change location within the network as a user picks them up and moves them. They may also occasionally leave the network and then reappear some time later. For example, when a user takes them out of range of the network by taking them out of the house and later returns them to the house. The network's topology is thus subject to random alteration.
In order to avoid packets being bounced around the network indefinitely, each packet suitably includes a lifetime field that defines the lifetime of the packet within the network. A communication device that receives the packet suitably checks whether the lifetime field is equal to a threshold value before retransmitting the packet. If the lifetime value is equal to the threshold, the communication device does not retransmit the packet. Otherwise the communication device does retransmit the packet. In one example the lifetime field is a Time-To-Live (TTL) field. This is a value in the packet that is suitably decremented each time that the packet is retransmitted. In one example the TTL value is decremented by one at each retransmission, with each communication device that receives the packets retransmitting it until the TTL value is decremented to zero. In another example the lifetime field is a Max Hop Count (MHC) field. In this example each communication device stores a threshold MHC value, which is a positive, non-zero number. The MHC value in each packet may be incremented by one each time that the packet is retransmitted, with each communication device that receives the packets retransmitting it until the MHC value reaches the device's stored MHC threshold.
The communication devices in
A connection between the communication device and its associated consumer may be wired or wireless. The communication device may be contained within the same housing as the consumer. In many implementations the communication device might be fully integrated with the consumer; they might even share circuitry. Often the communication device will be implemented by a chip within the consumer. An example of this is communication device 316 within phone 315. In other implementations the communication device and the consumer may be separate devices that are connected together. For example, the communication device might be a BLE tag connected to a PC.
For the purposes of this document, the communication device is considered to be the combination of hardware and/or software that implements the protocol governing the network, thereby implementing the packet transport that enables the consumer to communicate over the network.
Each communication device may be capable of acting as a relay in the network. An example of this is shown in
Although the arrangement shown in
In
Another example of a communication device is shown in
The device also comprises a clock 510, which can be turned on or off by the microprocessor 504 in order to save power, and an external wired connection 512 for exchanging information with the device's associated consumer. This information may include the 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. light fittings). The device also comprises a power source 511, which may be a battery. The device may also be mains-powered.
The RF front end 502 and the baseband processor could be implemented on one or more integrated circuits.
A communication device may take a wide range of different factors into account when deciding whether (and how) to adjust its listening operations to conserve power. Examples of the steps this might involve are shown in
In step 601 the communication device may determine the number of communication devices within range that are capable of acting as relays. This may be termed the “local mesh density”. There are a number of ways the communication device might do this. Some examples are described below.
The communication device suitably stores a record of packets it has received previously. The communication device may be configured to derive information about its local mesh density based on this record. For example, if the communication device has received the same packet multiple times, this may indicate that there are multiple devices acting as relays within range. Similarly, if those multiple copies of the same packet have similar values in their lifetime fields, this may tend to indicate that there are multiple relay-capable devices close to the communication device. If the communication device receives the same packet with very different lifetime value fields, this may be less indicative of a local mesh density but may indicate a good level of relay capability in the network as a whole.
The communication device may send probe packets to see how many copies of that packet it receives back from the network. Preferably the communication take steps to prevent probe packets from wasting resources by bouncing around the network. Preferably the probe packets are retransmitted only once. This may be achieved by the communication device setting the lifetime value of the probe packet to an appropriate value, e.g. by setting the TTL value to one. This has the further advantage of providing the communication device with local information about device density, since any copy of the probe packet it receives back must necessarily have been relayed by a device within radio range. In one example the communication device may incorporate a flag or similar in the probe packet that causes any device that receives it not only to retransmit the packet but also to include its own receive parameters, such as receive capabilities, receive range, power status, listening schedule etc. in the retransmitted packet.
In another example the communication device may be configured to operate over the network in accordance with a protocol that includes protocol, transport and bearer layers. Probe packets may be injected directly into the bearer layer, thus bypassing the protocol and transport layer. The protocol may define a host stack and a host controller stack. Bluetooth is an example of such an arrangement. BLE in particular places a significant amount of intelligence in the host controller so that the host only needs to be woken up when it needs to perform some action (the host is assumed to consume more energy than the host controller). In fact, in some implementations a communication device may not have a separate host at all, with the host controller (which is mostly implemented in software) performing all tasks that are usually associated with the host. It may be the host controller that injects the probe packet into the bearer layer In one example probe packets may be normal broadcast packets, e.g. broadcast packets according to the protocol that underlies the network (such as BLE). These normal broadcast packets may be different from the mesh packets that are normally transmitted over the network (for a start, they may not be signed by the network key), but they will still be monitored by all devices in the network. This also renders it possible for a device outside the mesh network to inject probe packets into the network. For example, a probing node, whose only purpose is to periodically broadcast data, might be outside of the mesh network itself but still inject probe packets into the mesh network.
The communication device may also be configured to more directly obtain information about neighbouring devices that are acting as relays. For example, the device may send packets requesting that any device that receives it responds with details about its own receive capabilities. This may include information such as power status, listening schedule, receive and/or transmit range, active status etc. These packets may be broadcast with a lifetime value that prevents them from being retransmitted. For example, the packets could be transmitted with a TTL value of zero.
The communication device may also be configured, together with other devices in the network, to implement a more general feedback program in which they exchange information about receive strategies/capabilities so that the devices can coordinate their listening operations. Request and probe packets may form part of such a feedback program.
Having determined the local mesh density, the communication device may be in a position to adjust its receive power accordingly. There are other factors that the communication device may also take into account, examples of which are represented by optional steps 602 to 605.
In step 602 the communication device determines whether it or its associated consumer are “active” or “non-active” with respect to the network. In some embodiments this step may be performed before the communication device detects other devices in the network, since some devices may be configured not to reduce their receive power at all unless their associated consumer is non-active.
In general a device may considered to be “active” if it is waiting to receive a packet from the network that will cause it to adapt its behaviour. This “waiting” does not require the device to be positively anticipating a packet; it just refers to a state in which the consumer is configured to listen for a packet that might cause it to perform some operation (no matter how insignificant that operation might be). The communication device may include a mode unit configured to determine whether its associated consumer is “active” or “non-active”. It may make this determination based on information received from the consumer, e.g. a code or setting received at switch-on identifying the type of device that the consumer is and/or a status update each time that the consumer changes from active to non-active and vice versa.
The term “mesh device” may be used to refer to a communication device together with its associated consumer. A mesh device may fall into one of two categories:
An MAD is typically constrained in its scheduling as it is important for the effective realisation of its function that it receives all commands addressed to it. This implies that an MAD has to spend significant amount of time listening for potential commands. It is generally not advisable to attempt to reduce this listening time. Practically, this is a moot point as the MAD will usually be associated with some actuator, which implies access to an inexhaustible or rechargeable power source and thus removes the requirement for power saving.
An MPT is essentially stateless nature with respect to the transmitted packets. It does not affect the behaviour of an individual MPT if it has not observed a particular packet. This makes it possible for an MPT to have shorter and/or less frequent listening “windows” if there are sufficient other MPTs in the system to compensate.
A mesh device might be an MPT if its consumer component falls into any one of the following categories:
A communication device preferably listens for the maximum time available if it falls into the MAD category. Otherwise it risks missing packets that it actually needs to receive. A communication device may, however, safely reduce its listening time if it falls into the MPT category.
In step 603 the communication device may check whether it has received any take information or commands from the network that it should take into account when determining its receive power. For example, it can be envisaged that in some situations there might be an insufficient density of devices for all non-active devices to substantially reduce their listening time. Therefore, if one device (e.g. a controller) determines that packets are taking too long to reach their destination or are being regularly dropped, it may send out an instruction for all devices to increase their listening time accordingly. The device that sent the instruction might have determined that the network transport is not performing well enough based on the number of acknowledgments that it is receiving to its own packets and/or the length of time that those acknowledgements are taking to reach it.
The communication device may consider its own power status when deciding how to control its receive power (step 604). This factor may be particularly relevant when it comes to deciding whether or not to accede to a request from the network. For example, whether it has access to mains power or not and, it is battery powered, the amount of power the battery has left. If the device is battery powered with little power remaining, it may decide to continue minimising its receive power as much as possible notwithstanding the instruction from the network.
The communication device might also take into account any information it has about neighbouring devices that are capable of acting as relays (step 605). In particular it may compare any information it may have about a neighbouring device's power supply with its own power situation. For example, if the communication device knows from a previous exchange of status information with its neighbouring devices that one or more of them is mains powered, while the device itself is battery powered, it may determine that the neighbouring mains powered device is far better placed to carry the burden of listening for packets and maintain its own power-saving approach accordingly. The communication device may also consider any information it has about the receive arrangements of neighbouring devices, and particularly their listening schedules.
Finally, in step 606, the communication device may control its receive power. There are a number of different options available to a communication device for controlling its receive power, including the following examples:
If a communication device decides that it should adjust its receive power, it may make any adjustments slowly, particularly if it is reducing its receive power, to allow other devices in the network time to adjust their own receive power to compensate. The communication device may control the speed at which the communication device ramps its receive power up or down in dependence on a variety of different factors, including a power level of the communication device, one or more receive parameters of its neighbouring devices, the time of day (some devices may have a schedule in which they do not listen at certain times of day), etc.
The principles described herein enable a network to transfer packets via a stochastic transport mechanism. This technique is well suited to ad hoc networks. The network is able to achieve reliable transport between two arbitrary devices via intermediary devices, which are not expected to handle communications reliably, because there is a sufficient density of devices in the network to compensate for devices that have reduced their receive power. Relaxing the constraint on the reliability of an individual device permits better power management, opening up the network to a wider range of devices. The mechanism is self-administering, in that each device makes its own decisions about how to adjust its receive power, but is still able to achieve network-wide reliability.
An example of how devices can compensate for one another is illustrated in
An example of a device listening as much as it can is illustrated in
An alternative implementation is shown in
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.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1403312.0 | Feb 2014 | GB | national |
| 1403314.6 | Feb 2014 | GB | national |
| 1405791.3 | Mar 2014 | GB | national |
