Data retrieval over multiple access networks

Abstract

Various aspects of the present disclosure relate to a UE comprising: a first communications interface for communication via a first access network; a second communications interface for communication via a second access network; at least one processor coupled with a memory and configured to cause the UE to: transmit HTTP requests via the first communications interface, wherein each HTTP request transmitted via the first communications interface requests a respective first data chunk of a content stored on a communication network; transmit HTTP requests via the second communications interface, wherein each HTTP request transmitted via the second communications interface requests a respective second data chunk of the content; estimate a throughput of each of the first and second access network; and dynamically adjust a size of the data chunks requested in the HTTP requests transmitted via at least one of the first and second communications interface, based on the throughput.

Description

DATA RETRIEVAL OVER MULTIPLE ACCESS NETWORKSTECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to retrieving content over multiple access networks.BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may support wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).

[0003] In the context of 5G and beyond, multiaccess communication has become a concept enabling devices to simultaneously leverage multiple network networks for data transmission. To facilitate this, the 3rd generation partnership project (3 GPP) has specified a feature called Access Traffic Steering, Switching, and Splitting (ATSSS) that enables devices to conduct multiaccess communication by managing and optimizing traffic distribution across 3GPP and non-3GPP access networks. With the move towards 6G, these multiaccess capabilities are expected to evolve further.SUMMARY

[0004] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,”“one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be constmed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0005] Embodiments of the present disclosure relate to the field of data communication and network optimization, specifically to methods and systems for optimizing HTTP content retrieval over multiple access networks. Embodiments of the present disclosure involve dynamic bandwidth utilization and load balancing across heterogeneous network interfaces. The methods described herein are particularly relevant to multiaccess communication in advanced network architectures, such as 5G and beyond, where efficient data transmission and minimal retrieval latency are critical. The methods described herein leverage the HTTP protocol's capabilities to enhance content delivery performance without requiring extensive modifications to existing network infrastructure.

[0006] Some implementations of the method and apparatuses described herein may include a user equipment (UE) for wireless communication, comprising: a first communications interface for communication with a communications network via a first access network; a second communications interface for communication with the communication network via a second access network; at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to:transmit HTTP requests via the first communications interface during a content retrieval process, wherein each HTTP request transmitted via the first communications interface requests a respective first data chunk of a content stored on the communication network; transmit HTTP requests via the second communications interface during the content retrieval process, wherein each HTTP request transmitted via the second communications interface requests a respective second data chunk of the content; estimate a throughput of each of the first access network and the second access network; and dynamically adjust a size of the data chunks requested in the HTTP requests transmitted via at least one of the first communications interface and the second communications interface, based on the throughput of each of the first access network and the second access network.

[0007] In some implementations of the method and apparatuses described herein, upon receiving a first data chunk via the first communications interface in response to transmission of a HTTP request via the first communications interface, the at least one processor is configured to cause the UE to: determine a size of a first data chunk to be requested in a subsequent HTTP request via the first communications interface, wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the size of the first data chunk to be requested in the subsequent HTTP request is a predetermined size; and wherein if more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the size of the first data chunk to be requested in the subsequent HTTP request is determined based on the throughput of each of the first access network and the second access network.

[0008] If more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the at least one processor may be configured to determine the size of the first data chunk to be requested in the subsequent HTTP request to synchronize reception of the firstdata chunk via the first communications interface, with reception of a second data chunk via the second communications interface.

[0009] If more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the at least one processor may be configured to determine the size of the first data chunk to be requested in the subsequent HTTP request based on one or more of: the predetermined size; a minimum size of a data chunk; a time when a first data chunk was last received via the first communications interface; and a time when a second data chunk was last received via the second communications interface.

[0010] In some implementations of the method and apparatuses described herein, upon receiving a second data chunk via the second communications interface in response to transmission of a HTTP request via the second communications interface, the at least one processor is configured to cause the UE to: determine a size of a second data chunk to be requested in a subsequent HTTP request via the second communications interface, wherein if more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is a predetermined size; and wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is determined based on the throughput of each of the first access network and the second access network.

[0011] If more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the at least one processor may be configured to determine the size of the second data chunk to be requested in the subsequent HTTP request to synchronize reception of the second data chunk via the second communications interface, with reception of a first data chunk via the first communications interface.

[0012] If more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrievalprocess, the at least one processor is configured to determine the size of the second data chunk to be requested in the subsequent HTTP request based on one or more of: the predetermined size; a minimum size of a data chunk; a time when a second data chunk was last received via the second communications interface; and a time when a first data chunk was last received via the first communications interface.

[0013] The at least one processor may be configured to commence the content retrieval process in response to receiving a HTTP request from an application running on the UE, wherein the HTTP request identifies the content stored on the communication network.

[0014] In some implementations of the method and apparatuses described herein, each HTTP request transmitted via the first communications interface and second communications interface includes a byte range.

[0015] In some implementations of the method and apparatuses described herein, the first data chunks of the content requested via the first communications interface are nonoverlapping, the second data chunks of the content requested via the second communications interface are non-overlapping, and the first data chunks are different to the second data chunks.

[0016] In some implementations of the method and apparatuses described herein, at the start of the content retrieval process the at least one processor is configured to transmit an initial HTTP request via the first communications interface, and transmit an initial HTTP request via the second communications interface, wherein the initial HTTP requests request equally sized data chunks.

[0017] The first access network may be a non-3GPP access network, and the second access network may be a 3 GPP access network.

[0018] The HTTP requests transmitted via at least one of the first communications interface and the second communications interface may be encrypted.

[0019] The HTTP requests transmitted via at least one of the first communications interface and the second communications interface may be unencrypted.

[0020] Some implementations of the method and apparatuses described herein may include a processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: output HTTP requests for transmission via a first communications interface of a user equipment (UE) during a content retrieval process, the first communications interface for communication with a communications network via a first access network, and each HTTP request for transmission via the first communications interface requests a respective first data chunk of a content stored on the communication network; output HTTP requests for transmission via a second communications interface of the UE during the content retrieval process, the second communications interface for communication with the communication network via a second access network, and each HTTP request for transmission via the second communications interface requests a respective second data chunks of the content; estimate a throughput of each of the first access network and the second access network; and dynamically adjust a size of the data chunks requested in the HTTP requests for transmission via at least one of the first communications interface and the second communications interface, based on the throughput of each of the first access network and the second access network.

[0021] In some implementations of the method and apparatuses described herein, upon obtaining a data chunk via the first communications interface, the at least one controller is configured to cause the processor to: determine a size of a first data chunk to be requested in a subsequent HTTP request via the first communications interface, wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the size of the first data chunk to be requested in the subsequent HTTP request is a predetermined size; and wherein if more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the size of the first data chunk to be requested in the subsequent HTTP request isdetermined based on the throughput of each of the first access network and the second access network.

[0022] In some implementations of the method and apparatuses described herein, upon obtaining a second data chunk via the second communications interface, the at least one controller is configured to cause the processor to: determine a size of a second data chunk to be requested in a subsequent HTTP request via the second communications interface, wherein if more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is a predetermined size; and wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is determined based on the throughput of each of the first access network and the second access network.

[0023] Some implementations of the method and apparatuses described herein may include a method performed by a user equipment (UE), the method comprising: transmitting HTTP requests via a first communications interface of the UE during a content retrieval process, the first communications interface for communication with a communications network via a first access network, and each HTTP request transmitted via the first communications interface requests a respective first data chunk of a content stored on the communication network; transmitting HTTP requests via a second communications interface of the UE during the content retrieval process, the second communications interface for communication with the communication network via a second access network, and each HTTP request transmitted via the second communications interface requests a respective second data chunk of the content; estimating a throughput of each of the first access network and the second access network; and dynamically adjusting a size of the data chunks requested in the HTTP requests transmitted via at least one of the first communications interface and the secondcommunications interface, based on the throughput of each of the first access network and the second access network.

[0024] In some implementations of the method and apparatuses described herein, upon receiving a data chunk via the first communications interface in response to transmission of a HTTP request via the first communications interface, the method comprising: determining a size of a first data chunk to be requested in a subsequent HTTP request via the first communications interface, wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the size of the first data chunk to be requested in the subsequent HTTP request is a predetermined size; and wherein if more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the size of the first data chunk to be requested in the subsequent HTTP request is determined based on the throughput of each of the first access network and the second access network.

[0025] In some implementations of the method and apparatuses described herein, upon receiving a data chunk via the second communications interface in response to transmission of a HTTP request via the second communications interface, the method comprising: determining a size of a second data chunk to be requested in a subsequent HTTP request via the second communications interface, wherein if more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is a predetermined size; and wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is determined based on the throughput of each of the first access network and the second access network.BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 illustrates an architecture for supporting multiaccess communication.

[0027] Figure 2 illustrates a further architecture for supporting multiaccess communication.

[0028] Figure 3 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.

[0029] Figure 4 illustrates an architecture for supporting multiaccess communication in accordance with aspects of the present disclosure.

[0030] Figure 5 illustrates example chunk size adjustment during a content retrieval process in accordance with aspects of the present disclosure.

[0031] Figure 6 illustrates simulations results of a chunk retrieval algorithm, and shows the content retrieval delay over two communication interfaces of a UE under varying throughput conditions.

[0032] Figure 7 illustrates simulations results of a chunk retrieval algorithm and shows the average chunk size retrieved by each communications interface across different throughput ratios.

[0033] Figure 8 illustrates an example network architecture in accordance with some aspects of the present disclosure, used to evaluate the performance of the chunk retrieval algorithm.

[0034] Figure 9 illustrates the content retrieval delay versus the chunk number for both a Wi-Fi interface and an LTE interface observed using the example network architecture shown in Figure 8.

[0035] Figure 10 illustrates the delay of individual chunks retrieved over the Wi-Fi interface and LTE interface observed using the example network architecture shown in Figure 8.

[0036] Figure 11 illustrates the measured throughput on the WiFi interface and the LTE interface that was observed using the example network architecture shown in Figure 8.

[0037] Figure 12 illustrates an example of a user equipment (UE) 1200 in accordance with aspects of the present disclosure.

[0038] Figure 13 illustrates an example of a processor 1300 in accordance with aspects of the present disclosure.

[0039] Figure 14 illustrate a flowchart of method performed by a UE in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0040] Figures 1 & 2 illustrate different architectures for supporting multiaccess communication. The architecture shown in Figure 1 is defined in the 3 GPP specifications in the context of ATSSS and is a comprehensive solution that enables the UE and User Plane Function (UPF) in the core network to exchange IP and Ethernet traffic via a 3 GPP access network (e.g., NG-RAN) and a non-3GPP access network (e.g., Wi-Fi). It requires a Multiaccess Steering Functionality (MSF) to operate in the UE and UPF, which applies a multiaccess transport protocol, such as MPTCP or MPQUIC. It performs policy-based scheduling of data traffic across various access networks (paths) by applying policy information created by the Policy Control Function (PCF). The architecture shown in Figure 1 requires the 5G network to support a Non-3GPP Interworking Function (N3IWF) for providing 5G access via non-3GPP networks, as well as a lot of enhancements in the 5G network functions, including the provision of an Access and Mobility Management Function (AMF), a Session Management Function (SMF), PCF, and UPF, etc.

[0041] The architecture shown in Figure 2 is a simplified version of ATSSS that reduces complexity by eliminating the need for a N3IWF. However, it still relies on an MSF within the UE and UPF to distribute and aggregate IP / Ethernet traffic across 3 GPP and non-3GPP access networks. While the architecture shown in Figure 2 is less complex than the architecture shown in Figure 1, it still requires substantial network modifications, and it features several limitations, e.g., it can transport signaling traffic only over path #2 (3GPP access network) and, should this path become unavailable, the control of the multiaccess connection becomes infeasible. In addition, some security concern arise, as the UE can contact the UPF directly over path #1.

[0042] The methods described herein are different from existing multiaccess solutions, such as those defined by 3GPP's Access Traffic Steering, Switching, and Splitting (ATSSS)feature (which relies on multi-path transport protocols like MPTCP and MPQUIC). The data chunk retrieval algorithm described herein is a novel approach for selecting the size of data chunks requested via different access networks. This algorithm aims to optimize content retrieval by dynamically adjusting chunk sizes to minimize retrieval latency and maximize throughput.

[0043] Unlike conventional methods that require multiaccess functionality within the UPF and complex network modifications, methods described herein operate entirely at the Hypertext Transfer Protocol (HTTP) layer. In particular, the methods described herein use the HTTP protocol's native byte-range request capability, which is widely supported by HTTP servers and clients, thereby simplifying deployment.

[0044] The data chunk retrieval algorithm described herein dynamically adjusts the size of data chunks requested over each access network based on real-time throughput measurements. This ensures optimal utilization of available bandwidth and minimizes content retrieval latency. The data chunk retrieval algorithm designates one network interface of the UE as the 'Leader' and the other as the 'Follower', dynamically synchronizing chunk retrieval to balance the load and maximize efficiency.

[0045] Aspects of the present disclosure are described in the context of a wireless communications system.

[0046] Figure 3 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE -Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G- Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologiesbeyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.

[0047] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN), a NodeB, an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.

[0048] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN). In some implementations, different geographic coverage areas associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0049] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of- Things (loT) device, an Internet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0050] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communicationdirectly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link 114 may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0051] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, N2, or network interface). In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).

[0052] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW), a Packet Data Network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0053] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).

[0054] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures). The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0055] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., / r=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., / r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., / r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., / r=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., / r=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., / r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0056] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframemay have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0057] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., / r=0, jU=l, / r=2, jU=3, / r=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., / i =0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0058] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In someimplementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0059] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., / r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., / r=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., / r=3), which includes 120 kHz subcarrier spacing.

[0060] Figure 4 illustrates an example network architecture 200 in accordance with some aspects of the present disclosure. In some implementations, the network architecture 200 may implement or be implemented by aspects of the wireless communications system 100 described herein with reference to Figure 3. For example, the network architecture 200 may include a UE 104, which may be an example of a UE 104 as described herein with reference to Figure 3. The network architecture 200 may include a RAN 102, which may be an example of a NE 102 as described herein with reference to Figure 3. The network architecture 200 may include a CN 106, which may be an example of a CN 106 as described herein with reference to Figure 3. Whilst Figure 4 shows the CN 106 as a 5G core, this is merely an example.

[0061] Embodiments of the present disclosure may utilize the architecture shown in Figure 4 which, compared with the architectures shown in Figures 1 and 2, provides a further simplified architecture that eliminates the need for both the N3IWF and the MSF within the UPF. It is designed specifically for HTTP / HTTPS traffic and, therefore, cannot support Ethernet or IP traffic other than HTTP / HTTPS. In many scenarios, however, this is sufficient since the majority of IP applications exchange data via the HTTP / HTTPS protocol. The architecture shown in Figure 4 does not require a multiaccess transport protocol, such as MPTCP or MPQUIC, because it operates on the HTTP layer and relies on the capability of the HTTP protocol to retrieve data in byte ranges (chunks).

[0062] The UE 104 comprises a communications interface for communication with a communications network 110 via a non-3GPP access network 108. Data transmissions via the non-3GPP access network may not be in accordance with any specifications defined by 3 GPP. The non-3GPP access network 108 may for example be a wireless local-area network (WLAN) e.g., a WiFi (public or home) network, or a satellite network, or a fixed broadband network. In certain embodiments, a non-3 GPP access network 108 may be controlled by an operator of the CN 106 and may have direct access to the CN 106. Such a non-3GPP access network deployment is referred to as a “trusted non -3 GPP access network”. A non-3GPP access network 108 is considered as “trusted” when it is operated by the 3GPP operator, or a trusted partner, and supports certain security features, such as strong airinterface encryption. In contrast, in other embodiments (as shown in Figure 4) a non-3GPP access network may not be controlled by an operator (or trusted partner) of the CN 106, does not have direct access to the CN 106, or does not support the certain security features, and such a non-3GPP access network is referred to as a “untrusted” non-3GPP access network.

[0063] The UE 104 also comprises a communications interface for communication with a communications network 110 via a 3 GPP access network (shown as RAN 102 in Figure 4) and a CN 106. Data transmissions via the 3 GPP access network 102 are in accordance with one or more specifications defined by 3 GPP. The 3 GPP access network 102 may be a NG- RAN network.

[0064] In embodiments of the present disclosure, a Multiaccess HTTP Functionality (MHF) 105 operates in the UE 104, which transmits HTTP range requests on both access networks, each HTTP range request requesting a HTTP server 112 in the communications network 110 to send only a portion of a piece of HTTP content back to the UE 104. Range requests are widely supported today by HTTP servers and are used by clients like media players and download managers when they need only part of a large file. HTTP Range requests can also be applied to support content retrieval via multiple access networks, as described further herein. The communications network 110 (e.g. the internet, private date network or other data network) is coupled to the CN 106 and comprises the HTTP server 112 on which content is stored. The HTTP server 112 supports HTTP range requests. The content stored by the HTTP server 112 may comprise text, audio and / or video data etc.

[0065] The architecture shown in Figure 4 utilized by embodiments of the present disclosure significantly reduces the complexity of network modifications and leverages the capabilities of the UE 104 to manage multiaccess traffic. Embodiments of the present disclosure utilizes the architecture shown in Figure 4 for HTTP content retrieval over multiple access networks by leveraging the HTTP protocol's byte-range capabilities.

[0066] Advantageously, the methods described herein do not require a MSF or a N3IWF, reducing the complexity of implementation. The simplified architecture of Figure 4 (compared with the architectures shown in Figures 1 and 2) employed by the present disclosure supports HTTP traffic specifically, which is sufficient for most IP applications.

[0067] In embodiments of the present disclosure, the MHF 105 applies a dynamic loadbalancing policy for HTTP requests, meaning that it attempts to retrieve requested content (hosted by the HTTP server 112) by optimally utilizing the available bandwidth of the access networks (i.e., the 3 GPP access network 102 and the non -3 GPP access network 108) and, thereby, minimizing the retrieval latency. To achieve this, the MHF 105 retrieves the requested content in a sequence of data chunks. Some data chunks are requested over the 3GPP access network 102 and others are requested over the non-3GPP access network 108. The MHF 105 implements a data chunk retrieval algorithm to dynamically manage the requested size of each data chunk based on the throughput of each access network. The larger the throughput, the larger the requested chunk size and vice versa. The operation of the data chunk retrieval algorithm is described in more detail below with reference to Figure 5.

[0068] The HTTP requests referred to herein may be encrypted, e.g., in accordance with the Hypertext Transfer Protocol Secure (HTTPS) protocol. The HTTP requests may be encrypted using the SSL / TLS protocol for security protection.

[0069] Alternatively, the HTTP requests referred to herein may be unencrypted. In this case, the SSL / TLS protocols are not applied for encrypting the HTTP requests.

[0070] Figure 5 illustrates example chunk size adjustment during a content retrieval process using the chunk retrieval algorithm implemented by the MHF 105.

[0071] The chunk retrieval algorithm optimizes the retrieval of HTTP content over multiple access networks with varying throughputs. The chunk retrieval algorithmdynamically adjusts the size of data chunks requested over each access network to maximize throughput and minimize retrieval time. It aims to leverage the capacities of multiple access networks by dynamically adjusting the size of the data chunks each access network retrieves based on their respective throughputs. The chunk retrieval algorithm designates one access network (or communications interface) as the ‘Leader’ and the other access network (or communications interface) as the ‘Follower’, allowing the follower to synchronize its chunk retrieval with the leader to ensure efficient and balanced data transfer.

[0072] Figure 5 illustrates data chunks that are received via a communications interface N and a communications interface M of the UE 104. One of the communications interfaces N,M is for communication via a 3 GPP access network 102 and the other of the communications interfaces N,M is for communication via the non-3GPP access network 108.

[0073] In one example, the communications interface N corresponds to the communications interface for communication via the non-3GPP access network 108, and the communications interface M corresponds to the communications interface for communication via the 3GPP access network 102.

[0074] The communications interface N may also be referred to herein as a first communications interface, and any data chunks received via the communications interface N may be referred to herein as a first data chunk. The communications interface M may also be referred to herein as a second communications interface, and any data chunks received via the communications interface M may be referred to herein as a second data chunk.

[0075] Figure 5 illustrates the size and retrieval time of a plurality of first data chunks received via the communications interface N during the example content retrieval process. The plurality of first data chunks are labelled 1 -9 which denotes the order in which the first data chunks are received at the communications interface N. The plurality of first data chunks are non-overlapping i.e. they correspond to different byte ranges of the requested content. Figure 5 further illustrates the size and retrieval time of a plurality of second data chunks received via the communications interface M during the example content retrieval process. The plurality of second data chunks are labelled 1 -4 which denotes the order in which the second data chunks are received at the communications interface M. The plurality of second data chunks are non-overlapping i.e. they correspond to different byte ranges of the requestedcontent. It will be appreciated that the specific values for the sizes of the data chunks and retrieval times are merely examples to illustrate the concept.

[0076] As shown in Figure 5, at the start of the content retrieval process (tO), the chunk retrieval algorithm requests the retrieval of two equally sized chunks (e.g., 1MB) via the two communications interfaces, designated as ‘interface N’ and ‘interface M’. In this example, chunk 1 received via communications interface N is retrieved in 1.3143 s, while chunk 1 via communications interface M is retrieved in 2.5603s. The first data chunks of the content requested via the communications interface N are different to the second data chunks requested via the communications interface M. That is, chunk 1 received via communications interface N is different to chunk 1 received via communications interface M i.e., chunk 1 received via communications interface N corresponds to a different byte range of the requested content than chunk 1 received via communications interface M.

[0077] At the end of each chunk retrieval instance tx (tl, t2, ... ), the chunk retrieval algorithm identifies the leader interface, i.e., the communications interface that has received the most data chunks during the content retrieval process (since tO), and the follower interface, i.e., the communications interface that has received the least data chunks during the content retrieval process (since tO), which is typically the slower interface.

[0078] A chunk retrieval instance corresponds to a time at which a data chunk is retrieved at either the communications interface N or communications interface M.

[0079] Upon receiving a first data chunk via the communications interface N (e.g. data chunk 1 received at tl) the chunk retrieval algorithm determines a size of a first data chunk to be requested in a subsequent HTTP request via the communications interface N. If more data chunks have been received via the communications interface N than have been received via the communications interface M during the content retrieval process (i. e. communications interface N is the leader and communications interface M is the follower), the size of the first data chunk to be requested in the subsequent HTTP request is a predetermined size (e.g. 1MB). If more data chunks have been received via the communications interface M than have been received via the communications interface N during the content retrieval process (i.e. communications interface M is the leader and communications interface N is the follower), the size of the first data chunk to be requested in the subsequent HTTP request is determinedbased on the throughput of each of the 3GPP access network 102 and the non-3GPP access network 108.

[0080] If more data chunks have been received via the communications interface M than have been received via the communications interface N during the content retrieval process, the size of the first data chunk to be requested in the subsequent HTTP request is determined so as to synchronize reception of the first data chunk via the communications interface N, with reception of a second data chunk via the communications interface M (i.e. to reduce the time between reception of a first data chunk via the communications interface N and reception of a second data chunk via the communications interface M).

[0081] Upon receiving a second data chunk via the communications interface M (e.g. data chunk 1 received at t7) the chunk retrieval algorithm determines a size of a second data chunk to be requested in a subsequent HTTP request via the communications interface M. If more data chunks have been received via the communications interface M than have been received via the communications interface N during the content retrieval process (i.e. communications interface M is the leader and communications interface N is the follower), the size of the second data chunk to be requested in the subsequent HTTP request is a predetermined size (e.g. 1MB). If more data chunks have been received via the communications interface N than have been received via the communications interface M during the content retrieval process (i.e. communications interface N is the leader and communications interface M is the follower), the size of the second data chunk to be requested in the subsequent HTTP request is determined based on the throughput of each of the 3GPP access network 102 and the non-3GPP access network 108.

[0082] If more data chunks have been received via the communications interface N than have been received via the communications interface M during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is determined so as to synchronize reception of the second data chunk via the communications interface M, with reception of a first data chunk via the communications interface N (i.e. to reduce the time between reception of a first data chunk via the communications interface N and reception of a second data chunk via the communications interface M).

[0083] In the example shown in Figure 5, the leader interface at every retrieval instance tx is the communications interface N. Therefore, the chunk retrieval algorithm requests data chunks on this interface with the predetermined size, e.g., 1MB. On the contrary, communications interface M is the follower interface, and the chunk retrieval algorithm assigns smaller and smaller chunk sizes to be requested in HTTP requests transmitted using this interface (68KB, 12KB, 8KB) in an attempt to synchronize the chunk retrieval times on both communications interfaces. This synchronization allows data retrieval on both communications interfaces to run in sync, avoiding one communications interface to run ahead or behind the other interface, thereby minimizing content retrieval latency.

[0084] The core mechanism of the chunk retrieval algorithm involves dynamically adjusting the requested chunk sizes based on the retrieval performance of each communications interface. At every chunk retrieval instance tx on a communications interface X (where communications interface X corresponds to communications interface M or communications interface N), the chunk retrieval algorithm selects the size of the next chunk as follows: if the communications interface X is a leader at retrieval instance tx, the next chunk size (to be requested in a HTTP request transmitted using the communications interface X) is equal to the predetermined size, e.g., 1MB; and if the communications interface X is a follower at retrieval instance tx, the next chunk size (to be requested in a HTTP request transmitted using the communications interface X) is calculated based on the throughput of each of the 3GPP access network 102 and the non-3GPP access network 108.

[0085] The MHF 105 is configured to dynamically estimate the throughput of the 3 GPP access network 102 and the non-3GPP access network 108. The MHF 105 is configured to estimate the throughput by dividing the data chunk size by the time take to retrieve the data chunk (i.e. throughput = data chunk size / time take to retrieve the data chunk). Taking the example of Figure 5, at retrieval instance t7, when determining the data chunk size for the 2nd data chunk to be requested over the communications interface M, the chunk retrieval algorithm uses an estimated throughput of the non-3GPP access network 108 (e.g. a throughput of 1MB / 0.2606s estimated at retrieval instance t6), and an estimated throughput of the 3GPP access network 102 (e.g. a throughput of 1MB / 2.5603s estimated at retrieval instance t7). The throughput estimation performed by the MHF 105 for a particularcommunications interface may be based on only the “last” chunk received via the communications interface (i.e. the most recently received data chunk). Alternatively, throughput estimation performed by theMHF 105 for a particular communications interface may be based on averaging the throughput over the last “n” data chunks received via the communications interface, to smooth out any variations in throughput (whereby n is a predetermined number).

[0086] If the communications interface X is a follower at retrieval instance tx, the next chunk size may be calculated as follows:

[0087] chunk size = max(min_chunk_size, min(norm_chunk_size x 2, int(Tf x (tr~tx) + norm chunk size x (Tf / Tl)))) where: min chunk size is the minimum size of a data chunk, norm chunk size is the predetermined size of a data chunk,Tf is the measured throughput of the follower interface,T1 is the measured throughput of the leader interface, tx is the time when the last chunk was retrieved on the follower interface, tr is the time when the last chunk was retrieved on the leader interface.

[0088] The size of a data chunk may range from a minimum value (referred to as min chunk size in the above formula) e.g., 1KB to a maximum value which may be 2 times the predetermined size, e.g., 2MB. Setting an upper bound (defined by the maximum value) to the chunk size avoids difficulties in achieving synchronization between the two interfaces which may arise due to large chunk sizes.

[0089] The rationale behind the above formula is to select a chunk size on the follower interface so that the retrieval of this chunk finishes approximately when the next chunk on the leader interface finishes too. This enables data retrieval in both interfaces to run in sync and thereby minimize content retrieval latency. It will be appreciated that the formula provided above is merely an example and other formula may be used. Generally, if thecommunications interface X is a follower at retrieval instance tx, the next chunk size may be calculated using one or more of: (i) the minimum size of a data chunk (min chunk size), the predetermined size of a data chunk (norm chunk size), the measured throughput of the follower interface (Tf), the measured throughput of the leader interface (Tl), the time when the last chunk was retrieved on the follower interface (tx), and the time when the last chunk was retrieved on the leader interface (tr).

[0090] Figure 6 illustrates simulations results of the chunk retrieval algorithm. In the simulation, the throughput of communications interface N was fixed at 8 Mbps, while the throughput of communications interface M was varied from 8 Mbps to 0.8 Mbps. Consequently, the ratio of the throughput of communications interface M to the throughput of communications interface N varied between 1 and 0.1. The predetermined chunk size was set to 1 MB, the maximum chunk size was set to 2 MB and the minimum chunk size was set to 1 KB. During the simulation, a 1GB file was retrieved by using the MHF 105 and the chunk retrieval algorithm for chunk size management.

[0091] Figure 6 illustrates the content retrieval delay over both interfaces under varying throughput conditions. The vertical bars represent the time each interface was active with chunk retrieval, while the line 602 indicates the minimum achievable delay, which is the delay when the HTTP content is retrieved using a single interface with a throughput equal to the combined throughput of both interfaces. For each throughput ratio, the left side vertical bar represents the time that communications interface N was active with chunk retrieval, and the right side vertical bar represents the time that communications interface M was active with chunk retrieval.

[0092] It can be seen that, during the HTTP content retrieval, both interfaces are active for the same amount of time. For example, when the throughput of interface M is half the throughput of interface M (at point 0.5), the interface N was active retrieving chunks for 683s, while the interface M was active retrieving chunks for 682s. It can also be seen that, importantly, the content retrieval delay is very close to the minimum delay 602, thus, its performance is near optimal. As can be seen in Figure 6, this is true for all ratio of throughputs; from 1 where both interfaces have the same throughput, to 0.1 where interface M is 10 times slower than interface N. This indicates that the chunk retrieval algorithmeffectively utilizes the available bandwidth of both interfaces, achieving near-optimal performance.

[0093] Figure 7 shows the average chunk size retrieved by each communications interface across different throughput ratios during the simulation. The vertical bars represent the average chunk size for interface N and the average chunk size for interface M. For each throughput ratio, the left side vertical bar represents the average chunk size for the communications interface N, and the right side vertical bar represents the average chunk size for the communications interface M. When the throughput of interface M is equal to interface N (ratio = 1), both interfaces retrieve chunks of approximately 1 MB, as initially set. However, as the throughput of interface M decreases, the average chunk size for interface M also decreases. This is a direct consequence of the chunk retrieval algorithm's adjustment mechanism, which reduces the chunk size for the slower interface (interface M) to synchronize its retrieval times with the faster interface (interface N). Interface N, designated as the leader, consistently retrieves larger chunks (up to the maximum size of 2 MB) even as the throughput of interface M decreases.

[0094] Figure 8 illustrates an example network architecture 800 in accordance with some aspects of the present disclosure, used to evaluate the performance of the chunk retrieval algorithm in a real-world scenario.

[0095] In the example network architecture 800 the MHF 105 is implemented within the UE 104 as a transparent HTTP proxy. The UE 104 hosts the MHF 105, which is responsible for receiving HTTP requests from UE applications, determining the optimal chunk sizes, and managing the retrieval of these chunks over two communications interfaces: communication interface N 804 which connects with a WLAN (Wi-Fi) access network, and communication interface M 806 which connects with an LIE access network. The cellular network shown in Figure 4 comprises a 4G RAN 102 and a 4G CN 106. A UE application may for example be a web browser, audio streaming application, video streaming application etc. In the example network architecture 800 the MHF 105 operates as a transparent HTTP proxy such that HTTP requests transmitted from a UE application (i.e. a HTTP client 802) are routed to the MHF 105, with such routing being invisible to the UE application 802. In particular, the networking layer in the UE 104 may be configured (with ‘iptables’) to perform DNAT, i.e., to identifyTCP packets with destination port 80 and to change their destination IP address and destination port to 127.0.0.1 :8001. This causes these TCP packets to be delivered locally to the MHF, which listens on port 8001. In response to receiving a HTTP request (which identifies content stored on the HTTP server 112 in the communications network 110) the MHF 105 is configured to perform the chunk retrieval algorithm described herein.

[0096] In other embodiments, a UE application may comprise the MHF 105 functionality. It will be appreciated that in these embodiments, reception of a HTTP request by the MHF 105 does not trigger the commencement of the chunk retrieval algorithm described herein.

[0097] The HTTP server 112 at the Fully Qualified Domain Name (FQDN) ‘releases.ubuntu.com’ hosts the content to be retrieved and supports HTTP range requests, allowing partial content retrieval based on byte ranges specified by the MHF 105.

[0098] In the experimental network architecture 800 shown in Figure 8, the throughput of the LTE interface (communications interface M) was much smaller than the throughput of the WLAN interface (communications interface N). For this reason, the chunk retrieval algorithm requested much smaller chunks over the LTE access network in order to keep chunk retrieval on both communications interfaces synchronized.

[0099] Figure 9 illustrates the content retrieval delay versus the chunk number for both the Wi-Fi interface (represented by the vertical bars 902) and LTE interface (represented by line 904) observed using the experimental network architecture 800 shown in Figure 8. Figure 9 shows the time each communications interface was busy retrieving chunks in relation to the chunk number, providing insights into the synchronization and efficiency of the retrieval process.

[0100] It can be seen from Figure 9 that the retrieval times for both interfaces are closely aligned, indicating effective synchronization. The delay for Wi-Fi to retrieve X chunks is almost the same as the delay for LTE to retrieve X chunks. This demonstrates that the chunk retrieval algorithm effectively balances the load between the two interfaces, ensuring that neither interface is significantly lagging or leading.

[0101] It can also be seen from Figure 9 that the LTE interface, being the follower, adjusts its chunk size dynamically, sometimes retrieving multiple smaller chunks in quick succession to stay synchronized with the Wi-Fi interface. This indicates an effective load balance between the two interfaces based on their measured throughput values. The close alignment of the retrieval delays for both interfaces supports the effectiveness of the chunk retrieval algorithm in real- world scenarios. By continuously adapting to the performance of each interface, the chunk retrieval algorithm ensures optimal use of available bandwidth and balanced workload distribution.

[0102] Figure 10 illustrates the delay of individual chunks retrieved over the Wi-Fi interface (line 1002) and LTE interface (line 1004) observed using the experimental network architecture 800 shown in Figure 8. Figure 10 provides a granular view of the chunk retrieval process, highlighting the performance consistency and variability of each communications interface.

[0103] Most of the time, the chunk retrieval delay for both Wi-Fi and LTE is around 0.2 seconds. This indicates a stable performance for both interfaces under typical network conditions. However, occasional sharp increases in chunk retrieval delay are observed, which could be attributed to temporary congestion on the Wi-Fi access path or to delays in the HTTP server 112 providing the requested chunks. Despite these occasional spikes, the chunk retrieval algorithm continues to synchronize the chunk retrieval times between the two interfaces.

[0104] It can again be seen from Figure 10 that the chunk delays for Wi-Fi and LTE are often very close to each other, demonstrating the effectiveness of the chunk retrieval algorithm in maintaining synchronization. Even when one interface experiences a delay spike, the other interface's delay mirrors it, maintaining balance. Hence, even in non-ideal network conditions, the chunk retrieval algorithm ensures efficient use of available bandwidth and minimizes retrieval latency.

[0105] Figure 11 illustrates the measured throughput on the Wi-Fi interface (line 1102) and the LTE interface (line 1104), with throughput measured after each chunk retrieval, that was observed using the experimental network architecture 800 shown in Figure 8. It is evident that the throughput for the Wi-Fi interface remains relatively stable and high,typically around 5MB / sec or 40Mbps. There are occasional dips in the throughput, but these are minor and quickly recovered, indicating a generally consistent and reliable performance. The stability of the Wi-Fi throughput demonstrates its role as the leader interface, consistently retrieving large chunks at a relatively steady rate.

[0106] In contrast, the LTE interface exhibits significant variability in throughput. The throughput for LTE frequently drops to very low values, even below 10,000 bytes per second, and then spikes back up to higher values. These fluctuations suggest that the LTE interface, acting as the follower, experiences more variability in network conditions, potentially due to the small signal strength. Despite these fluctuations, the LTE interface manages to retrieve chunks by dynamically adjusting the chunk size, as guided by the chunk retrieval algorithm.

[0107] It can be seen that the sharp declines in LTE throughput often correspond to increases in Wi-Fi throughput stability, indicating that the chunk retrieval algorithm effectively balances the load by adjusting chunk sizes and retrieval timing to maintain overall synchronization. The chunk retrieval algorithm's adaptability ensures that even when LTE throughput drops, the Wi-Fi interface can continue to retrieve data efficiently, minimizing the overall impact on content retrieval time.

[0108] Figure 11 also shows that the chunk retrieval algorithm can recover from throughput drops on the LTE interface, with the throughput eventually spiking back up. This recovery indicates that the chunk retrieval algorithm can adapt to temporary network issues and continue to optimize data retrieval across both interfaces.

[0109] Overall, Figure 11 highlights that the chunk retrieval algorithm is effective in operating under variable network conditions, ensuring efficient utilization of available bandwidth, and maintaining synchronization between the Wi-Fi and LTE interfaces. The dynamic adjustment of chunk sizes allows the chunk retrieval algorithm to cope with fluctuations in throughput, demonstrating its robustness and adaptability in real-world scenarios.

[0110] Through simulations and real-world experiments, the chunk retrieval algorithm has demonstrated its effectiveness in achieving near-optimal content retrieval times and efficient bandwidth utilization. The method effectively handles varying network conditions,maintaining synchronization between different network interfaces and ensuring balanced workload distribution.

[0111] It will be appreciated that whilst the UE 104 shown in Figure 8 comprises a communication interface N which connects with a WLAN (Wi-Fi) access network, and communication interface M which connects with an LTE access network, embodiments of the present disclosure are not limited to these types of access networks.

[0112] Figure 12 illustrates an example of a UE 1200 in accordance with aspects of the present disclosure. The UE 1200 may correspond to the UE 104 described above. The UE 1200 may include a processor 1202, a memory 1204, a controller 1206, and a transceiver 1208. The processor 1202, the memory 1204, the controller 1206, or the transceiver 1208, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0113] The processor 1202, the memory 1204, the controller 1206, or the transceiver 1208, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0114] The processor 1202 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 1202 may be configured to operate the memory 1204. In some other implementations, the memory 1204 may be integrated into the processor 1202. The processor 1202 may be configured to execute computer-readable instructions stored in the memory 1204 to cause the UE 1200 to perform various functions of the present disclosure.

[0115] The memory 1204 may include volatile or non-volatile memory. The memory 1204 may store computer-readable, computer-executable code including instructions when executed by the processor 1202 cause the UE 1200 to perform various functions describedherein. The code may be stored in a non-transitory computer-readable medium such the memory 1204 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or specialpurpose computer.

[0116] In some implementations, the processor 1202 and the memory 1204 coupled with the processor 1202 may be configured to cause the UE 1200 to perform one or more of the functions described herein (e.g., executing, by the processor 1202, instructions stored in the memory 1204). For example, the processor 1202 may support wireless communication at the UE 1200 in accordance with examples as disclosed herein. The processor 1202 may implement the Multiaccess HTTP Functionality (MHF) described herein. The UE 1200 may be configured to support a means for transmitting HTTP requests via a first communications interface of the UE during a content retrieval process, the first communications interface for communication with a communications network via a first access network, and each HTTP request transmitted via the first communications interface requests a respective first data chunk of a content stored on the communication network; transmitting HTTP requests via a second communications interface of the UE during the content retrieval process, the second communications interface for communication with the communication network via a second access network, and each HTTP request transmitted via the second communications interface requests a respective second data chunk of the content; estimating a throughput of each of the first access network and the second access network; and dynamically adjusting a size of the data chunks requested in the HTTP requests transmitted via at least one of the first communications interface and the second communications interface, based on the throughput of each of the first access network and the second access network.

[0117] The controller 1206 may manage input and output signals for the UE 1200. The controller 1206 may also manage peripherals not integrated into the UE 1200. In some implementations, the controller 1206 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 1206 may be implemented as part of the processor 1202.

[0118] In some implementations, the UE 1200 may include at least one transceiver 1208. In some other implementations, the UE 1200 may have more than one transceiver 1208. The transceiver 1208 may represent a wireless transceiver. The transceiver 1208 may include one or more receiver chains 1210, one or more transmitter chains 1212, or a combination thereof.

[0119] A receiver chain 1210 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1210 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 1210 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receiver chain 1210 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 1210 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data. The receiver chain 1210 may receive signals from a communications interface of the UE that is configured for communication with the communications network 110 via the non-3 GPP access network 108. The receiver chain 1210 may receive signals from a communications interface of the UE that is configured for communication with the communications network 110 via the 3 GPP access network 102.

[0120] A transmitter chain 1212 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1212 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 1212 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 1212 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0121] The transmitter chain 1212 may transmit signals from the communications interface of the UE that is configured for communication with the communications network 110 via the non-3 GPP access network 108. The transmitter chain 1212 may transmit signalsfrom a communications interface of the UE that is configured for communication with the communications network 110 via the 3GPP access network 102.

[0122] Figure 13 illustrates an example of a processor 1300 in accordance with aspects of the present disclosure. The processor 1300 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 1300 may include a controller 1302 configured to perform various operations in accordance with examples as described herein. The processor 1300 may optionally include at least one memory 1304, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 1300 may optionally include one or more arithmetic-logic units (ALUs) 1306. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0123] The processor 1300 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 1300) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), and others).

[0124] The controller 1302 may be configured to manage and coordinate various operations (e.g., signaling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 1300 to cause the processor 1300 to support various operations in accordance with examples as described herein. For example, the controller 1302 may operate as a control unit of the processor 1300, generating control signals that manage the operation of various components of the processor 1300. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0125] The controller 1302 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 1304 and determine subsequent instruction(s) to be executed to cause the processor 1300 to support various operations in accordance with examples as described herein. The controller 1302 may be configured to track memory address of instructions associated with the memory 1304. The controller 1302 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 1302 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 1300 to cause the processor 1300 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 1302 may be configured to manage flow of data within the processor 1300. The controller 1302 may be configured to control transfer of data between registers, arithmetic logic units (ALUs), and other functional units of the processor 1300.

[0126] The memory 1304 may include one or more caches (e.g., memory local to or included in the processor 1300 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 1304 may reside within or on a processor chipset (e.g., local to the processor 1300). In some other implementations, the memory 1304 may reside external to the processor chipset (e.g., remote to the processor 1300).

[0127] The memory 1304 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1300, cause the processor 1300 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 1302 and / or the processor 1300 may be configured to execute computer-readable instructions stored in the memory 1304 to cause the processor 1300 to perform various functions. For example, the processor 1300 and / or the controller 1302 may be coupled with or to the memory 1304, the processor 1300, the controller 1302, and the memory 1304 may be configured to perform various functions described herein. In some examples, the processor 1300 may include multiple processors and the memory 1304 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiplememories, which may, individually or collectively, be configured to perform various functions herein.

[0128] The one or more ALUs 1306 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 1306 may reside within or on a processor chipset (e.g., the processor 1300). In some other implementations, the one or more ALUs 1306 may reside external to the processor chipset (e.g., the processor 1300). One or more ALUs 1306 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 1306 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 1306 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 1306 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not- AND (NAND), enabling the one or more ALUs 1306 to handle conditional operations, comparisons, and bitwise operations.

[0129] The processor 1300 may support wireless communication in accordance with examples as disclosed herein. The processor 1300 may implement the Multiaccess HTTP Functionality (MHF) described herein. The processor 1300 may be configured to or operable to support a means for outputting HTTP requests for transmission via a first communications interface of a user equipment (UE) during a content retrieval process, the first communications interface for communication with a communications network via a first access network, and each HTTP request for transmission via the first communications interface requests a respective first data chunk of a content stored on the communication network; outputting HTTP requests for transmission via a second communications interface of the UE during the content retrieval process, the second communications interface for communication with the communication network via a second access network, and each HTTP request for transmission via the second communications interface requests a respective second data chunks of the content; estimating a throughput of each of the first access network and the second access network; and dynamically adjusting a size of the data chunks requested in the HTTP requests for transmission via at least one of the first communications interfaceand the second communications interface, based on the throughput of each of the first access network and the second access network.

[0130] Figure 14 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a UE as described herein. In some implementations, the UE may execute a set of instructions to control the function elements of the UE to perform the described functions.

[0131] At 1402, the method may include transmitting HTTP requests via a first communications interface of the UE during a content retrieval process, the first communications interface for communication with a communications network via a first access network, and each HTTP request transmitted via the first communications interface requests a respective first data chunk of a content stored on the communication network;

[0132] The operations of 1402 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1402 may be performed by a UE as described with reference to Figure 12.

[0133] At 1404, the method may include transmitting HTTP requests via a second communications interface of the UE during the content retrieval process, the second communications interface for communication with the communication network via a second access network, and each HTTP request transmitted via the second communications interface requests a respective second data chunk of the content The operations of 1404 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1404 may be performed by a UE as described with reference to Figure 12.

[0134] At 1406, the method may include estimating a throughput of each of the first access network and the second access network. The operations of 1406 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1406 may be performed a UE as described with reference to Figure 12.

[0135] At 1408, the method may include dynamically adjusting a size of the data chunks requested in the HTTP requests transmitted via at least one of the first communications interface and the second communications interface, based on the throughput of each of thefirst access network and the second access network. The operations of 1408 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1408 may be performed a UE as described with reference to Figure 12.

[0136] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible. Embodiments of the present disclosure are not limited to any particular radio access technology referred to herein.

[0137] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

CLAIMS1. A user equipment (UE) for wireless communication, comprising: a first communications interface for communication with a communications network via a first access network; a second communications interface for communication with the communication network via a second access network; at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: transmit HTTP requests via the first communications interface during a content retrieval process, wherein each HTTP request transmitted via the first communications interface requests a respective first data chunk of a content stored on the communication network; transmit HTTP requests via the second communications interface during the content retrieval process, wherein each HTTP request transmitted via the second communications interface requests a respective second data chunk of the content; estimate a throughput of each of the first access network and the second access network; and dynamically adjust a size of the data chunks requested in the HTTP requests transmitted via at least one of the first communications interface and the second communications interface, based on the throughput of each of the first access network and the second access network.

2. The UE of claim 1, wherein upon receiving a first data chunk via the first communications interface in response to transmission of a HTTP request via the first communications interface, the at least one processor is configured to cause the UE to: determine a size of a first data chunk to be requested in a subsequent HTTP request via the first communications interface, wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the size of the first data chunk to be requestedin the subsequent HTTP request is a predetermined size; and wherein if more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the size of the first data chunk to be requested in the subsequent HTTP request is determined based on the throughput of each of the first access network and the second access network.

3. The UE of claim 2, wherein if more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the at least one processor is configured to determine the size of the first data chunk to be requested in the subsequent HTTP request to synchronize reception of the first data chunk via the first communications interface, with reception of a second data chunk via the second communications interface.

4. The UE of claim 2 or 3, wherein if more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the at least one processor is configured to determine the size of the first data chunk to be requested in the subsequent HTTP request based on one or more of: the predetermined size; a minimum size of a data chunk; a time when a first data chunk was last received via the first communications interface; and a time when a second data chunk was last received via the second communications interface.

5. The UE of any preceding claim, wherein upon receiving a second data chunk via the second communications interface in response to transmission of a HTTP request via the second communications interface, the at least one processor is configured to cause the UE to: determine a size of a second data chunk to be requested in a subsequent HTTP request via the second communications interface, wherein if more data chunks have been received via the second communications interface than have been received via the firstcommunications interface during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is a predetermined size; and wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is determined based on the throughput of each of the first access network and the second access network.

6. The UE of claim 5, wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the at least one processor is configured to determine the size of the second data chunk to be requested in the subsequent HTTP request to synchronize reception of the second data chunk via the second communications interface, with reception of a first data chunk via the first communications interface.

7. The UE of claim 5 or 6, wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the at least one processor is configured to determine the size of the second data chunk to be requested in the subsequent HTTP request based on one or more of: the predetermined size; a minimum size of a data chunk; a time when a second data chunk was last received via the second communications interface; and a time when a first data chunk was last received via the first communications interface.

8. The UE of any preceding claim, wherein the at least one processor is configured to commence the content retrieval process in response to receiving a HTTP request from an application running on the UE, wherein the HTTP request identifies the content stored on the communication network.

9. The UE of any preceding claim, wherein each HTTP request transmitted via the first communications interface and second communications interface includes a byte range.

10. The UE of any preceding claim, wherein the first data chunks of the content requested via the first communications interface are non-overlapping, the second data chunks of the content requested via the second communications interface are non-overlapping, and the first data chunks are different to the second data chunks.

11. The UE of any preceding claim, wherein at the start of the content retrieval process the at least one processor is configured to transmit an initial HTTP request via the first communications interface, and transmit an initial HTTP request via the second communications interface, wherein the initial HTTP requests request equally sized data chunks.

12. The UE of any preceding claim, wherein the first access network is a non-3GPP access network, and the second access network is a 3 GPP access network.

13. The UE of any preceding claim, wherein the HTTP requests transmitted via at least one of the first communications interface and the second communications interface are encrypted.

14. The UE of any of claims 1 to 12, wherein the HTTP requests transmitted via at least one of the first communications interface and the second communications interface are unencrypted.

15. A processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: output HTTP requests for transmission via a first communications interface of a user equipment (UE) during a content retrieval process, the first communications interface for communication with a communications network via a first access network, and each HTTP request for transmission via the first communicationsinterface requests a respective first data chunk of a content stored on the communication network; output HTTP requests for transmission via a second communications interface of the UE during the content retrieval process, the second communications interface for communication with the communication network via a second access network, and each HTTP request for transmission via the second communications interface requests a respective second data chunks of the content; estimate a throughput of each of the first access network and the second access network; and dynamically adjust a size of the data chunks requested in the HTTP requests for transmission via at least one of the first communications interface and the second communications interface, based on the throughput of each of the first access network and the second access network.

16. The processor of claim 15, wherein upon obtaining a data chunk via the first communications interface, the at least one controller is configured to cause the processor to: determine a size of a first data chunk to be requested in a subsequent HTTP request via the first communications interface, wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the size of the first data chunk to be requested in the subsequent HTTP request is a predetermined size; and wherein if more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the size of the first data chunk to be requested in the subsequent HTTP request is determined based on the throughput of each of the first access network and the second access network.

17. The processor of claim 15 or 16, wherein upon obtaining a second data chunk via the second communications interface, the at least one controller is configured to cause the processor to: determine a size of a second data chunk to be requested in a subsequent HTTP request via the second communications interface, wherein if more data chunks have been receivedvia the second communications interface than have been received via the first communications interface during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is a predetermined size; and wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is determined based on the throughput of each of the first access network and the second access network.

18. A method performed by a user equipment (UE), the method comprising: transmitting HTTP requests via a first communications interface of the UE during a content retrieval process, the first communications interface for communication with a communications network via a first access network, and each HTTP request transmitted via the first communications interface requests a respective first data chunk of a content stored on the communication network; transmitting HTTP requests via a second communications interface of the UE during the content retrieval process, the second communications interface for communication with the communication network via a second access network, and each HTTP request transmitted via the second communications interface requests a respective second data chunk of the content; estimating a throughput of each of the first access network and the second access network; and dynamically adjusting a size of the data chunks requested in the HTTP requests transmitted via at least one of the first communications interface and the second communications interface, based on the throughput of each of the first access network and the second access network.

19. The method of claim 18, wherein upon receiving a data chunk via the first communications interface in response to transmission of a HTTP request via the first communications interface, the method comprising: determining a size of a first data chunk to be requested in a subsequent HTTP request via the first communications interface, wherein if more data chunks have been received viathe first communications interface than have been received via the second communications interface during the content retrieval process, the size of the first data chunk to be requested in the subsequent HTTP request is a predetermined size; and wherein if more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the size of the first data chunk to be requested in the subsequent HTTP request is determined based on the throughput of each of the first access network and the second access network.

20. The method of any of claim 18 or 19, wherein upon receiving a data chunk via the second communications interface in response to transmission of a HTTP request via the second communications interface, the method comprising: determining a size of a second data chunk to be requested in a subsequent HTTP request via the second communications interface, wherein if more data chunks have been received via the second communications interface than have been received via the first communications interface during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is a predetermined size; and wherein if more data chunks have been received via the first communications interface than have been received via the second communications interface during the content retrieval process, the size of the second data chunk to be requested in the subsequent HTTP request is determined based on the throughput of each of the first access network and the second access network.

Images