Protocol data unit set handling information for extended reality media traffic to and from a wireless transmit / receive unit

Abstract

Described herein are systems, methods, and instrumentalities associated with protocol data unit (PDU) sets. A network device associated with a wireless communication network may receive PDU set handling information that may indicate one or more transport protocol header extensions associated with a marking of a PDU set. The PDU set handling information may further indicate whether the PDU set handling information is applicable to uplink traffic, downlink traffic, or both the uplink traffic and the downlink traffic. The network device may receive a PDU session establishment or modification request and, in response, may send a message to another network device or a wireless transmit / receive unit. The message may indicate the PDU set handling information received by the network device.

Description

PROTOCOL DATA UNIT SET HANDLING INFORMATION FOR EXTENDED REALITY MEDIA TRAFFIC TO AND FROM A WIRELESS TRANSMIT / RECEIVE UNITCROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] XRM traffic may be supported in a communication system. A quality of service (QoS) flow may be enabled. Actions may be taken at various entities in the communication system to allow the network to efficiently transmit the XRM traffic to and from a wireless transmit / receive unit (WTRU).SUMMARY

[0003] Disclosed herein are systems, methods, and instrumentalities associated with protocol data unit (PDU) sets. According to embodiments of the present disclosure, a network device associated with a wireless communication network may be configured to receive PDU set handling information that may indicate at least one or more transport protocol header extensions associated with a marking of a PDU set. The PDU set handling information may further indicate whether the PDU set handling information is applicable to an uplink transmission of the wireless communication network or a downlink transmission of the wireless communication network. The network device may be further configured to receive a PDU session establishment or modification request, and, in response to receiving the PDU session establishment or modification request, the network device may send a message to another network device (e.g., a user plane function (UPF) of the wireless communication network) or a wireless transmit / receive unit (WTRU). The message may indicate the PDU set handling information received by the network device.

[0004] In examples, the one or more transport protocol header extensions include a real-time transport protocol (RTP) header extension. In examples, the RTP header extensions may indicate at least one of an end PDU of the PDU set, an importance of the PDU set, a PDU sequence number associated with the PDU set, or a size of the PDU set. In an example, the network device may be further configured to perform a session management function (SMF) associated with the wireless communication network (e.g., the network device may be an SMF device).

[0005] In examples, the PDU set handling information may be received from a policy control function (PCF) of the wireless communication network. In examples, the network device may be further configured to receive an indication from a radio access network (RAN) node that the RAN node may support PDU set-based transmissions or receptions. In examples, the network device may be configured to send the message that indicates the PDU set handling information in response to receiving the indication from the RAN node. In examples, the network device may send quality of service (QoS) related information associated with the PDU set to the RAN node, and receive the indication that the RAN node supports PDU set-based transmissions or receptions as a response to the QoS related information.

[0006] In examples, the message that indicates the PDU set handling information may be sent to a UPF of the wireless communication network. In examples, the message may include an instruction for the UPF to perform PDU set identification and / or PDU set marking based on the PDU set handling information. In examples, the PDU set handling information may further include information regarding an encryption of the PDU set. In examples, the message that indicates the PDU set handling information may be sent to the WTRU, for example, as a PDU session establishment or modification response.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 can be implemented.

[0008] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used within the communications system illustrated in FIG. 1 A 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 can be used within the communications system illustrated in FIG. 1 A according to an embodiment.

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

[0011] FIG. 2 illustrates examples of signaling associated with a protocol data unit (PDU) set feature.

[0012] FIG. 3 illustrates an example of handling a PDU set related quality of service (QoS) requirement or parameter.

[0013] FIG. 4 illustrates an example of a procedure for negotiating PDU set features.

[0014] FIG. 5 illustrates an example of a procedure for determining support for PDU set features.

[0015] FIG. 6 illustrates an example of a procedure for configuring PDU set features.DETAILED DESCRIPTION

[0016] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings.

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

[0018] As shown in FIG. 1A, the communications system 100 can 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 I nternet 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 can 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 can be referred to as a “station” and / or a “ST A”, can be configured to transmit and / or receive wireless signals and can include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g. , remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d can be interchangeably referred to as a WTRU.

[0019] The communications systems 100 can include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b can 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 can be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0020] The base station 114a can be part of the RAN 104 / 113, which can 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 can be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell can provide coverage for a wireless service to a specific geographical area that can be relatively fixed or that can change over time. The cell can further be divided into cell sectors. For example, the cell associated with the base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a can employ multiple-input multiple output (MIMO) technology and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in desired spatial directions.

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

[0022] More specifically, as noted above, the communications system 100 can be a multiple access system and can 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 can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA(HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

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

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

[0025] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c can 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 can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

[0026] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can 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.

[0027] The base station 114b in FIG. 1 A can be a wireless router, Home Node B, Home eNode B, or access point, for example, and can 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 can 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 can 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 can 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. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b cannot be required to access the Internet 110 via the CN 106 / 115.

[0028] The RAN 104 / 113 can be in communication with the CN 106 / 115, which can 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 can 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 can 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 can 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 can be utilizing a NR radio technology, the CN 106 / 115 can also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0029] The CN 106 / 115 can 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 can include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 can 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 can include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include another CN connected to one or more RANs, which can employ the same RAT as the RAN 104 / 113 or a different RAT.

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

[0031] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 can 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 can include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0032] The processor 118 can 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 can 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 can be coupled to the transceiver 120, which can 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 can be integrated together in an electronic package or chip.

[0033] The transmit / receive element 122 can 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 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 can be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

[0035] The transceiver 120 can 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 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

[0036] The processor 118 of the WTRU 102 can be coupled to, and can 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 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from, and store data in, any type of suitable memory, such as the non-removablememory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can 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 can 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).

[0037] The processor 118 can receive power from the power source 134 and can be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 can be any suitable device for powering the WTRU 102. For example, the power source 134 can 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.

[0038] The processor 118 can also be coupled to the GPS chipset 136, which can 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 can receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 can acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0039] The processor 118 can further be coupled to other peripherals 138, which can 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 can 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 can include one or more sensors, the sensors can 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.

[0040] The WTRU 102 can 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) can be concurrent and / or simultaneous. The full duplex radio can 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 WTRU 102 can 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)).

[0041] 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 can employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.

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

[0043] Each of the eNode-Bs 160a, 160b, 160c can be associated with a particular cell (not shown) and can 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 can communicate with one another over an X2 interface.

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

[0045] The MME 162 can be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and can serve as a control node. For example, the MME 162 can 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 can 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.

[0046] The SGW 164 can be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can 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.

[0047] The SGW 164 can be connected to the PGW 166, which can 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.

[0048] The CN 106 can facilitate communications with other networks. For example, the CN 106 can 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 can include, or can 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 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers.

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

[0050] In representative embodiments, the other network 112 can be a WLAN.

[0051] A WLAN in Infrastructure Basic Service Set (BSS) mode can have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can 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 can arrive through the AP and can be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS can be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS can be sent through the AP, for example, where the source STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. The traffic between STAs within a BSS can be considered and / or referred to as peer-to-peer traffic. The peer-to- peer traffic can be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS can use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (I BSS) mode cannot have an AP, and the STAs (e.g., all ofthe STAs) within or using the I BSS can communicate directly with each other. The IBSS mode of communication can sometimes be referred to herein as an “ad-hoc” mode of communication.

[0052] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP can transmit a beacon on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel can be the operating channel of the BSS and can 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) can be implemented, for example in 802.11 systems. For CSMA / CA, the STAs (e.g., every ST A), including the AP, can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0053] High Throughput (HT) STAs can 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.

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

[0055] 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, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah can support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths.The MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0056] WLAN systems, which can support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which can be designated as the primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all ST As in the BSS. The bandwidth of the primary channel can be set and / or limited by a STA, from among all STAs operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel can 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 can 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 can be considered busy even though a majority of the frequency bands remains idle and can be available.

[0057] In the United States, the available frequency bands, which can 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 for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0058] 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 can employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 can also be in communication with the CN 115.

[0059] The RAN 113 can include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 can include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c can 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 can implement MIMO technology. For example, gNBs 180a, 108b can utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, can 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 can implement carrier aggregation technology. For example, the gNB 180a can transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum while the remaining component carriers can be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180ccan implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0060] The WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c can 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).

[0061] The gNBs 180a, 180b, 180c can 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 can 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 can utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c can 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 can 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 can serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0062] Each of the gNBs 180a, 180b, 180c can be associated with a particular cell (not shown) and can 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 can communicate with one another over an Xn interface.

[0063] The CN 115 shown in FIG. 1 D can 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 can be owned and / or operated by an entity other than the CN operator.

[0064] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can 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 can 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 can 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 can 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.

[0065] The SMF 183a, 183b can be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b can also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can 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 can be IP-based, non-IP based, Ethernet-based, and the like.

[0066] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which can 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 can 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.

[0067] The CN 115 can facilitate communications with other networks. For example, the CN 115 can include, or can 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 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can 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 can 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.

[0068] In view of Figures 1A-1D, 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, can be performed by one or more emulation devices (not shown). The emulation devices can be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices can be used to test other devices and / or to simulate network and / or WTRU functions.

[0069] The emulation devices can 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 can 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 can 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 can be directly coupled to another device for purposes of testing and / or can perform testing using over-the-air wireless communications.

[0070] The one or more emulation devices can 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 can 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 can be testing equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which can include one or more antennas) can be used by the emulation devices to transmit and / or receive data.

[0071] A WTRU may negotiate PDU set features. The WTRU, which may be interested in an extended reality and media (XRM) service, may negotiate a PDU set feature through one or more of the following processes. The WTRU may send a registration request message to the network. The WTRU may obtain a registration accept message that may include a PDU set feature capability indication. The indication may include a request for the WTRU to check if the PDU set feature is enabled. The WTRU may start an application (e.g., an XRM application installed on the WTRU) and may determine, based on user equipment route selection policy (URSP) rules, to start a PDU session for the application and / or to use a PDU set feature for the application. The application in the WTRU may obtain the PDU set feature capability indication via one or more attention commands (AT commands). The WTRU application may determine whether to negotiate a PDU setfeature based on the obtained PDU set feature capability indication and / or the determination to use the PDU set feature for the application. The WTRU may determine PDU set options and / or PDU set marking configurations to use based on the obtained PDU set feature capability indication. The WTRU application may send a session description protocol (SDP) offer to the application server (AS), which may include one or more of the following: a PDU set feature capability indication, determined PDU set options, or a PDU set marking configuration to use. The WTRU application may obtain an SDP answer from the application server. The WTRU may establish the PDU session for the application. Based on the request included in the PDU set feature capability indication, the WTRU may determine the PDU set feature enabled indication. The WTRU application may inform the AS whether the PDU set feature is enabled.

[0072] A PDU set feature capability indication may indicate whether and / or how a network supports a PDU set feature. The PDU set feature capability indication may request a WTRU to check if a PDU set feature is enabled. The PDU set feature enabled indication may indicate whether a PDU set feature is enabled.

[0073] A WTRU may (e.g., after the WTRU has negotiated a PDU set feature with an AS) be configured to perform one or more of the following processes. The WTRU may change the radio access network (RAN) node that may serve the WTRU. The WTRU may determine that there may be a change in a PDU set feature enabled indication (e.g., based on information obtained from the RAN node). The WTRU may send a control message to the AS indicating the change in the PDU set feature enabled indication.

[0074] A session management function (SMF) in a network that may support a PDU set feature may be configured to perform one or more of the following operations. The SMF may receive an indication from a RAN node indicating that the RAN node may support a PDU set feature. The SMF may receive a PDU session establishment request from a WTRU, which may include a request for a PDU set feature enabled indication. The SMF may determine whether the RAN node (e.g., which may forward the PDU session establishment request of the WTRU) supports the PDU set feature. The SMF may send a PDU session establishment response to the WTRU, which may include the determined PDU set feature enabled indication.

[0075] A network exposure function (NEF) may enable an AS to determine PDU set feature support provided by a network. The NEF may be configured to perform one or more of the following operations. The NEF may receive a request (e.g., a Nnef_RetrieveServiceParameter request) from the AS. The NEF may provide a PDU set feature capability indication to the AS (e.g., over a Nnef_RetrieveServiceParameter response). The NEF may receive a location request (e.g., a Nnef_Location request) from the AS, which may include an ID of a WTRU to be located. The NEF may send (e.g., indicate) the WTRU location to the AS, for example, using an Nnef location response. The NEF may receive another Nnef_RetrieveServiceParameterrequest from the AS, which may include the WTRU location. The NEF may provide a PDU set feature enabled indication to the AS, for example, over the Nnef_RetrieveServiceParameter response.

[0076] An SMF in a network that may support a PDU set feature may be configured to perform one or more of the following. The SMF may receive a PDU session establishment request or a PDU session modification request (e.g., from a WTRU), which may include PDU set feature configurations (e.g., PDU set options and / or PDU set marking configurations). The SMF may configure a user plane function (UPF) in the network to identify a PDU set and perform a configured PDU set marking (e.g., a PDU set marking based on the PDU set feature configuration). The SMF may configure a RAN node to expect the PDU set marking (e.g., over one or more general packet radio system (GPRS) tunneling protocol user plane (GTP-U) packets from a PDU session anchor user plane function or PSA UPF). The SMF may respond to the WTRU with a PDU session establishment response or a PDU session modification command. The response may confirm that the PDU set feature may be enabled for the PDU session.

[0077] Multiple enhancements may be implemented to support XRM traffic over a 3GPP network and / or the efficient transmission of traffic. For example, a PDU set may be used, which may include one or more PDUs, each carrying a payload of information. The payload of information may be generated at the application level (e.g., the payload may include a video frame, a video slice, etc. associated with an XR service or application). For example, an XRM video frame may be made up of numerous PDUs, and those PDUs may be treated together as a PDU set. A data burst may include multiple PDUs generated and / or sent by an application during a period of time. The data burst may include one or multiple PDU sets.

[0078] Within a communication system such as a 5G system (5GS), a QoS flow may be enabled with PDU set-based QoS handling. The PDU set-based QoS handling may refer to a set of actions, performed by various entities in the communication system (e.g., 5GS), that may allow a network (e.g., a next-generation radio access network or NG-RAN) to efficiently transmit traffic (e.g., XRM traffic) to a WTRU or receive traffic from the WTRU. The transmission / reception efficiency may be measured based on scheduling, latency, and / or power consumption. For example, if an NG-RAN node is aware that a given PDU may be the last PDU in a data burst to a WTRU, the NG-RAN node may instruct the WTRU to enter a discontinuous reception (DRX) mode to save power.

[0079] PDU set based QoS handling at a network node (e.g., an NG-RAN node) may be performed based on PDU set QoS parameters and / or other PDU set information. The PDU set QoS parameters may be determined by a policy control function (PCF) and / or may be provided by a session management function (SMF) to the network node, e.g., as part of a QoS profile. The PDU set QoS parameters may be used tosupport PDU set-based QoS handling in the network node. One or more PDU set QoS parameters may be sent to the network node to enable the PDU set based QoS handling.

[0080] The PDU set QoS parameters described herein may include a PDU set delay budget (PSDB), a PDU set error rate (PSER), and / or PDU set integrated handling information (PSI HI). If a network node (e.g., a NG- RAN) obtains PDU set QoS parameters and supports them, the network node may enable PDU set-based QoS handling and apply the PDU set QoS parameters.

[0081] The PDU set information described herein may be provided in the headers of the PDUs obtained from a PDU session anchor (PSA) user plane function (UPF). Based on one or more instructions from an SMF, the UPF may identify a PDU set, derive PDU set information for downlink (DL) traffic, and / or send the PDU set information to an NG-RAN. The PDU set information may be sent, for example, via a downlink GTP-U header of a (e.g., each) PDU identified as belonging to the PDU set.

[0082] The PDU set information may include an indication of an end PDU of the PDU set, which may identify the last PDU of the PDU set. The PDU set information may include a PDU set sequence number, which may identify the PDU set within a QoS flow. The PDU set information may include a PDU sequence number within a PDU set, which may identify a PDU within a PDU set (e.g., a numerical ID starting at 0 for a first PDU and incremented by 1 for each PDU in the set). The PDU set information may include a PDU set size, which may indicate a total number of PDUs in the PDU set, a cumulative length of the PDUs in the PDU set, or a cumulative length of PDU payload (e.g., transport payload) in the PDU set. For example, the cumulative length may be described as a number of bytes.

[0083] The PDU set information may include an indication of a PDU set importance. The PDU set importance may be a numerical value indicative of an importance level of the PDU set within a QoS flow (e.g., from highest priority value 0 to lowest priority value 255). A network device (e.g., a RAN or base station) may use the PDU set importance for PDU set level packet discarding (e.g., in the presence of congestion). The PDU set importance may be different from a QoS flow priority level (e.g., the QoS flow priority level may apply to an entire flow, while the PDU set importance may apply to an individual PDU set). Within a QoS flow with a given priority level, multiple PDU sets may be transmitted, each with its own PDU set importance. The PDU set importance may allow for the provision of a more granular level of services within a QoS flow (e.g., in case of congestion, the PDU set importance may be used to drop less important traffic within a single QoS flow).

[0084] Additional PDU set information elements may be indicated / considered (e.g., in one or more real-time transport protocol (RTP) header extensions). These additional PDU set information elements may include PDU set dependence information and / or a PDU set layer. The PDU set dependence information may indicatewhether a PDU set may be dependent or independent. The PDU set dependence information may include the IDs of PDU sets that a current PDU or PDU set may depend upon. The PDU set dependence information may include the IDs of PDU sets that may depend on a current PDU set. The PDU set layer may indicate a temporal or spatial layer to which an application unit transported in the PDU set may belong. As part of a QoS enforcement rule, a network device (e.g., a UPF) may be configured with a PDU set information marking indicator. The indicator may indicate to the network device that it may identify PDU sets and / or insert PDU set information related to packets belonging to the PDU set into a GTP-U header. The network device may perform PDU set identification using various mechanisms or by detecting real-time transport protocol (RTP)Zsecure RTP (SRTP) headers or payloads. For example, the network device may identify PDU set markings carried in an RTP / SRTP header and / or header extension. For a (e.g., each) DL PDU (e.g., obtained via N6) for which PDU set based QoS handling may be indicated by an SMF, the network device (e.g., the UPF) may apply rules associated with PDU set identification and / or provide PDU set information, for example, to a RAN node (e.g., in one or more GTP-U headers).

[0085] In examples, a core network device such as a UPF may or may not support PDU set identification from a PDU set marking. One or more access network nodes, such as one or more NG-RAN nodes, may use PDU set information or PDU set QoS parameters.

[0086] Delivery of immersive media via a real-time transport protocol (RTP) for IMS-based and / or WebRTC- based conversational services may be supported. The RTP may be a network protocol for delivering audio and / or video signals over an IP network. The RTP may be configured with specific settings and / or features that may enable immersive experiences. Performance and / or quality of experience (QoE) improvements may be achieved by specifying RTP configurations that may be integrated and / or optimized for a communication system and / or by leveraging cross-layer optimizations.

[0087] An RTP configuration may be based on PDU sets and / or PDU set markings. The RTP configuration may be used between endpoints (e.g., an application server (AS) and an application hosted on a WTRU). The endpoints may negotiate whether they may both support PDU sets and / or which PDU set markings may be included in RTP messages. A first endpoint may be an application that may be hosted on a first WTRU. A second endpoint may be an application server (AS) or an application hosted on a second WTRU (e.g., a remote WTRU).

[0088] The RTP endpoints may negotiate a header extension format (e.g., selection between a one-byte or two-byte header extension format). The RTP endpoints may negotiate one or more of the following PDU set markings: a PDU set size in bytes and / or an end of burst (EoB) marking. If the PDU set size in bytes is notsupported, the endpoints may assume that a PDU set size field may not be present. This may lead to a shorter header extension for an RTP session. If the end of burst (EoB) marking is not supported, the endpoints may ignore the EoB bits in an RTP header extension (HE). If the PDU set markings are agreed upon, they may be applied to (e.g., all) RTP packets of an RTP stream, through the lifetime of an RTP session.

[0089] An AS and / or an application that may be hosted on a WTRU may use session description protocol (SDP) signaling to negotiate PDU set features or options. The negotiation may be performed through an offer / answer exchange at a session setup or during an update (e.g., through a Session Initiation Protocol (SIP) re-lnvite). A sender (e.g., the AS or the application hosted on the WTRU) may indicate to a receiver (e.g., the WTRU hosted application or the AS) whether the sender may request adding PDU set markings in one or more header extensions. The indication may be included in an SDP message. After PDU set markings are negotiated between the endpoints, the relevant information / decisions may be provided to a network so that it may apply the PDU set markings.

[0090] PDU set related information (e.g., rules and / or configurations) may be signaled via an intermediate server and / or by a media session handler (MSH).

[0091] For signaling by an intermediate server (e.g., a trusted WebRTC signaling server or a P-CSCF), the intermediate server may be able to inspect an SDP offer / answer and extract information related to a PDU set and / or an end of burst marking. FIG. 2 illustrates examples of signaling that may be performed and / or relayed by an intermediate server. As shown in FIG. 2, a WTRU may send an SDP offer for establishing an XR session to a WebRTC signaling server or a P-CSCF. The signaling server may forward the request to an application server, which may respond with an SDP answer. The application server may include an indication of a PDU set and / or an end of burst (EoB) marking in the SDP, as described above. The signaling server may inspect the SDP and extract information related to the PDU set and / or the end of burst marking. The signaling server may inform an application function (AF) about the WebRTC session (or an IMS session). The information may include configurations associated with a PDU set and / or the EoB marking. The AF may use a procedure (e.g., a Npcf_PolicyAuthorization procedure or a Nef_AFSessionWithQoS procedure) to request the allocation of a QoS for the media streams of the IMS / WebRTC session. The AF may confirm the allocation of the QoS for the media streams to the signaling server. The signaling server may forward the SDP answer to the WTRU.

[0092] For signaling by a media session handler, an application on a WTRU may use an interface (e.g., M6 interface) to a media session handler to pass information about a session. The information may include media components of the session, a PDU set, and / or an end of burst marking configuration.

[0093] FIG. 3 illustrates an example of PDU set-based QoS handling. As shown in FIG. 3, the use of PDU set markings may be negotiated between endpoints (e.g., two RTP endpoints such as an application hosted on a WTRLI and an application server), and PDU set-based QoS handling may be performed within a communication system such as a 5GS. For example, a network device such as a core network device may provide PDU set QoS parameters to an access network node such as an NG-RAN (e.g., a base station). A UPF may identify PDU set markings in incoming traffic and may insert PDU set information related to packets that belong to a PDU set into a header (e.g., a GTP-U header). The NG-RAN may use the PDU set QoS parameters and / or the PDU set information to perform (e.g., tailor) access stratum operations.

[0094] PDU set options and / or PDU set marking configurations may be negotiated between endpoints, but in some examples, the endpoints may not be aware of whether a core network system, such as a 5GS, may support PDU set-based QoS handling and / or whether a RAN node serving a WTRU endpoint may support PDU set QoS parameters and / or PDU set information. As a result, the endpoints may negotiate PDU set related features or options (e.g., such as RTP configurations associated with a PDU set), but the PDU set features or options (e.g., configuration information related to a PDU set) may not be used by the system (e.g., a 5GS) that may transport messages (e.g., RTP messages) associated with the PDU set. This may lead to several issues. For example, unnecessary processing may occur at the endpoints, unnecessary buffering may be performed at a network device (e.g., at a UPF), resources may be wasted over a core network transport (e.g., between a PSA UPF and a RAN node) and / or over a wireless air interface (e.g., between the RAN node and a WTRU), etc. As another example, when a communication network is not informed about PDU set features or options (e.g., PDU set configurations), unnecessary restrictions may be imposed on an application at an endpoint (e.g., the endpoint may behave differently depending on whether or not the communication network applies PDU set based QoS handling). For instance, depending on whether or not PDU set features are enabled, the endpoint may be configured to use different codecs, apply (or not apply) application layer forward error correction (FEC), and / or alter the rates at which RTP packets may be transmitted. These inefficiencies and / or wastes may be eliminated or reduced by having the endpoints determine or negotiate PDU set features or options (e.g., PDU set marking configurations), and informing communication systems involved in the transport of a PDU set (e.g., core and / or RAN networks) about the PDU set features or options and letting the communication systems use those features or options (e.g., when transmitting or receiving packets associated with a PDU set).

[0095] An endpoint (e.g., an AS or AF) may be made aware of whether a communication network (e.g., a 5GS or a RAN node) supports PDU set-based QoS handling. The endpoint may negotiate a PDU set feature based on the information.

[0096] WTRU mobility may be addressed after endpoints have negotiated a PDU set feature. For example, after a PDU set feature has been determined, the WTRU may move to and away from a network (e.g., a RAN node) that may or may not support the PDU set feature. If the WTRU moves to a network that does not support the PDU set feature (e.g., PDU set based QoS handling) and stays connected to the network for a period of time, the WTRU may experience the issues described above. In this situation, an endpoint may be informed about whether the WTRU is connected to a network (e.g., a RAN node) that does not support the PDU set feature (e.g., PDU set based QoS handling).

[0097] When used herein, a PDU set method may refer to any technique or mechanism used to implement PDU sets and / or PDU set features. A PDU set method may be based on RTP header extensions and / or be applicable to encrypted traffic (e.g., to an encrypted PDU set). When used herein, PDU set QoS parameters may refer to QoS parameters that may be applied to a PDU set (e.g., PSDB, PSER, and / or PSI HI). When used herein, PDU set information may refer to information that may be supplied to a network node (e.g., a RAN node) so that it may optimize the transmission of a PDU set. Such PDU set information may be contained in a GTP-U header of a PDU sent from a PSA UPF to a RAN node. When used herein, PDU set marking may refer to a process at a network device such as a PSA UPF that may mark the GTP-U headers of arriving PDUs with PDU set information. When used herein, PDU set options may refer to options that may be configured for a PDU set feature. For example, a PDU set option may indicate if a PDU set method may be used (e.g., whether a PDU set feature applies to UL traffic or DL traffic), and, in the case of RTP header extensions, if a one-byte or a two-byte header extension format may be used. When used herein, a PDU set marking configuration may refer to a configuration for marking a PDU set (e.g., by an endpoint or a UPF). The PDU set marking may include a PDU sequence number, a PDU set start indication, a PDU set end indication, an end of burst indication, etc. When used herein, a PDU set feature capability indication may refer to a set of information elements indicating whether a network supports PDU set QoS handling. When used herein, a PDU set feature enabled indication may refer to a set of information elements indicating whether a PDU set feature may be enabled. A PDU set feature may be enabled or disabled for specific WTRUs and / or specific network nodes (e.g., RAN nodes). When used herein, PDU set handling information may refer to a set of information or information elements indicating how PDU sets should identified and marked in a wireless network. For example, the PDU set handling information may include information on a PDU set method and / or a PDU setmarking configuration. The terms “PDU set QoS handling,” “PDU set features,” “PDU set-based QoS handling” and “PDU set-based reception and transmission” may be used interchangeably herein. When used herein, a RAN node may refer to a radio access network node (e.g., including a gNB, an eNB, and / or a WiFi access point). When used herein, a NG-RAN node may refer to a base station (e.g., a gNB and / or an ng-eNB), which may communicate using a core network (e.g., a 5G core network or 5GC).

[0098] One or more of the following may be applied or implemented (e.g., to enable efficient PDU set feature negotiation). A WTRU may determine a PDU set feature capability indication and / or a PDU set feature enabled indication. An application server may determine a PDU set feature capability indication and / or a PDU set feature enabled indication. A PDU set feature capability indication may be changed. A PDU set feature enabled indication may be monitored. A network may be informed about a configured PDU set feature.

[0099] A PDU set feature may be configured and / or used when necessary and feasible. If a PDU set feature is improperly configured (e.g., a WTRU and an AS may use a PDU set feature, but the feature may not be supported by a core network), network radio resources and / or network buffering resources may be wasted. If an AS is not aware of whether a network supports a PDU set feature, the AS may not be able to leverage that knowledge to tailor XRM related transmissions.

[0100] FIG. 4 illustrates an example of negotiating and / or enabling a PDU set feature. As shown in FIG. 4, a WTRU may, at 1 , obtain a user equipment route selection policy (URSP) to determine if an application may use a PDU set feature (e.g., after the application is started on the WTRU). At 2 and / or 3, the WTRU may determine a PDU set feature capability indication and / or a PDU set feature enabled indication, respectively. As shown in the figure, the WTRU may do so by communicating with various network devices including, for example, a RAN node, an AMF, and / or an SMF. At 4, the application hosted in the WTRU may be provided with the PDU set feature capability indication and / or the PDU set feature enabled indication. At 5, the application may determine whether to negotiate the PDU set feature. At 6, the application may negotiate, with an application server, a configuration for the PDU set feature (e.g., a PDU set option and / or a PDU set marking configuration). At 7, the application server may provide the negotiated PDU set configuration to a network (e.g., to a PCF, SMF, and / or UPF via a NEF). At 8, the application may start application related traffic and / or begin to monitor for the PDU set feature enabled indication. At 9, the WTRU may inform the application server about the determined PDU set feature enabled indication or a change in the PDU set feature indication. The order of the aforementioned operations / processes may be altered, and one or more of the operations / processes (e.g., the WTRU determining the PDU set feature enabled indication at 3) may be omitted.

[0101] A WTRU may be provided with an updated URSP that may contain a policy, rule, or configuration related to a PDU set feature. The policy may indicate whether an application may use the PDU set feature. The policy may indicate which PDU set method to use for the PDU set feature (e.g., this information may also be provided as a prioritized list of PDU set methods). The policy may indicate if the WTRU may request and / or negotiate the use of PDU sets for an application before enabling the PDU set feature for an application. The policy may provide a partial configuration associated with the PDU set feature. The policy may provide an indication of PDU set options that may be requested or negotiated.

[0102] As shown at 1 of FIG. 4, the WTRU may start an XRM application flow. The WTRU may use the URSP and determine that the XRM application flow may use the PDU set feature indicated by the URSP. The WTRU may determine a PDU set method to use for the application flow. The WTRU may make this determination based on a prioritized list of PDU set methods or based on the capabilities of the WTRU. The WTRU may send a supported list of PDU set methods to an application server (AS) in a subsequent process and have the AS determine the PDU set method.

[0103] If the WTRU determines to use the PDU set feature for the application flow, the WTRU may (e.g., at 2 of FIG. 4) determine if a communication network (e.g., a 5GC) supports the PDU set feature. The WTRU may obtain (e.g., receive) a PDU set feature capability indication (e.g., including PDU set related configuration information) from the 5GC to make the determination. The WTRU may decide to initiate PDU set feature negotiation if the 5GC supports PDU set based QoS handling. The WTRU may decide to start the PDU set feature negotiation and include the PDU set feature capability indication when exchanging information with the AS.

[0104] If the USRP indicates that the WTRU may use the PDU set feature for the application flow, the WTRU may interpret the indication as a confirmation (e.g., an implicit confirmation) that the core network (e.g., 5GC) supports the PDU set feature. In this situation, the WTRU may still determine the PDU set feature capability indication to obtain additional context related to the core network’s support for the PDU set feature.

[0105] The WTRU may determine (e.g., explicitly) if the core network (e.g., 5GC) may support the PDU set feature. For example, the WTRU may be in a visited PLMN (VPLMN) that may not support the PDU set feature. The WTRU may obtain a PDU set feature capability indication to determine if the core network (e.g., 5GC) supports the PDU set feature and to determine additional context related to the PDU set feature.

[0106] The PDU set feature capability indication described herein may include a context related to the core network’s support of the PDU set feature. The indication may be an information element (IE) that may include an indication of whether the PDU set feature is supported by the core network (e.g., 5GC). The PDU setfeature capability indication may indicate whether the WTRU should verify that the PDU set feature is enabled (e.g., the WTRU may check enablement of the PDU set feature). In examples, the WTRU may assume that the feature is supported in one or more (e.g., all) RAN nodes, so the WTRU may not check whether the PDU set feature is enabled. In examples, a core network (e.g., 5GC) may be aware that not all RAN nodes support the PDU set feature, and the WTRU may check whether or not the feature is enabled.

[0107] The PDU set feature capability indication may include location information. For example, the core network may provide (e.g., configure) the PDU set feature for an area, a RAN node, or a tracking area, and the WTRU may be provided with this information (e.g., in the form of a geofence, a list of RAN nodes, or a list of tracking areas).

[0108] The PDU set feature capability indication may include timing information. For example, the core network may provide an indication that the PDU set feature for a RAN node may be configured for a period of time (e.g., the network may limit XRM traffic to one or more periods of a day). The core network may provide an indication to the WTRU that the RAN node may support PDU set based QoS handling during those periods.

[0109] The PDU set feature capability indication may include information on a PDU set marking supported by the core network (e.g., by a PSA UPF). The PDU set feature capability indication may indicate a granularity of support for the PDU set feature (e.g., per slice or per slice type). The PDU set feature capability indication may indicate that the PDU set feature may be supported for all or some particular slices. The PDU set feature capability indication may indicate that the PDU set feature may be supported for all or some particular slice types. The PDU set feature capability indication may indicate one or more data networks over which the PDU set feature may be supported. These data networks may include a list of specific data networks or all available data networks. The data network indication may be combined with the slice indication. For example, the core network may provide an indication of which S-NSSAI / DNN combinations may support the PDU set feature.

[0110] The PDU set feature capability indication may indicate to the WTRU that the WTRU is required to obtain authorization to use the PDU set feature within the core network (e.g., 5GC). For example, the core network may decide that the WTRU may not use the PDU set feature for a time or for an area, so when establishing a PDU session for the WTRU (e.g., for transporting XRM traffic), the core network may provide a QoS rule indicating whether the WTRU may use the PDU set feature.

[0111] A WTRU may determine and / or obtain (e.g., receive) a PDU set feature capability indication by performing one or more of the following operations. If a communication network, such as a 5GC, supports a PDU set feature, the network may provide a PDU set feature capability indication (e.g., indicating PDU set marking and / or transmission methods) to the WTRU. For example, the network (e.g., an SMF) may provide thePDU set feature capability indication in a registration accept message. The indication may be included as an IE or as a sub-IE of another IE. The network (e.g., an AMF or an SMF) may determine to provide the PDU set feature capability indication based on a WTRU-provided or requested NSSAI, based on subscription information for the WTRU (e.g., whether the WTRU may access XRM services), and / or based on network support of a PDU set feature (e.g., associated with a requested NSSAI).

[0112] In examples, the network may provide the PDU set feature capability indication in a PDU session establishment accept or a PDU session modification command message (e.g., in response to a PDU session establishment or modification request). The indication may be included in an IE or a sub-IE of another IE. The indication may be included as part of a protocol configuration option (PCO) provided to the WTRU. For instance, an SMF may determine to provide the PDU set feature capability indication based on a WTRU- requested DNN, based on SM subscription information for a DNN / S-NSSAI combination (e.g., whether the WTRU may access XRM services on the network slice and / or the DNN), and / or based on the network’s support for the PDU set feature (e.g, associated with the DNN / S-NSSAI combination).

[0113] In examples, the network may provide the PDU set feature capability indication in an RRC message transmitted by a RAN node. If the RAN node supports the PDU set feature and the 5GC also supports the PDU set feature, the RAN node may provide the PDU set feature capability indication as part of a broadcast message. The broadcast message may include a PDU set feature capability flag, which may be broadcast in a particular cell or in a group of cells. The WTRU may assume that the absence of such a broadcast message from the RAN node may indicate (e.g, implicitly) that the network may not support the PDU set feature. For example, the indication may be provided in a master information block (MIB) or one of the system information blocks (SIBs). The indication may be provided in an RRC setup message, an RRC reconfiguration message, or another (e.g, newly defined) RRC message.

[0114] In examples, the network may not provide the PDU set feature capability indication to the WTRU. Instead, the WTRU may have the information provisioned in its USIM. For example, the USIM may have information as to whether a PLMN may support the PDU set feature. The WTRU may have the information preconfigured in the USIM. The WTRU may obtain the information through operation and maintenance (CAM) signaling or an over-the-air (OTA) mechanism.

[0115] In examples, the WTRU may (e.g, at 3 of FIG. 4) determine the PDU set feature enabled indication based on information received from the network (e.g, such as a 5GC). The WTRU may be informed about whether the PDU set feature may be enabled. The WTRU may be informed about whether a RAN node supports the PDU set feature and / or whether the PDU set feature is enabled for the RAN node. The WTRUmay skip the determination if an XRM application flow is carried on a different PDU session or over another access network.

[0116] The PDU set feature enabled indication may be an information element (IE) that may indicate if the PDU set feature is enabled for a RAN node to which the WTRU may be connected. The PDU set feature enabled indication may indicate whether the PDU set feature is enabled in one or more neighbor RAN nodes. The WTRU may be provided with a list of RAN nodes where the PDU set feature may be enabled. The PDU set feature enabled indication may include timing information. For example, a network may provide an indication that the PDU set feature for a RAN node may be enabled for a period of time (e.g., the network may limit XRM traffic to certain periods of a day), and the network may provide an indication to the WTRU that the RAN node may enable PDU set based QoS handling during these periods. The PDU set feature enabled indication may include capacity information, such as, for example, how many WTRUs may use the feature at the same time on the RAN node, and / or an indication of the current number of users. The PDU set feature enabled indication may indicate a priority of the feature. The WTRU may use the priority information (e.g, a priority order) to determine whether to use the feature immediately or wait for a certain amount of time before using the feature.

[0117] The network may provide the PDU set feature enabled indication (e.g, if the PDU set feature is enabled) to the WTRU via one or more of the following. The network may provide the PDU set feature enabled indication in an NAS message. For example, the SMF may include the indication in a PDU session establishment accept or a PDU session modification command message (e.g, in response to a PDU session establishment or modification request). The indication may be included in an IE or a sub-IE of another IE. The indication may be included as part of a protocol configuration option (PCO) provided to the WTRU. A RAN node may notify the SMF about whether the RAN node supports the PDU set feature. The RAN node may provide this information when the PDU set feature is activated or when support for the PDU set feature changes. The RAN node may provide the indication when the WTRU selects the RAN node as a serving RAN node. The SMF may determine whether the PDU set feature is enabled based on a support indication obtained (or not obtained) from the RAN node. The SMF may determine whether the feature is enabled on a per-PDU session basis. The WTRU may initiate an exchange with the SMF to determine the PDU set feature enabled indication.

[0118] The network may provide the PDU set feature enabled indication in an RRC message transmitted by a RAN node. If the RAN node supports the PDU set feature, the RAN node may broadcast information about the support. The broadcast message may include a PDU set feature enabled flag. The message may bebroadcast in a cell or in a group of cells. A WTRU may assume that an absence of such a broadcast message from the RAN node may indicate that the RAN node may not support the PDU set feature and / or that the PDU set feature may be disabled. For example, the RAN node may provide a PDU set feature enabled indication as part of the system information transmitted in a master information block (MIB) or one of the system information blocks (SIBs). The PDU set feature enabled indication may be provided in an RRC setup message, an RRC reconfiguration message, or another (e.g., newly defined) RRC message. The WTRU may initiate an exchange with the RAN node to determine the PDU set feature enabled indication.

[0119] The PDU set feature capability indication, PDU set feature enabled indication, and / or PDU set method described herein may be associated with an access stratum and / or a non-access stratum of the WTRU (e.g., received via a mobile terminal (MT) of the WTRU). On the other hand, the PDU set feature negotiation process described herein may be between an application hosted on the WTRU and an application server (AS). Hence, once the MT of the WTRU has determined the PDU set feature capability indication, the PDU set feature enabled indication, and / or the PDU set method, the MT may (e.g, at 4 of FIG. 4) provide information related to the PDU set feature capability indication, the PDU set feature enabled indication, and / or the PDU set method to the application hosted on the WTRU, so that PDU set options (e.g, including PDU set marking configurations) may be negotiated between the application and the AS.

[0120] In examples, the WTRU application may determine the PDU set feature capability indication, the PDU set method, and / or the PDU set feature enabled indication in the following way. The application may retrieve information related to the PDU set feature capability indication, the PDU set method, and / or the PDU set feature enabled indication using one or more ATtention (AT) commands (e.g, the MT may expose the information to the application and the information may be retrieved using the AT commands). The information may be retrieved using an AT command “+CGCONTRDP.” The application may use the command to retrieve a dynamically allocated PDU session context. This context may include the PDU set feature capability indication, the PDU set feature enabled indication, and / or the PDU set method. For example, a returned PDU session context may indicate that the PDU set feature may be enabled for the PDU session. The information may be retrieved using an AT command “-CGDCONT.” The application may use this command to retrieve an allocated PDU session context. This context may include the PDU set feature capability indication, the PDU set feature enabled indication, and / or the PDU set method. The information may be retrieved using an AT command “-RDGREG,” “+CEREG,” or “-C5GREG.” The application may use one of these commands to retrieve information regarding a PLMN with which the WTRU may be registered. The retrieved information may include the PDU set feature capability indication.

[0121] If the WTRU is aware of the PDU set feature capability indication, the PDU set feature enabled indication, and / or the PDU set method, the WTRU may take one or more of the following actions (e.g., at 5 of FIG. 4). If the PDU set feature capability indication indicates that the communication network (e.g., a 5GC) associated with the WTRU supports a PDU set feature, the WTRU may determine whether or not it should determine the PDU set feature enabled indication. For example, the WTRU may determine the PDU set feature enabled indication if the WTRU receives an indication to do so in the PDU set feature capability indication (e.g., if an indication to check enablement is included in the PDU set feature capability indication). If the WTRU decides to obtain the PDU set feature enabled indication, the WTRU may use one or more of the procedures described herein to obtain the PDU set feature enabled indication. As another example, if the PDU set feature capability indication indicates that the communication network (e.g., 5GC) supports the PDU set feature, the WTRU may include the PDU set feature capability indication, a selected PDU set method, a list of supported PDU set methods, and / or the PDU set feature enabled indication, in an exchange with the AS (e.g., to negotiate PDU set options and PDU set marking configurations with the AS).

[0122] If the PDU set feature capability indication indicates that the network (e.g., 5GC) may not support the PDU set feature, the WTRU may decide not to negotiate PDU set options and PDU set marking configuration with the application server. If the PDU set feature capability indication indicates that the network (e.g, 5GC) may support the PDU set feature, the WTRU may include the PDU set feature capability indication in an exchange with the application server (e.g, to negotiate PDU set options and PDU set marking configuration with the application server).

[0123] An application hosted on the WTRU may (e.g, at 6 of FIG. 4) negotiate a PDU set feature with an AS. A configuration of a PDU set feature may be provided (e.g, at 7 of FIG. 4) to a core network and / or a RAN node. The AS may (e.g, upon receiving an SDP offer during the PDU set feature negotiation with a PDU set feature capability indication indicating that the PDU set feature may be supported) determine the PDU set options to use and / or one or more PDU set marking configurations. For example, the AS (or an AF) may negotiate the usage of an RTP HE for transmitting PDU set information (e.g, PDU set marking by the AS and / or a UPF during a media session), and may inform a core network (e.g, a 5GC) about the PDU set information (e.g, support for the PDU set information). Such information may be used to configure PDU set features in the core network and / or in a RAN node. For example, information regarding an RTP header extension (e.g, an RTP HE ID) generated at an RTP session creation time may be signaled to an AF so that the information may be carried to a UPF through a PCF and / or an SMF. The AS may provide an SDP answerto the application hosted on the WTRU. A PDU set option described herein may include a PDU set method (e.g., for marking and / or transmitting a PDU set).

[0124] The AS may use PDU set related information to influence the type of FEC that may be used for XRM traffic. For example, upon receiving an SDP offer (e.g., during PDU set feature negotiation) with a PDU set feature capability indication indicating that a PDU set feature may be supported, or a PDU set feature enabled indication indicating that the PDU set feature may not be enabled (e.g., when a WTRU is connected to a non- 3GPP node), the AS may use such information to determine an FEC associated with the transport of XRM traffic. The AS may use the PDU set feature enabled indication to take a preventative action. For example, the AS may implement a gap (e.g., of a certain duration) between data bursts to help a WTRU save power. As another example, the AS may use a different encoder if the PDU set feature may not be supported.

[0125] As shown in the figures provided herein (e.g., FIG. 2 or FIG. 3), a WTRU may initiate an SDP exchange. For services that may be initiated by an application server, the AS may initiate the SDP exchange, and the WTRU may provide a PDU set configuration in an SDP answer sent back to the AS.

[0126] A WTRU may start an application flow for XRM traffic upon completing a PDU set feature negotiation. Based on a selected PDU session for the application flow and / or a serving RAN node, the WTRU may determine an initial PDU set feature enabled indication and / or inform an AS about whether a PDU set feature is enabled. The WTRU may monitor for a PDU set feature enabled indication from a communication network or the AS to determine if the PDU set feature is enabled. This may be because, for example, the WTRU may have switched to another serving RAN node due to mobility, and the other RAN node may not support PDU set related features (e.g., the RAN node may be a non-GPP node or a RAN node from an older technology such as 4G). The WTRU may monitor for the PDU set feature enabled indication because the communication network and / or the AS may enable / d isable the PDU set feature dynamically (e.g., to optimize network resources based on costs incurred for enabling the PDU set features). Another example reason for monitoring the indication may be that a PDU set feature may be offered only to users with a specific level of capabilities / qualities. For example, the highest paying users may have the PDU set feature enabled for the entire duration of an application (e.g., a guaranteed PDU set feature), while a lower paying user may have the PDU sets feature disabled if the network experiences congestion or has a resource usage issue (e.g., a nonguaranteed PDU set feature).

[0127] The WTRU may inform the AS about an initial PDU set feature enabled indication and / or the time at which the PDU set feature enabled indication may have changed. To determine when the PDU set feature enabled indication may have been changed, a network may send a message to the WTRU. The WTRU maydetermine a PDU set enabled indication using one of the procedures described herein for obtaining the PDU set feature enabled indication. For example, upon switching to a serving RAN node that may not broadcast a PDU set enabled indication, the WTRU may assume that the PDU set feature may be disabled. The broadcast may be configured for all WTRUs, for WTRUs for which the network has determined to disable the PDU set feature, or for WTRUs for which the PDU set feature may be non-guaranteed. The WTRU may subscribe to be notified when the PDU set feature enabled indication changes. The network may be configured to (e.g., always) provide the information to the WTRUs.

[0128] Upon determining an initial PDU set feature enabled indication or upon determining that the PDU set feature enabled indication may have been changed, the WTRU may display a message to a user that the PDU set feature may not be in use for an application flow. In response, the user may decide to terminate the application and / or change the connectivity for the application (e.g., from cellular to Wi-Fi). The WTRU may use a control protocol (e.g., RTCP) to send a message from the WTRU to an AS to provide the PDU set feature enabled indication to the AS. The message may indicate one or more available PDU set methods, PDU set options, and / or a PDU set marking configuration. The WTRU may issue an SIP re-invite or perform an SDP renegotiation to provide the PDU set feature enabled indication in a message to the AS. The message may indicate one or more available PDU set methods, PDU set options, and / or a PDU set marking configuration.

[0129] Upon receiving a PDU set feature enabled indication, an AS may perform one or more of the following actions. The AS may use the indication to start or stop providing PDU set lEs in the PDUs for an application. The AS may use the indication to change the method for providing PDU set lEs. For example, the AS may change a codec configuration. The AS may inform an application operator if the PDU set feature may be disabled or stopped for an application.

[0130] The AS may subscribe to be notified when a PDU set feature enabled indication changes (e.g., as an alternative to having the WTRU determine the PDU set feature enabled indication and provide the information to the AS). The AS may use an NEF service for the subscription (e.g., a Nnef_RetrieveServiceParameter service). Upon receiving a notification, the AS may change the PDU set options and PDU set marking configuration that may have been configured. The AS may notify an application hosted on the WTRU of the change in the PDU set options and PDU set marking configuration. If the WTRU is notified about the change in the PDU set options and PDU set marking configuration, the WTRU may configure an RTP accordingly.

[0131] If a change in a PDU set feature enabled indication is temporary or periodic, the corresponding PDU set feature may be suspended. In such a case, a network may notify an application server or a WTRU about the suspended PDU set feature. The AS and / or a WTRU application may decide to keep using a current RTPsession, even though the PDU set feature may be suspended in the network. The AS and WTRU application may also terminate the RTP session and reinitiate a session when the PDU set feature suspension is finished (e.g., when they obtain a PDU set suspension finished indication from the network).

[0132] A PDU set feature capability indication and / or a PDU set feature enabled indication may be changed dynamically. For example, the PDU set feature capability indication may change if a WTRU roams in a visited PLMN that may not support PDU sets, or if the network decides to switch to another PSA UPF that may not support PDU sets.

[0133] In an AS-based example, the AS may subscribe to be notified when a PDU set feature capability indication changes. The AS may use an NEF service to subscribe to be notified (e.g., a Nnef_RetrieveServiceParameter service). Upon receiving a notification, the AS may decide to change the PDU set options and the PDU set marking configuration that may have been configured. The AS may notify an application hosted on a WTRU of the change in the PDU set options, and the PDU set marking configuration, for example, by initiating its own SDP offer to the WTRU. If the WTRU is notified about the change in the PDU set options, and the PDU set marking configuration, the WTRU may configure an RTP accordingly.

[0134] In a WTRU-based example, a network may send a message to a WTRU to inform the WTRU about the change in a PDU set feature capability indication. The changed PDU set feature capability indication may be provided using one of the procedures described herein for obtaining a PDU set feature capability indication. The WTRU may subscribe to be notified when the PDU set feature capability indication changes. The WTRU may then issue an SIP re-invite to inform an AS about the changed PDU set feature capability indication or to inform the AS about proposed PDU set options and PDU set marking configurations.

[0135] If the change in a PDU set feature capability indication is temporary or periodic, the use of PDU sets may be suspended (e.g., temporarily suspended). In such a case, a network may notify an application server or a WTRU about the suspended PDU set feature. The AS and / or a WTRU application may keep using the current RTP session, even though the PDU set feature may be suspended in the network. The AS and WTRU application may terminate the current RTP session and reinitiate a session when the PDU set feature suspension is finished (e.g., when they obtain a PDU set suspension finished indication from the network).

[0136] An application on a WTRU and / or an AS may configure PDU set options and / or a PDU set marking configuration without using an SDP negotiation (e.g., without being aware of a PDU set feature capability indication, a PDU set feature enabled indication, and / or PDU set methods). For example, after negotiating some default PDU set feature options and / or configuration details, the AS may query a network to determine if the network supports a PDU set feature and / or if a WTRU is served by a cell that may support the PDU setfeature and has the PDU set feature enabled. FIG. 5 illustrates an example of an application server (AS) determining the support for a PDU set feature by a communication network. As shown, a WTRU (e.g., an application hosted on the WTRU) and an AS may negotiate default PDU set options and / or a PDU set marking configuration at 1 . The WTRU may indicate the current serving RAN node (e.g., a Cell ID) to the AS. At 2, the application server may query a core network to determine a PDU set feature capability indication. The AS may use a NEF service (e.g., a Nnef_RetrieveServiceParameter service) to obtain the PDU set feature capability indication from the core network. The AS may request the indication (e.g., per slice, per slice type, or per S- NSSAI / DNN combination). At 3, the AS may determine the WTRU location (e.g., using a Nnef location service) and / or use a service described herein to obtain the PDU set feature enabled indication at the determined location. At 4, the AS may change the PDU set options and the PDU set marking configuration configured at 1 . The AS may notify the application hosted on the WTRU of the change in the PDU set options and PDU set marking configuration, for example, by initiating its own SDP offer to the WTRU or by sending an RTCP message. At 5, if the WTRU is notified about the change in the PDU set options and PDU set marking configuration, the WTRU may configure RTP accordingly. The AS may (e.g., an alternative to the operations at 2 and 3) use the service described herein and provide a WTRU identity to the network. The network may retrieve the WTRU location based on the WTRU identity. The network may provide the PDU set feature capability indication and the PDU set feature enabled indication at the retrieved WTRU location.

[0137] A WTRU may provide an indication of a PDU set feature to a core network, for example, through NAS layer signaling (e.g., via a mobility management (MM) message or a session management (SM) message). FIG. 6 illustrates an example of a core network being informed about a PDU set feature via a WTRU message (e.g., a WTRU request). At 1 , the WTRU (e.g., an application hosted on the WTRU) and an AS may negotiate PDU set options (e.g., including PDU set marking configurations). At 2, the WTRU may determine a PDU set feature capability indication and / or a PDU set feature enabled indication. At 3, the WTRU may send a PDU session modification request to a network device (e.g., an SMF). The request may include an indication that the PDU set feature may be used for a PDU session. This request may also include PDU set options (e.g., including PDU set marking configurations). At 4, the SMF may contact a serving PCF for SM policy association establishment and may include an indication that the PDU set feature may be used. The PCF may derive policies pertaining to PDU sets and may send the policies (e.g., PCC rules) to the SMF. At 5, the SMF may configure a UPF to identify the PDU sets and perform PDU set marking (e.g., based on the configuration information described herein). At 6, the SMF may configure a RAN node to expect the PDU set markings (e.g., over GTP-U packets from the UPF such as a PSA UPF). At 7, the SMF may respond to theWTRU with a PDU session modification command, which may confirm that the PDU set feature may be enabled for the PDU session.

[0138] According to embodiments of the present disclosure, a network device such as an SMF associated with a wireless communication network may be configured to receive PDU set handling information that may indicate at least one or more transport protocol header extensions associated with a marking of a PDU set. The PDU set handling information may further indicate whether the PDU set handling information applies to an uplink transmission of the wireless communication network or a downlink transmission of the wireless communication network. The network device may be further configured to receive a PDU session establishment or modification request, and, in response to receiving the PDU session establishment or modification request, the network device may send a message to another network device (e.g., a UPF of the wireless communication network) or a WTRU. The message may indicate the PDU set handling information received by the network device.

[0139] The one or more transport protocol header extensions include a real-time transport protocol (RTP) header extension. In examples, the RTP header extensions may indicate at least one of an end PDU of the PDU set, an importance of the PDU set, a PDU sequence number associated with the PDU set, or a size of the PDU set. In example, the network device may be further configured to perform a session management function (SMF) associated with the wireless communication network (e.g., the network device may be an SMF device).

[0140] The PDU set handling information received by the SMF may be provided by a PCF of the wireless communication network. In examples, the SMF may receive an indication from a RAN node that the RAN node may support PDU set-based transmissions or receptions. In examples, the SMF may send the message that indicates the PDU set handling information in response to receiving the indication from the RAN node. In examples, the message that indicates the PDU set handling information may be sent to the UPF and may include an instruction for the UPF to perform PDU set marking via the one or more transport protocol header extensions. In examples, the PDU set handling information may further include information regarding an encryption of the PDU set.

[0141] Although features and elements are described herein in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include,but are not limited to, a read only memory (ROM), a random-access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magnetooptical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS1 . A network device associated with a wireless communication network, the network device comprising: a processor configured to: receive protocol data unit (PDU) set handling information that indicates one or more transport protocol header extensions associated with a marking of a PDU set, the PDU set handling information further indicating whether the PDU set handling information is applicable to uplink traffic, downlink traffic, or both the uplink traffic and the downlink traffic; receive a PDU session establishment or modification request; and in response to the reception of the PDU session establishment or modification request, send a message to another network device or a wireless transmit / receive unit (WTRU), wherein the message indicates the PDU set handling information received by the network device.

2. The network device of claim 1 , wherein the one or more transport protocol header extensions include a real-time transport protocol (RTP) header extension.

3. The network device of claim 2, wherein the RTP header extension indicates one or more of an end PDU of the PDU set, an importance of the PDU set, a PDU sequence number associated with the PDU set, or a size of the PDU set.

4. The network device of claim 1 , wherein the processor is further configured to perform a session management function associated with the wireless communication network.

5. The network device of claim 1 , wherein the PDU set handling information is received from a policy control function of the wireless communication network.

6. The network device of claim 1 , wherein the processor is further configured to receive an indication from a radio access network (RAN) node that the RAN node supports PDU set-based transmissions or receptions.

7. The network device of claim 6, wherein the processor is configured to send the message that indicates the PDU set handling information in response to receiving the indication from the RAN node.

8. The network device of claim 6, wherein the processor is further configured to send quality of service (QoS) related information associated with the PDU set to the RAN node, and wherein the indication that the RAN node supports PDU set-based transmissions or receptions is received from the RAN node as a response to the QoS related information.

9. The network device of claim 1 , wherein the message that indicates the PDU set handling information is sent to a user plane function (UPF) of the wireless communication network.

10. The network device of claim 9, wherein the message includes an instruction for the UPF to perform PDU set identification or PDU set marking based on the PDU set handling information.

11. The network device of claim 1, wherein the PDU set handling information further includes information regarding an encryption of the PDU set.

12. The network device of claim 1, wherein the message sent by the processor in response to the reception of the PDU session establishment or modification request includes a PDU session establishment or modification response sent to the WTRU.

13. A method performed by a network device associated with a wireless communication network, the method comprising: receiving protocol data unit (PDU) set handling information that indicates one or more transport protocol header extensions associated with a marking of a PDU set, the PDU set handling information further indicating whether the PDU set handling information is applicable to uplink traffic, downlink traffic, or both the uplink traffic and the downlink traffic; receiving a PDU session establishment or modification request; and in response to receiving the PDU session establishment or modification request, sending a message to another network device or a wireless transmit / receive unit (WTRU), wherein the message indicates the PDU set handling information received by the network device.

14. The method of claim 13, wherein the one or more transport protocol header extensions include a realtime transport protocol (RTP) header extension.

15. The method of claim 13, wherein the RTP header extension indicates one or more of an end PDU of the PDU set, an importance of the PDU set, a PDU sequence number associated with the PDU set, or a size of the PDU set.

16. The method of claim 13, wherein the network device is configured as a session management function of the wireless communication network.

17. The method of claim 13, wherein the PDU set handling information is received from a policy control function of the wireless communication network.

18. The method of claim 13, further comprising receiving an indication from a radio access network (RAN) node that the RAN node supports PDU set-based transmissions or receptions.

19. The method of claim 18, the message that indicates the PDU set handling information is sent in response to receiving the indication from the RAN node.

20. The method of claim 18, further comprising sending quality of service (QoS) related information associated with the PDU set to the RAN node, wherein the indication that the RAN node supports PDU set-based transmissions or receptions is received from the RAN node as a response to the QoS related information.21 . The method of claim 13, wherein the message that indicates the PDU set handling information is sent to a user plane function (UPF) of the wireless communication network.

22. The method of claim 21 , wherein the message includes an instruction for the UPF to perform PDU set identification or PDU set marking based on the PDU set handling information.

23. The method of claim 13, wherein the PDU set handling information further includes information regarding an encryption of the PDU set.

24. The method of claim 13, wherein the message sent in response to the reception of the PDU session establishment or modification request includes a PDU session establishment or modification response sent to the WTRU.

Images