COMMUNICATING DATA OVER A MESH NETWORK

Abstract

A communication device capable of operating in a mesh network and configured to transmit data to a destination device by encapsulating that data in a broadcast packet and transmitting it over the mesh network in order that another communication device, on receiving the broadcast packet, may forward it towards the destination device, the communication device being further configured to: establish a schedule for transmitting data encapsulated in broadcast packets; transmit information defining that schedule over the mesh network; and subsequently transmit the broadcast packets in accordance with that schedule.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This non-provisional patent application claims priority to Great Britain applications: GB 1412716.1, 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 an apparatus and method for communicating data over a mesh network.

BACKGROUND

FIG. 1 shows a distributed network. The network comprises a number of communication devices 101, 103, 105 and 107. Each device can communicate wirelessly with the other devices that are in effective range of it. In this example the network is a mesh network and each device relays data for the network. The devices can communicate to propagate data between them. For example, if device 101 transmits a signal, that signal can be received by devices 103 and 107 which are within range of device 101. Device 103 can then relay the signal received from device 101 so that it can be received by device 105, which is out of range of device 101. The coverage area of device 101 is illustrated at 108 and the coverage area of device 105 is illustrated at 109. This method of communication allows devices to communicate even though they are out of direct range or not synchronised with each other. Each device may also be connected to, or integrated within, an associated consumer device. So device 101 is connected to a sensor that detects whether window 102 is open or closed, and devices 103 and 105 are connected to light fittings 104 and 106 respectively.

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.

SUMMARY OF THE INVENTION

According to a first embodiment, there is provided a communication device capable of operating in a mesh network and configured to transmit data to a destination device by encapsulating that data in a broadcast packet and transmitting it over the mesh network in order that another communication device, on receiving the broadcast packet, may forward it towards the destination device, the communication device being further configured to: establish a schedule for transmitting data encapsulated in broadcast packets; transmit information defining that schedule over the mesh network; and subsequently transmit the broadcast packets in accordance with that schedule.

The communication device may be configured to encapsulate non-audio data in the broadcast packets.

The communication device may be configured to encapsulate control data in the broadcast packets.

The communication device may be configured to transmit the broadcast packets over a channel that implements frequency hopping.

The communication device may be configured to transmit the broadcast packets by transmitting each broadcast packet on a different frequency from the preceding broadcast packet.

The communication device may be configured to transmit the information defining the schedule over a different channel from the broadcast packets.

The communication device may be configured to transmit information that defines the timing and frequency of the schedule.

The communication device may be configured to broadcast the information defining the schedule over the mesh network.

The communication device may be configured to transmit the information defining the schedule over a connection with another communication device.

The communication device may be configured to terminate the connection with the other communication device once it has transmitted the information defining the schedule.

The communication device may be configured to establish a schedule under which the communication device transmits broadcast packets that encapsulate the same data for the same destination device at different time instants.

The communication device may be configured to transmit the broadcast packets over a Bluetooth Low Energy isochronous channel.

The communication device may be configured to encapsulate data for transmission over the mesh network in a Bluetooth Low Energy advertising packet.

According to a second embodiment, there is provided a communication device capable of operating in a mesh network and having a scan mode in which it listens for broadcast packets on the mesh network, said broadcast packets encapsulating data that is intended for a destination device, and forwards any such broadcast packet towards the respective destination device, the communication device being configured to: obtain information that defines a schedule according to which another communication device may transmit broadcast packets over the mesh network; and enter scan mode and listen for broadcast packets at times defined by the schedule.

The communication device may be configured to not enter scan mode at times that are not defined by the schedule.

The communication device may be configured to obtain information defining the schedule by listening for a broadcast packet that defines that schedule.

The communication device may be configured to obtain information defining the schedule by connecting with the other communication device.

The communication device may be configured to disconnect from the other communication device once the information defining the schedule has been received.

The communication device may be configured to enter scan mode and listen for broadcast packets when it is not connected to the other communication device.

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG. 1 shows an example of a distributed network;

FIGS. 2a to 2c show examples of communication devices and a method of operating the same;

FIGS. 3a and 3b show an example of a mesh network;

FIG. 4 shows an example of a communication channel; and

FIG. 5 shows an example of a communication device.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art.

The general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

FIG. 2a shows an example of a communication device. The communication device is generally configured for transmitting data over a mesh network. In most examples the communication device may be configured for wireless communication, although wired configurations are also possible. This is represented generally by output 201. In a wireless network data is transmitted via radio signals. In a wired implementation, data may be transmitted via electrical signals. Most commonly data may be arranged in “packets” incorporating payload data and some indication of the source device and the destination devices.

The communication device may be configured to operate in accordance with a communication protocol that governs communications across the mesh network. Suitably the communication protocol defines a broadcast packet type. A broadcast packet is one that is not addressed to any one particular device, and thus can be received by any device in the network that is within range.

The communication device comprises a transmit unit 202, which is configured to transmit data over the mesh network in accordance with the protocol. The transmit unit comprises a broadcast unit 203, which is configured to encapsulate data in broadcast packets. Suitably that data is control data. The data is usually intended for a particular subset of one or more devices in the mesh network. Although the broadcast unit identifies these destination devices in the broadcast packet, it may not establish a connection with those devices. Indeed, in many instances the communication device will be out of range of one or more of the destination devices. Instead, the transmission unit broadcasts the packet in the hope that another device in the mesh network, acting as a relay, will receive the packet and forward it on to its destination. The communication device is thus configured to operate in a mesh network that utilises flood routing to transport data between source and destination devices.

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. There are three main reasons why it may be impractical for a mesh 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. 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.

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 often 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 generally 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 deliberately not listen for packets at all, on the basis that any gaps in its listening will be covered by other devices in the vicinity.

If the relay devices decide unilaterally when to listen for packets, there is a risk that none of them will be listening when a particular packet is broadcast, and the packet may be dropped. Having some form of direct coordination between neighbouring relay devices might help to avoid listening gaps but could add undesirable complexity, particularly in an ad hoc mesh in which a relay device's neighbours may change with time. An indirect form of coordination may therefore be beneficial.

The communication device that is transmitting the broadcast packets may establish a transmission schedule. The relay devices may choose to listen to those packets or not (retaining their unilateral behavior), but having a mesh device transmit its broadcast messages at set times enables a relay device to tailor its listening windows to those times when there might actually be a broadcast packet for it to relay. Thus relays may reduce their power consumption without missing packets. The relays might reduce their power consumption still further by listening to only a subset of the transmission slots. This introduces a risk that a packet might be dropped. But by limiting the potential transmit time down to a number of discrete time slots it also becomes feasible that multiple relays, independently selecting which slots to listen to, might, as a group, end up listening to all slots. The likelihood that all slots will be listened to can be improved still further by the transmitting device communicating information about different subsets of its transmission slots to different relay devices. This is described in more detail below.

The communication device comprises a scheduler 204 for establishing a schedule for the transmission unit to transmit data encapsulated in broadcast packets over the mesh network. Transmit unit 202 may be configured to transmit information defining the schedule over the mesh network. Subsequently the transmit unit may establish a channel that embodies the schedule and transmit the broadcast packets over that channel.

FIG. 2b shows another example of a communication device. In this example the communication device is generally configured for receiving data over the mesh network. The communication device may be configured to act as a relay. In many implementations the communication devices represented by FIGS. 2a and 2b may be implemented together as part of one device that is capable of transmitting and receiving data over the mesh network.

As before, the communication device shown in FIG. 2b will usually be configured for wireless communication, although wired configurations are also possible. This is represented generally by output 205. The communication device may be configured to operate in a number of different modes, including a scan mode. The communication device comprises a mode controller 206 for controlling operation of a transceiver 207 in dependence on the current mode of operation. In scan mode, the mode controller 206 may control the transceiver 207 to listen for broadcast packets on the mesh network. These broadcast packets may encapsulate data that is intended for a destination device, which often may not be the communication device itself. The communication device may be configured to act as a relay in the mesh network by forwarding any broadcast packets intended for a different device towards their destination. The communication device may comprise a relay unit 208 for controlling the transceiver to retransmit any such packets.

The mode controller may also comprise a timing unit 209 for determining when the communication device should change from one operating mode to another, e.g. for determining when the communication device should wake from a sleep mode and enter the scanning mode. The timing unit 209 may be configured to obtain information that defines a schedule according to which another communication device may transmit broadcast packets over the mesh network. The mode controller 206 may be configured to control the transceiver to enter scan mode and listen for broadcast packets during the time slots defined by that schedule.

The structures shown in FIGS. 2a and 2b (and indeed all block apparatus diagrams included herein) are intended to correspond to a number of functional blocks in an apparatus. This is for illustrative purposes only. FIGS. 2a and 2b are not intended to define a strict division between different parts of hardware on a chip or between different programs, procedures or functions in software. In some embodiments, some or all of the algorithms described herein may be performed wholly or partly in hardware. In many implementations, at least part of transmit unit 202, broadcast unit 203, scheduler 204, mode controller 206, transceiver 207, relay unit 208 or timing unit 209 may be implemented by a processor acting under software control (e.g. the CPU of a communication device). Any such software may be stored on a non-transient computer readable medium, such as a memory (RAM, cache, hard disk, etc.) or other storage means (USB stick, CD, disk, etc.).

Various example scenarios are described below in which on device acts the part of a “transmitting device” and another device acts the part of a “receiving device”. This nomenclature just refers to the specific role that each device is playing in that particular scenario, and it should be understood that in most embodiments a “transmitting device” may be equally capable of “receiving” and vice versa. A “receiving device” is often also referred to as a “relay”. This is for reasons of convenience, since a receiving device may be acting as a relay when it listens for packets over the mesh network. The term “relay” is not intended to be limiting to devices that are specifically operating as a relay, however, as a device that is the destination for a particular broadcast packet may still operate in the same way with respect to listening for that packet as a device that relays the packet. Thus actions described as being performed by a “relay” might equally be performed by a generic “receiving device”.

An example of a method for setting transmission times in an ad hoc mesh network is shown in FIG. 2c. The transmitting device establishes a schedule for transmitting its broadcast packets (step S201). The transmitting device then communicates this schedule over the mesh network (step S202). There are different ways in which this schedule may be communicated. In some implementations the schedule may be communicated directly to a particular mesh device. In other implementations the schedule may simply be broadcast so that it can be intercepted by one or more mesh devices. (This is described in more detail below.) The transmitting device may communicate the entirety of its schedule or only selective parts of it. For example, the transmitting device may communicate different parts of its schedule to different mesh devices to increase the likelihood that all of its transmission schedule will be listened to.

In step S203 the schedule is received by the relay device. The relay device may then align its listening windows to the transmit schedule (step S204). In most implementations it may be up to the relay device to decide how many of the transmission slots it wants to listen to. Thus while the transmitting device is able to improve the chances of its broadcast packets being relayed by communicating its schedule, in some implementations the relays may still unilaterally decide when it wants to listen. In some implementations, however, the relay device may be mandated to listen to specified transmission slots. In step S205, the transmitting device transmits its broadcast packets over a communication channel that embodies its transmit schedule. The relay device listens according to its own listening schedule (step S206), and if it receives a broadcast packet intended for another device, rebroadcasts it (step S207).

One advantage of the techniques described above is it removes the need for continuous listening. This enables battery-powered relay devices become possible, whereas previously mains-powered relay devices could realistically be considered. This is a 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 transport of messages throughout a mesh network will now be described in more detail with reference to a specific example of a mesh network.

Within buildings, the propagation of radio frequency energy can be severely constrained by the construction of walls and other obstacles. This has led the development of a mesh network that relays messages via multiple devices (otherwise known as a mesh topology) to provide whole building coverage. An example of such a network is shown in FIG. 3, which represents a house having a distributed lighting system.

The system comprises a light switch unit 301 and light fittings 302, 303, 304, 305. Light switch unit 301 is integrated with a wireless communication device 312. Light fittings 302 to 305 are integrated with respective wireless communication devices 306, 307, 308, and 309. The house has a mains electrical supply which powers the light fittings and their respective wireless communication devices 306 to 309. Light switch unit 301 and its wireless communication device 312 are powered by a local battery 311.

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, 310, 315 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 protocol (BLE).

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 may also be 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.

Some of the communication devices may act as master devices, while others of the communication devices may act as slave devices. Some devices may always have the same role; communication device 319 of sensor 320 attached to window 318 might always act as a slave, for example. Other devices such as communication device 316 in mobile phone 315 may be capable of swapping between master and slave roles or of acting as a master and a slave at the same time. Master devices, for example, might act as slaves to other master devices. Master/slave arrangements can result in a full mesh node having significantly lower power consumption requirements than other mesh designs.

Each communication device may be capable of acting as a relay in the network. An example of this is shown in FIG. 3b, which shows the same distributed lighting system as FIG. 3a. The network is configured as a mesh network so, at least in theory, all devices that are part of the network have a responsibility to act as relays. A relay device suitably retransmits any packet that it recognises as having originated from the network (e.g. because it has been signed using a network key). The relay device might also take steps to prevent old packets from being continuously bounced around the network, e.g. by only forwarding the packet if it is new and/or by decrementing a “time-to-live” value in the packet before forwarding it on. FIG. 3a shows an example of the network operating according to traditional mesh principles. Light switch 301 transmits a packet addressed to all of devices 306 to 309 instructing light fittings 302 to 305 to switch on. This packet is propagated by all devices that receive it, eventually reaching light fitting 305, which is out of range of light switch 301, the source of the packet.

Although the arrangement shown in FIG. 3b is effective at propagating packets to all devices in the network, constant listening is an expensive operation and should be avoided in contexts where power availability is an issue. Although both device 316 and device 319 are capable as acting as relays, they are both battery powered and would prefer to reduce power consumption where possible. Therefore, one or both of those devices may deliberately reduce their receive power. For example, if device 316 communicates its transmit schedule to device 319, then device 319 can reduce its listening time by only entering scan mode during device 316's scheduled transmission slots. Thus it will still receive packets broadcast by device 316 but is able to save power by significantly reducing its receive windows.

A transmitting device's scheduled transmission slots can be considered to embody a “communication channel”. This channel may be termed an “isochronous channel” because it schedules communications to occur at set times. Isochronous channels allow for time predictable transmission and reception slots. A particular sequence of time slots might represent a particular physical channel.

An isochronous channel might be used as a uni-directional broadcast channel. For example, Device A might transmit data in broadcast packets at set times on an isochronous channel. Device B might listen to the isochronous channel at the set times to receive Device A's broadcast packets. Device A and Device B do not need to be connected with each other to do this. All that is required is for one device to know when it should listen for broadcasts from the other. Another option is for Devices A and B to use the set times on the isochronous channel as a bi-directional broadcast channel, which they both transmit and receive on (e.g. by each device having the right to transmit on alternate slots).

A transmitting device may be configured to use just one isochronous channel or multiple isochronous channels. For example, a transmitting device that is acting as a “master” or “central” device may use multiple isochronous channels to communicate with its slaves. Each channel may be designated for broadcasting to a particular slave. A master device is normally limited in the number of connections it can support simultaneously with its slave devices. An advantage of broadcasting data over isochronous channels is that it allows many slaves to be synchronised with the same master without all having to be connected to the master. This is because all the slave devices need to be able to synchronise with the isochronous channel is the timing of the transmission slots and the frequency of the channel. It does not need to be connected to the master to listen to isochronous broadcasts once it has the relevant timing and frequency information. Once a slave device is on the channel, it can stay synchronised.

A transmitting device can communicate its schedule simply by broadcasting it over the network. An alternative is for a relay device to connect to the transmitting device (or vice versa) and ask for the isochronous channel information. In some embodiments this request might be accompanied by a request to be able to send data back. The transmitting device may then allocate the relay a particular time slot (which may, for example, be defined relative to an isochronous event anchor point). The relay device then disconnects, allowing other devices to connect and request their own time slots. Thus the schedule may be communicated over a different channel from the isochronous channel that the transmitting device uses to broadcast mesh data. This enables the transmitting device to send data at low power to many relay devices, and allow those devices to send data back to it. It also enables the transmitting device to send data to device it is not connected to; it simply broadcasts data in the appropriate time slot and any relay device that has been assigned that slot, or has unilaterally decided to listen to that slot, should receive it. Using isochronous channels may therefore improve mesh throughput.

In a further example, time slots may hop between different frequencies to provide increased robustness. One option for transmitting mesh packets would be to use BLE advertising channels. There are three such channels, each on a different frequency. These channels offer frequency diversity but no frequency hopping, and thus no resilience to other networks that might be transmitting in the same frequency band. Therefore, use of isochronous channels that hop between different frequencies may be beneficial. Adaptive frequency hopping can actually be achieved with just two different frequencies. An isochronous channel might advantageously hop from one time slot to the next.

An example of a frequency hopping, isochronous channel can be found in the BLE protocol. BLE defines an isochronous channel that is designed for the transmission of audio traffic. The BLE isochronous channel defines regular time slots and a frequency hopping sequence that a master device will use to transmit some data to one or more listening slave devices. An example of such a channel is shown in FIG. 4. The channel is defined by specific times, known as “anchor points”, which set the start of each transmission. Each transmission may be known as an “event”, and may be followed by up to three re-transmissions known as “sub-events”. The sub-event anchor points are referenced to the event anchor points. Each transmission may be followed by an acknowledgement. Each “sub-event” may occur on a different frequency to increase robustness. The “sub-events” may also be an opportunity for the slave device to transmit data.

For a BLE isochronous channel, data may be time bound, meaning that specific data (e.g. a specific packet) can only be sent for a limited period of time after which the data is automatically flushed and new data can be sent. The isochronous channel is therefore different from a normal data channel on which data is retransmitted until acknowledged. The isochronous channel is typically used for broadcasting audio to multiple devices.

BLE isochronous channels are designed for audio data. They are not designed for command and control applications. When abstracted from an audio context, however, they have two qualities that particularly suit them to mesh networks: (i) transmissions occur according to a predefined schedule; and (ii) transmissions hop across different frequencies. BLE isochronous channels may therefore be advantageously adapted for transporting control-related data across a mesh network.

Assuming a BLE channel with a 120 ms interval, 0.35 ms long packets, spaced 0.15 ms apart, and three transmission opportunities every 50 ms, it is possible to have almost 40 devices synchronised with the broadcasts of a single mesh node. This is significantly higher than the number of simultaneous connections that could be supported by a single mesh node. Furthermore a slave would only need to listen for 0.35 ms every 120 ms, which is a very low duty cycle. It might be possible to reduce this duty cycle further without increasing the packet drop rate if data was retransmitted on two (or more) anchor points in a row. This would, however, be at the expense of latency.

Each of the BLE sub-events might be treated as a different isochronous channel. A different packet might be broadcast on each time slot. Alternatively packets may be repeated across successive sub-events, although this might be at the expense of latency, as mentioned above.

As can be seen from FIG. 4, BLE isochronous channels allow for acknowledgements to be sent. These may be optionally adopted as part of a mesh control channel. Mesh control messages may be either unreliable or reliably delivered. An unreliable message would typically not have a transaction identifier and would not be retransmitted. Typically these unreliable messages are used for status messages or for user-initiated actions that may be repeated again quickly, for example when rotating a dimmer control for a light. No acknowledgements may be sent for messages of this type. Reliable messages would typically contain a transaction identifier, and devices that respond to these would copy the transaction identifier from the message into the response to provide an acknowledgement for the transaction.

BLE isochronous channels are just an example of a channel that might be employed to broadcast control data over a mesh network. Channels according to other protocols might equally be used. For example, other protocols that might be employed in a mesh network include UDP, IPv4, IPv6 and TCP.

Another example of a mesh communication device is shown in FIG. 5. In this example the communication device is configured for wireless communication. The device of FIG. 5 comprises an antenna 501, a radio frequency front end 502 and a baseband processor 503. The baseband processor comprises a microprocessor 504 and a non-volatile memory 509. The non-volatile memory 509 stores in non-transitory form program code that is executable by the microprocessor to cause the baseband processor to implement the communication protocol of the network. In this example the non-volatile memory 509 stores in non-transitory form program code that is executable by the microprocessor to implement the transmit unit 505, broadcast unit 506, scheduler 507, mode controller 508, relay unit 513, timing unit 514 and receive unit 515.

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.

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 communication device capable of operating in a mesh network and configured to transmit data to a destination device by encapsulating that data in a broadcast packet and transmitting it over the mesh network in order that another communication device, on receiving the broadcast packet, forwards it towards the destination device, the communication device being further configured to:

establish a schedule for transmitting data encapsulated in broadcast packets;

transmit information defining the schedule over the mesh network; and

subsequently transmit the broadcast packets in accordance with the schedule.

2. The communication device as claimed in claim 1, configured to encapsulate non-audio data in the broadcast packets.

3. The communication device as claimed in claim 1, configured to encapsulate control data in the broadcast packets.

4. The communication device as claimed in claim 1, configured to transmit the broadcast packets over a channel that implements frequency hopping.

5. The communication device as claimed in claim 1, configured to transmit the broadcast packets by transmitting each broadcast packet on a different frequency from the preceding broadcast packet.

6. The communication device as claimed in claim 1, configured to transmit the information defining the schedule over a different channel from the broadcast packets.

7. The communication device as claimed in claim 1, configured to transmit information that defines the timing and frequency of the schedule.

8. The communication device as claimed in claim 1, configured to broadcast the information defining the schedule over the mesh network.

9. The communication device as claimed in claim 1, configured to transmit the information defining the schedule over a connection with another communication device.

10. The communication device as claimed in claim 9, configured to terminate the connection with the other communication device once it has transmitted the information defining the schedule.

11. The communication device as claimed in claim 1, configured to establish a schedule under which the communication device transmits broadcast packets that encapsulate the same data for the same destination device at different time instants.

12. The communication device as claimed in claim 1, configured to transmit the broadcast packets over a Bluetooth Low Energy isochronous channel.

13. The communication device as claimed in claim 1, configured to encapsulate data for transmission over the mesh network in a Bluetooth Low Energy advertising packet.

14. A communication device capable of operating in a mesh network and having a scan mode in which it listens for broadcast packets on the mesh network, said broadcast packets encapsulating data that is intended for a destination device, and forwards any such broadcast packet towards the respective destination device, the communication device being configured to:

obtain information that defines a schedule according to which another communication device will transmit broadcast packets over the mesh network; and

enter scan mode and listen for broadcast packets at times defined by the schedule.

15. The communication device as claimed in claim 14, configured to not enter scan mode at times that are not defined by the schedule.

16. The communication device as claimed in claim 14, configured to obtain information defining the schedule by listening for a broadcast packet that defines the schedule.

17. The communication device as claimed in claim 14, configured to obtain information defining the schedule by connecting with the other communication device.

18. The communication device as claimed in claim 17, configured to disconnect from the other communication device once the information defining the schedule has been received.

19. The communication device as claimed in claim 14, configured to enter scan mode and listen for broadcast packets when it is not connected to the other communication device.