US20150245203A1

US20150245203A1 - Packet identification

Info

Publication number: US20150245203A1
Application number: US14/298,177
Authority: US
Inventors: Hugo Mark Tyson; Nicolas Guy Albert Graube; Robin Heydon
Original assignee: Cambridge Silicon Radio Ltd
Current assignee: Qualcomm Technologies International Ltd
Priority date: 2014-02-25
Filing date: 2014-06-06
Publication date: 2015-08-27
Also published as: DE102015101699A1; GB2512256A; GB2512748A; DE102015101620A1; DE102015101698A1; GB2518120B; GB2512781B; DE102014012518A1; US20150245182A1; GB2515923B; US10055570B2; GB2512544A; GB2512502A; GB2523444B; GB201412720D0; GB201421698D0; GB2512748B; GB2513265B; GB201405785D0; GB201412717D0

Abstract

A method for identifying packets received at a wireless communication device capable of operating according to a wireless communications protocol and capable of communicating in a network, the method comprising: receiving a first packet; processing, in accordance with a predetermined algorithm, a portion of the first packet in dependence on a first network key associated with a first network; and determining if a result of said processing is successful or unsuccessful and, if successful, identifying the first packet as being addressed to devices in the first network.

Description

TECHNICAL FIELD

This invention relates to a method of identifying packets received at a wireless communications device in a network.

BACKGROUND OF THE INVENTION

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 a home, for example, it may be desirable that the objects in a room be capable of communicating with each other, and also potentially to be able to communicate with the internet or cloud. For example, the room may have a light, light switch, window and door. It may be desired that each of these objects be able to communicate with the others so that the home can be automated.
To enable objects to communicate, they may be equipped with a communication device that can communicate with similar communication devices attached to other objects. For this architecture to be of greatest use, a large number of objects may need to be able to communicate with each other. The result can be a network of
many communication devices, each associated with a respective object. As many of these objects will not have access to, or require, power themselves (for example, a window, door, packages sitting on a shelf, etc.), there may be a desire for the devices that communicate on the objects' behalf to be battery-powered devices that consume only a small amount of power. It may also be desirable that these devices be able to communicate wirelessly with each other so that there is no need for cables running between them.
One suitable method of communication for such a network is to use a mesh networking protocol. This permits a first device to send a message to a second device, which may be outside the communication range of the first device, by transmitting the message via one or more intermediate devices. Historically, mesh networking protocols are typically designed around the concept of devices sending messages using complex routing tables. Such complex routing requires processing power which tends to increase power consumption of the devices. Such mesh networking protocols also tend to operate according to proprietary protocols. This means devices have to be manufactured specifically for the task of communicating according to a particular mesh network. This may be undesirable because it increases the cost of devices that might be installed in a multitude locations and/or attached to a multitude of different devices.
There may he a large number of devices in a mesh network, which can lead to problems such as an increase in the complexity of the addressing scheme used identify devices and an increase in the power consumption of each device. For example, problems could arise within an apartment complex having various apartments, each having various devices that are capable of operating in a mesh network. Devices within a given apartment may not wish to relay messages from other apartments having devices that are owned by another user. Each time a device relays a message it uses energy, which is particularly disadvantageous for devices that are battery powered. Thus devices in a given apartment would waste energy relaying messages that are for devices in another apartments.
Another consideration may be to provide adequate security to devices in a mesh network against potential attackers. One possible type of attack is an “eavesdropper attack” where an attacker passively listens to messages exchanged between devices in the mesh network. Another type of attack is a “man-in-the-middle attack” where an attacker intercepts messages between two devices and pretends to be those devices. For example, as shown in FIG. 1, an eavesdropper “E” can passively listen to messages exchanged between devices C and B. A man-in-the-middle “M” may be able to intercept messages and pretend to be C to B and pretend to be B to C and so all messages between B and C are passed through M.
There is therefore a need for securely communicating messages between devices in a mesh network. Furthermore, there is also a need to minimise the power consumption of devices in a mesh network.

SUMMARY OF THE INVENTION

According to a first aspect there is provided a method for identifying packets received at a wireless communication device capable of operating according to a wireless communications protocol and capable of communicating in a network, the method comprising: receiving a first packet; processing, in accordance with a predetermined algorithm, a portion of the first packet in dependence on a first network key associated with a first network; and determining if a result of said processing is successful or unsuccessful and, if successful, identifying the first packet as being addressed to devices in the first network.
The first packet may further comprise an authentication code related, according to the predetermined algorithm, to the portion and the first network key, said determination may be dependent on the authentication code.
The processing step may comprise calculating, from the portion and first network key and using the predetermined algorithm, a value, and said determining step may comprise comparing said calculated value with the or an authentication code and, if said calculated value and the authentication code match, determining that the result of the processing is successful.
The predetermined algorithm may be a hash-based message authentication code algorithm.
The processing step may comprise decrypting the portion in accordance with the predetermined algorithm and in dependence on the first network key, and said determining step comprising analysing the decrypted portion so as to determine if the portion is decipherable and, if so, determining that the result of the processing is successful, the predetermined algorithm being a decryption algorithm.
The portion may be encrypted using the first network key.
The portion may be a payload of the first packet.
The first packet may be a transport layer packet and the portion may comprise a message for processing at a higher layer,
In response to identifying the packet as being addressed to devices in the first network, the message may be processed at a layer above the transport layer.
The message may be opaque to the transport layer.
In response to identifying the packet as being addressed to devices in the first network, a second packet may be formed comprising a portion that is the same as the portion of the first packet and broadcasting the second packet.
If the result of the processing is successful, the first packet may be identified as being sent from a device belonging to the first network.
In response to determining that the result of the processing is unsuccessful, the first packet may be identified as being addressed to devices in a network other than the first network.
The method may further comprise receiving and storing the first network key and a second network key associated with a second network that is different to the first
network.
The method may further comprise: processing, in accordance with the predetermined algorithm, the portion of the first packet in dependence on the second
network key; and determining if a result of said processing using the second network key is successful or unsuccessful and, if successful, identifying the first packet as being addressed to devices in the second network.
The wireless communication device may be capable of communicating with devices in the first and second networks.
According to a second aspect there is provided a method for forming a first packet at a wireless communication device capable of operating according to a wireless communications protocol, the method comprising: generating a message intended for a device in a first network; selecting a network key associated with the first network, encrypting the message in dependence of the selected network key; and forming a first packet comprising the encrypted message.
The method may further comprise: in dependence on a predetermined algorithm and the encrypted message, calculating an authentication code, the formed first packet further comprising the authentication code.
According to a third aspect there is provided a method for forming a first packet at a wireless communication device capable of operating according to a wireless communications protocol, the method comprising: generating a message intended for a device in a first network; selecting a network key associated with the first network; calculating, in dependence on a predetermined algorithm and the message, an authentication code; and forming a first packet comprising the message and the authentication code.
Preferably, the first packet does not have an address field for identifying a network.
The first network may be a mesh network.
The first network may be an ad-hoc network.
The wireless communications protocol may define a broadcast packet type, the method may further comprise receiving a broadcast packet of the broadcast packet type, the broadcast packet comprising the first packet.
The wireless communications protocol may be Bluetooth low energy.
According to a fourth aspect there is provided a wireless communication device capable of operating according to a wireless communications protocol and capable of communicating in a network, the device comprising: a transceiver configured receive a first packet; and a processor configured to process, in accordance with a predetermined algorithm, a portion of the first packet in dependence on a first network key associated with a first network, the processor being further configured to determine if a result of said processing is successful or unsuccessful and, if successful, identify the first packet as being addressed to devices in the first network.
According to a fifth aspect there is provided a wireless communication device capable of operating according to a wireless communications protocol, the device comprising:
an interface configured to provide a message intended for a first device in a first network; and a processor configured to: select a network key associated with the first network; calculate, in dependence on a predetermined algorithm and the message, an authentication code; and form a first packet comprising the message and the authentication code.

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 devices in an example scenario in which the security of a network may be compromised;

FIG. 2 shows a schematic diagram of an example network containing a plurality of wireless communications devices;

FIG. 3 shows a schematic diagram of the network of FIG. 2 and another example network containing a plurality of wireless communications devices;

FIG. 4 illustrates an example transport layer packet format; and

FIG. 5 shows a schematic diagram of an example wireless communications Device.

DETAILED DESCRIPTION OF THE INVENTION

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. 2 shows a first network 100 that comprises a plurality of objects each equipped with a wireless communication device that enables the object to communicate over a wireless communications protocol. This network 100 comprises lights 110, 120, 130, 140, 150, a fan 160 and light switch 170 which are each equipped with a wireless communication device. These objects are given as examples, and it will be readily appreciated that any other object could be equipped with such a communication device for communicating with the other communication devices.
The devices at the extremities of the network 100 may be outside of direct communications range of one or more of the other devices. This may be because the communication devices attached to the objects are low power communication devices. For example, lights 110 and 150, and fan 160 may be within the direct communication range of light switch 170. However, lights 120, 130 and 140 may be outside of the direct communication range of light switch 170, but within the direct communication range of lights 110 and 150 and fan 160. For light switch 170 to communicate with lights 120, 130 and 140, a communication sent by the light switch 170 is preferably retransmitted by at least one of light 110, light 150 or fan 160. These devices may not know whether the other devices have received the transmission, thus they alt may be configured to retransmit the message.
A suitable method of transmitting a message from the device associated with light switch 170 to the device associated with light 120 which is outside the direct communication range of light switch device 170 is a mesh network that can use a flood routing method to propagate information. Flood routing enables potentially every device that is capable of communicating according to the wireless communication protocol to receive a copy of a message transmitted either directly (e.g., from light switch device 170, which transmitted original message) or indirectly via another device receiving the message and retransmitting it. There may be some devices that do not receive a copy of a message due to those devices being out of range when a copy is sent or by not scanning at the appropriate times. In this way, a message sent by light switch device 170 will eventually reach light 120. Using flood routing can communicate a transmitted message to many other communication devices. Flood routing involves (i) a means of broadcasting messages to all devices that are within the communication range of a sending device and (ii) devices that receive such broadcast messages being configured to rebroadcast them so that the rebroadcast messages are also received by all devices within the respective communication ranges of the rebroadcasting devices.
FIG. 3 shows a second network 200 that comprises a plurality of objects each equipped with a wireless communication device that enables the object to communicate over the wireless communications protocol. This network 200 comprises lights 210, 220, 240, 250, a smartphone 260 and light switch 270 which are each equipped with a wireless communication device. In an example scenario, devices 110, 120, 140, 150, 160 and 170 in network 100 may belong to a first apartment and devices 210, 220, 240, 250, 260 and 270 in network 200 may belong to a second, adjacent apartment. Networks 100 and 200 may overlap in coverage area. Light 130 may belong to the first apartment (i.e. part of network 100) or it may be a communal light which may be in a hallway between the two apartments and thus belong to both networks 100 and 200.
A device, for example light 140, may wish to send a message to light switch 170. Using the flood routing method, the light 140 will broadcast the message, which may be received by nearby devices 130 and 160. Devices 130 and 160 may then rebroadcast the same message as part of the flood routing method. The retransmission by device 160 may lead to the message being delivered to its intended recipient, the light switch 170, which may then analyse the message.
However, the retransmission by light 130 could lead to the message being received by lights 220 and 240; which are pail of another, second, apartment. Devices 220 and 240 may then themselves rebroadcast the message even though they are not part of network 100. Thus, lights 220 and 240 would wastefully rebroadcast the message and the contents of that message may be accessible to a device located in the second apartment and beyond even though those devices are not in network 100 or in the apartment for vicinity) of the intended recipient. This can lead to a waste of energy tor the devices in the second apartment. The devices in the network 100 would also be more susceptible to the types of security attacks described above as its messages can be propagated away from the first apartment to untrusted devices. Furthermore, unconditionally retransmitting received messages can lead to congestion in both networks 100 and 200.
To overcome some of these and other issues, the devices that take part in the flood routing method could be partitioned into discrete networks so that devices only communicate with other devices that are part of the same network. Each device could be configured so that it would only accept messages that are associated with the network(s) associated with that device. Thus any message not associated with its network would be discarded as that message would be associated with another network. In this way, the devices would be configured to only rebroadcast messages that are associated with its network(s) and so the flood routing of messages is limited to associated devices.
Each device would need to know which network that it is a part of. This could be achieved by means of a network key, which could be unique to each network. Each device that is part of a network would be provided an appropriate network key. For example, smartphone 260 may be a device that configures network 200. The smartphone 260 may generate and provide a network key that is associated with network 200 to devices 210, 220, 240, 250, 260 and 270. Because the network key is critical to the security of the network 200, it is preferable that the network key is distributed to each device in a secure association procedure, which, for example, may use a key exchange mechanism (e.g. a Diffie-Hellman-Merkle key exchange) to encrypt the network key.
A device may be associated with a plurality of networks and thus be provided with a plurality of associated network keys. In the example where light 130 is a communal light, the configuring device 260 for network 200 may also provide light 130 with a network key for network 200. Thus light 130 can be part of network 100 and 200 and store their associated network keys.
Traditionally, to identify which network a received packet is addressed to, network identifiers are added to a header or tail of a packet comprising a payload. It would be possible to use a short identifier for the network key, and include this in the header or tail of a packet. However, an eavesdropping device that is not part of the network would be able to determine the network key from a transmitted packet, which would compromise the security of the network.
FIG. 4 illustrates a format of a packet 400 that could be used by the devices in networks 100 and 200. The packet 400 may comprise a higher layer message field 410, a Message Authentication Code (MAC) field 420 and a Time-To-Live (TTL) field 430.
The packet 400 may be comprised within the payload of a broadcast packet, which may, for example be a Bluetooth low energy non-connectable undirected advertising packet. Packet 400 may be a mesh transport layer packet which a device can process at the transport layer to enable the retransmission of the message throughout a network.
The higher layer message field 410 can comprise a message that is generated by one device to be sent to one or more other device. The contents of the higher layer message may be intended for processing at a layer higher than the transport layer (e.g. at the application level) and so it may be opaque to the transport layer. The higher level message field 410 may comprise the ID of the sender and a serial number. The serial number can be unique to that particular sender. The pair of the sender-ID and the serial number can be used to uniquely identify a particular message within the mesh network. The higher layer message 410 may be considered to be the payload of the packet as it contains the information that is purpose of the transmission of the packet. For example, light switch 270 may wish to instruct lights 210 and 240 to switch on and thus may generate an appropriate message for those lights at an application layer. Packet 400 may then be formed with the application layer message being the contents of the higher layer message 410.
The payload of the mesh transport packet 400 can also be described as the static content of the mesh transport packet 400 because if is not altered as it is retransmitted throughout the mesh network 100.
Optionally, the packet 400 may comprise the TTL field 430, which can generally be described as a lifetime field 430 that defines the lifetime of the mesh transport packet 400 within the mesh network. The lifetime field 430 of the mesh transport packet 400 can be used by a receiving device to determine whether the received mesh transport packet 400 should be rebroadcasted or not. When a device retransmits a packet 400, the device transmits the packet with fields 410 and 420 identical to that of the content of the packet as it received it, except that if decrements the TTL value, e.g. by one. Conveniently, each device is configured not to retransmit any mesh packets it receives with a TTL of zero. In that way the TTL serves to prevent messages circulating indefinitely in the mesh network. 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. In other implementations the TTL could be interpreted in other ways: for example it could be incremented up to a pre-set limit at each retransmission.
The MAC 420 could be generated by a transmitting device, e.g. light switch 270, in
dependence on the higher level message 410. The MAC 420 can be calculated using a predetermined algorithm. The algorithm may be, for example, a cryptographic hash function such as HMAC-SHA256 or a cipher block chaining MAC such as AES-128 CBC-MAC. The higher layer message 410 and the network key associated with the network of the transmitting device and the intended recipient device is inputted into the algorithm to calculate the MAC 420. The transmitting device then packetises the higher level message and the MAC, which is included in the MAC 420 field, to form packet 400, The packet 400 is then broadcasted. The broadcasted packet does not include the network key (but does include a MAC derived from the network key) and so an eavesdropper may not be able to determine the network key from the broadcasted packet.
Preferably, the higher level message is encrypted with the network key. The higher level message can be encrypted with the network key using an encryption algorithm. The encryption algorithm may be, for example, AES-128 Counter Mode, which can, use as inputs the sender ID and the serial number, for example. Alternatively, the higher level message may be encrypted using other encryption algorithms, such as AES-192, AES-256 or a DES algorithm. Thus, when sending a message, the transmitting device encrypts the message from the layer above the transport layer with the appropriate network key and then inputs the encrypted message and the same network key into the algorithm to generate the MAC. The encrypted message and the MAC are then packetised to form packet 400.
A packet broadcasted, by light switch 270 for example, may then be received by light 210. As mentioned above, it may be advantageous if a device only retransmits a packet if that packet is part of the same network. Thus light 210 processes the packet to identify if the received packet is from a device within the same network.
The network that a received packet belongs to can be identified using the network key or keys that are stored at a device. For example, device 210 may process a portion (which could be some or all parts) of the received packet in dependence upon a network key (e.g. for network 200) stored in a memory of that device. Device 210 can input the stored network key and the received higher level message into the hash-based MAC algorithm to calculate a value. If that value matches the MAC 410 of the packet, then the device 210 successfully determines that the packet is for network 200. If the calculated value does not match the MAC 410 of the received packet, then the match is deemed to be unsuccessful and the packet is not for network 200. Thus, device 210 is able to identify if a received packet is addressed to devices in network 200.
As mentioned above, when a device receives the mesh transport packet 400, it is preferably configured to decide whether to retransmit it or not.
Each device may be configured either to retransmit all mesh packets it receives or only those mesh packets identified as belonging to the network(s) of that device by means of its stored network keys. Which of these behaviours a device adopts may be determined manually or automatically in dependence on the power state of the device. For example, a device that is powered by mains electricity could be configured to detect that fact and in dependence on that determination automatically enter a state in which it forwards mesh messages it receives irrespective of its ability to identify/decrypt them. However, as mentioned above, it is preferable for a device to only forward messages mesh messages that are part of the same network(s) of that device. A device that is powered by battery could be configured to detect that fact, or the fact that the battery charge is below a predetermined threshold, and in dependence on that determination automatically enter a state in which it forwards only a subset of the mesh messages it receives, for example only the mesh messages it is capable of identifying as part of the same network. For example, if device 210 identifies a received packet as not being for network 200 (e.g. a packet from device 140), then device 210 can determine that the packet should not be retransmitted and can disregard the received packet. If device 210 identifies that a received packet is for network 200, then device 210 can determine whether to retransmit the packer and/or whether to process the higher layer message.
The retransmission behaviour of the device may also be determined in dependence on the initialisation state of the device. For example, a device may be configured to unconditionally forward all mesh packets it receives until it has been associated with a particular network. That is, the device may unconditionally forward all received mesh packets until it is configured with a network key and ID.
After determining that the received packet is for network 200, device 210 may determine whether that packet has the same payload as a previously received packet. If the payload has previously been received by the device 210, then device 210 does not retransmit the packet. If the payload of the packet has not previously been received by the device 210, then device 210 can decide whether to retransmit the packet or not based on, for example, the lifetime of the packet (which can be determined from the lifetime field 430) and/or the intended recipient of the higher level message. For example, if packet transmitted by device 270 has a higher layer message intended for device 240 and is received by device 210, then device 210 may decide to retransmit the packet. If device 240 receives the packet having a higher layer message intended for it, then the device 240 will not retransmit the packet and process the higher layer message data. The intended destination device for the higher layer message may be indicated in that message. For example, the intended destination device may be indicated by a destination ID, which may be contained in a destination address field within the higher layer message.
If a packet is to be retransmitted, the content of the higher layer message field 410 and the MAC field 420 may be unaltered when forming the packet for retransmission. Thus further devices that receive the retransmitted packet will then also be able to determine which network the packet is addressed to.
Devices may be a part of more than one network and thus store more than one associated network keys, which can be used to determine which of those networks a received packet is addressed to. For example, light 130 may belong to two networks 100 and 200 and therefore store network keys for both of those networks. When light 130 receives a packet, it can carry out a first hash-based MAC calculation using the received higher level message and the stored network key for network 100 and then also carry out a second hash-based MAC calculation using the same received higher level message and the stored network key for network 200. The network that the packet belongs to can then be determined from whichever of the first and second calculations results in a successful match with the MAC 420 in the received packet.
Encrypting the higher level message with the network key provides savings in the amount of data that is required to be transmitted to identify the packet. As the packet does not require a dedicated network identity field, the packet size can be smaller than if such a field was required. This reduces the packetisation overhead for data to be transmitted within the mesh network, which is particularly advantageous for low power devices. Furthermore, encryption of the higher level message using the network key also provides security against potential attacks. Thus a single network key can be used for the dual purpose of identifying which network received packets belong to and decrypting data in that packet. Furthermore, providing a network key to certain devices in a mesh network allows those certain devices to form another sub-network, within which devices only retransmit messages for that sub-network. This reduces the number of total retransmissions a device is required to make and also prevents messages to be sent to untrusted devices.
In another embodiment, the MAC field may not be required. In this embodiment, a transmitting device can encrypt a higher layer message with the appropriate network key and a receiving device can process the higher layer message and attempt to decrypt it using the network key or keys it has stored thereon. If the attempted decryption with one of the network keys results in a message that is decipherable by the device, then the decryption with that key is successful and thus it is determined that the packet was addressed to the network associated with that key. if an attempted decryption with a network key does not result in a decipherable message, then it is determined that the packet is not addressed to the network that is associated with that network key. Thus a successful or unsuccessful decryption of a packet using network keys can indicate which network the received packet is addressed to.
In yet another embodiment, a checksum may be used in addition or alternatively to the MAC. In this embodiment, a transmitting device composes a message for use in a certain mesh network and forms a payload including the traffic data it wishes to convey and generates a checksum for that payload using a predefined checksum algorithm. It then concatenates the payload and the checksum and encrypts them using a predefined encryption algorithm which takes as input the concatenated plaintext payload and the network key that corresponds to the mesh network in question. The output of the encryption step is an encrypted payload, which is added to a mesh packet that is broadcasted. When a receiving device receives a mesh packet it attempts to decrypt the packet using one or each network key it has stored. It applies the payload of the received packet and a stored network key as input to the inverse of the predefined encryption algorithm, it then computes a checksum for the portion of the decrypted string that would represent a plaintext payload (e.g. the first n bits of the decrypted string), and checks whether that computed checksum matches the portion of the decrypted string that would represent a checksum (e.g. the final m bits of the decrypted string). If the two match then the packet can be considered successfully decrypted. If not, the device repeats the process with any other network keys it has stored, if the receiving device has successfully decrypted the packet it interprets the plaintext payload according to a suitable application layer protocol.
By utilising the network key and the higher layer message (or payload) as described
above, a packet can be provided that does not require a dedicated network identity field. This could mean that the network identity can be made less explicit in the sense that the identity of the network would not appear as an identifiable set of bits within the data stream of a transmitted packet. Instead, the network identity can be made more implicit (and therefore more secure) by replacing a network identity field and processing packets with the network key as described above. One way of viewing this, is that, for example, rather than having a dedicated set of bits for identifying the network, these bits are spread over the data stream of the packet by orthogonally multiplexing the bits with the data stream.
As mentioned above, each of the objects (lights, switches, etc.) comprises a wireless communication device that enables the object to communicate over a wireless communications protocol. FIG. 5 shows a schematic diagram of an example wireless communication device 500. The device 500 may comprise an antenna 501 connected to a transceiver 602. The device 500 can use the transceiver 502 to communicate with at least one other communication device according to the communications protocol. The device 500 may also comprise a processor 503 that is capable of executing a set of program instructions that may be stored in a memory 504. The memory 504 can be a non-volatile memory that stores in non-transitory form program code that is executable by the processor 503 to cause the device 500 to communicate according to the communications protocol and to carry out the encryption/decryption and network identification processes described herein. The memory 504 may also store one or more network keys. The processor 503 can be a microprocessor. The memory 504 may be part of processor 503 or connected to processor 503 via a bus. Whilst the processor 503 and transceiver 502 are shown in FIG. 5 as separate elements, it will be appreciated that at least processor 503 and transceiver 502 could be incorporated in to one element, for example, being incorporated on a single chip.
The device 500 may also comprise a power source (not shown). The power source may be a battery. Alternatively, the device 500 may not comprise a power source and be connected to an external power source such as an electrical outlet.
The communication device also comprises an interface 506 for sending and receiving data that is sent and received using the communications protocol. A higher layer entity, e.g. an object controller, which may be an application, can provide higher layer message data via the interface 505 for sending via the protocol. Higher layer message data from a received packet can be provided to, e.g. the controller, via the interface 506. The interface 505 may be a wired link. The wired link may be to sensors for sensing external events, such as the operation of a light switch in the home environment described above, or a link to appliances for issuing control signals to those appliances, such as the light in the home environment described above.
The devices described herein may be wireless communication devices that operate according to the same wireless communication protocol. The wireless communication protocol could be a relatively short-range protocol. For example the effective range of each device could be less than 25 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. 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 802.11 or ZigBee.
The devices described herein may comprise secondary communication interface that supports a different, second, physical and/or logical communications protocol from the one that is used for communicating over the mesh network. Examples of the protocols that could be supported by the secondary communication interface include wireless protocols such as those mentioned above and also wired protocols such as Ethernet, USB or HomePlug.
The devices described herein could form a mesh network with other wireless communication devices. The devices could be configured to forward some or all messages they receive. The messages could be sent and received via a broadcast packet type defined in the wireless communication protocol. All the devices in the network could be peers in that they have identical roles at a network level.
The devices configured in accordance with the examples described herein could be embodied in hardware, software or any suitable combination of hardware and software. The receiving device of the examples described herein could comprise, for example, software for execution at one or more processors (such as at a CPU and/or GPU), and/or one or more dedicated processors (such as ASICs), and/or one or more programmable processors (such as FPGAs) suitably programmed so as to provide functionalities of the data processing system, and/or heterogeneous processors comprising one or more dedicated, programmable and general purpose processing functionalities. In the examples described herein, the devices comprise one or more processors and one or more memories having program code stored thereon, the data processors and the memories being such as to, in combination, provide the claimed data processing systems and/or perform the claimed methods.
Data processing units described herein (e.g. processor 503) need not be provided as discrete units and represent functionalities that could (a) be combined in any manner, and (b) themselves comprise one or more data processing entities. Data processing units could be provided by any suitable hardware or software functionalities, or combinations of hardware and software functionalities.
Any one or more of the methods described herein could be performed by one or more physical processing units executing program code that causes the unit(s) to perform the data processing methods. Each physical processing unit could be any suitable processor, such as a CPU or GPU (or a core thereof), or fixed function or programmable hardware. The program code could be stored in non-transitory form at a machine readable medium such as an integrated circuit memory, or optical or magnetic storage. A machine readable medium might comprise several memories, such as on-chip memories, computer working memories, and non-volatile storage devices.
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

What is claimed is:

1. A method for identifying packets received at a wireless communication device capable of operating according to a wireless communications protocol and capable of communicating in a network, the method comprising:

receiving a first packet;

processing, in accordance with a predetermined algorithm, a portion of the first packet in dependence on a first network key associated with a first network; and

determining if a result of said processing is successful or unsuccessful and, if successful, identifying the first packet as being addressed to devices in the first network.

2. A method as claimed in claim 1, the first packet further comprising an authentication code related, according to the predetermined algorithm, to the portion and the first network key, said determination being dependent on the authentication code.

3. A method as claimed in claim 1, said processing step comprising calculating, from the portion and first network key and using the predetermined algorithm, a value, and said determining step comprising comparing said calculated value with the or an authentication code and, if said calculated value and the authentication code match, determining that the result of the processing is successful.

4. A method as claimed in claim 1, said processing step comprising decrypting the portion in accordance with the predetermined algorithm and in dependence on the first network key, and said determining step comprising analysing the decrypted portion so as to determine if the portion is decipherable and, if so, determining that the result of the processing is successful, the predetermined algorithm being a decryption algorithm.

5. A method as claimed in claim 1, said predetermined algorithm being a hash-based message authentication code algorithm.

6. A method as claimed in claim 1, the portion being encrypted using the first network key.

7. A method as claimed in claim 1, the portion being a payload of the first packet.

8. A method as claimed in claim 1, the first packet being a transport layer packet and the portion comprising a message for processing at a higher layer.

9. A method as claimed in 8, in response to identifying the packet as being addressed to devices in the first network, processing the message at a layer above the transport layer.

10. A method as claimed in claim 1, further comprising: in response to identifying the packet as being addressed to devices in the first network, forming a second packet comprising a portion that is the same as the portion of the first packet and broadcasting the second packet.

11. A method as claimed in claim 1, if the result of the processing is successful, identifying that the first packet was sent from a device belonging to the first network.

12. A method as claimed in claim 1, in response to determining that the result of the processing is unsuccessful, identifying the first packet as being addressed to devices in a network other than the first network.

13. A method as claimed in claim 1, further comprising receiving and storing the first network key and a second network key associated with a second network that is different to the first network.

14. A method as claimed in claim 13, further comprising:

processing, in accordance with the predetermined algorithm, the portion of the first packet in dependence on the second network key; and

determining if a result of said processing using the second network key is successful or unsuccessful and, if successful, identifying the first packet as being addressed to devices in the second network.

15. A method as claimed claim 1, the first packet not having an address field for identifying a network.

16. A method as claimed in claim 1, the first network being a mesh network and/or an ad-hoc network.

17. A method as claimed in claim 1, the wireless communications protocol defining a broadcast packet type, the method comprising receiving a broadcast packet of the broadcast packet type, the broadcast packet comprising the first packet.

18. A method as claimed in claim 1, the wireless communications protocol being Bluetooth low energy.

19. A method for forming a first packet at a wireless communication device capable of operating according to a wireless communications protocol, the method comprising: generating a message intended for a device in a first network; selecting a network key associated with the first network; calculating, in dependence on a predetermined algorithm and the message, an authentication code; and forming a first packet comprising the message and the authentication code.

20. A wireless communication device capable of operating according to a wireless communications protocol and capable of communicating in a network, the device comprising:

a transceiver configured receive a first packet; and

a processor configured to process, in accordance with a predetermined algorithm, a portion of the first packet in dependence on a first network key associated with a first network,

the processor being further configured to determine if a result of said processing is successful or unsuccessful and, if successful, identify the first packet as being addressed to devices in the first network.