Accelerated session recovery over load balanced network services

Abstract

The present invention relates to methods and apparatus for increasing the likelihood that a device can restore previously established sessions (e.g., transport layer security sessions) with a load balanced network service (e.g., cloud service) that may support only node level load balancing. This may be accomplished by maintaining one or more network addresses and a valid session ticket (or identifier) for an individual node (e.g., a server) of a network service for a previous communication session, and based on a match of the particular node to one of the one or more network addresses and the session ticket or session identifier. The particular node is selected from a list of potential nodes returned through an address lookup (e.g., a domain name system (DNS) lookup) for a subsequent communication session.

Description

Technical Field

[0001] The present invention relates to a session resumption process for devices and / or applications (such as but not limited to load-balanced cloud services) in a wired or wireless network. Background Art

[0002] Internet of Things (IoT) devices often use sleeping to reduce power consumption. This causes communication sessions with their network to be suspended. In many cases, these sessions use secure protocols (e.g., TLS (Transport Layer Security)) for privacy reasons, and these sessions are also suspended.

[0003] To meet demand and reduce workload, organizations distribute workloads across multiple servers, which is called "load balancing." Load balancing is used to evenly distribute network traffic to prevent failures caused by overloading a particular resource. This strategy improves the performance and availability of applications, websites, databases, and other computing resources. This strategy also helps in processing user requests quickly and accurately.

[0004] Load balancing is often used at server farms that run high-traffic websites. Load balancing is also used for Domain Name System (DNS) servers, databases, and File Transfer Protocol (FTP) sites. By routing user requests evenly across a group of servers, load balancers minimize the possibility of downtime. If one server in the group fails, the load balancer reroutes traffic to other servers in the group. When new servers are added to the server pool, the load balancer automatically includes them in the traffic distribution process.

[0005] Thus, load balancing enables a service provider (eg, a cloud service provider) to balance the load of requests across multiple physical servers (also referred to as nodes) providing scalability and availability.

[0006] When the IoT device wakes up, it has to resume the session. A brute force solution would be to redo the full handshake process to obtain all the required information for restarting the session. This represents a considerable overhead for the typically very small message payload. Summary of the invention

[0007] It is an object of the present invention to provide enhanced efficiency when initiating communication sessions associated with load balanced services.

[0008] This object is achieved by an apparatus, a communication device, a client device method and a computer program product as claimed in the appended claims.

[0009] According to a first aspect, there is provided an apparatus for controlling initiation of a communication session between a client device and a network node, wherein the apparatus is adapted to:

[0010] Maintaining a list comprising a plurality of tuples, wherein the tuple comprises: a network address of an individual network node and an associated session ticket or session identifier, wherein the individual network node provides a target network service and was used by the client device for a previous communication session;

[0011] selecting the network node for a subsequent communication session from the list of potential nodes returned by the address lookup based on a match of the network address of the network node to one of the one or more network addresses and an associated session ticket or session identifier; and

[0012] The matched network address and associated session ticket or session identifier are used for session resumption with the selected network node.

[0013] According to a second aspect, there is provided a communication module comprising the apparatus of the first aspect. Thus, the client device can be upgraded or enhanced by adding or installing the communication module of the second aspect.

[0014] According to a third aspect, there is provided a client device comprising the apparatus of the first aspect.

[0015] According to a fourth aspect, there is provided a method for controlling initiation of a communication session between a client device and a network node, wherein the method comprises:

[0016] maintaining a list comprising a plurality of tuples, wherein the tuple comprises: a network address of an individual network node and an associated session ticket or session identifier, wherein the individual network node provides a target network service and was used for a previous communication session;

[0017] selecting the network node for a subsequent communication session from the list of potential nodes returned by the address lookup based on a match of the network address of the network node to one of the one or more network addresses and an associated session ticket or session identifier; and

[0018] The matched network address and associated session ticket or session identifier are used for session resumption with the selected network node.

[0019] According to a fifth aspect, there is provided a computer program product comprising code means for producing the steps of the above method according to the fourth aspect when the code means is run on a computer device.

[0020] Thus, previous connections (communication sessions) can be tracked by performing connection tracking on the client device side. The proposed enhanced client device is adapted to perform an address lookup (e.g., a DNS lookup) of a desired target network service (e.g., a cloud service) upon waking up from sleep to obtain a list of valid network addresses (e.g., IP addresses), maintain at least one entry with a valid session ticket or session identifier and network address from (one or more) previous communication sessions, and check whether at least one of the network addresses of the address lookup matches at least one of the maintained network addresses. If a match is determined, the stored associated session ticket or session identifier can be used to initiate a shortened (accelerated) handshake toward the matching network address.

[0021] The proposed enhanced session resumption process enables to reduce the protocol overhead independently of the server capabilities. Thus, lower protocol overhead can be achieved in terms of the number of exchanged (respectively received) message flights and certificate chains, thereby reducing energy consumption and data costs. This is particularly advantageous for energy-constrained wearable devices (e.g., cellular-connected wearable devices). A message flight will be understood as a sequence of one or more packets traveling in one direction (i.e., client to server or server to client). The next message flight occurs when the communication changes direction (i.e., server to client or client to server).

[0022] According to a first option that can be combined with any one of the first to fifth aspects above, network addresses corresponding to expired session tickets or session identifiers can be cleared, and the remaining network addresses obtained by address lookup can be compared with the maintained network addresses of the tuples in the stored list to identify the network nodes for session resumption. Therefore, as the number of available session tickets or session identifiers increases according to the length of the maintained list, a greater chance of shortening session resumption can be achieved.

[0023] According to a second option that can be combined with any of the first to fifth aspects above, only the associated session ticket or session identifier and the last network address for the previous session can be maintained, and it can be checked whether one of the network addresses in the list obtained from the address lookup matches the last network address and whether the corresponding session ticket is still valid. Therefore, the proposed enhanced session resumption can be simplified by only remembering (storing) the last tuple (i.e., the last IP address and the associated session ticket). This leads to a simplified control flow and reduced storage requirements.

[0024] According to a third option that can be combined with the first option or the second option or any of the first to fifth aspects above, if it is determined that the time period between consecutive session resumptions is greater than a predetermined portion of the lifetime of the session ticket or session identifier, the first option above can be configured to return to the second option above. Thus, in the case where the probability that the session ticket or session identifier is valid for a previous session older than a time period becomes too low, a compromise between a greater chance of shortened session resumption and a simplified control flow and reduced storage requirements can be achieved. According to a fourth option that can be combined with any of the first to third options or any of the first to fifth aspects above, network addresses associated with unexpired session tickets or session identifiers can be conditionally cleared to save storage space.

[0025] According to the fifth option which can be combined with any one of the first to fourth options or any one of the first to fifth aspects, the target network service can be a load-balanced network service, in particular a load-balanced cloud service. Thus, for the network service provided by the load-balanced server farm, the chance of shortening session recovery can be increased.

[0026] According to the sixth option which can be combined with any one of the first to fifth options or any one of the first to fifth aspects, session resumption can be performed according to the transport layer security (TLS) protocol. Thus, the shortened session resumption option provided by the TLS protocol can be improved for load-balanced network services.

[0027] According to the seventh option which can be combined with any one of the first to sixth options or any one of the first to fifth aspects, the communication session can be used for data ingest for the cloud service. This provides the advantage that the data upload efficiency of the client device having a dormant phase can be improved due to the availability of a shortened session recovery process.

[0028] According to an eighth option which can be combined with any one of the first to seventh options or any one of the first to fifth aspects, the communication module of the second aspect may include a modem configured to provide an attention (AT) command interface for implementing an end-to-end communication stack for data ingestion communication. Therefore, some AT commands may be sufficient for connection establishment and address lookup, so that communication efficiency can be improved.

[0029] According to a ninth option which can be combined with any one of the first to eighth options or any one of the first to fifth aspects, the modem can be adapted to perform a communication session with a network server via a cellular access device using a Long Term Evolution (LTE) machine type communication protocol or an LTE narrowband Internet of Things protocol. Thus, a low power solution with a low data rate and a low cost can be provided.

[0030] According to the tenth option which can be combined with any one of the first to ninth options or any one of the first to fifth aspects, the client device can be a wearable device for uploading sensor data to the cloud device by directly communicating with the cloud server. Thus, for a load-balanced cloud service, the efficiency of direct sensor data upload can be achieved.

[0031] It should be noted that the above-mentioned apparatus can be implemented based on an arrangement of discrete hardware circuits, integrated chips or chip modules with discrete hardware components, or based on a signal processing device or chip controlled by a software routine or program stored in a memory, written on a computer-readable medium or downloaded from a network (e.g., the Internet).

[0032] It shall be understood that the apparatus of claim 1, the communication module of claim 8, the client device of claim 11, the method of claim 13 and the computer program product of claim 14 may have similar and / or identical embodiments, in particular, as defined in the dependent claims.

[0033] It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or the above-described embodiments with the respective independent claim.

[0034] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In the attached picture:

[0036] Figure 1 A block diagram schematically illustrates a network architecture according to an embodiment;

[0037] Figure 2 Schematically illustrating different end-to-end communication stacks for data ingestion;

[0038] Figure 3 schematically shows a message sequence diagram including a TLS handshake;

[0039] Figure 4 A flowchart schematically illustrates an enhanced session resumption process according to various embodiments; and

[0040] FIG. 5A to FIG. 5C Schematically a diagram showing measurement results of different implementations of session resumption including embodiments is shown. DETAILED DESCRIPTION

[0041] Embodiments of the present invention are now described based on a TLS session resumption process for a device (eg, a wearable device or other type of IoT device) accessing a cloud service.

[0042] Wearable devices are a class of technical devices with low processing power that can be worn by users for the purpose of providing information and easy access to the main device paired with it. Cloud computing is the main driving force behind the recent trend of wearable technology. As cloud computing continues to develop and becomes more convenient and available, it is expected that wearable technology will become more popular in offices and homes. Wearable devices typically require continuous network access to upload information (e.g., sensor data), while needing to maintain low energy consumption through intermittent sleep modes. Similar problems may apply to battery-powered sensors, because these battery-powered sensors need to save power, have more limited processing power, and need to upload data to a computer (e.g., server) via a network. It is highly desirable to reduce improvements in activities that can be considered as overhead (i.e., not actual data collection and transmission).

[0043] Figure 1 Schematically a block diagram of the architecture of a system according to a cellular embodiment is shown. More specifically, a direct to cloud (D2C) device 10 (which may be a wearable device) is shown in the context of cellular communication towards a cloud service (CS) provided by the Internet, for example.

[0044] The device 10 includes at least one sensor 110 for sensing various parameters (e.g., health and / or physiological parameters (e.g., vital signs), environmental parameters, system control parameters, etc.) to be uploaded to the cloud service. In addition, the device 10 includes a power supply unit (BATT) 140 (e.g., a battery or storage battery) for supplying energy to other components. The measured sensor data is processed by an application microcontroller unit MCU (AMCU) 120, which can be an intelligent semiconductor integrated circuit (IC) that can be composed of a processor unit, a memory module, a communication interface, and peripheral devices. The MCU can be programmed according to the specific application required to process the measured sensor data to communicate with the cloud service via a modem circuit (MDM) 130 (e.g., an LTE-M or NB-IoT modem). The modem circuit 130 can communicate with the cloud service via an access device (e.g., a base station or eNodeB) of a cellular network according to an upload protocol (UL PROT) to upload the processed sensor data.

[0045] LTE-M is a simplified industry term for the Long Term Evolution Machine Type Communication (LTE-MTC) Low Power Wide Area (LPWA) technology standard released by 3GPP in Release 13 specifications. It specifically refers to LTE Category M1 (CatM1) suitable for IoT environments. LTE-M is a low power wide area technology that supports IoT and provides extended coverage through lower device complexity while allowing the reuse of the LTE installed base. This allows battery life of up to 10 years or more for a wide range of use cases, with modem costs reduced to 20%-25% of conventional modems.

[0046] LTE Narrowband IoT (NB-IoT) is part of the LTE specification and has been designed to provide a low power solution with low data rates and low costs, which is ideal for IoT solutions. The NB IoT specification is also scheduled for 3GPP Release 13 and provides another MTC standard with even lower complexity than LTE-M (but also with lower bandwidth). Part of the 5G specification includes enhanced machine type communications (e MTC), which will be associated with the NB IoT and Category M LTE standards and form the basis for future MTC in 5G networks.

[0047] More specifically, the modem 130 may be a module that provides a so-called attention (AT) command interface. This may be a high-level AT interface, thereby implementing a full stack (e.g., as described below in conjunction with Figure 2 This means that some AT commands may be sufficient, for example, to complete an HTTPS transaction, including establishing the underlying TLS and TCP connections and performing a DNS lookup. Alternatively, such a stack may be implemented on the application MCU 120, but this may involve more development work.

[0048] As an implementation example of the D2C device 10, a wearable D2C vital signs monitoring device is proposed. The D2C device 10 can be connected to the cloud service "directly" via a cellular network without the need for any type of gateway or routing equipment, such as a mobile phone or Wi-Fi or broadband infrastructure. This enables reliable, out-of-box connection at any time and anywhere. In particular, it avoids all the hassles of having to pair the device with, for example, a Bluetooth or Wi-Fi network or having to board the device, for example, a Bluetooth or Wi-Fi network. This in turn can help to implement transitional care scenarios, such as hospital to home.

[0049] D2C can imply that the wearable device 10 communicates directly with the cloud service (eg, AWS) itself. AWS and other cloud providers use standard communication protocols, primarily IETF communication protocols.

[0050] Figure 2An overview of various end-to-end communication stacks for communicating with cloud services or other network services for data ingestion is shown. A communication stack is a Figure 1 Four examples of protocol combinations that the D2C wearable device 10 uses to transmit sensor data to a cloud service.

[0051] The communication stack starts with the common IP layer as a basic requirement for communication via the Internet. TCP or UDP can be used to transmit data. TCP is a connection-oriented protocol, while UDP is a connectionless protocol. The difference between TCP and UDP is the speed, as TCP is relatively slower than UDP. Overall, UDP is a faster, simpler, and more efficient protocol. However, TCP only supports retransmission and order preservation of lost data packets.

[0052] In particular, the D2C device 10 can be used with the corresponding Figure 2 The HTTP / TLS / TCP / IP stack of Hypertext Transfer Protocol Secure (HTTPS) and / or communicate with cloud services (e.g., AWS) with the help of Open Authorization (OAuth). OAuth is specifically designed to work with HTTP and essentially allows access tokens to be issued to third-party clients by an authorization server with the approval of the resource owner. The third party then uses the access token to access protected resources hosted by the resource server.

[0053] Alternatively, communication may be achieved with the aid of Message Queuing Telemetry Transport (MQTT), which is a lightweight, publish-subscribe machine-to-machine network protocol designed for connecting to remote locations with devices that have resource constraints or limited network bandwidth. Figure 2 The MQTT / TLS / TCP / IP stack.

[0054] Alternatively, a more lightweight cloud ingestion protocol can be used, such as Constrained Application Protocol (CoAP) over Datagram Transport Layer Security (DTLS) (which corresponds to Figure 2 CoAP / DTLS / UDP / IP stack), and recent developments in the IETF (e.g., Quick User Datagram Protocol (UDP) Internet Connections (QUIC)) (which corresponds to Figure 2 HTTP / QUIC / UDP / IP stack).

[0055] The TLS protocol (as described, for example, in RFC5246 (2008) or RFC8446 (2018)) provides end-to-end security for TCP data transmission. In particular, it protects confidentiality, integrity, and provides server authentication necessary for the communication of sensitive personal data (e.g., vital signs or other sensible measurement parameters). For UDP data transmission, the DTLS protocol (as described, for example, in RFC6347 (2012) or in draft-ietf-tls-dtls13-43 (2021)) is the same as above. The QUIC protocol covers the functionality of TLS version 1.3 (as described, for example, in RFC8446 (2018)) by providing reliability, order preservation, and secure transmission over UDP.

[0056] Therefore, wherever "TLS" is mentioned in the rest of this disclosure, applicable elements of DTLS or QUIC are also implied.

[0057] exist Figure 3 In , a message (flight) sequence diagram is depicted to illustrate the message (flight) sequence diagram between D2C devices (e.g. Figure 1 During the communication between the device 10), the DNS server and the cloud server providing the cloud service (CS) Figure 2 The overhead introduced by the exemplary HTTPS (HTTP / TLS / TCP / IP) stack. Figure 3 In the message sequence diagram, the time is Figure 3 The TLS handshake is included between the horizontal dashed lines.

[0058] To safely and reliably send a limited sequence of vital sign data (e.g., 100 bytes in length), approximately fifteen message flights are involved, and several kilobytes of data may have to be transmitted. In particular, server authentication is achieved by downloading a certificate chain, which may include several kilobytes of data.

[0059] Figure 3 The communication process begins with a DNS lookup, where the D2C device attempts to resolve the domain name of the desired cloud service request by sending a DNS request (DNS REQ) to a DNS server, and the DNS server responds with a DNS response (DNS RESP) including the IP address of the cloud server providing the desired cloud service.

[0060] In the subsequent connection phase, the D2C device (client) establishes a TCP connection with the received cloud server IP address by sending a synchronization packet (TCP SYN). The cloud server confirms the synchronization packet by responding with an acknowledgment packet (TCP SYN / ACK). The D2C device responds with an acknowledgment packet (TCP ACK), thus ending the three-way TCP connection establishment.

[0061] Next, for TLS version 1.2 (as described, for example, in RFC5246 (2008)), the TLS handshake process begins, which involves four message flights (exchanges), i.e., a four-way handshake. The endpoints (D2C device and cloud server) need the first two messages (TLS Client Hello (TLS CL Hello) and TLS Server Hello (TLS S Hello)) to agree on a cipher suite, and the cloud server needs the above first two messages to authenticate itself to the client with the help of the above certificate chain. The latter two flights (TLS Client Key Exchange (TLS CL KE) and TLS Change Cipher Specification (TLS CH CIPHSPEC)) are required to establish a shared session key, which is used in subsequent message exchanges (and in Figure 1 Encrypted communications (for confidentiality and integrity) are implemented during scenarios such as uploading vital signs or other sensor data.

[0062] Once a secure connection has been established, one or more message exchanges may occur. Each message exchange ( Figure 4 The first embodiment of the present invention comprises a sending phase, in which the D2C device sends an HTTP request (HTTP REQ) to the cloud server. Then, in the subsequent waiting phase, the D2C device waits for the cloud server to respond to the request. During the waiting phase, the cloud server processes the HTTP request, finds the resource (the desired cloud service), and sends an HTTP response (HTTP RES) to the D2C device that loaded the content in the loading phase.

[0063] Once the necessary message exchanges have occurred, the connection can be torn down (e.g., before the client device goes to sleep). Figure 3 In FIG. 5 , an exemplary sequence of five message flights is shown, which leads to the teardown of the connection at the TLS and TCP layers. The first two message flights in this example are TLS encryption alerts (TLS EA). This may be followed by two more message flights (TCP FIN, TCP FIN / ACK) for closing the connection (no more data) and a final TCP acknowledgement (TCP ACK). In practice, other message sequences may also occur that have the same effect as tearing down the connection.

[0064] Session resumption can be used to reduce the above four-way TLS handshake to a two-way handshake and avoid the download of certificates at the same time. This is done by reusing the negotiated session data (including session keys) from the previous session.

[0065] For TLS version 1.2, this can be achieved by session resumption using a session identifier (session ID) or by session resumption using a session ticket (as described, for example, in RFC5077 (2008)). In the former case, both the server and the client keep a record of the session data (the session ID is a unique index for this data), while in the latter case, the server encapsulates the session data into an encrypted data block (the key is known only to the server), the so-called session ticket, and transmits it to the client. Therefore, in the latter case, no session data is retained at the server. When the client wants to resume an earlier session, it must present the session ticket to the server again.

[0066] Because session tickets avoid keeping state on the server side, they are more scalable from the perspective of a cloud provider or other service provider. To manage their storage resources, a cloud server or other network server may choose to purge session data associated with a session ID within a relatively short time span (e.g., 10 minutes), thereby invalidating the session ID. As a result, session tickets may have a significantly longer lifespan than session IDs (e.g., 12 hours versus 10 minutes), making them more suitable for wearable devices that wake up every few hours.

[0067] TLS version 1.3 (as described, for example, in RFC8446 (2018)) reduces the four-way handshake for initial session creation to a two-way handshake, and supports a similar mechanism for session resumption. Moreover, in this case, the download of the certificate chain is avoided, and optionally the handshake can even be reduced to no message flight at all. This option is called 0-RTT (RTT = Round Trip Time). Although technically there is still a two-way handshake for 0-RTT, the data traffic for this handshake can be piggybacked on other messages. Therefore, no additional message flight is required.

[0068] Therefore, TLS can provide a reduced handshake to save protocol overhead by reusing previously exchanged keys. As an example, TLS session resumption can reduce the number of message flights by two and can reduce payload size by up to 50% by avoiding repeated downloads of the same certificate chain.

[0069] However, many cloud services or other network services use multiple server nodes with load balancing, and therefore may not be able to handle TLS session resumption by themselves. Therefore, when the device is switched to a different node when the session is resumed, the device and the new server need to complete the full handshake protocol.

[0070] Therefore, TLS session resumption in conjunction with load-balanced network services (e.g., cloud services) may not be very efficient. As described above, many network services (e.g., cloud services) use multiple server nodes with load balancing, where devices can switch between nodes and switch between connections over time. Such server configurations are typically unable to handle TLS session resumption on their own. Therefore, when a device is switched to a different node upon resumption, the device and the new server need to complete a full handshake protocol.

[0071] The Open Systems Interconnection (OSI) model describes seven layers that computer systems use to communicate over a network. The seven layers are: physical layer (layer 1, used, for example, to electrically or optically transmit raw unstructured data bits across a network), data link layer (layer 2, used, for example, to manage node-to-node data transfer, where data is packaged into frames), network layer (layer 3, used, for example, to receive frames from the data link layer and deliver them to their intended destination based on the addresses contained within the frames), transport layer (layer 4, used, for example, to manage the delivery and error checking of data packets), session layer (layer 5, used, for example, to control conversations between different nodes, including authentication and reconnection), presentation layer (layer 6, used, for example, to format or convert data for the application layer based on the syntax or semantics accepted by the application), and application layer (layer 7, used, for example, to identify communication partners and resource availability, and to synchronize communications between end users and / or software applications).

[0072] Different types of load balancing are possible, and a given provider may use more than one type of load balancing. For example, one particular provider offers three different types of load balancers, namely: a Classic Load Balancer (CLB) that operates at OSI Layer 4 and OSI Layer 7 and in which the Internet Protocol (IP) address changes over time, an Application Load Balancer (ALB) that operates at OSI Layer 7 and in which the IP address changes over time, and a Network Load Balancer (NLB) that operates at OSI Layer 4 and in which the IP address remains the same.

[0073] To reduce the time and network traffic spent in the initial handshake process, the client can request session resumption from a server that previously shared a session with the client. Thus, the handshake process can be shortened. To support session resumption, the server can store session security parameters in a local database or use session tickets to delegate storage to the client. The type of session resumption supported (e.g., by AWS) and the extent of session resumption depends on the type of load balancer deployed.

[0074] According to the example, CLB supports session resumption based on session ID, but does not support session resumption based on session ticket. Session caching is supported at the node level. This means that if a client connects to a second node (B) using a session ID received from a first node (A), the handshake returns to a full handshake. Thereafter, a new session ID is generated by the second node (B).

[0075] According to another example, the ALB supports both session ID-based session resumption and session ticket-based session resumption. Both session ID and session ticket are supported at the node level. This means that if a client connects to a second node (B) using a session ID or session ticket received from a first node (A), the handshake returns to a full handshake. Thereafter, a new secure socket layer (SSL) session ID and session ticket are generated by the second node (B).

[0076] According to a further example, the NLB supports only session tickets for session resumption. Resumption using session tickets is supported at the zone level. The client can resume a Transport Layer Security (TLS) session with the NLB using any of its IP addresses.

[0077] This means that session recovery across nodes is not possible with CLB and ALB. While it is possible with NLB, not all cloud or other network service deployments use NLB.

[0078] As an example, when a DNS lookup is performed on a load-balanced non-NLB endpoint, a list of IP addresses may be returned. The client typically selects the first IP address from the list, but this is not mandatory. Since the time to live (TTL) for this lookup is often small (e.g., 60s), a new DNS lookup must be performed each time the client wakes up, and this may result in a different list of IP addresses.

[0079] Energy consumption and data communication costs are important criteria for cellular or other network devices, especially for small form factor wearables or other IoT devices. Therefore, minimizing the amount of data transmitted is an important design consideration. For non-cellular devices (e.g., Wi-Fi or other wired or wireless network devices), energy consumption may still be relevant.

[0080] Standard protocols for data ingestion (i.e., obtaining and importing data) for cloud services can introduce significant overhead in terms of the number of messages (flights) exchanged and in terms of payload. This is especially true if the net amount of data to be uploaded as part of a single transaction is relatively small (e.g., only a hundred bytes of vital signs) and if the period between transactions is long (e.g., 2 hours), such that the cellular communication modem needs to go into sleep mode to save energy. The latter can be relevant because it causes connections at different layers in the stack (e.g., Transmission Control Protocol (TCP), TLS, etc.) to be interrupted, requiring them to be set up again from scratch for the next transaction.

[0081] Figure 4 A flowchart of an enhanced session recovery process according to various embodiments of a load-balanced network service is schematically shown, which may be performed by Figure 1 The application is executed by MCU 120.

[0082] In step S400, the process is performed by a client device (e.g., Figure 1 The wearable D2C device 10 is triggered by a wake-up action (WU).

[0083] The process (or processing MCU) is configured to maintain a list of tuples (IP address, session ticket) across iterations of session start and / or resume. Initially, the list is empty. Each iteration begins with the modem (e.g. Figure 1 The modem 130 in the example embodiment of the present invention wakes up from sleep (i.e., a state in which it does not communicate with the server and generally consumes less energy) to initiate communication. As mentioned above, the time between iterations can be long, for example, several hours.

[0084] After waking up from hibernation in step S400 , a DNS lookup (DNS-LU) to the cloud service is performed in step S410 to obtain a list of valid IP addresses from the DNS server.

[0085] Then, in optional step S420, entries with expired session tickets obtained from the stored and maintained (IP address, session ticket) tuple list are purged (PU).

[0086] Then, in step S430, the remaining IP addresses obtained by the DNS lookup in step S410 are compared (CA) with the IP addresses of the tuples in the stored list.

[0087] If an address match (AM) is determined in the subsequent step S440 (i.e., at least one of the IP addresses of the DNS lookup matches the IP address of one of the tuples in the list), the process branches to step S450, in which a shortened handshake (SHS) is performed toward the IP address using the stored session ticket of the corresponding tuple of the matching IP address.

[0088] Otherwise, if it is determined in step S440 that no address matches, the process branches to step S460, where a new full handshake (FHS) is started with the arbitrary IP address from the DNS lookup. Then, in step S470, the arbitrarily selected IP address and the new session ticket obtained from the full handshake are added (ATL) as a new tuple to the maintained tuple list.

[0089] If the previous DNS lookup has not expired, i.e., if it is still within the TTL duration, the DNS lookup in step S410 can be avoided or skipped. In this case, the previous IP address can simply be reused for session resumption. However, for a user with a wearable D2C device 10 Figure 1 In the exemplary scenario of or similar scenarios, the time between iterations (e.g., 2 hours) is much longer than the TTL (e.g., 60 seconds).

[0090] Additionally, the session ticket may have a limited validity (lifetime). This information is encoded in the ticket itself (e.g., as used in step S420). However, this lifetime should not be confused with the DNS TTL duration described above.

[0091] One of the benefits of the present embodiments is that they can be implemented exclusively on the client side, and no changes are required on the server side (eg, cloud side). Therefore, the proposed shortened session resumption or accelerated session resumption does not require any modification on the network / server side.

[0092] As an example, the proposed shortened session resumption or accelerated session resumption of the embodiments described herein may be performed on a client device (e.g., Figure 1 D2C device 10) is implemented, for example, by making the device firmware suitable for implementing the above combination Figure 4 More specifically, two distinct deployment scenarios can be envisioned. In a first example, the implementation can be implemented as a host processor (e.g., Figure 1 In a second example, the implementation may be implemented as part of a device application code on an application MCU 120. In a second example, the implementation may be implemented as a wired or wireless (e.g., cellular, WiFi, etc.) modem (e.g., Figure 1 The modem 130) is implemented as part of its firmware.

[0093] According to an alternative embodiment, the session ticket can be modified (simplified) by only remembering (storing) the last tuple (i.e., the last IP address and associated session ticket). Figure 4 This results in simplified control flow and reduced storage requirements.

[0094] Therefore, after waking up from sleep in step S400, a DNS lookup is initiated in step S410 to obtain a list of valid IP addresses. Then, step S420 is skipped (not required), and the IP address in the obtained list is directly compared with the last IP address used for the previous session in a modified step S430.

[0095] Then, in modified step S440, it is checked whether one of the IP addresses in the list obtained from the DNS lookup matches the IP address used for the previous session (previous iteration), and whether the corresponding session ticket is still valid. If it is determined that the addresses match and the session ticket is still valid, the process branches to step S450, where a shortened handshake is performed towards the matching IP address using the associated session ticket of the stored tuple.

[0096] Otherwise, if it is determined that no address matches or if the session ticket is no longer valid, the process branches to step S460 where a new full handshake is started with an arbitrary IP address selected from the DNS lookup. The selected IP address and associated session ticket are then stored as a new tuple for the previous session in step S470.

[0097] It should be noted that if the period between uploads (session resumptions) is greater than a predetermined fraction (e.g., 50%) of the session ticket lifetime, then Figure 4 The embodiment can be configured to return to an alternative (simplified) embodiment.

[0098] As an example, in the case where it is known in advance that the upload period of the client device will be greater than half the lifetime of the session ticket, a process according to an alternative simplified embodiment may be activated instead of activating a process according to Figure 4 In the case where the upload period is a fixed given period, it can be decided at design time or during the setup of the client device. Otherwise, if the client device has multiple operation modes (for example, the D2C vital signs monitoring device uploads much more frequently when the patient is still in the hospital than when the patient returns home from the hospital), the client device can be reconfigured for another upload period, and upon such reconfiguration, the client device can also be reconfigured to use the process of the simplified embodiment or the process of the enhanced embodiment.

[0099] In an example, a ticket with a 12 hour lifespan uploaded every 8 hours may be used in the client device. Then, upon wakeup, an 8 hour old ticket may be stored (which will expire in 4 hours) that does not match any of the addresses in the DNS lookup. Therefore, a full handshake will be required to create a new second ticket. In this case, Figure 4 The enhanced embodiment will store two tickets (where the old ticket that has existed for 8 hours will not be applicable to the next iteration), while the simplified embodiment will only save the latest ticket. In other words, less storage space will be required by switching to the simplified embodiment.

[0100] In another modification, Figure 4 Embodiments may be configured to also purge tuples for session tickets that are still valid in order to save storage. This may occur either in step S420, for example by (conditionally) purging the tuple with the oldest expired ticket (e.g., if there are no other tuples to purge), or in step S470 when the storage is full and the oldest tuple should be replaced with a new tuple.

[0101] Each of the embodiments described herein can be implemented using a session ID instead of a session ticket. However, it should be considered that a session ID may have a shorter lifespan.

[0102] In order to evaluate the combination Figure 4 To describe the effectiveness of the two aforementioned embodiments with respect to the conventional session recovery process, a simulation has been performed for a scenario where a wearable D2C device uploads some vital signs to a load-balanced cloud service once every two hours.

[0103] For this experiment, DNS requests were sent to a DNS server once every two hours to resolve a fully qualified domain name associated with an Application Programming Interface (API) Gateway service hosted by AWS. The API Gateway is a server that provides a single entry point into the system via an API customized for each client. The list of IP addresses returned by the corresponding DNS response was recorded. Subsequently, the sequence of these IP address lists was used as input to simulate different candidate algorithms of the above embodiment and conventional session recovery, and the number of sessions that could be recovered was counted. In particular, the number of sessions that could be recovered was counted for each session. Figure 4 The algorithm of each of the above embodiments is compared with a direct ("naive") conventional session resumption process based on the latest session ticket.

[0104] It should be noted that the API Gateway service used supports node-level session tickets, and these session tickets have a validity of 12 hours. The latter parameter is taken into account when evaluating the embodiments. That is, session tickets from at most 5 iterations ago can still be used to successfully resume a session (5×2 hours < 12 hours).

[0105] FIG. 5A to FIG. 5C Schematically illustrates different implementations for session recovery (including simple session recovery ( Figure 5A ) and the above two embodiments ( Figure 5B and Figure 5C )) of a simulation of the invention. The horizontal axis of the figure shows fifty consecutive iterations of the experiment. The vertical axis shows fourteen different IP addresses A1 to A14 of different nodes of the cloud service, as observed in any of the DNS responses in the DNS responses. Successfully resumed sessions are indicated by black triangles. In addition, black squares are used to indicate addresses that were selected for a full handshake. Such addresses are selected to establish connections for which no valid session ticket exists (i.e., a full handshake must be performed), while black triangles indicate addresses that were selected and for which a session can be successfully resumed (and therefore a shortened handshake can be performed). The black dots are the remaining addresses, i.e., those addresses that were returned by the DNS lookup but were not selected for establishing any connection.

[0106] Figure 5A The results of a naive (conventional) implementation of TLS session resumption, such as described above, are shown. The first IP address in the list returned by the DNS response is recorded each time. If this IP address is equal to the IP address recorded for the previous iteration, the resumed session is counted and marked as a black triangle in the row of the relevant node. Figure 5A From the graph of , it can be seen that the session resumption succeeded only in 4 out of 50 iterations. In other words, an effectiveness of 8% can be achieved. Note that in this way, no single IP address in a row is used more than five times (i.e., the session ticket is therefore still valid).

[0107] Figure 5B As shown above Figure 4 The results of the simplified (alternative) embodiment (without step S420) of . Here, in 15 iterations out of 50 iterations, the session recovery is successful. In other words, an effectiveness of 30% can be achieved.

[0108] Figure 5C As shown above Figure 4 Here, session resumption succeeded in 26 out of 50 iterations. In other words, an effectiveness of 52% can be achieved.

[0109] The following table presents an overview of the effectiveness of the different options measured in the experiment. Figure 4The two embodiments are compared with a naive implementation, and the options of no session resumption at all, and full session resumption across nodes (i.e., using NLB). Note that for session resumption across nodes, the 12-hour validity of the session ticket means that a full handshake is still required in 1 / 6 of the cases. Therefore, the validity becomes 83%.

[0110]

[0111] Session resumption across nodes can be achieved by configuring a cloud service that supports this (e.g., NLB as described initially). This requires adaptation on the server side (e.g., cloud side), which may not be possible in all scenarios, for example, where the device manufacturer does not have control over the server side or chooses not to adapt it for other reasons.

[0112] Obviously, the above experimental results are highly specific to the battery-powered sensor / wearable D2C scenario and the choice and configuration of the cloud service. In particular, for any application with much more frequent uploads relative to the session ticket lifetime, the efficiency gain of the proposed embodiment can be much larger and can approach the efficiency gain of session resumption across nodes.

[0113] Other experiments with D2C devices have shown that uploads using the resumed handshake consume up to 33% less energy than uploads using the full handshake. This means that for Figure 4 A full embodiment of , can achieve a total energy reduction of up to 17% (52% of 33%) in cellular communications. The relative gains in energy consumption could be even greater in cases where the overhead of connecting to the network (cellular, Wi-Fi or other) would be smaller. The experiments involved the modem being powered off between uploads, which meant that it needed to reattach to the cellular network each time before IP communication became possible, reducing the relative gain of any optimization at the IP level. This means that embodiments that put the modem into a smarter sleep mode (called PSM) could show even higher relative gains.

[0114] The relative gain in transmitting data over the cellular network, and therefore the associated data cost, can be as high as a factor of 2. That is, in one example of uploading 100B of vital signs data, approximately 3kB of credentials are downloaded as part of a total of approximately 6kB of data exchange at the IP level.

[0115] For future protocols that require less handshakes (e.g., TLS 1.3, QUIC), the relative improvements in energy consumption and data volume will be greater.

[0116] As described above, the process / algorithm of the above-described embodiments may be implemented in a modem module of a client device (e.g., Figure 1 modem 130) or an application MCU (e.g., Figure 1 In the first case of modem implementation, the modem module can be used for various different client devices independent of the application MCU.

[0117] Alternatively, embodiments may be used as an exclusive feature of a specific client device to achieve longer battery life (or lower battery cost / form factor) and lower cellular communications expenses. In this case, the algorithm may be implemented on the application MCU instead.

[0118] In summary, methods and apparatus for increasing the likelihood that a device or application will be able to resume a previously established session (e.g., a transport layer security session) with a load-balanced network service (e.g., a cloud service) that may only support node-level load balancing have been described. This may be accomplished by maintaining valid session tickets (or identifiers) and one or more network addresses for individual nodes (e.g., servers) of the network service for a previous communication session, and selecting a particular node from a list of potential nodes returned by an address lookup (e.g., a domain name system (DNS) lookup) for a subsequent communication session based on a match of the particular node to one of the one or more network addresses and the session ticket or session identifier.

[0119] Although the present invention has been illustrated and described in detail in the drawings and the foregoing description, such illustration and description are considered to be illustrative or exemplary rather than restrictive. It should be understood that the embodiments can be combined, and the features of any embodiment in the embodiments can be used in combination with another embodiment. The present invention is not limited to the disclosed embodiments. The present invention can be applied to, for example, any type of biosensor to measure heart rate and / or respiratory rate or other physiological parameters by directly linking the biosensor to a clinical information system without requiring any hub or mobile phone for the patient. By achieving long battery life (e.g., cellular or Wi-Fi), this is also applicable to other small form factor (i.e., comfortably wearable), energy-constrained devices. In addition, this can be applied to help reduce the data communication costs of any type of cellular IoT devices (e.g., automated external defibrillators (AEDs) and respiratory devices) that send (small amounts of) application data.

[0120] However, the proposed concept of accelerated session resumption or shortened session resumption has broader applicability. Basically, any energy-constrained wired or wireless device that connects directly to a cloud service using a standard (secure and reliable) IP protocol can benefit, at least if the application payload is small relative to the protocol overhead.

[0121] Furthermore, the proposed improvements for session resumption can be implemented in all types of wired or wireless networks, for example, can be applied to devices or applications communicating using cellular wireless communication standards, in particular the 3rd Generation Partnership Project (3GPP) 5G and New Radio (NR) specifications. The communicating devices or applications can be different types of devices, for example, mobile phones, smart watches, smart tags for location tracking and logistics, commissioning devices, applications or tools, vehicles (for vehicle-to-vehicle (V2V) communication or more general vehicle-to-everything (V2X) communication), V2X devices, IoT devices (including low-power medical sensors for health monitoring), medical (emergency) diagnostic and treatment devices for hospital use or first responders, virtual reality (VR) headsets, etc., and can be used, for example, in ProSe and / or Personal IoT Networks (PINs) focused on UE-to-UE.

[0122] Furthermore, the proposed improvements for session resumption can be used in applications such as Wi-Fi, cloud access, browser synchronization, electronic passports, in the Thread network protocol for IoT devices, in standards developed by standards development organizations (SDOs) (e.g., IEEE, ISO / IEC, or IETF), in the IEEE 802.11 family of protocols and WiFi Protected Access (e.g., WPA3, e.g., in combination with Simultaneous Authentication of Equivalents (SAE)), in protocols for Transport Layer Security (e.g., TLS1.3) or Internet Key Exchange (e.g., IKEv2).

[0123] Additionally, the present invention may be applied to the following scenarios: medical applications or networked healthcare in which multiple wireless (e.g., 4G / 5G) connected sensor or actuator nodes participate; medical applications or networked healthcare in which wireless (e.g., 4G / 5G) connected devices occasionally consume or generate data streams with a specific average data rate, for example, video, ultrasound, X-ray, computed tomography (CT) imaging equipment, real-time patient sensors, audio or voice or video streaming devices used by medical staff; general IoT applications involving wireless, mobile or fixed sensor or actuator nodes (e.g., smart cities, logistics, agriculture, etc.); emergency services and critical communications applications; V2X systems; systems that use high-frequency (e.g., mmWave) RF to improve 5G cellular network coverage; and any other application areas of 5G communications using relays.

[0124] By studying the drawings, the disclosure and the appended claims, those skilled in the art can understand and implement other variations of the disclosed embodiments when practicing the claimed invention. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The foregoing description details specific embodiments of the invention. However, it should be understood that no matter how detailed the foregoing is in context, the present invention can be practiced in many ways and is therefore not limited to the disclosed embodiments. It should be noted that the use of a specific term in describing certain features or aspects of the present invention should not be taken as implying that the term is redefined herein to be limited to including any specific characteristics of the features or aspects associated with the term.

[0125] Furthermore, in those instances where a convention similar to “at least one of A, B, and C, etc.” is used, generally, such interpretation is intended to have the meaning as understood by those skilled in the art for such convention, e.g., “a system having at least one of A, B, and C” would include, but is not limited to: a system having only A, a system having only B, a system having only C, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B, and C, etc. In those instances where a convention similar to “at least one of A, B, or C, etc.” is used, generally, such interpretation is intended to have the meaning as understood by those skilled in the art for such convention, e.g., “a system having at least one of A, B, or C” would include, but is not limited to: a system having only A, a system having only B, a system having only C, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B, and C, etc. Those skilled in the art will further understand that any disjunctive words and / or phrases that actually present two or more alternative terms, whether in the specification, claims or drawings, should be understood to contemplate the possibility of including one, either or both of the terms. For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B".

[0126] A single unit or device may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0127] The operations described (such as Figure 4The operations indicated in (i) may be implemented as program code units of a computer program and / or dedicated hardware of the D2C device or another client device. The computer program may be stored and / or distributed on a suitable medium (e.g., an optical storage medium or a solid-state medium) supplied together with or as part of other hardware, but may also be distributed in other forms, for example, via the Internet or other wired or wireless telecommunication systems.

Claims

1. An apparatus located in a client device, the apparatus being used to control the initiation of a communication session between the client device (10) and a network node, wherein: The device is suitable for: maintaining (S470) a list comprising a plurality of tuples, wherein the tuples comprise: a network address of an individual network node and an associated session ticket or session identifier, wherein the individual network node provides a target network service (CS) and was used by the client device (10) for a previous communication session; selecting (S430, S440) a network node for a subsequent communication session from the list of potential nodes returned by the address lookup (S410) based on a match of the network address of the network node with one of the one or more network addresses and an associated session ticket or session identifier; and The matched network address and the associated session ticket or session identifier are used for session resumption with the selected network node (S450).

2. The device according to claim 1, wherein: The apparatus is adapted to: purge (S420) network addresses associated with expired session tickets or session identifiers, and compare (S430) remaining network addresses obtained by the address lookup (S410) with the network addresses maintained in the tuple in the stored list to identify (S440) a network node for session resumption (S450).

3. The device according to claim 2, wherein: The apparatus is adapted to conditionally clear (S420 / S470) network addresses associated with unexpired session tickets or session identifiers in order to save storage space.

4. An apparatus according to any preceding claim, wherein: The target network service (CS) is a load-balanced network service, and in particular, the target network service is a load-balanced cloud service.

5. An apparatus according to any preceding claim, wherein: The apparatus is adapted to perform the session resumption according to a transport layer security protocol.

6. An apparatus according to any preceding claim, wherein: The communication session is used for data ingestion to the cloud service.

7. A communication module (130), comprising the device according to any one of claims 1-6.

8. The communication module according to claim 7, wherein: The communication module includes a modem (130) configured to provide an attention command interface for implementing an end-to-end communication stack for data ingestion communications.

9. The communication module according to claim 8, wherein: The modem (130) is adapted to perform a communication session with a network server via a cellular access device using a Long Term Evolution (LTE) machine type communication protocol or a LTE narrowband Internet of Things protocol.

10. A client device (10), comprising the apparatus according to any one of claims 1-7.

11. The client device (10) according to claim 10, wherein: The client device (10) is a wearable device for uploading sensor data to a cloud device by directly communicating with a cloud server.

12. A client device method for controlling the initiation of a communication session between a client device (10) and a network node, wherein: The method comprises: maintaining (S470) a list of one or more tuples, wherein the tuples include: a network address of an individual network node and an associated session ticket or session identifier, wherein the individual network node provides a target network service (CS) and was used for a previous communication session; selecting (S430, S440) a network node for a subsequent communication session from the list of potential nodes returned by the address lookup (S410) based on a match of the network address of the network node with one of the one or more network addresses and an associated session ticket or session identifier; and The matched network address and the associated session ticket or session identifier are used for session resumption with the selected network node (S450).

13. A computer program product comprising code means for producing the steps according to claim 12 when the code means are executed on a computer device.

Images