Patent Application
20200073452
This disclosure relates to low complexity wireless radio devices configured for machine-to-machine communication, e.g. in the context of Internet of things. In particular, solutions are provided for improved management of such radio devices, to be able to handle situations of interoperability of the radio device.
Wireless network service providers, also referred to as mobile network operators, have been enjoying extensive growth in network user population and subscriptions. The majority of user equipment (“UE”) operating on mobile networks are mobile devices such as mobile phones, tablets, portable computers and the like. Mobile network operators manage cellular networks for providing communication coverage to their subscribers or customers, such as under the Third Generation Partnership Project (“3GPP”) networks commonly referred to as e.g. 3G (such as UMTS) or 4G (such as LTE). In addition to cellular networks, also non-cellular local area networks are frequently operated, such as under the Wireless LAN standard IEEE 802.11 commonly referred to as wifi.
One area of implementation of radio communication relates to machine-to-machine communication (M2M), which typically differs from customary use of radio communication in that no user need to be in active control for setting up or carrying out the communication. A device strictly configured for M2M need as such not even incorporate a user interface, such as a display, keypad, microphone or speaker. M2M communication has, as such, been used extensively already since the introduction of GSM. Various players on the market have also implemented different proprietary systems with Low-Power Wide-Area Networks such as LoRa®, RPMA, and SIGFOX. Recently, however, dedicated technical standards have been developed which are suitable for the purpose of M2M communication. This includes e.g. MTC (Machine Type Communication), for which service requirements have been outlined in 3GPP technical specification 22.368, and is further described in various associated specifications. MTC provides e.g. extended Discontinuous Reception (DRX), with longer sleep cycles optimized for delay-tolerant, device-terminated applications.
Another commitment within 3GPP relates to Narrow-band Internet of Things (NB-IOT). In 2016 3GPP completed the standardization of NB-IoT, the new narrowband radio technology developed for the Internet-of-Things, by accepting a wide number of specification changes implementing the feature of NB-IoT Release 13 (LTE Advanced Pro).
The types of communication systems referred to above are different examples of M2M network solutions, which may be implemented for communication with wireless radio devices. It is believed that the number of wireless devices operating various forms of IoT communication in general, and NB-IoT in particular, will increase rapidly in the near future. Each wireless M2M device may be configured to consume very little power, and may use a built-in battery that may last for months or years without having to be charged or replaced. Such devices may e.g. be used for simple monitoring of sensors and reporting of measurement data from such sensors, such as for electricity gauges, photo sensors, thermometers etc.
A potential problem with operation of low-complexity M2M devices is related to its particular character, namely that it need not have a user interface, or may be provided in a place where it cannot be readily accessed for direct physical access and interaction.
Solutions are provided herein related to configuration and implementation of wireless communications devices operating with M2M communication, and a method for managing such wireless devices. The invention providing these solution is defined by the claims.
According to an aspect, a wireless communications device comprising
In one embodiment, the boot system comprises
In one embodiment, the reset controller is configured to write one or more boot flags in the non-volatile memory dependent on a received reset signal.
In one embodiment, the reset mechanism includes
In one embodiment, the wireless communications device comprises a non-removable battery.
In one embodiment, the reset signal transceiver is configured to detect a reset signal from a wireless charging signal.
In one embodiment, the reset mechanism comprises
In one embodiment, the wireless communications device comprises a device key storage connected to the control unit configured to hold a device key which is shared between the wireless communications device and an authentication server;
In one embodiment, the reset signal transceiver is separate from the radio transceiver.
In one embodiment, the machine-to-machine radio device is configured to communicate with a cellular network.
In accordance with a second aspect, a system is provided for distribution of goods, comprising
In one embodiment, the return station comprises a carrier washing station.
In accordance with a third aspect, a carrier for distribution of goods is provided,
In one embodiment, the wireless communications device is molded into the carrier member.
In one embodiment, the wireless communications device is encapsulated in a waterproof casing,
In accordance with a fourth aspect, a method is provided for resetting a wireless communications device comprising a machine-to-machine radio device for communicating with a remote network and a boot system connected to the machine-to-machine radio device, the method comprising the steps of receiving a reset signal from a user agent in a reset signal transceiver; and executing reboot of the machine-to-machine radio device by means of a reset controller, responsive to the received reset signal.
In one embodiment, the step of executing reboot includes
In one embodiment, the step of writing one or more boot flags in the boot system comprises
In one embodiment, in response to receiving a reset signal, the method comprises the steps of
In one embodiment, the method comprises the steps of
Various embodiments of the invention will be described in detail below with reference made to the appended drawings, in which:
The invention and the embodiments described herein are related to M2M communication. In the following, the detailed description outlines example embodiments of the present invention in relation to broadband wireless wide area networks, but it may be noted that the invention is not limited thereto and can be applied to other types of wireless networks where similar advantages can be obtained. Such networks specifically include wireless local area networks (WLANs), wireless personal area networks and/or wireless metropolitan area networks. Furthermore, the description will at various places make reference to IoT, and an example of a radio system for operating embodiments of the invention may be NB-IoT. However, it shall be understood that the invention is as such not limited to such a system, and may e.g. alternatively make use of MTC under LTE, but the invention is applicable also to other types of radio systems where scheduling may be required to avoid collision of co-existing radio protocols, and may also include coming systems such as discussed under the concept of NR (New Radio).
In various embodiments, devices 100, 200 may communicate with each other or with other devices 50, through or at least under the control of the radio base station 10. In a direct communication D2D, resources may be scheduled or otherwise controlled by the base station 10, whereas communication may be carried out directly between adjacent devices 100, 200 over radio. In another embodiment, communication between devices 100, 200 will, even when they are close enough to detect each other, normally be carried out through the base station 10.
The radio device 110 may comprise a control unit 113 including one or more processors 114. A data storage device 155 including a computer readable storage medium is further included, storing programming for execution by processors of the controller 113. Additional software programs or code may reside in other entities, accessible as cloud-based through the core network 1. The radio device 110 further comprises a radio transceiver 111, which in turn is connected to an antenna 112. A power supply 102 may supply power where required in the wireless communications device 100. Preferably, the power supply is provided in the shape of a non-removable battery 102.
As will be readily understood by the skilled reader, the radio device 110 may comprise a number of other features and functions, such as sensors or sensor interfaces 116, 117, 118. The radio device is an M2M device and may thereby be configured to communicate with a network 1 by radio, e.g. as an NB-IoT device, by means of the radio transceiver 111. The radio device 110 is preferably configured to communicate at low data rate and/or with long cycles of inactivity between transmissions. The actual characteristics of radio communication are not the within the scope of this disclosure, and are thus not discussed in any further detail. However, the character of wireless communications device 100 is preferably that of low complexity and cost, and small size, such that it may be suitably incorporated in various structures and provided in large volumes.
The boot system 120 of the wireless communications device 110 preferably comprises a boot ROM 121, which is communicatively connected to the control unit 113 of the radio device 110. A non-volatile memory 122 is further included, and accessible to the boot ROM 121. The non-volatile memory 122 is configured to store one or more boot flags, which are usable by the boot ROM 121 for rebooting the radio device 110. The boot system may be selectably operated to reboot the radio device when required. This may e.g. be initiated by means of Firmware upgrade Over The Air (FOTA), using radio transceiver 111 to receive re-boot instructions and or boot flags.
If the radio device 110 is non-operative due to some malfunction, the option of initiating reset over radio is not open. If there are no accessible user interface, the battery is non-removable, and the radio interfaces are dead, the problem is how to make the device 110 reset. For this purpose, the reset mechanism 130 includes a reset signal transceiver 131, and a reset controller 132 connected to the reset signal transceiver 131 and connected to the boot system 120 to request reboot of the radio device 110 responsive to a received reset signal. This way a reset mechanism 130 is provided that allows resetting a radio device 110 regardless of the device software state.
The basic idea is to include a reliable subsystem, including the reset mechanism 130 and the boot system 120, which is independent of the normal, and unreliable, device functions of the radio device 110. This subsystem can be triggered from the outside and takes care of resetting the system in the desired way.
In the reset mechanism 130, the controller 132 may include a processor and memory storage containing software code for execution by the processor. In operation, this may realize logic to accept an external signal 134 received by the reset signal transceiver 131, and to trigger a device reset procedure based on that signal 134. The external signal 134 is preferably sent over a wireless interface which preferably also is reliable, in the sense that it shall be separate and independent of the unreliable radio device 110, which is the target of the reset procedure. The reset signal transceiver 131 may thus include or be connected to a radio antenna.
In one embodiment, the wireless data link 134 may be part of a wireless charging subsystem, e.g. according to Qi or A4WP. In a variant, the reset signal transceiver may be configured to operate over a RFID interface. In one embodiment, the wireless link 134 may involve Near Field Communication (NFC) signals. In another embodiment, a Bluetooth Low Energy (BLE) interface may be employed for the wireless link 134.
In its simplest form, the reset signal transceiver 131 may be configured only as a receiver. In another embodiment, it may also operate as a transmitter, as will be outlined for various embodiments below. The reset signal transceiver 131 may nevertheless be configured to communicate with a user agent 30, comprising a signal transceiver and a control member for controlling communication with the reset signal transceiver 131 over the de wireless link 134 in question. The user agent is thereby configured to transfer a reset signal to the reset mechanism 130 of the wireless communications device 100.
The reset controller 132 is preferably configured to write one or more boot flags in the non-volatile memory 122 of the boot system 120 dependent on a received reset signal 134. Reset signals may be received with control data that may be written directly to the non-volatile memory 122. In one embodiment, the reset mechanism is configured to receive reset signals 134 that include control data that need to be decoded or even decrypted before being able to write boot flags to the non-volatile memory 122. In one such embodiment, the reset mechanism 130 may include a storage device 133 storing instructions that are executable by the reset controller to 132 retrieve control data from a received reset signal 134, and to write one or more boot flags in the non-volatile memory 122 dependent on the retrieved control data. This increases the protection against tampering.
The non-volatile memory 122 is configured to store one or more boot flags, which are usable by the boot ROM 121. This represents memory whose state survives power loss, e.g. at reboot.
The boot ROM 121 contains logic to shut down and restart the system of the radio device 110. The boot ROM is controlled by the state of the boot flags. Depending on the state of the boot flags, the boot ROM will reset various parts of the system state. Some different examples of reset state for the radio device 110 include:
Restart—erase a system volatile memory (RAM);
Hardware Reset—reset non-volatile hardware driver state;
Factory Reset—reset all non-volatile memory to factory defaults;
FOTA roll-back—reset all non-volatile memory to a state saved before the latest FOTA upgrade.
Components of the reset mechanism 130 and the boot system 120 may be configured by means of discrete electrical components, or as functions implemented on the same silicon die as the radio device 110.
With reference to
In a preferred embodiment, the step of executing reboot includes
The step of writing one or more boot flags in the boot system may comprise the step of retrieving control data from the received reset signal, and writing one or more boot flags dependent on the retrieved control data. As mentioned, the control data from the reset signal 134 may require decoding, decrypting or at least mapping, using data stored in a memory storage 133 of the reset mechanism, so as to determine which boot flags to write.
In a preferred embodiment, when the reset mechanism sends a reboot request to the boot ROM which starts a reboot procedure 345, a first step of that reboot may be shutting down the radio device 110. At the start of the boot procedure, the boot ROM reads the boot flags and prepares for the requested boot type. The boot ROM thereby performs device boot, and subsequently hands over to a device Secondary Boot Loader SBL (not shown).
In one embodiment, extra security enablers are added so only authorized persons or software operating as user agent 30 can trigger the reset mechanism 130. As described, the possibility to reset the wireless communications device 100 are still an important function, for example to return the device to a well-known state, remove any data from the device or if the device is malfunctioning. However, reset is a sensitive function that preferably only should be allowed by authorized persons/software. In accordance with various embodiments, such reset function can be protected using cryptographic methods by extending the reset mechanism architecture proposed above.
Returning to
In a preferred embodiment, the authentication server 40 is used for the purpose of authenticating and authorizing a user agent 30 that is invoking a reset function. Before a user agent can issue a reset request, the user agent 30 must preferably be registered and authorized to issue reset requests by an administrator of the authentication server 40. In such a circumstance, the user agent 30 is preferably in possession of an Access token that has been issued by the authentication server 40. The access token may be provided after a successful authentication and authorization procedure, for example using OAuth or other industry standard.
A device key storage 119 may be connected to the control unit 113 of the radio device, configured to hold a device key which is shared between the wireless communications device 100 and the authentication server 40. However, the device key may not be accessible if the radio device 110 is not operative. In order for reset to be possible if the radio device 110 is malfunctioning, there must be some cryptographic key available in some reliable component. The reset mechanism 130 thus preferably comprises a reset key storage 133, connected to the reset controller 132, configured to hold a reset key.
In a preferred embodiment, the reset key is a cryptographic key generated in dependence of the device key. The reset key should be derived in such manner that the authentication server may derive the key material. For example the reset key could be generated in the following way:
Reset Key Id=Random Number()
Reset Key=Hash (Reset Key Id+Device Key);
This may e.g. be carried out the first time a wireless communications device 100 is started, i.e. at cold start, whereby a reset cryptographic key is generated and stored in the reliable key storage 133. In an embodiment where the Device Key is shared between the authentication server 40 and the radio device 110, the reset key can calculated by the authentication server 40 by providing the reset key Id. The shared device key may be reliably stored in a memory storage 41 connected to the authentication server 40.
Now referring to
Request Signature=HMAC(Reset Key, Reset Key Id+Nonce1+Timestamp1).
The Request Signature is sent 315 by the reset signal transceiver 131, potentially together with Reset Key Id, Nonce1, Timestamp1, to the user agent 30. The user agent 30 preferably forwards 320 all these parameters, and the Access Token stored in a memory 31 connected to the user agent 30, to the authentication server 40.
The authentication server 40 then validates the token, signature, Nonce and Timestamp. If those are valid the authentication server 40 responds 325 with an acknowledgment to the user agent 30, together with a new signature that can be cryptographic validated by the reset mechanism 130. For example:
Response Signature=HMAC(Reset Key, Request Signature+Nonce2+Timestamp2);
The user agent 30 preferably forwards the Response Signature to the reset mechanism 130, which is thereby configured to receive 330 both an acknowledgment indicating that the request signature is validated with an access token of the user agent, and a response signature created based on the request signature. Once the reset mechanism 130 receives the response signature with the Nonce2 and Timestamp2, the reset may be started if the signature validated, as described above. Thus, the step of executing reboot 345 of the machine-to-machine radio device is carried out responsive to successful validation of the response signature. In an alternative embodiment, corresponding mechanisms may be implemented using public cryptography. The length of cryptographic keys and hash calculations should be long enough to fulfill the security requirements.
An example of a system incorporating the wireless communications device in accordance with any of the embodiments outlined above will now be described with reference to
The embodiment of
On a general level, the system may comprise a multitude of product carriers 150, some of which may be in storage 401. A product supplier 402, such as a factory, a packing company or a farm, may receive or retrieve a plurality of product carriers 150, and fill them with products 403 for distribution. By means of any suitable means for transportation, the filled product carriers 150 are provided to other entities, such as retailers 404, storage or restaurants, where the products are taken out of the product carriers 150. The empty product carriers are subsequently provided to a return station 405 for cleaning, after which they may be either used again, or be scrapped or even recycled to make new product carriers 150 or other products at a recycling station 408.
In the embodiments described herein, the system may operate a monitoring system 50 including a network device 10 configured to receive and possible transmit data from a machine-to-machine radio device 101 of the wireless communications devices 100 through the network 1 (see
The return station 405 preferably includes a carrier washing station 406, and a control device 407 comprising a user agent 30 configured to communicate with the reset signal transceiver 131 of the wireless communications device 100 incorporated in the product carriers 150 passing the control device 407. In case the product carriers 150 are not reachable by radio communication from the monitoring system 50 when distributed in the system, it may e.g. be difficult maintain an overview of where all the product carriers are located in the system. Even if they are primarily intended for the distribution of goods, they may end up in storages at the place 404 where the goods are delivered, which may result in shortage of product carriers 150 for distribution to product suppliers 403. In accordance with the system as shown and described with reference to the example of
Embodiments of the invention have been discussed in the foregoing on a general level, and with respect to certain embodiments. The skilled person will realize that where not contradictory, the disclosed embodiments above may be combined in various combinations.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2017/058136 | 4/5/2017 | WO | 00 |
