Methods and apparatus for implementing multi-host multi-path secure transport using quic

Abstract

Methods and apparatuses for implementing multi-host multi-path secure transport using a quick user datagram protocol (UDP) connection (QUIC) are described herein. A method performed by a client endpoint can involve sending, to a network node, a request to establish a QUIC connection with a destination endpoint, the request to establish the QUIC connection including a flow identifier (ID). The method can involve receiving, from the network node, a response including an indication of the request to establish the QUIC connection with the destination endpoint. The method can involve encapsulating inner QUIC packetized data within outer QUIC packetized data, the inner QUIC packetized data including the flow ID. The method can involve sending the outer QUIC packetized data to the network node for forwarding to the destination endpoint based on the flow ID.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 976,753, filed on February 14, 2020, the contents of which are incorporated herein by reference. Background Technology

[0003] There are several use cases where protocol design based on data paths can improve data exchange. For example, in some use cases, deep control over multiple network paths may be required through applications and service providers. In some use cases, it may be desirable to maintain connectivity with relocation edge servers. Furthermore, in some use cases, it may be necessary to maintain intermittent device-to-device peer connections. Summary of the Invention

[0004] This document describes methods and apparatus for implementing secure multi-host, multi-path transport using Fast User Datagram Protocol (UDP) connections (QUIC). One method, executed by a client endpoint, may involve sending a request to a network node to establish a QUIC connection with a destination endpoint, the request including a flow identifier (ID). The method may involve receiving a response from the network node including an indication of the request to establish a QUIC connection with the destination endpoint. The method may involve encapsulating internal QUIC packetized data within external QUIC packetized data, the internal QUIC packetized data including the flow ID. The method may involve sending the external QUIC packetized data to the network node for forwarding to the destination endpoint based on the flow ID. Attached Figure Description

[0005] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, wherein similar reference numerals in the drawings indicate similar elements, and wherein:

[0006] Figure 1A This is a system diagram illustrating an exemplary communication system that can be implemented in one or more of the disclosed embodiments;

[0007] Figure 1B This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown;

[0008] Figure 1C This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown;

[0009] Figure 1D This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown;

[0010] Figure 2 This is a diagram illustrating an example of deep control over multiple network paths through applications and service providers;

[0011] Figure 3 This is a diagram illustrating an example of maintaining a connection with a relocation server;

[0012] Figure 4 This is a diagram illustrating an example of maintaining a connection between intermittent device-to-device (D2D) peers;

[0013] Figure 5 This is a diagram illustrating an example of establishing and maintaining a secure multicast or publisher / subscriber (PubSub) connection via QUIC;

[0014] Figure 6 This is a diagram illustrating an example of a master node and communication scenario in a multi-hop multipath (MHMP) system;

[0015] Figure 7 This is a diagram illustrating an example of the initial connection with the agent, depicting the nodes and grouping structure involved;

[0016] Figure 8 This is a diagram illustrating an example of a proxy or indirect connection using QUIC, depicting the nodes and grouping structure involved;

[0017] Figure 9 This is a diagram illustrating an example of a proxy or indirect connection using UDP on both the client-to-proxy segment and the proxy-to-server segment, depicting the nodes and packet structure involved;

[0018] Figure 10 This is a diagram illustrating an example of a direct connection between endpoints, depicting the nodes and grouping structure involved;

[0019] Figure 11 is a diagram of the first part of an example of an indirect connection bootstrapping method using a first alternative to establishing multiple QUIC connections;

[0020] Figure 11 is a diagram of the second part of an example of an indirect connection bootstrapping method that uses a second alternative, a QUIC-over-UDP connection instead of a QUIC-over-UDP connection;

[0021] Figure 12 This is a diagram illustrating an example of the agent discovery process using ADD_ADDRESS;

[0022] Figure 13A This is a diagram illustrating the first part of an example of a server migration process; and

[0023] Figure 13B This is a diagram of the second part, illustrating an example of the server migration process. Detailed Implementation

[0024] Figure 1A This is a schematic diagram illustrating an exemplary communication system 100 that can be implemented in one or more of the disclosed embodiments. Communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0025] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a Station (STA)) may be configured to transmit and / or receive wireless signals and may include User Equipment (UE), mobile stations, fixed or mobile user units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0026] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, Internet 110, and / or other networks 112. As examples, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, evolved Node Bs (eNBs), home Node Bs, home evolved Node Bs, next-generation NodeBs such as gNode Bs (gNBs), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0027] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area, which may be relatively fixed or changeable over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0028] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0029] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

[0030] In one implementation, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0031] In one implementation, base station 114a and WTRUs 102a, 102b, 102c can enable radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0032] In the implementation scheme, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, implement LTE radio access and NR radio access together using the dual connectivity (DC) principle. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0033] In other implementations, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN).

[0034] Figure 1ABase station 114b can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106.

[0035] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104 which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0036] CN 106 may also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

[0037] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 1A The WTRU 102c shown can be configured to communicate with a base station 114a that can employ cellular-based radio technology and with a base station 114b that can employ IEEE 802 radio technology.

[0038] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may include any sub-combination of the foregoing elements.

[0039] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0040] Transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 may be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0041] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0042] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via various RATs (such as NR and IEEE 802.11).

[0043] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 may access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory that is not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in that memory.

[0044] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0045] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0046] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. Sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0047] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)) are performed.

[0048] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an implementation scheme. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0049] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Evolved Nodes B 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In the implementation scheme, evolved Nodes B 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0050] Each of the evolved nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the UL and / or DL, etc. Figure 1C As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0051] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0052] The MME 162 can connect to each of the evolved nodes B 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0053] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-evolved Node B handovers, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0054] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0055] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0056] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0057] In a representative implementation, the other network 112 may be a WLAN.

[0058] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more sites (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0059] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically configured. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative implementations, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (including the AP) can listen to the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

[0060] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0061] The Very High Throughput (VHT) STA supports channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be split into two streams by a segment parser. Each stream can be processed individually using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped to two 80MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to Media Access Control (MAC).

[0062] 802.11af and 802.11ah support operating modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative implementations, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0063] WLAN systems supporting multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS (each supporting a minimum bandwidth operating mode). In the 802.11ah example, for STAs supporting (e.g., only supporting) a 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, the entire available frequency band can be considered busy even if most of the available bands remain idle.

[0064] In the United States, the available frequency bands for 802.11ah are 902MHz to 928MHz. In South Korea, the available frequency bands are 917.5MHz to 923.5MHz. In Japan, the available frequency bands are 916.5MHz to 927.5MHz. The total available bandwidth for 802.11ah ranges from 6MHz to 26MHz, depending on the country code.

[0065] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to the implementation scheme. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 104 can also communicate with CN 106.

[0066] RAN 104 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the implementation scheme. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communication with WTRUs 102a, 102b, and 102c via air interface 116. In the implementation scheme, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In the implementation scheme, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In the implementation scheme, gNBs 180a, 180b, and 180c can implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0067] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0068] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved Node Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate or connect to gNBs 180a, 180b, and 180c, and also communicate or connect to other RANs (such as evolved Node Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more evolved Node Bs 160a, 160b, and 160c. In a non-standalone configuration, evolved Node Bs 160a, 160b, and 160c can be used as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0069] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0070] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0071] AMF 182a and 182b can connect to one or more of gNB 180a, 180b, and 180c via the N2 interface in RAN 104 and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low Latency (URLLC) access, services that rely on Enhanced Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0072] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0073] UPF 184a and 184b can be connected via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 104. The gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

[0074] CN 106 can facilitate communication with other networks. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 106 may provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c may be connected to DNs 185a and 185b via UPFs 184a and 184b through their N3 interfaces and their N6 interfaces with local DNs 185a and 185b.

[0075] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding descriptions herein refer to one or more of the functions described below, or all of the functions described herein, which may be performed by one or more emulation devices (not shown): WTRU102a to 102d, base stations 114a to 114b, evolved Node B 160a to 160c, MME 162, SGW 164, PGW 166, gNB180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other devices described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0076] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, the one or more simulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or use over-the-air wireless communication to perform tests.

[0077] The one or more simulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0078] Fast User Datagram Protocol (UDP) Internet Connection (QUIC) is a currently developing UDP-based stream multiplexing encrypted transport protocol. There are many possible uses of QUIC, such as for substrates, including the use of proxies and similar applications as described herein.

[0079] Multipath protocols can exist at multiple layers, including the physical layer, link layer, and / or transport layer. Specifically, transport layer multipath protocols can include Multipath Transmission Control Protocol (TCP) (MPTCP), Flow Control Transmission Protocol (SCTP), and Multipath QUIC (MP-QUIC).

[0080] In one or more embodiments described herein, a multi-hop (MH) multipath (MP) mechanism (MHMP) may exist at the transport layer. This MHMP mechanism may use QUIC and its multipath extension (MP-QUIC) as the underlying technology because it is a secure transport protocol. The hosts involved at both ends of an MHMP transport connection can be designated as endpoints or peers. Endpoints may also be referred to as end users, client endpoints, destination endpoints, target endpoints, servers or server endpoints, user equipment, WTRU, UE, terminals, hosts or host users, and such terms are used interchangeably throughout the text. A client endpoint may initiate a connection, while the other endpoint may be a server endpoint. Intermediate nodes in an MHMP connection may be referred to as proxy nodes, network nodes, or forwarding nodes. Such terms are used interchangeably throughout the text.

[0081] As referenced throughout, endpoints, agents, nodes, and other systems may be able to establish paths that direct data flows along such paths via hardware or software. In addition to the components and peripherals described above that may be integrated into or operatively connected to a WTRU, NodeB, or STA, endpoints, servers, or any nodes used to implement or deploy agents may include any of the following: processors; field-programmable gate arrays (FPGAs); integrated circuits; memory; random access memory (RAM); non-volatile secondary storage devices; non-transitory storage media such as magnetic, optical, or electronic memory; antennas; antenna arrays; network interface controllers; network interface cards; modems; hubs; switches; or routers.

[0082] The goal of the MHMP transport protocol can be to establish and maintain end-to-end (e2e) MHMP connections between peers. An e2e MHMP connection can consist of one or more individual flows between endpoints, which can be called a path connection, or more simply, a "path". Path connections through a proxy can be "indirect paths", while other paths can be "direct paths". Multipath protocols such as MP-QUIC, MPTCP, and SCTP may only have direct paths between peers, while the MHMP protocol can have both direct and indirect paths.

[0083] The connection between an endpoint and a proxy can be referred to as a "proxy connection" in this article. Two proxies can also be connected to each other, which can also be called a proxy connection.

[0084] In some traditional scenarios, traffic direction between endpoints of a multipath transmission session can be controlled by the network operator through the deployment and configuration of routing devices and protocols within their network. In other scenarios, end users and application providers do not have direct control over traffic direction, except for choosing which local network interfaces (e.g., WiFi or cellular) to use to establish path connections.

[0085] In one or more embodiments disclosed herein, multi-hop multipath protocols may exist at the transport layer, where end users can more directly influence path selection and usage by selecting agents and application providers, and by deploying agents in the network (e.g., as software instances on physical or virtual servers, or as Virtual Network Functions, VNFs). This approach can enable several use cases, as outlined in Table 1, which illustrates at least some examples of use cases and motivations for implementing the disclosed embodiments.

[0086]

[0087]

[0088] Table 1: Use Cases and Motivations

[0089] In some use cases, there may be deep control over multiple network paths through applications and service providers. Cloud application providers (such as Netflix, Google, or Facebook) can exert some control over the multipath aspects of their client connections, enabling path diversity deep within the network. For example, such cloud application providers may instantiate proxy VNFs across multiple data centers, access and conversion networks (assuming such networks provide VNF hosting services). Clients can initially connect to the cloud application server using MHMP-enabled transport protocols. The cloud application server can then achieve path diversity by advertising a list of IP addresses and ports associated with the proxy VNFs that the client can connect to on the client-server connection. Alternatively, the client can be configured to receive, or receive from, a list of IP addresses and ports of the proxy VNFs that the client can use to connect to the service via different channels, thus eliminating the need to provide this information over a direct connection. The client can then establish an e2e connection with the cloud application server through the provided proxy VNF. To establish a proxy e2e connection, the client can communicate the IP address / port information to the proxy and, alternatively, can communicate the target application layer identifier (e.g., username, topic of interest, etc.) to the proxy. From this point onward, clients can connect to the server via multiple MHMP connections, for example, across different internet-autonomous systems, which can be selected by the application provider based on criteria such as high reliability and security. Clients may continue using a direct connection to the cloud application server, or not, depending on the application provider's policy. In this use case, the primary role of the agent can be to achieve path diversity for application control. In some cases, in heterogeneous network contexts, application providers may not have this kind of deep control over multiple network paths.

[0090] This deep control may not be intended to replace existing technologies, such as lower-layer access direction in 3GPP, where traffic flows can be sent over multiple paths between the WTRU and UPF. However, such deep control can complement these technologies by enabling application layer entities (e.g., application providers or users) to specify multiple end-to-end paths for sending traffic, where each of these paths can itself utilize lower-layer multipathing techniques.

[0091] Figure 2This diagram illustrates deep control over multiple network paths through applications and service providers. The network may include end devices or endpoints 210, where client applications can operate and provide MHMP protocol functionality. A first MHMP agent may be provided by data center 220, and a second MHMP agent may be provided at access or conversion network 240. Network server 230 may host service applications and provide MHMP protocol functionality. End devices or endpoints 210 may interface with the first MHMP agent via data center 220 and with the second MHMP agent via access or conversion network 240. The first MHMP agent and / or the second MHMP agent may interface with network server 230 via data center 220 and / or access or conversion network 240. Such interfaces can be implemented via WiFi, cellular, or any other wireless or fixed network. There may be three indirect paths and one direct path. Each of these four paths can be established and encrypted end-to-end between the end device and the server. In alternative use cases, additional agents may be linked to, for example, MHMP agent 1 at data center 220 to route traffic through multiple data centers, access, or conversion networks on more complex paths.

[0092] Some use cases may involve maintaining connectivity with a relocated edge server. In the context of a home or enterprise network, or in a smart city scenario, within a 5G or non-5G network (e.g., WiFi or industrial wireless network), a first edge server connected to an endpoint can be migrated to a second edge server, for example, to maintain low latency with the mobile endpoint or for load balancing. This assumes that a second IP address, different from the first server's IP address, is used on the second edge server to render or create / migrate new application instances for connection purposes. Any state transitions (if any) between the first and second edge servers can be performed using appropriate methods, such as direct or application-layer communication via the client. Assuming a multi-hop multipath transport protocol is initially used between the endpoint and the first edge server, the first edge server can communicate the second edge server's IP address and port to the endpoint via the initial connection. The endpoint can then initiate a connection to the second edge server via the first edge server (e.g., a one-hop connection, using the first edge server as a proxy) and / or via a direct end-to-end connection (e.g., zero-hop connection). A one-hop connection makes it possible to initiate communication with the second server even before a direct connection is possible. At some point, the initial connection to the first server ceases to be used for application data, and a connection to the second server begins to be used, supporting various transition modes such as gradual or immediate. After a period of time, the endpoint can close its indirect path through the first edge server and maintain direct communication only with the second edge server. Throughout this process, the same logical transport connections can be maintained between the endpoint and the application on both the first and second edge servers. Therefore, this relocation process can be transparent to the client application on the endpoint.

[0093] In some cases, maintaining connectivity to an edge server during a real-time application session when the edge server is relocated / migrated requires mechanisms in the network to maintain the server's IP address (e.g., for migrating VMs in a data center) or for application-layer redirection of clients to the new server (e.g., SIP session continuity in an IP Multimedia Subsystem (IMS) in a cellular network). In one approach, mechanisms disclosed herein that do not require maintaining IP addresses and do not require support / awareness at the application layer may exist.

[0094] Figure 3 This is a diagram illustrating an example of maintaining a connection with a relocation server. Figure 3Examples illustrate the use of MHMP in relocation use cases. For instance, connection 1 depicts a connection between a client (represented by element 310) at endpoint 1 and a server (represented by element 320) at endpoint 2. Connection 2 depicts a path for performing server migration between servers at endpoint 2 and endpoint 3 (represented by element 330). Connection 3 depicts a path where endpoint 2 can be used as a proxy to migrate a pre-existing connection, replacing endpoint 2 with endpoint 3. Connection 4 shows a direct path that gradually replaces the indirect path.

[0095] Some use cases may involve maintaining connections between intermittent D2D peers, such as in smart city scenarios. A first WTRU endpoint can connect to a second WTRU endpoint via an intermediate node, which could be an edge server hosting a VNF from an application provider via the MHMP transport protocol. Thus, an instance of the application provider on the agent is aware of this connection and can decide to configure the access network (e.g., a 5G network) to enable the D2D connection between the two endpoints. This D2D connection can therefore be charged to the application provider (e.g., it can recoup this cost through user subscriptions or advertising agreements). When endpoints are within range of D2D communication, devices can establish a D2D link between endpoints. Each endpoint can communicate its new IP address to the intermediate node via the MHMP protocol connection. After learning its peer's new IP address, one endpoint can initiate a new direct path via the D2D connection. From then on, the endpoints can exchange traffic over one or both of the following (e.g., transparent to applications using the connection): the D2D link and through the intermediate node in the network. If the D2D link is lost, communication can still proceed through the intermediate node in the network.

[0096] In some cases, it may be impossible to maintain the same transport connection between intermittent D2D peers. Figure 4 This is a diagram illustrating an exemplary framework for maintaining connections between intermittent D2D peers. Figure 4 As shown, Connection 1 illustrates terminal devices 1 and 2, represented by elements 410 and 420 connected via MHMP agent 430, respectively. Path 2 illustrates MHMP agent 430 requesting D2D communication to be enabled between terminal devices 1 and 2. Connection 3 illustrates establishing a new path between terminal devices 1 and 2 via D2D when they are within reach.

[0097] Some use cases may involve establishing and maintaining secure multicast or publish-subscribe connections between peers. In such use cases, an MHMP agent can act as a rendezvous point for multicast sources and receivers, or for pubsub publishers and subscribers. The agent can facilitate session key sharing and bootstrapping multicast communication between all endpoints. In cases where IP multicast is unavailable, unicast connections between endpoints and the agent can also be used to distribute data streams; this can be accomplished in a scalable manner using multiple agents within a layered, content delivery network (CDN) architecture.

[0098] Figure 5 This is a diagram illustrating an exemplary framework for establishing and maintaining secure multicast or PubSub connections via QUIC. Figure 5 As shown, path 1 illustrates endpoint 1, represented by element 510, which establishes a connection via MHMP agent 540 as a source / publisher to a multicast group / pubsub topic. Paths 2 and 2' illustrate multiple endpoints 2 and 3, represented by elements 520 and 530 respectively, which establish connections as receivers / subscribers to the same multicast group / pubsub topic, thereby receiving their QUIC session keys from MHMP agent 540. Path 3 illustrates endpoint 1 sending traffic on a unidirectional path that can be replicated to all receivers / subscribers (e.g., using the connection established in 1 / 2 / 2'). Path 4 can represent a multicast path between endpoint 1 and endpoints 2 and 3, which can be established to supplement or replace the initial path.

[0099] In some cases, MP transport protocols (e.g., MPTCP or MP-QUIC) may not support the use of one or more explicit hops (e.g., hops visible at the transport layer). Furthermore, MP transport protocols can implement the selection of the network interface used by the endpoint (e.g., by source IP address), but cannot select this path by explicitly using intermediate nodes on the path. This can limit the amount of control application providers and users have over the path. One or more implementations described herein can achieve this control, especially with modern transport protocols. In some cases, modern transport protocol designs using QUIC as a primary example can emphasize strong end-to-end security through encryption, and efficiency and flexibility through multiplexing, for example. Specifically, QUIC goes beyond simply supporting HTTP by supporting multiplexing of streams and datagrams within the same connection. Therefore, it may be necessary to enable the establishment of a single multiplexed and secure end-to-end transport connection (e.g., where the agent may not have access to the encrypted portion of e2e packets) over multiple paths that include explicit hops. Several key issues may need to be addressed to achieve this.

[0100] One issue is the need for a method to enable seamless (e.g., behaving like a normal QUIC connection) proxying of secure end-to-end transport layer QUIC connections without data traffic overhead (e.g., without tunneling), and / or to enable multiplexing of multiple proxy connections, and / or to enable application-specific actions to be performed on the proxy (e.g., D2D setup, application layer ID lookup, multicast critical session sharing, etc.). This issue may not be specific to multipath transport and may also be useful in regular (e.g., non-multipath) QUIC.

[0101] Another issue might be the need for a way to dynamically advertise proxy connections to multipath peers (e.g., in MP-QUIC).

[0102] Another issue might be that one application in a multi-hop, multi-path application needs to support server or client migration without breaking the transport connection. This might require a process that enables this feature while maintaining the same secure transport connection before, during, and after the migration.

[0103] In one or more implementations, since QUIC can be a secure transport protocol, protocol extensions may exist to handle indirect (e.g., proxy) paths, using the existing QUIC protocol and its proposed multipath extensions as a foundation. Similar enhancements can also be derived for other transport protocols such as MPTCP+TLS, SCTP+TLS, Secure SCTP, etc.

[0104] The core element of the method described in this paper is that one or more nodes (referred to herein as agents or MHMP agents) act as intermediaries in QUIC connections. MHMP agents can be deployed on physical or virtual infrastructure by network operators, applications, or service providers. For example, an MHMP agent controller application instance can be deployed on a virtualized infrastructure platform provided by an access network or data center operator. The agent controller application instance typically controls forwarding and encapsulation / decapsulation, operations performed in commercial off-the-shelf (COTS) or dedicated hardware (e.g., physical or virtual network devices). The agent controller application instance can control those operations using programmatic, HTTP-based, or SDN-based APIs (e.g., OpenFlow-based). The agent controller application instance can also perform application-specific operations (e.g., as described regarding the questions above).

[0105] Endpoints (e.g., QUIC endpoints) can also be part of an MHMP system. Endpoints can be WTRUs, UEs, PCs, laptops, IoT devices, etc., or more generally, any device capable of communicating using the QUIC protocol or similar protocols enhanced as described herein. In some scenarios (e.g., the server migration scenario described herein), endpoints can act as MHMP proxies.

[0106] MHMP QUIC operation can be based on the MP-QUIC protocol. The enhancements described herein can be described using QUIC and MP-QUIC as underlying protocols. An MP-QUIC connection between two endpoints consists of one or more paths. An MP-QUIC path can be a unidirectional or bidirectional data flow between the two endpoints. From each endpoint's perspective, the flow can be associated with a 4-tuple of source / destination IP address and transport (e.g., UDP) port (as seen by the endpoint). For example, when Network Address Translation (NAT) is applied to a path, each endpoint can see different 4-tuples for the same path. In MHMP QUIC, the same path definition can be used. In MHMP QUIC, each endpoint can see different 4-tuples for the same indirect path because, for each endpoint, the next hop at the IP and UDP layers is an MHMP proxy. MHMP-QUIC supports multiple simultaneous indirect and direct paths.

[0107] Figure 6 This is a diagram illustrating an example of a communication scenario in an MHMP system. The diagram shows a communication scenario involving an MHMP agent, as defined herein. These main communication scenarios using connections or paths (a), (b), and (c) are described in detail herein. In the scenario that generates path (A), by... Figure 6 Endpoint A, represented by element 630, can initiate communication with MHMP agent P, represented by element 610. This can create a regular QUIC connection or path (a), which is further described in the following paragraphs. Figure 7 The example further illustrates this. Following the process described herein, endpoint A can use connection (a) to send a request to MHMP agent P for an indirect connection toward endpoint B, represented by element 620. This may result in an indirect / agent path connection (b) between A and B, thereby using QUIC on QUIC on the segment between A and P, which in Figure 8This is illustrated (e.g., using the PACKET frame type described herein) and further described in the following paragraphs. This type of path connection can support multiplexing of multiple indirect / proxy connections over the same QUIC AP connection. Endpoint A or MHMP proxy P can trigger a switch to a costless indirect / proxy path connection using a SWITCH frame as described herein. This may result in the same QUIC path connection being forwarded over UDP on each segment (b), as shown below. Figure 9 As shown and further described in the following paragraphs, a direct connection (c) can be established between endpoints A and B, as follows: Figure 10 As shown and further described below, endpoint B can advertise its indirect IP address to A on path (c), as described herein. Endpoint A can then initiate the creation of path (b) as described above. Direct and indirect paths can coexist on the same multipath multihop QUIC connection.

[0108] Additional mechanisms can be implemented, where, for example, path (a) can be used to exchange key session materials, thereby enabling multicast sessions between endpoints. If agent P is also an endpoint, proxy ID information elements can be exchanged on path (b) to enable the migration of application instances from MHMP agent P to endpoint B.

[0109] Figure 7 This diagram illustrates an example of a typical initial connection with a proxy, showing an example of the network nodes and packet structure involved. As shown, endpoint A, represented by element 710, can establish a QUIC (AP) connection with MHMP proxy P, represented by 730. In addition to the QUIC connection, endpoint A can also communicate using a UDP connection (between a UDP port on A and a USDP port on P) and / or an IP connection (between IP addresses A and P). For example, a QUIC connection can be established via UDP and IP.

[0110] Figure 8This diagram illustrates an example of a proxy / indirect connection using QUIC, depicting the network nodes and packet structure involved. Endpoint A, represented by element 810, may have already established an internal QUIC connection (AB) with endpoint B, represented by element 850. The QUIC (AB) connection can be established on an external QUIC (AP) connection between endpoint A and MHMP proxy P, represented by element 830. Encrypted payloads sent via the QUIC (AB) connection can be encapsulated in a PACKET frame, which, as described above, may include a flow ID identifying the flow corresponding to the internal QUIC (AB) connection. The external QUIC (AP) connection can carry encrypted AP payloads to MHMP proxy P, at which point the encapsulated QUIC (AB) payload can be forwarded to endpoint B. Endpoints A and B can be further connected via IP and / or UDP.

[0111] Figure 9 This diagram illustrates another example of a proxy / indirect connection over two segments via UDP, depicting the nodes and packet structure involved. Endpoint A, represented by element 910, may have already established a QUIC connection (AB) with endpoint B, represented by element 950. Additionally, a connection can be provided via UDP between endpoint A and MHMP proxy P, represented by element 930, and between MHMP proxy P and endpoint B. Data sent via the QUIC connection (AB) can be forwarded from endpoint A to MHMP proxy P via a first UDP connection, and again from MHMP proxy P via a second UDP connection. The path between endpoint A and endpoint B can be further provided via IP and / or UDP.

[0112] Figure 10 This diagram illustrates an example of a direct connection between endpoints, depicting the network nodes and packet structure involved. As shown, a direct path connection can be established between endpoint A, represented by element 1010, and endpoint B, represented by element 1020. Endpoints A and B can be connected via Layer 2 protocols, IP, and / or UDP. A QUIC connection (AB) can be established, for example, upon request by endpoint A according to one or more mechanisms further described herein.

[0113] In some cases, MPTCP can support proxying; however, MPTCP proxies can be designed to split TCP connections, typically allowing MPTCP to be used on one side between the proxy and the client, while regular TCP is used between the proxy and the server. Thus, the MPTCP proxy resides on the entire path of traffic between the client and the proxy. This type of connection splitting may not be possible with QUIC, which enforces end-to-end encryption on any given individual path of a multipath connection. Therefore, the type of proxy described herein can differ from the type of proxy used with MPTCP (e.g., it may exist on some paths but not others; mutual authentication may exist between the client and the proxy before the connection is proxied; application instances on the proxy may participate in the proxy connection setup), and thus can rely on different mechanisms described herein and provide different types of services (e.g., implicit path selection, application-specific D2D or lookup, multicast or pubsub communication management).

[0114] HTTP CONNECT can be used as another proxy for connection establishment in certain situations. When using HTTP CONNECT, endpoints can communicate over an end-to-end TLS connection via the proxy using any protocol. The TLS connection can be transmitted over a first TCP session on the client-proxy segment and a second TCP session on the proxy-server segment. Therefore, HTTP CONNECT may not be suitable for carrying UDP-based QUIC traffic. Additionally, using HTTP CONNECT may prevent multiplexing of the proxy connection between the client and the proxy. Therefore, multiple connections communicating with multiple servers via the proxy may be required. Finally, to be able to use HTTP CONNECT, a full HTTP connection may need to be established with the proxy, which may waste resources on both the client and the proxy.

[0115] Table 2 illustrates examples of problems and mechanisms for resolving them. These exemplary mechanisms can enhance the QUIC protocol. In all cases in the table, the QUIC transport parameters can be extended to include relevant parameters such as an indication that this connection can be used to carry QUIC traffic on QUIC, a list of supported protocols for addressing remote endpoints in a proxy NEW_CONNECTION request, and / or an indication of support for GENERATION-based migration mechanisms.

[0116]

[0117] Table 2: Key Issues and Related Mechanisms

[0118] In some implementations, valid connections may exist via a proxy using QUIC or MP-QUIC. For example, a proxy connection method using a QUIC-on-QUIC encapsulation scheme may exist. This can be used for more than one purpose, such as: multiplexing multiple QUIC connections across multiple servers via a single proxy (e.g., on the same client-proxy connection); and / or, when multiplexing is not required (e.g., when a single QUIC connection is proxied), the proxy connection can be switched to directly carry an end-to-end QUIC connection without encapsulation, thus reducing data traffic overhead to zero. In both cases, traffic between the endpoint and the proxy may appear as regular QUIC traffic. Like any other intermediate node on a QUIC connection, a QUIC-on-QUIC proxy may only have visibility of unprotected fields in the QUIC packets, such as the IP header, UDP header, and unencrypted QUIC header (including the connection ID). MHMP proxies can implement application-specific actions.

[0119] There may be QUIC frame types used as building blocks for establishing efficient connections via a broker in a QUIC or MP-QUIC process. In a QUIC-on-QUIC encapsulation scheme, internal QUIC packets can be transmitted over an external QUIC connection (e.g., via a client-broker connection), where a packet is a complete processable unit of QUIC that can be encapsulated in a UDP datagram (e.g., may include one or more QUIC frames). End-to-end QUIC connections can be encapsulated as unidirectional or bidirectional streams of internal QUIC packets: each internal QUIC packet can be transmitted in a PACKET frame, associated with a stream ID, and is internal to the external QUIC connection. A QUIC-on-QUIC stream can be initiated when a client endpoint sends a NEW_CONNECTION frame to the broker; the NEW_CONNECTION frame identifies the new stream, including the ID and other parameters associated with the stream. Using the stream ID, multiplexing of multiple QUIC connections with multiple endpoints can be achieved over a single endpoint-broker connection. If the agent accepts a NEW_CONNECTION request, it can configure itself to forward internal QUIC packets to / from the NEW_CONNECTION destination.

[0120] This document describes a new PACKET frame type for carrying encapsulated data traffic. It may include information elements similar to those of the DATAGRAM frame type. However, the new frame type can be used to distinguish its new and unique purpose as a container for internal QUIC packets. Internal QUIC packets belong to a QUIC connection previously initiated by a NEW_CONNECTION frame. A PACKET frame may include at least the following fields: a stream ID (e.g., a variable-length integer), which identifies a unidirectional or bidirectional stream corresponding to an e2e QUIC connection, where this ID corresponds to the ID used in the NEW_CONNECTION frame that initiated the stream; a length (e.g., a variable-length integer), which is the length of the encapsulated packet stored in the data field; and / or a data field (variable length), which may be an internal QUIC packet (e.g., one or more QUIC frames).

[0121] This document describes a new NEW_CONNECTION frame type to define the destination / target and associated parameters associated with a stream of internal QUIC packets / frames. This frame type may include at least the following fields: Stream ID (e.g., a variable-length integer), which may be an ID identifying a bidirectional stream corresponding to an internal / encapsulated QUIC connection; Destination / Target Protocol (e.g., 16-bit), which may be the protocol used to address the destination endpoint; Destination / Target IP Address (e.g., 128-bit or 32-bit), which may be the IP address of the destination (e.g., endpoint 2), or a multicast IP address also known as a multicast group, used when the destination address protocol is IPv4 or IPv6; Destination / Target Application Identifier (e.g., a variable-length string), which may be an application layer identifier of the destination (e.g., endpoint 2), used when the destination protocol is an application layer protocol (e.g., this may be an application user ID, such as a Netflix or Facebook username, which can be looked up by a proxy to determine the IP address of the destination endpoint, or this may be something the proxy can use for publishing). - A topic ID or string that is part of the subscription scheme; a destination / target type (e.g., 2 bits), which may be a code indicating the type associated with the destination / target IP address or application ID, where the value may include "publish", "subscribe", "bidirectional", and its meaning may depend on the destination / target protocol (e.g., these values ​​identify the sender of the NEW_CONNECTION as a publisher or subscriber for the pubsub protocol, a source or receiver for the multicast protocol, or a regular node capable of sending / receiving on the path); a destination / target port (e.g., 16 bits), which may be a port used to connect to the server (e.g., a UDP port); and / or a proxy authorization field (e.g., a variable-length string), which may be a string describing credentials used to authorize proxy operations (e.g., it may use the same encoding as in the corresponding HTTP field, such as "basic dXNlcjpwYXNzd29yZA=="). Where the same authorization string can be used in multiple NEW_CONNECTION frames, the proxy authorization field may be present in the first NEW_CONNECTION and omitted below.

[0122] The destination / residence protocol can be IPv4, IPv6, or an application layer protocol (e.g., a username in a social networking application). Depending on the destination / residence protocol, any of the destination / residence IP address, port, and application identifier may or may not be present (e.g., IP address and port may be present with IPv4 / IPv6 protocols, and application identifier and type may be present with application layer protocols).

[0123] A PACKET frame associated with a given stream ID can be processed as a separate QUIC stream / flow and thus multiplexed with other streams / flows. Congestion control can be applied to the entire client-proxy QUIC connection.

[0124] Regarding the NEW_CONNECTION / PACKET frame type and related mechanisms, the QUIC stack implementation makes the programming API available to native applications running on the host (e.g., on a proxy). Procedures running on the proxy node can use this API and register a "NEW_CONNECTION received" event, passing a callback as a parameter. The registration scope can be used for all, a group, or a single incoming connection. The callback can receive parameters including NEW_CONNECTION frame information elements (flowID, destProtocol, destIP, destAppId, destType, destPort, ProxyAuth). When the proxy receives a NEW_CONNECTION, it can invoke the registered callback function, providing the parameters extracted from the NEW_CONNECTION frame. The callback function can, for example, use the ProxyAuth parameter to check if the client endpoint is authorized by the local policy and return a code indicating whether the request is accepted or rejected. In some examples, the callback function can look up the destination application identifier passed in NEW_CONNECTION (e.g., using a local or remote application-layer database) to determine if the caller is authorized to connect to it, and to determine the IP address and UDP port of the endpoint to which the proxy will forward internal traffic. In some examples, a local program on the proxy can expose this API as a REST API for external nodes (e.g., an application provider's management plane functionality to control NEW_CONNECTION requests).

[0125] There may be SWITCH frames used for establishing a valid connection via a proxy through a QUIC or MP-QUIC process. Specifically, to remove encapsulation and overhead where possible, the client endpoint (corresponding proxy) can send a new SWITCH frame to the proxy (corresponding client endpoint) to request a switch from exchanging e2e traffic encapsulated over the proxy connection to exchanging e2e traffic directly over UDP.

[0126] The new SWITCH frame type may have one or more of the following fields: a switch type (e.g., a variable-length integer), which may be a code indicating the desired switch type, which in the method described herein could be "QUIC on QUIC to QUIC on UDP," although it may also take other values, such as "QUIC on UDP to QUIC on QUIC," which could reverse the operation described herein, or other values ​​corresponding to switching between different types of encapsulation (GTP, Geneve, etc.). The SWITCH frame type may also include a message type (e.g., bits), which may be a code indicating whether the frame is a request or a response; or a status (e.g., a fixed-length integer), which may be a code indicating success / failure and can be used in the response.

[0127] A requester (e.g., a client endpoint or proxy) can send a packet including a SWITCH frame. A receiver can decide to accept or reject (e.g., a proxy can be configured to always accept or reject those requests based on operator policies) and then send a reply in a QUIC packet including a SWITCH frame. The receiver can stop sending packets on the connection (e.g., a client-proxy connection) after sending a positive response. The requester can stop sending packets on the connection after receiving a positive response. After sending a receive response, and once the receiver receives acknowledgment of the positive response packet, the requester can begin sending unencapsulated end-to-end packets on the UDP connection of the initial connection. SWITCH packets sent on connections with multiple active proxy connections (e.g., multiple flow IDs) may often be rejected because, after a successful switch, the flow ID may no longer be associated with internal QUIC packets. This can make multiplexing impossible without additional complexity (e.g., communicating with the server to ensure connection IDs are allocated within a specific range, similar to existing QUIC load balancing methods).

[0128] SWITCH can be used at any time during the lifecycle of an internal QUIC connection, such as: once the encapsulation protocol is sufficiently encrypted / protected (e.g., once the traffic is at a "1-RTT encryption level"); subsequently, such as during QUIC operations on a normal QUIC connection; and / or as early as a NEW_CONNECTION request. Once the 1-RTT encryption level is reached, using SWITCH allows earlier unprotected and 0-RTT protected packets to be encapsulated and thus encrypted over an external QUIC connection. This way, eavesdroppers between the client and the agent will not see plaintext packets, concealing the fact that a proxy connection is being established. Instead, the SWITCH operation can manifest as a change in the connection ID, which can be common in QUIC protocol operations. Therefore, this makes proxy operations as seamless as possible. The process described in Figure 11 and the following paragraphs illustrates this particular use case. However, SWITCH can also be sent earlier, for example, as described below regarding... Figure 11A and Figure 11B In the described process, steps 1113-1117 can occur between steps 1104 and 1105, in which case the first packet of the end-to-end connection and all subsequent packets can be transmitted via UDP connection to each segment client-agent and agent-server.

[0129] The indirect connection bootstrapping method can be used to establish an effective connection via a proxy through a QUIC or MP-QUIC procedure. This can be a procedure that bootstraps a QUIC connection to a proxy using the new frame type described earlier. This method can be used to establish an indirect path connection as part of an e2eMHMP connection, or it can be used to establish a single QUIC proxy connection.

[0130] Figure 11A and Figure 11B A process diagram illustrating an example of an indirect connection bootstrapping method is shown. Figure 11 illustrates how endpoint 1, represented by element 1150 (e.g., using IP addresses IP1a, IP1b, etc.), connects via proxy 1160 to endpoint 2, represented by 1170 (e.g., using IP addresses IP2a, IP2b, etc.). To distinguish it from other proxies, this proxy may support the PACKET / NEW_CONNECTION frame type and may support the SWITCH frame type, and may be an MHMP proxy, even though it can also be used for non-multipath QUIC.

[0131] about Figure 11A and Figure 11BAs shown in the steps, at step 1101, endpoint 1 can establish a QUIC connection with the proxy. The proxy can authenticate the client (e.g., based on a certificate provided by the client). In some cases, QUIC may only support server authentication for the client, but it can be extended to support client authentication for the server.

[0132] Endpoint 1 can further use this QUIC layer connection to carry HTTP / 3 traffic for login, authentication, and other tasks using common network-based mechanisms such as WebAuthn, HTTP Basic Authentication, JSON Web Tokens, and two-factor authentication. However, this step is not always necessary and may impose some processing overhead on both the endpoint and the proxy.

[0133] During the establishment of the endpoint 1-agent transport connection, transport parameters can be exchanged (e.g., using QUIC transport parameter extensions). The agent and / or endpoint 1 can use transport parameter indications, such as transport parameter IDs, to indicate support for the new fields and related procedures described herein.

[0134] For example, a transport parameter ID (e.g., 0x000f) with proxy operation support may have or include a transport parameter length, such as 0 bits (e.g., null parameter), and this transport parameter may indicate the frame type for which the sender supports the NEW_CONNECTION, PACKET, SWITCH, and associated proxy-related procedures described herein.

[0135] For example, a transport parameter ID (e.g., 0x0010) with a supported proxy protocol can have a transport parameter length, such as a variable-length list of integers, and this transport parameter can list one or more protocols (e.g., IPv4, IPv6, application layer protocols) that are supported for addressing remote endpoints in NEW_CONNECTION frames.

[0136] At 1102, endpoint 1 can send a NEW_CONNECTION frame to the agent, which includes a previously unused stream ID (e.g., 0 in the initial request) and indicates the expected server endpoint IP address (e.g., IP2a or multicast IP address) or destination application identifier (e.g., application-specific username, pubsub topic name), type, port, protocol, and possible authorization token.

[0137] At point 1103, the agent can decide whether to authorize the NEW_CONNECTION request based on given parameters, local policies from the agent operator, and possibly some interactions with backend services in the cloud. When applicable, the agent can perform application-specific actions such as: enabling a D2D connection between endpoint 1 and endpoint 2 to authorize endpoint 1 and endpoint 2 to establish a direct path between them (e.g., the agent can access the 5G network API for this); performing application-layer authentication with the client; and / or performing a lookup of the application identifier provided in NEW_CONNECTION (if the application identifier is used instead of the IP address).

[0138] At 1104, the agent can send a NEW_CONNECTION response (e.g., including a response code indicating that the request is accepted).

[0139] At 1105, client endpoint 1 can use a PACKET frame as described herein, with the flow ID used in NEW_CONNECTION, to send an initial end-to-end packet encapsulated in the initial QUIC connection with the proxy to endpoint 2.

[0140] At 1106, the proxy can decapsulate the packet and send it to server endpoint 2, sometimes via UDP packets (e.g., using the proxy IP address / UDP port as the source IP address / UDP port).

[0141] At 1107, endpoint 2 can send a QUIC response to the initial packet (e.g., following the QUIC connection establishment procedure).

[0142] At 1108, the proxy encapsulates the response from endpoint 2 into the initial endpoint 1-proxy connection in the PACKET frame (e.g., using the same flow ID as in the request).

[0143] At 1109, this endpoint 1-endpoint 2 exchange can continue until an end-to-end connection is established after the end-to-end QUIC connection establishment process, with transmission over both segments. Packets are encapsulated in QUIC on the endpoint 1-proxy segment and sent over UDP on the proxy-endpoint 2 segment. To achieve this, packet forwarding operations can be configured on the MHMP proxy, for example, as an entry in the forwarding table that associates the flow ID used in the PACKET frame with the second segment's UDP session 4-tuple (e.g., MHMP proxy IP address and UDP port, endpoint 2 IP address and UDP port).

[0144] At point 1110, a QUIC connection can be established end-to-end between endpoint 1 and endpoint 2, and data can be transmitted over the two segments mentioned above.

[0145] The exemplary process in Figure 11 can proceed to step 1111 or step 1112 depending on the circumstances.

[0146] At 1111, in the first alternative, client endpoint 1 can send additional NEW_CONNECTION frames using different flow IDs to multiplex multiple proxy connections over the client-proxy QUIC connection. Therefore, the process can loop through steps 1102-1110. The process can end in this alternative.

[0147] Figure 11B The second part of the process diagram is shown, and alternatives to the steps described above with respect to step 1111 are described. For example... Figure 11B As shown, at 1112, in the second alternative, client endpoint 1 may not need to use multiplexing and decides to reduce the overhead of the proxy connection. At this stage, the end-to-end connection can be protected at a 1-RTT (e.g., highest) level (e.g., starting from step 9). Therefore, QUIC on QUIC encapsulation can add unnecessary overhead to the connection (e.g., because multiplexing is not required).

[0148] At 1113, endpoint 1 can send a SWITCH message (e.g., a request where the switch type is "QUIC on QUIC to UDP on QUIC") to trigger an end-to-end internal connection instead of the initial connection (on the same underlying UDP stream). Note that, alternatively, a broker can also be the sender of a SWITCH frame.

[0149] At 1114-1115, the receiver (e.g., an agent) can decide to accept or reject the SWITCH request and send back a response (e.g., with a code indicating that the request is accepted).

[0150] At points 1116-1117, Endpoint 1 and the agent can begin exchanging end-to-end (e.g., Endpoint 1 to Endpoint 2) packets directly via UDP. On the MHMP agent, forwarding operations can be configured, for example, to associate the first 4-tuple (e.g., Endpoint 1 IP address and UDP port, MHMP agent IP address and UDP port) with entries in the forwarding table of the second 4-tuple (e.g., MHMP agent IP address and UDP port, Endpoint 2 IP address and UDP port).

[0151] In step 1118, starting from this point, end-to-end packets on the QUIC path between endpoint 1 and endpoint 2 can be sent through a proxy that can forward end-to-end packets through UDP connections on each segment proxy-endpoint 1 and proxy-endpoint 2.

[0152] Agents can be used in multipath transport protocols to establish efficient connections via agents during QUIC or MP-QUIC processes. MP-QUIC signaling and procedures can be used to establish separate indirect paths as part of a multipath connection. When used in conjunction with the QUIC-on-QUIC mechanism and / or SWITCH-based mechanisms described earlier herein, these procedures enable the establishment of separate paths via agents. Traffic scheduling between paths (e.g., direct and indirect) can be accomplished similarly to regular MP-QUIC scheduling. Alternatively, MHMP-QUIC endpoints can influence scheduling policies using their knowledge of the indirect or direct nature of a path (e.g., known from the novel ADD_ADDRESS frame type field described herein). The reasons for deploying and using agents can vary and may depend on the goals of the application or service provider, and thus may lead to different or even opposite strategies. For example, an MHMP-QUIC client might use indirect paths when available, for example, because it values ​​path diversity regardless of other factors, and keep direct paths inactive as backup paths. In another example, where the MHMP agent is used to establish a backup path on the satellite link, the MHMP-QUIC client can use the direct path when available and keep the indirect path inactive as a backup.

[0153] Furthermore, an MHMP path can traverse more than one agent. This can be hidden from the endpoints: each agent can decide which other agents to use as the next hop and then establish agent connections with other agents. Agents can forward NEW_CONNECTION and SWITCH frames to the next agent and relay the response back. Therefore, those frames can be forwarded all the way to the last agent on the path.

[0154] Multicast and Pubsub communication can be enabled for efficient connections via brokers in the QUIC or MP-QUIC process. The QUIC multicast protocol can obtain session keys using an HTTP Alternate Service (“Alt-Svc”). The MHMP protocol can be leveraged to complement this existing work, providing additional features. For example, it can enable the sharing of session keys at the transport layer, which may be more efficient / dynamic than using HTTP Alt-Svc. In scenarios such as video broadcasting or Pubsub point-to-multipoint message distribution (e.g., MQTT), the MHMP protocol can also enable the use of IP unicast as a supplement to or replacement for IP multicast. Alternatively, using multiple distributed brokers and unicast can be scalable and easily deployed in deployments where multicast is not permitted in the network. Additionally, multicast can be enabled in parts of the network, where it can be used to improve distribution efficiency.

[0155] Multicast and pubsub nodes can connect to the agent and use NEW_CONNECTION frames with the target / destination application ID and target / destination type. Multicast stream sources / receivers can set the destination IP address to the multicast group and the destination type to "Publish" and "Subscribe" respectively. Pubsub publishers / subscribers can set the destination application ID to the topic name and the destination type to "Publish" and "Subscribe" respectively.

[0156] For example, when all multicast / pubsub nodes (e.g., source, receiver, publisher, subscriber) have the role of endpoint 1, it can be used Figure 11A and Figure 11B The process described herein. In this case, Endpoint 2 can be a virtual endpoint, which may be hosted, for example, on the MHMP agent itself. The role of Endpoint 2 may include facilitating key distribution and maintaining / configuring the forwarding of QUIC streams between endpoints. Each multicast group or pubsub topic may require a single instance of Endpoint 2.

[0157] Initially, the source / publisher endpoint can connect to endpoint 2, as described herein. At the end of this process, the source / publisher may be able to stream data to endpoint 2 via QUIC connection "S" (e.g., traffic sent to endpoint 2 may be dropped by the agent if no receiver / subscriber exists). Endpoint 2 / the agent can store the QUIC session key in its internal state, associated with a multicast group or topic name, for future use.

[0158] The receiver / subscriber can also connect to endpoint 2 as described herein until they send a NEW_CONNECTION. If endpoint 2 / agent accepts the request to subscribe to a multicast group or topic name, endpoint 2 / agent can reply with a SESSION_KEY frame, which includes the key material needed to decrypt the QUIC traffic from the source / publisher of this multicast group or topic name. The receiver / subscriber can process this frame and configure its QUIC connection with the agent using the session key material. From this point onward, the receiver / subscriber can decrypt packets sent by the source / publisher on connection "S". Endpoint 2 / agent can configure forwarding rules on the agent to forward copies of all incoming packets on connection "S" to the receiver / subscriber via the existing UDP connection with the receiver / subscriber.

[0159] At this point, a point-to-multipoint connection can exist between the source / publisher endpoint and the receiver / subscriber endpoint via a unicast point-to-point UDP connection between each endpoint and the MHMP agent. Endpoint 2 / agent can receive the stream but does not modify it or send any data about it. Endpoint 2 / agent can communicate with Endpoint 1 via an Endpoint 1-agent connection (e.g., to provide statistics on the number of subscribers / receivers). The source / publisher can advertise the actual multicast IP address (e.g., using ADD_ADDRESS). Upon receiving ADD_ADDRESS, the receiver / subscriber can establish a new path listening on the multicast address. The receiver / subscriber can close or keep the unicast path through the MHMP agent as an unused backup.

[0160] In some implementations, agent discovery can be performed via MP-QUIC. Endpoints can learn about suitable agents through various mechanisms such as DHCP, IPv6 ND and provisioning domains, DNS service discovery, local discovery using mDNS, port control protocols, and / or anycast addresses. However, these methods may be suitable for discovering long-term agents deployed by network operators. For some use cases described in this paper, a more dynamic approach may be needed to discover agents deployed by application providers. Therefore, it is necessary to understand how endpoints can learn about agents that can be used for indirect paths in multipath protocols.

[0161] In this method, an endpoint can learn about available indirect paths from its remote peers through existing paths. An endpoint can use this indirect path immediately, within the same connection, or later in another connection with the next endpoint.

[0162] The enhanced ADD_ADDRESS frame type can be used for agent discovery. Typically, the ADD_ADDRESS frame type can have several fields, such as a “P” bit that can indicate the presence of a port field (if set); an address ID, which can be a unique identifier for the advertised address for tracking and removal purposes, which may be needed when, for example, NAT changes the IP address so that two hosts see different IP addresses for the same path endpoint; an interface type, which can indicate the interface technology type such as fixed (0), WLAN (1), or cellular (2); an IP version, which may be associated with the address in the IP address field; an IP address, which can be the IP address advertised by the sender to the receiver; and / or a UDP port number, which may be associated with the advertised IP address.

[0163] In the enhanced / extended ADD_ADDRESS frame type, there may be several fields, such as: an "I" bit, which, if set, indicates the presence of a proxy-related field; an "A" bit, which, if set, indicates that the proxy can be used for all connections with the sending endpoint, and if not set, indicates that the proxy can be used only for this multipath connection; a proxy IP address, which can be the IPv6 or IPv4 address of the proxy as seen by the receiving endpoint (e.g., the proxy's publicly accessible IP address), and alternatively, the proxy IP address field can be replaced by a proxy name field (e.g., FQDN); a proxy IP version, which can indicate whether the IP version of the proxy IP address field is IPv4 or IPv6; and / or a proxy port, which can be the transport layer (e.g., UDP) port associated with the proxy IP address. These fields may supplement the normal fields and may be necessary to enable the endpoint receiving this frame to initiate indirect path connections through the proxy, as described earlier in this document.

[0164] Using the techniques described in this article, a proxy discovery process using ADD_ADDRESS is possible. Figure 12 This is a process diagram illustrating an example of the agent discovery process using the enhanced ADD_ADDRESS and indirect connection bootstrapping method described herein.

[0165] Regarding Figure 12 As shown in the steps, at 1201, endpoint 1, represented by element 1250, can establish a multipath transport connection with endpoint 2, represented by element 1270, through one or more paths (e.g., using existing MP-QUIC procedures for direct paths and / or the methods described herein for indirect paths). At this point, an MHMP connection consisting of a set of direct or indirect paths may exist between endpoint 1 and endpoint 2.

[0166] At point 1202, application providers can now deploy agent instances dynamically, or they can deploy them earlier. For example... Figure 12 As shown, a proxy is represented by element 1260 and can be an MHMP proxy. The existence of the proxy and the availability of its IP address / port to endpoint 2 can be made possible (e.g., through management plane communication mechanisms, possibly along with policy information regarding the conditions of use of this proxy). For example, a given proxy might be available to all application users located in a specific area or to all application users with a specific plan.

[0167] At point 1203, endpoint 2 (e.g., the server) may know that endpoint 1 (e.g., the client) can be used for this connection or as a proxy for all connections with this server. This information can be configured on the server, provided through a management plane system, or provided using other methods. Endpoint 2 may send packets including ADD_ADDRESS frames, which, in addition to the usual ADD_ADDRESS field, include the proxy IP address, version, and port to be used, where the "I" bit is set to indicate the presence of proxy information, and, where applicable, the "A" bit is set to indicate that the proxy can be used for other connections with the server. Endpoint 2 may send several ADD_ADDRESS frames (e.g., advertising multiple proxies and / or multiple endpoint 2 IP addresses via a proxy).

[0168] At 1204, upon receiving an ADD_ADDRESS frame, endpoint 1 can update the local connection state using the ADD_ADDRESS parameter.

[0169] At point 1205, at some point, such as an immediate or local policy-based decision (e.g., if the current path becomes unreliable), the path manager component on endpoint 1 (e.g., enhanced MP-QUIC) decides to initiate a new path using information from one of the recently received agent-based ADD_ADDRESS frames.

[0170] At 1206, endpoint 1 can initiate an indirect path connection by means of a proxy known from ADD_ADDRESS, as described in Figure 11.

[0171] At point 1207, in addition to all pre-existing paths, the multipath connection between endpoint 1 and endpoint 2 can now include new indirect paths via MHMP proxies.

[0172] In some implementations, server (or client) migration may be enabled. This approach addresses how the MHMP protocol mechanism described herein can be used to facilitate application connectivity continuity during server or client migration. One advantage of this approach is that endpoints do not need to discover the newly migrated remote endpoint via external protocols (e.g., DNS, application layer protocols, etc.); another advantage is maintaining transport sessions, which enables transparent migration.

[0173] When enabling server or client migration, new building blocks may exist, such as new GENERATION, STATE, and enhanced ADD_ADDRESS and PATHS frame types.

[0174] One approach is to associate a "generation ID" with an IP address and then with the address in the ADD_ADDRESS and PATHS messages. A generation can be associated with a side (e.g., a client or a server). For example, even-numbered generation IDs can be associated with clients, and odd-numbered generation IDs can be associated with servers. By default, all client addresses can be associated with generation 0 ("gen0"), and all server addresses can be associated with generation 1 ("gen1"). gen0 and gen1 can be defaulted to the currently active generation. Therefore, all existing messages and behaviors can be used by default, enabling backward compatibility of the generation mechanism. New addresses, for example, associated with different servers, can then be advertised in association with the next available generation 3 ("gen3"). Clients can establish paths to gen3 addresses, but cannot exchange any data on them as long as the active server-side generation remains gen1. A given path can be associated with a path generation ID, which is formed by the client generation ID (e.g., the generation ID of the client address associated with this path) and the server generation ID (e.g., the server-side IP address).

[0175] For example, a path can have a path generation ID of gen0-gen1 by default, and in the event of a server migration, the new path can have path generation IDs of gen0-gen3. A new GENERATION frame can be sent by the current server to the client to indicate the now active path generation ID. Upon receiving the GENERATION frame, the client switches all communication (e.g., from the gen0-gen1 path to the gen0-gen3 path). In some cases, this change can be applied only to new application connections, while it can alternatively be applied to all traffic immediately: the transition mode field of the GENERATION frame determines which behavior should be applied. Before switching generations, the old server can issue a new STATE frame on the existing gen0-gen1 path to request all traffic to pause or become inactive, which can enable, for example, VM migrations between old and new servers. The new server can be made aware that its IP address will be associated with a non-default generation (e.g., using a programming API). For example, an application can listen for incoming connections on two ports: a first port for normal connections from new clients and a second port for connections from clients migrating from another server. A socket listening on the second port can be created using the new socket option, which includes the default alias used by this socket. The server IP address used for the connection via the second port can be associated with gen3 by default. An equivalent mechanism defined in a transport protocol such as QUIC may be required, and frame types such as GENERATION or STATE may need to be defined.

[0176] While server migration (e.g., from gen1 to gen3) can serve as a typical example of the process described in this paper, the same mechanism can be used to support client migration (e.g., from gen0 to gen2), where the roles of client and server are swapped.

[0177] The new GENERATION frame type may have the following fields: server ID (e.g., variable-length integer), which may be the ID used with the new active server (e.g., odd); client ID (e.g., variable-length integer), which may be the ID used with the new active client (e.g., even); conversion mode (e.g., variable-length integer), which may be a code indicating the conversion type, including "new application transactions only" or "all active connections"; and / or a reset flag (e.g., bit), which, if set, can reset all paths and associated addresses to the active ID, and can also be used after the migration is complete (e.g., to reset all server-side IP address IDs to 3 to 1, and all gen0-gen3 paths to gen0-gen1 paths).

[0178] The new STATE frame type may have the following fields: Server connection state (e.g., a variable-length integer), which may be a code (ACTIVE or INACTIVE) indicating the desired connection state on the server side. This can be changed only by the server and / or omitted in STATE frames sent by the client. The STATE frame type may also include client connection state (e.g., a variable-length integer), which may be a code (ACTIVE or INACTIVE) indicating the desired connection state on the client side, and this can be changed only by the client and omitted in STATE frames sent by the server (e.g., two peers may maintain client and server connection states for a given path in their internal states, and both client and server connection states can be ACTIVE for use in data traffic).

[0179] The following fields can be used to enhance the normal ADD_ADDRESS frame type: the G bit (if set) can indicate whether the Proxy ID field exists; and / or the Proxy ID (e.g., a variable-length integer), which can be a Proxy ID associated with an address.

[0180] Furthermore, the PATHS frame type can be enhanced using code ID-related information. In some cases, the PATHS frame may include path descriptions for all sending and receiving paths (e.g., from the perspective of the PATHS frame sender). Each path descriptor may include a path ID, local and remote address IDs. Additionally, for each path descriptor, the PATHS frame type can be enhanced with the following fields: a local code ID (e.g., a variable-length integer), which can be a code ID associated with a local IP address (e.g., from the perspective of the PATHS frame sender); and / or a remote code ID (e.g., a variable-length integer), which can be a code ID associated with a remote IP address (from the perspective of the PATHS frame sender).

[0181] The generation ID can be alternatively encoded within the address ID (e.g., it can be a field already present in the MP-QUIC frame, such as ADD_ADDRESS, and can be used to identify the address to remove the address). For example, since only generations 0, 1, 2, and 3 are needed, and since the address side (client, server) is known, a single bit in the address ID may be sufficient: even the client-side address ID could be gen0, odd-numbered client-side address IDs could be gen2, and even the server-side address ID could be gen1, odd-numbered server-side address IDs could be gen3. However, for illustrative purposes, generation IDs can be used.

[0182] Figure 13A and Figure 13B This is a diagram illustrating an example of a server migration process using one or more of the technologies described in this article. Figure 13A and Figure 13B These can all be considered part of a single process that supports migration from the first server to the second while maintaining the transport connection. As essentially discussed in the paragraphs above, this process can be adapted to handle client migrations similarly.

[0183] A proxy ID identifies an instance running on an endpoint: the same proxy ID can refer to the same instance, while different proxy IDs can refer to different instances. Different instances may not share application or connection state. Therefore, a core aspect of this process is synchronizing the switch from communicating with one instance (e.g., proxy ID 1, the first server) to communicating with another instance (e.g., proxy ID 3, the second server).

[0184] about Figure 13A and Figure 13BThe steps shown, at 13011, initially, endpoint 1 (e.g., a client), represented by element 1350, can use a multipath protocol with MPMH capability (e.g., MP-QUIC enhanced as previously described herein) to establish a transport connection with endpoint 2 (e.g., a server), represented by element 1360. Transport parameters can be added to existing transport parameters sent by one or both endpoints to indicate support for GENERATION-based server migration, and can be used in conjunction with other transport parameters described herein. The transport parameter ID can be generation-based migration support (e.g., 0x0011), and the transport parameter length can be a value such as 0 bits (e.g., a null parameter). This transport parameter can indicate that the sender supports new frame types GENERATION and STATE, enhanced (e.g., for generation ID awareness) frame types ADD_ADDRESS and PATHS, and the relevant migration support procedures described herein.

[0185] At 1302, a transmission connection may exist between endpoint 1 and endpoint 2 via one or more direct or indirect paths.

[0186] At point 1303, server instance migration can be initiated, for example, through the service provider's management plane. Management plane ( Figure 13A (Not shown in the image) can send a signal to endpoint 2 to notify that the migration is about to occur.

[0187] Regarding steps 1304-1306, these steps may occur, for example, in situations where server instance migration requires pausing traffic, such as in a hot VM migration. Endpoint 2 may send a STATE (INACTIVE) frame on the path to endpoint 1. Endpoint 1 may, for example, stop sending data on the path upon receiving a STATE (INACTIVE) frame. Endpoint 2 may, for example, stop sending data on the path before sending a STATE (INACTIVE) frame.

[0188] At 1307, the management plane can select the target server endpoint 3, represented by element 1370, and coordinate server migration. This may include creating a software instance on endpoint 3, and / or migrating VMs or application states between endpoint 2 and endpoint 3. At this point, the migrated instance on endpoint 3 can listen for incoming connections but may not yet be ready to exchange application traffic. The management plane can provide endpoint 2 with the IP address of endpoint 3.

[0189] Regarding 1308-1309, Endpoint 2 can send ADD_ADDRESS frames to the client. Each ADD_ADDRESS frame includes the IP address of Endpoint 3 and, in some cases, other existing fields (e.g., Address ID, Port, Protocol Version, etc.) and a proxy ID value as the next unused proxy ID on this side (e.g., "3" for server migration). Proxy information elements may exist specifying Endpoint 2 as a proxy (e.g., including Endpoint 2's IP address, version, port, where the I bit is set and typically the A bit is not set). However, Endpoint 2 can send ADD_ADDRESS frames for direct (e.g., no proxy), indirect (e.g., with a proxy, such as Endpoint 2), or a mixture of direct and indirect connections. Figure 13A In the example shown, endpoint 2 itself can act as a proxy to send ADD_ADDRESS along with proxy information. This can be useful for establishing communication with endpoint 3 even before direct communication is possible (e.g., during anticipated mobility events). Endpoint 1 may send back an acknowledgment.

[0190] At 1310, endpoint 1 can store added address information (e.g., including proxy information elements, if present) in the internal state of the connection upon receiving data. Then, endpoint 1's path manager can decide which new path connections to establish.

[0191] At 1311, endpoint 1 can establish one or more new paths, or a connection to endpoint 3. In this example, these could be indirect paths established using the methods described herein (e.g., using NEW_CONNECTION, PACKET, and possibly SWITCH frames). Since both endpoint 1 and endpoint 3 may know that these paths are gen0-gen3 paths, these paths may not be used to carry any data traffic.

[0192] At 1312, endpoint 1 may have a gen0-gen1 path connection to endpoint 2 (e.g., which can be used for data traffic unless they are set to inactive in steps 1304-1306) and a gen0-gen3 path connection to endpoint 3, which may not currently be used for data traffic.

[0193] At point 1313, at some point, the entity (e.g., the management plane) signals endpoint 2 when the server migration is complete. Endpoint 3 is now ready to exchange application traffic.

[0194] Regarding 1314-1315, endpoint 2 can send a GENERATION frame to endpoint 1 on one or more paths, including the server ID value "3". The transition mode can be "All active connections" or "New application transactions only". Endpoint 1 sends back an acknowledgment.

[0195] Regarding 1316-1319, endpoint 1 can implement a transformation from using the gen0-gen1 path to using the gen0-gen3 path. Endpoint 1 can use an existing gen0-gen3 path and / or initiate a new gen0-gen3 path. The transformation from gen0-gen1 to gen0-gen3 can be performed in different ways depending on the requested transformation mode, the current state of the gen0-gen1 path (e.g., active or inactive), and the behavior of the application server.

[0196] In the first example, in the case of VM or container migration, all gen0-gen1 path connections may be inactive at this time (e.g., since steps 1304-1306). The conversion mode can be set to "All active connections". Upon receipt, the client (e.g., endpoint 1) can forward GENERATION (e.g., gen0-gen3) frames on one or more gen0-gen3 paths, which can notify endpoint 3 that the gen0-gen3 path is now available for data traffic. Endpoint 1 can send all application traffic through the gen0-gen3 path. In this case, the migration can be completely transparent to both client and server applications.

[0197] In another example, the gen0-gen1 path may currently be active (e.g., steps 1304-1306 are not used). The transformation mode can be set to "new application transactions only". This could be used, for example, when endpoint 3 hosts a stateless application instance that communicates with a backend database server in the data center. Upon receiving a GENERATION (gen0-gen3) frame from endpoint 2, the client can forward it on one or more gen0-gen3 paths. This informs endpoint 3 that the gen0-gen3 path is now available for application traffic. Endpoint 1 can continue using the existing application transaction's gen0-gen1 path and send all new transaction traffic (e.g., all HTTP GET / POST messages) to the gen0-gen3 path. Again, in this case, the application client and server may be unaware of the migration, even though the application server could be designed to handle each request independently (e.g., as a stateless application).

[0198] In another example, the transition mode could also be set to "new application transactions only". Upon receiving a signal that the server migration is complete, the application instance running on endpoint 2 might fail all incomplete application transactions. When a GENERATION (gen0-gen3) frame is received from endpoint 2, the client can forward it on one or more gen0-gen3 paths. This informs endpoint 3 that the gen0-gen3 path is now available for application traffic. The client application on endpoint 1 can retry application requests, and thus can send them to endpoint 3 on the gen0-gen3 path, as these retries can be new application transactions. In this case, the server migration could be made visible to the client application as a set of transaction failures, but this might not require a major redesign of the application and could even be handled with normal application failure handling behavior. The server application might require some support for this situation, such as it must fail all ongoing transactions for a given client upon request (e.g., from a management plane component).

[0199] At 1320, endpoint 1 can have a gen0-gen1 path to endpoint 2, which can be used for ongoing transactions or may be unused. Endpoint 1 can also have a gen0-gen3 path to endpoint 3, which can be used for application traffic.

[0200] At point 1321, assuming the existing gen0-gen3 paths are indirect paths via endpoint 2 / proxy, as shown in the diagram, endpoint 3 can use ADD_ADDRESS to advertise its IP address to endpoint 1 via one or more gen0-gen3 paths. Endpoint 1 can use this information to establish a direct path connection with endpoint 3. Once the direct path is established, endpoints 1 and 3 can stop using the indirect path. Therefore, endpoint 2 may have no indirect path traffic to forward and can remove forwarding entries (e.g., after a timeout period).

[0201] At 1322, once the gen0-gen1 path between endpoint 1 and endpoint 2 is no longer in use (e.g., after an ongoing application transaction has ended, or immediately after the GENERATION message has been received), either endpoint 1 or endpoint 2 can close the gen0-gen1 path.

[0202] At 1323, the original endpoint 1-endpoint 2 connection is now migrated to a single-path or multi-path connection between endpoint 1 and endpoint 3.

[0203] At 1324, in order to perform another migration to another server after the same process, endpoint 1 or endpoint 3 can reset all gen3 addresses to gen1 addresses (e.g., the gen0-gen3 path thus becomes the gen0-gen1 path). This can be done once the only existing path from the perspective of both endpoints is known to be gen0-gen3. For example, endpoint 3, which can terminate only the gen0-gen3 path, can receive enhanced PATHS frames as defined herein from endpoint 1, which only includes the gen0-gen3 path. Endpoint 3 can then send GENERATION (e.g., gen0-gen1, where the reset flag is set) to endpoint 1. Then both endpoint 1 and endpoint 3 can set all gen3 addresses to gen1 in their internal state.

[0204] For seamless proxies with no traffic overhead or multiplexing, and for application-specific actions on the proxy, endpoints can send NEW_CONNECTION frames to the proxy to initiate a QUIC-on-QUIC proxy based on a PACKET frame. Endpoints can send SWITCH frames to replace encapsulated proxy connections with internal QUIC connections, which can be replaced with overhead-free forwarding instead of encapsulation. SESSION_KEY frames can be used to enable point-to-multipoint and multicast. For the advertisement of proxy connections in MP_QUIC, endpoints can send ADD_ADDRESS frame types enhanced with proxy-related information elements. Receiving endpoints can use this information to initiate a path using QUIC-on-QUIC. Where server-side and client-side IP addresses are associated with a proxy ID, the server can inform the client to switch from an old-generation path to a new-generation path using the new frame types GENERATION and STATE, and on the enhanced frame types ADD_ADDRESS and PATHS, as part of the migration process.

[0205] Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile optical discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A client endpoint, the client endpoint comprising: processor; and Transceiver: The processor and the transceiver are configured to send a request to a network node to establish a Fast User Datagram Protocol (UDP) connection (QUIC) to a destination endpoint, the request to establish the QUIC connection including a flow identifier (ID); The transceiver is configured to receive from the network node a response including an indication of the request to establish a QUIC connection with the destination endpoint; The processor and the transceiver are configured to send external QUIC packetized data to the network node, which encapsulates internal QUIC packetized data to be forwarded to the destination endpoint, wherein the internal QUIC packetized data includes information indicating the flow ID; The processor and the transceiver are configured to send a request to the network node to stop encapsulating internal QUIC packetized data within external QUIC packetized data; The transceiver is configured to receive from the network node a response to the request to stop encapsulating internal QUIC packetized data within external QUIC packetized data, wherein the response includes information indicating that the request is accepted; and The processor and the transceiver are configured to send UDP datagrams to the network node, the UDP datagrams including internal QUIC packetized data to be forwarded to the destination endpoint.

2. The client endpoint of claim 1, wherein the processor and the transceiver are configured to send a request to the network node to establish another QUIC connection with another destination endpoint, the request to establish the other QUIC connection including another stream ID.

3. The client endpoint of claim 1, wherein the request to establish the QUIC connection with the destination endpoint is encapsulated in the external QUIC packetized data.

4. The client endpoint according to claim 1, wherein the internal QUIC packetized data and the external QUIC packetized data are encrypted separately.

5. The client endpoint of claim 1, wherein a request to stop encapsulating internal QUIC packetized data within external QUIC packetized data is sent in response to a predefined encryption level being reached with the connection to the destination endpoint.

6. The client endpoint of claim 1, wherein the request to stop encapsulating internal QUIC packetized data is accepted provided that the QUIC connection to the destination endpoint does not carry multiple multiplexed QUIC streams.

7. The client endpoint of claim 1, wherein the network node is a proxy configured to forward the internal QUIC packetized data to the destination endpoint.

8. A method executed by a client endpoint, the method comprising: A request is sent to a network node to establish a Fast User Datagram Protocol (UDP) connection (QUIC) to the destination endpoint, the request to establish the QUIC connection including a flow identifier (ID); Receive a response from the network node including an indication of the request to establish a QUIC connection with the destination endpoint; Send external QUIC packetized data to the network node, which encapsulates internal QUIC packetized data to be forwarded to the destination endpoint, wherein the internal QUIC packetized data includes information indicating the flow ID; Send a request to the network node to stop encapsulating internal QUIC packetized data within external QUIC packetized data; Receive from the network node a response to the request to stop encapsulating internal QUIC packetized data within external QUIC packetized data, wherein the response includes information indicating that the request is accepted; and Send a UDP datagram to the network node, the UDP datagram including internal QUIC packetized data to be forwarded to the destination endpoint.

9. The method of claim 8, the method comprising sending a request to the network node to establish another QUIC connection with another destination endpoint, the request to establish the other QUIC connection including another stream ID.

10. The method of claim 8, wherein the request to establish the QUIC connection with the destination endpoint is encapsulated in the external QUIC packetized data.

11. The method of claim 8, wherein the internal QUIC grouped data and the external QUIC grouped data are encrypted separately.

12. The method of claim 8, wherein a request to stop encapsulating internal QUIC packetized data within external QUIC packetized data is sent in response to a predefined encryption level being reached with the connection to the destination endpoint.

13. The method of claim 8, wherein the request to stop encapsulating internal QUIC packetized data is accepted provided that the QUIC connection to the destination endpoint does not carry multiple multiplexed QUIC streams.

14. The method of claim 8, wherein the network node is a proxy configured to forward the internal QUIC packetized data to the destination endpoint.

15. A network node, comprising: processor; and transceiver; The transceiver is configured to receive from the client endpoint a request to establish a Fast User Datagram Protocol (UDP) connection (QUIC) to the destination endpoint, the request to establish the QUIC connection including a stream identifier (ID); The processor and the transceiver are configured to send a response to the client endpoint including an indication of the request to establish the QUIC connection with the destination endpoint; The transceiver is configured to receive external QUIC packetized data from the client endpoint, which encapsulates internal QUIC packetized data, including the stream ID; The processor and the transceiver are configured to forward the internal QUIC packetized data to the destination endpoint based on the stream ID; The transceiver is configured to receive from the client endpoint a request to stop encapsulating internal QUIC packetized data within external QUIC packetized data; The processor and the transceiver are configured to send a response to the client endpoint to the request to stop encapsulating internal QUIC packetized data within external QUIC packetized data, wherein the response includes information indicating that the request is accepted; and The processor and the transceiver are configured to forward UDP datagrams to the destination endpoint, the UDP datagrams including internal QUIC packetized data from the client endpoint.

16. The network node of claim 15, wherein the processor and the transceiver are configured to receive from the client endpoint a request to establish another QUIC connection with another destination endpoint, the request to establish the other QUIC connection including another stream ID.

17. The network node of claim 15, wherein the request to establish the QUIC connection with the destination endpoint is encapsulated in the external QUIC packetized data.

18. The network node of claim 15, wherein the internal QUIC packetized data and the external QUIC packetized data are encrypted separately.

19. The network node of claim 15, wherein the request to stop encapsulating internal QUIC packetized data within external QUIC packetized data is received when the connection with the destination endpoint reaches a predefined encryption level.

20. The network node of claim 15, wherein the request to stop encapsulating internal QUIC packetized data is accepted provided that the QUIC connection to the destination endpoint does not carry multiple multiplexed QUIC streams.

Images