Fast session resumption in load-balanced network services

Abstract

The present invention relates to a method and device for increasing the likelihood that a device can resume a previously established session (e.g., a Transport Layer Security session) with a load balancing network service (e.g., a cloud service) that can only support load balancing at the node level. This is achieved by maintaining one or more network addresses and valid session tickets (or identifiers) of individual nodes (e.g., servers) of the network service that were used for the previous communication session, and selecting a particular node for a subsequent communication session from a list of potential nodes returned by an address lookup (e.g., a Domain Name System (DNS) lookup) based on a match with one of the one or more network addresses and the session ticket or identifier.

Description

[Technical Field]

[0001] The present invention relates to session resumption procedures for devices and / or applications in wired or wireless networks, such as, but not limited to, load-balancing cloud services. [Background technology]

[0002] Internet of Things (IoT) devices frequently use sleep to reduce power consumption, which interrupts communication sessions with the network. Often, these sessions use security protocols such as Transport Layer Security (TLS) for privacy, and these sessions are also interrupted.

[0003] To meet demand and reduce workload, mechanisms distribute workload across multiple servers (called "load balancing"). Load balancing distributes network traffic evenly to prevent failures caused by overloading a particular resource. This strategy improves the performance and availability of applications, websites, databases, and other computing resources. It also helps process user requests quickly and accurately.

[0004] Load balancing is often used in server farms that run high-traffic websites. It is also used for DNS (Domain Name System) servers, databases, and FTP (File Transfer Protocol) sites. By routing user requests evenly among a group of servers, load balancing devices minimize the chance of downtime. In the event of a failure, they do this by rerouting traffic to other servers in the group. When you add a new server to the server pool, the load balancing device automatically includes it in the traffic distribution process.

[0005] Load balancing thus enables a service provider (e.g., a cloud service provider) to distribute the load of requests across multiple physical servers (also known as nodes), providing scalability and availability.

[0006] When an IoT device wakes up, it needs to resume the session. A brute force solution would be to redo the full handshake procedure to get all the information needed to resume the session, which often presents a significant overhead for very small message payloads. Summary of the Invention [Problem to be solved by the invention]

[0007] An object of the present invention is to improve the efficiency of initiating communication sessions in connection with load-sharing services. [Means for solving the problem]

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

[0009] According to a first aspect, there is provided a device for controlling initiation of a communication session between a client device and a network node, the device comprising: maintain a list including a plurality of tuples, the tuples including a network address and an associated session ticket or session identifier of each network node that provides the target network service and that has been used by the client device for a previous communication session, the device further comprising: Select a 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 with one of the one or more network addresses and an associated session ticket or identifier, and use the matched network address and associated session ticket or identifier for session resumption with the selected network node.

[0010] According to a second aspect, there is provided a communications module comprising the device of the first aspect, whereby the client device can be upgraded or expanded by adding or implementing a communications module of the second aspect.

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

[0012] 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, the method comprising:

[0013] maintaining a list comprising a plurality of tuples, each tuple including a network address and an associated session ticket or session identifier of each network node that provides the target network service and that was used in the previous communication session; The method includes selecting a network node for a subsequent communication session from a list of potential nodes returned by the address lookup based on a match of the network address with one of the one or more network addresses and an associated session ticket or identifier, and using the matched network address and associated session ticket or identifier for session resumption with the selected network node.

[0014] According to a fifth aspect, there is provided a computer program product comprising code means for generating the steps of the method according to the fourth aspect when executed on a computing device.

[0015] 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, upon waking up from sleep, perform an address lookup (e.g., DNS lookup) of a desired target network service (e.g., a cloud service) to obtain a list of valid network addresses (e.g., IP addresses), maintain at least one entry having a network address and a valid session ticket or identifier from one or more previous communication sessions, and check whether at least one of the network addresses from the address lookup matches the maintained at least one network address. If a match is determined, the stored associated session ticket or identifier can be used to initiate an abbreviated (expedited) handshake to the matching network address.

[0016] The proposed extended session resumption procedure enables a reduction in protocol overhead that is independent of server capabilities. This allows for low protocol overhead in terms of the number of message flights and certificate chains received and exchanged, respectively, reducing energy consumption and data costs. This is particularly advantageous for energy-constrained wearable devices, such as cellular-connected wearable devices. A message flight should be understood as a sequence of one or more packets going in one direction (i.e., from client to server or from server to client). The next message flight occurs when the communication changes direction (i.e., from server to client or from client to server).

[0017] According to a first option, which can be combined with any of the first to fifth aspects above, network addresses corresponding to expired session tickets or identifiers can be purged, 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 network nodes for session resumption, thereby achieving an increased chance of abbreviated session resumption, since the number of available session tickets or identifiers is increased according to the length of the maintained list.

[0018] According to a second option, which can be combined with any of the first to fifth aspects above, only the last network address and associated session ticket or identifier used in 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. This can simplify the proposed extended session resumption by storing only the last tuple (i.e., the last IP address and the associated session ticket). This simplifies the control flow and reduces storage requirements.

[0019] According to a third option, which can be combined with the first or second option or any of the first to fifth aspects, the first option can be configured to revert to the second option if it is determined that the period between successive session resumptions is longer than a predetermined fraction of the lifetime of the session ticket or identifier. This achieves a trade-off between increased opportunities for abbreviated session resumption and simplified control flow and reduced storage requirements when the probability that a session ticket or identifier is valid for a previous session older than one period is too low. According to a fourth option, which can be combined with any of the first to third options or any of the first to fifth aspects, network addresses associated with unexpired session tickets or identifiers can be conditionally purged to save storage space.

[0020] According to a fifth option that can be combined with any of the first to fourth options or any of the first to fifth aspects, the target network service can be a load-balanced network service, in particular a load-balanced cloud service, thereby increasing the chance of a shortened session resumption for network services provided by a load-balanced server farm.

[0021] According to a sixth option, which can be combined with any of the first to fifth options or any of the first to fifth aspects, the session resumption can be performed in accordance with the Transport Layer Security (TLS) protocol, thereby improving the abbreviated session resumption options provided by the TLS protocol for load-balanced network services.

[0022] According to a seventh option, which can be combined with any of the first to sixth options or any of the first to fifth aspects, the communication session can be used for data retrieval for a cloud service, which provides the advantage that the efficiency of data upload by a client device having a sleep phase can be improved due to the availability of a shortened session resumption procedure.

[0023] According to an eighth option that can be combined with any of the first to seventh options or any of the first to fifth aspects, the communication module of the second aspect can include a modem configured to provide an attention (AT) command interface for implementing an end-to-end communication stack for data capture communication. Thus, a small number of AT commands are sufficient for connection setup and address lookup, thereby improving communication efficiency.

[0024] According to a ninth option, which can be combined with any of the first to eighth options or any 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 IoT protocol, thereby providing a low data rate and low cost, low power solution.

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

[0026] It should be noted that the above-described apparatus may be implemented based on a discrete hardware circuit having an arrangement of discrete hardware components, integrated chips, or chip modules, or based on a signal processing device or chip controlled by a software routine or program stored in memory, written onto a computer-readable medium, or downloaded from a network such as the Internet.

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

[0028] It is to be understood that preferred embodiments of the invention can be any combination of the dependent claims or the above embodiments with the respective independent claim.

[0029] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. [Brief explanation of the drawings]

[0030] [Figure 1] FIG. 1 illustrates a schematic block diagram of a network architecture according to an embodiment. [Figure 2] 1A-1C are schematic diagrams illustrating different end-to-end communication stacks for data ingestion. [Figure 3] 1 is a diagram illustrating a schematic of the message sequences that comprise a TLS handshake. [Figure 4] 1 is a schematic flow diagram of an enhanced session resume process in accordance with various embodiments. [Figure 5A] 1 is a schematic diagram illustrating measurement results of different implementations of session resumption, including an embodiment. [Figure 5B] 1 is a schematic diagram illustrating measurement results of different implementations of session resumption, including an embodiment. [Figure 5C] 1 is a schematic diagram illustrating measurement results of different implementations of session resumption, including an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0031] An embodiment of the present invention will be described based on a TLS session resumption procedure for devices (such as wearable devices or other types of IoT devices) that access cloud services.

[0032] Wearable devices are a category of technology devices with low processing power that can be worn by a user for the purpose of providing information and facilitating access to a master device with which they are paired. Cloud computing has been a driving force behind the recent trend in wearable technology. As cloud computing continues to advance and become more convenient and usable, wearable technology is expected to become even more popular in offices and homes. Wearable devices typically require continuous network access to upload information (e.g., sensor data), while energy consumption must be kept low through intermittent sleep modes. Similar concerns apply to battery-powered sensors in that they need to conserve power, have more limited processing power, and must upload data over a network to a computer (e.g., a server). Improvements that reduce activities considered overhead (i.e., not actual data collection and transfer) are highly desirable.

[0033] 1 shows a schematic block diagram of a system architecture according to a cellular embodiment. More specifically, a Direct-to-Cloud (D2C) device 10 (which may be a wearable device) is shown in the context of cellular communication to a Cloud Service (CS), for example provided by the Internet.

[0034] 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 a cloud service. Furthermore, the device 10 includes a power supply unit (BATT) 140 (e.g., a battery or accumulator) for supplying energy to other components. The measured sensor data is processed by an application microcontroller unit (MCU) 120, which may be an intelligent semiconductor integrated circuit (IC) that may consist of a processor unit, a memory module, a communication interface, and peripherals. The MCU can be programmed according to the specific application required to process the measured sensor data for communication 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 a cellular network access device (e.g., a base station or eNodeB) according to an upload protocol (UL PROT) for uploading the processed sensor data.

[0035] LTE-M is the abbreviated industry term for the LTE-MTC (Long Term Evolution Machine Type Communication) low-power wide-area (LPWA) technology standard published by 3GPP in its Release 13 specification. It specifically refers to LTE Category M1 (CatM1), which is suitable for IoT environments. LTE-M is a low-power wide-area technology that supports IoT through lower device complexity and provides extended coverage while allowing reuse of the LTE installed base. This enables battery life of 10 years or more for a wide range of use cases, and modem costs are reduced to 20-25% of traditional modems.

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

[0037] More specifically, modem 130 can be a module that provides a so-called attention (AT) command interface. This can be a high-level AT interface that implements a complete stack as described below in connection with FIG. 2. This means that, for example, a small number of AT commands are sufficient to complete an HTTPS transaction, including performing a DNS lookup as well as setting up the underlying TLS and TCP connections. Alternatively, such a stack can be implemented on application MCU 120, but this may involve more development effort.

[0038] As an example implementation of the D2C device 10, a wearable D2C vital signs monitoring device is proposed. The D2C device 10 can connect "directly" to cloud services via a cellular network without the need for any type of gateway or routing device, such as a cellular, Wi-Fi, or broadband infrastructure. This enables reliable, anytime, anywhere, out-of-the-box connectivity. In particular, it avoids all the hassle of having to pair or onboard a device to, for example, a Bluetooth or Wi-Fi network. This, in turn, can help enable transitional care scenarios, such as hospital-to-home.

[0039] D2C means that the wearable device 10 itself communicates directly with a cloud service such as AWS. AWS and other cloud providers use standard communication protocols, most of which are IETF.

[0040] Figure 2 shows an overview of various end-to-end communication stacks for data capture communication with a cloud service or other network service. These communication stacks are four examples of protocol combinations that the D2C wearable device 10 of Figure 1 can use to communicate sensor data to a cloud service.

[0041] The communication stack starts with the common IP layer as the basic requirement for communication over the Internet. Data can be communicated using TCP or UDP. TCP is a connection-oriented protocol, while UDP is a connectionless protocol. The difference between TCP and UDP is speed, with TCP being relatively slower than UDP. Overall, UDP is a much faster, simpler, and more efficient protocol. However, retransmission of lost data packets and order preservation are only supported by TCP.

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

[0043] Alternatively, communication can be achieved through Message Queue Telemetry Transport (MQTT), a lightweight, publish-subscribe, machine-to-machine network protocol designed for connecting devices to remote locations that are resource constrained or have limited network bandwidth, which corresponds to the MQTT / TLS / TCP / IP stack in Figure 2.

[0044] Additionally, more lightweight cloud ingest protocols such as Constrained Application Protocol (CoAP) over Datagram Transport Layer Security (DTLS), which corresponds to the CoAP / DTLS / UDP / IP stack of Figure 2, as well as recent developments in the IETF (such as Quick User Datagram Protocol (UDP) Internet Connection (QUIC)), which corresponds to the HTTP / QUIC / UDP / IP stack of Figure 2, can also be used.

[0045] The TLS protocol (e.g., as described in RFC 5246 (2008) or RFC 8446 (2018)) provides end-to-end security for TCP data transport. In particular, it protects confidentiality, integrity, and provides server authentication, which is necessary for the communication of sensitive personal data such as vital signs or other actionable measurement parameters. The DTLS protocol (e.g., as described in RFC 6347 (2012) or draft-ietf-tls-dtls13-43 (2021)) does the same for UDP data transport. The QUIC protocol encompasses the functionality of TLS version 1.3 (e.g., as described in RFC 8446 (2018)) by providing reliable, order-preserving, and secure transport over UDP.

[0046] Therefore, whenever "TLS" is mentioned in the remainder of this disclosure, it also means the applicable elements of DTLS or QUIC.

[0047] In Figure 3, a message (flight) sequence diagram is shown to illustrate the overhead incurred in the example HTTPS (HTTP / TLS / TCP / IP) stack of Figure 2 during communication between a D2C device (e.g., device 10 of Figure 1), a DNS server, and a cloud server providing a cloud service (CS). In the message sequence diagram of Figure 3, time progresses from top to bottom in Figure 3, and the TLS handshake is included between the dotted horizontal lines.

[0048] To safely and reliably transmit a limited sequence of vital signs data (e.g., 100 bytes in length), approximately 15 message flights may be required, transferring several kilobytes of data. In particular, server authentication is achieved by downloading a chain of certificates, which may contain several kilobytes of data.

[0049] The communication procedure in Figure 3 begins with a DNS lookup in which the D2C device attempts to resolve the domain name for the desired cloud service request by sending a DNS request (DNS REQ) to a DNS server, which responds with a DNS response (DNS RESP) containing the IP address of the cloud server that provides the desired cloud service.

[0050] In the subsequent connection phase, the D2C device (client) establishes a TCP connection with the received IP address of the cloud server by sending a synchronization packet (TCP SYN). The cloud server acknowledges the synchronization packet by responding with an acknowledgement packet (TCP SYN / ACK). The D2C device responds with an acknowledgement packet (TCP ACK), thereby completing the three-way TCP connection establishment.

[0051] Next, for TLS version 1.2 (e.g., as described in RFC 5246 (2008)), the TLS handshake procedure begins, which involves four message flights (exchanges), i.e., a four-way handshake. The first two messages (TLS Client Hello (TLS CL Hello) and TLS Server Hello (TLS S Hello)) are required for the endpoints (the D2C device and the cloud server) to agree on a cipher suite and for the cloud server to authenticate itself to the client using the aforementioned certificate chain. The last two flights (TLS Client Key Exchange (TLS CL KE) and TLS Change Cipher Spec (TLS CH CIPH SPEC)) are required to establish a shared session key, enabling encrypted communication (for confidentiality and integrity) during subsequent message exchanges (and in the case of Figure 1, especially vital signs or other sensor data uploads).

[0052] Once a secure connection is established, one or more message exchanges can take place. Each message exchange (only one is shown in FIG. 4) includes a send phase in which the D2C device sends an HTTP request (HTTP REQ) to the cloud server. Then, in a subsequent wait phase, the D2C device waits for the cloud server to respond to the request. During the wait 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, which then loads the content in a load phase.

[0053] Once the necessary message exchanges have taken place, the connection can be terminated (e.g., before the client device goes to sleep). Figure 3 shows an example sequence of five message flights that results in the termination of a connection at both the TLS and TCP layers. The first two message flights in this example are TLS encryption alerts (TLS EA). They are followed by two more message flights (TCP FIN, TCP FIN / ACK) (no data) to close the connection and a final TCP acknowledgment (TCP ACK). In practice, other message sequences can take place that have the same effect of terminating a connection.

[0054] Session resumption can be used to reduce the above four-way TLS handshake to a two-way handshake while avoiding certificate downloads by reusing negotiated session data, including session keys, from a previous session.

[0055] In the case of TLS version 1.2, this can be achieved by session resumption using a session identifier (session ID) (as described, for example, in RFC 5077 (2008)) or by session resumption using a session ticket. In the former case, both the server and the client keep a record of the session data (the session ID is a unique index to that data), while in the latter case, the server packages the session data into an encrypted data block (the key of which is known only to the server), the so-called session ticket, and forwards it to the client. Therefore, in the latter case, the session data does not remain on the server. If the client wants to resume a previous session, it must present the session ticket again to the server.

[0056] Session tickets are more scalable from the perspective of a cloud provider or other service provider because they avoid maintaining state on the server side. To manage their storage resources, a cloud server or other network server can choose to purge session data associated with a session ID within a relatively short period (e.g., 10 minutes) and invalidate the session ID. As a result, session tickets can have a significantly longer lifespan than session IDs (e.g., 12 hours vs. 10 minutes), making them more suitable for wearable devices that wake up every few hours.

[0057] TLS version 1.3 (as described in, for example, RFC8446(2018)) reduces the four-way handshake for initial session creation to a two-way handshake and supports a similar mechanism for session resumption. This also avoids the download of the certificate chain, and optionally the handshake can be reduced to not involve any message flights at all. This option is called 0-RTT (RTT = round trip time). Technically, for 0-RTT, a two-way handshake still exists, but the data traffic for that handshake can be piggybacked onto other messages. As a result, no additional message flights are required.

[0058] Therefore, TLS can reduce handshakes 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 by avoiding downloading the same certificate chain over and over again, can reduce payload size by as much as 50%.

[0059] However, many cloud services or other network services may not be able to handle TLS session resumption themselves because they use multiple server nodes with load balancing, which means that if a device is switched to a different node during session resumption, the device and the new server must complete the full handshake protocol.

[0060] Therefore, TLS session resumption may not be very effective in combination with load-balanced network services (e.g., cloud services). As mentioned above, many network services (e.g., cloud services) use multiple server nodes with load balancing, where devices may be switched between nodes and connections over time. Such server configurations often cannot handle TLS session resumption themselves. As a result, when a device is switched to a different node during resumption, the device and the new server must complete the full handshake protocol.

[0061] The Open Systems Interconnection (OSI) model describes seven layers that computer systems use to communicate over networks: the physical layer (Layer 1, used for transmitting unstructured raw data bits electrically or optically across the network), the data link layer (Layer 2, used for managing node-to-node data transfers where data is packaged into frames), the network layer (Layer 3, used for receiving frames from the data link layer and delivering them to their intended destinations based on the addresses contained in the frames), the transport layer (Layer 4, used for managing delivery of data packets and error checking), the session layer (Layer 5, used for controlling the conversation between different nodes, including authentication and reconnection), the presentation layer (Layer 6, used for formatting and translating application layer data based on the syntax and semantics accepted by the application), and the application layer (Layer 7, used for identifying communication partners and resource availability, and synchronizing communications between end users and / or software applications).

[0062] Different types of load balancing are possible, and a given provider may use more than one. For example, one particular provider offers three different types of load balancers they call Classic Load Balancers (CLBs), which operate at OSI layers 4 and 7 and whose Internet Protocol (IP) addresses change over time; Application Load Balancers (ALBs), which operate at OSI layer 7 and whose IP addresses change over time; and Network Load Balancers (NLBs), which operate at OSI layer 4 and whose IP addresses remain the same.

[0063] To reduce the time and network traffic spent in the initial handshake procedure, a client can request session resumption from a server that previously shared a session with the client, thereby shortening the handshake procedure. To support session resumption, a server can store session security parameters in a local database or delegate storage to the client using a session ticket. The type and extent to which session resumption is supported (e.g., by AWS) depends on the type of load balancing device deployed.

[0064] According to one example, CLB supports session ID-based session resumption, but not session ticket-based session resumption. 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 reverts to a full handshake. A new session ID is then generated by the second node (B).

[0065] According to another example, ALB supports both session ID-based session resumption and session ticket-based session resumption. Both session IDs and session tickets are supported at the node level. This means that when a client connects to a second node (B) using a session ID or session ticket received from a first node (A), the handshake reverts to a full handshake. A new Secure Sockets Layer (SSL) session ID and session ticket are then generated by the second node (B).

[0066] As a further example, an NLB only supports session tickets for session resumption. Resumption using session tickets is supported at the regional level. A client can resume a TLS (Transmit Layer Security) session with the NLB using any of its IP addresses.

[0067] This means that CLB and ALB do not allow for session resumption between nodes, while NLB does, but not all cloud and other network service deployments use NLB.

[0068] As an example, when performing a DNS lookup on a load-balanced, non-NLB endpoint, a list of IP addresses may be returned. The client will typically select the first IP address from this list, although this is not required. The time-to-live (TTL) for this lookup tends to be small (e.g., 60 seconds), so every time the client wakes up, a new DNS lookup must be performed, which may result in a different list of IP addresses.

[0069] Energy consumption and data communication costs are important criteria for cellular or other network devices, especially wearable or other IoT devices with small form factors. Therefore, minimizing the amount of data communicated is an important design consideration. Even for non-cellular devices, such as Wi-Fi or other wired or wireless network devices, energy consumption may still be significant.

[0070] Standard protocols for data ingestion (i.e., data acquisition and import) for cloud services incur significant overhead in terms of the number of messages (flights) exchanged, as well as in terms of payload. This is especially true when the net amount of data uploaded as part of a single transaction is relatively small (e.g., only 100 bytes of vital signs) and when the period between transactions is long (e.g., 2 hours), requiring cellular modems to go into sleep mode to conserve energy. The latter is significant because it disrupts connections at different layers in the stack (e.g., TCP (Transmit Control Protocol), TLS, etc.) and requires them to be set up again from scratch for the next transaction.

[0071] FIG. 4 illustrates a flow diagram of an enhanced session resumption procedure according to various embodiments for a load-balanced network service that may be performed by application MCU 120 of FIG.

[0072] In step S400, the procedure is triggered by a wake-up operation (WU) of a client device (for example, the wearable D2C device 10 of FIG. 1).

[0073] The procedure (or processing MCU) is configured to maintain a list of tuples (IP address, session ticket) across iterations of session initiation and / or resumption. Initially, the list is empty. Each iteration begins with a modem (e.g., modem 130 in FIG. 1) waking up from sleep (i.e., some state in which it is not communicating with a server and generally has low energy consumption) to begin communication. As mentioned above, the time between iterations can be long, e.g., several hours.

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

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

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

[0077] If an address match (AM) is determined in the subsequent step S440 (i.e., at least one of the IP addresses in the DNS lookup matches the IP address of one of the tuples in the list), the procedure branches to step S450, where an abbreviated handshake (SHS) is performed towards the matching IP address using the stored session ticket of the corresponding tuple of that IP address.

[0078] Otherwise, if no address match is determined in step S440, the procedure branches to step S460, where a new full handshake (FHS) is initiated with an arbitrary IP address from the DNS lookup. Then, in step S470, this arbitrarily selected IP address and the new session ticket obtained from the full handshake are added as a new tuple to the maintained tuple list (ATL).

[0079] The DNS lookup in step S410 can be avoided or skipped if the previous DNS lookup has not yet expired, i.e., it is still within the TTL duration. In that case, the previous IP address can simply be reused for session resumption. However, in the example scenario of FIG. 1 using a wearable D2C device 10 or a similar scenario, the time between repetitions (e.g., 2 hours) is much longer than the TTL (e.g., 60 seconds).

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

[0081] One advantage of this embodiment is that it can be implemented exclusively on the client side without requiring any changes on the server side (e.g., cloud side). Therefore, the proposed shortened or accelerated session resumption does not require any modifications on the network / server side.

[0082] As an example, the proposed shortened or accelerated session resumption of the embodiments described herein can be implemented in a client device (e.g., D2C device 10 of FIG. 1 ) by adapting device firmware to implement, for example, the procedures (e.g., algorithms) described above in connection with FIG. 4 . More specifically, two distinctly different deployment scenarios can be envisioned. In a first example, the implementation can be achieved as part of the device application code on a host processor (e.g., application MCU 120 of FIG. 1 ). In a second example, the implementation can be achieved as part of the firmware of a wired or wireless (e.g., cellular, WiFi, etc.) modem (e.g., modem 130 of FIG. 1 ).

[0083] According to an alternative embodiment, the procedure of Figure 4 can be modified (simplified) by remembering (storing) only the last tuple (i.e., the last IP address and associated session ticket), which simplifies the control flow and reduces storage requirements.

[0084] Thus, after waking up from sleep in step S400, a DNS lookup is initiated in step S410 to obtain a list of valid IP addresses, and step S420 is skipped (made unnecessary) and the IP addresses in the resulting list are directly compared with the last IP address used in the previous session in a modified step S430.

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

[0086] Otherwise, if an address match is not determined or the session ticket is no longer valid, the procedure branches to step S460, where a new full handshake is initiated with any IP address selected from the DNS lookup, and in step S470, the selected IP address and associated session ticket are stored as a new tuple for the previous session.

[0087] Note that the embodiment of Figure 4 may be configured to revert to an alternative (simplified) embodiment if the period between uploads (session resumptions) exceeds a predetermined portion (e.g., 50%) of the session ticket's lifetime.

[0088] As an example, if it is known in advance that the upload period of a client device will exceed half of the session ticket lifetime, the procedure according to the alternative simplified embodiment can be activated rather than the procedure according to the enhanced embodiment of FIG. 4. If the upload period is a fixed, given period, this can be determined at design time or during setup of the client device. Alternatively, if the client device has multiple modes of operation (e.g., if a D2C vital signs monitoring device has a much higher upload frequency while a patient is in the hospital than when the patient returns home from the hospital), the client device can be reconfigured for a different upload period and, upon such reconfiguration, can be reconfigured to use either the procedure according to the simplified embodiment or the procedure according to the enhanced embodiment.

[0089] In one example, a client device may use tickets with 8-hourly uploads and a 12-hour lifetime. As a result, upon wakeup, an 8-hour-old ticket (due to expire in 4 hours) may be stored that does not match any of the addresses in a DNS lookup. Therefore, a full handshake is required to create a new, second ticket. In this case, the enhanced embodiment of FIG. 4 stores two tickets (the one that is 8 hours old is not useful for the next iteration), while the simplified embodiment stores only the most recent ticket. In other words, by switching to the simplified embodiment, less storage space is required.

[0090] 4 can be configured to also purge session ticket tuples that are still valid, in order to save storage. This can be done in step S420 by (conditionally) purging the ticket tuple that expires first (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 one.

[0091] 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.

[0092] To evaluate the effectiveness of both of the above embodiments described in relation to Figure 4 over conventional session resumption procedures, a simulation was performed of a scenario in which a wearable D2C device uploads several vital signs to a load-balanced cloud service once every two hours.

[0093] In this experiment, once every two hours, a DNS request was sent to a DNS server 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 each client with a single entry point into the system via an adapted API. The list of IP addresses returned by the corresponding DNS response was recorded. Using these sequences of IP address lists as input, different candidate algorithms from the above embodiments and traditional session resumption were then simulated, and the number of sessions that would have been resumed was counted. In particular, the algorithm for each of the above embodiments in Figure 4 was compared with a simple ("naive") traditional session resumption procedure based on the latest session ticket.

[0094] Note that the API gateway service used supports session tickets at the node level, and these session tickets have a validity period of 12 hours. This latter parameter was taken into account when evaluating the embodiment. This means that a session ticket from up to five iterations ago can still be used for a successful session resumption (5 x 2 hours < 12 hours).

[0095] 5A-5C are schematic diagrams showing simulation measurement results for different session resumption embodiments, including naive session resumption (FIG. 5A) and the two embodiments described above (FIGS. 5B and 5C). The horizontal axis of the diagrams represents 50 consecutive iterations of the experiment. The vertical axis represents 14 different IP addresses A1-A14 of different nodes of the cloud service, observed in one of the DNS responses. Successfully resumed sessions are indicated by black triangles. Furthermore, black squares are used to indicate addresses selected for a full handshake. Such addresses are selected to set up a connection 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 successful session resumption was possible (and therefore, an abbreviated handshake was performed). Black dots represent remaining addresses, i.e., addresses that were returned by the DNS lookup but were not selected to set up a connection.

[0096] Figure 5A shows the results of a naive (traditional) implementation of TLS session resumption like the one described above. Each time, the first IP address in the list returned by the DNS response is recorded. If that IP address is equal to the IP address indicated in the previous iteration, the resumed session is counted and marked as a black triangle in the row of the relevant node. As can be seen from the diagram in Figure 5A, session resumption is successful only in 4 out of 50 iterations. In other words, an 8% effectiveness can be achieved. Note that no single IP address was used more than 5 times in a row (i.e., the session ticket is still valid).

[0097] Figure 5B shows the results of the simplified (alternative) embodiment of Figure 4 (without step S420) as described above, where session resumption is successful in 15 out of 50 iterations. In other words, a 30% effectiveness can be achieved.

[0098] Figure 5C shows the results of the embodiment of Figure 4 above, where session resumption is successful in 26 out of 50 iterations. In other words, an effectiveness of 52% can be achieved.

[0099] The table below gives an overview of the effectiveness of the various options measured in experiments. It compares the two embodiments of Figure 4 with a simple implementation, an option with no session resumption at all, and a full-fledged session resumption between nodes (i.e., using NLB). Note that in the case of session resumption between nodes, a 12-hour validity of the session ticket means that a full handshake is required in 1 out of 6 cases. The effectiveness is therefore 83%. [Table 1]

[0100] Session resumption between nodes can be achieved by configuring cloud services that support it, such as the NLB described earlier. This requires adaptation on the server side (e.g., the cloud side), which may not be possible in all scenarios, e.g., scenarios where the device manufacturer has no control over the server side or chooses not to adapt it for other reasons.

[0101] 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. Specifically, in any application with much more frequent uploads compared to the session ticket lifetime, the efficiency gain of the proposed embodiment can be much larger and approach the efficiency gain of inter-node session resumption.

[0102] Other experiments on D2C devices show that the energy consumption of uploads using resumed handshakes is up to 33% less than that of uploads using full handshakes. This means that the full embodiment of Figure 4 can achieve an overall energy reduction of up to 17% (52% of 33%) in cellular communication. In scenarios where the overhead of connecting to a network (cellular, Wi-Fi, or other) is lower, the relative gain in energy consumption is greater. This experiment involves a modem being switched off between uploads, which means that each time it needs to reconnect to the cellular network before IP communication is possible, reducing the relative gain of any optimizations at the IP level. This means that an embodiment that puts the modem into a smarter sleep mode (called PSM) shows a higher relative gain.

[0103] The relative gain in terms of data transmitted over the cellular network, and thus the associated data costs, can be as much as twofold: in the example upload of 100 B of vital signs data, approximately 3 kB of certificates were downloaded as part of a total IP-level data exchange of approximately 6 kB.

[0104] The relative improvements in energy consumption and data volume will be greater for future protocols that require fewer handshakes (e.g., TLS 1.3, QUIC).

[0105] As mentioned above, the procedures / algorithms of the above embodiments can be implemented in a modem module (e.g., modem 130 in FIG. 1) or in the application MCU of a client device (e.g., application MCU 120 in FIG. 1). In the first case of modem implementation, the modem module can be used in a variety of different client devices independent of the application MCU.

[0106] Alternatively, embodiments can be used as an exclusive feature of a particular client device to enable longer battery life (or lower battery cost / form factor) as well as lower consumption in cellular communications, in which case the algorithms can be implemented on the application MCU instead.

[0107] In summary, methods and devices are described for increasing the likelihood that a device or application can 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 load balancing at the node level. This can be achieved by maintaining one or more network addresses and valid session tickets (or identifiers) of individual nodes (e.g., servers) of the network service that were used for the previous communication session, and by selecting a particular node for the subsequent communication session from a list of nodes that may be returned by an address lookup (e.g., a Domain Name System (DNS) lookup) based on its match with one of the one or more network addresses and session tickets or identifiers.

[0108] While the present invention has been illustrated and described in detail in the drawings and the foregoing description, such illustration and description should be considered exemplary or explanatory and not restrictive. It should be understood that embodiments may be combined, and that any one feature of an embodiment may be used in combination with another embodiment. The present invention is not limited to the disclosed embodiments. The present invention can be applied to any type of biosensor for measuring cardiac and / or respiratory rate or other physiological parameters, for example, by directly linking the biosensor to a clinical information system without the patient needing a hub or mobile phone. It can also be applied to other small-form-factor (i.e., comfortably wearable) energy-constrained devices (e.g., cellular or Wi-Fi) by enabling long battery life. Furthermore, it can be applied to help reduce data communication costs for any type of cellular IoT device that transmits (small amounts of) application data, such as automated external defibrillators (AEDs) and respiratory equipment.

[0109] However, the proposed accelerated or simplified session resumption concept has wider applicability: essentially, any energy-constrained wired or wireless device that connects directly to cloud services using standard (secure and reliable) IP protocols can benefit, at least if the application payload is small compared to the protocol overhead.

[0110] Furthermore, the proposed improvements for session resumption can be implemented in all types of wired or wireless networks, for example, it can be applied to devices or applications that communicate using cellular wireless communication standards, specifically the 3rd Generation Partnership Project (3GPP) 5G and New Radio (NR) standards. The communication 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, IoT devices for hospital or first responder use, virtual reality (VR) headsets, etc., and can be used, for example, in UE-to-UE focused personal IoT networks (PINs) and / or ProSe.

[0111] Furthermore, the proposed improvements for session resumption can be used in applications such as Wi-Fi, cloud access, browser synchronization, and e-passports, in threaded network protocols for IoT devices, in standards developed by Standards Development Organizations (SDOs) such as IEEE, ISO / IEC, and IETF, in IEEE 802.11s protocols and Wi-Fi Protected Access (e.g., WPA3 associated with SAE (Simultaneous Authentication of Equals)), or in Transport Layer Security (e.g., TLS 1.3) or Internet Key Exchange (e.g., TLS 1.3) protocols.

[0112] Additionally, the present invention can be applied in medical applications or connected healthcare involving multiple wireless (e.g., 4G / 5G) connected sensor or actuator nodes, in medical applications or connected healthcare where wireless (e.g., 4G / 5G) connected equipment (e.g., video, ultrasound, X-ray, computed tomography (CT) imaging devices, real-time patient sensors, audio or voice or video streaming devices used by medical staff) occasionally consumes or generates data streams at a certain average data rate, in general IoT applications (smart cities, logistics, agriculture, etc.) involving wireless, mobile or fixed sensor or actuator nodes, in emergency services and critical communication applications, in V2X systems, in systems improving the coverage of 5G cellular networks using high frequency (e.g., mmWave) RF, and other application areas of 5G communications where relaying is used.

[0113] Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprise" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The foregoing description details particular embodiments of the present invention. However, no matter how detailed the above appears in text, it will be understood that the invention can be embodied in many forms and is therefore not limited to the disclosed embodiments. It should be noted that the use of a particular term in describing a particular feature or aspect of the present invention does not mean that the term is redefined herein to be limited to include the specific feature or aspect of the invention to which the term relates.

[0114] Furthermore, when a convention similar to "at least one of A, B, and C, etc." is used, generally, such a configuration will be understood by one of ordinary skill in the art; for example, "a system having at least one of A, B, and C" includes, but is not limited to, A alone, B alone, C alone, a system of A and B together, a system of A and C together, a system of B and C together, and / or a system of A, B, and C together. When a convention similar to "at least one of A, B, or C" is used, generally, such a configuration is intended to have the meaning that one of ordinary skill in the art would understand the convention. For example, "a system having at least one of A, B, or C" includes, but is not limited to, a system of A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, and C together. It will be further understood by those skilled in the art that virtually any language and / or phrase presenting two or more alternative terms, whether in the detailed description, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" is understood to include the possibilities of "A" or "B" or "A and B."

[0115] 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.

[0116] 4 can be implemented as program code means of a computer program and / or as dedicated hardware in the D2C device or another client device. The computer program can be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but can also be distributed in other forms, such as over the Internet or other wired or wireless telecommunications systems.

Claims

1. 1. An apparatus, located in a client device, for controlling initiation of a communication session between the client device and a network node, comprising: maintaining a list including a plurality of tuples, each tuple including a network address and an associated session ticket or identifier of each network node providing a target network service that was used by the client device for a previous communication session; selecting a network node for a subsequent communication session from the list of potential nodes returned by the address lookup based on a match of its network address with one of the one or more network addresses and an associated session ticket or identifier; The apparatus uses the matched network address and associated session ticket or identifier for session resumption with the selected network node.

2. 2. The apparatus of claim 1, further comprising: purging network addresses associated with expired session tickets or identifiers; and comparing remaining network addresses obtained by the address lookup with the maintained network addresses of the tuples in the stored list to identify a network node for the session resumption.

3. The apparatus of claim 2 , wherein the apparatus conditionally purges network addresses associated with unexpired session tickets or identifiers to conserve storage space.

4. The apparatus according to claim 1 , wherein the target network service is a load-balanced network service, in particular a load-balanced cloud service.

5. The device of claim 1 , wherein the device is configured to perform the session resumption in accordance with a Transport Layer Security protocol.

6. The device of claim 1 , wherein the communication session is used for data retrieval of a cloud service.

7. A communication module comprising a device according to any one of claims 1 to 6.

8. 10. The communication module of claim 7, further comprising a modem configured to provide an attention command interface for implementing an end-to-end communication stack for data capture communications.

9. 10. The communication module of claim 8, wherein the modem conducts the communication session with the network server via a cellular access device using an LTE machine type communication protocol or an LTE narrowband IoT protocol.

10. A client device comprising an apparatus according to any one of claims 1 to 7.

11. The client device of claim 10 , wherein the client device is a wearable-to-cloud device for uploading sensor data by directly communicating with a cloud server.

12. 1. A method by a client device for controlling initiation of a communication session between the client device and a network node, comprising: maintaining a list including one or more tuples, each tuple including a network address and an associated session ticket or identifier of an individual network node providing a target network service that was used by the client device for a previous communication session; selecting a network node for a subsequent communication session from the list of potential nodes returned by the address lookup based on a match of its network address with one of the one or more network addresses and an associated session ticket or identifier; using the matched network address and associated session ticket or identifier for session resumption by the selected network node; A method having the following.

13. A computer program product which, when executed by a computer, causes the computer to carry out the method of claim 12.

Images