Waking up the device

Abstract

A method and system for a method for communicating between a device and a server, the method including the steps of the server initiating a device wake-up; obtaining generic bootstrap architecture (GBA) push information (GPI) including security credentials or information used to derive security credentials; sending a device wake-up message to the device, the device wake-up message including the GPI; authenticating the security credentials within the GPI to obtain a key; and establishing a secure communication channel between the device and the server using the obtained key, the secure communication channel using a certificate-based protocol and the obtained key being used in place of certificate authentication.

Description

[Technical field]

[0001] FIELD OF THE PRESENT APPLICATION The present invention relates to a method and system for waking up a device to communicate with a server. [Background technology]

[0002] 2. Background of the Invention Devices, particularly machine to machine (M2M) devices, are used in many different contexts and may be incorporated into a variety of different items and hardware. Typically, these managed devices have low computing resources, limited power, and limited functionality. Nevertheless, large networks of such devices may be developed that require maintenance, control, and other interactions that require communication with a device manager or other server.

[0003] Due to the nature of devices and limited resources, both in power and computing potential, it is often necessary to power down devices and keep them in a reduced power or hibernating state until they are needed (e.g., until they are needed to provide readings or accept commands). Devices may be scheduled to power up at specific times or intermittently. However, this approach has drawbacks when information is needed from such devices or when control or other management information needs to be sent outside such scheduled operating times. Alternatively, some form of communication between managed devices and their device managers may be maintained, but this requires additional power and bandwidth, especially for large networks of managed devices. Additionally, secure communication with devices is needed while limiting system resources and power consumption.

[0004] Therefore, what is needed is a method and system for communicating with devices that overcomes these problems. Summary of the Invention [Means for solving the problem]

[0005] SUMMARY OF THE PRESENT APPLICATION Devices such as machine-to-machine (M2M) or internet of things (IoT) devices may be powered using a battery or other long-term power source. In some cases, this power source may not be easily replaceable or replenished. Power management is therefore important, especially for devices that are intended to be installed for several years. One technique for achieving this is to power off the device or put it to sleep for a period of time (e.g., in a low-power mode or a mode that does not include powering one or more communication interfaces) and operate the device only for short or intermittent periods (or in a high-power mode that is higher than the low-power mode). The device may include a timer or schedule to achieve this. However, communication with the device may be needed during the time it is scheduled to sleep or when it is in a low-power mode. Furthermore, communication with the device may not be needed if the device is scheduled to be in an awake or high-power mode. In this case, waking up the device may simply waste power and other system resources.

[0006] Thus, there is a need to wake up devices when communication is required, and such communication needs to be protected while keeping power requirements low. For example, these communications may be to provide data, such as sensor data, from the device to a server. In such cases, a wake-up condition or message may be initiated. Because communication with the device needs to be protected, there is also a need to provide the device with security credentials. However, preferred security protocols such as TLS, DTLS, SSL, etc. typically require a certified authority (CA), and communication with the CA requires further messaging and communication (e.g., exchanging certificates) that have their own power and bandwidth requirements.

[0007] Rather than sending security credentials separately, the wake-up message can have a dual purpose, i.e., it can both wake up the device and contain security credentials in the form of generic bootstrap architecture (GBA) push information (GPI). The wake-up message itself does not need to be secured (although in some cases it may have its own security). The wake-up message includes a GPI so that a security protocol, usually involving a CA, can be used to secure the communication channel between the device and the server, but since the security credentials are sent as part of the GPI in the wake-up message, no CA or certificate exchange is required for authentication. Also, it is easier to transmit key material to the server (e.g., to provide a key) than with the device. Furthermore, the device does not need to be able to process or store security credentials, only needing to process the GBA, which can be optimized for low power and resource devices.

[0008] The security credentials in the GPI are authenticated or verified, which results in a key (e.g., Ks_NAF). The key is then used to secure communications between the device and the server. Preferably, the device includes a SIM, USIM, or UICC. Using the GBA in this manner has the advantage that no certificates (or authentication thereof) are required and the key can be derived from data on the SIM or UICC. Preferably, the SIM or UICC is used as a hardware token on the device to manage the credentials and / or the derivation of the credentials. In some exemplary implementations, the secure communication channel may be protected using TLS or other certificate-based protocols. Thus, such protocols can be set up without authentication.

[0009] The wake-up message is preferably in the form of an SMS, but may take other forms since the GPI may be distributed in other ways. The SMS itself may be unsecured or protected. Using unsecured SMS reduces processing overhead, but does not reduce the security of the secure communications channel, since the secure communications channel is already protected by the GBA and unsecured SMS is only used to transport the GPI (and security credentials).

[0010] According to a first aspect, there is provided a method for communicating between a device and a server, comprising: a server initiating a device wake-up; obtaining generic bootstrap architecture (GBA) push information (GPI) that includes a security credential or information used to derive a security credential; sending a device wakeup message to the device, the device wakeup message including a GPI; authenticating the security credentials within the GPI to obtain the key; establishing a secure communication channel between the device and a server using the obtained key, where the secure communication channel uses a certificate-based protocol and the obtained key is used in place of certificate authentication; Thus, good security can be maintained without the need for certificate messaging and associated overhead.

[0011] Preferably, the GPI may be obtained from a network application function (NAF), so the method can be used with existing GBA infrastructure, although other mechanisms can also be used.

[0012] Optionally, the server may initiate a device wake-up message by issuing an application programming interface (API) command, or call, to a separate device, which may be, for example, an API hub. The API hub can then manage interactions with other telecommunications infrastructure.

[0013] Advantageously, the GPI may be obtained by a separate device in response to receiving an API command from the server, for example when a separate device receives the API command it may interact with a Network Application Function (NAF) to obtain the GPI data or may perform NAF steps itself.

[0014] Whatever process is used to create the GPI data may be incorporated into a wake-up message for transmission to the device.

[0015] Preferably, the wake-up message may be an SMS message, however, the wake-up message may be sent and received (e.g., via different communication channel types) in different formats (e.g., fixed line, telephone, etc.).

[0016] Optionally, the method comprises: In response to receiving the wake-up message, the device changes state before establishing a secure communication channel. It may further include.

[0017] Preferably, the device may change state from a first power state to a second power state, and the power used by the device in the first power state is less than the power used by the device in the second power state, thus conserving battery power and extending the life of the device.

[0018] Optionally, the device may be a Machine-to-Machine (M2M) device. The device may be an Internet of Things (IoT) device.

[0019] Upon receiving a wake-up message containing a GPI block of data, the device may perform GAA server function authentication using the received GPI data block and derive the Ks_NAF key (or other key) as the result of the authentication.

[0020] The device may then use the derived Ks_NAF key as input to a TLS function, which may be used to initiate a secure client connection with a server (eg, an application server).

[0021] Optionally, the established secure communication channel may be TLS, SSL, DTLS, QUIC, QUIC PSK, or QUIC 0-RTT. Other certificate-based protocols may be used without the need for a certificate authority.

[0022] Preferably, authenticating the security credentials in the GPI to obtain the key may further include the device authenticating the GPI with a bootstrap server function (BSF) and receiving the key from the BSF upon successful authentication, thus leveraging the existing GBA infrastructure.

[0023] Optionally, the server may be a device manager (DM) server, however the server may take other forms and perform other functions.

[0024] Optionally, wake-up messages may be initiated at predefined intervals and / or upon expiration of a previously obtained key. Different mechanisms can be used to initiate wake-up messages. These can be scheduled or ad-hoc.

[0025] Optionally, the server initiates device wake-up messages in response to requests originating at the device. Thus, some components or aspects of the device can control how and when the remaining components (e.g., the communication interface) are powered and woken up.

[0026] Optionally, the method may further include sending a wake-me-up message to the server when the device is in a low power state, the low power state being at a lower power than the operating power. This further message or signal may be sent, for example, over the same communication type and channel as the wake-up message (e.g., SMS) or as a different message type.

[0027] Optionally, in an exemplary implementation where a device initiates its own wake-up by sending a wake-me-up message (or another form of request), the wake-me-up message may be communicated to the application server with no data (or very little data) transmission. In this case, the associated protocol may require a data connection to be established between the initiating device and the application server, and once the connection is established, it may be closed by the device (e.g., immediately or after a short time) and all resources released. In this mode of operation, the communication component may communicate the identity of the calling device to a server, the application server (or API server), which may then use this identification information to obtain GPI data via a NAF server, etc.

[0028] Optionally, wake-up messages to and / or from the device may include data indicating a wake-up delay, thus providing further control over how and when the device wakes up and / or resumes communication with the server.

[0029] Advantageously, the method may further comprise the step of the device delaying establishment of a secure communications channel with the server for a period based on the data indicative of the wake-up delay. The delay may be achieved using other mechanisms.

[0030] Optionally, the wake-up message may include data indicating a wake-up type of a plurality of wake-up types.

[0031] Optionally, the method may further include establishing a secure communication channel between the device and the server according to a procedure determined by a wake-up type in the wake-up message. Different types may include, for example, waking up immediately, waking up after a delay, and waking up at a specified time.

[0032] Optionally, the step of establishing a secure communication channel between the device and the server may further comprise providing an identifier of the device to the server, which may be, for example, an IMSI, an IMEI, or other identifier.

[0033] Optionally, if the device does not respond within a predetermined time, the wake-up message may be resent to the device, or a new wake-up message is sent to the device, which may improve reliability.

[0034] Optionally, the message may be associated with a timestamp, and the method may further comprise the step of resending the wake-up message or triggering a new wake-up message to be sent to the device if the server does not have a record of the establishment of a secure communication within a predetermined time from the timestamp. Such a timestamp may be a timestamp of the message itself (e.g., SMS) or timestamp data within the message.

[0035] According to a second aspect, there is provided a system comprising means for carrying out the steps of the method described above.

[0036] Preferably, the system comprises a server; With one or more devices There may also be multiple servers, for example associated with a group of devices or to provide load balancing and redundancy.

[0037] Preferably, the system comprises: an application programming interface (API) hub configured to receive a command from the server to initiate a device wake-up message and to send a device wake-up message to the device in response; The device may further include:

[0038] Advantageously, the system comprises: A network application function (NAF) configured to provide GPIs The GPI may be provided, for example, directly from the NAF or via an intermediate source or provider, such as a server or API hub.

[0039] According to a third aspect, there is provided a computer program comprising instructions which, when said program is executed by a computer, cause the computer to carry out the steps of the method described above.

[0040] The above-described methods may be implemented as a computer program comprising program instructions for operating a computer. The computer program may be stored on a computer-readable medium.

[0041] The computer system may include a processor, such as a central processing unit (CPU). The processor may execute logic in the form of a software program. The computer system may include memory, including volatile and non-volatile storage media. A computer readable medium may be included for storing logic or program instructions. Different parts of the system may be connected using a network (e.g., wireless and wired networks). The computer system may include one or more interfaces. The computer system may include a suitable operating system, such as, for example, UNIX, Windows (RTM), or Linux.

[0042] It should be noted that any of the features described above may be used in any particular aspect or embodiment of the invention.

[0043] BRIEF DESCRIPTION OF THE DRAWINGS The invention may be put into practice in a number of ways and embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0044] [Figure 1] FIG. 2 is a high level sequence diagram of a process for sending a wake-up message from a server to a device. [Diagram 2] FIG. 1 is a schematic diagram of an example device management system. [Diagram 3] 4 is a flowchart of an exemplary method for communicating between a device and a server. [Figure 4] FIG. 2 is a sequence diagram of an example implementation of a method for sending a wake-up message to a device. [Diagram 5] 4 is a sequence diagram of an alternative exemplary method for sending a wake-up message to a device. [Figure 6]4 is a sequence diagram of an alternative exemplary method for sending a wake-up message to a device. [Figure 7] 4 is a sequence diagram of an alternative exemplary method for sending a wake-up message to a device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0045] It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale, and similar features are given the same reference numbers.

[0046] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Generic Bootstrap Architecture (GBA) Push Information (GPI) can be distributed using any suitable means. The GPI can include security credentials that can be used to derive a key. A Network Application Function (NAF) can provide such a GPI to a device. Generic authentication architecture (GAA) allows for authentication of the GPI resulting in an authentication result (e.g., a key or other cryptographic material). Note that while the following example implementation uses SMS to distribute the GPI to the device, other technologies (e.g., WiFi, landline, etc.) can be used.

[0047] Additionally, the devices described in these exemplary implementations are machine-to-machine (M2M) devices or Internet of Things (IoT) devices, although other device types may be used with the described techniques and systems. These devices typically have low computing and power resources, but need to protect the data they collect and transmit. For example, these data may include utility data usage data or infrastructure sensor data. Therefore, a secure communication protocol is needed to transmit these data from the devices. Furthermore, to keep power requirements and bandwidth usage at a low level, such devices (which are typically battery-powered, and may or may not be replaceable or rechargeable) can be put into a low-power or sleep mode. A low-power mode uses less power than a high-power mode when further communication interfaces are powered and in use. However, the low-power and high-power modes may affect other components as well as the communication interfaces. Timers and schedules may be built into the devices so that they wake up periodically. However, it may be necessary to communicate with such devices (or put them into a higher power mode for other reasons) outside of these schedules. For example, a firmware update may be required or momentary data may need to be collected that requires immediate or at least quicker resumption of communication with the device. Thus, in addition to or instead of a wake-up schedule, the device may receive a wake-up message that switches the device from a low power mode to a high power mode and / or a mode that allows communication with a server or other entity to take place.

[0048] FIG. 1 illustrates a sequence diagram of a high level method for waking up device 20. While this diagram illustrates application server 40, any server type may be used or incorporated. Application server 40 initiates a device wake-up message by invoking an application programming interface (API) call to API hub 60. Again, other mechanisms may be used to initiate the wake-up message, either within the server or external to it. API hub 60 responds to the API call by generating an SMS using a telecommunications infrastructure (not shown in this diagram). Device 20 includes a UICC or SIM and telecommunications components that allow it to receive SMS even in a low power state. The SMS may be directed to a single device (i.e., based on its mobile phone number) or multiple SMS may be sent simultaneously to a wake-up group of devices or to all devices within a particular network of devices.

[0049] In response to receiving the SMS, the device 20 initiates a client connection with the application server 40. This may be by access point name (APN) or other telecommunications infrastructure. Thus, data communication between the device 20 and the application server 40 may be initiated. The wake-up message thus causes the device 20 to change state, and waking up may involve performing more on-board processes than a low power, sleep, or hibernate state (a state in which minimal or fewer processes are performed, including monitoring for or the ability to receive wake-up messages). The communication channel carrying the wake-up message may be secured or unsecured depending on the particular application.

[0050] FIG. 2 shows a schematic diagram of a system 10 for implementing an exemplary wake-up procedure. The device 20 includes a UICC or SIM 30, and the server 40 includes a communication interface 50. In this figure, an API hub 60 is shown receiving an API call from the server 40 and initiating an SMS to be sent to the device 20. However, in this exemplary implementation, the API hub 60 obtains a GPI (containing security credentials or information for deriving such security credentials) from, for example, a GBA NAF server or a NAF push server 70. Thus, the API hub 60 can embed the GPI in the SMS that is subsequently sent to the device 20. The GPI contains security credentials that are used directly or indirectly to secure communications between the device 20 and the application server 40. This is achieved by the device 20 authenticating the GPI with a Generic Authentication Architecture (GAA) server 80. This authentication results in a key 90 that is used to secure communications between the device 20 and the server 40.

[0051] The particular security protocol used to secure communications between the device 20 and the server 40 is one that would otherwise use a security system of certificates and a Certificate Authority (CA) for the device 20 and server 40 to authenticate each other and obtain a shared key 90. However, no CA or certificate processing is required, as the security credentials are already contained within the GPI and available to both the device 20 and the server 40 using the NAF 70 (or otherwise).

[0052] As can be seen from this diagram, the NAF 70 also shares security credentials with the server 40. Alternatively, the key 90 may be shared directly with the server 40, either from the API hub 60 or elsewhere. Thus, the server 40 does not need to process (or receive) a GPI or security credentials. In either case, no CA or certificate process is required.

[0053] FIG. 3 shows a flow chart of a method 100 for communicating between the device 20 and the server 40. In step 110, a wake-up message is initiated. This may be done directly by the server 40 or by another entity that causes the server 40 to initiate a process. In some example implementations, the initiation may come from the device 20 itself. In this case, a process implemented within the device 20 while the device 20 is in a sleep mode may trigger this initiation. Waking up the device 20 internally may waste resources while the device 20 waits to receive or obtain the key 90 to secure the communication with the server 40. Thus, the described wake-up procedure holds advantages even when it comes from the device 20 itself.

[0054] In step 120, a GPI is obtained. This may be from the NAF 70 or another entity. The GPI is embedded in a wake-up message sent to the device in step 130. The credentials are authenticated in step 140. This may be by the device 20 and / or the server 40. In an example implementation, this authentication may be accomplished using a GBA and / or by using a SIM or UICC 30 in the device 20. The result of this authentication is a key 90 or material for deriving a key 90 (e.g., using the UICC or SIM 30).

[0055] The key 90 is used to secure communications between the device 20 and the server 40 in step 150. The method 100 can be used with a different key 90 each time a wake-up message is sent, or the key 90 can be changed as frequently as desired (e.g., the wake-up message can include security credentials in the GPI only when or every time a wake-up message is sent). Thus, the increased security of using a different key (e.g., periodically or always) does not significantly increase the required computing, bandwidth, or power resources (at least of the device 20).

[0056] As previously mentioned, different certificate-based security protocols may be used to secure communications between device 20 and server 40. Figures 4, 5, 6, and 7 illustrate certain example implementations of the use of different security protocols, as well as certain alternative method steps used to set up these security protocols and the secured communications.

[0057] FIG. 4 illustrates how a transport layer security (TLS) security protocol communication is set up between the device 20 and the server 40. This figure shows a sequence diagram including various exemplary steps that may be used as part of this process. Similar to the method described with reference to FIG. 3, the application server 40 uses an API call to the API hub 60 to initiate a wake-up procedure (or wake up a device or group of devices in response to an external request) or create a wake-up message. Again, the API hub 60 requests a GPI from the NAF push server 70, which is then returned to the API hub 60 in response to the request. In this exemplary implementation, the API hub 60 also returns the GPI to the application server 40 so that it can authenticate itself (e.g., with the GAA 80 or otherwise) of the GPI, so that the Ks_NAF key is available to the server 40. An SMS (including the GPI with security credentials) is sent to the device 20.

[0058] As described above, the GAA server 80 is used by the device 20 (in some example implementations, the server 40) to authenticate the GPI and security credentials. In this example implementation, the result of this authentication is the same Ks_NAF key that is available to the server 40 (transferred to it or derived as the authentication result).

[0059] The device 20 and the server 40 now possess keys 90 that they can use to create TLS connections with each other without the need to use a CA. The device 20 does this by creating a client TLS connection context using Ks_NAF. The server 40 verifies Ks_NAF at the NAF push server 70 via the API hub 60. The NAF push server 70 returns the verification result to the application server 40, again via the API hub 60.

[0060] A TLS connection context is established and a TLS handshake is completed from the application server 40 to the device 20. This achieves a TLS-secured socket connection between the device 20 and the application server 40.

[0061] When the key (Ks_NAF) 90 is provided directly to the server 40, either from the API hub 60 or elsewhere, the four steps shown in FIG. 4 between the server 40 via the API hub 60 and the NAF push server 70 to verify the Ks_NAF and return the verification result are no longer necessary. This further improves the efficiency of the method. This alternative can be used for any security protocol implementation, including the examples described with respect to any of FIGS. 4, 5, 6, and 7. Security can be maintained in this exemplary implementation, since the server 40 may be provided with a pre-shared key (PSK) and can therefore securely receive further keys.

[0062] FIG. 5 shows a sequence diagram of a method similar to that described with reference to FIG. 4. However, instead of a TLS connection being established, a DTLS connection is established. As can be seen from FIG. 5, after the wake-up message and the encapsulated GPI are sent to the IoT device 20, a DTLS connection context is established and a DTLS handshake is completed. The description of these same steps is the same as that described with reference to FIG. 4, except for the use of DTLS instead of a TLS connection and context, and will not be repeated. As can be seen from FIG. 5, the application server 40 and the device 20 achieve a DTLS user datagram protocol (UDP) socket connection to complete any communication in a secure manner. Again, a CA is not required, although DTLS would normally require a CA.

[0063] FIG. 6 illustrates an alternative exemplary implementation of the method 100, as described with reference to FIGS. 4 and 5, but resulting in the establishment of a Quick UDP Internet Connections (QUIC) protocol session between the IoT (or other) device 20 and the application server 40. Again, this figure includes the same steps as those described with reference to FIGS. 4 and 5, up to the point where the device 20 authenticates the GPI received in the SMS with the GAA server 200. At this stage in the sequence, the device initiates the QUIC session using Ks_NAF as a zero round trip time (0-RTT) key. Using this method, the device can immediately start sending data over the QUIC session, since the key is known by both the device 20 and the application server 40, without requiring a reply from the server 40 beforehand.

[0064] A bidirectional QUIC session is established and the handshake is completed, resulting in a multiplexed and encrypted QUIC connection between, for example, device 20 and server 40.

[0065] FIG. 7 shows a sequence diagram of a method similar to that described with reference to FIG. 6. However, in this exemplary implementation, the QUIC session is implemented using a PSK. Again, the same method steps are performed as described with reference to FIGS. 4, 5, and 6 up to the point of how the IoT device 20 authenticates the GPI with the GAA server 200 and obtains the Ks_NAF. At this point in the process, the device 20 initializes the QUIC session using the Ks_NAF as the PSK. A bidirectional QUIC session is established and the handshake is completed, resulting in a multiplexed and encrypted QUIC connection between the device 20 and the application server.

[0066] A UICC or SIM provisioned to the device 20 may be used as a hardware token to manage security credentials and their derivation. There is no need to provide a key (presenting a cryptographic challenge) for secure communication between the device 20 and the server 40. This method can be used in any application that requires secure communication with low overhead and is particularly suitable for mobile edge computing (MEC).

[0067] Further advantages of the described systems and methods over a client-driven approach include:

[0068] 1. Device 20 does not need to support Ua or Ub flows, reducing the complexity of the device solution and the need for dual APNs.

[0069] 2. The device 20 does not need to support a GAA server, and although it still requires some GAA type functionality, these are much simpler.

[0070] 3. The application flow can be built into the SSL library functionality, i.e. once the device has the GPI packet, it can use that packet as a parameter to the TLS handshake (or other certificate-based security protocol), all that is needed is from the device coding perspective. The SSL library may also have support added for the GBA flow.

[0071] 4. A user (eg, a commercial entity) may be provided with extended SSL library functionality that is deployed on both the device 20 and the application server 40.

[0072] 5. The device 20 does not need to exchange certificates with the server 40 or walk the CA chain. This reduces the amount of data transmitted and the required power budget.

[0073] 6. The system and method may support TLS 1.3 or other security protocols.

[0074] 7. The system and method can support UDP and TCP / IP transport protocols.

[0075] The GPI contains enough information for the SIM, UICC, or USIM in the device 20 to generate Ks and for the GAA server 80 to generate the corresponding Ks_NAF. This is similar to the same key derivation used for regular GBA.

[0076] The computer system and architecture may include a processor, such as a central processing unit (CPU). The processor may execute logic in the form of a software program. The computer system may include memory, including volatile and non-volatile storage media. A computer readable medium may be included to store logic or program instructions. Different parts of the system may be connected using a network (e.g., wireless and wired networks). The computer system may include one or more interfaces. The computer system may include a suitable operating system, such as, for example, UNIX, Windows (RTM) or Linux.

[0077] As will be appreciated by those skilled in the art, details of the above embodiments may be changed without departing from the scope of the invention as defined by the appended claims.

[0078] For example, the device or client may prompt or issue a wake-up request on its own. The server 40 may perform a validation request before proceeding to accept a TLS (or any other) handshake as part of setting up a secure communication channel. Additionally, similar to the server 40 performing the step of validating a new Ks_NAF with the NAF push server 70 via the API hub 60 (or other methods) shown in Figures 4 and 5, the server 40 may inquire whether a previously acquired Ks_NAF has expired, is about to expire, or has been revoked. If such a situation occurs (i.e., it is determined that a new Ks_NAF is required), the server 40 may be triggered to obtain a new Ks_NAF from the NAF push server 40 (or, more simply, a new Ks_NAF may be triggered and sent to the server 40 as a response).

[0079] The GAA server (or component) may be implemented within the SIM, UICC, or USIM (or within the modem) of device 20, resulting in less code needing to be installed on the device.

[0080] Within the TLS (and DTLS) process, the server 40 may use Ks_NAF in conjunction with the NAF push server 70 to authenticate incoming connections and derive keys on the server 40 .

[0081] Other methods may be used to provide the key 90 to the server 40 to achieve secure communications with the device 20. For example, the NAF push server 70 may return a GPI to the server 40 when a wake-up is first triggered, or alternatively, the GPI may be provided to the server 40 by a return path from the device 20.

[0082] The openssl driver library may implement the NAF push server 70 functionality, for example implemented as an extension, and the openssl driver library may also include GAA server functionality within the openssl code.

[0083] Although one device and a single server are shown in the figures, networks or groups of devices, as well as more than one server or application server, may be used with the described systems and methods. A group of devices may, for example, be managed by or communicate with one or more servers.

[0084] Other actions may be taken following device wake-up. For example, sensor or other data may be transmitted over the secure communication channel. Firmware updates may be taken over the secure communication channel or other device management actions. These may include decisions regarding device operation (e.g., battery levels, signal levels, device health, etc.).

[0085] A wake-up message has been described, which may take the form of a message received over a particular interface (e.g., SMS), may have a particular message type or other attributes, and may, but need not, include an explicit designation or name that is a wake-up message.

[0086] A wake-up message may also be initiated by the device itself. In this case, the device may issue a "wake me up message". This may be sent with the device in a particular low power mode or other case, e.g., when using fewer resources than when actively transmitting data or other communications. The server may determine in various ways which particular device is requesting to be woken up (e.g., to make it more active and transmit useful data again). For example, the information used to determine the device may be the IMSI of its SIM or UICC.

[0087] This information may be explicitly sent from the device in the wake-me-up request. Alternatively, this information may be inferred indirectly. For example, the device (or IMSI) may be determined when an Access Point Name (APN) connection is set up and then indirectly communicated to a server, application, or application server.

[0088] This has the advantage of reducing data communication and activity (or power usage) on the device when opening and closing an APN connection without requiring data transmission. When a device opens a data connection, a request may be sent to a Radius server that has the identity of the device. The Radius (or other) server authenticates the connection and allocates some resources (e.g., an IP address) that the connection can use. The Radius server can then communicate to the NAF or API function that a device with a particular IMSI has requested to perform a "wake-me-up" process.

[0089] Many combinations, modifications, or alternatives to the features of the above-described embodiments will be readily apparent to those skilled in the art and are intended to form part of the present invention. Any of the features described with specific reference to one embodiment or example may be used in any other embodiment by making appropriate modifications.

Claims

1. A method for communicating between a device and a server, comprising: starting device wake-up by the server; obtaining generic bootstrapping architecture (GBA) push information (GPI) including security credentials or information used to derive the security credentials; sending a device wake-up message to the device, the device wake-up message including the GPI and the wake-up message being an SMS message; authenticating the security credentials within the GPI to obtain a key; establishing a secure communication channel between the device and the server using the obtained key, the secure communication channel using a certificate-based protocol and the obtained key being used instead of certificate authentication, the established secure communication channel being transport layer security (TLS), secure sockets layer (SSL), datagram transport layer security (DTLS), quick user datagram protocol internet connections (QUIC), or QUIC zero round-trip time trip (QUIC 0-RTT); and a method comprising the steps of:

2. The method according to claim 1, wherein the GPI is obtained from a network application function (NAF).

3. The server starts the device wake-up message by issuing application programming interface (API) commands to a separate device. The method according to claim 1, wherein the GPI is obtained by the separate device in response to receiving the API command from the server.

4. The step of the device changing its state in response to receiving the wake-up message before establishing the secure communication channel. further comprising The method according to claim 1, wherein the device changes its state from a first power state to a second power state, and the power used by the device in the first power state is less than the power used by the device in the second power state.

5. The method according to claim 1, wherein the device is a machine-to-machine (M2M) device.

6. The step of authenticating the security credentials in the GPI to obtain the key further includes the step of the device authenticating the GPI using a bootstrapping server function (BSF) and the step of receiving the key from the BSF upon successful authentication. The method according to claim 1, wherein the server is a device manager (DM) server.

7. The method according to claim 1, wherein the wake-up message is initiated at a predetermined interval and / or when the expiration date of a previously obtained key has expired.

8. The server initiates the device wake-up message in response to a request generated by the device. The method according to claim 1 further includes the step of the device sending a wake-me-up message to the server when the device is in a low-power state, wherein the low-power state is at a power lower than the operating power.

9. The wake-up message includes data indicating a wake-up delay. The method according to claim 1 further includes the step of the device delaying the establishment of the secure communication channel with the server for a period based on the data indicating the wake-up delay.

10. The wake-up message includes data indicating a wake-up type among a plurality of wake-up types. The method according to claim 1 further includes the step of establishing the secure communication channel between the device and the server according to a procedure determined by the wake-up type in the wake-up message.

11. The method according to claim 1, wherein the step of establishing the secure communication channel between the device and the server further includes providing an identifier of the device to the server.

12. If the device does not respond within a predetermined time, the wake-up message is resent to the device, or a new wake-up message is sent to the device. Further, The wake-up message is associated with a timestamp, and the method further includes the step of triggering the server to resend the wake-up message or send a new wake-up message to the device if the server does not have a record of establishing the secure communication channel within the predetermined time from the timestamp.

13. A system comprising means for performing the steps of the method according to any one of claims 1 to 12.

14. A server, One or more devices The system according to claim 13, comprising.

15. An application programming interface (API) hub configured to receive a command from the server to initiate the device wake-up message and, in response, send the device wake-up message to the device; A network application function (NAF) configured to provide the GPI; The system according to claim 13, further comprising.

16. A computer program comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 12.

Images