Enabling optimized masque for PDU sets

Abstract

A user plane function (UPF) may receive a message from a session management function (SMF) that comprises an indication to initiate a proxied connection to an application server (AS) and / or an indication to parse metadata which is coalesced with media data on a same user datagram protocol (UDP) datagram. The UPF may send a request message to the AS that includes an indication to support coalescing one round trip time (1-RTT) quick UDP internet connections (QUIC) packets, coalescing QUIC packets with different connection identifications (CIDs), and / or coalescing protocol data unit (PDU) set information and a media PDU, the request message comprising one or more parsing parameters. The UPF may receive a UDP datagram from the AS. The UPF may parse the UDP datagram using the one or more parsing parameters, for example, to identify the PDU set information and a QUIC packet in the UDP datagram.

Description

ENABLING OPTIMIZED MASQUE FOR PDU SETSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of United States Provisional Application No. 63 / 568,630 filed on March 22, 2024, the entire contents of which is incorporated herein by reference in its entirety.BACKGROUND

[0002] XR traffic handling by wireless networks and / or PDU sets may be described herein. It may be challenging for wireless networks to carry media flows, especially for applications with high-throughput and / or low latency requirement(s), such as video conferencing and / or XR. Wireless networks can implement techniques to improve network capacity and / or energy efficiency, as well as reduce the impact of packet losses on user experience. For example, wireless networks such as 5G can handle groups of packets based on how critical they are to the user experience. One or more (e.g., some) groups of data packets may hold application data units that are handled together (e.g., decoded) by the application, and / or that are referend to as PDU set. A PDU set may, for example, correspond to the PDUs carrying a single complete network application layer (NAL) unit. To support high-throughput low-latency media flows, the network (e.g., RAN) can perform differentiated / integrated QoS handling of XR traffic. This can include prioritizing PDU sets over others in case of congestion. The network can use the face that application data units can depend on other application data units to be handled and / or decoded by the application (e.g., P-frames may depend on l-frames, and / or enhancement layers may depend on base layers). The network may (e.g., also) selectively drop data packets that depend on an already lost application data unit. The network can limit wake-up time (e.g., of radios) to transmit and / or receive data. For example, the packet scheduler (e.g., in RAN nodes) and / or wireless transmit / receive units (WTRUs) can synchronize their transmission and / or listening times using information on the size and / or periodicity of traffic, as well as delay budget and / or expected jitter specific to the application.

[0003] The RAN can perform differentiated / integrated QoS handling of XR traffic, for example, based on differentiated / integrated handling lEs associated with a flow and / or PDU sets inside this flow. Differentiated / integrated handling lEs may include PDU set QoS parameters that are received via the control plane and / or PDU set information that was received via user plane. For downlink traffic, PDU set information can be sent by the UPF tothe RAN node via GTP-U header of a user plane packet For uplink traffic, PDU set information can be provided by a WTRU application through the service data adaptation protocol (SDAP) interface.SUMMARY

[0004] Embodiment(s) related to Protocol Data Unit (PDU) set identification and / or quality of service (QoS) handling of encrypted QUIC-based media traffic, using enhanced QUIC-aware proxying are described herein. An AF may configure the network to receive media and / or PDU set information using an enhanced mode of operation of multiplexed application substrate over QUIC encryption (MASQUE) with QUIC-aware proxying. The user plane function (UPF) and / or the application function (AF) may negotiate the use of an enhanced mode of operation of MASQUE with QUIC-aware proxying. The application server (AS) may provide parsing information to the UPF, for example, to enable parsing. The UPF may use the parsing information to parse a coalesced user datagram protocol (UDP) datagram. The UPF may identify the PDU set from the first QUIC packet and / or may forward the second QUIC packet including the media PDU to a wireless transmit / receive unit (WTRU).

[0005] A UPF may receive a message from a session management function (SMF) that comprises an indication to initiate a proxied connection to an AS and / or an indication to parse metadata which is coalesced with media data on a same user datagram protocol (UDP) datagram. The UPF may send a request message to the AS. The request message may include an indication to support one or more of coalescing one round trip time (1-RTT) quick UDP internet connections (QUIC) packets, coalescing QUIC packets with different connection identifications (Cl Ds), or coalescing protocol data unit (PDU) set information and a media PDU, the request message comprising one or more parsing parameters. The UPF may receive a UDP datagram from the AS. The UPF may parse the UDP datagram using the one or more parsing parameters, for example, to identify the PDU set information in the UDP datagram and / or identify a QUIC packet in the UDP datagram.

[0006] The QUIC packet may be a first QUIC packet. The PDU set information in the UDP datagram may be identified based on information in a second QUIC packet. The UPF may forward the first QUIC packet with the PDU set information to a network. The second QUIC packet may include the PDU set information. The first QUIC packet may include the media PDU. The second QUIC packet may be associated with an AS to UPF connection.The first QUIC packet may be associated with an AS to wireless transmit / receive unit (WTRU) connection.

[0007] The UPF may receive the one or more parsing parameters from the SMF. The one or more parsing parameters may be received in the message from the SMF. The one or more parsing parameters may include information on coalescing that enables the first network node to parse the UDP datagram. The UPF may receive a response message from the AS. The response message may include an indication of support for one or more of coalescing 1-RTT QUIC packets, coalescing QUIC packets with different CIDs, or coalescing PDU set information and the media PDU. The request message may include one or more QUIC-aware proxying optimized for PDU set information coalescing (QPOP) setup information elements (IBs), and wherein the QPOP setup lEs indicate support of one or more of coalescing 1-RTT QUIC packets, coalescing QUIC packets with different CIDs, or coalescing PDU set information and the media PDU. The UPF may configure a multiplexed application substrate over QUIC encryption (MASQUE) proxy client for QUIC-aware proxying with the AS.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0009] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0010] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0011] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0012] FIG. 2 depicts an example user datagram protocol (UDP) datagram including coalesced QUIC packets.

[0013] FIG. 3 depicts an example of major phases and / or information elements (lEs) for QUIC-aware proxying optimized for protocol data unit (PDU) set information coalescing (QPOP).

[0014] FIGs. 4A and 4B depict an example call flow diagram with respect to configuration, establishment, and / or operation of an extended reality (XR) media session using QPOP.DETAILED DESCRIPTION

[0015] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 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 uniqueword DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0016] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or a “STA”, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a WTRU. Further, any description herein that isdescribed with reference to a UE may be equally applicable to a WTRU (or vice versa). For example, a WTRU may be configured to perform any of the processes or procedures described herein as being performed by a UE (or vice versa).

[0017] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0018] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the 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.

[0019] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0020] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such asCDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). 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 UL Packet Access (HSUPA).

[0021] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE- Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0022] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).

[0023] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., a eNB and a gNB).

[0024] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0025] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d mayimplement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE- A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0026] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1 A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0027] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0028] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configuredto communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0029] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, nonremovable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0030] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0031] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0033] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.

[0034] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the nonremovable memory 130 and / or the removable memory 132. The 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. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0036] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated thatthe WTRU 102 may acquire location information by way of any suitable locationdetermination method while remaining consistent with an embodiment.

[0037] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0038] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0039] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0040] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMOtechnology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0041] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 10, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0042] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0043] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0044] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0045] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0046] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS)server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0047] Although the WTRU is described in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0048] In representative embodiments, the other network 112 may be a WLAN.

[0049] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an AccessPoint (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0050] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detectedand / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0051] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0052] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0053] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11 n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representative embodiment, 802.11ah may support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0054] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11ac, 802.11af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) thatsupport (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0055] In the United States, the available frequency bands, which may be used by 802.11ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0056] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0057] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0058] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions,different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0059] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non- standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0060] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0061] The CN 115 shown in FIG. 1 D 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. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0062] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b,102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AM F 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. The A F 162 may provide a control plane function for switching between the RAN 113 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.

[0063] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernetbased, and the like.

[0064] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0065] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a,184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0066] In view of Figures 1 A-1 D, and the corresponding description of Figures 1 A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a- c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0067] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the 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 in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or may performing testing using over-the-air wireless communications.

[0068] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0069] The terms application server (AS) and application function (AF) may be used interchangeably herein. An AS may, in example, be an edge application server (EAS). The term user plane function (UPF) may designate a protocol data unit (PDU) session anchor (PSA) (e.g., unless otherwise specified). The term connection identification (CID) (e.g., in the QUIC protocol) may designate destination CID (e.g., unless otherwise specified). The term information element (IE) may be used herein to represent one or more parameters. An IE may be made up of one or more other lEs. The terms PDU set lEs, PDU set metadata,and / or metadata may be used interchangeably herein. The term coalesced user datagram protocol (UDP) datagram and coalesced datagram may refer to a single UDP da that includes more than one packet (e.g., more than one QUIC packet(s)). The term coalesced QUIC packet may refer to packet(s) that are sent in the same UDP datagram.

[0070] How a UPF can process a coalesced UDP datagram may be described herein. One or more (e.g., same) concepts may be applied to one or more other network nodes that process user plana data such as a WTRU, AS, proxy, and / or radio access network (RAN) node.

[0071] This work enhances a method for providing PDU set information along with media PDU, from an AS to a UPF, to enable PDU Set QoS handling by the 5GS. The UPF and AS negotiate the use of a mode of operation of MASQUE with QUIC-aware proxying, where a sender can coalesce QUIC packets which have both a short header and a different CID, in the same UDP datagram. AS provide parsing information, to enable parsing of the coalesced UDP datagram by the UPF. The parsing information can include a length, minimum length, type, CID. The AS packetizes the PDU Set information “A” and its related media PDU “B”, coalesces “A” and “B” in a same UDP datagram. The UPF parses the coalesced UDP datagram using the parsing information, identifies the PDU set information and forwards the media PDU towards the WTRU.

[0072] PDU Set Identification and QoS Handling of encrypted QUIC-based media traffic, using enhanced QUIC-aware proxying may be provided. The AF configures the network to receive media and PDU set information using an enhanced mode of operation of MASQUE with QUIC-aware proxying. The UPF and AS negotiate the use of an enhanced mode of operation of MASQUE with QUIC-aware proxying. The AS provides parsing information to the UPF, to enable parsing. The UPF uses the parsing information to parse a coalesced UDP datagram. The UPF identifies the PDU set from the first QUIC packet and forwards the second QUIC packet containing the media PDU to the WTRU.

[0073] Embodiments with respect to QUIC-aware proxying optimized for PDU set information coalescing (UPF) are described herein.

[0074] A network node (e.g., an UPF) may receive, from another network node (e.g., the session management function (SMF)), a message that includes an indication to initiate a proxied connection to an AS, for example, for traffic to and from a WTRU. The indication may include the AS endpoint (e.g., internet protocol (IP) address and port), security material (e.g., shared key and / or certificate), traffic identification (e.g., a traffic filter), and / or the like. The message may include an indication to use optimized parsing and / or may include one ormore parsing parameters. The indication to use optimized parsing may indicate to parse metadata which is coalesced with media data on a same UDP datagram. The UPF may be configured as a MASQUE proxy client for QUIC-aware proxying with the AS.

[0075] The UPF may transmit, to the AS, a request to use proxying with QUIC-aware forwarding. For example, the UPF may send a request message to the AS. The request message may include an indication to support coalescing 1-round trip time (RTT) QUIC packets, coalescing QUIC packets with different CIDs, and / or coalescing PDU set information and a media PDU. For example, the request message may include one or more QPOP setup lEs that indicate support of coalescing 1-RTT QUIC packets, coalescing QUIC packets with different CIDs, and / or coalescing PDU set information and the media PDU. The QPOP setup lEs may be sent by the UPF to the AS to request using QPOP.

[0076] The UPF may receive, from the AS, a response (e.g., a response message) accepting proxying with QUIC-aware forwarding, an indication of support for coalescing 1- RTT QUIC packets, coalescing QUIC packets with different CIDs, and / or coalescing QUIC packets with PDU set information and / or media PDU. For example, the AS may send a response message in response to the request message.

[0077] The UPF may receive, from the AS, parsing parameters (e.g., parsing parameters may be provided in one or more procedures described herein). For example, one or more different parsing parameters may be provided in a message from the SMF, in a response message from the AS, etc. (e.g., as described herein). For example, one or more of the same parsing parameters may be provided in one or more different procedures (e.g., as described herein). For example, one or more (e.g., different) parsing parameters may be provided in the indication to initiate a proxied connection to an AS and / or receipt of the parsing parameters from the AS. Receiving the parsing parameters from the AS may occur more than once (e.g., the AS may update the CID associated with QUIC packets carrying PDU set information). The one or more parsing parameters may include information associated with coalescing that enables the first network node to parse the UDP datagram.

[0078] The UPF may receive a UDP datagram from the AS.

[0079] The UPF may parse the UDP datagram, for example, using one or more parsing parameters (e.g., QUIC-aware proxying optimized for protocol data unit (PDU) set information coalescing (QPOP) parameters) to identify the first QUIC packet and / or identify the beginning of the second QUIC packet. For example, the UPF may parse the UDP datagram to identify the PDU set information in the UDP datagram and one or more QUIC packets in the UDP datagram.

[0080] The UPF may read the PDU set information from (e.g., based on information in) a first QUIC packet of the one or more QUIC packets, and / or may forward a second QUIC packet of the one or more QUIC packets towards the RAN, along with the PDU set information (e.g., in generic tunneling protocol user plane (GTP-U) header), for example, to enable PDU set based quality of service (QoS) handling by the RAN. The second QUIC packet may be forwarded over UDP / IP. The first QUIC packet may include the PDU set information and the second QUIC packet may include the media PDU. The first QUIC packet may be associated with an AS to UPF connection. The second QUIC packet may be associated with an AS to WTRU connection.

[0081] Transmitting the request to use proxying with QUIC-aware forwarding and / or receiving the response may occur (e.g., once) for the QUIC connection (e.g., QUIC transport parameters that may include an indication to support coalescing 1-RTT QUIC packets and / or QUIC packets with different CIDs) and / or (e.g., once) for the MASQUE session within the QUIC connection (e.g., hypertext transfer protocol (HTTP) CONNECT request & HTTP response including an indication to coalesce PDU set information with media PDU).

[0082] Receiving the indication to initiate the proxied connection to an AS and / or receiving the parsing parameters from the AS may (e.g., both) provide parsing parameters (e.g., a fixed length may be provided in the indication to initiate the proxied connection to an AS, and / or a CID may be provided when receiving the parsing parameters from the AS). In examples, the parsing parameters may be provided (e.g., only) in the indication to initiate the proxied connection to an AS or (e.g., only) when receiving the parsing parameters from the AS.

[0083] The term PDU set IE can be used to represent lEs described herein as PDU set information and / or PDU set QoS parameters.

[0084] PDU set information may include one or more of the following. PDU set information may include PDU set ID. PDU set ID may be an identifier of a PDU set, which (e.g., uniquely) identifies the PDU set within the flow, at least for duration corresponding to the transmission time of PDUs between sender and receiver. PDU set ID may be, for example, a numerical ID, a timestamp, etc. PDU set information may include start and / or end of a PDU set indication. Start and / or end time of a PDU set indication may identify the first and / or last PDU(s) of a PDU set. PDU set information may include PDU sequence number within a PDU set. PDU sequence number within a PDU set may identify a PDU within a PDU set, for example, a numerical ID that is initialized (e.g., at 0 for the first PDU of the set), and / or that may be incremented for each subsequent PDU in the set. PDU setinformation may include PDU set size. The PDU set size may hold the total number of PDUs, and / or the cumulative length of (e.g., all) the PDUs in the set, and / or the cumulative length of (e.g., all) PDU payload (e.g., transport payload) in the PDU set. PDU set information may include PDU set importance. PDU set importance may be a numerical value indicative of the importance level of a PDU set within a service flow (e.g., from highest priority value 0 to lowest priority value 255). RAN may use PDU set importance for PDU set level packet discarding in presence of congestion. PDU set information may include end-of- burst indication. End-of-burst indication may indicate that a PDU and / or a PDU set is the last PDU and / or PDU set of a burst. End-of-burst indication may (e.g., also) include lEs indicating the amount of time before the next burst. PDU set information may include XR application session ID, which may identify the session (e.g., to provide a scope for prioritizing, scheduling, and / or synchronizing flows, packets, and / or PDU sets). PDU set information may include XR application session priority, which provides a priority for intersession prioritization (e.g., to prioritize between flows belonging to different application sessions, which have a same flow priority). PDU set information may include XR flow ID, which identifies the flow (e.g., for applying XR service on the flow. XR flow ID may be provided by the mobile network (e.g., it may be a PDU session ID). PDU set information may include XR flow priority, which may provide a priority for inter-flow prioritization. PDU set information may include data type (e.g., audio, video, haptic, data. Data type may be used for inter-flow synchronization (e.g., to determine the acceptable synchronization delay between flows). PDU set information may include XR synchronization group ID, which may indicate which flows of the application session should be synchronized (e.g., with each other). PDU set information may include a list of applicable network services, which may indicate which network services (e.g., including PDU QoS set handling). The list of applicable network services may include one or more additional services, such as increased reliability (e.g., using multipath connectivity such as provided by access traffic steering, switching and splitting (ATSSS)), low-latency delivery, etc. The list of applicable network services can be used by the 5G network to determine which level of service should be provided to a given PDU set. PDU set information may include PDU set type, which may enable associating a domain-specific meaning with a PDU set (e.g., l-frame, P-frame, B- frame). PDU set type may be useful to provide XR services where specialized processing is required for selected types of PDU sets.

[0085] PDU set information may include PDU forward error correcting (FEC) parameters, including FEC algorithm and / or its parameters. They can be used, for example,by the WTRU / UPF / AS to recover lost packets in a PDU set protected by the FEC. PDU set information may include PDU parent set ID, which may identify a parent PDU set that is required to be received by the application, for the (child) PDU set to be usable by the application. PDU set information may include one or more timing lEs such as media unit timestamp, presentation timestamp, sending time timestamp, accumulated transmission delay, and / or PDU synchronization ID. PDU synchronization ID may identify a group of interrelated PDUs that may (e.g., must) be presented to the user at a similar time, within the same flow (e.g., a set of frames that must be presented to the user at the same time in a multi-screen setup), and / or between different flows (e.g., a video PDU that must be presented to the user together with haptic PDU).

[0086] PDU set QoS parameters may be a set of parameters to configure the QoS handling of a flow. PDU set QoS parameters may include one or more of the following. PDU set QoS parameters may include PDU set error rate. PDU set error rate may be a value that corresponds to error rate(s) applicable to PDU sets (e.g., where a PDU set loss corresponds to an event where at least a PDU of the set could not be transmitted successfully). PDU set error rate can be used to configure the acceptable error rate for PDU sets of a service flow and / or QoS flow in the RAN. PDU set QoS parameters may include PDU set delay budget. PDU set delay budget may be a value that corresponds to the acceptable delay for transmitting a full PDU set (e.g., from the reception of the first PDU of the set, to the transmission of the last PDU of the set). PDU set delay budget may be used to configure the delay budget for a service flow and / or QoS flow in the RAN. PDU set QoS parameters may include PDU set integrated indication. PDU set integrated indication may indicate whether one or more (e.g., all) PDUs of the set are needed by the application. PDU set QoS parameters may include burst periodicity. Burst periodicity may be a value that designates the period of a data burst for this flow (e.g., transmission period for consecutive independent frames in a video stream, transmission period for a group of pictures, etc.).

[0087] PDU set (PS) identification may be the determination of which PDU set a PDU belongs to, along with the identification of PS lEs that are associated with this PDU set. For non-encrypted media flows (e.g., using the real-time protocol (RTP)), this operation may (e.g., typically) be performed by the UPF for downlink flows. For encrypted media flows, this operation can be performed (e.g., both) by the media sender (e.g., origin media server and / or a proxy with access to transport metadata), and / or by the UPF (e.g., based on metadata placed in the PDU by the media sender, which may be visible by the UPF).

[0088] PS QoS handling may designate the operation (e.g., in RAN and / or in UPF) that includes providing differentiated handling (e.g., depending on PS lEs). For example, PS QoS handling may include dropping PDUs of lower PS importance in case of congestion.

[0089] QUIC-based media transport may be described herein. Encryption media protocols transport can prevent certain intermediaries (e.g., intermediaries not explicitly trusted by an endpoint and / or inserted in the connection) to perform PDU set identification. Encrypted media protocols may include HTTP-based stream protocols (e.g., when using transport layer security (TLS) for transport), secure real-time transport protocol (SRTP) when used with encrypted RTP extensions (e.g., such as described in RFC9335), RTP over QUIC (ROQ) and / or media over QUIC protocols (MOQ). Among these protocols, MOQ and / or ROQ may be a part of another (e.g., new) family of protocols that carry media over QUIC.

[0090] QUIC may be a transport protocol that supports flow-control streams, datagrams, and / or low-latency connection establishment and network path migration. QUIC may ensure confidentiality and / or integrity protection through its integration of TLS. HTTP / 3 may be transported over QUIC, including HTTP datagrams.

[0091] QUIC packets can be of one of several packet types. One of these packet types, 1-RTT, may be used to carry data, for example, after the initial connection setup is complete. 1-RTT packets may be used to carry (e.g., most) application data during a connection. 1-RTT packets may include a short header, while other types of packets may include a long header. The short header may not include a length.

[0092] MASQUE may be described herein. MASQUE protocol may enable configuring and / or running multiple proxied flows in an HTTP connection (e.g., using HTTP / 3 over QUIC). The MASQUE services may include the CONNECT-UDP service, which enables transporting UDP traffic between a client and a proxy (and in some cases between two proxies), CONNECT-IP, which enables transporting IP traffic, and / or CONNECT- ETHERNET, which may enable transporting Ethernet traffic.

[0093] To initiate a MASQUE service (also referred to as a MASQUE tunnel), the client may send an HTTP CONNECT request to a proxy (e.g., an HTTP request including a method field set to CONNECT, a protocol field set to the actual MASQUE transport method used, such as connect-udp, connect-ethernet, and / or connect-ip. The proxy may send an HTTP response to indicate that the service request is accepted and / or rejected. The MASQUE service may include forwarding the application payload transported over the MASQUE connection towards an endpoint (e.g., UDP server, and / or endpoint over anEthernet link and / or IP network). The application payload may be transported, between the MASQUE client and proxy, over HTTP datagrams and / or over an HTTP stream.

[0094] Herein, a MASQUE connection may designate the HTTP (e.g., HTTP / 3 over QUIC) connection between the client and proxy. A MASQUE connection can be used to establish one or more (e.g., multiple) tunnels using different CONNECT requests on different HTTP streams. Herein, a MASQUE session may designate an individual MASQUE tunnel.

[0095] QUIC-Aware proxying may be described herein. When a QUIC flow (e.g., MOQ and / or ROQ flow) is transported through a MASQUE proxy, for example, the client-proxy connection may use QUIC-Aware Proxying to minimize the load on the proxy. When using QUIC-Aware Proxying, end-to-end QUIC traffic may be transported in forwarded mode over the client-proxy MASQUE connection. A QUIC packet transported in forwarded mode may not be encapsulated (e.g., non re-encrypted) in the client-proxy connection. The proxy may forward forwarded mode QUIC packets (e.g., directly) between the client and the server. The proxy may, in examples, modify the CID of the forwarded mode QUIC packets, substituting the end-to-end CID (between the application endpoints) with a virtual CID (between the proxy and client). Using a virtual CID may protect against linking between both legs of an end-to-end proxied connection, by an attacker, with access to both the clientproxy and proxy-server paths. Both client and proxy may maintain a mapping between virtual CID and end-to-end CID, for example, to enable the substitution.

[0096] Mechanisms may have been proposed for supporting downlink PDU set identification, by a network, of end-to-end encrypted traffic transported over QUIC (e.g., MOQ, ROQ). These mechanisms may be based on (e.g., rely on) a MASQUE tunnel between UPF and AS, which may use QUIC-aware proxying, to limit resource usage on the UPF (e.g., by avoiding decrypting / encrypting media PDUs). When using these mechanisms, the AS may transmit PDU set information in a QUIC packet (e.g., packet A) that is part of the UPF-AS MASQUE connection. The PDU set information may pertain to a media PDU. When using these mechanisms, the AS may transmit the media PDU in a QUIC packet (e.g., packet B) that is part of the AS-WTRU end-to-end QUIC connection.

[0097] It may be desired to have both the QUIC packets (e.g., packet(s) A and / or B) being coalesced in a single UDP datagram to minimize inefficiencies at the UPF. This may make it possible for the UPF to get both packet A and packet B, which relate to each other, at the same time and without requiring additional processing and / or buffering to match packet A and packet B, which may be otherwise needed if they were sent in differentdatagrams. In other words, matching packets A and B may mean determining that packets A and B are associated.

[0098] Coalescing packets (e.g., packets A and B) may include one or more issues. One issue may include that QUIC packets A and B are (e.g., usual) data packets (e.g., “1-RTT” packets), which both may use a short header. In the QUIC, 0-RTT packets and / or 1-RTT packet may be referred to as (e.g., classified as) application data packets. 0-RTT may be (e.g., only) sent (e.g., very) early in the connection, then 1-RTT (e.g., only) may be sent later in the connection. For example, packet A and / or packet B may be 1-RTT QUIC packet. It may not be possible, when following the QUIC protocol standard, to coalesce two QUIC packets with short headers. For example, if a sender coalesces two short header QUIC packets in a UDP datagram, a receiver may not have enough information to determine the beginning of the second QUIC packet, for example, because the QUIC short header does not include a length. Another issue may include packets A and / or B may (e.g., typically) use different CIDs. It may not be possible, when following the QUIC protocol standard, to coalesce QUIC packets with different CIDs. For example, if a sender coalesces two QUIC packets with different CIDs, a QUIC protocol compliant receiver can close the connection with a protocol violation error.

[0099] A (e.g., new) solution may be desired to enable coalescing QUIC packets (e.g., A and B QUIC packets), with minimal disruption to existing standards and / or implementations, and / or minimal impact on network resource usage.

[0100] FIG. 2 depicts an example UDP datagram 200 including coalesced QUIC packets. QUIC-aware proxying optimized for PDU set information coalescing (QPOP) may be described herein. QPOP may include enabling coalescing: one or more (e.g., multiple) QUIC packets with short headers in a same UDP datagram; and / or one or more (e.g., multiple) QUIC packets with different destination CIDs in a same UDP datagram. The network may be configured with QPOP configuration lEs including an indication to use QPOP and / or QPOP parsing parameters. When the WTRU establishes another (e.g., new) media flow with an AS, for example, the network (e.g., PDU session anchor UPF (PSA UPF)) may establish a MASQUE connection with the AS, using QUIC-aware proxying, and / or may indicate the use of QPOP on the MASQUE connection and / or session. The UPF and / or the AS may exchange QPOP parsing parameters during the MASQUE connection and / or session establishment. QPOP parsing parameters may provide information on the coalescing operation, which may make it possible for the UPF to parse the coalesced QUIC packets. During the media session, for example, the AS may generate media PDUs and / orassociated PDU set information lEs; the AS may packetize the associated PDU set information lEs in a first QUIC packet (e.g., QUIC packet A) of the AS-UPF connection and / or may packetize the media PDU in a second QUIC packet (e.g., QUIC packet B) of the end-to-end AS-WTRU connection; the AS may coalesce both QUIC packets (e.g., both QUIC packets A and B) in a same UDP datagram, as illustrated in FIG. 2; and / or the AS may send the UDP datagram to the UPF. Upon reception, the UPF may use the QPOP parsing parameters which were received during MASQUE connection and / or session establishment, to parse the coalesced UDP datagram; the UPF may identify the PDU set information based on information that is included in QUIC packet A; the UPF may forward QUIC packet B in a UDP / IP datagram to the WTRU, encapsulated in a GTP packet and / or may include the associated PDU set information in the GTP header. The RAN may use the PDU set information to provide PS QoS handling service. The WTRU may forward the media PDU to the WTRU application, which can play the media.

[0101] In one or more (e.g., some) systems, the order of QUIC packet A and B may be reversed. For example, QUIC packet B carrying the media PDU may be the first packet, and QUIC packet A carrying the PDU set information may be the second packet. The methods described herein may (e.g., also) be used in this case. For example, in the case where parsing parameters (e.g., described herein) include a CID and / or a fixed length, the UPF can detect a coalesced UDP datagram based on the CID of the (e.g., first) packet B and / or may count a fixed length from the end of the UDP datagram to find the beginning of the (e.g., second) packet A. From this point on (e.g., for simplicity), the methods and / or procedures may use the case where packet A is the first QUIC packet, and packet B is the second QUIC packet.

[0102] FIG. 3 depicts example major phases and lEs for QPOP 300. lEs defined herein may include configuration lEs and setup lEs. In the configuration phase, as FIG. 3 illustrates, the network may be configured with QPOP configuration lEs. In the establishment phase of FIG. 3, a media session may be established and / or a UPF-AS MASQUE connection may be established to transport the media traffic. In the operation phase of FIG. 3, the AS may coalesce media PDU and its associated PDU set information, and / or the UPF may parse the coalesced UDP datagram to obtain the PDU set information and / or may forward the media PDU.

[0103] QPOP applicability may be more general. The enhanced coalescing methods of QPOP may be described herein in the context of PDU set information transmission usingQUIC-aware proxying. It may be useful in one or more other scenarios (e.g., to support efficient multiplexing of multiple proxied connections).

[0104] A first phase may relate to configuring the network for optimized QUIC-Aware proxying for PDU set information coalescing. In a first phase, the network may be configured to use optimized QUIC-aware proxying between the UPF and the AS. QPOP configuration lEs may be used by the network to use the optimized QUIC-aware proxying feature. As described herein, QPOP configuration lEs may be configured in the policy control function (PCF), session management function (SMF), and / or the UPF.

[0105] QPOP configuration lEs may include one or more of the following. QPOP configuration lEs may include an indication to use QUIC-aware proxying optimized for PDU set support (e.g., an indication to use the method and / or procedures described herein). QPOP configuration lEs may include an indication to use, or not to use, Virtual CIDs with QUIC-aware proxying. Virtual CIDs can improve privacy but can (e.g., also) increase the central processing unit (CPU) load on the UPF. The AS / AF may request using Virtual CIDs, for example, for services marketed as protective of privacy. The network (e.g., PCF and / or SMF) may determine whether to apply virtual CIDs, for example, based on the subscription profile. For example, the network may decide to agree to use virtual CIDs for users who applied for a higher privacy protection service.

[0106] QPOP configuration lEs may include QPOP parsing parameter lEs (e.g., also referred to herein as parsing parameters) for enabling and / or facilitating parsing of a coalesced datagram by the receiver, including one or more of (e.g., a combination of) the following. QPOP parsing parameter lEs may include one or more first-packet CIDs that may be included in the first short header QUIC packet of a coalesced UDP datagram. Each short header QUIC packet may (e.g., always may) include one destination CID that is picked by the sender from a set of CIDs provided by the remote peer. The AS may select one CID (e.g., which may be referred to as the first-packet CID) from the set and / or may decide to use this from the first-packet CID in one or more (e.g., all) QUIC packets including PDU set information and / or one or more (e.g., all) first short header QUIC packets in a coalesced UDP datagram, and / or the AS may use a different CID for other QUIC packets it may (e.g., wish) to send to the UPF on this connection. The AS may select more than one first-packet CID and / or may use them concurrently and / or switch from using one to use another one after a certain time. The AS may, for example, provide first-packet CIDs to the UPF in a (e.g., CAPSULE) message during the lifetime of the UPF-AS QUIC connection. The AS can change the first-packet CID over time and / or may send another (e.g., new) message toinform the UPF of one or more other (e.g., new) values. Upon receiving a UDP datagram including a first QUIC packet with a first-packet CID, for example, the UPF may determine that this QUIC packet may be coalesced with another QUIC packet. Upon receiving a UDP datagram including a first QUIC packet with a CID that is not a first-packet CID, for example, the UPF may determine that this QUIC packet is not coalesced with another QUIC packet, which may simplify the parsing logic on the UPF. Based on this determination, if the UDP datagram is likely to be coalesced, the UPF may use other parsing parameters hereinafter to enable the parsing of the coalesced UDP datagram (e.g., further processing as described herein). Based on this determination, if the UDP datagram is not coalesced, the UPF may read the QUIC packet carried in the UDP datagram and / or may process the packet according to a pre-determined configuration for non-coalesced packets (e.g., forward the QUIC packet, over UDP / IP, towards the WTRU through the RAN).

[0107] QPOP configuration lEs may include the length of the first short header QUIC packet in a coalesced UDP datagram. The length parameter may require the AS to (e.g., always) emit QUIC packets A of the same length, including PDU set information lEs and / or adding additional padding frames to reach the exact length provided in QPOP parsing parameters. The length parameter may enable the UPF to determine where the second coalesced QUIC packet (e.g., packet B) should be located and / or may check the validity of the CID at this location in the UDP datagram. The length parameter may (e.g., also) enable the UPF to determine which portion of the UDP datagram should be decrypted as QUIC pack A, which may enable decrypting QUIC packet A in one pass. The usage of parsing parameters length and / or first-packet CIDs may be combined, for example, to enable the UPF to identify a coalesced UDP datagram using the first-packet CID, and / or may (e.g., then) use the length to find the boundaries of QUIC packet A and / or QUIC packet B. The UPF may (e.g., then) decrypt QUIC packet A and / or may forward QUIC packet B.

[0108] QPOP configuration lEs may include the minimum length of the first short header QUIC packet in a coalesced UDP datagram. This may enable the UPF to decrypt the beginning of the first QUIC packet in a UDP datagram, up to this minimum length, and / or (e.g., then) parse the beginning of the QUIC packet payload, including a length IE. When using the minimum length parameter, for example, the AS may (e.g., may need) to ensure that the first short header QUIC packet in a coalesced UDP datagram includes enough information in the first minimum length bytes of the QUIC packet, to determine the length of the whole QUIC packet. For example, the AS can use a QUIC datagram including a length,if the total length of the QUIC header, first 9 bytes of the DATAGRAM frame, and overhead from QUIC encryption, is less than the minimum length provided as parsing parameter.

[0109] QPOP configuration IBs may include an indication of the type of information that is carried in the payload of the first short header QUIC packet in a coalesced datagram (e.g., packet type and / or frame type). For example, the type can indicate a QUIC datagram frame, an HTTP datagram, and / or a PDU set information HTTP datagram type. The type parameter may provide information to the UPF, on how to parse the first QUIC packet payload. In examples, (e.g., where type is a QUIC datagram frame with LEN bit set to 1), the UPF may expect to get the length from the first 9 bytes of the start of DATAGRAM frame. When using the minimum length parameter, the AS may (e.g., need to) ensure that the first short header QUIC packet in a coalesced UDP datagram is using a type provided as parsing parameter.

[0110] QPOP configuration lEs may include a protocol version and / or protocol extension identifier required for the QUIC connection between UPF and AS. The protocol version / extension parsing par ammeter may indicate the QUIC minimum version (e.g., v1 or v2) and / or QUIC extension(s) that may be (e.g., need to be) negotiated and / or used between the UPF and AS. For example, this can be a QUIC extension (e.g., as described herein) enabling coalescing short header QUIC packets and / or QUIC packets with different CIDs. In examples, a minimum QUIC version v3 may be required, in a hypothetical case where another (e.g., new) QUIC v3 is defined to support coalescing QUIC packets with different CIDs.

[0111] QPOP configuration lEs may include an indication to use a UDP option to provide parsing information to the UPF. The indication to use a UDP option can, for example, include the UDP option kind (e.g., a new kind / type value), which identifies the format of the UDP option (e.g., including UDP option kind COALESCED, a length, and / or a single integer value that is the length of the first QUIC packet). When the AS coalesces QUIC packets including PDU set information and media PDU, for example, the AS may place dynamic parsing information (e.g., the length of the first coalesced QUIC packet) in a UDP option and / or may transmit the IP packet including the UDP datagram and / or the UDP option. Upon receiving the IP packet, for example, the UPF may detect the presence of the UDP option as usual (e.g., based on the length lEs of the IP header and / or UDP header), and / or may read the UDP option. Based on the UDP option kind (e.g., COALESCED), for example, the UPF may determine that the UDP datagram carries coalesced short header QUIC packets. The UPF may read the length of the first QUIC packet from the IE in the UDPoption and / or may use it to parse the first QUIC packet and / or may find the beginning of the second QUIC packet.

[0112] QPOP configuration IBs may include a maximum number of coalesced QUIC packets with short headers. This maximum number may be, for example, 2 in the case where QPOP is used to transmit PDU set information from AS to UPF e.g., which is used as the main usage example herein). This maximum number may be higher in other use cases, for example, where the MASQUE session is used to coalesce packets to and / or from one or more (e.g., multiple) sources.

[0113] The AF and / or network operator may configure QPOP configuration lEs in the network (e.g., an AF can request an AF session with QoS that includes PDU set QoS parameters, and / or that include QPOP configuration lEs and / or the IP address and / or fully qualified domain name (FQDN) for the AS. The PCF may create and / or modify a policy and charging control (PCC) rule with this information, including QPOP configuration lEs. The PCF may provide the PCC rule to the SMF and / or the SMF may send an N4 session establishment / modification message to the UPF, including QPOP configuration lEs. The UPF may configure a MASQUE client to use QPOP, using QPOP parsing parameters if provided by the SMF. The QPOP parsing parameter IES may (e.g., also) be provided during the establishment of the MASQUE connection / session (e.g., as described herein).

[0114] The UPF capabilities (e.g., configured on UPF and / or obtained by SMF over the N4 session) can include an indication for QPOP support. The SMF may use the QPOP support UPF capability to determine whether to apply QPOP on a PDU session. The SMF may use the QPOP support UPF capability to select a PSA UPF capable of handling a PDU session using QPOP. For example, the SMF may interact with a network repository function (NRF) to discover UPFs and / or may receive information from the NRF that indicates whether a UPF supports the QPOP. The SMF may (e.g., then) select a UPF based on the UPF’s support for QPOP.

[0115] A second phase may relate to establishment of QUIC-aware proxying optimized for PDU set information coalescing. In a second phase, the UPF may establish a MASQUE connection with the AS. The UPF and / or the AS may use QUIC-aware proxying to exchange end-to-end media packets in forwarded mode (e.g., not encapsulated in the UPF-AS MASQUE connection). Using QUIC-aware proxying may save UPF resources. The UPF may use QPOP to process media PDU and / or PDU set information coalesced in the same UDP datagram.

[0116] The UPF and AS may exchange QPOP Setup lEs during the MASQUE connection establishment with the AS, and / or over the course of the MASQUE connection. Setup lEs may include the same lEs as defined in the QPOP configuration lEs. QPOP setup lEs may be provided using another (e.g., new) QUIC transport parameter for QPOP that is defined to indicate support and / or usage for enhanced coalescing. Enhanced coalescing may include enabling QUIC short packets, using different CIDs, to be coalesced. QPOP parsing parameter lEs may be provided as values of the QUIC transport parameter. For example, the UPF may include a QPOP QUIC transport parameter in a QUIC initial packet, with value 1 to indicate support. The AS may respond with a QUIC packet including a QPOP QUIC transport parameter with a value of 50, to indicate the fixed and / or minimum length of the first QUIC packet in a coalesced datagram. QPOP setup lEs may be provided using another (e.g., new) indication to use QPOP that is defined to indicate that a specific MASQUE session should be QPOP. This indication may be, for example, the value of another (e.g., new) HTTP header field in the HTTP CONNECT message that initiates the MASQUE session, and / or a value in a CAPSULE message sent over the MASQUE session. For example, the UPF can set a qpop:<value> HTTP header in the HTTP CONNECT message, and / or the AS may set a qpop:<value> HTTP header in the HTTP response to indicate QPOP will be used, and / or qpop:0 to indicate QPOP will not be used. The <value> may be a QPOP parsing parameter IE, or 1 to indicate support without providing a QPOP parsing parameter IE, for example, if QPOP parsing parameters were already transmitted using other means (e.g., as described herein). In examples, the UPF and / or AS may send a QPOP CAPSULE message including <value> and / or the remote peer (UPF and / or AS) may reply with a QPOP CAPSULE including <value> and / or 0.

[0117] The establishment of a QPOP-capable connection can be performed as follows: once the UPF is configured using QPOP configuration lEs and / or AS IP address and / or FQDN, the UPF may establish a MASQUE connection with the AS, including another (e.g., new) QUIC transport parameter QPOP. This QUIC transport parameter may indicate at least that the QUIC stack supports coalescing QUIC packets with short headers and / or different CIDs (which may not be allowed by the current QUIC protocol standard. Instead of establishing another (e.g., new) MASQUE connection, for example, the UPF may select an existing MASQUE connection with this AS. Once the MASQUE connection is established / selected, for example, the UPF may send an HTTP CONNECT request, to create a MASQUE session to transport the media PDUs between the AS and the WTRU over the PDU session. The UPF and AS may negotiate the use of QPOP for a givenMASQUE session, for example, using a QPOP HTTP header in the CONNECT request and / or reply, and / or in a control message (e.g., CAPSULE message) once the MASQUE session is created. These negotiations may (e.g., also) be used to exchange a QPOP parsing parameters between AS and UPF. For example, a MASQUE connection between a UPF and an AS can be reused for one or more (e.g., multiple) media sessions each over their own MASQUE session, and / or each MASQUE session may use different QPOP parsing parameters.

[0118] A third phase may relate to transmission and processing of coalesced media PDU and PDU set information. In a third phase, the AS may transmit coalesced media PDU and PDU set information, and / or the UPF may process the coalesced packet to identify the PDU set information and / or forward the media PDU to the RAN so that it can be transmitted to the WTRU.

[0119] The AS may packetize a media unit in (at least) one PDU and / or may generate PDU set information related to each media PDU. The AS (e.g., then) may packetize the PDU set information. This may result in a first QUIC packet (e.g., QUIC packet A) including PDU set information and / or a second QUIC packet (e.g., QUIC packet B) including the media PDU. QUIC packet A may be part of the AS-UPF MASQUE connection. QUIC packet B may be part of the AS-WTRU end-to-end QUIC connection (e.g., the MOQ and / or ROQ session). QUIC packets A and B may have (e.g., therefore) different destination CIDs and / or may be encrypted using different session keys. Since the AS-UPF MASQUE connection is using QUIC-aware proxying, for example, QUIC packet B may not be encapsulated (e.g., not re-encrypted) in the AS-UPF MASQUE connection.

[0120] The AS may perform an enhanced coalescing operation of the QUIC packets A and B. The AS may ensure that the first QUIC packet A is created with proper characteristics matching the QPOP parsing parameters. For example, if a QPOP parsing parameter is an exact QUIC packet length and / or a minimum QUIC packet length, the AS may add QUIC PADDING frames to reach this length. The AS may ensure that QPOP was enabled for this MASQUE connection / session (e.g., as described herein, as described with respect to Phase two) and / or the AS may coalesce QUIC packets A and B in a same UDP datagram. The AS may transmit the coalesced UDP datagram to the WTRU, over the UPF- AS MASQUE connection, using QUIC-aware proxying in forwarding mode.

[0121] The AS may transmit control messages to the UPF (e.g., CAPSULE messages and / or HTTP datagrams), including QPOP parsing parameters such as fixed and / or minimum length, and / or type. For example, the control messages may include a QPOPparsing parameter that is applicable to one or more (e.g., all) coalesced datagrams on this session. In examples, the control message may include a QPOP parsing parameter and / or one or more Cl Ds, to indicate that the QPOP parsing parameter is valid if the CID of the first QUIC packet is in the provided list.

[0122] Coalescing QUIC packets in a UDP diagram may include (e.g., require) the resulting datagram to fit the path maximum transmission unit (MTU). The QUIC packets may be limited in size. For example, the QUIC packet including PDU set information may be set to a maximum length M, and / or the QUIC packet including media data may be (e.g., also) limited to a maximum length corresponding to the path MTU minus M. In examples, the QPOP parsing parameter may be a fixed length M, decided ahead of time by design of the AS application, and / or negotiated between the UPF and AS using a QUIC transport parsing parameter and / or HTTP header.

[0123] Upon reception, the UPF may perform an enhanced parsing operation on the coalesced datagram. The UPF may determine if the first QUIC packet has a short header (e.g., if the header form bit value is 0). If it is a short header packet, for example, the UPF may read the destination CID from the short header. If the CID indicates the QUIC packet is a forwarded mode packet, for example, the UPF may determine (e.g., can assume) the whole UDP datagram payload is a single QUIC packet, and / or may forward the QUIC packet, in a UDP / IP header, to the WTRU. IF the CID indicates the QUIC packet is a tunnel mode packet, for example, the UPF may decrypt the beginning and / or totality of the first QUIC packet, up to a number of bytes based on the QPOP parsing parameters (e.g., a fixed length based on the fixed and / or minimum QUIC packet size, and / or by steps to progressively decrypt enough payload to read, for example, the QUIC datagram length, and / or then complete the decryption of the first QUIC packet in the datagram). If the QPOP parsing information includes first-packet CIDs, the UPF may identify coalesced UDP datagrams by comparing the CID of the first QUIC packet with the list of first- packet CIDs in the QPOP parsing information. This identification based on first-packet CIDs may simplify parsing: for example, it may prevent false positives, where the UPF mistakenly determines (e.g., assumes) that a UDP datagram is coalesced while it is not. Such false positive can lead to unnecessary operations on the UPF, resulting in an inefficient usage of UPF processing resources.

[0124] Once the first QUIC packet is read, for example, the UPF may read the PDU set information IBs from the payload of the first QUIC packet. The remainder of the UDP datagram payload, if any, may be determined by the UPF to be a second QUIC packet. TheUPF may verify that the remainder of the UDP datagram payload is a valid QUIC packet {e.g., it may start with a valid QUIC header with a known CID). If it is not a valid QUIC packet, for example, the UPF may determine this is a protocol violation and / or may close the MASQUE session and / or may send an error indication to the AS and / or may send an error indication to the SMF. If the remainder of the UDP datagram payload is a valid packet, for example, the UPF may read the destination CID of the second QUIC packet and / or may verify that it is a valid CID for an end-to-end media packet (e.g., in forwarded mode it can be a virtual ID and / or end-to-end CID, and / or in tunnel mode it can be a CID of the UPF-AS connection). If the second QUIC packet is in tunnel mode, for example, the UPF may decrypt it. If the second QUIC packet is in forwarded mode with a virtual CID, the UPF may replace the virtual CID and / or the corresponding end-to-end CID. The UPF may (e.g., then) forward the resulting second QUIC packet to the WTRU, by adding a UDP header and / or an IP header, and / or (e.g., then) by forwarding the resulting IP packet over GTP through the RAN, including PDU set information lEs from the first QUIC packet in the GTP header.

[0125] Additionally or alternatively, one or more mechanisms described herein may be used to enable coalescing and / or parsing the QUIC packets with PDU set information and / or media PDU. These mechanisms may be extensions to the QUIC protocol, negotiated using a QUIC transport parameter. These mechanisms may not be included (e.g., required) if mechanisms described herein (e.g., using parsing parameters such as fixed length, minimum length, and / or type) are used). The AS may use a long header QUIC packet to carry the PDU set information. The AS may add another (e.g., new) length field in the QUIC header, creating another (e.g., new) header format that is an intermediate between the short and long header form.

[0126] Additionally or alternatively, the MASQUE connection may be established by the WTRU with the UPF, and / or the UPF may establish a second MASQUE connection with the AS, resulting in two legs. The MASQUE connection may use QUIC-aware proxying, and / or QPOP as described herein. The end-to-end media session (e.g., over MOQ / ROQ) may be forwarded over the two legs. One difference may be that the WTRU can provide the QPOP configuration / setup lEs to the UPF (e.g., during the MASQUE connection establishment and / or over the course of the MASQUE connection). The UPF can (e.g., then) provide the QPOP configuration / setup lEs to the AS, as described herein. The WTRU can obtain the QPOP configuration / setup lEs from the WTRU application, for example, and / or from the network (e.g., from the SMF in a PDU session establishment response). During the media session, the UPF may either (e.g., only) forward the QUIC packet including the media PDU,or it may forward the QUIC packet carrying the PDU set information coalesced with the QUIC packet carrying the media PDU into a coalesced UDP datagram. In examples, the WTRU may use the QPOP parsing parameters to parse the coalesced UDP datagram, and / or the WTRU may use the PDU set information, for example, to apply QoS handling when forwarding the media PDU (e.g., over a sidelink and / or another wireless link).

[0127] QPOP configuration, establishment, and / or operation may be provided herein. FIGs. 4A and 4B depict an example call flow diagram with respect to configuration, establishment, and / or operation 400 of an extended reality (XR) media session using QPOP.

[0128] At 430, an application at a WTRU 402 may trigger the establishment of an XR application session with an AS 422.

[0129] At 432, the WTRU 402 may trigger the establishment and / or modification of a PDU session for the XR application flow. The PDU session triggering may be based on user equipment route selection (USRP) rules present on the WTRU 402. In the case where the WTRU 402 initiates the MASQUE connection through a UPF 414, the URSP rules may be enhanced to include QPOP configuration lEs. In this case, for example, the WTRU 402 may provide the QPOP configuration / setup lEs to the UPF 414 over the MASQUE connection, and / or the UPF 414 may provide the QPOP configuration / setup lEs to the AS 422. In examples, the UPF 414 may originate the MASQUE connection with the AS 422.

[0130] At 434, the AF / AS 422 may configure the QoS for the flow, for example, by sending an AF session with Required QoS request to a PCF 416 directly and / or through a network exposure function (NEF) 418. This AF / AS action may have been triggered by a session request from the WTRU 402. The request may identify the user plane traffic, which is QUIC-based (e.g., MOQ and / or ROQ traffic). The request may include AS address information to enable establishing a MASQUE connection to the AS 422 (e.g., AS FQDN and / or IP address and / or port). The AF / AS 422 may include QPOP configuration lEs to indicate that QPOP will be used to transmit PDU set information to the network.

[0131] At 436, once the traffic identification, AS address, QoS information, and / or QPOP configuration lEs are configured in the network, for example, in PCC rules in the PCF 416, the PCF 416 may transmit the QoS flow configuration information to the SMF 412 (e.g., through a SM policy association establishment and / or modification procedure).

[0132] At 438, the SMF 412 may transmit the traffic indication, AS address, QoS information, and / or QPOP configuration lEs to the UPF 414, for example, in an N4 session establishment and / or modification request.

[0133] In a scenario where the UPF 414 has a QPOP capability, the SMF 412 may check whether the current UPF 414 serving the PDU session supports the QPOP feature, and / or may, if it is not the case, perform UPF reselection.

[0134] In a scenario where the UPF 414 does not support a QPOP capability, and the SMF 412 decides to keep the same UPF 414 to serve the PDU session and decides that QPOP is not to be used for the PDU session, the SMF 412 may send a notification message to the PCF 416 which sends a message to the AF 422 via NEF 418, to inform them that the QPOP is not supported for this PDU session, and / or the AF session is (e.g., still) accepted.

[0135] At 440, the UPF 414 may configure a MASQUE proxy client for QUIC-aware proxying with AS 422 with PDU set support & QPOP (e.g., for negotiating QPOP and / or for QPOP parsing).

[0136] At 442, the UPF 414 may send an N4 session establishment and / or modification response indicating a successful operation.

[0137] At 444, the SMF 412 may (e.g., also) configure the RAN with one or more QoS profiles derived from the PCC rule.

[0138] At 446, the SMF 412 may provide one or more QoS rules derived from the PCC rules to the WTRU 402.

[0139] At 448, the WTRU 402 may send an initial end-to-end QUIC packet to the AS 422 (e.g., a QUIC client hello message to initiate a WTRU-AS QUIC connection to transport a MOQ and / or ROQ session). The initial end-to-end QUIC packet may be sent over the PDU session, through the UPF 414.

[0140] At 450, upon reception of the initial end-to-end QUIC packet, the UPF 414, based on the configuration (e.g., configured at 440), may establish a QUIC connection with AS 422. The UPF 414 may include (e.g., in the client hello message to establish UPF-AS QUIC connection) a QUIC transport parameter which may include QPOP setup lEs (e.g., QPOP indication / parsing parameters), to request using QPOP over this connection. The AS 422 may reply (e.g., in the server hello message) including a QUIC transport parameter which may include QPOP setup lEs (e.g., QPOP indication / parsing parameters) to indicate that the AS 422 accepts using QPOP and / or to provide QPOP parsing parameters determined by the AS 422. The QUIC transport established (e.g., typically) may include one or more additional messages between UPF 414 and AS 422.

[0141] At 452, the UPF 414 may send an HTTP CONNECT request which may include QPOP setup lEs (e.g., QPOP indication / parsing parameters), to request using QPOP over this MASQUE session.

[0142] At 454, the AS 422 may determine if it accepts to use QUIC-aware proxying with QPOP for PDU set information.

[0143] At 456, the AS 422 may send back an HTTP response which may include QPOP setup IBs (e.g., QPOP indication / parsing parameters), to accept using QPOP over this MASQUE session.

[0144] At 458, for example, the AS 422 and / or the UPF 414 may send to each other, over the MASQUE session, additional messages (e.g., CAPSULE messages and / or HTTP datagrams), which include QPOP indication / parsing parameters. For example, the AS 422 may send a CAPSULE message to the UPF 414 to include first-packet CID parsing parameters, each time another (e.g., new) CID is added to and / or removed by the AS 422 from the list of first- packet CID parsing parameters.

[0145] At 460, the UPF 414 may forward the end-to-end QUIC packet (e.g., received at 448), towards the AS 422, over the MASQUE session.

[0146] At 462, the end-to-end QUIC connection and / or end-to-end media session (e.g., ROQ and / or MOQ) may be established between the AS 422 and the WTRU 402, through the exchange of one or more (e.g., multiple) additional messages.

[0147] At 464, the AS 422 may generate a media PDU, may generate related PDU set information, may packetize and / or coalesce them in a UDP datagram, and / or may transmit the datagram. When packetizing the first QUIC packet (e.g., QUIC packet A), including PDU set information, the AS 422 may (e.g., must) respect the limitations associated with the QPOP parsing parameters (e.g., exact, or minimum length, packet / frame type, CID).

[0148] At 466, the AS 422 may send, towards the WTRU 402 through the UPF 414 over the MASQUE session, the coalesced UPD datagram, which may include a QUIC packet (e.g., QUIC packet A) including PS lEs and / or QUIC packet B including a DL media flow PDU.

[0149] At 468, the UPF 414 may use the QPOP parsing parameters to parse the received coalesced UDP datagram. The UPF 414 may decrypt QUIC packet A including the PS lEs and / or may use the QUIC packet A payload to identify the PDU Set information. The UPF 414 may overwrite the CID of the QUIC packet B (e.g., replace the virtual CID with the end-to-end CID, as per the QUIC-aware proxying method). The UPF 414 may be configured by the SMF 412 with information that indicates whether virtual CIDs should be used or not.

[0150] At 470, the UPF 414 may forward the QUIC packet B towards the WTRU 402, after adding a UDP header and an IP header, over a GTP-U tunnel to the RAN. The UPF 414 may set the PDU set information in the GTP-U header.

[0151] At 472, the RAN may apply PS QoS handling using the PDU set information in the GTP-U header.

[0152] At 474, the RAN may forward the QUIC packet B (e.g., over UDP over IP) towards the WTRU 402.

[0153] At 476, the WTRU application may (e.g., then) play the media data.

[0154] Different combinations of QPOP indications and / or parsing parameters can be exchanged in the procedure(s) described herein. In examples, one or more procedures, as described herein, may indicate that QPOP indication and / or parsing parameters may be included in configuration (e.g., at 434 through 440), QUIC connection establishment (e.g., at 450), MASQUE session establishment (e.g., at 452 through 456), and / or MASQUE session control (e.g., at 458). In one or more (e.g., some) systems, the QPOP indication / parsing parameters may be included in one or more (e.g., all) configuration / QUIC connection establishment / MASQUE session establishment / MASQUE session control. In one or more (e.g., other) systems the QPOP indication / parsing parameters may be included in a subset of the procedures, as described herein. In an exemplary system, QPOP indication and / or parsing parameter QUIC extension for QPOP may be included in the configuration steps; QPOP indication may be provided by UPF in QUIC connection establishment (e.g., as a QPOP transport parameter) and / or QPOP parsing parameter length may be provided by AS in the response message (e.g., as a value of the QPOP transport parameter); QPOP indication may be provided in MASQUE session establishment steps (to request / accept using QPOP on the MASQUE session); QPOP parameter CID may be provided by AS in CAPSULE message in MASQUE session control procedure. In one or more (e.g., other) exemplary systems, other combinations of QPOP indications and / or parsing parameters can be passed between AS / AF and UPF.

Claims

CLAIMS:

1. A user plane function (UPF) comprising: a processor configured to: receive a message from a session management function (SMF) that comprises an indication to initiate a proxied connection to an application server (AS) and an indication to parse metadata which is coalesced with media data on a same user datagram protocol (UDP) datagram; send a request message to the AS, the request message comprising an indication to support one or more of coalescing one round trip time (1-RTT) quick UDP internet connections (QUIC) packets, coalescing QUIC packets with different connection identifications (CIDs), or coalescing protocol data unit (PDU) set information and a media PDU, the request message comprising one or more parsing parameters; receive a UDP datagram from the AS; and parse the UDP datagram using the one or more parsing parameters to identify the PDU set information in the UDP datagram and identify a QUIC packet in the UDP datagram.

2. The UPF of claim 1 , wherein the QUIC packet is a first QUIC packet, and wherein the PDU set information in the UDP datagram is identified based on information in a second QUIC packet, and wherein the processor is further configured to forward the first QUIC packet with the PDU set information to a network.

3. The UPF of claim 2, wherein the second QUIC packet comprises the PDU set information and the first QUIC packet comprises the media PDU.

4. The UPF of claim 2 or 3, wherein the second QUIC packet is associated with an AS to UPF connection and the first QUIC packet is associated with an AS to wireless transmit / receive unit (WTRU) connection.

5. The UPF of any of claims 1 to 4, wherein the processor is further configured to receive the one or more parsing parameters from the SMF.

6. The UPF of claim 5, wherein the one or more parsing parameters are received in the message from the SMF.

7. The UPF of any of claims 1 to 6, wherein the processor is further configured to receive a response message from the AS, the response message comprising an indication of support for one or more of coalescing 1-RTT QUIC packets, coalescing QUIC packets with different CIDs, or coalescing PDU set information and the media PDU.

8. The UPF of any of claims 1 to 7, wherein the request message comprises one or more QUIC-aware proxying optimized for PDU set information coalescing (QPOP) setup information elements (IBs), and wherein the QPOP setup lEs indicate support of one or more of coalescing 1-RTT QUIC packets, coalescing QUIC packets with different CIDs, or coalescing PDU set information and the media PDU.

9. The UPF of any of claims 1 to 8, wherein the processor is further configured to configure a multiplexed application substrate over QUIC encryption (MASQUE) proxy client for QUIC- aware proxying with the AS.

10. The UPF of any of claims 1 to 9, wherein the one or more parsing parameters comprise information on coalescing that enables the first network node to parse the UDP datagram.

11. A method performed by a user plane function (UPF), the method comprising: receiving a message from a session management function (SMF) that comprises an indication to initiate a proxied connection to an application server (AS) and an indication to parse metadata which is coalesced with media data on a same user datagram protocol (UDP) datagram; sending a request message to the AS, the request message comprising an indication to support one or more of coalescing one round trip time (1-RTT) quick UDP internet connections (QUIC) packets, coalescing QUIC packets with different connection identifications (CIDs) or coalescing protocol data unit (PDU) set information and a media PDU, the request message comprising one or more parsing parameters; receiving a UDP datagram from the AS; and parsing the UDP datagram using the one or more parsing parameters to identify the PDU set information in the UDP datagram and identify a QUIC packet in the UDP datagram.

12. The method of claim 11 , wherein the QUIC packet is a first QUIC packet, and wherein the PDU set information in the UDP datagram is identified based on information in a second QUIC packet, the method further comprising forwarding the first QUIC packet with the PDU set information to a network.

13. The method of claim 12, wherein the second QUIC packet comprises the PDU set information and the first QUIC packet comprises the media PDU.

14. The method of claim 12 or 13, wherein the second QUIC packet is associated with an AS to UPF connection and the first QUIC packet is associated with an AS to wireless transmit / receive unit (WTRU) connection.

15. The method of any of claims 11 to 14, further comprising receiving the one or more parsing parameters from the SMF.

16. The method of claim 15, wherein the one or more parsing parameters are received in the message from the SMF.

17. The method of any of claims 11 to 16, further comprising receiving a response message from the AS, the response message comprising an indication of support for one or more of coalescing 1-RTT QUIC packets, coalescing QUIC packets with different CIDs, or coalescing the PDU set information and the media PDU.

18. The method of any of claims 11 to 17, wherein the request message comprises one or more QUIC-aware proxying optimized for PDU set information coalescing (QPOP) setup information elements (lEs) , and wherein the QPOP setup lEs indicate support of one or more of coalescing 1-RTT QUIC packets, coalescing QUIC packets with different CIDs, or coalescing PDU set information and the media PDU.

19. The method of any of claims 11 to 18, further comprising configuring a multiplexed application substrate over QUIC encryption (MASQUE) proxy client for QUIC-aware proxying with the AS.

20. The method of any of claims 11 to 19, wherein the one or more parsing parameters comprise information on coalescing that enables the first network node to parse the UDP datagram.

Images