Method for handling a connection between a client and a server using a cluster of proxy instances which shares a protocol context associated with the connection.

Abstract

A method performed by a proxy node is provided. The method is for handling a data connection for a data packet stream between a client and a server via the proxy node in a communications network. The proxy node comprises a cluster of proxy instances. When the proxy node identifies that a proxy instance fails, the proxy node obtains from a database shared between the proxy instances, a protocol context of the failed proxy instance and the proxy node replaces the failed proxy instance with another proxy instance from the cluster of proxy instances.

Description

[0001] METHOD FOR HANDLING A CONNECTION BETWEEN A CLIENT AND A SERVER USING A CLUSTER OF PROXY INSTANCES WHICH SHARES A PROTOCOL CONTEXT ASSOCIATED WITH

[0002] THE CONNECTION

[0003] TECHNICAL FIELD

[0004] Embodiments herein relate to a proxy node and a method therein. In some aspects,

[0005] 5 embodiments relate to handling a data connection for a data packet stream between a client and a server via the proxy node in a communications network.

[0006] BACKGROUND

[0007] In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and / or User Equipment (UE), communicate via a Wide Area Network or a Local Area Network such as a Wi-Fi network or a cellular network comprising a Radio Access Network (RAN) part and a Core Network (CN) part. The RAN covers a geographical area which is divided into service areas or cell areas, which may also be referred to as a beam or a beam group, with each

[0008] 15 service area or cell area being served by a radio network node such as a radio access node e.g., a Wi-Fi access point, a Base Station (BS) or a radio base station (RBS), which in some networks may also be denoted, for example, a Base Station (BS), a NodeB, eNodeB (eNB), or gNodeB (gNB) as denoted in Fifth Generation (5G) telecommunications. A service area or cell area is a geographical area where radio

[0009] 20 coverage is provided by the radio network node. The radio network node communicates over an air interface operating on a radio frequency with the wireless devices within the range of the radio network node.

[0010] 3rd Generation Partnership Project (3GPP) is the standardization body for specifying the standards for the cellular system evolution, e.g., including 3G, 4G, 5G and the future evolutions. Specifications for Evolved Universal Terrestrial Radio Access (E- UTRA) and Evolved Packet System (EPS) have been completed within the 3GPP. In 4G also called a Fourth Generation (4G) network, EPS is core network and E-UTRA is radio access network. In 5G, 5G Core (5GC) is core network, NR is radio access network. As a continued network evolution, the new release of 3GPP specifies a 5G network also

[0011] 30 referred to as 5G New Radio (NR) and 5GC.

[0012] Frequency bands for 5G NR are being separated into two different frequency ranges, Frequency Range 1 (FR1) and Frequency Range 2 (FR2). FR1 comprises sub-6 GHz frequency bands. Some of these bands are bands traditionally used by legacy standards but have been extended to cover potential new spectrum offerings from 410 MHz to 7125 MHz. FR2 comprises frequency bands from 24.25 GHz to 52.6 GHz. Bands in this millimeter wave range have shorter range but higher available bandwidth than bands in the FR1.

[0013] Multi-antenna techniques may significantly increase the data rates and reliability of a wireless communication system. For a wireless connection between a single user, such as UE, and a base station (BS), the performance is in particular improved if both the transmitter and the receiver are equipped with multiple antennas, which results in a Multiple-Input Multiple-Output (MIMO) communication channel. This may be referred to as Single-User (SU)-MIMO. In the scenario where MIMO techniques is used for the wireless connection between multiple users and the base station, MIMO enables the users to communicate with the base station simultaneously using the same time-frequency resources by spatially separating the users, which increases further the cell capacity. This may be referred to as Multi-User (MU)-MIMO. Note that MU-MIMO may benefit when each UE only has one antenna. The cell capacity can be increased linearly with respect to the number of antennas at the BS side. Due to that, more and more antennas are employed in BS. Such systems and / or related techniques are commonly referred to as massive MIMO.

[0014] Transport layer i.e. , Layer four (L4) in a communications network comprises protocols such as e.g., QUIC, Transmission Control Protocol (TCP), and Stream Control Transmission Protocol (SCTP) to control communication between a client and a server. A client may e.g., be an loT device, a laptop, a connected vehicle, a mobile phone or a network function. A server may e.g., be a web-server or a mobile network function.

[0015] Among the transport layer protocols, the usage of QUIC is increasing while the usage of TCP is decreasing in the Internet communication. QUIC is to very high extend replacing TCP in the 6G network design. From the protocol implementation perspective, this means that the transport protocol stack is moved from kernel as in TCP to a userspace as in QUIC. This also means that modifications to the QUIC protocol stack are easier to make compared to TCP.

[0016] QUIC is a protocol running on top of a User Datagram Protocol (UDP). It utilizes a Transport Layer Security (TLS) 1.3 based handshake for authentication and key agreement, and then protects the payload carried by the UDP. QUIC provides a clientside mobility where the topological location of the end-point changes in the network. QUIC achieves this by binding the QUIC protocol context comprising e.g., protocol parameters and cryptographic keys to a connection identifier carried by the QUIC packets instead of IP addresses and ports. A connection identifier identifies a communication channel between a client and a server. This allows the server to keep associating the received traffic to the same context even if the client changes IP address.

[0017] Figures 1a and 1b illustrate possible situations that are covered by the QIIIC protocol design. Figure 1a describes a scenario a) where a QIIIC client sends packets, referred to as Pn:1. Pn:2 in Figure 1a, to a QIIIC server for which the server sends acknowledgements, referred to as Ack:1. A QIIIC server may be a web-server or a network function. The packets from the server comprising the acknowledgments however arrive in disorder to the client. This results in a need to wait for acknowledgement packets until a timeout. After a time-out the client retransmits the lost packet with a new packet number. In scenario b) a replay attack results in a MitM attacker sending a copy of the server’s packet to the client causing the client to drop the duplicate of the packet. This may happen also due to a routing issue in the network. A MitM attacker may be e.g., malicious node between the client and the server. Such scenarios are covered when using QIIIC because the protocol can handle packet retransmissions based on received packet numbers. QIIIC handshakes may be performed by 1-Round Trip Time (1-RTT) handshake or 0-RTT handshake. The main difference between them is that the 0-RTT handshake includes an option for clients to send data immediately in the first message.

[0018] QUIC aware middle-boxes

[0019] A QUIC aware middle-box is forwarding QUIC packets based on the connection identifiers carried in the packets. QUIC Load balancers (LB)s are used to distribute Hypertext Transfer Protocol version 3 (http3) traffic between web services. The distribution of QUIC packets in LB is based on destination connection identifiers carried in QUIC packets. A destination QUIC connection identifier is 1 to 20 bytes long identifier carried in the packet header used to identify the connection regardless of the source IP. Signalling between LB and the platform running the web services is specific to each platform. Such signalling may include registering and / or deregistering IP addresses of the web service instance to and / or from the LB.

[0020] A QUIC proxy may e.g. be running as a virtualized workload on the top of a cloud platform. A QUIC proxy may optimize signalling traffic between the client and the server or implement UDP tunnelling between endpoints.

[0021] However, QUIC aware middle-boxes are stateful. This means that a QUIC protocol context cannot be transferred between proxy instances, such as e.g., web proxies without support for server-side migration of address and context.

[0022] QUIC packet numbers, ACKs and stream offsets QUIC packet numbers never repeat within a packet number space for the lifetime of a connection. The packet numbers are sent in monotonically increasing order within a space, preventing ambiguity. It is permitted for some packet numbers to never be used, leaving intentional gaps.-The-packet numbers indicate the transmission order, and the delivery order is determined from the stream offsets in STREAM frames. -QUIC acknowledgments are irrevocable. Once acknowledged, a packet remains acknowledged, even if it does not appear in a future ACK frame.-Every packet should be acknowledged at least once. An endpoint could receive data for a stream at the same stream offset multiple times. Data that has already been received can be discarded. The data at a given offset must not change if it is sent multiple times; an endpoint may treat receipt of different data at the same offset within a stream as a connection error of type PROTOCOL_VIOLATION.

[0023] SUMMARY

[0024] As part of developing embodiments herein, the inventors identified some problems that first will be described.

[0025] It is essential for some use-cases such as e.g., in connected cars and 5G loT device communication that the transport layer connections between the UEs and services are secure and resilient. Resilient connections can offer stable latency and throughput for applications, being a key requirement in many use-cases. Some use-cases such as e.g., loT deployments equipped with limited battery lifetime do not require continuously high- throughput but Low Latency, Low Loss, and Scalable Throughput (L4S). Resiliency and reliability of connections depend on several L1-L4 networking characteristics. From the resiliency perspective, transport layer i.e., L4 protocols such as e.g., QUIC are essential technologies in the network design since they provide end-to-end protection e.g., with TLS for applications. They also have recovery capabilities for packet loss and congestion in the network.

[0026] Furthermore, clients connect to services that are nowadays typically running in containers in a cluster so that provides redundancy and resilience for services. While the cluster can provide redundancy for a service instance, the server-side protocol state is terminated together with the service instance after a failure. A service instance may fail when e.g., due to a hardware failure. This means that the client needs to recover from the service failure with the help of transport layer mechanisms. In other words, if the serverside transport protocol state-machine crashes, the client needs to reinitiate its connection with the service. Therefore, one essential problem is related to the transport layer i.e. , L4 performance and resilience on the server-side in case of a software failure or unexpected disturbance in the service cluster. The interruption in the service causes additional delay in the communication due to a protocol timeout and time taken in renegotiating the connection. This results in unwanted fluctuation in the latency and throughput with long- living client sessions. The problem applies both to QIIIC and TCP protocols.

[0027] Another problem with the long-living client connections is related to the so-called scale-down property on the service cluster side. In the scale-up phase, the cluster allocates more resources e.g., a web service for serving the clients. However, in the scale-down phase, the cluster terminates some of the services to save resources. At the same time, active client connections that are associated with those services will be closed without protocol state transfer support. This results in protocol timeout and reestablishment of transport connection at the client side.

[0028] As described above, QIIIC provides client-side mobility when a client changes its topological location in the network, namely, an IP-address. However, it does not support server-side mobility the same way. A server-side mobility means that the server changes its topological location in the network. Server-side mobility requires migration of serverside address and context to support protocol context transfer between containers in a cluster. However, if an unexpected system failure happens before or during the context transfer, the transfer is unsuccessful resulting in transport state loss.

[0029] To recover from such a failure, QIIIC can use the session resumption feature of TLS 1.3. In a basic case, this feature is used with the same server instance from the client perspective. However, in a distributed web cluster deployment there is a need to share the same TLS session keys between the different web server instances due to load balancing. However, TLS session resumption does not solve the above-mentioned problem if the transport layer protocol state is lost during the QUIC session. During a TLS session resumption process, only the protocol state corresponding to the TLS session is stored in a database to enable fast connection re-establishment. This information that is stored is not sufficient to recover the full QUIC protocol state without initiating a new connection.

[0030] In brief, there is a design challenge in realizing a resilient and secure transport-layer protocol server for long-living client connections without causing essential fluctuation in the latency and throughput in the case of an unexpected system failure. An object of embodiments herein is to improve the data connection between a client and a server in a communications network.

[0031] According to an aspect of embodiments herein, the object is achieved by a method performed by a proxy node. The method is for handling a data connection for a data packet stream between a client and a server via the proxy node in a communications network. The proxy node comprises a cluster of proxy instances. The proxy node distributes data packets of the data packet stream, among one or more of the proxy instances in the cluster of proxy instances. The data packets are received from the client and / or the server. For one or more of the proxy instances in the cluster that comprises a respective data packet of the distributed data packets, the proxy node obtains from a database that is shared between the proxy instances in the cluster, a protocol context related to the client and / or the server based on a connection identifier comprised in the respective data packet, identifying said data connection. The proxy node processes one or more out of: the respective data packet received from the client and / or the server and the obtained protocol context related to the client and / or the server. The proxy node updates said protocol context based on information related to the respective data packet, and the processed respective data packet and / or the obtained protocol context. The proxy node stores said updated protocol context in the shared database. When the proxy node identifies that a proxy instance, comprising at least one distributed data packet, of the cluster of proxy instances, fails, the proxy node obtains among the updated protocol contexts in the shared database, the protocol context of the failed proxy instance and the proxy node replaces the failed proxy instance with another proxy instance from the cluster of proxy instances. The proxy node thus enables the data connection to be kept for the data packet stream between the client and the server via the replaced proxy instance comprised in the proxy node.

[0032] According to another aspect of embodiments herein, the object is achieved by a proxy node. The proxy node is configured to handle a data connection for a data packet stream between a client and a server via the proxy node in a communications network. The proxy node is adapted to comprise a cluster of proxy instances. The proxy node is further configured to: - Distribute data packets of the data packet stream, among one or more of the proxy instances in the cluster of proxy instances, which data packets are received from the client and / or the server,

[0033] For one or more of the proxy instances in the cluster that comprises a respective data packet of the distributed data packets:

[0034] - Obtain from a database that is shared between the proxy instances in the cluster, a protocol context related to the client and / or the server, based on a connection identifier comprised in the respective data packet, identifying said data connection,

[0035] - Process one or more out of: the respective data packet received from the client and / or the server and the obtained protocol context related to the client and / or the server,

[0036] - Update said protocol context based on information related to the respective data packet, and the processed respective data packet and / or the obtained protocol context,

[0037] - Store said updated protocol context in the shared database, The proxy node is further being configured to:

[0038] - Identify that a proxy instance, comprising at least one distributed data packet, of the cluster of proxy instances, fails:

[0039] - Obtain among the updated protocol contexts in the shared database, the protocol context of the failed proxy instance and

[0040] - Replace the failed proxy instance with another proxy instance from the cluster of proxy instances, enabling the data connection to be kept for the data packet stream between the client and the server via the replaced proxy instance comprised in the proxy node.

[0041] Thanks to that the proxy node comprises a cluster of proxy instances to forward the data packets from the client to the server and to update the protocol context in a database, the client can keep the data connection with the server even when one or more proxy instances fail thereby eliminating any delay due to the establishment of a new data connection. This results in an improved data connection between a client and a server in a communications network.

[0042] Embodiments herein may provide one or more of the following advantages:

[0043] They provide resilient and secure transport-layer protocol proxy functionality for long-living client connections without causing essential fluctuation in the latency and throughput in the case of an unexpected system failure on the proxy side. Thus, any proxy instance can fail at any time without resetting the client connection. They do not require changes to standards and are transparent to the client and web server.

[0044] They provide a scalable design that allows protection for web servers against certain Denial-of-Service (DoS) attacks where the attacker tries to consume web service network and computation resources and tries to establish QIIIC connections and keep them open for a long time.

[0045] They allow the QIIIC proxy and the web server to scale up and down the resources independently of each other thereby allowing the QIIIC proxy to close the connections towards the web server without impacting the session on the client side.

[0046] They separate the client-facing QIIIC endpoint from the web server into a different container, which provides additional protection from lateral movement in case of a vulnerability in the QIIIC or encryption libraries.

[0047] BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Examples of embodiments herein are described in more detail with reference to attached drawings in which:

[0049] Figure 1 shows a combined flowchart and signaling scheme according to prior art.

[0050] Figure 2 is a schematic block diagram illustrating embodiments of a communications network.

[0051] Figure 3 is a flowchart depicting an embodiment of a method in a proxy node.

[0052] Figure 4 is a schematic illustrating an example embodiment of a method herein. Figure 5 is a schematic illustrating an example embodiment of a method herein. Figure 6 shows a combined flowchart and signaling scheme of an example embodiment of a method herein.

[0053] Figure 7 shows a combined flowchart and signaling scheme of an example embodiment of a method herein.

[0054] Figure 8 shows a combined flowchart and signaling scheme of an example embodiment of a method herein.

[0055] Figure 9 shows a combined flowchart and signaling scheme of an example embodiment of a method herein.

[0056] Figure 10 shows a combined flowchart and signaling scheme of an example embodiment of a method herein.

[0057] Figure 11 shows a combined flowchart and signaling scheme of an example embodiment of a method herein. Figure 12 shows a combined flowchart and signaling scheme of an example embodiment of a method herein.

[0058] Figure 13 is a schematic block diagram illustrating embodiments of a proxy node. Figure 14 schematically illustrates embodiments of a communication system.

[0059] Figure 15 is a generalized block diagram of embodiments of a UE.

[0060] Figure 16 is a generalized block diagram of embodiments of a network node. Figure 17 is a generalized block diagram of embodiments of a host.

[0061] Figure 18 is a generalized block diagram of embodiments of a virtualization environment.

[0062] Figure 19 is a generalized block diagram of embodiments of a communication diagram of a host.

[0063] DETAILED DESCRIPTION

[0064] Examples of embodiments herein provide a resilient, secure and scalable proxy node design for long-living client connections. The proxy node may be referred to as e.g., proxy cluster as it comprises a cluster of proxy instances. In example embodiments herein, a client communicates with a server through the proxy node wherein the proxy node implements a server role towards the client and a client role towards the web server. In some example embodiments herein, the proxy node also implements the web server role.

[0065] Embodiments herein e.g., provide a stateless proxy node design for transport layer protocol such as e.g., QIIIC, Transmission Control Protocol (TCP), Transport Layer Security (TLS), Stream Control Transmission Protocol (SCTP), Low Latency, Low Loss, and Scalable Throughput (L4S). In some embodiments herein, the proxy node such as e.g., its LB, divides the received data packets from a client between processing elements, referred to as proxy instances herein. The processing elements referred to as proxy instances herein may be represented by e.g., containers, virtual machines, processes or software threads. The data packets herein may e.g., refer to packets related to control signalling, handshake packets, packet stream, QUIC packets, TCP packets. These proxy instances may be comprised in a proxy cluster referred to as the proxy node herein.

[0066] According to example embodiments herein, the data packets received by the proxy node may be divided in a round-robin order between proxy instances or forwarded to a specific proxy instance based on connection identifiers carried in the data packets.

[0067] In some embodiments herein, the proxy instances are executed in a container, in a virtual machine, in an enclave or in a sandboxed software thread. These proxy instances may perform parallel computing and process the received data packets independently of each otherwhere each packet updates the corresponding protocol context. According to examples herein, the proxy instances store the shared protocol context to a database such as e.g., a distributed database or key-value store, in a secure way where other proxy instances can fetch the protocol context.

[0068] Embodiments herein provide different databases to avoid race conditions in this kind of parallel processing approach. In these databases, not only the TLS or QIIIC context but the whole transport layer protocol context may be stored to the database. As a result, the client may not need to initiate a new connection with the proxy cluster if a single proxy instance crashes.

[0069] According to example embodiments herein, the transport connection is kept alive between the client and the proxy node while the connection from the proxy node to the web server may be re-established if needed. The proxy node and the web server may be located topologically close to each other to reduce the latency in the backend. The proxy node and the web server may be located in the same administrative domain, implying a reduced risk of malicious connections between the two.

[0070] Figure 2 is a schematic overview depicting a communications network 100 wherein embodiments herein may be implemented. The communications network 100 comprises one or more access networks, such as RANs, and one or more CNs, such as CN 106, which communicate with a server 140.

[0071] The communications network 100 may use 5G NR but may further use a number of other different technologies, such as, wired communication, 6G, Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications / enhanced Data rate for GSM Evolution (GSM / EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.

[0072] RAN nodes, such as a RAN node 110, operate in the RAN of the communications network 100. The RAN node 110 may be a transmission and reception point e.g. a radio access network node such as a base station, e.g. a radio base station such as a NodeB, an evolved Node B (eNB, eNode B), an NR Node B (gNB), a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a transmission arrangement of a radio base station, a stand-alone access point, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), an access controller, or any other network unit capable of communicating with UEs, such as a UE 121 that is used by a subscriber, within a cell, served by the RAN node 110. The RAN node 110 may act as a connecting point between the UE 121 and the server 140 via the CN node 130. The RAN node 110 may be referred to as a serving radio network node and may communicate with the UE 121 with Downlink (DL) transmissions to the UE 121 and Uplink (UL) transmissions from the UE 121.

[0073] A client 120 operates in the communications network 100. The client 120 may be represented by the UE 121 or the web server 141 in the server 140 also operating in the communications network 100.

[0074] One or more UEs operate in the communication network 100, such as e.g. the UE 121. The UE 121 may represent a client 120 communicating with the server 140 using a transport layer protocol e.g., QUIC. The data connection between the UE 121 and the server 140 may be via a RAN node e.g., RAN node 110 and a CN node e.g., CN node 130. The UE 121 may e.g., be a wireless device, an NR device, a mobile station, a wireless terminal, an NB-loT device, an MTC device, an eMTC device, a CAT-M device, a WiFi device, an LTE device and a non-access point (non-AP) STA, a STA. It should be understood by the skilled in the art that “UE” is a non-limiting term which means any terminal, client, mobile client, IMS client, wireless communication terminal, user equipment, Device to Device (D2D) terminal, or node e.g., smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a car or any small base station communicating within a cell.

[0075] Network nodes, such as e.g., a proxy node 130, may operate in the communications network 100, such as in the CN, RAN or Internet. In some embodiments, the proxy node 130 may e.g., be represented by a QUIC proxy cluster.

[0076] CN nodes, such as e.g., proxy instances 132, 132, 133 operate in the CN 106 of the communications network 100. According to some embodiments herein, the proxy node 130 may comprise a cluster of one or more CN nodes e.g., proxy instances 131, 132, 133. The proxy instances may e.g., be represented by containers, virtual machines, software processes or threads.

[0077] Servers, such as e.g., in some embodiments herein, a server 140 operates in the communications network 100. The server 140 may comprise one or more web servers e.g., web server 141 and web server 142. According to example embodiments herein, the web server 141 may represent the client 120 that communicates with the web server 142 via the proxy node 130 in the CN 106. In some embodiments, the web server 142 communicates with the UE 121 which may act as the client 120 via the proxy node 130 in the CN 106. Databases such as e.g., a database 190 operates in the communication network 100. The database may comprise the protocol context for the communicating client 120 and the server 140. The database may be represented by e.g., distributed database or a key-value store. According to example embodiments herein, the database may be accessed by the proxy node 130 during data connection between the client 120 and the server 140.

[0078] According to embodiments herein, the communication between the client 120 and the server 140 is via the proxy node 130 comprising one or more proxy instance 131, 132, 133. In some embodiments herein, the communication may be from the client 120 to the server 140. In some embodiments herein, the communication may be from the server 140 to the client 120. The client 120 may be represented by the UE 121 or the web server 141 in the server 140. The server 140 may be represented by the web server 141 or the web server 142.

[0079] Methods according to aspects of embodiments herein are performed by the proxy node 130. This node may be Distributed Nodes (DN)s and their functionality may e.g., be comprised in a cloud 170 as shown in Figure 2.

[0080] Examples of embodiments herein provide e.g., a stateless and secure design of the proxy node. Embodiments herein increase reliability and resiliency of the client connections. The clients may be, e.g., different Internet of Things (loT) devices in the manufacturing and automotive sector, where the stability of the transport connections is highly important in such mission critical use-cases. Embodiments herein may result in a trade-off between the achieved resiliency and maximum throughput due to the required signalling with the database.

[0081] A number of embodiments will now be described, some of which may be seen as alternatives, while some may be used in combination.

[0082] A method according to embodiments herein will be described as seen from the view of the proxy node 130 together with Figure 3. This will be followed by a more detailed description with implementing examples of the method.

[0083] Figure 3 shows exemplary embodiments of a method performed by the proxy node 130. The method is for handling a data connection for a data packet stream between a client 120, 121, 141, and a server 140, 142, via the proxy node 130 in a communications network 100. As mentioned above, the client 120 may be represented by the UE 121 or the web server 141 in the server 140. The server 140 may be represented by the web server 141 or the web server 142. The proxy node 130 comprises a cluster of proxy instances 131, 132, 133. In some embodiments as described above, the proxy node 130 may e.g., be represented by a QIIIC proxy cluster.

[0084] According to an example scenario, the client 120 and the server 140 have established a data connection for data packet stream via the proxy node 130 comprising the proxy instances 131, 132, 133.

[0085] The method comprises the following actions, which actions may be taken in any suitable order. Optional actions are referred to as dashed boxes in Figure 3.

[0086] Action 301. The proxy node 130 may receive data packets from the client 120, 121, 141 and / or the server 140, 142. The data packets may e.g., refer to packets related to control signalling, user data, QIIIC packets, TLS packets, TCP packets. The data packets comprise the connection identifier identifying the data connection between the client 120 and the server 140.

[0087] Action 302. The proxy node 130 distributes data packets of the data packet stream, among one or more of the proxy instances 131 , 132, 133 in the cluster of proxy instances. The data packets are received from the client 120, 121, 141 and / or the server 140, 142. The distribution of the data packets may be performed by an LB comprised the proxy node 130. In some embodiments, the LB may distribute the received data packets in a round robin order i.e., the packets are distributed between proxy instances 131, 132, 133 equally. In some other embodiments, the LB may distribute the data packets with the same connection identifier to a specific proxy instance e.g., proxy instance 131. The LB may be part of the proxy node or be external to the proxy node.

[0088] Action 303. The proxy node 130 obtains from a database 190, that is shared between the proxy instances 131, 132, 133 in the cluster, a protocol context related to the client 120, 121 , 141 and / or the server 140, 142, for one or more of the proxy instances 131 , 132, 133 in the cluster that comprises a respective data packet of the distributed data packets. The protocol context is obtained based on a, e.g., one or more, connection identifiers comprised in the respective data packet, identifying said data connection. The database may be represented by e.g., distributed database that is resilient against failures or a key-value store. In some embodiments, the protocol context related to the client 120, 121 , 141 and / or the server 140, 142 correspond to a transport layer protocol for the data connection between the client 120, 121, 141 and the server 140, 142. In these embodiments, the transport layer protocol is represented by any one out of: QUIC protocol, TCP, TLS, SCTP, L4S. Action 304. For one or more of the proxy instances 131 , 132, 133 in the cluster that comprises a respective data packet of the distributed data packets, the proxy node 130 processes one or more out of: the respective data packet received from the client 120, 121 , 141 and / or the server 140, 142 and the obtained protocol context related to the client 120, 121 , 141 and / or the server 140, 142. In some embodiments, the processing may be performed by the proxy instances 131 , 132, 133 comprising the distributed data packet. As described in Action 303, the connection identifier in the data packet may be used to obtain the previously stored protocol context related to the data connection between the client 120 and the server 140. The processing may be performed to update the protocol context.

[0089] Action 305. For one or more of the proxy instances 131 , 132, 133 in the cluster that comprises a respective data packet of the distributed data packets, the proxy node 130 updates said protocol context based on information related to the respective data packet, and the processed respective data packet and / or the obtained 203 protocol context. In some embodiments, the updating may be performed by the proxy instances 131, 132, 133 comprising the distributed data packet if the processing was performed by the proxy instances 131, 132, 133 in Action 304.

[0090] Action 306. The proxy node 130 may encrypt the updated protocol context with an encryption key for one or more of the proxy instances 131 , 132, 133 in the cluster that comprises a respective data packet of the distributed data packets. The encryption may be performed by the proxy node 130 to enable use of untrusted databases to store the protocol context related to the data connection. In some embodiments, the encryption key is shared among the proxy instances 131, 132, 133. This may be to enable all proxy instances in the cluster of proxy instances 131, 132, 133 comprised in the proxy node 130 to access the protocol context stored in the database 190. According to the example scenario, this sharing of the encryption key to enable any proxy instance to access the protocol context from the database 190 enables the data connection between the client 120 and the server 140 to be kept without any interruption even if one of the proxy instances e.g., 131 fails.

[0091] Action 307. For one or more of the proxy instances 131 , 132, 133 in the cluster that comprises a respective data packet of the distributed data packets, the proxy node 130 stores said updated protocol context in the shared database. According to the example scenario, this shared access to the database 190 enables any proxy instance 131, 132, 133 in the cluster of proxy instances comprised in the proxy node 130 to access the stored protocol context, thereby enabling the data connection between the client 120 and the server 140 to be kept without any interruption even if one of the proxy instances e.g., 131 fails.

[0092] Action 308. The proxy node 130 identifies that a proxy instance 131, comprising at least one distributed data packet, of the cluster of proxy instances 131, 132, 133, fails. A proxy instance e.g., proxy instance 131 may fail due to e.g., a hardware or software failure, an overload situation, a security attack, a resource scaling or a software upgrade.

[0093] Action 309. When identifying that a proxy instance 131, comprising at least one distributed data packet, of the cluster of proxy instances 131, 132, 133, fails, the proxy node 130, obtains among the updated protocol contexts in the shared database, the protocol context of the failed proxy instance 131. In some embodiments, this obtaining of the protocol contexts related to the failed proxy instance 131 is to send them to another proxy instance e.g., proxy instance 132. In these embodiments, the data connection between the client 120 and the server 140 then may continue via the proxy instance 132.

[0094] Action 310. When identifying that a proxy instance 131, comprising at least one distributed data packet, of the cluster of proxy instances 131, 132, 133, fails, the proxy node 130, further replaces the failed proxy instance 131 with another proxy instance 132 from the cluster of proxy instances 131 , 132, 133. This replacement enables the data connection to be kept for the data packet stream between the client 120, 121, 141 and the server 140, 142 via the replaced proxy instance 132 comprised in the proxy node 130.

[0095] In this way by using the methods above, the solution provides resilient and secure transport-layer protocol proxy functionality for long living client connections e.g., connections of client 120, 121 , 141 without causing essential fluctuation in the latency and throughput in the case of an unexpected system failure on the proxy side. This means that any proxy instance 131 , 132, 133 may fail at any time without resetting the connection of the client 120, 121 , 141.

[0096] Embodiments herein such as the embodiments mentioned above will now be further described and exemplified. The text below is applicable to and may be combined with any suitable embodiment described above.

[0097] Figure 4 illustrates the topological location of the proxy node 130 between the client 120 and the server 140. In examples herein, the database 190 is referred to as a distributed DB and the proxy node 130 is referred to as proxy cluster. The proxy node 130 may be running on a container platform where each proxy instance 131, 132, 133 is executed inside its own container. The proxy node 130 may be running on a hypervisor where each proxy instance 131 , 132, 133 is executed inside its own virtual machine. The LB distributes the data packets between the proxy instances 131, 132, 133.

[0098] Connection identifier as database record identifier

[0099] According to some embodiments herein, the proxy instance 131, 132, 133 may select unique source connection identifiers towards the client 120 and the server 140 as illustrated in Figure 5. In examples herein, the database 190 is referred to as a context, and the proxy node 130 is referred to as QUIC proxy. This selection is to clarify the functionality and ensure the uniqueness of the identifiers. A source connection identifier identifies e.g., a QUIC connection at the QUIC client 120. The proxy node 130 may identify the protocol state of the corresponding connection between the client 120 and the server 140 in the database 190 using the connection identifiers as keys. These connection identifiers may act as protocol context identifiers. From the perspective of the proxy node 130, the protocol states of the connection between the client 120 and server 140 may relate to the same proxy context. Therefore, the proxy node 130 should preferably be able to fetch and store the full context using either of the keys.

[0100] There are at least two different approaches to avoid race conditions in updating protocol context in the database 190. One alternative is to use distributed record locking which is a technique of preventing simultaneous access to protocol context in a database, to prevent inconsistent results. For example, a widely used Redis database supports distributed locks which allow consistent simultaneous access to stored data. Its other capabilities are horizontal scalability and high availability. Another alternative is to avoid race-conditions by using Raft consensus algorithm to ensure consistency in storage of protocol context across all proxy instances 131 , 132, 133 in a proxy node 130. This is a reliable, distributed key-value store algorithm. According to embodiments herein, the key may refer to the connection identifier and the value may refer to the protocol context. It guarantees that multiple writers can update values i.e. , the protocol contexts in the keyvalue store without resulting in inconsistent results. The database 190 may be referred to as key-value store herein. This may be implemented by versioning the stored values i.e., the protocol contexts. The clients such as client 120 may fetch the version history of the values stored to the key-value store.

[0101] Connection identifier, packet number, stream offset analysis Example embodiments that analyze different situations about connection identifier, packet number, and stream offsets are described below.

[0102] Scenario 1: Initial connection establishment

[0103] The default connection identifier selection procedure is applied by the client 120. The default connection identifier selection procedure is applied to both directions by the proxy node 130. In this case, multiple keys for the key-value store are required. The web server e.g., web server 142 in a server 140 applies the default connection identifier selection procedure.

[0104] Scenario 2: Acknowledgement (ACK) procedure

[0105] The client 120 applies the default ACK procedure. The proxy node 130 may perform one of the two alternatives as described in Figure 6. In the first alternative, the default ack procedure is applied by the proxy node 130. In this case, the proxy node 130 uses its own packet number space towards the client 120 and the web server 142 and the packets may be re-transmitted at different rates towards the client 120 and the web server 142. In another alternative, the proxy node 130 relies on the protocol state of the client 120. The proxy node 130 forwards ACKs between the client 120 and the web server 142 and does not drop the data packets or reply with own ACKs to the web server 142.

[0106] The web server 142 applies the default ACK procedure.

[0107] Scenario 3: A http request is sent multiple times to the web server 142 by the proxy node 130

[0108] Such a scenario may e.g., happen e.g. POST operation. The client 120 trusts the proxy node 130 to behave correctly. The trust of the client 120 on the proxy node 130 is based on the certificate of the proxy node 130. Optionally, the certificate may have a pointer to a third party’s trust claim. The proxy node 130 copies the stream frames sent by the client 120 through the data connection towards the web server 142. A duplicate containing an already received packet number or stream offset is dropped by the web server 142 according to QIIIC specification RFC9000. In addition, application layer logic may prevent duplicates.

[0109] Consistent Database record updates

[0110] According to embodiments herein, the proxy node 130 comprises a database that may be e.g., a distributed database that supports locks or a distributed key-value store that supports Raft consensus algorithm as described above. In both cases, the database provides reliable and highly available storage for storing the protocol contexts. Example embodiments that describe the trade-offs between the different kinds of databases in different kinds of situations are described below. The example scenarios analyze the differences between parallel processing and serial processing of the data packets among the proxy instances 131, 132, 133 comprised in the proxy node 130. Parallel processing may refer to the use database 190 with key-value store based on Raft consensus algorithm without usage of locks. Serial processing may refer to the use of database 190 with locks.

[0111] Scenario 4: Multiple copies of a packet are processed by different proxy instances 131 , 132, 133.

[0112] Such a scenario may happen when a client 120 re-transmits a data packet or LB creates copies of the data packets from the client 120. Parallel processing of packets may lead to that each proxy instance 131 , 132, 133 sends a reply to the client 120. The reply may be e.g., a QIIIC Initial packet. The client 120 may in such case is expected to drop the extra replies. In serial processing, one of the proxy instances e.g., proxy instance 131 may acquire the mutex which is a software locking mechanisms for data fields containing the context. It may then process the data packet received from the client 120 and update the protocol context in the database 190 as described in Actions 304 and 305 while other proxy instances 132, 133 may drop the received data packet after fetching the updated protocol context. In this scenario, the cost of parallel processing may be measured by the number of reply packets sent by the proxy instances 131, 132, 133 to the client 120.

[0113] Scenario 5: Client 120 sends a stream of payload data packets which are distributed by a LB between the proxy instances 131, 132, 133.

[0114] Parallel packet processing increases the throughput. However, the proxy instances 131 , 132, 133 may get multiple versions of the protocol context from the database 190 that increases the amount of processing i.e., protocol context resolution. A protocol context resolution may e.g., mean that the proxy instance 131 , 132, 133 identifies the latest version of the context. This also increases the number of bytes transferred from the database 190 for each received data packet from the client 120. In serial processing, each proxy instance 131 , 132, 133 processes the received data packet sequentially after acquiring the mutex. Even though serial processing reduces the throughput, the positive side is that it also reduces the amount of required computation as there is no context resolution. As a result, the number of bytes transferred from the database 190 to the proxy instance 131 , 132, 133 are also reduced. There’s a correlation between the packet throughput and the consumed computation and network resources among the proxy instances 131, 132, 133 in the proxy node 130.

[0115] Scenario 6: A proxy instance 131 , 132, 133 crashes during the data packet

[0116] In parallel processing, the crash of a proxy instance e.g., proxy instance 131 as described above in the Action 308, does not have impact on other proxy instances such as proxy instances 132, 133. However, it leads to packet re-transmission at the client side. In serial processing, after a crash, a mutex is freed after a timeout that was defined by the proxy instance e.g., proxy instance 131 when the lock was acquired. The challenge in this case is to find an optimal timeout that does not interrupt the processing of the data packet for too long time after a crash. On the other hand, if the mutex timeout is too short and another proxy instance 132 acquires the lock, it prevents the original caller i.e., proxy instance 131. To update the protocol context. LB may send a copy of the received data packet to two or more proxy instances to avoid re-transmissions from the client 120 after a crash on the proxy instance e.g., proxy instance 131. This means that there is a trade-off between re-transmissions from the client 120 and resources consumed by multiple proxy instances 131, 132, 133; i.e., in terms of computational resources and the number of reply data packets.

[0117] -value store and versioning of values

[0118] According to examples described above, in the case of using a database 190 based on Raft consensus algorithm, different proxy instances 131 , 132, 133 may store their own versions of the protocol context to the key-value store due to parallel processing of the data packets. This is illustrated in the following Table 1. Table 1 describes an example of parallel processing of the data packets in two proxy instances 131 and 132 according to example embodiments herein. The first two columns of Table 1 illustrate the packet processing steps in the two proxy instances 131 and 132, and the third column illustrates the stored protocol context versions with included packet numbers. Pn#x may refer to the packet number x. ctx#x may refer to the protocol context x. In some example embodiments, a proxy instance 131 , 132, 133 that is processing a data packet may receive multiple versions of the protocol context from the database 190. Therefore, each protocol instance 131, 132, 133 may have to merge the different versions of the protocol context received from the database 190 before processing the data packet and updating the protocol context. This procedure is called as protocol context resolution in the proxy instance 131 , 132, 133. According to some embodiments herein, after the protocol context resolution, processing of the received data packet and storing of the updated protocol context to the key-value store i.e., database 190, the proxy instance 131 , 132, 133 may delete the older versions of the protocol context in the database 190. Protocol context encryption key for database

[0119] As described above in Action 306, a shared encryption key is used to encrypt the protocol context before storing it to the database 190. This may be to enable all proxy instances in the cluster of proxy instances 131, 132, 133 comprised in the proxy node 130 to access the protocol context stored in the database 190. According to the example embodiments herein, this sharing of the encryption key to enable any proxy instance to access the protocol context from the database 190 enables the data connection between the client 120 and the server 140 to be kept without any interruption even if one of the proxy instances e.g., 131 fails. The proxy instance 131 , 132, 133 may acquire the shared encryption key in a secure manner during the start-up phase from the orchestration or configuration platform, such as e.g. Kubernetes or Ansible. This may be implemented, e.g., by storing the shared encryption key to a secure key storage where the proxy instance 131 , 132, 133 fetches the key. The proxy instance 131, 132, 133 may use, e.g., a client certificate for authenticating itself to the secure key storage that is provisioned to the proxy instances 131, 132, 133 by the platform during the launch. In some embodiments, the shared encryption key is provisioned with enclave technologies.

[0120] Load Balancer (LB) and cluster platform

[0121] According to embodiments herein as described above, a LB distributes traffic between proxy instances 131, 132, 133 in the proxy node 130. LB is topologically located between the client 120 and the proxy node 130 and between the proxy node 130 and the web service 142 in the server 140, as illustrated in Figure 4. In some embodiments, the LB between the proxy node 130 and web server 142 is optional. The identification of the connections in LB is based on the destination connection identifiers carried in the data packets. As mentioned above, the distribution of the data connections between the proxy instances 131, 132, 133 may happen in a round-robin fashion or the LB may support so- called sticky connections where the data packets carrying the same destination connection identifier are forwarded to the same proxy instance say e.g., proxy instance 131. According to embodiments herein as described in Action 310, if the proxy instance 131 stops working, the LB selects a new registered proxy instance say e.g., proxy instance 132 for the data connection between the client 120 and the web server 142. The proxy instances 131, 132, 133 are, upon startup, registered to the LB. The private IP address of the proxy instance 131 , 132, 133 may be registered to the LB when the instance is launched. The registration may be done by the proxy node 130 running on a platform e.g., Kubernetes platform. The platform may also monitor the proxy instances 131 , 132, 133 during run-time and finds out if some of the proxy instances e.g., 131 stop working. In this case, the platform deregisters the failed proxy instance 131 from the LB.

[0122] LB may implement Network Address Translation (NAT) functionality between IP addresses towards endpoints and private IP addresses used by proxy instances 131, 132, 133 in the proxy node 130. LB may bind a public IP address with the connection identifier i.e., the destination connection identifier of the client 120 and the web server 142 carried in the data packets from the proxy node 130 to the client 120 and the web server 142. In this way, the IP address of the proxy node 130 remains the same towards the client 120 and the web server 142. This means that LB hides the data connection migration between the proxy instances 131 , 132, 133 during the connection lifetime from the client 120 and web server 142 perspective. LB may implement port number translations towards the web server 142. The client 120 and the web server 142 may by default accept the data packets related to a specific data connection that are coming from different source port numbers since this may happen also due to any NAT renumbering event.

[0123] As mentioned above, QUIC handshakes may be performed by 0-RTT handshake and 1-RTT handshake. Embodiments below describe the different variants of the QUIC handshake and streams.

[0124] Variant 1 : Proxy node 130 - Round-robin load balancing

[0125] This variant describes the distributed processing of QUIC 1-RTT data packets in the proxy node 130 as illustrated in Figure 7. In this variant, the LB distributes the incoming packets in a round-robin fashion between proxy instances 131 , 132, 133. The proxy instance e.g., 131 may stop working at any time due to a system failure or other disturbances. The presented signalling below protects the loss of the protocol state related to the data connection at the proxy node 130 against these kinds of situations. The signalling in the following embodiment correspond to the processing of handshake packets in the proxy node 130.

[0126] 700. Each proxy instance 131 , 132, 133 in the proxy node 130 acquires the secret key in the beginning of the execution as described above. The same secret key may be used by all the proxy instances for encrypting the shared protocol context in the database 190 according to Action 306. This may be to enable all proxy instances in the cluster of proxy instances 131 , 132, 133 comprised in the proxy node 130 to access the protocol context stored in the database 190. According to the example embodiments herein, this sharing of the encryption key to enable any proxy instance to access the protocol context from the database 190 enables the data connection between the client 120 and the server 140 to be kept without any interruption even if one of the proxy instances e.g., 131 fails. The key may be acquired in different ways as discussed earlier.

[0127] 701. The client 120 sends the first handshake packet to the IP address of the LB. In this variant, the LB forwards the data packet in a round-robin order to one of the stateless proxy instances 131, 132, 133 running in the proxy node 130. In Figure 7, the data packet is forwarded to proxy instance 131. Each proxy instance 131 implements the protocol stack according to RFCs.

[0128] 702. In case the client 120 does not receive a reply from the proxy node 130 within a specified time-period, it sends a new data packet with an increased packet number to the LB after a timeout. In Figure 7, the data packet is forwarded by the LB to the proxy instance 132. This may result in parallel processing of the data packets from the client 120 in the proxy node 130 as illustrated in Figure 7.

[0129] 703. The fetch and store operation of the protocol context in the database 190 consists of two parts as described in Actions 303, 304, 305 and 307. Firstly, the proxy instance e.g., 131 fetches the protocol context as described in Action 303 from the database 190 if there is any previously stored protocol context based on the destination connection identifier carried in the data packet received in step 701. Secondly, the proxy instance 131 processes, updates and stores the protocol context to the database 190 Actions 304, 305 and 307. The protocol context may be encrypted with the secret key that was acquired by the proxy instance 131 in step 700. The communication between the proxy instance 131 and the database 190 may use, e.g., http3. As described earlier, the race condition in updating the protocol context in the database 190 may be solved, e.g., by using locks or using Raft consensus algorithm. Both alternatives may be applied in this step and in further steps. If the database 190 uses locks, the proxy instance 131 acquires the mutex before fetching the protocol context from the database 190. If the database 190 supports Raft consensus algorithm, the proxy instance 131 takes care of the version of the protocol context by performing protocol context resolution as described earlier as part of this step.

[0130] 704. The database 190 replies that the operation was successful and releases the mutex if the database 190 supports locks.

[0131] 705. The proxy instance 131 replies to the client 120 according to the RFC which may be e.g., an acknowledgement packet. The communication through the LB allows that the destination IP address remains the same from the perspective of the client 120 even when the data packet may be processed in different topological locations in the proxy node 130 i.e., in different proxy instances 131 , 132, 133.

[0132] 706. The proxy instance 132 makes a query to the database 190 to fetch the protocol context. It receives the protocol context from the database 190 that was already stored by the proxy instance 131 in step 703. However, he proxy instance 132 may assume that the reply packet from the proxy instance 131 in step 705 did not reach the client 120 and that may be the reason that the client 120 retransmitted the data packet in step 702. Therefore, the proxy instance 132 continues processing the data packet received in step 702 and stores an updated protocol context to the database 190.

[0133] 707. In this step, the same actions as in step 704 are performed.

[0134] 708. The proxy instance 132 follows the same procedure like the proxy instance 131 in step 705. However, according to RFC the client 120 discards the received data packet since it has already processed the reply from the proxy instance 131 in step 705.

[0135] 709. The client 120 sends a handshake packet to the LB that forwards the packet to the proxy instance 133 in a round-robin order.

[0136] 710. The proxy instance 133 makes a query to the database 190 to fetch the protocol context.

[0137] 711. The database 190 replies with the encrypted protocol context. In this part of the signalling in Figure 7, the communication between the proxy instance 133 and the database 190 is divided into more detailed signalling flows.

[0138] 712. The proxy instance 133 acts as a client 120 towards the web server 142 and negotiates a handshake with the web server 142. There are two alternative ways for running the handshake in the proxy node 130 through LB that is located between the proxy node 130 and the web server 142. As one alternative, the LB may distribute the handshake packets between the proxy instances 131 , 132, 133 during the handshake in a similar way as with the client 120 in the earlier steps. As another alternative, the LB may sticky tag the connections to the same proxy instance say e.g., 133 for the full handshake. In Figure 7, the LB translates private IP address of the proxy instance 133 to an IP address that is visible towards the web server 142 based on the destination connection identifier. The established data connection with the web server 142 is used later in step 717 to forward the data stream from the client 120 to the web server 142 and from the web server 142 to the client 120.

[0139] 713. After successful handshake in step 712, the proxy instance 133 stores the protocol contexts both for the client 120 and the web server 142 to the database 190 using the source connection identifiers as protocol context identifiers. 714. In this step, the same actions as in step 704 are performed.

[0140] 715. The proxy instance 133 replies to client 120 with a data packet according to RFC.

[0141] 716. The client 120 sends data in stream frames to the proxy node 130. This is illustrated in more detail in Figure 8.

[0142] 717. The proxy node 130 forwards the received stream frames to the web server 142 using the data connection established in step 712. This is illustrated in more detail in the Figure 8.

[0143] Figure 8 illustrates the stream forwarding between the client 120 and the web server 142 through the proxy node 130. In this variant, the LB distributes the incoming data packets in a round-robin order between the proxy instances 131, 132, 133. The proxy instances e.g., 131 may stop working at any time due to a system failure or other disturbances. The presented signalling below protects the loss of the protocol state related to the data connection at the proxy node 130 against these kinds of situations. The signalling in the following embodiment correspond to the processing of stream packets in the proxy node 130. The stream packets may also be referred to as e.g., data packets herein.

[0144] 801. In this step, the 1-RTT handshake between the client 120 and the proxy node 130 as presented earlier in Figure 7 is performed.

[0145] 802. In this step, the 1-RTT handshake between the proxy node 130 and the web server 142 as presented earlier in Figure 7 is performed.

[0146] 803. The client 120 sends a 1-RTT data packet with a stream frame carrying an HTTP request fragment to the LB. The LB forwards the data packet in a round-robin order to the proxy instance 131.

[0147] 804. The proxy instance 131 fetches the protocol context from the database 190, processes the received data packet and stores the updated protocol context to the database 190. As part of the processing, the proxy instance 131 follows the normal packet parsing and verification procedure in the server side as described in RFC.

[0148] 805. The database 190 replies that the operation was successful.

[0149] 806. The proxy instance 131 copies the stream frame received in step 803 to a 1- RTT data packet that it sends to the web server 142 using a stream established in step 802.

[0150] 807. In this step, as first option, the proxy instance 131 may reply with an ACK including the packet number carried in 1-RTT in step 803. In this first option, the stream packets may arrive in a higher rate from the client 120 through the proxy node 130 to the web server 142 than the web server 142 can process in step 806. As a result, the proxy node 130 may need to buffer and re-transmit the packets for the web server 142 more than in the second option described in step 811. However, in the second option described in step 811 , the throughput may be worse than in the first option due to an extra database signalling in step 809.

[0151] 808. The web server 142 replies with 1-RTT carrying an ACK frame as a response to the message in step 806. In Figure 8, the LB forwards the message in a round-robin order to the proxy instance 132.

[0152] 809. The proxy instance 132 fetches, processes, updates and stores the protocol context to the database 190 as described in Actions 303, 304, 305 and 307.

[0153] 810. The database 190 replies that the operation was successful.

[0154] 811. In this step, the second option as mentioned in step 807 is performed. The proxy instance 132 replies with an ACK frame including the packet number carried in 1- RTT in step 803. The trade-offs between the first option and the second option were discussed in step 807.

[0155] 812. The web server 142 defragments the received http request and parses the request.

[0156] 813. The web server 142 performs the web logic based on the received http request.

[0157] 814. The web server 142 replies with an http reply message that is in most cases fragmented to multiple 1-RTT stream packets. The web server 142 sends the stream packets to the LB that forwards them in a round-robin order to proxy instances 131 , 132, 133. In Figure 8, the proxy instance 133 receives the data packet.

[0158] 815. In this step, the same actions as performed in step 809 are performed.

[0159] 816. In this step, the same actions as performed in step 810 are performed.

[0160] 817. The proxy instance 133 copies the stream frame received in step 814 to a 1- RTT packet that it sends to the web server 142 through the LB using a stream established in step 801.

[0161] Variant 2: Proxy node 130 - Sticky connections at load balancer

[0162] This variant describes the distributed processing of QUIC 1-RTT data packets in the proxy node 130 as illustrated in Figure 9. In this variant, the LB distributes the incoming packets in a sticky fashion that binds each data connection to a specific proxy instance e.g., 131 based the connection identifiers carried in the data packets. As described in variant 1 , the proxy instance e.g., 131 may stop working at any time due to a system failure or other disturbances. The presented signalling below protects the loss of the protocol state related to the data connection at the proxy node 130 against these kinds of situations. The signalling in the following embodiment correspond to the processing of handshake packets in the proxy node 130.

[0163] 900. In this step, the same actions as performed in step 700 of variant 1 are performed.

[0164] 901. The client 120 sends the first exchange packet to the IP address of the LB. In this variant, the LB forwards the packet to a specific proxy instance say e.g., 131 based on the destination connection identifier carried in the data packet. This is called sticky tagging.

[0165] 902. In this step, the same actions as performed in step 703 in variant 1 are performed.

[0166] 903. In this step, the same actions as performed in step 704 in variant 1 are performed.

[0167] 904. In case the client 120 does not receive a reply from the proxy node 130 within a specified time period, it sends a new data packet with an increased packet number to the LB after a timeout. In Figure 9, the data packet is forwarded to the proxy instance 131 instance due to the sticky connection binding in the LB. The proxy instance 131 discards the data packet because it has not yet replied to the first data packet received in step 901. This helps in efficient resource utilization as data is not shared between multiple proxy instances 131, 132, 133, thereby reducing the signalling that is required to keep data in sync between the multiple proxy instances, e.g., proxy instances 131 , 132, 133.

[0168] 905. In this step, the same actions as performed in step 705 in variant 1 are performed.

[0169] 906. The client 120 sends a handshake packet to the LB that forwards the packet to the proxy instance 131 due to sticky connections.

[0170] 907. In this step, the same actions as performed in step 712 in variant 1 are performed.

[0171] 908. The proxy instance 131 needs to fetch the protocol context only once in step 902 in this variant. After that it stores the updated protocol context to the database 190.

[0172] 909. In this step, the same actions as performed in step 704 in variant 1 are performed.

[0173] 910. In this step, the same actions as performed in step 715 in variant 1 are performed. 911. The client 120 sends data in stream frames to the proxy node 130. This is illustrated in more detail in Figure 10.

[0174] 912. The proxy node 130 forwards the received stream packets to web server 142 using the data connection established in step 907. This is illustrated in more detail in Figure 10.

[0175] Figure 10 illustrates the stream forwarding between the client 120 and the web server 142 through the proxy node 130. In this variant, the LB distributes the incoming packets in a sticky fashion that binds each connection to a specific proxy instance e.g., 131. Also in this case, the proxy instances e.g., 131 may stop working at any time due to a system failure or other disturbance. The presented signalling below protects the loss of the protocol state related to the data connection at the proxy node 130 against these kinds of situations. The signalling in the following embodiment correspond to the processing of stream packets in the proxy node 130. The stream packets may also be referred to as e.g., data packets herein.

[0176] 1001. In this step, the handshake between the client 120 and the proxy node 130 as presented earlier in Figure 9 is performed.

[0177] 1002. In this step, the handshake between the proxy node 130 and the web server 142 as presented earlier in Figure 9 is performed.

[0178] 1003. In this step, the same actions as performed in step 803 in variant 1 are performed.

[0179] 1004. The proxy instance 131 fetches the protocol context from the database 190. This is done only once for the specific connection identifier during the lifetime of the proxy instance 131. This is because the same proxy instance 131 handles all the data packets between the client 120 and the web server 142. This reduces the signalling that is required to keep data in sync between the multiple proxy instances, e.g., proxy instances 131 , 132, 133.

[0180] 1005. In this step, the same actions as performed in step 805 in variant 1 are performed.

[0181] 1006. The proxy instance 131 processes the received data packet and stores the updated protocol context to the database 190. As part of the processing, the proxy instance 131 follows the normal packet parsing and verification procedure in the server side as described in RFC. 1007. In this step, the same actions as performed in step 805 in variant 1 are performed.

[0182] 1008. In this step, the same actions as performed in step 806 in variant 1 are performed.

[0183] 1009. In this step, the same actions as performed in step 808 in variant 1 are performed.

[0184] 1010. In this step, the same actions as performed in step 1006 are performed.

[0185] 1011. In this step, the same actions as performed in step 1007 are performed.

[0186] 1012. In this step, the same actions as performed in step 811 or 807 in variant 1 are performed.

[0187] 1013. In this step, the same actions as performed in step 812 in variant 1 are performed.

[0188] 1014. In this step, the same actions as performed in step 813 in variant 1 are performed.

[0189] 1015. In this step, the same actions as performed in step 814 in variant 1 are performed.

[0190] 1016. In this step, the same actions as performed in step 815 in variant 1 are performed.

[0191] 1017. In this step, the same actions as performed in step 816 in variant 1 are performed.

[0192] 1018. In this step, the same actions as performed in step 817 in variant 1 are performed.

[0193] Variant 3: Proxy node 130 - Proxy node 130 acts also as web server

[0194] This variant describes the distributed processing of QIIIC 1-RTT data packets in the proxy node 130 as illustrated in Figure 11 and Figure 12. Figure 11 illustrates the handshake signalling and Figure 12 illustrates the reply from the proxy node 130 for the http3 request. In this variant, the proxy instances 131 , 132, 133 also implement the web server logic. The variant 3 in Figure 11 is otherwise similar to variant 1 in Figure 7, except in variant 3 there is no handshake between the proxy node 130 and the web server 142.

[0195] 1201. This step is illustrated in Figure 11.

[0196] 1202. In this step, the same actions as performed in step 801 in variant 1 are performed. 1203. In this step, the same actions as performed in step 804 in variant 1 are performed. But here the proxy instance 131 also stores the stream frames together with the context to the database 190.

[0197] 1204. In this step, the same actions as performed in step 805 in variant 1 are performed.

[0198] 1205. In this step, the same actions as performed in step 807 in variant 1 are performed.

[0199] 1206. The client 120 sends the last stream frame of the http request.

[0200] 1207. The proxy instance 133 makes a query to the database 190 to fetch the protocol context including all the received stream frames.

[0201] 1208. The database 190 replies with the protocol context.

[0202] 1209. The proxy instance 133 performs packet defragmentation based on the received stream frames.

[0203] 1210. The proxy instance 133 executes the web logic for the received http request from the client 120 and communicates with the web content in the database 190 if necessary.

[0204] 1211. The proxy instance 133 stores the updated protocol context with the connection identifier and proxy identifier after every N:th outgoing 1-RTT packet. N can be any number between 0 and total number of http reply packets. According to embodiments herein, this storing of the protocol context along with the connection identifier and the proxy identifier enables to fetch the protocol contexts corresponding to a data connection even when a proxy instance e.g., 133 fails thereby enabling the replacement of the failed proxy instance 133 with a new proxy instance 132 as described in steps 1214 to 1217. In case the proxy instance 133 crashes during the operation, the next proxy instance that is launched by the proxy node 130 may end up retransmitting some of the data packets according to the protocol context information in the database 190 as described in steps 1215 to 1217. This means that there is a trade-off between the amount of signaling with the database 190 and the packet retransmissions after a crash.

[0205] 1212. The database 190 replies that the operation was ok.

[0206] 1213. The proxy instance 133 sends a 1-RTT packet carrying a stream frame to the client 120. The client 120 acknowledges the received packets.

[0207] 1214. In case the proxy instance 133 crashes while sending the http reply to the client 120, the proxy node 130 identifies the crash as described in Action 308. The proxy node 130 knows the identifier of the proxy instance that failed i.e., the proxy instance 133. 1215. The proxy node 130 makes a query to the database 190 to fetch all the protocol contexts corresponding to the proxy identifier that is in this case the proxy instance 133 as mentioned in Action 309.

[0208] 1216. The database 190 replies with one or more protocol contexts. In some design approaches, it is possible that the proxy instance 133 that failed was processing multiple client sessions. In this case, the proxy node 130 uses the connection identifier to identify the protocol context related to the data connection with the client 120.

[0209] 1217. The proxy node 130 calls the API at the LB to register as described in Action 310 a new proxy instance for the destination connection identifier that is in this case the proxy instance 132. According to embodiments herein, this registration of the new proxy instance 132 in the place of the failed proxy instance 133 allows the data connection with the client 120 to be kept even when the proxy instance 133 fails without the need to establish a new data connection.

[0210] 1218. The LB calls an API at the proxy instance 132 to trigger the http reply process that is the same as steps 1211 to 1213.

[0211] Variant 4: Proxy cluster - 0-RTT

[0212] In this variant, the processing of the 0-RTT handshake packets in the proxy node 130 is described. As mentioned earlier, the 0-RTT handshake includes an option for client 120 to send data immediately in the first message. To support 0-RTT signalling with the stateless proxy node 130, it is possible to establish a handshake between the proxy node 130 and the web server 142 already after the first data packet from the client 120 arrives as presented above in variant 1 after step 704 and in variant 2 after step 903.

[0213] The LB may create and / or destroy the proxy node 130 dynamically based on the traffic amount when the proxy node 130 is implemented as a cloud function.

[0214] To perform the method actions above, the proxy node 130 is configured to handle a data connection for a data packet stream between a client 120, 121 , 141 and a server 140, 142, via the proxy node 130 in a communications network 100. The proxy node 130 is adapted to comprise a cluster of proxy instances 131, 132, 133. The proxy node 130 may comprise an arrangement depicted in Figure 13. The proxy node 130 may comprise an input and output interface 1300 configured to communicate in the communications network 100. The input and output interface 1300 may comprise a wireless receiver not shown, and a wireless transmitter not shown.

[0215] The proxy node 130 is further configured to distribute data packets of the data packet stream, among one or more of the proxy instances 131 , 132, 133 in the cluster of proxy instances. The data packets are received from the client 120, 121 , 141 and / or the server 140, 142.

[0216] For one or more of the proxy instances 131, 132, 133 in the cluster that comprises a respective data packet of the distributed data packets:

[0217] - The proxy node 130 is further configured to obtain from a database that is shared between the proxy instances 131, 132, 133 in the cluster, a protocol context related to the client 120, 121, 141 and / or the server 140, 142, based on a connection identifier comprised in the respective data packet, identifying said data connection,

[0218] - The proxy node 130 is further configured to process one or more out of: the respective data packet received from the client 120, 121 , 141 and / or the server 140, 142 and the obtained 203 protocol context related to the client 120, 121 , 141 and / or the server 140, 142,

[0219] - The proxy node 130 is further configured to update said protocol context based on information related to the respective data packet, and the processed respective data packet and / or the obtained 203 protocol context,

[0220] - The proxy node 130 is further configured to store said updated protocol context in the shared database,

[0221] The proxy node 130 is further being configured to:

[0222] Identify that a proxy instance 131, comprising at least one distributed data packet, of the cluster of proxy instances 131, 132, 133 fails:

[0223] - Obtain among the updated protocol contexts in the shared database, the protocol context of the failed proxy instance 131 and

[0224] - Replace the failed proxy instance 131 with another proxy instance 132 from the cluster of proxy instances 131 , 132, 133, enabling the data connection to be kept for the data packet stream between the client 120, 121, 141 and the server 140, 142 via the replaced proxy instance 132 comprised in the proxy node 130.

[0225] In some embodiments, the proxy node 130 is further being configured to: for one or more of the proxy instances 131, 132, 133 in the cluster that comprises a respective data packet of the distributed data packets, encrypt the updated protocol context with an encryption key, which encryption key is adapted to be shared among the proxy instances 131 , 132, 133.

[0226] In some embodiments, the protocol contexts related to the client 120, 121 , 141 and / or the server 140, 142 correspond to a transport layer protocol for the data connection between the client 120, 121, 141 and the server 140, 142.

[0227] In some embodiments, the transport layer protocol is adapted to be represented by any one out of: QIIIC protocol, Transmission Control Protocol, TCP, Transport Layer Security, TLS, Stream Control Transmission Protocol, SCTP, Low Latency, Low Loss, and Scalable Throughput, L4S.

[0228] Embodiments herein may be implemented through a respective processor or one or more processors, such as the respective processor 1310 of a processing circuitry in the proxy node 130 depicted in Figure 13 together with respective computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the respective proxy node 130. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the respective proxy node 130.

[0229] The proxy node 130 may further comprise a respective memory 1320 comprising one or more memory units. The respective memory 1320 comprises instructions executable by the processor in the respective proxy node 130. The respective memory 1320 are arranged to be used to store e.g., media functions, indications, tags, information, data, configurations, communication data, and applications to perform the methods herein when being executed in the respective proxy node 130.

[0230] In some embodiments, a respective computer program 1330 comprises instructions, which when executed by the respective at least one processor 1310, cause the at least one processor of respective proxy node 130 to perform the actions above.

[0231] In some embodiments, a respective carrier 1340 comprises the respective computer program 1330, wherein the respective carrier 1340 is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium. Those skilled in the art will appreciate that units in the respective proxy node 130 described above may refer to a combination of analog and digital circuits, and / or one or more processors configured with software and / or firmware, e.g. stored in the respective proxy node 130, that when executed by the respective one or more processors such as the processors described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry ASIC, or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a System-on-a-Chip (SoC).

[0232] ADDITIONAL EXPLANATION

[0233] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0234] Figure 14 shows an example of a communication system QQ100 in accordance with some embodiments.

[0235] In the example, the communication system QQ100 includes a telecommunication network QQ102 that includes an access network QQ104, such as a radio access network (RAN), and a core network QQ106, which includes one or more core network nodes QQ108. The access network QQ104 includes one or more access network nodes, such as network nodes QQ110a and QQ110b (one or more of which may be generally referred to as network nodes QQ110), or any other similar 3rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network QQ102 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network QQ102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network QQ102, including one or more network nodes QQ110 and / or core network nodes QQ108. Examples of an ORAN network node include an open radio unit (0-Rll), an open distributed unit (0-Dll), an open central unit (O-CU), including an O-CU control plane (O- CLI-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1, F1, W1, E1 , E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes QQ110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 121, QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which may be generally referred to as UEs QQ112) to the core network QQ106 over one or more wireless connections.

[0236] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system QQ100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system QQ100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0237] The UEs QQ112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes QQ110 and other communication devices. Similarly, the network nodes QQ110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs QQ112 and / or with other network nodes or equipment in the telecommunication network QQ102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network QQ102.

[0238] In the depicted example, the core network QQ106 connects the network nodes QQ110 to one or more hosts, such as host QQ116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network QQ106 includes one more core network nodes (e.g., core network node QQ108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node QQ108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (ALISF), Subscription Identifier Deconcealing function (SidentifierF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0239] The host QQ116 may be under the ownership or control of a service provider other than an operator or provider of the access network QQ104 and / or the telecommunication network QQ102, and may be operated by the service provider or on behalf of the service provider. The host QQ116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0240] As a whole, the communication system QQ100 of Figure 14 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0241] In some examples, the telecommunication network QQ102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network QQ102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network QQ102. For example, the telecommunications network QQ102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0242] In some examples, the UEs QQ112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network QQ104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network QQ104. Additionally, a UE may be configured for operating in single- or multi- RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0243] In the example, the hub QQ114 communicates with the access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UE QQ112c and / or QQ112d) and network nodes (e.g., network node QQ110b). In some examples, the hub QQ114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub QQ114 may be a broadband router enabling access to the core network QQ106 for the UEs. As another example, the hub QQ114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes QQ110, or by executable code, script, process, or other instructions in the hub QQ114. As another example, the hub QQ114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub QQ114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub QQ114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub QQ114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub QQ114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0244] The hub QQ114 may have a constant / persistent or intermittent connection to the network node QQ110b. The hub QQ114 may also allow for a different communication scheme and / or schedule between the hub QQ114 and UEs (e.g., UE QQ112c and / or QQ112d), and between the hub QQ114 and the core network QQ106. In other examples, the hub QQ114 is connected to the core network QQ106 and / or one or more UEs via a wired connection. Moreover, the hub QQ114 may be configured to connect to an M2M service provider over the access network QQ104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes QQ110 while still connected via the hub QQ114 via a wired or wireless connection. In some embodiments, the hub QQ114 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node QQ110b. In other embodiments, the hub QQ114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node QQ110b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0245] Figure 15 shows a UE QQ200 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes such as e.g. proxy node 130 and / or other UEs, such as e.g., UE 121. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptopmounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-loT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0246] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0247] The UE QQ200 includes processing circuitry QQ202 that is operatively coupled via a bus QQ204 to an input / output interface QQ206, a power source QQ208, a memory QQ210, a communication interface QQ212, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 15. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0248] The processing circuitry QQ202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory QQ210. The processing circuitry QQ202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry QQ202 may include multiple central processing units (CPUs).

[0249] In the example, the input / output interface QQ206 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE QQ200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0250] In some embodiments, the power source QQ208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source QQ208 may further include power circuitry for delivering power from the power source QQ208 itself, and / or an external power source, to the various parts of the UE QQ200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source QQ208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source QQ208 to make the power suitable for the respective components of the UE QQ200 to which power is supplied.

[0251] The memory QQ210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory QQ210 includes one or more application programs QQ214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data QQ216. The memory QQ210 may store, for use by the UE QQ200, any of a variety of various operating systems or combinations of operating systems.

[0252] The memory QQ210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAidentifier), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUlCC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory QQ210 may allow the UE QQ200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory QQ210, which may be or comprise a device-readable storage medium.

[0253] The processing circuitry QQ202 may be configured to communicate with an access network or other network using the communication interface QQ212. The communication interface QQ212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna QQ222. The communication interface QQ212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter QQ218 and / or a receiver QQ220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter QQ218 and receiver QQ220 may be coupled to one or more antennas (e.g., antenna QQ222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0254] In the illustrated embodiment, communication functions of the communication interface QQ212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11 , Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0255] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface QQ212, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0256] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0257] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smartwatch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE QQ200 shown in Figure 15.

[0258] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-loT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation. In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0259] Figure 16 shows a network node QQ300 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O- RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU).

[0260] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0261] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi- cel l / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs). The network node QQ300 includes a processing circuitry QQ302, a memory QQ304, a communication interface QQ306, and a power source QQ308. The network node QQ300 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node QQ300 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node QQ300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory QQ304 for different RATs) and some components may be reused (e.g., a same antenna QQ310 may be shared by different RATs). The network node QQ300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node QQ300, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFidentifier) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node QQ300.

[0262] The processing circuitry QQ302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node QQ300 components, such as the memory QQ304, to provide network node QQ300 functionality.

[0263] In some embodiments, the processing circuitry QQ302 includes a system on a chip (SOC). In some embodiments, the processing circuitry QQ302 includes one or more of radio frequency (RF) transceiver circuitry QQ312 and baseband processing circuitry QQ314. In some embodiments, the radio frequency (RF) transceiver circuitry QQ312 and the baseband processing circuitry QQ314 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry QQ312 and baseband processing circuitry QQ314 may be on the same chip or set of chips, boards, or units. The memory QQ304 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device- readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry QQ302. The memory QQ304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry QQ302 and utilized by the network node QQ300. The memory QQ304 may be used to store any calculations made by the processing circuitry QQ302 and / or any data received via the communication interface QQ306. In some embodiments, the processing circuitry QQ302 and memory QQ304 is integrated.

[0264] The communication interface QQ306 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface QQ306 comprises port(s) / terminal(s) QQ316 to send and receive data, for example to and from a network over a wired connection. The communication interface QQ306 also includes radio front-end circuitry QQ318 that may be coupled to, or in certain embodiments a part of, the antenna QQ310. Radio front-end circuitry QQ318 comprises filters QQ320 and amplifiers QQ322. The radio front-end circuitry QQ318 may be connected to an antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry may be configured to condition signals communicated between antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry QQ318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry QQ318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters QQ320 and / or amplifiers QQ322. The radio signal may then be transmitted via the antenna QQ310. Similarly, when receiving data, the antenna QQ310 may collect radio signals which are then converted into digital data by the radio front-end circuitry QQ318. The digital data may be passed to the processing circuitry QQ302. In other embodiments, the communication interface may comprise different components and / or different combinations of components. In certain alternative embodiments, the network node QQ300 does not include separate radio front-end circuitry QQ318, instead, the processing circuitry QQ302 includes radio front-end circuitry and is connected to the antenna QQ310. Similarly, in some embodiments, all or some of the RF transceiver circuitry QQ312 is part of the communication interface QQ306. In still other embodiments, the communication interface QQ306 includes one or more ports or terminals QQ316, the radio front-end circuitry QQ318, and the RF transceiver circuitry QQ312, as part of a radio unit (not shown), and the communication interface QQ306 communicates with the baseband processing circuitry QQ314, which is part of a digital unit (not shown).

[0265] The antenna QQ310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna QQ310 may be coupled to the radio front-end circuitry QQ318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna QQ310 is separate from the network node QQ300 and connectable to the network node QQ300 through an interface or port.

[0266] The antenna QQ310, communication interface QQ306, and / or the processing circuitry QQ302 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna QQ310, the communication interface QQ306, and / or the processing circuitry QQ302 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0267] The power source QQ308 provides power to the various components of network node QQ300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source QQ308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node QQ300 with power for performing the functionality described herein. For example, the network node QQ300 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source QQ308. As a further example, the power source QQ308 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0268] Embodiments of the network node QQ300 may include additional components beyond those shown in Figure 16 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node QQ300 may include user interface equipment to allow input of information into the network node QQ300 and to allow output of information from the network node QQ300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node QQ300.

[0269] Figure 17 is a block diagram of a host QQ400, which may be an embodiment of the host QQ116 of Figure 14, in accordance with various aspects described herein. As used herein, the host QQ400 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host QQ400 may provide one or more services to one or more UEs.

[0270] The host QQ400 includes processing circuitry QQ402 that is operatively coupled via a bus QQ404 to an input / output interface QQ406, a network interface QQ408, a power source QQ410, and a memory QQ412. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures QQ2 and QQ3, such that the descriptions thereof are generally applicable to the corresponding components of host QQ400.

[0271] The memory QQ412 may include one or more computer programs including one or more host application programs QQ414 and data QQ416, which may include user data, e.g., data generated by a UE for the host QQ400 or data generated by the host QQ400 for a UE. Embodiments of the host QQ400 may utilize only a subset or all of the components shown. The host application programs QQ414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAG, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs QQ414 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host QQ400 may select and / or indicate a different host for over-the-top services for a UE. The host application programs QQ414 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0272] Figure 18 is a block diagram illustrating a virtualization environment QQ500 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments QQ500 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment QQ500 includes components defined by the O-RAN Alliance, such as an O- Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface.

[0273] Applications QQ502 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0274] Hardware QQ504 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers QQ506 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs QQ508a and QQ508b (one or more of which may be generally referred to as VMs QQ508), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer QQ506 may present a virtual operating platform that appears like networking hardware to the VMs QQ508.

[0275] The VMs QQ508 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer QQ506. Different embodiments of the instance of a virtual appliance QQ502 may be implemented on one or more of VMs QQ508, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0276] In the context of NFV, a VM QQ508 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs QQ508, and that part of hardware QQ504 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs QQ508 on top of the hardware QQ504 and corresponds to the application QQ502.

[0277] Hardware QQ504 may be implemented in a standalone network node with generic or specific components. Hardware QQ504 may implement some functions via virtualization. Alternatively, hardware QQ504 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration QQ510, which, among others, oversees lifecycle management of applications QQ502. In some embodiments, hardware QQ504 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system QQ512 which may alternatively be used for communication between hardware nodes and radio units.

[0278] Figure 19 shows a communication diagram of a host QQ602 communicating via a network node QQ604 with a UE QQ606 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE QQ112a of Figure 14 and / or UE QQ200 of Figure 15), network node (such as network node QQ110a of Figure 14 and / or network node QQ300 of Figure 16), and host (such as host QQ116 of Figure 14 and / or host QQ400 of Figure 17) discussed in the preceding paragraphs will now be described with reference to Figure 19.

[0279] Like host QQ400, embodiments of host QQ602 include hardware, such as a communication interface, processing circuitry, and memory. The host QQ602 also includes software, which is stored in or accessible by the host QQ602 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE QQ606 connecting via an over-the-top (OTT) connection QQ650 extending between the UE QQ606 and host QQ602. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection QQ650.

[0280] The network node QQ604 includes hardware enabling it to communicate with the host QQ602 and UE QQ606. The connection QQ660 may be direct or pass through a core network (like core network QQ106 of Figure 14) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

[0281] The UE QQ606 includes hardware and software, which is stored in or accessible by UE QQ606 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE QQ606 with the support of the host QQ602. In the host QQ602, an executing host application may communicate with the executing client application via the OTT connection QQ650 terminating at the UE QQ606 and host QQ602. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection QQ650 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection QQ650.

[0282] The OTT connection QQ650 may extend via a connection QQ660 between the host QQ602 and the network node QQ604 and via a wireless connection QQ670 between the network node QQ604 and the UE QQ606 to provide the connection between the host QQ602 and the UE QQ606. The connection QQ660 and wireless connection QQ670, over which the OTT connection QQ650 may be provided, have been drawn abstractly to illustrate the communication between the host QQ602 and the UE QQ606 via the network node QQ604, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

[0283] As an example of transmitting data via the OTT connection QQ650, in step QQ608, the host QQ602 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE QQ606. In other embodiments, the user data is associated with a UE QQ606 that shares data with the host QQ602 without explicit human interaction. In step QQ610, the host QQ602 initiates a transmission carrying the user data towards the UE QQ606. The host QQ602 may initiate the transmission responsive to a request transmitted by the UE QQ606. The request may be caused by human interaction with the UE QQ606 or by operation of the client application executing on the UE QQ606. The transmission may pass via the network node QQ604, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step QQ612, the network node QQ604 transmits to the UE QQ606 the user data that was carried in the transmission that the host QQ602 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step QQ614, the UE QQ606 receives the user data carried in the transmission, which may be performed by a client application executed on the UE QQ606 associated with the host application executed by the host QQ602.

[0284] In some examples, the UE QQ606 executes a client application which provides user data to the host QQ602. The user data may be provided in reaction or response to the data received from the host QQ602. Accordingly, in step QQ616, the UE QQ606 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input / output interface of the UE QQ606. Regardless of the specific manner in which the user data was provided, the UE QQ606 initiates, in step QQ618, transmission of the user data towards the host QQ602 via the network node QQ604. In step QQ620, in accordance with the teachings of the embodiments described throughout this disclosure, the network node QQ604 receives user data from the UE QQ606 and initiates transmission of the received user data towards the host QQ602. In step QQ622, the host QQ602 receives the user data carried in the transmission initiated by the UE QQ606.

[0285] One or more of the various embodiments improve the performance of OTT services provided to the UE QQ606 using the OTT connection QQ650, in which the wireless connection QQ670 forms the last segment. More precisely, the teachings of these embodiments may improve the latency and thereby provide benefits such as reduced user waiting time.

[0286] In an example scenario, factory status information may be collected and analyzed by the host QQ602. As another example, the host QQ602 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host QQ602 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host QQ602 may store surveillance video uploaded by a UE. As another example, the host QQ602 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host QQ602 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and / or transmitting data.

[0287] In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection QQ650 between the host QQ602 and UE QQ606, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host QQ602 and / or UE QQ606. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection QQ650 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection QQ650 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node QQ604. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host QQ602. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection QQ650 while monitoring propagation times, errors, etc. Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0288] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0289] When using the word "comprise" or “comprising” it shall be interpreted as nonlimiting, i.e. meaning "consist at least of". The embodiments herein are not limited to the preferred embodiments described above. Various alternatives, modifications and equivalents may be used.

Claims

CLAIMS1. A method performed by a proxy node (130) for handling a data connection for a data packet stream between a client (120, 121 , 141) and a server (140, 142), via the proxy node (130) in a communications network (100), which proxy node (130) comprises a cluster of proxy instances (131, 132, 133), the method comprising: distributing (302) data packets of the data packet stream, among one or more of the proxy instances (131 , 132, 133) in the cluster of proxy instances, which data packets are received from the client (120, 121, 141) and / or the server (140, 142), for one or more of the proxy instances (131, 132, 133) in the cluster that comprises a respective data packet of the distributed data packets:- obtaining (303) from a database (190) that is shared between the proxy instances (131 , 132, 133) in the cluster, a protocol context related to the client (120, 121 , 141) and / or the server (140, 142), based on a connection identifier comprised in the respective data packet, identifying said data connection,- processing (304) one or more out of: the respective data packet received from the client (120, 121 , 141) and / or the server (140, 142) and the obtained (203) protocol context related to the client (120, 121 , 141) and / or the server (140, 142),- updating (305) said protocol context based on information related to the respective data packet, and the processed respective data packet and / or the obtained (303) protocol context,- storing (307) said updated protocol context in the shared database (190), the method further comprising:- identifying (308) that a proxy instance (131), comprising at least one distributed data packet, of the cluster of proxy instances (131, 132, 133) fails:- obtaining (309) among the updated protocol contexts in the shared database (190), the protocol context of the failed proxy instance (131) and- replacing (310) the failed proxy instance (131) with another proxy instance (132) from the cluster of proxy instances (131 , 132, 133), enabling the data connection to be kept for the data packet stream between the client (120, 121 , 141) and the server (140, 142) via the replaced proxy instance (132) comprised in the proxy node (130).

2. The method according to claim 1 , further comprising:for one or more of the proxy instances (131, 132, 133) in the cluster that comprises a respective data packet of the distributed data packets, encrypting (306) the updated protocol context with an encryption key, which encryption key is shared among the proxy instances (131, 132, 133).

3. The method according to any of the claims 1-2, wherein the protocol contexts related to the client (120, 121 , 141) and / or the server (140, 142) correspond to a transport layer protocol for the data connection between the client (120, 121 , 141) and the server (140, 142).

4. The method according to any of the claims 1-3, wherein the transport layer protocol is represented by any one out of: QIIIC protocol, Transmission Control Protocol, TCP, Transport Layer Security, TLS, Stream Control Transmission Protocol, SCTP, Low Latency, Low Loss, and Scalable Throughput, L4S.

5. A computer program (1330) comprising instructions, which when executed by a processor (1310), causes the processor (1310) to perform actions according to any of the claims 1-4.

6. A carrier (1340) comprising the computer program (1330) of claim 5, wherein the carrier (1340) is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

7. A proxy node (130) configured to handle a data connection for_a data packet stream between a client (120, 121 , 141) and a server (140, 142), via the proxy node (130) in a communications network (100), which proxy node (130) is adapted to comprise a cluster of proxy instances (131, 132, 133), wherein the proxy node (130) is further configured to: distribute data packets of the data packet stream, among one or more of the proxy instances (131, 132, 133) in the cluster of proxy instances, which data packets are received from the client (120, 121, 141) and / or the server (140, 142), for one or more of the proxy instances (131, 132, 133) in the cluster that comprises a respective data packet of the distributed data packets:- obtain from a database (190) that is shared between the proxy instances (131, 132, 133) in the cluster, a protocol context related to the client (120, 121, 141) and / or the server (140, 142), based on a connection identifier comprised in the respective data packet, identifying said data connection,- process one or more out of: the respective data packet received from the client (120, 121, 141) and / or the server (140, 142) and the obtained protocol context related to the client (120, 121 , 141) and / or the server (140, 142),- update said protocol context based on information related to the respective data packet, and the processed respective data packet and / or the obtained protocol context,- store said updated protocol context in the shared database (190); and wherein the proxy node (130) is further configured to:- identify that a proxy instance (131), comprising at least one distributed data packet, of the cluster of proxy instances (131 , 132, 133), fails:- obtain among the updated protocol contexts in the shared database (190), the protocol context of the failed proxy instance (131) and- replace the failed proxy instance (131) with another proxy instance (132) from the cluster of proxy instances (131, 132, 133), enabling the data connection to be kept for the data packet stream between the client (120, 121 , 141) and the server (140, 142) via the replaced proxy instance (132) comprised in the proxy node (130).

8. The proxy node (130) according to claim 7, further being configured to: for one or more of the proxy instances (131, 132, 133) in the cluster that comprises a respective data packet of the distributed data packets, encrypt the updated protocol context with an encryption key, which encryption key is adapted to be shared among the proxy instances (131 , 132, 133).

9. The proxy node (130) according to any of the claims 7-8, wherein the protocol contexts related to the client (120, 121 , 141) and / or the server (140, 142) correspond to a transport layer protocol for the data connection between the client (120, 121 , 141) and the server (140, 142).

10. The proxy node (130) according to any of the claims 7-9, wherein the transport layer protocol is adapted to be represented by any one out of: QIIIC protocol, Transmission Control Protocol, TCP, Transport Layer Security, TLS, StreamControl Transmission Protocol, SCTP, Low Latency, Low Loss, and Scalable Throughput, L4S.

Images