Implementing XR service proxy

Abstract

Systems, methods, and instrumentalities are disclosed herein for implementing an augmented reality (XR) service broker. A first network node may receive a session request for a data session and a MOQ service from a WTRU. The first network node may determine a MOQ agent deployment, including a local agent and a network agent. Based on a network agent deployment, the first network node may determine a second network node for providing the MOQ service and a network MOQ agent. The first node may transmit a proxy setup message for requesting the network MOQ proxy and a session setup message for requesting a local MOQ proxy from the WTRU.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 338,727, filed on May 5, 2022, and U.S. Provisional Application No. 63 / 414,241, filed on October 7, 2022, the contents of which are incorporated herein by reference in their entirety. Background Art

[0003] Mobile communications using wireless communications continue to evolve. The fifth generation of mobile communications radio access technology (RAT) may be referred to as 5G New Radio (NR). The previous generation (legacy) mobile communications RAT may be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the invention

[0004] Disclosed herein are systems, methods, and means for implementing an extended reality (XR) service proxy. A first network node may receive a session request message from a wireless transmit / receive unit (WTRU), and the session request message may request a data session and request a media over QUIC (MOQ) service. The first network node may determine a MOQ proxy deployment for the MOQ service, and the MOQ proxy deployment may include a local proxy deployment and a network proxy deployment.

[0005] The first network node may determine a second network node for providing the MOQ service and providing a network MOQ agent based on the network agent deployment. The first network node may transmit an agent establishment message to the second network node, and the agent establishment message may request the second node to provide the network MOQ agent for the MOQ service. The network MOQ agent may support the data session.

[0006] The first network node may transmit a session establishment message to the WTRU based on the local agent deployment, and the session establishment message may request the WTRU to provide a local MOQ agent supporting the data session to communicate with the network MOQ agent.

[0007] The first network node may receive policy information from a third network node, and the policy information may include at least one of a Policy and Charging Control (PCC) rule or a session rule. The first network node may determine the MOQ proxy deployment using at least one of the PCC rule or the session rule.

[0008] The first network node may determine a capability of the second network node to support MOQ proxy functionality. The first network node may select the second network node based on the capability of the second network node.

[0009] The first network node may determine a capability of the second network node to support an MOQ extension, and the MOQ extension may include an extended reality (XR) service extension. The first network node may select the second network node based on the capability of the second network node.

[0010] The proxy setup message may be transmitted to the second network node using an N4 interface, and the proxy setup message may include at least one of a MOQ service flag or a MOQ proxy configuration information element.

[0011] The first network node may receive a session establishment response message from the second network node, and the session establishment response message may include MOQ proxy information. The MOQ proxy information may include one or more of a MOQ proxy IP address, a domain name, or a port.

[0012] The first network node may transmit the session establishment message to the WTRU, and the session establishment message may include the MOQ proxy information received in the session establishment response message from the second network node.

[0013] The first network node may receive network MOQ proxy information from the second network node in response to the proxy establishment message. A network MOQ proxy discovery method may be determined based on the network MOQ proxy information, and the network MOQ proxy discovery method may help the WTRU discover the network MOQ proxy. The first network node may further determine the capability of the second network node to provide the network MOQ proxy based on either a local configuration or a management plane message. The session establishment message may include a MOQ proxy information element.

[0014] The first network node may include a MOQ Proxy Information Element in the session establishment message transmitted to the WTRU. This may be done so that the first network node may act as a proxy for the WTRU.

[0015] Procedures that can be used to establish XR stream connectivity and enable XR services on these streams. XR streams can be transmitted between wireless transmit / receive units (WTRUs), user plane functions (UPFs), and / or application servers (ASs) over proxy connections. XR service information elements (IEs) can be associated with XR streams, protocol data unit (PDU) sets, and packets to enable the WTRU / UPF / AS and intermediate radio access network (RAN) and / or core network (CN) nodes to provide XR services using these IEs.

[0016] A procedure for establishing QUIC-based media (MOQ) connectivity over a secure MOQ relay may be provided, which may enable a network to provide XR support services. Embodiments herein may incorporate and / or provide a technique for mapping a PDU set descriptor message to a PDU transmitted over MOQ over a secure MOQ relay, and / or a technique for discovering and establishing communications over a MOQ relay deployed in a network and / or on a WTRU. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

[0018] Figure 1B is an example of a method that can be used according to an embodiment of the present invention. Figure 1A 0026] A system diagram of an example wireless transmit / receive unit (WTRU) for use within the communication system illustrated in FIG.

[0019] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of an example radio access network (RAN) and an example core network (CN) used within the communication system illustrated in FIG.

[0020] Figure 1D is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of another example RAN and another example CN used within the communication system illustrated in .

[0021] FIG. 2A to FIG. 2D An example data plane architecture that may be used for extended reality (XR) services (such as for XR services and / or for data packets) is shown.

[0022] FIG. 3A to FIG. 3E An example setup and operation procedure for an XR service is shown, which may be how an XR service is established and operated.

[0023] Figure 4 An example of protocol data unit (PDU) set selection is shown.

[0024] Figure 5A and Figure 5B An example procedure for QoS handling based on a PDU set based on MASQUE is shown. QoS can be handled using this method.

[0025] Figure 6 An example of a secure MOQ repeater model is shown.

[0026] Figure 7 An example of a deployment scenario for a secure MOQ repeater is shown.

[0027] FIG. 8A to FIG. 8C Example XR service operations through a secure MOQ repeater may be shown.

[0028] Fig. 9 An example representation of capsule messages to / from a secure MOQ repeater is shown.

[0029] Fig. 10A and Fig. 10B An example representation of a PDU transmitted over MOQ using a secure MOQ relay in Mode 1 is shown.

[0030] Fig.11 An example representation of a PDU transmitted over MOQ using a secure MOQ repeater in Mode 2 is shown.

[0031] Fig.12 An example MOQ repeater discovery and connection establishment procedure is shown. DETAILED DESCRIPTION

[0032] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0033] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 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 “STA”) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0034] The communication system 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 that is 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 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, an NR Node B, 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.

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

[0036] 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).

[0037] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, 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 use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. 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).

[0038] 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) that may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-APro).

[0039] 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).

[0040] 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 together implement LTE radio access and NR radio access, for example using the dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

[0041] 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), etc.

[0042] Figure 1AThe base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, 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 may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In 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 a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0043] 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 different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although not described in detail in the text, the CN 106 / 115 may be 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 different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Figure 1A Although not shown in the figure, 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 utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0044] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides 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), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired communication networks and / or wireless communication 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.

[0045] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication 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 via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to 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.

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

[0047] 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal decoding, 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. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0049] Although the transmit / receive element 122 Figure 1B 1 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, the WTRU 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.

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

[0051] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an 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 a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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 a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0052] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control 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., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0053] 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 from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0054] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules 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 electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (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, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: 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.

[0055] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both 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 for reducing and / or substantially eliminating self-interference via signal processing performed via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0056] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with 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.

[0057] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-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 evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0058] Each of the evolved Node 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 UL and / or DL, etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0059] Figure 1C The illustrated CN 106 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 is depicted as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0060] The MME 162 may be connected to each of the evolved Node-Bs 160a, 160b, 160c 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, etc. 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.

[0061] The SGW 164 may be connected to each of the evolved Node-Bs 160a, 160b, 160c in the RAN 104 via an 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 the user plane during inter-evolved Node-B handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

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

[0063] 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 be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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 other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.

[0064] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communication interface with a communication network.

[0065] In a representative embodiment, the other network 112 may be a WLAN.

[0066] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STA) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and leading to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be transmitted to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the destination STA (e.g., directly between them) using a direct link establishment (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0067] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send beacons on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may listen to the primary channel. If the primary channel is listened / detected and / 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.

[0068] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0069] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0070] 802.11af and 802.11ah support operating modes below 1 GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0071] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum 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 (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only the 1MHz operating mode) is sending to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

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

[0073] Figure 1D1 is a system diagram illustrating the RAN 113 and the CN 115 in accordance with an embodiment. As noted above, the RAN 113 may employ 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.

[0074] 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, the gNBs 180a, 180b may utilize beamforming to send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send 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, gNB 180a may transmit multiple component carriers to 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, 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).

[0075] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, 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 the gNBs 180a, 180b, 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths over time).

[0076] 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 a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the evolved Node-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the evolved Node-B 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0077] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0078] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0079] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 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 mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 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.

[0080] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0081] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the 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, etc.

[0082] 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 acts 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 other networks 112, which may include other wired networks and / or wireless networks 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 via an N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the local DN 185a, 185b.

[0083] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other device described herein. The simulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0085] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0086] References herein to a timer may refer to a time, a time period, tracking a time, tracking a time period, etc. References herein to expiration of a timer may refer to determining that a time has occurred or a time period has expired.

[0087] Extended reality (XR) applications, protocol data unit (PDU) aggregation and / or multimodal synchronization may be provided.

[0088] For XR applications on mobile networks, enhancements may be used to support advanced media services (e.g., high data rate, low latency services such as augmented reality (AR), virtual reality (VR), and / or XR services). These services may be designated as XR services and may be described as such herein. The enhancements may include one or more of: support for multimodal data streams (e.g., related audio, video, and tactile data); interaction between the system and applications for synchronization and QoS; QoS support for media unit granularity; uplink-downlink transmission coordination to meet round-trip time (RTT) latency; jitter minimization; or power saving enhancements. In an example, the WTRUs involved in an XR application session may access the mobile network, for example, via a device-to-device (D2D) link, via a relay WTRU. For example, a tethering may include an AR / VR glasses WTRU to a phone.

[0089] PDU sets may be defined to improve QoS handling of XR traffic. A PDU set may include one or more PDUs that carry a payload of an information unit (e.g., a frame and / or video segment for an extended reality and media (XRM) service) generated at the application layer. PDUs (including PDU sets) may be of equal importance (e.g., all of equal importance) at the application layer. In an example, the application layer may use the PDUs in the PDU set (e.g., all PDUs) to use the corresponding information unit. In an example, for example, if multiple PDUs in the PDU set are lost, the application layer may recover part of the information unit.

[0090] A fast UDP Internet connection (QUIC) and a multiplexed application layer (MASQUE) based on QUIC encryption may be provided. The MASQUE protocol may implement, for example, the use of a hypertext transfer protocol (HTTP) / 3 based on QUIC to configure and / or run multiple proxy streams in an HTTP connection. The MASQUE service may include a user datagram protocol (UDP) proxy and an Internet protocol (IP) proxy. In order to initiate a UDP proxy service, a client may, for example, transmit an HTTP CONNECT request to the proxy using a uniform resource locator (URL) such as https: / / masque.example.org / {target_host} / {target_port} / , where marsque.example.org may be a qualified domain name (e.g., a fully qualified domain name (FQDN)) that resolves to a MASCQUE proxy, where {target_host} may be a remote server FQDN or IP address, and where {target_port} may be a target UDP port on a remote server. The HTTP CONNECT may include a "connect-udp" service tag, for example, as a protocol pseudo-header value or an upgrade header value. Upon accepting such a request, the MASQUE proxy may begin forwarding UDP traffic between the client and the remote server. Data traffic between a client and a MASQUE agent may include packets containing an end-to-end UDP payload transmitted via a datagram associated with a stream used by a CONNECT request. The datagram may be an HTTP datagram or a CAPSULE message of datagram type, where CAPSULE may be a TLV-based protocol defined by HTTP / 3, HTTP / 2, and HTTP / 1.1 data streams. Data traffic may be sent over UDP / IP between a MASQUE agent and a remote server. Other services may be provided by the MASQUE agent. For example, an IP agent may initiate a CONNECT request with a connect-ip service tag.

[0091] Access Traffic Steering, Switching and Splitting (ATSSS) may be provided. The WTRU may be capable of accesses (e.g., both 3GPP accesses and non-3GPP accesses). This capability may provide flexibility to the network operator in determining which access is used for the service data flow. ATSSS may rely on establishing a multi-access (MA) PDU session in which traffic from the service data flow may be transmitted over an access (e.g., a 3GPP access, over a non-3GPP access, or over both accesses). ATSSS may rely on steering functionality logic to implement switching, steering, or splitting. The steering functionality (e.g., two steering functionalities) may include one or more of the following: Multipath Transmission Control Protocol (MPTCP) (e.g., which may be used for Transmission Control Protocol (TCP) traffic) and ATSSS-LL (e.g., which may be used for Ethernet traffic, TCP traffic, or UDP traffic). The steering functionality may be used to carry UDP traffic, Ethernet traffic, and other types of traffic over an MA-PDU session. These functionalities may include steering functionality based on the QUIC protocol (e.g., possibly including its multipath extensions) and / or steering functionality based on the DCCP protocol (e.g., possibly including its multipath extensions).

[0092] Differentiated Services Code Point (DSCP) can be used to set traffic handling policies in IP networks using a 6-bit field in the IP header. DSCP code points can be associated with per-hop behaviors (PHBs) in intermediate nodes (e.g., routers). One or more DSCP code points can be standardized, including support for best-effort traffic, guaranteed forwarding PHBs, and higher priority expedited forwarding traffic. In an example, a quarter of the DSCP code point space can be reserved for experimentation or local use.

[0093] XR services may be supported in a mobile network. How to identify and provide differential handling of packets of a PDU set may be provided. For example, the following may be provided: how the network identifies a packet as part of a PDU set, how the network determines the importance of a PDU set or the dependency of the PDU set on other PDU sets, how / where differential PDU set packet handling is performed (e.g., in a WTRU, a radio access network (RAN), and / or a user plane function (UPF)), what information may be provided to the WTRU, RAN, and / or UPF to perform the task, and / or how the information may be provided.

[0094] Features supported for XR services in a mobile network may be described, including traffic analysis / deep packet inspection (DPI) performed by the UPF and gNodeB (e.g., of a real-time transport protocol (RTP) header field) to classify data packets into PDU sets, and wherein a PDU set information element (IE) may be transmitted in an N3 encapsulation header (e.g., a GTP header). The PDU set classification may be performed by an application server (AS), and the PDU set IE may be provided by the AS to the UPF using a preconfigured AS-UPF tunnel. One or more of the following may be applied based on the features described herein. For PDU set classification, the PDU set classification may be performed in the gNodeB and UPF, and it may rely on DPI. Using DPI may be useful for supporting protocols such as RTP or secure RTP (SRTP) without requesting (e.g., without requiring) application layer adaptation for use on a system (e.g., a 5G system), which may facilitate initial adoption. Using DPI on the gNodeB and UPF may result in one or more of the following. In various cases (e.g., all cases), especially when the traffic may be encrypted (e.g., RTP over Datagram Transport Layer Security (DTLS), RTP over QUIC, or non-RTP protocols such as the Warp protocol over QUIC or the Reliable (Unreliable) Streaming Protocol (RUSH)), DPI may not be available on the gNodeB. Maintaining a DPI implementation to keep up with the evolution of XR protocols may be expensive.

[0095] One or more of the following may be applied based on the features described herein. In an example, integration may not be used between ATSSSs. This lack of integration may prevent or complicate path selection or packet scheduling decisions using the XR service IE. For example, in some settings, it may be useful to use one path with, for example, a low packet loss rate for I frames, while other paths may be used for less important PDU sets. A system (e.g., a 5G system) may provide features that interoperate with ATSSS features, including when higher layer ASSSSs (e.g., based on QUIC / DCCP) may be used.

[0096] Based on the features described herein, one or more of the following may apply. For preconfigured N6 tunnels, a set of preconfigured N6 tunnels between the UPF and a trusted 5G-XR application server (5G-XR AS) may be used and carry one or more IEs associated with a set of PDUs. This may include limitations such as not supporting untrusted ASs and / or preconfiguration of tunnels using Generic Routing Encapsulation (GRE) or GTP. A system (e.g., a 5G system) may provide features that enable dynamic establishment of a proxy connection to an application server that is trusted or untrusted by an operator (e.g., a 5G operator).

[0097] Based on the features described herein, one or more of the following may be applied to identify PDU sets, and the features described herein may enable PDU set marking on a per-packet basis. This overhead may ensure that network nodes (e.g., all network nodes) providing XR services have information (e.g., all necessary information) for knowing the number of packets, priority levels, and dependencies between PDU sets. A system (e.g., a 5G system) may implement PDU set marking while limiting per-packet overhead.

[0098] The features described herein may or may not cause the network to affect network nodes providing XR services when congestion may be detected. For example, a system (e.g., 5GS) may use L4S / ECN to affect applications that support the protocol and affect XR services even when the applications may not support L4S / ECN. A system (e.g., 5G system) may support L4S / ECN marking by the network, congestion control in XR services affected by L4S / ECN, and relaying of L4S / ECN signaling by XR services to support XR applications.

[0099] For the features described herein, a proxy connection may be established, for example, between a WTRU and a UPF to carry an XR flow. In an example, a chain of proxy connections may be established, for example, between a WTRU, a relay WTRU, an I-UPF, and / or a PSA UPF. Procedures for establishing such proxy connections while associating an XR service IE with an XR flow, a PDU set, and / or individual packets may be described.

[0100] Nodes (e.g., WTRU, UPF, relay WTRU, I-UPF, PSA UPF, gNodeB, gateway, and other RAN / CN nodes) may implement XR services using associated XR service IEs. XR services may include PDU set classification and marking, relaying of XR service markings, support functions for XR path selection, XR packet scheduling, XR congestion handling, and / or support functions for XR synchronization.

[0101] The XR proxy may be collocated with the UPF and / or other nodes (e.g., WTRU, UPF, relay UE, I-UPF, PSA UPF, gNodeB, gateway, and other RAN / CN nodes). The XR proxy may be referred to herein as a proxy. In examples where the proxy may be co-located with the UPF, the XR proxy may be referred to herein as UPF / proxy or UPF.

[0102] An XR proxy collocated with a function (e.g., such as a UPF) may be instantiated on the same node as the function (e.g., sharing computing resources with the UPF function), or may be instantiated on a node connected to the function (e.g., on a virtual network function (VNF) deployed in the same data center as the UPF function). The proxy may be described as being located on the UPF to indicate one form of collocation (e.g., any form of collocation).

[0103] One or more of the following may be applied based on the features described herein. An uplink PDU set may be marked by the WTRU (e.g., instead of by the gNodeB), which may enable support for encrypted XR streams and may enable the use of an access network (AN) (e.g., a non-3GPP access network). A downlink PDU set may be marked by an AS (e.g., a non-legacy AS) instead of a UPF, which may enable support for encrypted XR streams. When DPI is valuable, DPI may be supported (e.g., to support legacy AS). A UPF proxy (e.g., QUIC-based or DCCP-based) may be used to provide ASSSS services and XR services, which may enable combining ATSSS IEs and XR service IEs during path selection and packet scheduling. Combining ATSSS and XR services may reduce the cost of implementing an XR proxy-based mechanism, for example, through code reuse, as described herein. In a MASQUE-based proxy feature such as described herein, the UPF / agent may authenticate the AS (e.g., a non-legacy AS) before transmitting a MASQUE CONNECT request to the AS, which may establish (e.g., dynamically establish) a proxy connection / tunnel to the AS. Network-based authentication techniques may be used as building blocks to establish trust between WTRU applications, operators (e.g., 5G operators), and / or AS operators based on a trust model. Tunnel establishment may be dynamic. The XR service IE described herein may be associated by stream, by PDU set, and / or by packet. The set of XR service IEs per packet may be streamlined to the minimum set used by the intermediate node application XR service. Other XR service IEs may be exchanged at a lower rate through a proxy connection between, for example, the WTRU and the UPF, and XR services may be implemented by the WTRU / UPF / AS. This may reduce the per-packet overhead from the XR service IE and / or minimize the overhead. Congestion markings (e.g., ECN or L4S) may be set by intermediate RAN / CN nodes on the outer header of packets transmitted between the WTRU and the UPF. The tag may be used by the WTRU / UPF to apply the XR service and / or may be relayed to the application.

[0104] Provides an overview of the data plane architecture.

[0105] FIG. 2A to FIG. 2D An example of a data plane architecture for XR services (including XR services and data packets) is shown.

[0106] An XR application session may be established between an XR WTRU application (WTRU app) and an XR AS located in a data network (DN). The XR WTRU app / AS may implement the XR application logic and transmit / receive media streams. The XR WTRU app / AS may handle congestion feedback from the network (e.g., ECN or L4S). The XR WTRU app / AS may support the XR services described herein, such as classification and marking of PDU sets. An XR WTRU app / AS that does not support the XR services described herein (e.g., any XR services) may be referred to as a legacy XR WTRU app / AS.

[0107] Can provide multiple functions. For example, FIG. 2A to FIG. 2D As shown, the functionality may include an AS hosting an XR application and a WTRU hosting an XRWTRU application. An XR WTRU app and an XR AS may be involved in an application session (e.g., transmitting and receiving XR streams as part of the application session). Although there may be a single WTRU and AS in this setup, in other setups, multiple WTRUs and / or ASs may be involved in an application session. The XR services described herein may be applied to multiple XR streams to / from multiple WTRUs (e.g., multi-modal multi-device synchronization). A non-legacy WTRU app and AS may provide XR services as described herein.

[0108] XR streams may be video / audio / haptic / object service data streams that include XR application sessions and are subject to XR services performed by the mobile network. XR streams may be sent via single access and / or multi-access PDU sessions between the WTRU and UPF and via the N6 interface between the UPF and AS. In other settings (e.g., FIG. 2A to FIG. 2D In an example (not shown), the XR streams may be sent via a device-to-device link (e.g., via a PC5 reference point) between a WTRU (e.g., AR glasses) and a relay WTRU. The SMF may be used to handle signaling (e.g., all signaling) for a given XR application session. In an example, handling the XR streams (e.g., all XR streams) for a given XR application session may involve a single UPF. In an example, for example, involving multiple distributed WTRU / AS, multiple UPFs may be involved and these UPFs may use coordination. For example, synchronization of XR streams involving multiple UPFs may use one UPF, which is designated as a synchronization server and exchanges timing information with other UPFs to implement XR synchronization services.

[0109] In this architecture, for example, a proxy in the UPF and relay UE may be used to send XR streams via a tunnel through a proxy connection. The proxy may be located in the UPF or the relay WTRU. The proxy may be used to implement XR services. The XR stream may be carried via a proxy connection (e.g., between a WTRU and a UPF) or a chain of proxy connections (e.g., between a WTRU, a relay WTRU, and a UPF, such as between a WTRU app, a WTRU, and a UPF). In an example, the proxy connection mechanism may be a MASQUE-based tunnel, which is based on HTTP / 3, which is based on QUIC. In an example, the proxy connection may use an HTTP-based tunnel, which is based on DCCP. Other proxy connection mechanisms may be used to implement the procedures described herein.

[0110] The proxy client and proxy server connection management functions may handle a single connection or multipath connections and may exist in the WTRU, UPF, and intermediate nodes such as relay WTRUs and / or I-UPFs. Other UPF / WTRU functions may be grouped in a traffic management function that directs traffic to and from lower layer functions such as the client / server proxy connection management function. XR services may be performed in the traffic management function and / or may be performed in the proxy connection management function.

[0111] XR services may be provided by RAN and core network (CN) functions (including WTRU, UPF, gNodeB, and gateway) to support QoE of XR application sessions. FIG. 2A to FIG. 2D The XR services may be assigned to the traffic management function and the proxy connection management function. For example, XR services that are applicable to multiple streams concurrently (e.g., inter-stream synchronization support) may be performed in the traffic management function, while other XR services such as PDU set marking or intra-stream synchronization support may be performed in the proxy connection management function. The XR services may be implemented by different nodes / functions.

[0112] like FIG. 2A to FIG. 2DAs shown, XR stream packets may be provided. While representing RTP packets, XR streams may use other protocols such as DASH, RUSH, WARP, RTP based on DTLS, RTP based on QUIC, SRTP, etc. Legacy AS and WTRU apps may exchange RTP packets directly with the WTRU / UPF, while non-legacy AS and WTRU apps may use another means to convey PDU set markings, such as using MASQUE encapsulation. XR stream packets between the WTRU and the UPF may use MASQUE encapsulation in the PDU set descriptor (e.g., RTP data packets may be encapsulated in HTTP / 3 datagrams associated with the XR service IE per PDU set XR service IE). When establishing a stream, the per-stream XR service IE may be communicated, for example, between the WTRU and the UPF. In order to enable intermediate RAN / CN nodes to apply XR services, one or more XR service IEs (e.g., per-packet XR service IEs) may be arranged in an outer IP header, for example, using DSCP and / or PDU set IP options (e.g., PSO).

[0113] In the case where XR traffic may be encrypted by the application, non-legacy WTRU applications and AS may perform XR services such as PDU set classification and provide per-XR flow IEs and per-PDU set IEs to the WTRU / UPF, for example using MASQUE as described herein. The WTRU / UPF may use the XR Service IE provided by the WTRU app / AS to provide other XR services, including per-packet XR Service IE marking. Other RAN / CN functions may provide XR services using per-packet XR Service IEs (e.g., DSCP and IP header options) or by collocation with functions providing XR proxy (e.g., gNodeB collocated with I-UPF).

[0114] XR services may be provided. XR services may be used herein to specify services provided by, for example, a mobile network to support QoE of XR and other applications. XR services provided by the WTRU / UPF / SMF / AS may include PDU set classification and marking, support functions for XR path selection, XR packet scheduling, XR congestion handling and / or XR synchronization.

[0115] PDU set classification and marking may be provided. The WTRU / UPF / AS may determine the application data content and / or boundaries belonging to different PDU sets, which may be associated with PDU set priorities. PDU set classification may be based on application logic (for example, the AS and WTRU app may associate each I frame, P frame, and B frame with a different PDU set, and / or the AS and WTRUapp may associate segments of a video frame with different PDU sets). Legacy applications may be supported that do not support PDU set classification. The WTRU / UPF may perform DPI, for example, using RTP header fields or other IEs present in the packet to determine the boundaries of the PDU set. Once the classification may be performed, the WTRU / UPF / AS may perform per-PDU set marking of the PDU set IE as described herein. As described herein, the WTRU / UPF / AS may mark each packet with a per-packet XR service IE to enable the network to provide XR services.

[0116] Relaying of XR service markings between applications and the network may be performed. For example, the AS (e.g., the corresponding WTRU application) may perform per-PDU aggregate marking, and the UPF (e.g., the corresponding WTRU) may mark each packet with a per-packet XR service IE based on the per-PDU aggregate marking.

[0117] Support functionality for XR path selection, XR packet scheduling, and XR congestion handling may include actions such as reordering packets, dropping packets, marking packets for congestion (e.g., L4S or ECN), and / or determining whether to transmit packets via one path or multiple paths. Congestion marking of packets may be performed when forwarding queue buffer utilization reaches a threshold (e.g., L4S marking) or when congestion is being experienced or expected (e.g., ECN marking). The selection of packets for congestion marking, dropping, and / or reordering may be determined using XR service IEs (including XR stream ID, XR stream priority, XR application session ID, XR application session priority, PDU set sequence number, PDU set priority, and / or parent PDU set sequence number). The operation may be based on other IEs, such as loss of packets in a PDU set (e.g., an incomplete PDU set) or its parent PDU set. The WTRU / UPF / AS may request a remote peer to stop transmitting a PDU set (e.g., if the PDU set cannot be used by an application because its parent PDU set was not completely received, or may be unusable for other reasons). The parent PDU set may be a set of PDUs available for reception by an application. In order to enable a PDU set (e.g., a child PDU set) to be used by an application, to this end, the WTRU / UPF / AS (e.g., any WTRU / UPF / AS) may transmit a CLOSE_PDU_SET(ID) message, as described herein, wherein an ID (e.g., a context ID) may identify the PDU set to stop transmitting. The remote peer may stop transmitting packets of the PDU set based on reception. In an example of integration with ATSSS, the WTRU / UPF may select a path for transmitting packets based on an XR service IE. The ATSSS bootstrap mode may be described using the XR service IE to determine path selection (e.g., transmitting packets from a PDU set of a specified priority on a path with the lowest packet loss rate).

[0118] Support functionality for XR synchronization may include, for example, one or more of the following: supporting inter-modal QoE (e.g., adapting the QoS of the stream and, if necessary, applying local delays to some packets to reduce and / or minimize inter-modal delay and minimize jitter); measuring RTT and jitter for reporting to the application; or using XR service IE and / or transport protocol latency estimates to obtain latency measurements, and providing latency measurements to the SMF, which updates the QoS of the UL and DL streams to meet the round-trip delay (e.g., round-trip delay requirements).

[0119] XR services may be provided on RAN / CN nodes. The support functions for XR path selection, XR packet scheduling, XR congestion handling and / or XR synchronization described herein may be performed in a WTRU and / or a RAN / CN node (such as a gNodeB and an I-UPF). The RAN / CN node may use, for example, a per-packet XR service IE in an IP header to identify packets associated with a PDU set and apply the associated XR services. The WTRU or RAN node may use the XR service IE to make a transmission decision. For example, if the WTRU or RAN node determines that the transmission of data from a first PDU has failed (e.g., HARQ feedback indicates that the transmission was unsuccessful), the WTRU or RAN node may determine not to attempt to retransmit the failed first PDU and / or to send other PDUs associated with the same PDU set or other PDU sets (the XR service IE indicates that it is related or associated with the first PDU). The decision not to attempt to retransmit the failed PDU and / or to send the associated PDUs may be made by the WTRU or RAN node based on the XR service IE associated with each PDU set (e.g., PDU set type and / or PDU set priority). In an example, when an XR service IE is sent in the UL indicating one or more PDUs related or associated with a PDU set, the WTRU may determine a forwarding configuration (e.g., a radio bearer configuration) to be applied at the access layer. If the WTRU applies a forwarding configuration when sending a first PDU in the UL, the WTRU may apply the same or similar forwarding configuration for a second PDU associated with the first PDU indicated by the XR service IE. In an example, the WTRU may provide assistance information to the RAN node using a per-stream XR service IE and / or a per-PDU set XR service IE. The RAN node may use the assistance information and the per-packet XR service IE to make scheduling decisions or change the WTRU access layer configuration. For example, based on the per-stream XR service IE and / or the per-PDU set XR service IE, the WTRU may determine that a particular PDU set may no longer be used (e.g., needed). The WTRU may make this decision based on timing (e.g., the PDU reception may be too late to be used by the application and / or the jitter of the PDU reception may be too high for the application) or based on the failure to receive an associated PDU set (such as a parent PDU set). The WTRU may provide an indication to the RAN node of a set of PDUs that may no longer be used (eg, needed). The WTRU may provide the indication via an RRC message, a MAC control element, or via uplink control information (UCI).

[0120] The XR services on the WTRU / UPF / AS may be performed by different WTRU / UPF / AS components. For example, the AS (e.g., the corresponding WTRU application) may perform PDU set classification and marking, while the UPF (e.g., the corresponding WTRU) may perform relaying of the XR service marking. In the example, the UPF / WTRU may perform both XR services.

[0121] XR service IEs may be provided. XR service IEs may be IEs that implement XR services as described herein from a system (e.g., a 5G system). These IEs may be associated with streams, PDU sets, and / or packets.

[0122] The per-stream XR service IE may be applied to XR streams and implement the XR service functionality described herein. The per-stream XR service IE may be provided, for example, by the WTRU when establishing a proxy session for a given XR stream. For example, this may be a CONNECT (e.g., an extended HTTP CONNECT) message transmitted to establish a MASQUE session or an initialization message transmitted over a created proxy data stream. When provided in a CONNECT request, the per-stream XR service IE may be encoded as an HTTP header. The per-stream XR service IE may include one or more of the following: an XR application session ID, which identifies a session for providing prioritization, scheduling, and synchronization of a range of streams, packets, and PDU sets; an XR application session priority, which provides a priority for inter-session prioritization to prioritize between streams belonging to different application sessions with the same stream priority; an XR stream ID, which identifies the stream for applying the XR service on the stream (e.g., the ID may be provided by the mobile network and / or it may be a PDU session ID); an XR stream priority, which provides a priority for inter-stream prioritization priority; data type (e.g., audio, video, haptic, data), which can be used for inter-stream synchronization to determine acceptable synchronization delays between streams; an XR synchronization group ID, which indicates which streams of an application session can be synchronized with each other; an applicable XR service list, which indicates which XR services (e.g., including the XR services described herein) can be applied to the XR stream; or a PDU set sequence number space declaration, which defines a number space that can be used, for example, by the WTRU / UPF to generate PDU set sequence numbers, and associates each PDU set IE with a number space (e.g., per number space). For example, this can be used to associate a PDU set priority and / or data type with a number space. An example of HTTP header encoding is provided herein: pdu-sets:< <range="1-10000";prio=5;type="audio",range="10001-20000";prio=6;type="haptic",range="20001-30000";prio=7;type="video"> >

[0123] The per-PDU-set XR service IE may be applied to a PDU set (e.g., a specific PDU set) and may implement the XR service functionality described herein. The per-PDU-set XR service IE may be provided, for example, by the WTRU / AS / UPF along with the PDU set. For example, the per-PDU-set XR service IE may be transmitted in a PDU set descriptor, which may be sent using, for example, a PDU_SET_DESCRIPTOR message as described herein, which is transmitted on a stream (e.g., a reliable stream), a dedicated datagram (e.g., a dedicated unreliable datagram), and / or on an unreliable datagram (e.g., a first datagram) containing PDU set data. When arranged in a dedicated datagram or stream, a packet containing a per-PDU-set XR service IE may be transmitted with enhanced reliability, for example by marking the packet with a high priority / reliability DSCP code point. The recipient may associate a PDU set descriptor with a PDU set by arranging an ID (e.g., a context ID) in both the PDU set descriptor and the PDU set, as described herein. In an example, a PDU set descriptor may be included in the first PDU in a PDU set or in the first K PDUs in a PDU set without using a PDU_SET_DESCRIPTOR message. The per-PDU set XR service IE may include one or more of the following: an IE described herein as a per-stream XR service IE (e.g., any IE) may be applied per PDU set (e.g., in the case where multiple data types are transmitted within the same XR stream, the data type may be associated with a PDU set); a PDU set priority that enables prioritization between PDU sets within the same stream or between multiple streams (e.g., between multiple streams belonging to the same application instance); a PDU set type that enables associating domain-specific meanings with PDU sets (e.g., I frames, P frames, and / or B frames and PDU set types may be useful for providing the following XR services: a PDU set of a selected type may require specially processed XR services ; PDU forward error correction (FEC) parameters, including the FEC algorithm and its parameters (e.g., which may be used by the WTRU / UPF / AS to recover lost packets in a PDU set protected by FEC); a PDU set sequence number, which uniquely identifies a PDU set within a PDU session, XR stream, or XR application session; a PDU parent set sequence number, which identifies a parent PDU set that may be requested (e.g., required) to be received by an application so that a PDU set (e.g., a child PDU set) may be used by the application; a PDU set length, which may be the total number of packets (e.g., or octets) in the PDU set; or timing IEs, such as a media unit timestamp, a presentation timestamp, a transmission timestamp, an accumulated send delay, and / or a PDU synchronization ID.The PDU Sync ID may identify a group of interrelated PDUs that may be presented to a user in close time within the same stream (e.g., a set of frames that may be presented to a user simultaneously in a multi-screen setup) or between different streams (e.g., a video PDU that may be presented to a user along with a haptic PDU).

[0124] A per-packet XR service IE may be applied to a specific packet and implement the XR service functionality described herein. The per-packet XR service IE may be encoded in a variety of ways in an outer IP (e.g., possibly, and UDP using UDP options) header. In an example, the PDU aggregate priority may be encoded using a DSCP code point in an outer IP header, and / or the per-packet XR service IE may be encoded using an IP header extension (e.g., using a PDU aggregate IP option as described herein). In order to limit per-packet overhead, the size of the per-packet XR service IE may be limited as much as possible while enabling XR services to be provided by the network. For example, the per-packet XR service IE may be limited to a PDU aggregate priority and a PDU aggregate sequence number LSB. Per-packet XR service IEs may include one or more of the following: an IE (e.g., any IE) described herein as a per-stream / per-PDU set XR service IE may be applied per packet; a PDU set first packet flag IE and / or a last packet flag IE may be used to mark the first and last packets of a PDU set; a PDU sequence number that identifies (e.g., uniquely identifies within a PDU set) a PDU; or a subset (e.g., any subset) of per-stream / per-PDU set / per-packet XR service IEs that may be used per packet. For example, if such a subset may be provided by the network for XR services, the n (e.g., 8) least significant bits (LSBs) of the PDU sequence number and / or the PDU set sequence number may be set per packet to limit overhead. In this case, if IE wraparound occurs at sufficiently long intervals, using an IE based on 8 LSBs of the PDU sequence number may be sufficient, depending on the maximum PDU set rate and the design of the XR service.

[0125] Establishment and / or operation of XR services may be provided.

[0126] FIG. 3A to FIG. 3E An example setup and operation procedure of an XR service is shown. FIG. 3A to FIG. 3E As shown, a procedure for establishing and operating services on XR streams in an XR application session can be provided. The procedure can use the XR service IE and XR service described herein.

[0127] At 1, the WTRU app may decide to request XR services for one or more XR streams. For example, the WTRU app may have previously established an application session with the AS (e.g., via non-XR streams). The WTRU app may initiate communication with the AS (e.g., open a socket) for the XR streams, which triggers the techniques for PDU session establishment and modification requests as described herein.

[0128] At 2, the WTRU may transmit a PDU session establishment / modification request (e.g., an XR service request or a DNN / S-NSSAI combination, which indicates to the network that this may be a PDU session for an XR service and / or an XR application session ID) to the SMF, for example, via the AMF. The AMF may select the SMF based on the XR application session ID, for example to ensure that the SMF (e.g., a single SMF) handles the XR flows (e.g., one or more XR flows) within an application session (e.g., the same application session). The XR service request IE or DNN / S-NSSAI combination may be a flag indicating that XR services may be requested globally for the flows (e.g., or one or more eligible flows) of the PDU session, or may be a flag that exists individually for a service data flow (e.g., a service data flow) for which XR services may be requested. If the XR service request may be a global flag, the eligibility of a flow for XR services may be determined, for example, by the SMF using Policy Charging and Control (PCC) rules (e.g., for each Service Data Flow (SDF) in a PDU session, the SMF uses the XR service flag in the PCC rules associated with the SDF or other IEs such as the protocol type to determine whether the XR service is applicable to that flow). The XR Application Session ID IE may identify an application session. An application session may provide a range of XR services. For example, the UPF may implement priorities between XR flows within a given application session, for example to provide a higher priority to an audio stream than a video stream.

[0129] At 3, the SMF may determine to associate a flow with an XR service based on the PDU Session Establishment / Modification Request IE. It may also be based on (e.g., XR service request and / or XR application session ID), PCC rules and / or application policies. The SMF may select a UPF based on the XR application session ID. For example, the purpose of doing this may be to ensure that a single UPF or a limited number of UPFs can be used to handle the flows of an application session.

[0130] At 4, the SMF may transmit an N4 session establishment / modification request to the UPF, including instructions to use the XR service for the XR flow determined herein. For example, the instruction to use the XR service may be XR control information obtained, for example, from a PCC rule. The XR control information may include one or more of the following IEs: a list of applicable XR services, including PDU set classification and marking, relaying of XR service markings, support functions for XR path selection, XR packet scheduling, XR congestion handling, and / or support functions for XR synchronization; or parameters of the XR service, including the arrangement of the XR service (e.g., an indicator of whether the AS or UPF performs PDU set classification and marking), XR service IEs (e.g., application session IDs to which the XR service can be applied), and / or synchronization (e.g., synchronization requirements, such as acceptable timing delays or timing delay categories between different types of streams (such as audio / video / haptic)).

[0131] At 5, the UPF may create or select multiple XR proxy instances. The UPF may assign a link-specific address or prefix for XR services to the WTRU. The link-specific address or prefix for XR services may be used by the WTRU to obtain an IP address, which the WTRU may use as a source address to communicate with the XR proxy.

[0132] At 6, the UPF may configure traffic management and XR proxy instances for XR services. The XR proxy instance may, for example, listen for incoming connections on an IP address and UDP or DCCP port that may be configured by the UPF. The XR proxy instance may handle one or more streams from one or more application sessions. In this case, the UPF may configure an XR proxy to accept a connection from the WTRU over a PDU session and handle the XR streams (e.g., all XR streams) of the PDU session over the connection. In cases where QUIC-based or DCCP-based ATSSS may be used, the same QUIC / DCCP proxy instance may be used for XR and ATSSS services. In this case, the UPF may configure a proxy for joint XR and ATSSS services, which may enable path selection and packet scheduling to be performed based on XRIE and ATSSS IE.

[0133] In an example, in a deployment where UPF and XR proxy are deployed separately, SMF can configure UPF and XR proxy independently. SMF can configure traffic management and XR proxy instances for XR services.

[0134] At 7, the UPF may transmit an N4 session establishment / modification response (e.g., including a link-specific address / prefix for the XR service and XR proxy information) to the SMF. The XR proxy information may provide IEs used (e.g., required) by the WTRU to connect to the XR proxy. The XR proxy information may include a proxy protocol (e.g., UDP and / or DCCP), an IP address and port, and / or an FQDN. The XR proxy information may include IEs associated with the proxy, such as a synchronization group ID (e.g., indicating that the associated proxy performs synchronization for the group), a flag indicating that the proxy may or may not support a particular XR service, and / or other XR service IEs (e.g., application session IDs) that may be matched by the XR flow using the proxy. These IEs may enable the WTRU to select applicable proxy information from multiple XR proxy information IEs provided by the UPF. There may be more than one XR proxy information IE, for example, to identify multiple proxies on the UPF. In an example, multiple proxies may be provided to enable the WTRU to associate flows from different XR application sessions with different proxies. In an example, multiple proxies may be provided to enable the WTRU to associate flows that use (e.g., require) a given set of XR services with a proxy that provides that set of XR services. In an example, multiple proxies may be provided to enable the WTRU to associate flows that may be synchronized with each other (e.g., may need to be synchronized with each other) with a proxy dedicated to their synchronization group. In this case, the WTRU may later dynamically change the proxy used for the XR flow, for example when the XR flow becomes part of a new synchronization group. To perform this action, the WTRU may connect to a second proxy associated with the synchronization group ID and establish a second XR flow session towards the AS through the second proxy, as described in the XR flow establishment request. The WTRU may begin forwarding XR flow packets through the second XR flow session and close the first XR flow session.

[0135] At 8a, the SMF may transmit a PDU Session Establishment / Modification Response to the WTRU via the RAN. The PDU Session Establishment / Modification Response may include a link-specific address / prefix for the XR service, XR proxy information, and / or XR service IE, etc.

[0136] At 8b, RAN nodes (e.g., gNodeBs) may use the XR Service IEs to configure the XR services they provide (e.g., associating PDU sessions and / or individual QoS flows and / or service data flows to applicable XR service lists, sync group IDs, XR application session IDs, and / or other XR Service IEs.

[0137] At 8c, the PDU Session Establishment / Modification Response message may include the configuration information XR Service IE. This may include an applicable XR service list, a synchronization group ID, and / or an XR application session ID.

[0138] The WTRU may locally configure a link-specific address or prefix for the XR service at 9. It may create, select or manage an XR proxy client instance as well as WTRU traffic management and XR proxy client instances.

[0139] At 10, the WTRU may establish a connection with the UPF / Proxy, where the UPF / Proxy specifies an XR Proxy on the UPF and / or another component of the UPF. The WTRU may connect to the UPF / Proxy. It may use an address derived from the Link Specific Address / Prefix for the XR Service IE as the source IP address. The WTRU may connect to the UPF / Proxy using the destination IP address, port, and protocol obtained from the XR Proxy Information IE. For example, the WTRU may establish a QUIC-based HTTP / 3 connection. It may establish this connection with the UPF / Proxy.

[0140] An XR streaming session may be established between the WTRU and the UPF / Proxy. The XR streaming session may be a tunnel that associates an XR streaming data stream with a per-stream, per-PDU set, and per-packet XR service IE. The XR streaming session may be, for example, a MASQUE session, which may be initiated by a client transmitting a MASQUE request (e.g., an HTTP CONNECT request) to the proxy. When connected to a legacy AS, the streaming session may terminate at the UPF / Proxy, or if the AS may be a non-legacy AS (e.g., supporting XR services as described herein), the streaming session may reach the AS through a chain of proxy connections (e.g., WTRU to UPF and UPF to AS).

[0141] At 11, the WTRU may transmit an XR stream session establishment request (e.g., including an XR stream session ID, an AS IP address / port, and / or a per-stream XR service IE) to the UPF / agent. For example, the message may be an HTTP-based MASQUE service request (e.g., an extended HTTP CONNECT request with a connect-udp protocol field). Such a request may include the IP address and UDP port of the AS to inform the UPF / agent where to forward the traffic transmitted through the proxy connection. In an example, the message may be a CONNECT request with a connect-ip protocol field or a DCCP-based CONNECT request or another type of tunnel establishment request. The XR stream session ID may be an ID that is unique within the scope of the connection. In a specific implementation based on MASQUE, the HTTP / 3 stream ID used for the CONNECT request may be used as the XR stream session ID. The per-stream XR service IE described herein may be provided by the WTRU, for example, encoded as an HTTP header field in a CONNECT request. In an example, the UPF / agent may transmit an XR stream establishment request to the WTRU to configure the stream.

[0142] At 12a, in the case where the AS may be a legacy XR AS, the UPF / Proxy may open a (for example) UDP socket towards the AS and configure itself to forward traffic between the AS and the proxy connection to the WTRU. The UPF / Proxy may configure itself to use DPI, for example to perform PDU set classification. In this case, the procedure may jump to the UPF proxy update performed as described herein.

[0143] In the event that the AS supports XR services as described herein, the UPF / Proxy may perform one or more of the following. At 12, the UPF / Proxy may transmit an XR stream session establishment request (e.g., XR stream session ID, AS IP address / port, and / or per-stream XR service IE) to the AS. The message may use the same protocol and parameters as in the XR stream establishment request (e.g., MASQUE service request using CONNECT) as described herein. Proxy chaining (e.g., WTRU to relay WTRU to I-UPF to PSA-UPF to AS) may be used in this manner.

[0144] At 13 , the AS may update its configuration of the XR service for the application session using the per-stream XR service IE.

[0145] At 14, the AS may transmit an XR streaming session establishment response to the UPF / proxy indicating success or failure of the operation. In an example, a feature (eg, another tunnel feature) may be established for transmitting XR service IEs associated with the PDU between the AS and the UPF.

[0146] At 15, the UPF / Proxy may update its configuration of the XR service for the application session using the per-stream XR service IE. For example, the UPF / Proxy may associate an XR stream (e.g., each XR stream) with a corresponding per-stream XR service IE (including the XR application session ID and the list of XR services that apply to that stream). The UPF / Proxy may configure a list of XR streams that are allowed to be proxied for the proxy (e.g., each proxy).

[0147] At 16, the UPF / Proxy may transmit an XR Streaming Session Establishment Response to the WTRU indicating success or failure of the operation.

[0148] In an example, the methods and / or processes described herein may be performed while an XR streaming session is open.

[0149] The WTRU and / or WTRU application may mark the PDU sets and groups with the XR Service IE at 17. The WTRU application may apply the XR service based on the XR Service IE.

[0150] At 18, the RAN / CN node (e.g., gNodeB) may apply the XR service based on the per-packet XR service IE.

[0151] The AS / UPF may mark the PDU sets and packets with the XR service IE at 19. The AS / UPF may apply the XR service based on the XR service IE.

[0152] At 20, the PDU set descriptor and data packets of the XR flow may be encapsulated in a proxy connection (e.g., in a MASQUE tunnel between the WTRU and the UPF / proxy) and sent, switched, directed or diverted via a PDU session between the WTRU and the UPF / proxy.

[0153] The XR stream may be forwarded by the UPF / proxy to / from the AS at 21. This may be done with or without encapsulation, depending on whether any XR stream session establishment request, AS update, or XR stream establishment response is performed.

[0154] A PDU set may be sent. At 22, a PDU set may be transmitted in the downlink by a non-legacy AS or by a UPF. In this case, the UPF or AS may perform PDU set classification and transmit a PDU set descriptor message, for example, in an HTTP datagram (e.g., an unreliable HTTP datagram) or a CAPSULE message over a reliable stream, including a per-PDU set XR service IE. The UPF / AS may transmit PDU set data packets, for example, in an HTTP datagram (e.g., an unreliable HTTP datagram). The network / CN node (e.g., RAN) and the WTRU may read the per-packet XR service IE in the header (e.g., IP header) and apply the XR service to the PDU using the XR service IE. The XR service may include packet prioritization, synchronization, and / or jitter adjustment. The network / CN node (e.g., RAN) may apply the XR service using a per-stream XR service IE or a per-PDU set XR service IE provided by the WTRU. The WTRU may transmit a per-stream XR service IE or a per-PDU set XR service IE to the RAN node so that the RAN node may apply the XR service to the PDUs in the PDU set. For example, the WTRU may transmit a per-stream XR service IE or a per-PDU set XR service IE to the RAN node via an RRC message. In an example, the WTRU may transmit a per-stream XR service IE or a per-PDU set XR service IE to the RAN node in a UL MAC CE or UCI. In an example, the WTRU may be configured via RRC to report a per-stream XR service IE or a per-PDU set XR service IE to the RAN node periodically and / or based on an event trigger (e.g., when a change in any information / parameter carried in the XR service IE or associated with the XR service IE is detected). The network / CN node (e.g., RAN) may apply the XR service using the per-stream XR service IE or per-PDU set XR service IE provided by the UPF. The WTRU / UPF / AS may determine the message type (e.g., descriptor or data packet) and that they are related to the same PDU set (e.g., one or more are related to the same PDU set). In a MASQUE-based implementation, this may be achieved by using a context ID of the MASQUE. The MASQUE may enable an endpoint (e.g., an endpoint) to generate a unique context ID. Data packets of a PDU set (e.g., one or more data packets) may be transmitted using the same, unique and / or context ID. If a PDU set descriptor is transmitted using a PDU_SET_DESCRIPTOR CAPSULE message (e.g., a reliable PDU_SET_DESCRIPTOR CAPSULE message), the PDU_SET_DESCRIPTOR message may include an associated context ID IE containing the context ID of the PDU set datagram to which it is related.If the PDU set descriptor is transmitted using HTTP datagrams (e.g., unreliable HTTP datagrams), then these HTTP datagrams may use a context ID derived from the context ID used for the associated PDU set data group. For example, the data group context ID and the descriptor context ID may differ in the value of their most significant bit (MSB) (e.g., only in that value). The receiving WTRU / UPF / AS may associate the PDU set descriptor and the PDU set group (e.g., all PDU set groups) to the same PDU set and apply the XR service to the PDU set. If a PDU set sequence number space declaration IE is provided in the XR stream establishment request, both the WTRU and the UPF may derive one or more per-PDU set XR service IEs, such as priority and type, from the context ID. In this case, the PDU set XR service IE may not be (e.g., may not need to be) conveyed in the PDU set descriptor. Per-PDU set XR service IEs may be encoded in the context ID, including one or more of the following: PDU set ID, PDU set priority, data type, PDU set length, etc. IEs encoded in or derived from the context ID enable provision of XR services even in situations where the PDU set descriptor may be lost or late.

[0155] Another PDU set may be sent. At 23, the PDU set may be transmitted by the WTRU in the uplink. In this case, the WTRU application or the WTRU hosted proxy client may perform PDU set classification and transmit a PDU set descriptor message, for example, in an HTTP datagram (e.g., an unreliable HTTP datagram) or transmit a CAPSULE message over a reliable stream, including an XR service IE per PDU set. A WTRU hosted proxy client that may be hosted in a terminal equipment (TE) portion of the WTRU may transmit PDU set classification information to a mobile terminal (MT) portion of the WTRU. For example, this may be accomplished by invoking an AT command to communicate information from the WTRU hosted proxy client to the MT portion of the WTRU. When information may be communicated from the WTRU hosted proxy client to the MT portion of the WTRU, the WTRU hosted proxy client may indicate what PDU session context the information may be associated with. When applying a service to a PDU in a PDU set, the WTRU may use an XR service IE, including an XR service IE per PDU set. The WTRU may transmit a per-PDU set XR service IE to a RAN node so that the RAN node may apply the XR service to the PDUs in the PDU set. For example, the WTRU may transmit a per-PDU set XR service IE to the RAN node via an RRC message. In an example, the WTRU may transmit a per-PDU set XR service IE to the RAN node in a UL MAC CE or UCI. In an example, the WTRU may be configured via RRC to report the per-PDU set XR service IE to the RAN node periodically and / or on an event-triggered basis (e.g., when a change in any information / parameter carried in or associated with the XR service IE is detected). The WTRU may transmit a per-PDU set XR service IE to the system (e.g., 5GC) via a NAS-SM message so that the SMF may configure the UPF to apply the XR service to the PDUs in the PDU set. For example, the WTRU may transmit a per-PDU set XR service IE to the AMF via a NAS-SM message, and the SMF may configure the UPF with information on how packets may be prioritized via the N4 interface. The WTRU hosting proxy client may transmit a PDU set data packet, for example, in an HTTP datagram (e.g., an unreliable HTTP datagram). The PDU set that the WTRU hosting proxy client may transmit to the MT for transmission may include a per-packet XR service IE in the IP header. The RAN and UPF may read the per-packet XR service IE and apply the XR service to the PDU. The XR service may include packet prioritization, synchronization, and / or jitter adjustment. When the PDU set may be transmitted to the MT portion of the WTRU, the WTRU hosting proxy client may transmit a per-packet XR service IE to the MT portion of the WTRU so that the WTRU may apply the XR service to the PDU.For example, as described herein, the WTRU may detect that the transmission of another PDU from the same PDU set has failed and may decide not to transmit the PDU set. The MT portion of the WTRU may indicate to the WTRU hosting agent client that transmission of the PDU may not be attempted and transmission of the PDU set may be considered aborted / failed.

[0156] The XR agent, which may be hosted in the UPF or in the N6-LAN, may determine the message type (e.g., descriptor or data packet) and that they are related to the same PDU set (e.g., all related to the same PDU set). In an exemplary MASQUE-based implementation, this may be achieved by using a context ID of the MASQUE. The MASQUE may enable an endpoint (e.g., each endpoint) to generate a unique context ID. The data packets of the PDU set (e.g., all data packets) may be transmitted using the same, unique context ID. If the PDU set descriptor is transmitted using a PDU_SET_DESCRIPTOR CAPSULE message (e.g., a reliable PDU_SET_DESCRIPTOR CAPSULE), the PDU_SET_DESCRIPTOR message may include a related context ID IE containing the context ID of the PDU set datagram to which it is related. If the PDU set descriptor is transmitted using HTTP datagrams (e.g., unreliable HTTP datagrams), these HTTP datagrams may use context IDs derived from the context IDs used for the related PDU set data packets. For example, the data packet context ID and the descriptor context ID may differ in the value of their MSB (e.g., only in that value). The receiving WTRU / UPF / AS may associate the PDU set descriptor and the PDU set grouping (e.g., all PDU set groups) to the same PDU set and apply the XR service to the PDU set. If a PDU set sequence number space declaration IE is provided in the XR streaming session establishment request, both the WTRU and the UPF may derive one or more per-PDU set XR service IEs, such as priority and type, from the context ID. In this case, the PDU set XR service IE may not (e.g., may not need to be) conveyed in the PDU set descriptor. Per-PDU set XR service IEs may be encoded in the context ID, including one or more of the following: PDU set ID, PDU set priority, data type, PDU set length, etc. The IEs encoded in the context ID or derived from the context ID enable the provision of XR services even in cases where the PDU set descriptor may be lost or late.

[0157] exist FIG. 3A to FIG. 3EIn the example, the WTRU app may be a legacy application. In the example, the WTRU app may (e.g., explicitly) exchange XR service IEs with the WTRU / UPF. After the XR WTRU app decides to request XR services for one or more streams, the WTRU app may transmit an XR stream establishment request (e.g., the same message as described in the XR stream session establishment request as described herein) to a local proxy on the WTRU (e.g., an XR proxy client component on the WTRU that provides an XR proxy server interface to the local WTRU app). Based on completing the XR stream session establishment response, the local proxy on the WTRU may transmit an XR stream establishment response to the XR WTRU app. Therefore, from this point on, the WTRU app may exchange XR service IEs with the local proxy. The XR service IEs may be exchanged along a proxy chain between the WTRU app and the AS. In the example, the WTRU app may use a programmatic application programming interface (API) (e.g., a function call) to transmit the XR service to the WTRU, rather than using a proxy connection between the WTRU app and the WTRU to communicate the XR service IE.

[0158] Figure 4 An example of a PDU aggregation option is shown. A PDU aggregation option in an IP header may be provided. The outer IP (e.g., IPv6) header may include a hop-by-hop or destination options header including a PDU aggregation option TLV. For example, as described in relation to Figure 4 As described, in addition to the option type and length, the short PDU set sequence option may include one or more of the following: a start (S) flag set on the first PDU in the set, an end (E) flag set on the last PDU in the set, a PDU sequence number (Seq), or a PDU set length (e.g., number of packets).

[0159] Additional option types may be defined to carry additional or different per-packet XR Service IEs, including larger sequence number spaces (eg, 14 bits, 22 bits, 30 bits) and / or parent PDU aggregate sequence numbers. Similarly, an IPv4 PDU aggregation option may be defined.

[0160] CAPSULE protocol extensions for XR services may be provided. One or more of the following CAPSULE protocol messages may be described to support the procedures described herein. The CAPSULE protocol message may include a PDU_SET_DESCRIPTOR message type, which may include one or more of the following: parameters, which may include a context ID used by an HTTP datagram and / or one or more per-PDU set XR service IEs as described herein, the HTTP datagram carrying data packets for a PDU set associated with the PDU set descriptor; a transmitter, which may include a client or an agent (e.g., a WTRU, UPF, or AS); a receiver, which may include a client or an agent (e.g., a WTRU , UPF or AS); reason for transmission (for example, the message can be transmitted before / with the data packet of the PDU set); action upon reception (for example, the receiver can store the per-PDU set XR service IEs and associate them with the PDU set data packets (such as the PDU set data packets associated with the context ID that enables the receiver to perform XR services on the PDU set)); or other aspects (for example, the capsule can be transmitted on a reliable stream or an unreliable datagram, and the packets carrying the capsule can be marked with a high priority DSCP code point to minimize losses). The CAPSULE protocol message may include a CLOSE_PDU_SET message type, which may include one or more of the following: parameters, which may include a context ID for identifying a set of PDUs to stop sending; a transmitter, which may include a client or an agent (e.g., a WTRU, UPF, or AS); a receiver, which may include a client or an agent (e.g., a WTRU, UPF, or AS); a reason for transmission (e.g., the transmitter wants its remote peer to stop transmitting packets related to the PDU set); or an action upon reception (e.g., the receiver stops transmitting packets of the PDU set identified by the context ID).

[0161] Figure 5A and Figure 5B An example procedure for QoS handling based on PDU sets based on MASQUE is shown. UL and DL XR traffic may be supported, including cases where the WTRU and AS exchange XR traffic and WTRU1-WTRU2 peer links. PDU set handling services (e.g., XR service sets applied to PDU sets, as described herein) may be provided in the WTRU and UPF.

[0162] The WTRU may host a PDU aggregation handling service proxy client. The UPF may host a PDU aggregation handling service proxy server. A tunnel may be established using the MASQUE protocol to carry the XR stream between the proxy client and the proxy, which MASQUE protocol may rely on HTTP / 3 over QUIC and support proxying of UDP streams. The HTTP / 3 protocol may be defined in draft-ietf-quic-http, and extensions may be defined in one or more of the following: draft-ietf-masque-connect-udp for supporting UDP proxy over HTTP; draft-ietf-masque-h3-datagram for supporting HTTP datagram; or draft-ietf-httpbis-h3-websockets for supporting extended CONNECT. The QUIC protocol may be defined (e.g., in IETF specifications RFC 9000, RFC 9001, RFC 9002, and extensions defined in RFC 9221) to support UDP proxy over HTTP. In the WTRU, the proxy client may be an HTTP / 3 client. In the WTRU, the proxy server may be an HTTP / 3 proxy. Once an HTTP / 3 connection is established between the proxy client and the proxy server, the proxy client may allocate a bidirectional HTTP data stream for the data stream (e.g., each data stream). The bidirectional HTTP data stream (e.g., each bidirectional HTTP data stream) may be established by the proxy client, which transmits an extended CONNECT to the proxy server to establish a session for the stream. Once the HTTP data stream is established for the data stream, the proxy client and the proxy server may transmit data packets to each other in unreliable HTTP datagrams. The data packet (e.g., each data packet) may carry a PDU or information about the PDU set. The proxy client and the server may perform PDU set identification for inbound traffic (e.g., UL traffic on the WTRU and DL traffic on the UPF).

[0163] The PDU set handling service may be configured with different granularities. For example, one or more of the following may apply. Per-stream information (e.g., per-stream XR service IE) may be exchanged between a proxy client and a proxy server, for example using extended CONNECT requests and responses. The information may include a flow descriptor (e.g., an IP 3-tuple describing a flow between a WTRU and an XR application server). Per-PDU set information (e.g., per-PDU set XR service IE) may be exchanged between a proxy client and a proxy server. When transmitted by the WTRU to the UPF, the per-PDU set information may enable the UPF to handle PDU sets (e.g., send it toward an AS or another WTRU) without regenerating the PDU set information based on the application header (e.g., or without requiring the entire PDU set information to be present in all packets). The distinction between transmitting per-PDU set information over a proxy connection and transmitting per-PDU information at a lower layer may enable an optimized design of per-PDU information to reduce overhead without affecting the PDU set information received by the WTRU or UPF. The information may include one or more of the following: information for handling within a PDU set (e.g., a PDU set sequence number (SN), a start / end PDU in a PDU set, a PDU SN within a PDU set, and / or the number of PDUs within a PDU set); or information for handling between PDU sets (e.g., PDU set importance and / or PDU set dependency). PDUs may be communicated between a proxy client and a proxy server. Per-PDU information (e.g., per-packet XR service IE) may be transmitted with the PDU (e.g., each PDU) and may be visible to the RAN. Per-PDU marking may be set by the WTRU for UL traffic and by the UPF for DL ​​traffic. In the DL, the UPF may populate the GTP-U header with information that may be used by the RAN for PDU set handling. In the UL, the WTRU may include per-PDU information in a PDU header that may be visible to the RAN. The information may include a PDU set first packet flag and / or a last packet flag, a PDU sequence number (e.g., within a PDU set).

[0164] If the per-PDU aggregate information (e.g., any of the PDU aggregate information) may be useful to the RAN, it may be included in the per-PDU information (e.g., the PDU header). What information may be encoded in the PDU header (e.g., whether the information is useful to the RAN) may be left to the RAN WG. How the PDU header may be encoded in the PDU may be left to stage 3 (e.g., using IP header options, DSCP code points, or other techniques for encoding).

[0165] like Figure 5A and Figure 5BAs shown, these techniques may include one or more of the following. At 1, the WTRU may establish a PDU session. The WTRU may provide a PDU aggregate handling service flag to request a PDU aggregate handling service on the PDU session. At 2, the SMF may transmit an N4 rule to the UPF, including an indication that the PDU aggregate handling service may be requested and the N4 rule including an extension to support PDU aggregate related handling. At 3, the UPF may configure a proxy server (e.g., create / select an XR proxy instance) to provide the requested PDU aggregate handling service.

[0166] At 4, the UPF may transmit proxy server information (e.g., IP address and port of the proxy server instance) to the SMF for the WTRU to use to connect to the proxy. The proxy server information may be included in or indicated by a response message that may be transmitted to the SMF.

[0167] At 5, the SMF may transmit a PDU Session Establishment Accept message. The PDU Session Establishment Accept message may include the IP address and port number of the proxy server. The N2 message may include a QoS profile and an indication that a PDU aggregate handling service may be implemented. The QoS profile may include extensions to support PDU aggregate related handling.

[0168] For a stream (e.g., each stream), the proxy client may establish a MASQUE connection with the proxy server using the IP address and port number received in the PDU Setup Accept message. At 6, a MASQUE connection may be established. The proxy client may initiate a MASQUE session (e.g., each MASQUE session) by transmitting an HTTP CONNECT request including connect-udp protocol parameters and per-stream information. The WTRU app may transmit / receive a UDP payload (e.g., RTP and / or SRTP packets) of an XR stream to / from the WTRU. The proxy client may implement a PDU set handling service including a PDU set identifier, and may forward encapsulated XR streams to / from the UPF via MASQUE. At 7, the UPF may forward UDP traffic to / from the AS as described herein.

[0169] At 8, the AS may transmit the DL packet to the UPF. At 9, upon receiving the DL packet from the XR AS, based on the received N4 rule or local configuration, the UPF's proxy server may identify the PDU sets and per-PDU set information listed herein by matching the RTP / SRTP header and payload.

[0170] At 10, if the PDU may be the first PDU in a set, the server agent may transmit a PDU set descriptor (e.g., and a DL packet (per packet tag)) to the proxy client. In the DL, the UPF may populate the GTP-U header with per-PDU information that may be used by the RAN for PDU set handling.

[0171] At 11, the RAN may apply a PDU set based QoS treatment using the per PDU information. At 12, a node associated with the RAN may transmit the PDU to the proxy client.

[0172] At 13, based on the reception of the PDU, the proxy client may forward the XR traffic to the WTRU. At 14, the WTRU app may provide the UL packet to the WTRU. At 15, when the proxy client receives the UL traffic (e.g., at 14), the proxy client (e.g., the WTRU) may identify the PDU set and per-PDU set information in a manner similar to the UPF PDU set identification. If the PDU may be the first PDU in the set, the client proxy may transmit a PDU set descriptor to the server client.

[0173] At 16, in the UL, the WTRU may include the per-PDU information in the PDU header, which may be visible to the RAN. The WTRU may apply a PDU aggregate based QoS treatment. At 17, the RAN may apply a PDU aggregate based QoS treatment.

[0174] At 18, the RAN may transmit the PDU set descriptor (eg, and UL packets (per packet tag)) to the UPF. At 19, the UPF may transmit the UL packets to the XR AS.

[0175] QUIC-based media protocol relay may be provided. The concept of extended reality (XR) may be applied to augmented reality (AR), virtual reality (VR), and mixed reality (MR). XR traffic may be associated with a round-trip latency that may be approximately 50ms. Round-trip latency may include gesture-to-rendering-to-photon latency. Motion-photon latency may be approximately 20ms.

[0176] The Media over QUIC (MOQ) protocol can be a low-latency media delivery for ingestion and distribution of media. MOQ can be applied to live broadcasts, games, and / or media conferencing, and can be extended to include XR scenarios. This article describes the MOQ protocol and mechanisms.

[0177] For example, an MOQ repeater may be an intermediate node in an end-to-end MOQ connection by acting as a forwarding proxy and providing services (e.g., congestion management or XR support services as described herein).

[0178] Techniques may be developed to improve QoS for XR applications as well as increase cell capacity and reduce energy usage for this type of application. Such support may require (e.g., require) the network to have access to XR traffic metadata. While RTP / SRTP traffic may be analyzed (e.g., by a UPF or WTRU) to produce metadata that can be used by the network, the network may not analyze encrypted traffic like MOQ in a similar manner. Techniques for encrypted traffic may include analyzing traffic characteristics using machine learning algorithms.

[0179] A mechanism for MOQ application endpoints to transmit XR traffic metadata along with XR media data may allow intermediate nodes (e.g., acting as MOQ relays) to provide XR support services as described herein.

[0180] The mechanism may use a secure MOQ repeater for XR support located in the network and / or WTRU (e.g., located on an I-UPF, PSA UPF, WTRU, and / or relay WTRU). A "secure MOQ repeater for XR support" may be referred to as a "secure MOQ repeater" or "MOQ repeater." To protect the privacy of the user, the secure MOQ repeater may be blocked from accessing media data and metadata (e.g., most metadata) through end-to-end encryption. The secure MOQ repeaters may have (e.g., only have) access to metadata that enables the services they provide. These services may include traffic forwarding and / or XR support.

[0181] A secure MOQ repeater may apply services on a media stream. Such services may be referred to as MOQ services. In an example, a MOQ service may be an XR-enabled service, where an application endpoint may establish communication through a secure MOQ repeater that provides the MOQ service. A MOQ application endpoint (e.g., a media source located on a WTRU or AS) may transmit an XR service IE (also referred to herein as XR metadata) as described herein along with the media data. A secure MOQ repeater may receive XR service IEs and use these XR service IEs to provide XR services. XR services may include one or more of the following: associating XR metadata with PDUs transmitted to the RAN to enable the RAN to perform XR services, locally prioritizing PDUs based on XR metadata in case of congestion, selecting a path to forward the PDU when multiple paths are available between the MOQ relay and the next hop (e.g., WTRU WTRU), or performing local RAN XR services in the case where the MOQ relay can be co-located with the WTRU or in the case where the MOQ relay can be co-located with the RAN node (e.g., the MOQ relay in the UPF is co-located with the RAN node).

[0182] The MOQ protocol can carry media data (e.g., live media segments) over a QUIC-based transport protocol. The MOQ protocol can adjust the media transmission rate based on the internal state of the transport congestion control function, for example, reducing the rate when congestion is experienced on the connection. Different types of congestion control algorithms can be supported (e.g., loss-based and / or delay-based algorithms), and different types of codecs can be supported, including codecs for XR video (e.g., immersive video (e.g., MIV), video-based point cloud compression (V-PCC), and / or geometry-based point cloud compression (G-PCC)). Examples of the MOQ protocol may include existing QUIC-based media streaming protocols such as RUSH and WARP.

[0183] The MOQ protocol can be carried over a WebTransport session or over a raw QUIC connection. Peers can agree on the use of the MOQ protocol through convention (e.g., out-of-band knowledge of the target URL for accessing the service) or signaling (e.g., the "moq" scheme in the URL, application layer protocol negotiation (ALPN), HTTP or QUIC setup parameters, capsule messages transmitted over a WebTransport session specifying the MOQ protocol, etc.). The MOQ protocol can carry control messages (e.g., including media request PDU set descriptor messages as described herein) over HTTP / QUIC streams, and can carry media data and related metadata over HTTP / QUIC streams and / or datagrams. For MOQ over WebTransport, HTTP / QUIC streams / datagrams can carry a WebTransport session ID for associating them with the appropriate WebTransport session.

[0184] This article may describe procedures for MOQ based on WebTransport. These procedures can be used to derive similar procedures that can be applied to MOQ based on original QUIC.

[0185] A direct MOQ connection (e.g., without involving a MOQ relay) between a client / WTRU (e.g., a JavaScript application running in a browser on the WTRU) and a server / AS may include one or more of the following. The WTRU may establish an HTTP / 3 connection with the AS, where both the WTRU and the AS have set the HTTP setting "SETTINGS_ENABLE_WEBTRANSPORT". In order to start a WebTransport session over the HTTP / 3 connection, the WTRU may transmit an extended HTTP CONNECT message to the AS, including parameters "protocol" (e.g., with a value of "webtransport"), "scheme" (e.g., "https"), "authority" set to the media server domain (e.g., media.example.com), "path" identifying the media to be sent (e.g., path / to / media), and / or "origin" set to the network origin of the request. Based on the receipt, the AS may determine whether the request is acceptable for a given network origin. If the request is acceptable, the AS may transmit an HTTP response (e.g., 200OK) to the WTRU. The requested WebTransport session may exist and may be identified by a session ID (e.g., equal to the stream ID used by the extended HTTPCONNECT request that started the session). The WTRU and the AS may exchange control messages, media data, and / or associated metadata over the session.

[0186] To gain support for XR media streams, the MOQ application may expose information to the network about the relative importance / relationships of different data units (e.g., PDU sets) within the stream. For example, within a video stream, an application may associate different priorities and inter-relationships with I-frames, P-frames, and B-frames. Another application may associate this information with other kinds of application data units determined by the application (e.g., layers when a scalable video codec is used). By setting different PDU set priorities, an application may ask the network to prioritize data units that may be useful for the end-user's quality of experience. By setting inter-relationships, an application may enable the network to discard PDUs that are useful for the end-user's quality of experience (e.g., discard PDUs that rely on a lost base layer for decoding). For example, an application may call the MOQ library function send_application_unit(), whose parameters include a media application unit, a priority, a PDU set or inter-relationships of application units, and other XR service IEs. As a result of this call, the MOQ library may transmit XR service IEs and PDUs, such as information about FIG. 8A to FIG. 8C described.

[0187] The XR service IE may be transmitted along the media stream via MOQ and may be visible to an intermediate MOQ repeater, which may be collocated, for example, with a WTRU, a D2D relay WTRU, a PSA UPF, an I-UPF, and / or an edge server. For example, the XR service IE may be transmitted in the header of a media stream datagram and / or stream using a common ID (e.g., a PDU set ID, a media stream ID, a context ID, or a stream ID), or in a separate message associated with the media stream datagram and / or stream. The MOQ repeater may collect information exposed by the application and perform a series of packet processing functions, including marking relevant packets with information that may be used by the RAN to implement XR support. The MOQ repeater may provide additional services in addition to marking packets for the RAN. The MOQ repeater may perform priority-based local queue management based on PDU set importance. The MOQ repeater may mark the TOS / TC / FL fields on the forwarded PDUs so that the network may classify them into different QoS flows. In the case where multipath QUIC (or other multipath mechanisms such as access traffic steering, switching, splitting, ATSSS) may be used between a MOQ relay and a WTRU (e.g., or between two MOQ relays), the MOQ relay may forward the PDU through a path selected from multiple available paths, for example based on a PDU set IE, to enable the system to classify the PDU into different QoS flows based on path characteristics (e.g., per-path characteristics such as a 5-tuple), and / or to enable the system to send the PDU over different access technologies (e.g., 5G NR, WiFi). When the PDUs are classified into different QoS flows, the PDUs may receive different QoS treatments.

[0188] Figure 6 An example of a secure MOQ repeater model is shown. Figure 6 A secure MOQ relay model may be represented where hop-by-hop IEs may be exchanged between a client / WTRU, a secure MOQ relay, and a server / AS (e.g., transmitted by one endpoint and forwarded by the relay to another endpoint with or without modification). End-to-end IEs and media data may be exchanged between a client and a server (e.g., and protected by encryption from being accessed by the secure MOQ relay that forwards them). The hop-by-hop IEs may include PDU Set IEs, as described herein. The end-to-end IEs and media data may be protected by (e.g., transport layer) encryption between the client and the server. The end-to-end IEs may include a Media Request Message IE and metadata (e.g., subtitles) not related to the service provided by the secure MOQ relay.

[0189] Figure 7 Example deployment scenarios for a secure MOQ relay are shown. These scenarios may represent clients, MOQ relays, and servers, and may represent hop-by-hop and end-to-end traffic flows, such as Figure 6To use a given scenario, the MOQ application client and the MOQ repeater may be configured with their next hop (eg, MOQ repeater or AS) to establish a communication link. Fig.12 The described procedures may describe a technique in which the network provides such configuration, for example, based on policies set by an application provider. In scenario (1), a secure (e.g., single secure) MOQ relay collocated with the UPF may be used between the WTRU / MOQ client and the AS / MOQ server (e.g., located in the UPF, in a network function, or in an edge computing server). This can be used to apply XR services on downlink media streams from the AS. In an example, for example, when the AS may be located in a local area data network, the secure MOQ relay may be collocated with the UPF and the gNodeB. In scenario (2), the secure MOQ relay may be collocated with both the WTRU and the UPF. This can be used to apply XR services on downlink media streams and uplink media streams. In scenario (3), the secure MOQ relay may be collocated with both the D2D relay WTRU and the UPF. This can be used to apply XR services on downlink media streams and / or uplink media streams, between the D2D relay WTRU and the UPF. In scenario (4), a secure MOQ relay may be collocated with WTRU1, WTRU2, and the UPF. This may be used to apply XR services on both the downlink and uplink legs of peer-to-peer (eg, WTRU1 to WTRU2) media flows.

[0190] In the scenario described herein, a MOQ client (e.g., a WTRU) may establish a connection to a MOQ server (e.g., an AS) through a secure MOQ repeater for XR support. If the MOQ repeater refuses the connection (e.g., by closing the connection), the MOQ client may connect directly to the AS without using a repeater. This may reduce the quality of service. The application provider may determine a scenario (e.g., a suitable scenario) based on the nature of the application or based on the nature of the application features used by the user (e.g., the user may be consuming downlink AR traffic, resulting in scenario (1); the user may be generating uplink VR traffic, resulting in scenario (2)). The application provider may configure the scenario in the system, for example, through the NEF API. The system may store the scenario configuration from the NEF API in a policy rule (e.g., a PCC rule).

[0191] Communication through a secure repeater may be provided. Types of secure MOQ repeaters (eg, two types) may be described herein: a MASQUE-based MOQ repeater and a MOQ repeater using end-to-end encryption keys. The MOQ protocol design may correspond to Mode 2.

[0192] The MASQUE-based MOQ repeater tunnel mode (e.g., referred to herein as "Mode 1") may overlay end-to-end communications on a MASQUE connection, thereby protecting MOQ media data and metadata from being exposed to a secure MOQ repeater through end-to-end encryption. The client / WTRU may establish a MASQUE session with a secure MOQ repeater, and the MOQ repeater may establish a MASQUE session with a MOQ server (e.g., by forwarding an initial CONNECT request from the client to the server). The MOQ repeater may forward end-to-end traffic (e.g., application PDUs encapsulated in HTTP datagrams) between endpoints via the MASQUE session. In Mode 1, secure MOQ repeaters may provide their services using metadata exposed through the MASQUE session. The client / WTRU, server / AS, and MOQ repeater may communicate IEs used (required) to provide services (e.g., including XR support services) provided by the MOQ repeater through a MASQUE session using hop-by-hop messaging (e.g., using a capsule protocol (e.g., TLV messages)).

[0193] MOQ repeater "HTTP intermediate mode" (e.g., referred to herein as "mode 2") using end-to-end encryption keys may use the MOQ repeater as an HTTP intermediary, but may use end-to-end encryption keys (e.g., exchanged out-of-band using a protocol such as Messaging Layer Security (MLS)) to protect media data and some metadata end-to-end, while some metadata may be visible to the MOQ repeater but may be end-to-end authenticated using a pre-shared key.

[0194] MOQ designs for XR support when using secure MOQ repeaters are available. FIG. 3A to FIG. 3EThe described WebTransport mechanisms, MASQUE (e.g., in Mode 1) and / or end-to-end encryption (e.g., in Mode 2), and the techniques described herein enable efficient provision of XR support through a secure MOQ repeater. For example, PDU set descriptor messages may not be transmitted over a MOQ session in Mode 1, and these PDU set descriptor messages may not be transmitted end-to-end encrypted in Mode 2 because the secure relay has access to (e.g., needs to have access to) those messages. The PDU set descriptor may be arranged (e.g., needs to be arranged) in a message that can be read by the MOQ repeater (e.g., a CAPSULE message in a MASQUE in Mode 1 or an unencrypted WebTransport CAPSULE message in Mode 2), and may include (e.g., needs to include) a PDU set context ID that corresponds to an ID present in a media data PDU and that can be read by a secure MOQ repeater. A technique may be used to enable mapping of PDU set descriptor messages and PDUs transmitted over MOQ through a secure MOQ relay so that the secure MOQ relay can use them to provide XR support services. A WTRU application may be provided that discovers a MOQ relay to be used when establishing a connection to a MOQ server under the control of a network operator. A technique may be used (e.g., required) to discover and establish communications through a MOQ relay and implement the above-described Figure 7 A series of deployments described.

[0195] A mechanism for using MOQ repeaters for XR support may be provided. XR service operations through MOQ repeaters may be provided. FIG. 8A to FIG. 8C As shown, XR service operations through a secure MOQ repeater may be provided. A PDU set descriptor message may be used to associate XR metadata with a PDU set using a "PDU set context ID". A PDU set descriptor message may be described herein, wherein a "context ID" parameter may be a "PDU set context ID" as described herein, and wherein the other parameters are one or more per-PDU set XR service IEs as described herein. The "PDU set context ID" may have a 1-to-1 relationship with a "PDU set ID", which may be present in a PDU (e.g., each PDU) in a given PDU set.

[0196] The relationship between the "PDU Set Context ID" and the "PDU Set ID" may depend on the mode of operation and may be as described herein. A MOQ application may transmit PDUs associated with a "PDU Set ID" over a MOQ / WebTransport session. The "PDU Set ID" may be a (e.g., non-encrypted end-to-end) field in the MOQ protocol header, an HTTP stream ID (e.g., if the PDUs in the PDU Set are transmitted on a dedicated HTTP stream), or an HTTP datagram context ID (e.g., if the PDUs in the PDU Set are transmitted on an HTTP datagram identified with a context ID dedicated to the PDU Set). In mode 2, the "PDU Set ID" may be used directly as the "PDU Set Context ID" in the PDU Set Descriptor, since the WTRU / AS / MOQ relay may have (e.g., all have) access to the "PDU Set ID" in the PDU. In mode 1, the transmitter may maintain a mapping between the "PDU Set ID" and the "MASQUE Context ID" visible to the secure MOQ relay. The "MACSQUE context ID" may be the context ID of the HTTP datagram encapsulating the QUIC packet carrying the PDU of the associated "PDU set ID". In Mode 1, the MASQUE context ID may be used as the "PDU set context ID" in the PDU set descriptor. In Mode 1, the secure MOQ relay may establish and maintain a mapping between MASQUE context IDs on the legs of the connection (e.g., each leg). To illustrate the use of different IDs, Fig. 9 May represent a capsule message such as a PDU set descriptor. Fig. 10A and Fig. 10B It can represent the application PDU carried in mode 2. Fig.11 It can represent the application PDU carried in mode 1.

[0197] Other similar procedures may be derived from this procedure, involving a chain of secure MOQ repeaters (e.g., one secure MOQ repeater co-located with the WTRU and one secure MOQ repeater co-located with the UPF, or following procedures such as those regarding Figure 7 The secure MOQ repeater in the chain can be configured with the next-hop secure MOQ repeater (if the next-hop secure MOQ repeater exists). Fig.12 The procedures in may indicate how such configuration may be performed.

[0198] FIG. 8A to FIG. 8C An example XR service operation through a secure MOQ repeater is shown. Fig. 8AIn, at 1 to 4, a MOQ session may be established between the WTRU and the AS through a secure MOQ repeater, possibly including XR service negotiation. For mode 1, both the secure MOQ repeater and the AS may act as MASQUE proxies. The WTRU may establish a MASQUE session with the secure MOQ repeater, and the secure MOQ repeater may establish a MASQUE session with the AS. The WTRU may establish a WebTransport session with the AS, which is transmitted over the MASQUE session. The WTRU, the MOQ repeater, and the AS may exchange capabilities, including XR support service capabilities, through the MASQUE session during or after the establishment of the MASQUE session. For mode 2, the WTRU and the AS may exchange end-to-end encryption keys, for example, using the MLS protocol. The WTRU may establish an HTTP connection with the AS through a MOQ repeater (e.g., acting as an HTTP proxy). The WTRU may initiate a WebTransport session by transmitting an extended HTTP CONNECT request to the AS via the MOQ repeater. The WTRU, MOQ repeater, and AS may exchange capabilities, including XR support service capabilities, through a WebTransport session during or after the WebTransport session is established. At this point, as illustrated in 2 to 4, a WebTransport session (e.g., identified by stream ID 3) may be established through an HTTP connection between the WTRU and the AS. Media data and end-to-end metadata may be end-to-end encrypted through the WebTransport session. The hop-by-hop metadata may not be encrypted, and in each case, the hop-by-hop metadata may be updated by the secure MOQ repeater. A portion of the connection between the WTRU and the MOQ repeater may be branch 1, and a portion of the connection between the MOQ repeater and the AS may be branch 2.

[0199] At 5 to 8, a media request / response initiated by the WTRU may be shown. The AS may transmit a media request for requesting an uplink media stream. At 5, the WTRU (e.g., based on user interaction) may decide to request media. Different media streams (e.g., video, audio, etc.) may be requested over a single MOQ / WebTransport session, and these different media streams may include (e.g., each contain) one or more types of PDU sets, thereby allowing multiple media streams to be multiplexed over the session.

[0200] At 6, the WTRU may transmit a MOQ media request message over WebTransport session ID3 (e.g., over a new HTTP stream associated with WebTransport session ID3). The MOQ media request message may include a media target ID. The MOQ media request message may include an XR-Service-Request IE (e.g., a Boolean flag) that indicates (e.g., if set to "true") that an XR Service IE is requested for the stream. This IE may make it possible to request an XR Service IE on some streams and not request an XR Service IE on other streams.

[0201] At 7, the AS may evaluate (e.g., and accept) the media request. The AS may select an XR Service IE to provide for the media stream based on the XR-Service-Request IE. If the XR Service Request IE is not provided in the MOQ media request, the AS may consider providing an XR Service IE on the stream (e.g., based on application logic or configuration and media type such as video, audio, text, etc.).

[0202] At 8, the AS may transmit a MOQ media response over WebTransport session ID 3. The MOQ media response may include an XR-Service-Response IE (eg, a Boolean flag) to indicate that the AS may provide an XR Service IE associated with the requested media stream.

[0203] exist Figure 8B 9 to 21 may relate to an exemplary downlink PDU set. The AS may transmit PDU set information. The AS may reliably and asynchronously transmit the PDU set information in advance. The AS may transmit a PDU corresponding to the PDU set.

[0204] At 9, the AS may determine the XR Service IE associated with the PDU set selected to be transmitted to the WTRU. The AS may retain the PDU set context ID 10. ID 10 may be used to identify the selected PDU set. For example, the AS may determine ID 10 by selecting the next unused PDU set ID.

[0205] At 10, the AS may transmit a PDU_SET_DESCRIPTOR message to the secure MOQ relay, including the PDU set context (ID10) and the XR service IE associated with the selected PDU set. In mode 1, the PDU_SET_DESCRIPTOR may be a capsule protocol message transmitted over the HTTP stream of the MASQUE session between the AS and the MOQ relay. In mode 2, the PDU_SET_DESCRIPTOR may be a capsule protocol message transmitted over the HTTP stream of the WebTransport session ID3.

[0206] Fig. 9Capsule messages to / from a secure MOQ repeater are shown (e.g., Figure 8B 10 in the example. Fig. 9 As shown, a specific representation of the PDU_SET_DESCRIPTOR message may be provided, including a stream ID, a PDU_SET_DESCRIPTOR capsule type, an XR service IE, and a PDU set context ID (ID10). One or more fields may be represented by a dashed line to indicate that they may or may not exist. Figure 8B At 10 in FIG. 1 , the packet may include an IP address and UDP port, which may point to the secure MOQ relay. Based on receiving the message, the secure MOQ relay may determine how to forward the message based on the flow ID, how to extract the next hop (e.g., WTRU) IP address / port from the MASQUE (e.g., Mode 1) or WebTransport (e.g., Mode 2) session information.

[0207] Reference Figure 8B , at 11, the secure MOQ repeater may save the PDU set descriptor (e.g., including the XR service IE and PDU set context ID10) for use (e.g., future use). In mode 1, the secure MOQ repeater may retain the MASQUE context ID / PDU set context ID11 in the WTRU-AS MASQUE session. The secure MOQ repeater may save the mapping between PDU set context ID10 and PDU set context ID ID11. In mode 2, the same PDU set context ID may be used on both leg 1 and leg 2 (e.g., because in this mode, the PDU set context ID may be the stream / context / PDU set ID of the end-to-end WebTransport session). In mode 2, PDU set context ID10 and ID11 may be the same ID.

[0208] At 12, the secure MOQ relay may transmit a PDU_SET_DESCRIPTOR message to the WTRU, including the XR service IE and the PDU set context ID11. At 13, the WTRU may save the PDU set descriptor (e.g., including the XR service IE and the PDU set context ID11) for use (e.g., future use). At 14, the AS may transmit a first PDU #1, which may be part of a PDU set associated with ID10 / ID11. PDU #1 may be transmitted via WebTransport session ID3.

[0209] Fig. 10A and Fig. 10B FIG. 1 shows a PDU transmitted via MOQ using a secure MOQ repeater in Mode 1 (e.g., which may be Figure 8B14 in the example representation). In mode 1, Fig. 10A and Fig. 10B A specific representation of the PDU may be provided, including the MASQUE session ID, the PDU collection context ID10 and the WebTransport session ID3.

[0210] Fig.11 FIG. 1 shows a PDU transmitted via MOQ using a secure MOQ repeater in Mode 2 (e.g., which may be Figure 8B 14 in the example of using). In mode 2, Fig.11 A specific representation of the PDU may be provided, including a PDU set context ID 10 (e.g., which may be a PDU set ID) and a WebTransport session ID 3. One or more fields may be represented using dashed lines to indicate that they may or may not be present. The MOQ header may include fields such as a timestamp, a frame start indicator, a frame end indicator, a layer ID, an XR service IE, and the like. One or more fields may be end-to-end encrypted, while other fields may not be end-to-end encrypted. In mode 2, the PDU set context ID may be encoded as an HTTP datagram context ID or an MOQ header field (e.g., not end-to-end encrypted).

[0211] Reference Figure 8B , at 15, the secure MOQ relay may use the PDU set context ID 10 from PDU #1 and the information stored at 11 to extract a PDU set descriptor corresponding to PDU #1 (e.g., including an XR service IE). The secure MOQ relay may use the XR service IE from the extracted PDU set descriptor to apply the XR service on PDU #1. As described herein, the XR service may include one or more of the following: marking PDU #1 before forwarding it toward the RAN so that the RAN can apply the XR service on the PDU (e.g., by marking the GTP-U header field); selecting a path for forwarding PDU #1 if multipath QUIC can be used between the secure MOQ relay and the WTRU; marking the PDU #1 IP header TOS / TC / FL before forwarding; performing local prioritization of PDUs in the event of congestion; performing local RAN optimization on the WTRU when the MOQ relay can be co-located with the WTRU. In Mode 1, the secure MOQ relay may use PDU Aggregate Context ID10 from PDU#1 and the mapping information stored in step 11 to extract PDU Aggregate Context ID11 to be used when forwarding PDU#1. In Mode 2, PDU Aggregate Context ID11 may be equal to PDU Aggregate Context ID10.

[0212] At 16, the secure MOQ repeater may forward PDU#1 to the WTRU associated with PDU collection context ID11. PDU#1 may be transmitted using marking and / or path selection, as determined at 15. At 17, the WTRU may extract the PDU collection descriptor corresponding to PDU#1 using PDU collection context ID11 from PDU#1 and the information stored at 13. The WTRU may apply the XR service as described herein. In the example where the WTRU is a repeater for another client WTRU, in the event of congestion on the link between the client WTRU and the relay WTRU, the relay WTRU may use the PDU collection information to prioritize the media data.

[0213] 14 to 17 may be repeatedly performed for PDUs (eg, each PDU) in the PDU set associated with PDU set context ID 10 on leg 2 and PDU set context ID 11 on leg 1. Exemplary PDU #n processing may be represented at 18 to 21.

[0214] exist Figure 8C 22 to 34 may relate to an exemplary uplink PDU set. The WTRU may reliably and asynchronously transmit the PDU set information in advance. The WTRU may transmit the PDU corresponding to the PDU set. 22 to 34 may be similar to and derived from 9 to 13. In Mode 2, PDU set context ID 20 and ID 21 may be the same ID.

[0215] At 27, the WTRU may apply XR services before transmitting PDU # 1. For example, the WTRU may mark the layer 2 header field of PDU # 1 to enable the RAN to apply uplink XR service techniques (e.g., adjust transmission reliability based on the PDU set importance IE), or the WTRU may locally implement uplink RAN ​​XR service techniques.

[0216] At 28, the nature of the XR service provided by the secure MOQ relay may depend on the scenario. For example, if the server / AS is deployed on the WTRU, the secure MOQ relay may use GTP-U marking to enable the RAN to provide the XR service. In an example, if the server / AS may be deployed in a remote cloud or edge cloud, the secure MOQ relay may mark the forwarded PDU IP header TOS / TC / FL fields. In an example, the secure MOQ relay may apply priority when forwarding PDUs based on the PDU Set IE, for example, in the event of congestion.

[0217] In an example, a media transmitter (e.g., a WTRU or AS) or a MOQ repeater may determine that a PDU set transmission may be canceled. For example, the cancellation may be performed in response to a congestion event or detection of lost packets. In addition to the event itself, the WTRU / AS / MOQ repeater may use the XR service IE associated with the PDU set to select which PDU sets may be canceled. When a decision can be made, the WTRU / AS / MOQ repeater may transmit a CLOSE_PDU_SET message to the WTRU, AS, and / or MOQ repeater to request that the selected PDU set be stopped from being sent and discarded. In an example, for example, in mode 2, when a dedicated per-PDU set HTTP stream is used to transmit PDUs, the WTRU / AS / MOQ repeater may close (e.g., alternatively close) the stream without transmitting a CLOSE_PDU_SET message.

[0218] Provides secure MOQ repeater connection establishment and discovery. Fig.12 MOQ relay discovery and connection establishment procedures may be used. Prior to this procedure (which may not be shown), the WTRU and AS may exchange end-to-end encryption keys, for example using MLS.

[0219] Fig.12 An example MOQ repeater discovery and connection establishment procedure is shown. Fig.12 As shown, a secure MOQ relay discovery and connection establishment procedure may be provided. In this procedure, the WTRU and the network may determine the use (e.g., need) of a secure MOQ relay based on control plane signaling and policy, deploy the secure MOQ relay, and convey the secure MOQ relay ID through the control plane so that the WTRU application and the intermediate secure MOQ relay can be configured with the next hop MOQ relay. In an example, mode 2 may be used.

[0220] In an example, prior to this procedure (e.g., may not be shown), the WTRU and the AS may exchange end-to-end encryption keys, for example, using MLS. At 0, the WTRU may obtain policies from the network. Such policies may be WTRU routing selection policies (URSP), WTRU access network discovery and selection policies (ANDSP), WTRU vehicle-to-vehicle policy (V2XP), and / or WTRU 5G proximity service policy (ProSep).

[0221] The policy rules may include a "MOQ Repeater Configuration IE" that includes one or more of the following. They may include a repeater / proxy type (e.g., an application layer protocol negotiation (ALPN) tag "moq") to indicate the MOQ repeater type. They may include instructions (e.g., a flag) for setting a "MOQ service request indication" in a connection establishment / update message. They may include a MOQ repeater usage scenario identifier, whose possible values ​​indicate no repeater, a repeater in the network, a repeater in the WTRU, and / or a repeater in the network and the WTRU. The MOQ repeater usage scenario identifier may include a value indicating a MOQ repeater in the UPF and a D2D relay WTRU, or may include a value indicating a MOQ repeater in the UPF and multiple endpoint WTRUs. This may enable configuration such as Figure 7 Other encodings may be used, such as a Boolean flag indicating the presence / absence of a MOQ repeater locally and within the network. They may include additional MOQ repeater protocol parameters, including a list of MOQ protocol extensions to use, which may include "XR support" MOQ protocol extensions (e.g., extensions or operating modes of the MOQ protocol that use the PDU set descriptor and other XR service functionality described herein).

[0222] At 1, the WTRU application may decide to establish a MOQ flow / connection (e.g., a new MOQ / flow / connection). Based on the service request (e.g., when the application transmits the first DNS request packet), the WTRU may select a URSP rule that matches the URSP rule traffic descriptor (e.g., based on the WTRU application name) and may select (e.g., the highest priority) routing selection descriptor (RSD) from the rule. If the selected RSD includes an instruction to add a "MOQ service request indication", the WTRU may determine at 2 to add a MOQ service request indication in the PDU session establishment request / update.

[0223] At 2, the WTRU may transmit a PDU Session Establishment Request / Update. The WTRU may add a MOQ Service Request indication in the PDU Session Establishment Request / Update based on policy (e.g., at 0 and / or 1) and / or based on configuration or WTRU application request. The MOQ Service Request indication may be a MOQ Service Flag and / or one or more MOQ Relay Configuration IEs.

[0224] At 3a (e.g., or earlier), the SMF may obtain policies from the PCF, for example, including policy and charging control (PCC) rules and session rules. These policy rules may include MOQ relay configuration IE as described herein. Upon receiving the session request message, the first network node (e.g., SMF) may determine policy information from the third network node (e.g., PCF).

[0225] The SMF may determine policy information from a third network node (e.g., PCF) (e.g., before obtaining a policy from the PCF). At 3a (e.g., or earlier), the SMF may obtain policy information from the PCF, for example, including policy and charging control (PCC) rules and session rules. At 3b, the SMF may select the UPF based on the MOQ repeater configuration IE in the policy (e.g., PCC) rule, based on the MOQ service request indication in the message received at 2, based on the UPF capability to support MOQ repeater functionality, and / or based on the UPF capability to support specific MOQ extensions (such as "XR-service" extensions). As described herein, an extension may refer to a feature that can be added to the MOQ protocol to support functionality. A MOQ extension may be a feature added to the MOQ protocol, and an XR service extension may refer to a modification to the MOQ protocol that can support extended reality (XR) services. Based on local configuration and / or management plane messages from an operator (e.g., PCF), the SMF may be aware of the UPF's support for MOQ repeater functionality and extensions. A local configuration or management plane message may (e.g., explicitly) define the supported MOQ extensions and functionality of the UPF (e.g., support for a specific MOQ protocol version, XR services, or other MOQ-related features). The capabilities of the UPF (e.g., the second network node) may be determined (e.g., implicitly) based on provided information such as the hardware of the UPF (e.g., the second network node) or the software specifications of the second network node, which may be used to infer the supported MOQ functionality. For example, a local configuration or management plane message may include an indication that the UPF supports MOQ repeaters / proxy. In another example, a local configuration or management plane message may include an indication that the UPF supports XR traffic, and the SMF may derive from the information that the UPF supports MOQ repeaters / proxy. A first network node (e.g., SMF) may determine the ability of a second network node (e.g., UPF) to provide a network MOQ proxy based on a local configuration or management plane message.

[0226] The second network node may be selected based on the ability of the second network node (e.g., UPF) to support MOQ extensions (such as extended reality service (XR service) extensions). The first network node (e.g., SMF) may select the second network node based on the received MOQ service request and the ability of the second network node (e.g., UPF) to support MOQ proxy functionality. Based on local configuration and / or management plane messages from the operator, the SMF may be aware of the UPF's support for MOQ repeater functionality and extensions. The ability of the UPF to support MOQ repeater functionality and extensions may be determined based on local configuration or management plane messages. In the first network node (e.g., SMF), a session request message for a data session and a QUIC-based media (MOC) service may be received from the WTRU. The first network node may determine the MOQ proxy deployment and determine the second network node based on the network proxy deployment. The proxy establishment message may be transmitted by the first network node to the second network node. The session establishment message may be transmitted by the first network node to the WTRU based on the local proxy deployment.

[0227] At 4, the SMF may transmit an N4 session establishment / modification request to the UPF, including an instruction to use the MOQ relay. The instruction may be an N4 rule IE, and may contain an MOQ service flag and / or one or more MOQ relay configuration IEs. When transmitting a relay establishment message to the second network node, the first network node may send the relay establishment message via the N4 interface and include an MOQ service flag or an MOQ relay configuration information element in the relay establishment message.

[0228] At 5, the UPF may create a MOQ repeater instance (e.g., a new MOQ repeater instance) and / or may select an existing MOQ repeater instance for use with the PDU session. The created / selected MOQ repeater instance may be referred to as an "in-network MOQ repeater" instance. The in-network MOQ repeater instance may be collocated with the PSA UPF, with the I-UPF, or with the NF. At 6, the UPF may configure traffic forwarding for the PDU session traffic using rules provided by the SMF via N4. The UPF may configure the MOQ repeater instance (e.g., to accept traffic from the IP address of the WTRU). When determining a second network node (e.g., UPF) for providing MOQ service based on a network proxy deployment, the first network node (e.g., SMF) may obtain MOQ proxy information from a session establishment response received from the second network node (e.g., UPF), and the MOQ proxy information may include the following: MOQ proxy IP address, domain name, or port.

[0229] At 7, the UPF may transmit an N4 Session Establishment / Modification Response to the SMF, including the MOQ Relay Information IE. The MOQ Relay Information IE may include one or more of the following: MOQ Relay IP address, FQDN, (eg, UDP) port, or MOQ Relay Configuration IE.

[0230] At 7b, the SMF may configure MOQ repeater discovery using the MOQ repeater information IE from 7. In an example, the SMF may configure an SRV record in the DNS server (e.g., an entry _moq. <operator-domain-name>). The first network node (e.g., SMF) may include an MOQ Proxy Information Element in the Session Setup message transmitted to the WTRU. In an example, the SMF may configure other discovery techniques (e.g., other DNS-based or DHCP-based methods, etc.). This may be useful for WTRU applications to be able to discover MOQ relays (e.g., in Figure 7 The first network node (e.g., SMF) may obtain network MOQ agent information from the second network node (e.g., UPF) in response to the agent establishment message, and configure the network MOQ agent discovery method based on the network MOQ agent information, so that the WTRU application of the WTRU can discover the network MOQ agent.

[0231] At 8, the SMF may (e.g., after obtaining network MOQ proxy information from the second network node in response to the proxy establishment message) transmit a PDU session establishment / modification response to the WTRU (e.g., via the RAN), which may include a MOQ relay information IE. At 9, the WTRU may determine whether a local MOQ relay may be used (e.g., required) based on, for example, the MOQ relay configuration IE from the configuration / policy information and / or the MOQ relay information IE from the PDU session establishment / modification response. For example, if a MOQ relay usage scenario identifier may be set for a scenario with a local MOQ relay, a local MOQ relay may be used (e.g., required). If a local MOQ relay may be used (e.g., required), the WTRU may select an existing local MOQ relay instance (e.g., or create and select a new MOQ relay instance). The WTRU may collect the IP address / FQDN / port of the selected local MOQ relay instance. The WTRU may configure the discovery of the local MOQ relay through the WTRU application. For example, the WTRU may use a service (SRV) record with a well-known entry in the domain (e.g., _moq. <local-domain-name>), configure a DNS service (e.g., a local DNS service on the WTRU) with, for example, an ALPN "moq" tag and the local MOQ repeater IP address / FQDN / port. In the example, the WTRU may configure other discovery techniques for the local MOQ repeater (e.g., updating the local configuration of the WTRU application, other DNS-based or DHCP-based methods, etc.). For discovering the in-network MOQ repeater, in addition to or in lieu of the configuration at 7b, the WTRU may configure other discovery techniques for the in-network MOQ repeater to enable the WTRU application (e.g., or the local MOQ repeater (if present)) to discover the in-network MOQ repeater (e.g., updating the local configuration of the WTRU application or the local MOQ repeater or using a local DHCP-based or DNS-based discovery technique).

[0232] At 10, the WTRU application may establish a MOQ connection with the AS. The WTRU application may establish a MOQ connection with the AS by sending a DNS request for an SRV record (e.g., for the record "moq. <local-domain-name>", and if unsuccessful, pass a request to the logger "moq. <operator-domain-name>" second request) to discover MOQ repeater information (e.g., IP address / FQDN / port). Based on receiving the DNS response including the discovered MOQ repeater information (e.g., ALPN "moq" tag, IP address / FQDN / port), the WTRU application can initiate communication with the AS through the discovered MOQ repeater. The WTRU application can use other techniques for discovering MOQ repeaters (e.g., local configuration or other DNS / DHCP-based techniques).

[0233] If a local MOQ repeater is used, then upon receiving a connection request from a WTRU application, the local MOQ repeater may use similar techniques (e.g., by transmitting a reference to the SRV record "moq. <operator-domain-name>" DNS request) to discover MOQ repeaters within the network.

[0234] The WTRU application may establish a MOQ connection with the AS through the intra-network MOQ relay, for example, by establishing an HTTP connection with the intra-network MOQ relay and transmitting an extended CONNECT request to the MOQ relay, specifying the AS FQDN and port as the destination. The intra-network MOQ relay may forward the CONNECT request to the AS (e.g., via a MOQ relay-AS HTTP connection) to establish an end-to-end MOQ connection.

[0235] When the connection is established, the WTRU application may establish a MOQ connection with the AS through the local MOQ relay. When a CONNECT request is transmitted to the local MOQ relay, the local MOQ relay may forward the CONNECT request to the in-network MOQ relay, and the in-network MOQ relay forwards the CONNECT request to the AS.

[0236] The WTRU application, MOQ relay, and AS may negotiate extensions (e.g., if needed). For example, the WTRU may send a message to the AS via the MOQ relay including a list of supported / requested extensions. If the MOQ relay does not support the extensions, it may close the connection. The AS may reply with the same list of extensions to indicate its acceptance or a modified list of extensions. The WTRU may accept the list of extensions in the reply or close the connection.

[0237] The WTRU application and the AS may exchange media traffic via the MOQ protocol, for example, following FIG. 8A to FIG. 8C The WTRU application and the AS may use a pre-shared end-to-end encryption key to protect the media and metadata.

[0238] Although the above features and elements are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without the other features and elements.

[0239] Although the implementations described herein may consider 3GPP specific protocols, it should be understood that the implementations described herein are not limited to such scenarios and are applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it should be understood that the solutions described herein are not limited to such scenarios and are also applicable to other wireless systems.

[0240] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (sent via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, built-in hard disks and removable disks), magneto-optical media, and / or optical media (such as compact disk (CD)-ROM disks and / or digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. A first network node, the first network node comprising: A processor, the processor being configured to: receiving a session request message from a wireless transmit / receive unit (WTRU), wherein the session request message requests a data session and requests a media over QUIC (MOQ) service; Determine a MOQ proxy deployment for the MOQ service, wherein the MOQ proxy deployment includes a local proxy deployment and a network proxy deployment; Determining a second network node for providing the MOQ service and creating a network MOQ proxy based on the network proxy deployment; transmitting a proxy setup message to the second network node, wherein the proxy setup message requests the second node to create the network MOQ proxy for the MOQ service, and wherein the network MOQ proxy supports the data session; as well as A session establishment message is transmitted to the WTRU based on the local agent deployment, wherein the session establishment message requests the WTRU to create a local MOQ agent supporting the data session to communicate with the network MOQ agent.

2. The first network node of claim 1 , wherein the processor is configured to determine the MOQ proxy deployment for the MOQ service comprises: The processor is configured to: receiving policy information from a third network node, wherein the policy information comprises at least one of a Policy and Charging Control (PCC) rule or a session rule; and The MOQ proxy deployment is determined using at least one of the PCC rules or the session rules.

3. The first network node of claim 1 , wherein the processor is configured to determine the second network node based on the network agent deployment comprises: The processor is configured to: determining a capability of the second network node to support MOQ proxy functionality; as well as The second network node is selected based on the capabilities of the second network node.

4. The first network node of claim 1 , wherein the processor is configured to determine the second network node based on the network agent deployment comprises: The processor is configured to: determining a capability of the second network node to support an MOQ extension, wherein the MOQ extension comprises an extended reality (XR) service extension; and The second network node is selected based on the capabilities of the second network node.

5. The first network node of claim 1, wherein the proxy setup message is transmitted to the second network node using an N4 interface, and wherein the proxy setup message includes at least one of a MOQ service flag or a MOQ proxy configuration information element.

6. The first network node according to claim 1, wherein the processor is further configured to: A session establishment response message is received from the second network node, wherein the session establishment response message includes MOQ proxy information, and wherein the MOQ proxy information includes one or more of a MOQ proxy IP address, a domain name, or a port.

7. The first network node according to claim 6, wherein the processor is further configured to: The session establishment message is transmitted to the WTRU, the session establishment message including the MOQ proxy information received in the session establishment response message from the second network node.

8. The first network node according to claim 1, wherein the processor is further configured to: receiving network MOQ proxy information from the second network node in response to the proxy setup message; and A network MOQ agent discovery method is determined based on the network MOQ agent information, wherein the network MOQ agent discovery method helps the WTRU discover the network MOQ agent.

9. The first network node of claim 1, wherein the processor is further configured to: A capability of the second network node to provide the network MOQ proxy is further determined based on either a local configuration or a management plane message.

10. The first network node of claim 1, wherein the session establishment message comprises a MOQ Proxy Information Element.

11. A method for a first network node, the method comprising: receiving a session request message from a wireless transmit / receive unit (WTRU), wherein the session request message requests a data session and requests a media over QUIC (MOQ) service; Determine a MOQ proxy deployment for the MOQ service, wherein the MOQ proxy deployment includes a local proxy deployment and a network proxy deployment; Determining, based on the network proxy deployment, a second network node for providing the MOQ service and providing a network MOQ proxy; transmitting a proxy setup message to the second network node, wherein the proxy setup message requests the second node to provide the network MOQ proxy for the MOQ service, and wherein the network MOQ proxy supports the data session; as well as A session establishment message is transmitted to the WTRU based on the local agent deployment, wherein the session establishment message requests the WTRU to create a local MOQ agent supporting the data session to communicate with the network MOQ agent.

12. The method of claim 11, wherein determining the MOQ proxy deployment for the MOQ service comprises: receiving policy information from a third network node, wherein the policy information comprises at least one of a policy and charging control (PCC) rule or a session rule; as well as The MOQ proxy deployment is determined using the at least one of the PCC rules or the session rules.

13. The method of claim 11, wherein determining the second network node based on the network agent deployment comprises: determining a capability of the second network node to support MOQ proxy functionality; as well as The second network node is selected based on the capabilities of the second network node.

14. The method of claim 11, wherein determining the second network node based on the network agent deployment comprises: determining a capability of the second network node to support an MOQ extension, wherein the MOQ extension comprises an extended reality (XR) service extension; as well as The second network node is selected based on the capabilities of the second network node.

15. The method of claim 11, wherein the proxy setup message is transmitted to the second network node using an N4 interface, and wherein the proxy setup message includes at least one of a MOQ service flag or a MOQ proxy configuration information element.

16. The method according to claim 11, further comprising: A session establishment response message is received from the second network node, wherein the session establishment response message includes MOQ proxy information, and wherein the MOQ proxy information includes one or more of a MOQ proxy IP address, a domain name, or a port.

17. The method according to claim 16, further comprising: The session establishment message is transmitted to the WTRU, the session establishment message including the MOQ proxy information received in the session establishment response message from the second network node.

18. The method according to claim 11, further comprising: receiving network MOQ proxy information from the second network node in response to the proxy establishment message; as well as A network MOQ agent discovery method is determined based on the network MOQ agent information, wherein the network MOQ agent discovery method helps the WTRU discover the network MOQ agent.

19. The method according to claim 11, further comprising: A capability of the second network node to provide the network MOQ proxy is further determined based on either a local configuration or a management plane message.

20. The method of claim 11, wherein the session establishment message includes a MOQ proxy information element.

Images