Network devices associated with reliable transmission of pdu sets

Abstract

Disclosed herein are systems, methods, and instrumentalities associated with reliable transmission of protocol data unit (PDU) sets. A network device may receive an indication that a PDU set is to be delivered in a reliable manner over a wireless communication network. The network device may determine reliability metadata associated with the PDU set based on the received indication. The network device may transmit the reliability metadata associated with the PDU set to another device in the wireless communication network. The network device may perform one or more operations for a PDU of the PDU set based at least on the reliability metadata associated with the PDU set.

Description

NETWORK DEVICES ASSOCIATED WITH RELIABLE TRANSMISSION OF PDU SETSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of Provisional U.S. Patent Application No. 63 / 456,250, filed March 31 , 2023, the disclosure of which is incorporated herein by reference in its entirety.BACKGROUND

[0002] Traffic in a wireless communication network may be transmitted using various types of communication protocols, including reliable transport protocols such as a transmission control protocol (TCP). Using these reliable transport protocols to transmit the traffic may create challenges and opportunities for network devices and / or wireless transmit / receive units (WTRUs).SUMMARY

[0003] Disclosed herein are systems, methods, and instrumentalities associated with reliable transmission of protocol data unit (PDU) sets. According to embodiments of the disclosure, a network device (e.g., a core network device such as a user plane function (UPF) or a radio access network (RAN) device such as a base station) may receive an indication that a PDU set is to be delivered in a reliable manner over a wireless communication network. The network device may determine reliability metadata associated with the PDU set based on the received indication. The network device may transmit the reliability metadata associated with the PDU set to another device (e.g., a WTRU) in the wireless communication network. The network device may perform one or more operations for a PDU of the PDU set based at least on the reliability metadata associated with the PDU set.

[0004] In examples, the network device may determine a level of service for the PDU that is different from a level of service provided to one or more PDUs of a different PDU set. The level of service may be associated with a quality of service (QoS) flow or a transmission priority.

[0005] In examples, the network device may determine an importance (e.g., a priority) of the PDU within the PDU set. The importance of the PDU within the PDU set may be determined based on the position of the PDU in the PDU set (e.g., as indicated by an index of the PDU within the PDU set). The network device may indicate the importance of the PDU to the other device in the wireless communication network. The network device may determine whether to drop or retransmit the PDU based on the importance of the PDU in the PDU set. In examples, the network device may transmit the PDU to the other device in the wireless communication network, receive an indication (e.g., a negative acknowledgment or NACK) that thePDU was not received by the other device, and determine whether to retransmit the PDU to the other device (or drop the PDU).

[0006] In examples, the network device may close a transport stream associated with the PDU set based on a congestion condition, a number of transmission failures associated with the PDU set, or an indication from the other device in the wireless communication network to close the transport stream.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0011] FIG. 2 is a diagram illustrating examples of entities and messages that may be involved in providing support for the reliable transmission of PDU sets.

[0012] FIG. 3 is a diagram illustrating an example of determining and transmitting reliability metadata associated with a PDU set in the downlink of a wireless communication network.

[0013] FIG. 4 is a diagram illustrating an example of determining and transmitting reliability metadata associated with a PDU set in the uplink of a wireless communication network.

[0014] FIG. 5 is a diagram illustrating an example of providing an acknowledgment or a negative acknowledgment for the delivery of a PDU or a PDU set.

[0015] FIG. 6 is a diagram illustrating an example of closing a PDU set or a transport stream associated with the PDU set.DETAILED DESCRIPTION

[0016] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communicationssystems 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 multicarrier (FBMC), and the like.

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

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

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

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

[0021] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

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

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

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

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

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

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

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

[0029] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be 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.

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

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

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

[0033] Although the transmit / receive element 122 is depicted in FIG. 1 B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, 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.

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

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

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

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

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

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

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

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

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

[0043] The CN 106 shown in FIG. 1 C 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 part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

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

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

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

[0051] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / 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.

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

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

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

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

[0056] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for802.11 ah is 6 MHz to 26 MHz depending on the country code.

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

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

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

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

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

[0062] The CN 115 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

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

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

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

[0070] When used herein, the term QUIC may refer to a family of transport protocols, and the term MOQ (media over QUIC) may refer to a family of protocols for carrying media contents over QUIC. In examples, MOQ may include real-time transport protocol (RTP) over QUIC. QUIC may support reliable streams (e.g., reliable datagrams) and unreliable streams (e.g., unreliable datagrams). These streams may be multiplexed within the same QUIC connection. Some MOQ protocols may carry media segments via reliable streams (e.g., in RTP-over-QUIC datagrams with ACK / NACK enabled, in RTP-over-QUIC streams, etc.). Some MOQ protocols may use unreliable datagrams to carry media segments (e.g., in RTP-over- QUIC datagrams). An intermediate node that may be configured to terminate QUIC connections and / or relay MOQ protocols between QUIC connections may be called a MOQ relay or a MOQ proxy. A MOQ relay may enable a network to obtain metadata associated with media data and may use such metadata to provide network support for the media data (e.g., extended reality (XR) traffic). For example, a MOQ relay that may reside in a wireless communication network node (e.g., in a user plane function (UPF), a base station, and / or a WTRU) may enable support for XR traffic carried over a MOQ protocol. Other reliable media transport protocols may also be used, including, e.g., RTP over UDP (e.g., when using ACK / NACK), RTP over other reliable transport protocols (e.g., stream control transmission protocol), dynamic adaptive streaming over HTTP (DASH) over TCP, low-latency DASH (LL-DASH) over TCP, etc.

[0071] It may be challenging to carry media flows, such as application traffic with high-throughput and low latency requirements (e.g., video conferencing, XR, etc.), in a wireless communication network. Techniques may be implemented in the wireless communication network to improve network capacity and / or energy efficiency, or to reduce the impact of packet losses on user experience, etc. For example, the wireless communication network may be configured to handle groups of packets based on their criticality to the user experience. Some groups of data packets may include application data units or application control information that an application may handle together (e.g., decoded together). The term “PDU set” may be used herein to refer to such a group of data packets (e.g., which may carry the payload of one or more application data units). For example, a PDU set may correspond to the data packets of a network application layer (NAL) unit. A PDU set may include multiple PDUs, each of which may include one or more data packets or one or more data units.

[0072] A wireless communication network may be configured to handle different PDU sets differently (e.g., perform differentiated handling of the PDU sets), for example, to support high-throughput low-latency media flows. The wireless communication network may, for example, prioritize certain PDU sets over other PDU sets in case of congestion. The wireless communication network may, for example, perform differentiated data handling (e.g., video decoding) based on the fact that a first set of application data units (e.g., corresponding to a first PDU set) may depend on a second set of application data units (e.g.,corresponding to a second PDU set). For example, P-frames of a video stream may depend on l-frames of the video stream, higher-layer data may depend on lower-layer data, etc., so devices of the wireless communication network may be configured to devise a plan for differentiated data handling before processing the first set of application data units. A wireless communication network device may selectively drop data packets that may depend on an already lost application data unit. The wireless communication network device may limit a wake-up time (e.g., of one or more radios) associated with the transmission and reception of data. For example, a packet scheduler (e.g., in an RAN node such as a base station) and / or a WTRU may synchronize their transmission and / or listening times based on the size and / or periodicity of traffic, a delay budget, expected jitter specific to an application, etc.

[0073] The term “reliable PDU sets” may be used herein to refer to PDU sets transmitted in a reliable manner (e.g., using a reliable protocol). A reliable PDU set may be associated with, for example, a MOQ stream, a TCP stream, a stream control transmission protocol (SCTP) stream, data transmitted using RTP over UDP (e.g., when using ACK / NACK), etc. One or more of the following may be true for a reliable PDU set. Reliability may be achieved using positive or negative acknowledgements of reception, which may trigger retransmission of un-received or un-acknowledged PDUs by a sender. A reliable PDU set may be available to an application if the PDU set is received in its entirety. An application may be able to access a partially received PDU set, in which case an initial, contiguous portion of the received PDU set payload may be accessed. For example, the application may access the payload starting from the first PDU of the PDU set until a first not-yet-received PDU of the PDU set (e.g., until encountering a first hole or gap in the received data). The order of PDUs may refer to the order of PDU set data inside those PDUs. For example, the first PDU of a PDU set may include a first byte of the PDU set data. While the delivery order of PDUs may not be guaranteed by a network, a reliable protocol may ensure a proper ordering of the PDU set data presented to an application.

[0074] Low-latency and / or real-time media traffic may be transmitted using datagram-based protocols (e.g., an RTP), using reliable transport protocols (e.g., QUIC protocols), or over other classes of reliable transport protocols such as TCP or LL-DASH. Using a reliable transport protocol for low-latency and / or real time media traffic may create challenges and / or opportunities for network devices and / or WTRUs.

[0075] Network devices (e.g., a RAN node such as a base station, a UPF, etc.) and / or WTRUs may adopt reliability-specific or reliability-related data handling mechanisms for downlink and / or uplink traffic flows, for example, to improve the handling of high-throughput low-latency traffic when the traffic is carried over a reliable transport protocol. In examples, earlier packets may be more important than later packets in a reliable stream (e.g., if an application may use a partial stream). A lost packet in a stream may prevent a receiving endpoint from using the rest of the stream. Reliability-specific data handling may focus networkresources on transmitting earlier packets, for example, if multiple packets are retransmitted and network resources are insufficient to retransmit those packets successfully and / or on-time. A lost packet may lead to a lost round-trip time (RTT), since a recipient may send back a negative acknowledgement (NACK) identifying one or more missing PDUs or missing PDU data, and a sender may, in response, transmit (e.g., retransmit) a PDU carrying the missing data. Reliability-specific data handling may limit this issue, e.g., by using layer-2 recovery more intensively to reduce the occurrence of the issue and / or by closing a stream more aggressively if it is determined that the recovery of lost packets may lead to a failure in meeting a delay budget (e.g., for a relevant PDU set).

[0076] Certain URLLC features, such as duplicating transmissions through different base stations (e.g., gNodeBs), may consume extra network resources. These features may not be suitable for low-latency high-throughput traffic (e.g., XR traffic). Mechanisms may be implemented in a wireless communication system to improve a user’s quality of experience (QoE). These mechanisms may include mechanisms for selecting which packet(s) to drop in case of congestion (e.g., based on reliability metadata), while minimizing the impact on network resource usage. These mechanisms may be collectively referred to herein as “XR support,” “low-latency high-throughput traffic support,” or “PDU set handling support” mechanisms.

[0077] With some wireless communication technologies, reliability information associated with a PDU set may not be available to nodes or devices (e.g., a base station or a WTRU) in the network, and reliable handling of PDU sets (e.g., delivering the PDU sets in a reliable manner) may not be enabled for these nodes or devices. For example, with certain wireless communication technologies, XR application data units may be transported in a PDU set, which may correspond or include RTP datagrams, and the processing of the PDU set may not consider reliability characteristics of the PDU set. As such, a lost packet may prevent an application from further accessing data in a stream, may trigger negative acknowledgment or retransmission of the lost packet between transmission endpoints, may hinder or prevent the reconstruction of a PDU set, and / or may offset sequence numbering in the network. With these wireless communication technologies, metadata associated with a PDU set that may be transmitted to a UPF, RAN, or WTRU (e.g., along with data packets of the PDU set) may not include any indication of reliability for the PDU set.

[0078] When referred to herein, metadata associated with a PDU set (also referred to as PDU set metadata) may include information (e.g., information elements) associated with application data and used by a communication network to provide enhanced support for a class of traffic (e.g., XR traffic) that may be structured as a PDU set. For example, when referred to herein, PDU set metadata may include a PDU set identifier, a PDU set first packet indication, a PDU set last packet indications, a PDU set size, a packetsequence number within a PDU set, a PDU set importance indication, a PDU set integrated indication (PSII) (e.g., whether all PDUs are needed for an application layer to use the PDU set), and / or the like. The PDU set metadata may include other metadata, such as, for example, inter-PDU set dependency (e.g., a list of other PDU sets that the current PDU set may depend on).

[0079] A reliability attribute may be assigned to and / or transmitted with a PDU set over a wireless communication network. The reliability attribute may be used (e.g., by a WTRU and / or a network device such as a base station or a UFP) to enhance the processing or handling (e.g., differentiated handling) of the PDU set (e.g., to enhance support for XR traffic). The techniques described herein may be applicable to media data transported over reliable streams and connections, such as those using MOQ protocols, TCP-based media protocols (e.g., DASH and its variants), or other reliable media protocols (e.g., including those described herein or may become available in the future). In examples, a protocol may allow for multiplexing media segments of a reliable transport stream with media segments of an unreliable transport stream, in which case the techniques described herein may be applied to the media segments transmitted in the reliable transport stream. The techniques described herein may enhance XR traffic handling as well as handling of other types of traffic (e.g., high-throughput and / or low-latency traffic). The techniques described in the context of XR support may also be used to handle other classes of traffic and may be referred to herein as XR support only for ease of description.

[0080] FIG. 2 illustrates examples of entities and / or messages that may be involved in the transmission of data streams (e.g., XR data streams) between a source (e.g., an application server (AS), a cloud server, an edge cloud server or a WTRU) and a destination (e.g., an AS, a cloud server, an edge cloud server, or a WTRU). Support for such data streams may be provided in a downlink flow (e.g., a media broadcast), an uplink flow (e.g., a live media contribution by an app on a WTRU), or a combination of uplink and downlink flows (e.g., a 2-way live media session). When referred to herein, a relay component may include a WTRU, a network device, or a network function (e.g., a UPF) that may be configured to generate or extract reliability metadata from a media flow or a set of medial packets, and associate the reliability metadata with a PDU set of the media flow or the set of media packets. Such a relay component may include a MOQ relay, a TCP proxy, a multiplexed application substrate over QUIC encryption (MASQUE) proxy, an HTTP proxy, an RTP relay, a deep packet inspection (DPI) component, a WTRU application component, etc. The relay component may be collocated with a UPF and / or with an edge server, for example, to enable support for downlink traffic. The relay component may be collocated with a WTRU, for example, to enable support for uplink and / or sidelink traffic. The relay component may be configured to generate or extract metadata (e.g., PDU set metadata) associated with a media flow. In examples, the relay component may extract metadata from unencrypted header fields (e.g., as may be the case with a DPI component or an RTP relayconfigured to extract metadata from unencrypted RTP headers or extension headers). In examples, the relay component may be part of a secure connection and may have access to encrypted headers (e.g., as may be the case with a MOQ relay, a MASQUE proxy, or an RTP relay with access to session keys). The relay component may forward media data PDUs, together with reliability metadata and / or PDU set metadata, to an XR support component (e.g., a network device or a WTRU).

[0081] The discovery of and / or connection to a relay component (e.g., by a WTRU) may be context dependent. In examples (e.g., when MOQ or MASQUE may be used), a relay component may be discovered through configuration or other protocols (e.g., during PDU session establishment), and a WTRU may initiate (e.g., explicitly) a connection to a server through the relay component. In examples (e.g., when TCP or DPI may be used), the WTRU may initiate a connection to a server, and the communication network associated with the connection may include (e.g., in a manner transparent to the WTRU and / or other devices) a relay component in the path of the connection. When referred to herein, a UPF or a relay component may include a combination of a user plane function and a relay function (e.g., the relay function may be collocated with the user plane function). A UPF and a relay component may be collocated with an edge server. Media flows related to an application (e.g., a single application) may be handled through a relay component (e.g., a single relay component) that may be located on a UPF or an edge server, or through different relay components that may be located on one or more UPFs or edge servers. A decision regarding whether to use one or multiple relay components may depend on the protocol used to carry the traffic of different modalities (e.g., audio and / or video). An XR support component (e.g., a single XR support component in a gNodeB) may be configured to handle multiple media flows (e.g., using different relay components) since, for example, different relays may be able to communicate metadata to the XR support component using common signaling (e.g., using a tunneling protocol such as GTP-U headers).

[0082] The reliability metadata described herein may include an indication (e.g., a reliability indication provided as an information element of the reliability metadata) that a PDU set (or a packet) may belong to a specific reliable transport session (e.g., a QUIC stream or a TCP / SCTP session). Such an indication may be associated with one or more PDUs (e.g., all PDUs) of the PDU set and may indicate that the PDUs may be associated with acknowledgment messages and / or that the PDUs may be retransmitted in case of a loss. The indication may be used (e.g., by a WTRU, a base station, and / or a UPF) to determine if a reliable delivery mechanism as described herein may be applied to the PDUs.

[0083] The reliability metadata described herein may include an indication that a PDU set or a group of PDU sets may be carried in a stream that may be stopped independently from another PDU set or another group of PDU sets. The indication (e.g., which may also be referred to as an independent stream indication) may be provided as a flag and / or an ID such as a stream ID. The reliability metadata describedherein may include an indication that a stream is not an independent stream (e.g., if multiple PDU sets share a single reliable stream) and, as such, the stream may not be canceled independently from other PDU sets (e.g., as the cancellation may impact the other PDU sets). The indication (e.g., of an independent or non-independent stream) may be provided to a network node device such as a UPF, a base station, or a WTRU.

[0084] A relay component, such as a WTRU, a base station, or a UPF, may be configured to determine reliability metadata associated with a PDU set, which may include a reliability indication. If multiple (e.g., all) packets associated with the PDU set are to be transported in a reliable manner (e.g., using a reliable transport protocol or mechanism such as via a QUIC, TCP, or SCTP stream), the relay component may set the reliability indication associated with the PDU set to true (or an equivalent value). If a reliable mechanism (e.g., RTP using ACK / NACK) is used by an application layer to transmit the PDU set, and the relay component detects the use (e.g., based on signaling associated with the reliable mechanism such as session description protocol (SDP) parameters, QUIC transport parameters, or other parameters), then the relay component may set the reliability indication associated with the PDU set to true (or an equivalent value). Conversely, if the PDU set is not to be transported in a reliable manner, the relay component may set the reliability indication associated with the PDU set to false (or an equivalent value). In examples, a WTRU or network device (e.g., a UPF) may (e.g., based on configuration) set a reliability indication for a PDU set to true if the PDU set has unknown reliability. In these cases, the WTRU or network device may apply a mechanism described herein to the PDU set as if it were to be transported in a reliable manner.

[0085] In examples, a WTRU or network device may determine and / or convey a degree of reliability for a PDU set in a non-binary fashion (e.g., using enumerated values such as [reliable, semi-reliable, unreliable] or using integer reliability values corresponding to different levels of reliability). For example, a PDU set carrying PDUs based on a protocol with limited retransmissions may be labeled as “semi-reliable.” In these examples, one or more of the mechanisms described herein may be applied to the PDU set with a range of reliability values. For ease of description, a binary reliability indication may be assumed in the examples provided herein, but those skilled in the art will appreciate that some or all of the examples may still be applicable if non-binary reliability indications are used. In examples, a reliability indication may be used to convey additional information, such as the type of reliability mechanism used (e.g., transport versus application layer mechanisms).

[0086] With respect to the independent stream indication described here, if multiple (e.g., all) packets in a PDU sets are carried in a dedicated stream (e.g., in SCTP or QUIC), then the independent stream indication may be set to true (or a value associated with the stream ID). Otherwise, the independent stream indication may be set to false (or an equivalent value).

[0087] As an example of how reliability metadata may be determined, if a relay component (e.g., an MOQ relay) identifies a QUIC stream as corresponding to a PDU set and associates PDU set metadata (e.g., as described herein) with the PDU set, the relay component may set the reliability indication to true for the PDU set. If the PDU set includes a QUIC datagram or an application layer reliability mechanism is not be used for the PDU set, the relay component may set the reliability indication to false for the PDU set. If an application layer reliability mechanism is signaled (e.g., via one or more QUIC transport parameters), the relay component may set the reliability indication to true for the PDU set.

[0088] A relay component (e.g., a WTRU or a network device) may transmit reliability metadata to an XR support component, for example, along with PDU set metadata. The relay component may transmit the PDU set metadata to the XR support component (e.g., using general packet radio services (GPRS) tunneling protocol user plane (GTP-U)), for example, if the relay component is collocated with a UPF in an access network. The relay component may encode the reliability metadata and / or PDU set metadata in a GTP-U header of the GTP-U packets associated with the PDU set. The relay component may encode the reliability metadata and / or PDU set metadata using other methods (e.g., in a tunnel protocol header, using a UDP or IP-based mechanism, etc.).

[0089] A relay component (e.g., a WTRU or a network device) may transmit reliability and / or PDU set metadata to a network function (e.g., to a UPF) using a tunnel header field (e.g., GTP) or other mechanisms (e.g., a UDP or IP-based mechanism), for example, if the relay component is collocated with an edge server. In this way, the network function (e.g., UPF) may obtain access to the metadata, even if the PDUs are encrypted, which may be the case for MOQ traffic. The network function may transmit reliability and / or PDU set metadata to an access network (e.g., a base station) using, for example, a GTP-U header field or other mechanisms (e.g., a UDP or IP-based mechanism).

[0090] A relay component may transmit reliability and / or PDU set metadata to an XR support component in a WTRU as parameters associated with data packets and / or through one or more function calls (e.g., the metadata may be passed to a service data adaption protocol (SDAP) layer of the WTRU). For example, the relay component may transmit reliability and / or PDU set metadata to the XR support component in the WTRU if the relay component is collocated with the WTRU.

[0091] A relay component may transmit reliability and / or PDU set metadata to an XR support component collocated with a RAN node (e.g., a base station) in one or more layer-2 header fields associated with uplink packets. For example, the relay component may transmit the reliability and / or PDU set metadata to the XR support component collocated with the RAN node in one or more layer-2 header fields if the relay component is collocated with the WTRU.

[0092] Reliability metadata may include a reliability indication and / or an independent stream indication, for example, if the reliability metadata is encoded in a protocol header. The reliability indication may be signaled explicitly (e.g., via a reliable-PDU-set flag) or implicitly. For example, a protocol ID value corresponding to TCP / SCTP may be used to convey a reliability indication value. Such a protocol ID value may not be sufficient for QUIC since, for example, QUIC may be used to carry multiplexed reliable and unreliable data flows in a single connection.

[0093] In the examples provided herein, reliability metadata may be a part of the PDU set metadata, or may be separate from (and conveyed along with) the PDU set metadata.

[0094] An XR support component as described herein may be a component or function that may implement one or more XR support features (e.g., as described herein). An XR support component may be located in an RAN (e.g., in a base station or gNodeB), in a WTRU (e.g., in the PDCP layer and / or a lower layer), and / or in a core network function or device (e.g., in a UPF). An XR support component may be integrated with other network or WTRU components or functions (e.g., a transmission scheduling function). An XR support component may use metadata, including reliability metadata and / or PDU set metadata, associated with a media flow. A core network function (e.g., a UPF) may host aspects of an XR support component, such as the aspects for associating PDUs with QoS flows based on reliability metadata, or for associating PDUs with per-PDU effective importance, as described herein.

[0095] XR support features may be implemented by an XR support component. For example, the XR support features may include PDU set classification and marking, relay of XR service marking, support for XR path selection, XR packet scheduling, XR congestion handling (e.g., congestion marking of packets), selection of packets for congestion marking, dropping and / or reordering, requesting an endpoint to close a PDU set, path selection, support for XR synchronization (e.g., buffering to minimize inter-modal delay, measuring and reporting RTT and jitter, etc.). The XR support features may be enabled by reliability metadata and / or may include differentiated services for reliable PDUs, degressive importance of PDUs (e.g., ranked in a descending order from earlier PDUs or packets to later PDUs or packets) in a PDU set, ACK / NACK support, and / or support for closing a reliable PDU set. The term “XR support features” or “XR support services” may be used interchangeably herein.

[0096] Differentiated services for reliable PDUs or a reliable PDU set may refer to providing different levels of services (e.g., by a WTRU, RAN node, or core network function such as a UPF) to PDUs of a reliable PDU set (e.g., a PDU set transported in a reliable manner) than PDUs of an unreliable PDU set (e.g., a PDU set transported in an unreliable manner). Degressive importance of PDUs in a PDU set may refer to prioritizing the use of network resources (e.g., by a WTRU, RAN node, or core network function such as a UPF) for the retransmission of earlier packets in the PDU set over the retransmission of laterpackets in the PDU set. The degressive importance of the PDUs may be determined based on the effective importance of each PDU, which may be derived from PDU set importance (or nominal PDU set importance) applicable to multiple (e.g., all) PDUs of the PDU set. ACK / NACK support may refer to the transmission (e.g., by a WTRU, RAN node, or core network function such as a UPF) of an NACK for a packet associated with a reliable PDU set if the packet is lost, and / or the transmission of an ACK if the packet associated with the reliable PDU set is transmitted successfully. A relay component that receives an ACK / NACK of a packet may delay its own acknowledgement of the packet to a sending endpoint of the packet until the ACK / NACK is received from a receiving endpoint (e.g., from a RAN node) of the packet (e.g., to improve the response time for retransmissions). Close reliable PDU set support may refer to the consideration (e.g., by an XR support component and / or a relay component such as a WTRU, RAN node, or core network function such as a UPF) of reliability metadata to decide whether to close a PDU set (e.g., a stream associated with the PDU set) and / or send an indication of the closing decision (e.g., via a CLOSE_RELIABLE_PDU_SET(pdu_set_id) message). Such an indication may be sent, for example, over a GTP-U connection between a base station and a UPF, or between an XR support component and a relay component inside a WTRU.

[0097] An XR support component may decide to send a closing indication of a PDU set (e.g., via a CLOSE_RELIABLE_PDU_SET message) to a relay component. For example, if the XR support component determines that the PDU set may not be delivered within a PDU set delay budget (PSDB), the XR support component may decide to send a CLOSE_REUABLE_PDU_SET message to a relay component. Upon reception of the CLOSE_RELIABLE_PDU_SET message, the relay component may close a corresponding (e.g., QUIC) stream (e.g., associated with the PDU set) between the relay component and an (e.g., each) endpoint. For example, the relay component may send a RESET_STREAM QUIC message to one or both endpoints of a stream associated with a PDU set to close the stream.

[0098] An application endpoint may close a stream (e.g., corresponding to a PDU set) at any time, e.g., if the application endpoint determines that the stream data may be delivered too late to be useful to the application. A relay component may choose to close a stream if certain thresholds are met (e.g., a PSDB or jitter may be over a threshold). A network function (e.g., UPF), RAN node, or WTRU may be informed about the closing of a stream (e.g., as soon as possible) so that the device may stop sending and requesting PDUs associated with the stream or the PDU set. To enable this, a relay component, in response to determining that the stream may be closed (e.g., upon detecting a RESET_STREAM message sent by an endpoint), may send a CLOSE_RELIABLE_PDU_SET indication to an XR support component that may be associated with the PDU set (e.g., PDU set ID) corresponding to the closed stream.

[0099] The features and functions described herein may be applicable to non-XR traffic, such as other types of low-latency, high-throughput traffic. The features and functions described herein may be applicable to traffic handled by a wireless communication network using PDU set-based QoS handling. For ease of description, the features and functions described herein may be described as being related to XR, XR support, or XR support features, but those skilled in the art will appreciate that the features and functions described herein may be applicable to other types of traffic and may be referred to as PDU set handling support components, PDU set handling support features, etc.

[0100] Policy and / or configuration information associated with XR (or other types of) services may be provided to nodes or devices (e.g., WTRUs, base stations, core network devices or functions, etc.) in a wireless communication network. The policy and / or configuration information may include an indication of whether the policy or configuration information applies to a reliable PDU set, a non-reli able PDU set, or both types of PDU sets. The policy and / or configuration information may include one or more information elements indicative of a PDU set importance (e. g., degressive PDU set importance). For example, such policy and / or configuration information may include an indication of whether and / or how to apply a PDU set importance indicated in the policy and / or configuration information. As another example, the policy and / or configuration information may identify service flows to which the policy and / or configuration information may be applicable (e.g., based on a flow identifier such as a 5-tuple, a domain name, an application name, etc.). As yet another example, the policy and / or configuration information may include parameters for calculating an effective PDU importance based on a nominal PDU set importance (e.g., a constant named “delta importance” may be used for the calculation, where the effective PDU importance of PDU #n of the PDU set may be calculated as nominal_pdu_set_importance - n * deltajmportance).

[0101] The policy and / or configuration information associated with XR (or other types of) services may include one or more information elements associated with closing a reliable PDU set. For example, the policy and / or configuration information may include an indication of whether the closing of a reliable PDU set is supported. As another example, the policy and / or configuration information may identify the service flows to which the policy and / or configuration information is applicable (e.g., based on a flow identifier such as a 5-tuple, a domain name, an application name, etc.). As yet another example, the policy and / or configuration information may include parameters that may influence the determination of whether to close a reliable PDU set. These parameters may include, for example, a time threshold relative to a PDU set delay budget (e.g., “PSDB - 5ms,” “PSDB + 0ms,” etc.), after which the closing of a PDU set may be applied.

[0102] The policy and / or configuration information associated with XR (or other types of) services may include information elements associated with ACK / NACK (e.g., early ACK / NACK) that may be transmittedby a network device or a WTRU. For example, the policy and / or configuration information may include an indication of whether an ACK / NACK associated with a PDU from a reliable PDU set is supported. As another example, the policy and / or configuration information may identify the service flows to which the policy and / or configuration information is applicable (e.g., based on a flow identifier such as a 5-tuple, a domain name, an application name, etc.). As yet another example, the policy and / or configuration information may include parameters that may influence the determination to send ACK / NACK messages to a relay component. These parameters may include, for example, the nature of an ACK / NACK message (e.g., an ACK comprising a list of acknowledged packets or data segments, an NACK comprising a list of missing packets or data segments, etc.), the number of ACK / NACK to send for a given PDU set, etc.

[0103] The policy / configuration information described herein may be provided as part of policy and charging control (PCC) rules. For example, a network function (e.g., an SMF) may obtain one or more PCC rules from another network function (e.g., a PCF), and may provide related rules such as URSP rules, QoS rules, QoE rules, etc. to a WTRU, a base station, and / or a UPF. These related rules may include the policy and / or configuration information described herein. The WTRU, base station, and / or UPF may use the policy and / or configuration information to determine whether to provide a reliable mechanism for transmitting a PDU set, as described herein, and may configure the reliable mechanism and / or perform operations for the PDU set using the reliable mechanism.

[0104] In examples, a relay component (e.g., which may reside in a WTRU) may determine reliability metadata and / or other PDU set metadata associated with a PDU set and transmit the metadata to another entity such as an XR support component (e.g., which may reside in the WTRU or in a RAN node) that may be configured to provide XR (or other types of traffic) support services based on the reliability metadata and / or the PDU metadata. For example, the WTRU may obtain a PDU associated with the PDU set (e.g., the PDU set may be associated with an application running on the WTRU) and the XR support component on the WTRU may use metadata associated with the PDU set (e.g., reliability metadata and / or PDU set metadata) to improve the service (e.g., from a QoS perspective) associated with the PDU or PDU set. The WTRU may receive an ACK / NACK (e.g., from a lower layer of the WTRU or from a base station) associated with the PDU, identify a lost packet, and retransmit the PDU in response. The WTRU may receive (e.g., from the lower layer or the base station) a message (e.g., a CLOSE_RELIABLE_PDU_SET message) indicating that the PDU set is to be closed. Based on the message, the WTRU may determine one or more streams associated with the PDU set (e.g., based on a PDU set ID) and may close the one or more streams (e.g., towards an application server (AS) and / or the WTRU). A network function or device such as a UPF may receive a message from a RAN node (e.g., such as a base station) requesting theretransmission of a PDU or the closing of a PDU set. Based on the message, the network function or device may retransmit the PDU or close a stream associated with the PDU set.

[0105] A network node or device (e.g., a RAN node such as a base station) may receive a PDU associated with a PDU set and reliability and / or PDU set metadata associated with the PDU set. Based on the reliability and / or PDU set metadata, the network node may associate the PDU with one or more levels of services (e.g., as indicated by a QoS identifier such as a 5G QoS identifier (5QI), a PC5 QoS identifier (PQI), and / or a QoS flow priority level), which may be different than the level of services provided to PDUs of a different PDU set (e.g., an unreliable PDU set). The network node may receive or determine an importance value associated with a PDU (e.g., an effective PDU importance value) that may decrease with respect to the position of the PDU (e.g., as indicated by a PDU sequence number) in the PDU set. The network node may determine to retransmit or drop the PDU (e.g., in response to receiving a NACK associated with the PDU) based on the effective PDU importance value of the PDU (e.g., within the PDU set and / or across multiple PDU sets). The network node may decide not to transmit a PDU and may inform a core network function (e.g., a UPF) about the decision (e.g., the network node may inform the UPF about the non-transmission of the PDU instead of waiting for a peer to detect that the PDU is missing and send an ACK / NACK). This may allow the UPF to determine whether to retransmit the PDU or take another action (e.g., close a relevant stream). The network node may detect an unsuccessful transmission of the PDU and may send an ACK / NACK message to another device (e.g., a UPF). The network node may receive a retransmitted PDU from the UPF and forward the PDU to a peer. The network node may determine to close the PDU set associated with the PDU and send a corresponding message (e.g., a CLOSE_RELIABLE_PDU_SET message) to the UPF. The network node may receive and / or forward a message related to the closing of a stream to a transmission endpoint. This may happen, for example, if the message is encrypted and the network node is unable to decrypt the message, while the transmission endpoint may be able to decrypt it.

[0106] A network function or device (e.g., a UPF or edge server with a relay component residing therein) may determine reliability metadata associated with a PDU set and transmit the reliability metadata to an XR support component (e.g., which may reside in a RAN node such as a base station) configured to provide XR support services based on the reliability metadata. The network function or device may receive a PDU of the PDU set and send the PDU to the XR support component (e.g., together with the reliability metadata for the PDU set and / or other PDU set metadata). The XR support component may use the reliability metadata to enhance a service associated with the PDU (e.g., to enhance the QoS of the PDU). The network function or device may receive an ACK / NACK from the XR support component (e.g., a RAN node), and may identify a lost packet data and retransmit the PDU. The network function or device may receive amessage regarding the closing of a PDU set (e.g., a CLOSE_RELIABLE_PDU_SET message) from the XR support component (e.g., which may reside in a RAN node). The network function or device may retrieve one or more streams associated with the PDU set (e.g., based on a PDU set ID) and may close the one or more streams (e.g., towards an AS and / or a WTRU) based on an event (e.g., based on an indication of transmission failures). The network function or device may receive a message from the XR support component requesting a PDU retransmission or the closing of a PDU set. Based on the message, the network function or device may retransmit the PDU or close a stream associated with the PDU set.

[0107] FIG. 3 illustrates an example of determining reliability metadata and transmitting the reliability metadata to an XR support component in an example downlink media distribution scenario. As shown in FIG. 3, a first WTRU may, at 0a, receive policy and / or configuration information (e.g., as described herein) from a network device. In examples, the policy and / or configuration information may be received in an NAS-SM message from an SMF. In examples, the policy and / or configuration information may be associated with a PDU session or a PDU set. In examples, the policy and / or configuration information may be received in an NAS-PCF message from a PCF in the form of a policy that the WTRU may associate with a PDU session, a PDU set, or an application traffic flow.

[0108] At Ob of FIG. 3, an application (e.g., a media streaming or XR application) on the first WTRU may initiate communication with one or more peers (e.g., a second WTRU) or a server (e.g., an application server). In examples, the first WTRU may discover (e.g., explicitly) a relay component (e.g., a UPF) and may establish the communication with the one or more peers or the server through the relay (e.g., for media flows over MOQ or using a MOQ relay). In examples, the first WTRU may establish communication with a server and a network device may include one or more relay components in the path of a media flow (e.g., a TCP flow through a transparent TCP proxy as a relay, a DPI component as a relay, etc.) between the first WTRU and the server. At 0c of FIG. 3, an application session may be established between the first WTRU and a peer (e.g., an AS or a second WTRU).

[0109] At 1 a and / or 1 b of FIG. 3, the server (e.g., an AS) may transmit media data (e.g., one or more PDUs) and metadata (e.g., PDU set metadata as described herein) associated with the media data, which may identify and / or characterize a PDU set associated with the media data. The metadata may be associated with the media data in an application protocol dependent manner. For example, a MOQ relay may communicate the metadata using an OBJECT message header and / or QUIC signaling (e.g., via a QUIC stream offset field and / or end flag, a QUIC packet number, etc.).

[0110] At 2a, the relay component (e.g., UPF) may determine reliability metadata for a PDU set associated with the media data. As described herein, the reliability metadata may include, for example, a reliability indication and / or an independent stream indication for the PDU set. The relay component (UPF)may determine the reliability metadata using information collected earlier, such as transport protocol features (e.g., QUIC transport parameters) that may have been identified during connection establishment. The relay component may retrieve the PDU set metadata from a media flow. For example, if the media transport protocol is RTP, the relay component may obtain the PDU set metadata from RTP headers and / or RTP extension headers. If the media transport protocol is MOQ, the relay component may obtain the PDU set metadata from MOQ metadata (e.g., delivery order, message length, etc.) and / or underlying QUIC signaling (e.g., QUIC stream offset and end flag, QUIC stream ID, etc.). In examples, metadata for the PDU set may be placed at the beginning of the PDU set (e.g., in an MOQ header), in which case the relay component may extract the metadata from the PDU set and maintain a local state that maps the metadata to the PDU set (e.g., to a stream used to transport the PDU set). This way, the metadata may be associated with subsequent PDUs of the PDU set.

[0111] The relay component (e.g., UPF) may maintain a mapping between the PDU set (e.g., PDU set ID) and the corresponding stream (e.g., a QUIC stream used to carry the PDU set over MOQ, a TCP stream used to carry the PDU set, etc.), or between the PDU set and a pseudo-stream (e.g., a set of RTP header fields that may identify the PDU set). The mapping may associate the correct PDU set ID to multiple (e.g., all) PDUs within the stream or pseudo-stream (which may be collectively referred to as a stream herein). The mapping may also be used to facilitate other operations, such as the transmission of ACK / NACK for the reliable PDU set, the closing of the reliable PDU set, etc., as described herein.

[0112] At 2b of FIG. 3, the relay component (e.g., UPF) may transmit the PDU set (e.g., one or more PDUs of the PDU set), the PDU set metadata, and / or the reliability metadata associated with the PDU set to another device (e.g., a RAN node such as a base station) in the communication network. In examples, the PDU set metadata and / or reliability metadata may be placed in a GTP-U header encapsulating a (e.g., each) packet of the PDU set sent by the relay component (e.g., UPF) to the other device (e.g., the RAN node), as described herein. In examples, the operations at 2b may be performed between a relay component on the first WTRU and an XR support component in an RAN node such as a base station. In those examples, the reliability metadata may be placed in a layer-2 signaling header, as described herein. In examples, the operations at 2b may be performed between a relay component on the first WTRU and an XR support component in the same WTRU. In those examples, the reliability metadata may be passed as a parameter associated with the PDU set packets or buffer in a programmable API, as described herein. In examples, the PDU set metadata and reliability metadata may be sent in a PDU set descriptor message (e.g., a message sent in advance of PDU set packets and carrying the PDU set ID).

[0113] At step 3a and / or 3b of FIG. 3, the XR support component (e.g., a RAN node such as a base station) may use the PDU set metadata and / or reliability metadata to perform operations on the PDU set.These operations may include, for example, delivering the PDU set using techniques aimed at improving the quality of experience for XR application users. Examples of the operations performed by the XR support component (e.g., a base station) based on the reliability metadata may include those described herein such as, for example, providing differentiated services (e.g., reliable-low-latency-specific services) for the reliable PDUs, assigning / using degressive importance of the PDUs in the PDU set, providing support for ACK / NACK feedback, providing support for the closing of the reliable PDU set, etc. At least some of these operations may also be performed by another node (e.g., by a UPF or a relay component), or by multiple nodes cooperatively (e.g., by a RAN node in cooperation with a UPF or relay component).

[0114] The operations associated with 1a to 3b of FIG. 3 may be repeated for PDUs (e.g., all PDUs) in one or more PDU sets.

[0115] At 4 of FIG. 3, the application on the first WTRU may read application data including the PDU set from a buffer (e.g., of a QUID stream or TCP connection). Contiguous data starting from offset 0 may be available to the application. The first WTRU may process an entire PDU set once received, although some applications may be configured to process a partial PDU set. The processing of the application data may include displaying media contents associated with the application data in a head-mounted display, for example.

[0116] At 5 of FIG. 3, media delivery may continue with additional PDU sets. The first WTRU may send ACK / NACK (e.g., QUIC, TCP, or RTP ACK / NACK) back to its peer (e.g., the AS or the second WTRU) to indicate successful delivery of packets or lost packets. In response, the peer may retransmit lost packets.

[0117] FIG. 4 illustrates an example process for determining reliability metadata and transmitting the reliability metadata (e.g., to an XR support component) in the uplink of a wireless communication network (e.g., for uplink media delivery). As shown in FIG. 4, a relay component may be located in a first WTRU, e.g., as a part of an application (or a library) of the first WTRU or as a separate process (e.g., a MOQ relay) on the first WTRU. An XR support component may be located in the first WTRU or in an RAN node (e.g., in a base station). In examples, the XR support component may be distributed between the first WTRU and the RAN. The protocol used to carry the reliability metadata from the relay component to the XR support component may be over layer-2 signaling (e.g., if the XR support component is in the RAN node) or an internal API (e.g., if the XR support component is in the first WTRU), as described herein. The other operations illustrated by FIG. 4 may be similar to those shown in FIG. 3, but in the uplink direction instead of the downlink direction, and / or by different entities than those shown in FIG. 3. For example, at 0a of FIG. 4, the first WTRU may receive policy and / or configuration information (e.g., as described herein) from a network device (e.g., the policy and / or configuration information may be received in an NAS-SM message generated by an SMF and / or transmitted via a base station). The policy and / or configuration informationmay be associated with a PDU session or a PDU set. The policy and / or configuration information may be received in an NAS-PCF message from a PCF, for example, in the form of a policy that the WTRU may associate with a PDU session, a PDU set, or an application traffic flow.

[0118] At Ob of FIG. 4, an application (e.g., a media streaming or XR application) on the first WTRU may initiate communication with one or more peers (e.g., a second WTRU) or a server (e.g., an application server). The first WTRU may include a relay component and may establish the communication with the one or more peers or the server through the relay (e.g., for media flows over MOQ or using a MOQ relay). At 0c of FIG. 4, an application session may be established between the first WTRU and the one or more peers (e.g., the second WTRU) or the server (e.g., the AS).

[0119] At 1 a and / or 1 b of FIG. 4, the first WTRU (e.g., the XR application on the first WTRU) may transmit XR media data (e.g., as part of a PDU set such as via a PDU of the PDU set) and / or PDU set metadata to the relay component. At 2a, the relay component (e.g., in the first WTRU) may determine reliability metadata associated with the PDU set (e.g., based on the policy and / or configuration information obtained at 0a) and / or retrieve other PDU set metadata. At 2b, the relay component (e.g., the first WTRU) may transmit a PDU of the PDU set, the PDU set metadata, and / or the reliability metadata associated with the PDU set to an XR support component (e.g., which may be located in the first WTRU or on a base station), which may use the reliability metadata and / or the PDU set metadata to provide XR support service including, for example, forward the PDU to the one or more peers or the AS at 3b.

[0120] At 4, the one or more peers or the AS may process the PDU (e.g., as part of the PDU set). As part of the operations at 3a, 3b and / or 4, the first WTRU may receive a message from the XR support component and / or the peers / server regarding the transmission status of the PDU. For example, such a message may include an acknowledgment (ACK) or a negative acknowledgment (NACK) of the PDU indicating, respectively, that the transmission of the PDU was successful or unsuccessful. The message may also include a command or indication to close the PDU set. In response to receiving such a message, the first WTRU may perform one or more operations associated with the PDU based on the received message. The first WTRU may, for example, retransmit the PDU based on a received indication that the previous transmission of the PDU has failed. As another example, the first WTRU may close the PDU set (e.g., close an independent transport stream associated with the PDU set as described herein) if the message received by the first WTRU includes an indication to close the PDU set. In examples, the first WTRU may determine an importance of the PDU within the PDU set and perform the one or more operations for the PDU based on the importance of the PDU within the PDU set (e.g., the first WTRU may decide to drop the PDU instead of retransmitting it in response to receiving a NACK if the importance of the PDU is low).

[0121] As described herein, providing differentiated services (e.g., in either the downlink or the uplink) to reliable PDUs may refer to the use of reliability metadata (e.g., one or more reliability indications) to provide differentiated services for reliable PDUs in a wireless communication network (e.g., by a RAN node such as a base station, by a WTRU, or by a UPF). An XR support service (e.g., in a WTRU, RAN node, or UPF) may provide differentiated services for reliable PDUs by associating reliable and unreliable PDU sets (e.g., as identified by the reliability metadata or indications) with different levels of service to ensure differentiated treatments of the PDUs. These different levels of service may be associated with different quality indicators (e.g., different 5Qls over an Uu reference point), different PQIs (e.g., over a PC5 reference point), and / or different QoS flow priority levels.

[0122] Reliability metadata (e.g., one or more reliability indications) may be used by a wireless communication network (e.g., by a RAN node such as a base station, by a WTRU, or by a core network function such as a UPF) to determine, assign, and / or use degressive importance of PDUs in a PDU set. The device (e.g., a RAN node such as a base station, a WTRU, or a core network function such as a UPF) implementing the degressive importance of PDUs in the PDU set may associate an effective PDU importance value with a (e.g., each) PDU of the PDU set. Such an effective importance value may not be the same for all PDUs in the PDU set, and may decrease through the PDU set (e.g., from earlier PDUs in the PDU set to later PDUs in the PDU set). The effective PDU importance value may be calculated based on an importance value associated with the whole PDU set, which may be referred to herein as a nominal PDU set importance. A RAN node such as a base station, a WTRU, or a core network function such as a UPF may determine the respective effective PDU importance values for the PDUs that have been identified as being part of a reliable PDU set (e.g., as identified using reliability metadata or indications). Various methods (e.g., including those based on the respective positions or sequence numbers of the PDUs within the PDU set) may be used to calculate the effective PDU importance values for the PDUs. The sequence number of a PDU within the PDU set may be based on the order of the PDU payload data within the PDU set payload data, which may or may not correspond with the order in which the PDU is received (e.g., since the order of transmission may not be guaranteed for IP packets). For example, the effective PDU importance of a PDU may be equal to the nominal PDU set importance minus the product of a factor and the sequence number of the PDU in the PDU set. For example, with a factor of 1, the effective importance value of a PDU may decrease by one for each subsequent PDU in the PDU set. With a factor below 1, the decrease in the effective PDU importance value may occur every several PDUs. For example, based on the policy and / or configuration information described herein, the effective importance value for PDU #n in a PDU set may be calculated as nominal_pdu_set_importance - n*delta_importance, as described herein.

[0123] A relay component (e.g., in a WTRU or a UPF) or an XR support component (e.g., in a WTRU or a RAN node) may determine the effective importance value of a PDU. If the relay component determines the effective importance value, the value may be associated with one or more PDUs (e.g., each PDU) sent to the XR support component (e.g., in a GTP-U header sent to a RAN node). The XR support component (e.g., in a RAN node or WTRU) may use the effective importance value of a PDU for multiple purposes. For example, the XR support component may allocate more network resources to transmit or retransmit PDUs having a higher effective importance value (e.g., PDUs earlier in a PDU set). The XR support component may drop PDUs with a lower effective importance value (e.g., PDUs later in a PDU set), for example, in case of congestion. The XR support component may (e.g., in the case of congestion) rank the PDUs using the nominal importance as a primary key and (e.g., in case of a primary key tie) using the effective importance as a secondary key. For example, the XR support component may drop the PDUs with a lower nominal importance value first and, upon considering PDUs with the same nominal importance value, drop the PDUs with a lower effective importance value. If two PDU sets have equal nominal PDU set importance values, later PDUs in both PDU sets may be dropped, resulting in the first part of both PDU sets being partially received by a receiving peer. Such a mode of operation may be referred to as “effective PDU importance isolated per-PDU set,” since the PDU effective importance values may be compared between (e.g., only between) PDUs of the same PDU set.

[0124] An XR support component may drop PDUs with a lower effective importance value regardless of which PDU set they belong to, for example, in the case of congestion. If two PDU sets have equal or close nominal PDU set importance values, this may result in the later PDUs from both PDU sets being dropped and the first part of both PDU sets being partially received by a receiving peer. Such a mode of operation may be referred to as “effective PDU importance shared between PDU sets,” since the PDU effective importance values may be compared between (e.g., only between) PDUs of different PDU sets.

[0125] An XR support component may determine which mode of operation (e.g., between “effective PDU importance isolated per-PDU set” and “effective PDU importance shared between PDU sets”) to use based on network configuration information or policy. For example, a WTRU, a core network function (e.g., a UPF) or a RAN node (e.g., a base station) may be configured by an SMF (e.g., using URSP rules, N4 rules, and / or QoS rules) based on PCC rules obtained from a PCF, wherein the PCC rules may indicate the mode of operation (e.g., “effective PDU importance isolated per-PDU set” or “effective PDU importance shared between PDU sets”) to use. Such PCC rules may enable association of a mode of operation with an application flow.

[0126] If a PDU set reaches a PSDB and some PDUs of the PDU set are still queued for transmission, an XR support component (e.g., in a RAN node) may determine to transmit, among the queued PDUs, theearliest PDUs of the PDU set (e.g., with a higher effective PDU importance value), and to drop or delay the remaining PDUs of the PDU set.

[0127] If a packet is lost and a scheduler decides not to retransmit it, the scheduler may decide to drop the following PDUs in a reliable PDU set (e.g., all PDUs with the same PDU set ID, a PDU having a lower effective PDU importance value than the PDU that failed to transmit, etc.). This approach may conserve bandwidth for other reliable PDU sets that do not have a lost PDU, and may be taken because there may not be gains in sending the remaining PDUs of the PDU set immediately (e.g., since those PDUs may remain in the receiving buffer of a receiver and not be processed by an application). This approach may result in a future retransmission from the sender or a relay component.

[0128] In examples where an effective PDU importance value may be shared between PDU sets, a per- PDU effective importance value may be based on a PDU set size. In examples, the effective PDU importance value may be equal to the nominal PDU set importance minus the product of a factor and the sequence number of the PDU in the PDU set, and plus or minus an integer (e.g., based on the PDU size in bytes). This approach may be used to prioritize smaller or larger PDU sets.

[0129] In examples where an effective PDU importance value may be shared between PDU sets, the per-PDU effective importance value may be based on a PDU set integrated indication (PSII). For example, the effective PDU importance value that may otherwise be calculated using the methods described herein may be modified by adding an offset when the PSII is associated with the PDU set. The offset may have a positive value to increase the effective importance of the PDUs associated with the PSII, which may result in more network resources being allocated to ensure a successful transmission of those PDUs (e.g., compare to PDUs not associated with the PSII).

[0130] The degressive importance of PDUs in a PDU set may cause a reliable PDU set to be received as a contiguous group of PDUs (e.g., starting from the first PDU of the set), while missing PDUs, if any, may form a contiguous group at the end of the PDU set. This may improve network efficiency (e.g., from an application standpoint), since the application may be able to access (e.g., only access) contiguous data starting from the beginning of a reliable stream.

[0131] Reliability metadata (e.g., one or more reliability indications) may be used (e.g., by a RAN node, a WTRU, or a UPF) to implement ACK / NACK feedback for a reliable PDU set. FIG. 5 illustrates an example of an XR support component (e.g., a WTRU or a RAN node) sending ACK / NACK feedback to a relay component (e.g., subsequent to the operations illustrated in FIG. 3 and FIG. 4), and the relay component sending acknowledgment or negative acknowledgment about a packet to a sending endpoint in response to receiving the ACK / NACK feedback from the XR support component. The XR support component may use the reliability metadata (e.g., one or more reliability indications) to determine thatACK / NACK feedback is to be enabled (e.g., ACK / NACK messages should be sent). The relay component may retransmit lost packets without waiting for an acknowledgement from a receiving endpoint (e.g., a WTRU).

[0132] In an example downlink setting, the sender may be an AS or a remote WTRU, the relay component may be collocated with a UPF or an edge server, the XR support component may be collocated with a base station, and the receiver may be a WTRU application. In an example uplink setting, the sender may be a WTRU application, the relay component may be collocated with the WTRU, the XR support component may collocated with the WTRU (or with a base station), and the receiver may be an AS or a second WTRU.

[0133] In examples, the operations illustrated in FIG. 5 may be used to implement load balancing, for example, in a UPF (e.g., a base station may transmit downlink PDU sets until a congestion event occurs). If a transmission fails for a PDU of a PDU set, the base station may decide not to transmit another PDU in this PDU set and may send NACK(s) / ACK(s) accordingly to the UPF. The UPF may decide which PDUs (from which PDU sets) to retransmit to the base station, for example, by applying global load balancing and taking into consideration the importance of the PDU sets, the type of the PDU sets, the presence of a PSII indication in a PDU set, network congestion information, user profiles, application profiles, etc.

[0134] As shown in FIG. 5, a media flow may be delivered at 0 with support from a network device and / or using PDU set metadata and / or reliability metadata as described herein. This operation may encompass one or more operations illustrated in FIG. 3 and / or FIG. 4. At 1 of FIG. 5, a sender (e.g., an AS or WTRU) may send a PDU of the media flow towards a receiver, and the PDU may reach a relay component (e.g., a MOQ relay, a DPI component, or another proxy). At 2a, 2b, and / or 2c, the relay may forward the PDU to the receiver (e.g., through a RAN). In examples (e.g., if the relay may be a transport session endpoint, such as a MOQ relay or a TCP proxy), the relay may send an acknowledgement (e.g., a QUIC ACK or TCP ACK) to the sender. The relay may extract PDU set metadata and / or reliability metadata from the PDU and / or earlier PDUs, and may associate the metadata with the PDU forwarded to the XR support component (e.g., using a GTP-U header or other methods described herein). The relay may buffer the PDU (e.g., to enable retransmission of the PDU if needed), for example, based on the PDU set reliability metadata (e.g., the relay may decide to only buffer reliable PDUs). The relay may determine the size of the buffer based on an expected latency of the flow (e.g., an SMF may configure the buffer size on a UPF based on PCC rules or parameters such as PDB, PSDB, DL / UL maximum bitrate, etc. of the flow).

[0135] At 3a and / or 3b of FIG. 5, the XR support component may attempt to transmit the PDU to the receiver (e.g., over the RAN to the WTRU on the downlink, or over the RAN to a base station on theuplink). The XR support component may determine that the transmission is unsuccessful and may determine that a retransmission may not be performed (e.g., because of a temporary congestion, a low PDU set importance value, or a possibility that the retransmission may cause a PSDB to be exceeded). The XR support component may determine to use ACK / NACK based on criteria such as the presence of reliability metadata indicating that the PDU set ID is reliable, based on configuration information, based on the number of ACKs / NACKs already transmitted, based on a network congestion status, etc. The XR support component may send an ACK / NACK message to the relay component (e.g., indicating the IDs of successfully transmitted PDUs and unsuccessfully transmitted PDUs, respectively). In examples, a PDCP PDU number may be used as the ID for the PDUs in ACK / NACK. In an example downlink setting, an ACK or NACK GTP-U header extension may be defined to hold PDU IDs and / or ranges of PDU IDs that may be (positively or negatively) acknowledged.

[0136] At 4a and / or 4b of FIG. 5, the relay may identify the buffered PDU corresponding to a lost PDU indicated by an NACK message. The relay may determine whether or not to retransmit the lost PDU. The relay may consider a number of past retransmissions, a current RAN status, PDU set importance, whether the PDU set carries a PSII indication, a QoS flow priority level, PDU set reliability metadata, etc. in determining whether or not to retransmit the lost PDU. If the relay determines to retransmit the lost PDU, the relay may send a copy of the lost PDU (e.g., in a GTP-U header) to the XR support component. If the relay determines not to retransmit the lost PDU, the relay may wait to receive a transport-layer ACK / NACK from the receiver (e.g., a QUIC ACK message, a TCP ACK message, an RTCP NACK, etc.). The relay may determine to close the stream associated with the lost PDU. The relay may send a message to the sender and / or the receiver to close the stream.

[0137] In examples, data may not be buffered in the relay component at 2a, in which case the relay may send an ACK / NACK message to the sender at 4a to obtain a retransmitted PDU from the sender, and may forward the retransmitted PDU to the XR support component at 4b.

[0138] Reliability metadata (e.g., one or more reliability indications) may be used (e.g., by a RAN node such as a base station, a WTRU or a core network function such as a UPF) to enable the closing of a reliable PDU set. FIG. 6 illustrates examples of closing a reliable PDU set based on a reliability indication.

[0139] In a first example involving a downlink setting, a sender may be an AS, a relay component may be collocated with a UPF, an XR support component may be collocated with a base station (e.g., gNodeB), and a receiver may be an application running on a WTRU. At 0 of FIG. 6, a media flow may be delivered with support from the network using PDU set metadata and / or reliability metadata as described herein.This operation may encompass one or more steps shown in FIG. 3 or FIG. 4. The XR support component may send a request (e.g., a CLOSE_RELIABLE_PDU_SET message) to the relay component to trigger theclosing of a transport layer stream corresponding to the PDU set. A header extension (e.g., a CLOSE_RELIABLE_PDU_SET GTP-U header extension) may be defined to hold the PDU set I D(s) to be closed.

[0140] At 1-1 of FIG. 6, the sender may send a PDU to the receiver. The PDU may be sent through the relay component, which may extract and associate PDU set metadata (e.g., including a PDU set ID) and / or reliability metadata with the PDU, and forward the PDU and the associated metadata to the XR support component. The relay may maintain an association between the PDU set I D(s) and the corresponding stream I D(s) (e.g., uplink and / or downlink QUID stream(s), TCP stream(s), RTP PDU set I D(s) based on RTP header fields, etc.)

[0141] At 1 -2a and / or 1 -2b of FIG. 6, the XR support component may determine whether to close the PDU set considering criteria such as a current congestion status, a number of failures to transmit PDUs in the reliable PDU set, the number of PDUs waiting for transmission, a PDU set importance value, whether the PDU set is associated with a PSII indication, a QoS flow priority level, and / or reliable metadata associated with the PDU set (e.g., such as a reliability indication and / or an independent stream indication). For example, if the PDU set is not an independent stream (e.g., as defined herein), the XR support component may decide not to close the reliable PDU set. As another example, if the PDU set is not indicated as reliable, the XR support component may decide not to close the reliable PDU set; if the PDU set is indicated as reliable, the XR support component may consider other criteria to determine if the reliable PDU set should be closed.

[0142] Upon determining whether to close the PDU set, the XR support component may send a response (e.g., a CLOSE_RELIABLE_PDU_SET (PDU set ID) message) to the relay component. In examples such as when multiple PDU sets are inter-dependent (e.g., based on dependency PDU set metadata or inter-modal dependency PDU set metadata), the XR support component may send multiple responses (e.g., multiple CLOSE_RELIABLE_PDU_SET (PDU set ID) messages) including the PDU set IDs of the multiple inter-dependent PDU sets to the relay component.

[0143] At 1 -3a, 1 -3b, and / or 1 -3c of FIG. 6, the relay may retrieve the stream I D(s) associated with the PDU set I D(s) obtained at 1 -2b and determine how to process the CLOSE_REUABLE_PDU_SET message from the XR support component. This determination may be made based on criteria such as the nature of the transport protocol, the size of the PDU set, the number of PDUs or PDU sets already received at the relay, the number of CLOSE_RELIABLE_PDU_SET messages already received at the relay, PDU set reliability metadata, etc. The outcome of the determination may include one or more of the following.

[0144] In examples, the relay may decide to close the stream(s) corresponding to the PDU set(s) and may send messages or commands (e.g., in a QUIC STREAM_RESET frame, a TCP reset message,and / or a programmatic indication to a local WTRU application) to the relevant endpoint(s) to close the associated streams. This decision may be the default decision if the closing of reliable PDU sets is enabled.

[0145] In examples, the relay may decide not to close the associated stream(s) from the sender and to close the stream(s) towards the receiver. This may be because, for example, the relay may have already received data from the sender, and therefore, the stream(s) from the sender may have already been closed or may be in the process of being closed by the sender.

[0146] In examples, the relay may decide not to close any associated stream and to stop transmitting PDUs from the PDU set. This may be because, for example, the PDU set reliability metadata may indicate that the PDU set is not an independent stream and, therefore, closing the stream may affect other PDU sets.

[0147] In examples, the relay may decide not to close any associated stream and continue transmitting PDUs from the PDU set. This may be because, for example, the occurrence of CLOSE_RELIABLE_PDU_SET messages may be sparse, and the relay may decide to use an end-to-end transport retransmission mechanism without interference.

[0148] At 1 -4a and / or 1 -4b of FIG. 6, the endpoints associated with a relevant stream (e.g., the receiver and sender of the stream) may close the stream if they receive a message or command to do so.

[0149] In a second example involving an uplink setting, the sender may be a WTRU application, the relay component may be collocated with the WTRU, the XR support component may be collocated with the WTRU (or a base station), and the receiver may be an AS. In such a setting, the relay may send a message (e.g., a CLOSE_REUABLE_PDU_SET message) to the XR support component, for example, to reduce network resource usage when a transport stream may be closed by an endpoint of the stream or the relay. A header extension (e.g., a CLOSE_RELIABLE_PDU_SET GTP-U header extension) may be defined to hold the PDU set I D(s) to be closed.

[0150] At 2-1 of FIG. 6, the relay may receive a message or command to close a stream associated with an endpoint (e.g., a media sender or a media receiver). The relay may also determine to close a stream based on criteria such as the number of lost PDUs or a network congestion status.

[0151] At 2-2a and / or 2-2b of FIG. 6, the relay may retrieve the PDU set ID associated with the stream to be closed (e.g., using a mapping established using the methods described herein). The relay may determine whether or not to send a CLOSE_RELIABLE_PDU_SET message. This determination may be based on criteria such as the current congestion status, the amount of data from this PDU set already forwarded to the receiver, whether the PDU set is associated with a PSII indication, a QoS flow priority level, reliable metadata associated with the PDU set such as a reliability indication and / or an independentstream indication, etc. Based on the outcome of the determination, the relay may send a response such as a CLOSE_REUABLE_PDU_SET(pdu set ID) message to the XR support component.

[0152] At 2-3 of FIG. 6, the XR support component may, upon reception of the CLOSE_RELIABLE_PDU_SET message, drop the PDUs in its buffers that may be associated with the PDU set ID indicated in the message.

[0153] At 2-4a and / or 2-4b of FIG. 6, the relay may send a message or command to an endpoint to close the associated stream. Since the sender may have initiated the closing of the stream (e.g., at 2-1), the relay may send the message or command to the receiver.

[0154] Although features and elements described above 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 other features and elements. Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0155] 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 (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks, and / or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

CLAIMSWhat is claimed is:1 . A network device, comprising: a processor configured to: receive an indication that a protocol data unit (PDU) set is to be delivered in a reliable manner over a wireless communication network; determine, based on the received indication, reliability metadata associated with the PDU set; transmit the reliability metadata associated with the PDU set to another device in the wireless communication network; and perform one or more operations for a PDU of the PDU set based at least on the reliability metadata associated with the PDU set.

2. The network device of claim 1 , wherein the processor being configured to perform the one or more operations for the PDU comprises the processor being configured to determine a level of service for the PDU that is different from a level of service provided to one or more PDUs of a different PDU set.

3. The network device of claim 2, wherein the level of service is associated with a quality of service (QoS) flow or a transmission priority.

4. The network device of claim 1 , wherein the processor being configured to perform the one or more operations for the PDU comprises the processor being configured to determine an importance of the PDU within the PDU set.

5. The network device of claim 4, wherein the processor is configured to determine the importance of the PDU within the PDU set based on a position of the PDU in the PDU set.

6. The network device of claim 4, wherein the processor being configured to perform the one or more operations for the PDU further comprises the processor being configured to indicate the importance of the PDU to the other device in the wireless communication network.

7. The network device of claim 4, wherein the processor being configured to perform the one or more operations for the PDU further comprises the processor being configured to determine whether to drop or retransmit the PDU based on the importance of the PDU in the PDU set.

8. The network device of claim 1 , wherein the processor being configured to perform the one or more operations for the PDU comprises the processor being configured to: transmit the PDU to the other device in the wireless communication network; receive an indication that the PDU was not received by the other device; and determine whether to retransmit the PDU to the other device.

9. The network device of claim 1 , wherein the processor being configured to perform the one or more operations for the PDU comprises the processor being configured to close a transport stream associated with the PDU set based on a congestion condition, a number of transmission failures associated with the PDU set, or an indication from the other device in the wireless communication network to close the transport stream.

10. The network device of claim 1 , wherein the network device is configured as a user plane function in the wireless communication network.11 . The network device of claim 1 , wherein the network device is a base station in the wireless communication network.

12. A method implemented by a network device, the method comprising: receiving an indication that a protocol data unit (PDU) set is to be delivered in a reliable manner over a wireless communication network; determining, based on the received indication, reliability metadata associated with the PDU set; transmitting the reliability metadata associated with the PDU set to another device in the wireless communication network; and performing one or more operations for a PDU of the PDU set based at least on the reliability metadata associated with the PDU set.

13. The method of claim 12, wherein performing the one or more operations for the PDU comprises determining a level of service for the PDU that is different from a level of service provided to one or more PDUs of a different PDU set.

14. The method of claim 13, wherein the level of service is associated with a quality of service (QoS) flow or a transmission priority.

15. The method of claim 11 , wherein performing the one or more operations for the PDU further comprises determining an importance of the PDU within the PDU set.

16. The method of claim 15, wherein the importance of the PDU within the PDU set is determined based on a position of the PDU in the PDU set.

17. The method of claim 15, wherein performing the one or more operations for the PDU further comprises indicating the importance of the PDU to the other device in the wireless communication network.

18. The method of claim 15, wherein performing the one or more operations for the PDU further comprises determining whether to drop or retransmit the PDU based on the importance of the PDU in the PDU set.

19. The method of claim 12, wherein performing the one or more operations for the PDU further comprises: transmitting the PDU to the other device in the wireless communication network; receiving an indication that the PDU was not received by the other device; and determining whether to retransmit the PDU to the other device.

20. The method of claim 12, wherein performing the one or more operations for the PDU further comprises closing a transport stream associated with the PDU set based on a congestion condition, a number of transmission failures associated with the PDU set, or an indication from the other device in the wireless communication network to close the transport stream.21 . The method of claim 12, wherein the network device is configured as a user plane function or a base station in the wireless communication network.

Images