Bluetooth®-based IPv6 low-power networking

Abstract

The present invention provides wireless devices, relay devices, systems, and methods that reduce the possibility of device failure due to the depletion of accumulated power. [Solution] In an embodiment including a wireless medical device S mounted to perform medical functions, a relay device T having a radio for communicating via a wireless communication protocol that employs messages constructed as Layer 2 MAC frames each including a Layer 2 MAC header and a payload, receives messages M0, ..., Mn from the wireless device S via the radio, each including a higher layer protocol data unit encapsulated within the payload of a Layer 2 MAC frame without including an IPv6 header, inserts header information A' into the messages, and retransmits the messages as messages M0', ..., Mn'.

Description

Technical Field

[0001]

[0001] This application claims the benefit of U.S. Provisional Application No. 62 / 622,982, filed on January 29, 2018, entitled "BLUETOOTH (Registered Trademark) IPV6 LOW POWER". U.S. Provisional Application No. 62 / 622,982, filed on January 29, 2018, is hereby incorporated by reference in its entirety.

[0002]

[0002] The following generally relates to wireless medical sensors, low-power wireless sensors, mobile sensors, and other similar applications.

Background Art

[0003] The Bluetooth® Low Energy (BLE) communication protocol is a subset of the Bluetooth® standard that targets low-power applications. With the latest Bluetooth®-5 standard, which has optional range and data length extensions for BLE, BLE is a more suitable candidate for Internet of Things (IoT) devices and Internet of Health (IoH) devices in application areas such as home automation and healthcare. In addition, the Internet Protocol Support Profile (IPSP) specification has been published along with the IETF specification RFC7668 to enable support for exchanging IPv6 packets between devices over Bluetooth® Low Energy Transport. This allows BLE devices to autonomously decide to send data (and adjust their activation schedule accordingly) whenever they have new data available, enabling them to implement common IP layer communication protocols such as Constrained Application Protocol (CoAP) over UDP / IP, Message Queuing Telemetry Transport (MQTT) over TCP / IP, or Hypertext Transfer Protocol (HTTP) over TCP / IP, without relying on specific General Attributes (GATT) profiles to be supported on the device, and without relying on GATT clients to fetch data from a device acting as a GATT server. Furthermore, this allows each device to have a common addressing scheme that enables BLE personal area networks to extend to wide area networks. [Overview of the project] [Problems that the invention aims to solve]

[0004]

[0004] In the field of mobile medical devices, there is particular interest in such devices operating with low power consumption in order to extend the time that a device can operate on a single device battery charge, and thus reduce the possibility of device failure due to the depletion of stored power. Technologies such as BLE are advantageous in this regard, but the objective in some mobile medical devices is to operate for an extended period, for example several weeks or longer, on a single battery charge.

[0005]

[0005] The following discloses some improvements. [Means for solving the problem]

[0006]

[0006] In some exemplary embodiments disclosed herein, a wireless device comprises a radio for communicating via a wireless communication protocol that employs messages constructed as Layer 2 MAC frames, each including a Layer 2 MAC header and a payload. The wireless device is configured to operate in a first mode, (i) via the radio, messages (N0, ..., Nn) each including an IPv6 packet header and a higher layer protocol data unit encapsulated within the payload of a Layer 2 MAC frame, and (ii) via the radio, messages (M0, ..., Mn) each including a higher layer protocol data unit encapsulated within the payload of a Layer 2 MAC frame without including an IPv6 header. The wireless device is further configured to transition from a first mode to a second mode by an operation that includes transmitting a header information message (X) via a radio (R) to a relay device (T) that provides a header insertion service (I), wherein the header information message includes at least the address (A) of the wireless device to be used to construct an IPv6 source address or the address (D) of a host device to be used to construct an IPv6 destination address. In some embodiments, the wireless device is further configured to transition from a first mode to a second mode by an operation that further includes receiving a message from the relay device that triggers the transition from the first mode to the second mode.

[0007]

[0007] In some exemplary embodiments disclosed herein, a relay device comprises a radio for communicating over a wireless communication protocol that employs messages constructed as Layer 2 MAC frames, each including a Layer 2 MAC header and a payload. The relay device is configured to perform a header insertion service, in which the relay device receives messages (M0, ..., Mn) from a wireless device via the radio, each including a higher-layer protocol data unit encapsulated within the payload of a Layer 2 MAC frame without including an IPv6 header, inserts header information (A') into the messages received from the wireless device, and retransmits the message with the complete header as a message (M0', ..., Mn'). The relay device is further configured to receive a header information message from the wireless device and store the header information contained in the header information message as header information in the relay device. The relay device is further configured to send a message to the wireless device to notify the wireless device of the availability of the relay device to perform a header insertion service for the wireless device.

[0008]

[0008] In some exemplary embodiments disclosed herein, the system comprises the wireless device and relay device described in the two preceding paragraphs.

[0009]

[0009] The present invention can take the form of various components and arrangements of components, as well as various steps and arrangements of steps. The drawings are for illustrative purposes only and should not be construed as limiting the present invention. [Brief explanation of the drawing]

[0010] [Figure 1]

[0010] This figure schematically shows one embodiment of a low-power wireless medical device that operates together with a header insertion device to reduce the power consumption of the wireless medical device. [Figure 2]

[0011] This diagram shows a schematic flowchart illustrating the communication methods described herein. [Figure 3] This diagram shows a schematic flowchart illustrating the communication methods described herein. [Figure 4] This diagram shows a schematic flowchart illustrating the communication methods described herein. [Figure 5] This diagram shows a schematic flowchart illustrating the communication methods described herein. [Figure 6] This diagram shows a schematic flowchart illustrating the communication methods described herein. [Figure 7] This diagram shows a schematic flowchart illustrating the communication methods described herein. [Figure 8]

[0012] This diagram schematically illustrates one embodiment of a low-power wireless medical device that operates in conjunction with a header insertion device to reduce the power consumption of the wireless medical device. The medical device is a gateway device equipped with a BLE radio and functionality to operate as a GAP peripheral with IPSP support, while the header insertion device is a gateway device equipped with a BLE radio and functionality to operate as a GAP central with IPSP support. [Modes for carrying out the invention]

[0011]

[0013] An IPv6 address is 128 bits long. Each header is at least 40 bytes long, as every IPv6 frame header contains the source and destination addresses, along with several other header attributes such as payload length, version, and hop limits. Furthermore, if UDP or TCP transport protocol headers must also be included, this means an additional 8 bytes and 20 bytes, respectively. This results in significant overhead in the payload of a BLE packet data unit (PDU), particularly in the case of BLE sensor devices where the data payload is typically very small (e.g., temperature readings in Celsius / Fahrenheit, heart rate in pulses per minute). Therefore, RFC7668 requires that all headers be compressed according to the encoding format described in RFC6282. A border router (or other suitable device such as a smartphone, tablet, or bedside monitor) expands the compressed headers back to their full headers before forwarding the frame to its destination. This is known as the IP Header Compression (IPHC) format and significantly reduces the IPv6 header size. An IPv6 address consists of a 64-bit network address (prefix) and a 64-bit interface address (IID). Generally, the IPv6 address space is divided globally (in order) into registry, ISP prefix, site prefix, subnet prefix, and interface ID. Generally, a single subnet has enough address space to cover a large number of devices (e.g., 2 64 It should be sufficient to cover any large company or organization and assign a unique global address to any device, with room for growth. A large hospital may be easily covered by a single subnet, but it would be desirable to deploy two or more subnets, for example, one subnet for the internal clinical device network and another subnet for providing internet access to guests and / or patients.

[0012]

[0014] In addition to global addresses, every device also has a link-local address, which can be used for one-hop communication (e.g., in small networks). For IPv6 header compression, global and link-local addresses are distinguished. If an IPv6 link-local address can be used for both source and destination, and the local interface address can be derived from the device address (i.e., stateless address configuration), the compressed IPv6 header size is reduced to just 2 bytes. If the source and destination addresses belong to the same IPv6 subnet, and the subnet prefix is ​​available from the context table, the prefix is ​​omitted, and the header size is reduced from 40 bytes to 19 bytes (or to fewer bytes if the IID can be compressed, e.g., if the source or destination address is a link-local address). For non-link-local IPv6 addresses, neighbor discovery (ND) is required, and a context table or routing table must be maintained. These context tables differ for the source address prefix and the destination address prefix.

[0013]

[0015] When User Datagram Protocol (UDP) is used as the transport protocol for an application, the UDP header is also compressed from 8 bytes to a minimum of 2 bytes. In some examples of IPHC compressed headers for UDP over IPv6, the IPHC compressed header is 6 bytes, 8 bytes, or 13 bytes.

[0014]

[0016] Devices generally have a global address assigned by the network using a dynamic host configuration protocol, such as DHCPv6. However, if a device is mobile, it may need to switch to a different subnet or site, or even a different Internet Service Provider (ISP). For example, if a mobile device leaves a hospital, it switches from the hospital's BLE radio to a cellular network. In such cases, the IPv6 source address to be used during communication changes with the subnet, site, or ISP. To facilitate the mobility of IPv6 devices, several standards have been created, including Mobile IPv6, Proxy Mobile IPv6, and Hierarchical Mobile IPv6 (HMIPv6) Mobility Management. Technologies such as NPTv6 also help here to provide stateless translation from the network prefix portion of an IPv6 address to another, such as a global network prefix. Two prefix converters within two networks can be configured equivalently, or traffic from the two networks can converge at an encompassing edge router, perform NPTv6 or NAT64 translation, and produce the same IP address to the outside world. NPTv6 is considered the successor to NAT44 (Network Address Translation from IPv4 to IPv4), which translated IP addresses from one IPv4 address space to another, primarily due to the limited IPv4 address space. In the case of IPv6, network address translation is therefore generally no longer necessary due to the vast address space, but the idea is that it will be used for a while to translate from IPv6 to IPv4 and vice versa.

[0015]

[0017] Supporting mobility is crucial in mobile medical devices. For example, in the case of a BLE healthcare sensor, a typical scenario is that the sensor initially connects to a bedside monitor, but as the patient is moved or walks around the hospital, the sensor switches its connection from the bedside monitor to BLE access points (APs) throughout the hall, and possibly to several other APs along the way. The same sensor is also used when the patient leaves the hospital, in which case the sensor connects to a BLE home gateway when the patient arrives home. All these devices that a BLE healthcare sensor connects to during its lifespan give different characteristics in terms of support for advanced routing features and in terms of trustworthiness (e.g., whether they are from the same manufacturer or from a competing manufacturer). In particular, with respect to Bluetooth® and some other wireless protocols, the devices that a BLE healthcare sensor connects to are not always trustworthy.

[0016]

[0018] RFC 7668 and the Bluetooth® White Paper, 2017, “Internet Gateways,” describe BLE gateways along with Bluetooth® IP native 6LoBTLE nodes. While IPv6 provides a common addressing mechanism for any device anywhere, and the IPHC header compression format was standardized in the cited literature, these methods lead to unnecessary power consumption. This is because, for all the methods described above (IPv6 header compression, mobile IPv6 (normal and tiered), proxy mobile IPv6), the IP stack is expected to be active on the 6LoBTLE node, requiring transmit power to send the compressed IPv6 header as described below. This is partly based on the assumption that devices want to have common IP support because they can reach various destinations (e.g., a mobile phone is used to browse the web). However, this is not true for sensor devices that simply send their data to a given destination server.

[0017]

[0019] Furthermore, IPv6 headers still introduce significant message overhead, even with compressed source and destination addresses, especially for messages with small payloads. For example, if a BLE sensor device wants to send its sensor data to a routable address (outside the link-local one-hop range), such as a centralized sensor aggregation device or a cloud server on the internet, the IPv6 header is at least 10 bytes long (in order: 1 byte for the dispatch header field, 2 bytes for the IPHC header field, 1 byte for the context ID header field, 2 bytes for the Dst Comp IID header field, 1 byte for the NHC_UDP header field, 1 byte for the UDP port header field, and 2 bytes for the checksum header field), assuming the border router has the destination address prefix registered in its context table. Further reduction of this overhead would be beneficial in low-energy operation.

[0018]

[0020] In two-way communication, the global source address must be used instead of the link-local address, resulting in at least two additional bytes. For mobile IPv6 (standard and hierarchical mobile IP), BLE sensor devices even need to perform IPv6 packet encapsulation within the sensor device itself, thereby requiring the sensor device to be aware of its care of address, home agent (HA), or mobility anchor point (MAP) address in order to enable packet encapsulation. This results in multiple IPv6 addresses being included in each packet, leading to larger packets and therefore additional overhead on non-mobile IPv6 solutions.

[0019]

[0021] In the embodiments disclosed herein, the BLE device can use upper layer protocols such as IPv6 and CoAP for its communication, including end-to-end encryption of the payload, while reducing communication overhead and the overhead of IP packet processing and compression, and thus power consumption. This is done by omitting the transmission of the IPv6 header and UDP / TCP headers when not needed, after the BLE device has dynamically discovered that another BLE device (e.g., a BLE access point or gateway) can perform IPv6 header insertion on behalf of the BLE device. By doing this dynamically, the disclosed approach supports mobility and enables roaming from one access point to another, inside or outside the local network, while applying the proposed power optimization whenever appropriate.

[0020]

[0022] End-to-end encryption and / or mutual authentication are crucial for the communication of medical data. In end-to-end encryption, a password, passcode, or other secret is shared between the BLE sensor and the destination server, and the secret is used to derive a key for encrypting the data. In mutual authentication, the knowledge of the shared secret between the BLE sensor and the destination server, which is used to derive a key for encrypting the data, is verified. However, with BLE, the security implemented between devices is lacking, for example, when "Just-works" pairing is used. This is a problem in a medical context because, in a healthcare environment, patient medical data should not fall into the wrong hands and should be delivered in a trusted manner to the appropriate destination (e.g., a hospital server computer hosting electronic medical or health records, a nurse station computer, etc.). To provide a sufficient level of security, the entire network path from the sensor to the server should be considered secure (for example, by using an IPSec authentication header in communication to / from the server to ensure that the IP layer fields have not been tampered with, or by using other mechanisms to verify that the intermediate node is trustworthy, such as by proving knowledge of a shared secret). Preferably, the sensor can verify whether the data has been received correctly using an end-to-end encrypted acknowledgment (for example, using an encrypted COAP acknowledgment or an HTTP200 OK message), so that the sensor can either securely send the data to the server or disconnect. In the case of a BLE actuator device that administers medical therapy to a patient, secure communication between the actuator device and the server device that controls the actuator device must be trustworthy to ensure patient safety.

[0021]

[0023] The embodiments disclosed herein provide an additional mechanism for reducing the power consumption of BLE - equipped medical devices (e.g., vital - sign sensor devices, actuator devices, etc.) by having the BLE access point / gateway filter them without the need to decrypt end - to - end encrypted messages. This results in a reduction in the traffic volume between the BLE sensor / actuator and the BLE access point / gateway, enabling an increase in the sleep time during the listen intervals, and thus reducing the power consumption while keeping the communication secure and reliable. Also, these benefits are achieved while supporting roaming such that the BLE device can flexibly connect to different devices along the way, e.g., another BLE access point in a hospital, a mobile phone, a bedside monitor, or a home gateway when the patient arrives home while wearing the same sensor.

[0022]

[0024] Referring to Figures 1 and 2, an exemplary embodiment includes a wireless medical device S (e.g., a medical sensor or actuator) mounted to perform a medical function F. Device S is equipped with storage for storing an IPv6 address and / or other header information A that uniquely identifies Device S in a wireless communication network (e.g., a Bluetooth® network), thereby Device S is further equipped with a Bluetooth® low-energy (BLE) radio R used to form a communication link L with Device T. As shown in Figure 2, at 10, when device T receives a message W from device T via communication link L indicating that device T is capable of performing IPv6 header insertion on behalf of wireless medical device S, device S sends header information A to device T using header information message X at 12, and at 14, device S switches to a mode in which device S sends its data via BLE communication link L by including its data as part of messages M0...Mn, where messages M0...Mn do not include IPv6 headers as part of these messages (however, messages M0...Mn do include other header information such as PHY / MAC headers). Device T receives a header information message X, stores a copy of the received header information A' from Device S, and then, upon receiving messages M0...Mn, performs a header insertion function I in 16 to insert the header information A' into messages M0...Mn, completing the headers and creating corresponding valid IPv6 messages with the received header information A' (or a copy thereof) inserted into the IPv6 message headers of these messages, and retransmits the messages with the inserted header information via BLE as messages M0'...Mn', each with a valid IPv6 header. Message X includes a source IPv6 address (or part thereof), a destination IPv6 address (or part thereof), a value for the traffic class, and / or an extension header, which may be used by Device T to construct the valid IPv6 headers of messages M0'...Mn'.Other fields in the IPv6 header to be constructed by device T for messages M0'...Mn', such as the payload length, can be derived from the payload length shown in the Layer 2 header within messages M0...Mn. Other fields, such as the version and hop limit fields, can be filled with default values, i.e., a value of 6 for the version and a value of 255 for the hop limit.

[0023]

[0025] Conversely, as shown in Figure 3, if at 20 the wireless medical device S does not receive a message from device T via the communication link indicating that device T is capable of performing header insertion on behalf of device S (or if it receives a message from device T indicating that it will no longer perform the header information insertion service I), then at 24 the wireless medical device S switches (or switches again) to a mode in which it sends data from device S, including the full header or a header-compressed IPv6 header, as IPv6 messages N1...Nn via the BLE communication link.

[0024]

[0026] Therefore, it can be seen that device T may be called relay device T, or header insertion device T, or similar names. It will be understood that device T is preferably a device whose power consumption is less critical compared to wireless medical device S. The power-consuming process of adding and transmitting headers is no longer performed by wireless medical device S, which is desired to be a low-power device, and is instead performed by header insertion device T, which does not need to have an equally low power consumption. For this purpose, device S only needs to send a message X containing header information, such as a source IPv6 address or destination IPv6 address, to be used by relay device T, in order to initiate the transition to this low-power operating mode, in which device S no longer needs to send IPv6 header information.

[0025]

[0027] The wireless medical device S comprises components (not shown) such as a microprocessor, microcontroller, field-programmable gate array (FPGA), graphics processing unit (GPU), or other programmable electronic chip (optionally including a multicore, numerical coprocessor, or otherwise enhanced), and a non-temporary storage medium that stores instructions readable and executable by the programmable electronic chip, for performing functions related to performing medical functions F as disclosed herein and for performing wireless communication with a BLE radio R. The non-temporary storage medium includes (as non-limiting exemplary examples) flash memory, read-only memory (ROM), electronically erasable programmable ROM (EEPROM) or a variation thereof, and / or magnetic storage medium (e.g., hard disk), optical storage medium (e.g., optical disc), and various combinations thereof. The medical functions F performed by the mobile medical device S are determined by the type of device, and the device S comprises additional components as appropriate for performing medical resources or functions F. For example, in the case of a medical device S that includes an infusion pump, the device S includes suitable pump hardware and a flow sensor, etc., and the medical resource or function F includes functions such as controlling intravenous (IV) fluid flow, measuring IV fluid flow, and measuring the temperature of the IV fluid, and the programmable electronic chip is programmed to perform the medical resource or function F, which includes operating the pump based on flow feedback from a flow meter to deliver a controlled flow of IV fluid, and optionally other related functions such as monitoring the IV fluid temperature. In another example, if the wireless medical device S includes a vital signs sensor, the device S preferably further includes sensor hardware (e.g., EGC, EEG, or HR monitor electrodes, blood pressure cuff, and inflation pump hardware, etc.), and the programmable electronic chip is programmed to perform the medical resource or function F, which includes operating the sensor hardware to acquire vital signs data.These are merely non-exclusive illustrative examples; more generally, a wireless medical device S is configured to provide, in some cases, a desired (one or more) medical function F. Furthermore, it is intended that the device S is a device for performing non-medical tasks in the context of non-medical applications.

[0026]

[0028] Device T comprises components (not shown) such as a BLE radio similar to the radio R of Device S, a microprocessor, microcontroller, FPGA, GPU, or other programmable electronic chip (optionally including multicore, numerical coprocessor, or otherwise enhanced), and a non-temporary storage medium that stores instructions readable and executable by the programmable electronic chip of Device T, in order to perform the header insertion service I and other functions that Device T normally performs. For example, Device T is a wireless access point (AP) and therefore includes programming for its purpose, or other mobile devices such as a cellular phone, a tablet computer, or a general-purpose operating system (e.g., Android or iOS operating system) and various application programs ("apps") loaded on a mobile device. The non-temporary storage medium of Device T also comprises (as non-limiting illustrative examples) flash memory, read-only memory (ROM), electronically erasable programmable ROM (EEPROM) or variations thereof, and / or magnetic storage medium (e.g., hard disk), optical storage medium (e.g., optical disc), various combinations thereof, etc.

[0027]

[0029] Server C can be a single server computer, a cluster of server computers that are interconnected in an operational manner, or cloud computing resources where computers are interconnected in an ad-hoc manner.

[0028]

[0030] In a further optional aspect, the payload Px (0 ≤ x ≤ n) of message Mx is encrypted by wireless medical device S, and a header insertion service I performed by device T includes the exact same payload Px as part of message Mx' without decryption / re-encryption.

[0029]

[0031] In a further optional embodiment, message X includes an IPv6 address and parameters related to a network transport protocol such as UDP / TCP (e.g., destination port), where the address is the global unicast IPv6 address of server C (optionally a cloud server), and device T sets up a UDP / TCP connection to server C based on the received parameters, thereby device T includes that address as the destination address as part of the inserted header information A' in device T's IPv6 message, thereby device S does not include either the IPv6 header or the UDP / TCP header as part of messages M0...Mn.

[0030]

[0032] Referring to Figure 1 and further to Figure 4, in a further optional embodiment (which may be performed regardless of whether device T provides a header insertion service), device S may, in 30, send a request to device T to reduce the rate at which application-level transport acknowledgments are received (for example, after receiving the first correct end-to-end encrypted application-level transport acknowledgment itself) using message Y (which is optionally part of message X), thereby including criteria for how to detect an end-to-end encrypted application-level transport acknowledgment, i.e., message Y includes acknowledgment detection criteria, such as a general message size, the communication protocol used, the message type, or other packet header information, or in other embodiments, a hash, bit pattern, CRC, or key indicating the acknowledgment. The criteria include the type of security algorithm / protocol used to encrypt the acknowledgments, such as words, regular expressions, or deep packet inspection rule sets (optionally extended with keys, or other knowledge such as seeds, counters, homomorphic key information to partially or entirely decrypt the encrypted messages), and then device T applies this criterion to filter these messages received from server C in 32, and device S forwards these encrypted acknowledgment messages to wireless device S in 34 at a reduced rate (e.g., by discarding half of the messages) to allow for further power reduction in device S by synchronizing its sleep / wake cycle with the reduced rate at which relay device T forwards the filtered acknowledgments to wireless device S. Generally, application-level transport acknowledgments are considered any type of acknowledgment for protocols above the IP layer (OSI layer 3), and therefore include TCP-level acknowledgments, CoAP message acknowledgments, HTTP message acknowledgments (e.g., HTTP200 OK success status acknowledgments), application-specific acknowledgments, etc.The acknowledgment message is encrypted using OSCoAP, DTLS, HTTP SSL / TLS, MQTT SSL / TLS, several IPSec options, public-key cryptography / Diffie-Hellman, AES / DES encryption, homomorphic key cryptography, deep packet inspection encryption, etc. Therefore, device T must employ deep packet inspection techniques (e.g., based on heuristics), for example, employing bit pattern or regular expression matching techniques, calculating and comparing encrypted and unencrypted hashes, using knowledge of the communication protocols being used and their general communication patterns (e.g., what types of messages sent to the server lead to an acknowledgment being sent as a reply message), preferably using knowledge of the security / encryption techniques being used without relay device T possessing knowledge of the decryption key related to decrypting the message. In addition to the reference information received from device S, device T also optionally receives information from the server to further assist in acknowledgment detection and filtering. Device T sets up a separate communication channel with the server to request notification whenever an acknowledgment is sent, for example, to receive message counter or header information, which Device T can use to identify and distinguish acknowledgment messages from other messages. In some embodiments, the reduced rate included in message Y is specified as the rate at which the relay device discards acknowledgments received from a server that meet the acknowledgment detection criteria. In some embodiments, the reduced rate included in message Y is specified as the maximum time at which the relay device discards acknowledgments received from a server that meet the acknowledgment detection criteria. For example, the reduced rate may be specified as a percentage or integer indicating the number of acknowledgments to be discarded before the next acknowledgment is forwarded to wireless device S, or the reduced rate may be specified as the number of acknowledgments per unit of time.Generally, relay devices forward filtered acknowledgments to wireless device S at a reduced rate by not forwarding discarded acknowledgments to wireless device S.

[0031]

[0033] In a further optional aspect, if wireless medical device S does not receive application-level transport acknowledgments for a certain period of time, device S triggers audio / visual feedback indicating that device S has a problem connecting to the backend server C. Generally, if device S does not receive these acknowledgments, this is either because the communication path to the destination has been interrupted, or because device T is a malicious device that deliberately discards messages from medical device S. This mechanism prevents a malicious device from simply discarding messages without being able to detect that device S is doing something wrong.

[0032]

[0034] However, it should be noted that if the medical device S is an actuator, device S cannot be certain that it has not deliberately discarded messages from the server controlling it, since it does not know for sure which incoming messages it should expect. To address this, the actuator device preferably has an additional level of trust in device T (for example, by verifying whether device T has knowledge of a particular pre-shared secret, whether device T possesses a private key belonging to a public key that proves this, or whether device T has sent a public key certificate signed by a trusted certificate authority) before allowing device T to perform a header insertion (and optional UDP / TCP transport) service I on behalf of device S. Alternatively, the application-level protocol may provide a mechanism by which device S can periodically check with server C to determine whether server C has sent a message to device S within a given time period (therefore server C can repeat the messages it has sent to device S).

[0033]

[0035] In a further optional aspect, device T measures the round-trip time for message Mx'(0≦x≦n) to the destination address of server C, sends this information to device S using a further message, and device S then adjusts its sleep / wake schedule and / or the rate at which it sends messages M0...Mn based on the received round-trip time.

[0034]

[0036] In a further optional embodiment, device T sends UDP / TCP port information of a port opened on device T to device S in order to receive incoming messages from server C, and device S stores this information. If device S connects to a device U (not shown), device S sends this UDP / TCP port information to device U along with the source IPv6 address, destination IPv6 address, and destination UDP / TCP port to device U, and device U uses this UDP / TCP port information to set up a source port for incoming UDP / TCP traffic coming from server C.

[0035]

[0037] In a further optional embodiment, the header information A of device S (and a copy A' of it in relay device T) includes a securely hashed / encrypted sensor ID. This reduces the amount of application layer data to be sent, as sensor identification can be done directly from the source address. The output of securely hashing or encrypting the sensor ID can be used within the 64-bit IID portion of the IPv6 address (a larger portion of the IPv6 address could be used, but this would lead to routerability issues, as in the case of a 128-bit ORCHID IPv6 identifier, for example). This technique assumes that the ecosystem of devices capable of connecting to a server operates with a sensor ID address space of less than or equal to 64 bits.

[0036]

[0038] In the embodiment shown in Figure 4, power savings in the wireless device S are achieved by reducing the rate at which acknowledgments are forwarded to the wireless device S. This is done by receiving a message Y from the wireless device S, where message Y includes a request that acknowledgments received from a server at the relay device T should be sent to the wireless device S at a reduced rate, and by receiving message Y, which further includes an acknowledgment detection criterion, applying the acknowledgment detection criterion to filter the acknowledgments received from the server, and forwarding the filtered acknowledgments to the wireless device (S) via the radio at a reduced rate. More generally, it is intended that this process be employed to forward other types of messages at a reduced rate. For example, the disclosed technique is used to forward non-acknowledgment response messages or server-initiated messages at a reduced rate. In the generalized case, the relay device T receives message Y from the wireless device S, where message Y includes a request that messages of a message type received from a server at the relay device T should be sent to the wireless device S at a reduced rate. Message Y further includes a detection criterion for detecting messages of that message type. Relay device T applies the detection criterion to filter messages of that message type received from the server and forwards the filtered messages of that message type to wireless device S via the radio at a reduced rate.Similarly, detection criteria include the general message size for messages of that message type, the communication protocol used, message type or other packet header information, hashes or bit patterns, CRC, keywords, regular expressions or deep packet inspection rule sets that identify messages of that message type, and / or the type of security algorithm / protocol used to encrypt messages of that message type (optionally extended with keys or other knowledge such as seeds, counters, homomorphic key information for partially or entirely decrypting encrypted messages).

[0037]

[0039] Referring to Figure 1 and further to Figure 5, in a further optional embodiment, wireless medical device S exchanges a certificate with device T at 40 (e.g., using a Diffie-Hellman exchange), and at 42 determines whether device T has knowledge of a specific pre-shared secret (e.g., common to devices of a certain manufacturer). If device T has such knowledge, device S sends message Z (not shown; optionally message X or Y) to device T at 44, the message relating to a higher-layer transport protocol (such as HTTP, CoAP, MQTT) that device T should use to communicate with server C. The message includes parameters (such as the destination URI of the server resource, and the REST action to take, such as GET or POST), and in 46, if device T supports this upper layer transport protocol, device S switches to a certain mode in 48, thereby device S sends data in messages M1...Mn over the Bluetooth® low energy communication link, and messages M1...Mn do not include IPv6 headers, UDP / TCP port information, and upper layer transport headers (such as HTTP, CoAP, MQTT headers) in order to enable further power reduction in device S.

[0038]

[0040] In a further optional aspect, device T dynamically selects a transport protocol based on which protocols are declared to be supported by server C.

[0039]

[0041] In a further optional embodiment, device S receives a message from device T indicating an error from the upper-layer transport protocol. This device uses this information for audio / visual feedback that device S is having a problem connecting to the backend server C.

[0040]

[0042] Referring to Figure 1 and further to Figure 6, in a further optional embodiment, device S and / or device T determine at 50 that the quality of the link between the two devices is degrading (for example, based on measuring the RSSI) or that another device U is in a much closer vicinity to device S and takes over the connection with device S (i.e., device S roams from device T to device U), and thereafter, device S sends a message to device T at 52 to stop sending messages on behalf of device S in order to avoid confusion if the remaining messages (e.g., retry messages or incoming messages from server C) are still being actively processed by device T while device S is already connected to server C via device U. When device S is connected at 54 via the new device U (i.e., device S has roamed to the new device U), device S at 56 asks device T (via device U) whether any messages have arrived in the meantime, or alternatively, asks server C to resend a small number of recent messages.

[0041]

[0043] Referring to Figure 1 and further to Figure 7, in a further optional embodiment, wireless medical device S exchanges certificates with device T (e.g., using a Diffie-Hellman exchange) in 60, and in 62 determines whether device T has knowledge of a pre-shared secret that forms the basis of end-to-end encryption between device S and server C (e.g., whether S, T, and C are in the same security domain certified by the same manufacturer or certification authority), and if device T has that knowledge, device S sends message Q (or part of messages X, Y, Z) to device T in 64, which triggers when device T will perform end-to-end encryption of payload Px in message Mx'(0≦x≦n), and in 66, if supported by device T, device S switches to a mode in which device S does not perform end-to-end encryption of payload Px contained in message Mx(0≦x≦n).

[0042]

[0044] Referring to Figure 8, in a particular exemplary embodiment, wireless medical device S incorporates a BLE radio and functionality to operate as a GAP perimeter with IP Support Services (IPSS) support. Device S further incorporates functionality to operate as a 6LowPAN (6LoBTLE) node for BLE. Device T is a gateway device incorporating a BLE radio and functionality to operate as a GAP central with IP Support Profile (IPSP) support. Device T further incorporates functionality to operate as a 6LowPAN (6LoBTLE) boundary router for BLE. Medical device S is generally extremely power-limited and operates on a button battery, while relay device T is generally a power supply device (although other types of devices such as cell phones or tablet computers are also intended). This architecture has several advantages over classic GATT-based architectures, as the 6LowPAN architecture for BLE generally allows for long sleep periods in BLE sensor devices, so that a sensor can only wake up its radio when it has new data to send.

[0043]

[0045] To establish a connection between device S and device T, the GAP peripheral function on device S is used to advertise its presence to nearby BLE devices. The GAP central function on device T detects these advertisement packets and initiates the link layer connection setup between the two BLE devices by sending a CONNECT_IND PDU via the BLE radio. After the link is established, the devices perform a pairing procedure, establishing a data communication connection between device S and device T, thereby allowing both devices to operate the BLE transport layer using the Logical Link Control and Adaptive Protocol (L2CAP) with the additional requirement of IPSP. Alternatively, these roles can be swapped, so that device S acts as the GAP central with IPSP support and device T acts as the GAP peripheral with IPSP support, setting up the L2CAP connection in a similar manner.

[0044]

[0046] The explanation presented here adopts the Open System Interconnection (OSI) model, which includes the Physical Layer (Layer 1), Data Link Layer (Layer 2), Network Layer (Layer 3), Transport Layer (Layer 4), Session Layer (Layer 5), Presentation Layer (Layer 6), and Application Layer (Layer 7). In the IEEE 802 standard, the Physical Layer includes the Physical Layer Convergence Procedure (PLCP) sublayer and the Physical Medium Dependency (PMD) sublayer, while the Data Link Layer (Layer 2) includes the Logical Link Control (LLC) layer and the Layer 2 Medium Access Control (MAC) layer. The Network Layer (Layer 3) is considered the IP layer, where each IP packet is encapsulated within a Layer 2 MAC frame. In Bluetooth®, the PHY layer includes the RF and baseband components, while the Layer 2 MAC includes the L2CAP layer and the Link Manager layer. The BLE packet data structure includes (in order) a preamble (1 byte), an access address (4 bytes), a protocol data unit (PDU) of 2 to 257 bytes, and a CRC (3 bytes). A PDU comprises either a data channel PDU including (in order) a PDU header (2 bytes), a data payload, and an MIC (4 bytes), or an advertising channel PDU including (in order) a PDU header (2 bytes) and an advertising payload. The data payload generally consists of an L2 cap packet including (in order) an L2 header (4 bytes) and an L2 payload (up to 247 bytes). In Bluetooth®, the IP layer (Layer 3) is generally encapsulated within the L2 payload of the L2 cap packet. An IP packet within the IP layer has an IPv6 packet structure including (in order) an IPv6 header and (in order) a payload including an extension header and an upper-layer PDU. In Long-Term Evolution (LTE), including its low-power variants, Narrowband Internet of Things (NB-IoT), and LTE for Machines (LTE-M), the data link layer (Layer 2) includes the Packet Data Convergence Protocol (PDCP) layer, the Radio Link Control (RLC) layer, and the MAC layer.The IP layer (Layer 3) is typically encapsulated within the payload of a user-plane PCDP data protocol data unit (PDU).

[0045]

[0047] As a further exemplary embodiment employing the OSI / BLE packet / IPv6 architecture described above, a wireless device S comprises a radio R for communicating via a wireless communication protocol that employs messages constructed as Layer 2 MAC frames, each containing a Layer 2 MAC header and a payload. The wireless device is configured to operate in a first mode, (i) via the radio R, messages N0, ..., Nn, each containing an IPv6 packet header and a higher-layer protocol data unit encapsulated within the payload of a Layer 2 MAC frame, and (ii) via the radio R, messages M0, ..., Mn, each containing a higher-layer protocol data unit encapsulated within the payload of a Layer 2 MAC frame without including an IPv6 header. In a preferred method, the wireless device is configured to transition from the first mode to the second mode by an operation that includes sending a header information message X to a relay device T that provides a header insertion service I. The header information message includes at least the address of the wireless device (A) to be used to construct an IPv6 source address or the address of the host device (D) to be used to construct an IPv6 destination address. The wireless device is preferably configured to transition from a first mode to a second mode by an operation that further includes receiving a message W from a relay device T that triggers the transition from the first mode to the second mode. Note that the message W also includes information about a subnet or routing prefix that can be used by device S to select different destination servers, e.g., an in-hospital server versus a cloud server. If the IP address of the destination server changes over time, device S will need to resolve the IP address of the destination server from time to time, for example, by contacting a Domain Name Server (DNS) with the fully qualified domain name, or by using ping with the NetBIOS name.

[0046]

[0048] Relay device T comprises a radio for communicating via a wireless communication protocol that employs messages constructed as Layer 2 MAC frames, each containing a Layer 2 MAC header and a payload. Relay device T is configured to perform a header insertion service I, in which the relay device receives messages M0, ..., Mn from wireless device S via its radio, each containing upper-layer protocol data units encapsulated within the payload of a Layer 2 MAC frame without including an IPv6 header. Header insertion service I inserts header information A' into the messages M0, ..., Mn received from wireless device S and retransmits the messages with complete headers as messages M0', ..., Mn'. Relay device T receives a header information message X from wireless device S and is configured to store the header information contained in the header information message as header information A'. Relay device T is further configured to send a message W to wireless device S to notify wireless device S of the availability of relay device T to perform the header insertion service I for wireless device S.

[0047]

[0049] The system preferably comprises a wireless device S and a relay device T as described in the preceding two paragraphs. In a system comprising such a wireless device S, a relay device T, or both devices S and T, the wireless communication protocol is preferably Bluetooth® Low Energy (BLE), but other wireless communication protocols are also contemplated. Optionally, messages M0, ..., Mn are encrypted by the wireless device S, and the relay device T includes the exact same content of messages M0, ..., Mn in messages M0', ..., Mn' without decryption / re-encryption.

[0048]

[0050] To enable the dynamic discovery and configuration of IPv6 header insertion features and / or acknowledgment reduction features, both device S and device T must indicate support for these features. Indication of the ability of IPv6 header insertion features and / or acknowledgment reduction features may be sent as part of the advertisement data in BLE advertisement messages and / or scan request / response (e.g., additional fields or further parts of the advertisement payload). These messages may also be used by device T to include (one or more) IPv6 addresses stored in device S that should be used as source and / or destination by device T, and / or to include the message size, hash or bit pattern used by device T for discovery of acknowledgment messages from destination servers, and a rate indicator of whether device T should send an acknowledgment to device S. This information is also communicated using separate L2CAP or GATT messages. Alternatively, the IPv6 neighbor discovery protocols specified in RFC6775 and 7668 may be leveraged, for example, by using an extended neighbor solicitation message that uses an address registration option (ARO) to send and register source IP addresses at a gateway device, which is extended with additional fields / parameters to indicate to the gateway device that it should use an IP header insertion feature instead of IP header compression (in which case device S includes a compressed IPv6 header in message N0...Nn) or transparent relay (in which case device S includes a full IPv6 header in message N0...Nn). These messages are then used as a trigger for device T to switch modes to insert (one or more) received IPv6 addresses as part of outgoing message M0'...Mn' and / or to begin filtering acknowledgments.A response message received by device S as a result of sending one of the above messages to device T may be used as a trigger to switch modes in device S so as not to send the IPv6 header as part of message M0...Mn, and / or to adapt device S's sleep pattern based on the rate at which device S can expect to receive an acknowledgment from the server relayed through device T.

[0049]

[0051] Device S has some non-temporary storage for storing one or more IPv6 addresses, such as an IPv6 source address (which is either from a DHCPv6 server or locally generated based on subnet information received from Device T) or an IPv6 destination address (e.g., the IP address of a backend server configured via NFC). Note that if Device S detects that the subnet of Device T is different from the subnet of a stored IPv6 source address, Device S will generally update its IPv6 source address. These IP addresses may be set or retrieved using one or more additional interface functions or configurations to the sensor and stored locally in Device S. Locally stored IP addresses may be used to notify or update Device T, which exposes Device S to the IP network by performing IPv6 header insertion based on the complete IPv6 address. Updating IP addresses to or from sensor nodes is only necessary when the address context of the sensor network changes, which is expected to be a rare event and therefore imposes minimal overhead.

[0050]

[0052] Higher-layer transport protocols include, but are not limited to, standards such as CoAP, MQTT, and HTTP. They also include other protocols such as IEEE 11073-20601, which directly circulate TCP, FTP, RTSP, XMPP, MLLP, etc. For the remainder of this specification, these protocols, i.e., protocols operating above the IPv6 layer, will be referred to as application-layer protocols. However, for low-power sensors, application-layer transport protocols appear to converge on CoAP, MQTT, and HTTP REST, because many data formats (e.g., FHIR / HL7 data model, OCF data model, IEEE 11073-based data model, custom JSON-based data model) are mapped over these application transport protocols for transport.

[0051]

[0053] Most application layer protocols require a communication channel to support bidirectional communication in order to receive response messages / acknowledgments. Typically, this is a request / response mechanism and therefore only covers short time intervals. Also, some application protocols allow bidirectional asynchronous communication, such as MQTT subscribers or CoAP observers. Similarly, using protocols such as IEEE11073-20601 over TCP directly requires bidirectional communication to enable manager-initiated measurement data transmission, such as scan requests. This means that the BLE sensor needs to keep a UDP or TCP port open on the device. In the proposed solution, this is now handled by device T, which can receive messages from the server on behalf of device S, buffer the messages, and send them to device S in its next wake-up schedule. This increases the power efficiency of device S because it can reduce the time device S spends listening for incoming messages. To enable this, device T keeps a UDP or TCP port open for each connected device S. Device T can distinguish traffic for each of these UDP ports by maintaining a virtual NIC for each IPv6 address of each connected device S (i.e., using multihoming software).

[0052]

[0054] The IP address used by a BLE sensor to subscribe to an MQTT broker or CoAP server should not change during roaming, or at least should not change frequently, because this would interrupt any current subscriptions or communication sessions that would need to be restarted. In the case of IPv6, the IP address rarely needs to change. Therefore, if device S roams from access point T to access point U, and after connecting to access point U, device S sends its stored IPv6 source and destination addresses to device U, device U can set up a UDP / TCP connection to the destination address and set up its UDP / TCP port to receive incoming messages. According to one embodiment, if device S receives UDP / TCP incoming port information from device T and passes this information to device U, device U can then take over for device S with the exact same IP address and incoming UDP / TCP port and begin sending messages. To server C, nothing appears to have changed, and therefore any ongoing MQTT subscriptions or COAP observer registrations continue to function. Device U sends a message to update its routing table in the network and now refers to itself, and no longer needs to refer to device T (for example, by using a neighbor discovery protocol). Device U communicates with device T, or device S itself communicates with device T via device U, for example, to ask if a message has arrived for device S in the meantime. Alternatively, some application-level retry mechanism is used by device S (for example, by asking a server to resend a few recent messages). After device T discovers that device S has disconnected (after a certain amount of time, or after receiving a message from device U), device T can clean up its resources for device S.

[0053]

[0055] BLE actuator devices face a similar problem because they must be reachable and remain reachable to the server controlling them. To ensure the device remains reachable, the actuator device periodically sends some message (e.g., a keep-alive message) to the server to keep the routing tables in intermediate nodes along the path to the server and the IP address / port information of device S at the server up to date. Alternatively, to resolve addressability from the server, a home address is registered with a mobile IP home agent or mobility anchor point (MAP). Similarly, if the IPv6 address is globally addressable, the intermediate router or home agent / mobile anchor point needs to be aware of the new route after it connects to another access point. Registering the home address after roaming from access point T to access point U can be done by access point U on behalf of the BLE actuator.

[0054]

[0056] After it is determined that device T supports the requested capabilities and that device S has performed a mode switch, device S sends messages M0...M1 directly over the L2CAP connection, thereby device S secures the application-level transport using application-level authentication and / or end-to-end encryption, which can be achieved using, for example, OSCoAP, DTLS, HTTP SSL / TLS, MQTT SSL / TLS, several IPSec options, public key cryptography / Diffie-Hellman, AES / DES encryption, etc.

[0055]

[0057] While described in the context of a low-power wireless medical device employing Bluetooth® Low Energy (BLE) communication of messages constructed as IPv6 packets, the disclosed method for operating the low-power wireless medical device S with a relay device T that provides a header insertion service I to the device S to reduce power consumption in the device S will be understood to also be applicable in the context of other wireless communication protocols that employ messages constructed as packets containing a header and payload, respectively, such as WiFi, Narrowband Internet of Things (NB-IoT), Long-Term Evolution (LTE), LTE-M, and 5G new radio. Furthermore, the gateway device may be an access point, a cellular base station, a server in the cloud, or a virtual network function.

[0056]

[0058] In the case of NB-IoT and LTE-M as defined by the Third Generation Partnership Project (3GPP), a similar approach can be achieved, thereby, device S is a device (also called a user device or UE in 3GPP terminology) equipped with an LTE category NB1 / NB2 radio (in the case of NB-IoT) or an LTE category M1 / M2 radio (in the case of LTE-M). Since the packet gateway (P-GW) generally assigns IP addresses to connected UEs (e.g., via DHCP) and provides an interface to the internet, relay device T is preferably a device hosting the P-GW. Alternatively, relay device T is a device in a 4G Advanced Packet Core (EPC) network hosting a serving gateway (S-GW), a mobility management entity (MME), a service capability exposure function (SCEF), or an enode B. In embodiments where device T functions as a P-GW or S-GW, the messages X (for IPv6 header insertion service) and / or Y (for acknowledgment reduction service), sent from device S, are preferably packet data network (PDN) connectivity request messages (encapsulated within an Advanced Packet System (EPS) session management message container as defined in 3GPP TS24.301), and are extended with several additional fields to carry header information (e.g., source address or destination address) to be used by device T's header insertion service, and / or message size, hash or bit pattern to be used by device T for detecting an acknowledgment message from the destination server, and a rate indicator of whether device T should send an acknowledgment to device S. The PDN connectivity request message optionally has additional informational elements, including a boolean flag to indicate that device T should initiate header insertion instead of header compression or transparent relay, and / or a boolean flag to indicate that device T should initiate acknowledgment reduction.Alternatively, in the case of IPv6 header insertion, the PDN type information element is set to the value "Non-IP" as a trigger for device T to initiate header insertion (Note: Generally, when the value is "Non-IP", device T either assigns an address on behalf of device S or uses its own address as the source address; however, in this invention, device T uses the source address received from device S to construct the IPv6 source address field in the IPv6 header to be sent from device T to the destination server. The same applies to the destination address).

[0057]

[0059] Alternatively, message X or Y is a separate EPS session management (ESM) message sent from device S to device T acting as a P-GW or S-GW. For device T acting as an MME, message X or Y is an EPS mobility management (EMM) or any other network access layer (NAS) message (such as an attach request message), extended with several additional fields to carry header information and / or acknowledgment filtering information / criteria to be used by device T. For device T acting as an enode B, message X is an RRC message, such as a radio resource control (RRC) connection request message, extended with several additional fields to carry header information and / or acknowledgment filtering information / criteria to be used by device T.

[0058]

[0060] A reply message sent by device T to device S in response to message X (for example, a "Default EPS Bearer Context Activation Request" in an attach-to-attach message in response to a PDN connectivity request message, reusing an existing information element in the "Activate Default EPS Bearer Context Request," such as the PDN type value in the PDN address information element, or an additional information element, such as a boolean flag) may be used as message W to trigger device S to switch modes. In the case of the IPv6 header insertion feature, if device S requests a PDN type "non-IP" and receives a reply message containing an ESM cause information element with "Cause #57 - PDN type IPv4v6 only possible," device S does not switch modes and acts by including the full header or header-compressed IPv6 header as part of IPv6 messages N1...Nn. If device T cannot support acknowledgment reduction, similar values ​​are defined for the cause information element.

[0059]

[0061] In the case of NB-IoT and LTE-M, IP messages (N0...Nn) and non-IP messages (M0...Mn) can be sent as payloads of user-plane PCDP data protocol data units, or as payloads of ESM data transport messages when transport is performed via the control plane instead of the user plane.

[0060]

[0062] To enable the dynamic discovery of IPv6 header insertion and / or acknowledgment reduction features, both device S and device T must demonstrate support for these features. Instructions for device S's IPv6 header insertion capability may be sent as part of a UECapabilityInformation RRC message extended with additional indicators, non-essential extensions, or UE-EUTRA-capability fields, or as an additional field in an RRC connectivity request, attach request, PDN connectivity request, or ESM information response message. Instructions for relay device T's IPv6 header insertion or acknowledgment reduction capability may be sent as part of a system information block in a system information message by extending an existing system information block type with additional fields, or by defining an additional system information block type. Alternatively, the instruction may be sent as part of a "default EPS bearer context activation request" or ESM information request message, for example, as an additional field in a protocol configuration option, or as a separate additional information element.

[0061]

[0063] The present invention has been described in relation to preferred embodiments. Anyone who has read and understood the above detailed description will be able to conceive of modifications and alterations. The exemplary embodiments are construed to include such modifications and alterations to the extent that all such modifications and alterations fall within the scope of the appended claims or their equivalents.

Claims

1. A wireless device comprising a radio and an electronic chip for communicating via a wireless communication protocol that employs messages constructed as Layer 2 MAC frames, each containing a Layer 2 MAC header and a payload, The aforementioned electronic chip is (i) The wireless device operates in a first mode in which it transmits a message to a relay device via the radio that includes an IPv6 packet header and a higher layer protocol data unit encapsulated within the payload of a Layer 2 MAC frame, and (ii) the wireless device operates in a second mode in which it transmits a message to a relay device via the radio that includes a higher layer protocol data unit encapsulated within the payload of a Layer 2 MAC frame without including the IPv6 header. Transitioning from the first mode to the second mode by an operation including transmitting a header information message via the radio to the relay device that provides a header insertion service, wherein the header information message includes at least the address of the wireless device to be used to construct an IPv6 source address or the address of a host device to be used to construct an IPv6 destination address. A wireless device programmed to perform the aforementioned action.

2. The wireless device according to claim 1, wherein the wireless device transitions from the first mode to the second mode by an operation further comprising receiving a message from the relay device that triggers the transition from the first mode to the second mode.

3. The wireless device according to claim 1 or 2, further comprising transitioning from the second mode to the first mode in response to the wireless device roaming from the relay device to another relay device different from the relay device.

4. The wireless device according to claim 3, further comprising roaming to the other relay device and querying via the other relay device whether the relay device received a message for the wireless device during the transition.

5. The wireless device according to claim 3, further comprising roaming to the other relay device and requesting a server to retransmit messages for the wireless device through the other relay device.

6. The wireless device according to any one of claims 1 to 5, further comprising roaming between relay devices and switching between the first mode and the second mode depending on whether the relay device to which the wireless device is connected provides the header insertion service.

7. The wireless device according to any one of claims 1 to 6, further comprising: exchanging a certificate with the relay device via the radio; and transitioning from the first mode to the second mode if the wireless device determines, based on the exchanged certificate, that the relay device possesses knowledge of a shared secret.

8. A radio for communication via a wireless communication protocol that employs messages constructed as Layer 2 MAC frames, each containing a Layer 2 MAC header and payload, A relay device comprising an electronic chip, The aforementioned electronic chip is The header insertion service is performed by the relay device receiving a message (M0, ..., Mn) from a wireless device via the radio, each containing a higher-layer protocol data unit encapsulated within the payload of a Layer 2 MAC frame without including an IPv6 header; inserting header information into the message received from the wireless device; and retransmitting the message with a complete header as a message (M0', ..., Mn'). The relay device receives a header information message from the wireless device and uses the header information contained in the header information message as the header information. A relay device programmed to perform the above-mentioned function.

9. The relay device according to claim 8, further comprising the relay device transmitting a message to the wireless device to notify the wireless device of the availability of the relay device to perform the header insertion service for the wireless device.

10. A wireless device according to any one of claims 1 to 7, The relay device according to claim 8 or 9 and A system that includes these features.

11. A wireless device, relay device, or system according to any one of claims 1 to 10, wherein the message (M0, ..., Mn) is encrypted by the wireless device, and the relay device includes in the message (M0', ..., Mn') exactly the same content as the message (M0, ..., Mn) without decryption / re-encryption.

12. The relay device, A radio for communicating with wireless devices via a wireless communication protocol, A relay device comprising an electronic chip, The aforementioned electronic chip is The relay of messages from the wireless device to the server, and the relay of messages from the server to the wireless device, Receiving a message from the wireless device, wherein the message includes a request that messages of a message type received from the server at the relay device should be sent to the wireless device at a reduced rate, and the message further includes a detection criterion for detecting messages of the message type. In order to filter messages of the message type received from the server, the detection criteria are applied, To forward the filtered message of the message type to the wireless device via the radio at the reduced rate. A relay device programmed to perform the above-mentioned function.

13. The relay device according to claim 12, wherein the detection criterion includes a message size criterion.

14. The relay device according to claim 12, wherein the detection criterion comprises a hash or bit pattern criterion.

15. The relay device according to any one of claims 12 to 14, wherein the message type is an affirmative response message type and the detection criterion comprises an affirmative response detection criterion.

16. The relay device according to claim 15, wherein the acknowledgment is an end-to-end encrypted application-level transport acknowledgment sent by the server.

17. The reduced rate included in the message comprises the rate or maximum time at which the relay device discards acknowledgments received from a server that meets the acknowledgment detection criteria. The relay device according to claim 16, wherein the relay device forwards the filtered acknowledgments to the wireless device at the reduced rate by not forwarding discarded acknowledgments to the wireless device.

18. Wireless devices and A relay device according to any one of claims 12 to 17 A system that includes these features.

19. The system according to claim 18, wherein the wireless device exchanges certificates with the relay device via the relay device's radio, and sends a message if the wireless device determines that the relay device has knowledge of a shared secret based on the shared certificates.

20. The system according to claim 18 or 19, wherein the wireless device triggers an audio / visual alert indicating that the wireless device has not received a message of a certain type from the relay device for a predetermined period of time.

21. The system according to any one of claims 18 to 20, wherein the wireless device synchronizes its sleep / wake cycle with a reduced rate at which the relay device forwards the filtered messages of the message type to the wireless device.

22. A step of operating a radio in a wireless device to communicate via a wireless communication protocol that employs a message constructed as a Layer 2 MAC frame, each comprising a Layer 2 MAC header and a payload, wherein the operating step is in a first mode, in which the wireless device transmits a message to a relay device via the radio, each comprising an IPv6 packet header and a higher-layer protocol data unit encapsulated within the payload of the Layer 2 MAC frame, A step of transmitting a header information message via the radio to a relay device that provides a header insertion service, wherein the header information message includes at least the address of the wireless device to be used to construct an IPv6 source address or the address of a host device to be used to construct an IPv6 destination address. A step of transitioning the wireless device from the first mode to the second mode after the step of transmitting the header information message, wherein in the second mode, the wireless device transmits a message to the relay device via the radio, each containing upper-layer protocol data units encapsulated within the payload of a Layer 2 MAC frame without including the IPv6 header. A method having.

23. The wireless device receives a message from the relay device that triggers the steps of transmitting the header information message and transitioning from the first mode to the second mode. The method according to claim 22, further comprising the above.

24. The steps include roaming the wireless device between relay devices, The steps include switching the wireless device between the first mode and the second mode depending on whether the relay device to which the wireless device is connected provides the header insertion service, and The method according to claim 22 or 23, further comprising the above.

25. In a relay device, the step of receiving a header information message from a wireless device, wherein the header information message includes header information; The relay device performs a header insertion service, the header insertion service comprising the steps of: the relay device receiving a message (M0, ..., Mn) from the wireless device via a radio, the message being constructed as a Layer 2 MAC frame each containing a Layer 2 MAC header and a payload, and each message further containing a higher layer protocol data unit encapsulated within the payload of the Layer 2 MAC frame without containing an IPv6 header; The relay device inserts the header information into the message received from the wireless device, The steps include: resending the message with the complete header to the server as a message (M0', ..., Mn'); A method having.

26. The relay device relays messages from the wireless device to the server and relays messages from the server to the wireless device. The relay device receives a message from the wireless device, the message includes a request from the server that an acknowledgment received by the relay device should be sent to the wireless device at a reduced rate, and the message further includes an acknowledgment detection criterion. The relay device includes the step of applying the acknowledgment detection criteria in order to filter the acknowledgment received from the server, The relay device forwards the filtered acknowledgment to the wireless device via the radio at the reduced rate. A method having.

27. The reduced rate included in the message comprises the rate or maximum time at which the relay device discards acknowledgments received from a server that meets the acknowledgment detection criteria. The method according to claim 26, wherein the relay device forwards the filtered acknowledgments to the wireless device at the reduced rate by not forwarding discarded acknowledgments to the wireless device.

Images