Methods and apparatus for adaptive bitrate support for XR traffic in a communication network

Abstract

Systems, methods, devices, and instrumentalities are described herein for providing adaptive media streaming. A first network node (e.g., a UPF) can be provided. The first network node can include a processor configured to determine one or more presentation detection rules. A first message can be received from a second network node (e.g., an AS). The first message can include a protocol data unit (PDU) and indicate a first presentation. The first presentation can be detected based on the PDU and the one or more presentation detection rules. A presentation identification (ID) can be determined to be associated with the first presentation. The presentation ID can be determined to indicate a change from a second presentation to the first presentation. A second message can be sent to a third network node (e.g., a SMF) based on determining that the presentation ID indicates the change from the second presentation to the first presentation.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 547,053, filed November 2, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] This disclosure relates to processes, methods, architectures, apparatuses, systems, devices, and computer program products for and / or for adaptive bit rates for extended reality (XR) services in communication networks, particularly 5G networks. Summary of the Invention

[0003] This document describes systems, methods, apparatus, and means for providing adaptive media streaming. A first network node (e.g., UPF) may be provided. The first network node may include a processor configured to determine one or more reversion detection rules. A first message may be received from a second network node (e.g., AS). The first message may include a Protocol Data Unit (PDU) and indicate a first reversion. The first reversion may be detected based on the PDU and one or more reversion detection rules. A reversion identifier (ID) associated with the first reversion may be determined. A reversion ID may be determined to indicate a change from the second reversion to the first reversion. Based on the determination of the reversion ID indicating a change from the second reversion to the first reversion, a second message may be sent to a third network node (e.g., SMF). The second message may indicate a change from the second reversion to the first reversion. A third message may be sent to a fourth network node (e.g., RAN). The third message may include a PDU and may indicate the first reversion and the reversion ID.

[0004] In the example, the demo is at least one of resolution or codec. One or more demo detection rules can be received from a third network node (e.g., SMF). The first message may include a detection method and one or more IDs, wherein a demo ID is detected from the demo according to the detection process, and wherein the demo ID comes from one or more IDs. The demo detection rules may be based on one or more input service characteristics. The third message further indicates resource usage associated with the demo ID, demo selection prompts, and changes to the demo ID. Attached Figure Description

[0005] A more detailed understanding can be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. Like the detailed description, the figures in these drawings are exemplary. Therefore, the drawings and detailed description should not be considered limiting, and other equally valid examples are possible. Furthermore, the same reference numerals (“reference signs”) in the drawings (“Figures”) denote the same elements.

[0006] Figure 1AThis is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments can be implemented.

[0007] Figure 1B The illustration shows a method according to one embodiment. Figure 1A The system diagram shown is of an example wireless transmit / receive unit (WTRU) used in the communication system.

[0008] Figure 1C The illustration shows a method according to one embodiment. Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used in the communication system shown.

[0009] Figure 1D The illustration shows a method according to one embodiment. Figure 1A The system diagram shows another example RAN and another example CN used in the communication system shown.

[0010] Figure 2 This is a diagram illustrating the stages of adaptive Quality of Service (QoS) configuration and operation according to an embodiment.

[0011] Figure 3 is a signal flow diagram illustrating an exemplary process of adaptive QoS configuration and operation according to an embodiment.

[0012] Figure 4 This is a flowchart illustrating the process of adaptive media streaming.

[0013] Figure 5 This is a flowchart illustrating another process of adaptive media streaming.

[0014] Figure 6 This is a flowchart illustrating another process of adaptive media streaming. Detailed Implementation

[0015] In the following detailed description, numerous specific details are set forth to provide a full understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, processes, components, and circuits have not been described in detail so as not to obscure the description below. Furthermore, embodiments and examples not specifically described herein may be practiced in place of or in combination with embodiments and other examples explicitly, implicitly, and / or inherently (collectively, the “Provided”) described, disclosed, or otherwise provided herein. Although various embodiments are described and / or claimed herein, in which apparatuses, systems, devices, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any portions thereof, it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc., and / or any element thereof is configured to perform any operation, process, algorithm, function, etc., and / or any portion thereof.

[0016] The methods, processes, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. (See also...) Figure 1A-1D An overview of various types of wireless devices and infrastructures is provided, in which various elements of the network can be utilized, performed, arranged and / or adapted to and / or configured for use with the methods, apparatuses and systems provided herein, according to the methods, apparatuses and systems provided herein.

[0017] Figure 1A This is a schematic diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messages, and broadcasts to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Spread Spectrum OFDM (ZT UWDTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

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

[0019] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), node B, eNode B, home node B, home eNode B, gNB, NR node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

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

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

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

[0024] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using a new radio (NR).

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

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

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

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

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

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

[0031] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, among other things, WTRU 102 may include, in particular, 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 supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

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

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

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

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

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

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

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

[0039] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, such as gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, and / or humidity sensors.

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

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

[0042] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c on air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

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

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

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

[0046] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0047] SGW 164 can connect to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks such as Internet 110, so as to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

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

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

[0050] In a representative embodiment, another network 112 may be a WLAN.

[0051] A WLAN in Infrastructure Basic Services 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 access or interface with a distributed system (DS) or another type of wired / wireless network that transmits traffic to and / or out of the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for an external BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be transmitted via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be transmitted between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to here as an "ad-hoc" communication mode.

[0052] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide bandwidth of 20 MHz) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

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

[0054] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

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

[0056] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA among all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, 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 Sense and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the available band remains idle and can be available.

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

[0058] Figure 1D This diagram illustrates a system diagram of RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

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

[0060] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a variable number of OFDM symbols and / or a continuously variable length of absolute time). gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In a standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In a standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

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

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

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

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

[0065] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. This N3 interface provides WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 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, and providing mobility anchoring.

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

[0067] Given Figure 1A-1D as well as Figure 1A-1DThe corresponding descriptions herein indicate that one or more of the following functions can be performed by one or more emulation devices (not shown): WTRU 102a-d, Base Station 114a-b, eNode-B160a-c, MME 162, SGW 164, PGW 166, gNB180a-c, AMF 182a-b, UPF 184a-b, SMF183a-b, DN185a-b, and / or any other device(s) described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

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

[0069] One or more simulation devices may perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used to test test scenarios in laboratory and / or non-deployment (e.g., testing) wired and / or wireless communication networks to implement the testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0070] XR service processing can be provided via wireless networks and PDU sets. Carrying media streams over wireless networks can be challenging, especially for applications with high throughput and / or low latency requirements, such as video conferencing and extended reality (XR). Wireless networks can implement techniques to improve network capacity and energy efficiency, as well as reduce the impact of packet loss on user experience. For example, wireless networks (such as 5G networks) can process packet groups based on their importance to the user experience. Some groups of data packets can hold application data units, which are processed together by the application (e.g., decoded) and / or referred to as PDU (Packet Data Unit) sets. For example, a PDU set can correspond to a PDU carrying a single complete Network Application Layer (NAL) unit.

[0071] To support high-throughput, low-latency media streaming, networks (e.g., RANs) can perform differentiated and / or integrated QoS processing for XR services. This can include prioritizing some PDU sets over others during congestion. Networks can leverage the fact that application data units may depend on other application data units to be processed and / or decoded by the application (e.g., P-frames depend on I-frames, and enhancement layers depend on the base layer). Networks can selectively drop data packets that depend on application data units that have been lost. Networks can limit (e.g., radio) wake-up times for sending and / or receiving data. For example, packet schedulers (e.g., in RAN nodes) and / or WTRUs can use information about the size and / or periodicity of the service, as well as application-specific latency budgets and / or expected jitter, to synchronize their transmission and / or listening times.

[0072] The RAN can perform differentiated / unified QoS processing for XR services based on differentiated and / or integrated processing information elements (IEs) associated with the flow and / or the PDU set within the flow. The differentiated / unified processing IE includes PDU set QoS parameters received via the control plane and PDU set information received via the user plane. For downlink services, the PDU set information can be sent to the RAN node by the UPF via the GTP-U header of user plane packets. For uplink services, the PDU set information can be provided by the WTRU application through the Service Data Adaptation Protocol (SDAP) interface.

[0073] The term PDU set IE can be used to refer to the IE described here as PDU set information and PDU set QoS parameters.

[0074] PDU set information may include a PDU set ID. This ID can be an identifier for the PDU set, uniquely identifying the PDU set within the stream for at least the duration corresponding to the PDU transmission time between the sender and receiver. This ID can be, for example, a numeric ID, a timestamp, etc.

[0075] PDU set information may include the start and / or end of the PDU set indication. These IEs can identify the first and / or last (one or more) PDUs in the PDU set.

[0076] PDU set information can include the PDU serial number within the PDU set. This IE can identify the PDUs within the PDU set, for example, with a numeric ID that starts at 0 for the first PDU and increments by 1 for each PDU in the set.

[0077] PDU set information may include the PDU set size. The IE may store the total number of PDUs, the cumulative length of all PDUs in the set, and / or the cumulative length of the payloads (e.g., transmission payloads) of all PDUs in the PDU set.

[0078] PDU set information can include PDU set importance. This IE can be a numerical value indicating the importance level of the PDU set within the service flow (e.g., from the highest priority value of 0 to the lowest priority value of 255). The RAN can use it for PDU set-level packet dropping in the event of congestion.

[0079] PDU set information may include a burst end indication. This IE may indicate that the PDU or PDU set is the last PDU or PDU set in the burst. This IE may also include an IE indicating (e.g., the amount of time preceding the next burst).

[0080] PDU set QoS parameters can be a set of parameters that configure the QoS processing of a flow.

[0081] The PDU set QoS parameter may include PDU set information and / or may include the PDU set error rate (PSER). This IE value may correspond to an error rate applicable to the PDU set (e.g., where PDU set loss corresponds to an event where at least one PDU in the set may not have been sent). This IE can be used to configure the (e.g., acceptable) error rate of the PDU set for a service flow or QoS flow in the RAN.

[0082] The PDU set QoS parameter can include the PDU set delay budget (PSDB). This IE value can correspond to the acceptable delay for transmitting the complete PDU set (e.g., from receiving the first PDU in the set to transmitting the last PDU in the set). This IE can be used to configure the delay budget for service flows or QoS flows in the RAN.

[0083] PDU set QoS parameters can include PDU set integrated processing information (PSIHI). This IE can indicate whether the application needs all PDUs in the set.

[0084] PDU set QoS parameters can include burst periodicity. This IE value can specify the duration of data bursts in the stream (e.g., the transmission duration of consecutive independent frames in a video stream, such as the transmission duration of a set of pictures).

[0085] Common related definitions may include: (1) a PS identifier, which may be an identifier that determines which PDU belongs to and the PS IE associated with that PDU set. For media over Real-Time Protocol (RTP), this operation may (e.g., typically) be performed by the UPF for downlink flows, and (2) PS QoS processing (e.g., PS processing or PSH), which may specify operations (e.g., in the RAN and / or possibly in the UPF) that may include providing differentiated processing based on the PS IE, such as dropping PDUs with lower PS importance during congestion.

[0086] Adaptive media streaming can be provided. The concept of a media presentation (e.g., generally referred to herein as a "presentation") can be used for media streaming. A media stream can be transmitted using one or more available resolutions and bitrates of content. For example, a version of media content associated with a resolution and bitrate (e.g., each version) can be referred to as a presentation. The media sender can stream different presentations and / or can dynamically switch between one presentation and another during a streaming session. Media streaming that follows this dynamic selection and switching between presentations can be specified as adaptive bitrate (ABR) streaming. Media content can be configured to switch between presentations at specific locations in the stream, thereby defining media segments that are time-aligned across presentations and / or can be decoded independently of earlier content.

[0087] Multiple media streaming protocols utilize switching between media presentations. HTTP streaming protocols such as Dynamic Adaptive Streaming over HTTP (DASH), LL-DASH, and HTTP Real-Time Streaming (HLS) allow clients to request specific presentations from the sender. Based on current link capacity, such as that determined by congestion control algorithms, the Media over QUIC (MOQ) protocol allows the sender to switch between a set of presentations agreed upon between the sender and receiver. Real-Time Transport Protocol (RTP) protocols (e.g., including variants such as RTP over QUIC (ROQ)) allow for flexible adaptation to different network conditions. RTP can work in conjunction with a Real-Time Control Protocol (RTCP), which can be used to monitor and / or control RTP sessions. Based on feedback regarding the QoS and performance of the RTP session (e.g., from the receiver), the RTP sender can adjust transmission parameters, such as transmission rate or quality settings.

[0088] (For example, an alternative QoS profile can be a combination of QoS parameters (e.g., Packet Delay Budget (PDB), Packet Error Rate (PER), and / or others) that the application service can accommodate. For Guaranteed Bit Rate (GBR) QoS flows, multiple (e.g., alternative) QoS profiles can be (e.g., optionally) provided to the RAN node. If the RAN cannot satisfy the primary QoS profile, the RAN can begin applying (e.g., alternative) QoS profiles, and / or notify the SMF with a reference to a (e.g., alternative) QoS profile that the RAN can satisfy.

[0089] Adaptive Bit Rate (ABR) can be used for streaming content over 5G networks. A given ABR service stream can transmit different portions of the media stream over time. The throughput requirements for this stream may evolve over time. The ABR service stream can use available bandwidth to provide the best Quality of Experience (QoE) for the user. The QoS used for this service can be multimedia-specific (e.g., 5QI "2" for live streaming, "3" for live gaming, etc.).

[0090] 5G networks may be enhanced to handle XR services, which require both high throughput and low latency. XR-related enhancements may limit energy and / or network resource usage while maintaining an acceptable QoE for end users. These enhancements may include supporting differentiated QoS processing based on PDU sets and / or leveraging service periodicity to reduce energy consumption.

[0091] XR-related enhancements may not include support for ABR. (For example, the same QoS profile may be applied to services in different demos.)

[0092] In the example, a PSDB sized for a low-quality presentation might be too short for a high-quality presentation, artificially increasing the reported PDU set error rate (PSER). Conversely, a PSDB sized for a high-quality presentation might be too large for a low-quality presentation, causing delays in PDU delivery and reducing the time the WTRU is placed in low-power mode.

[0093] In the example, burst periods (e.g., video frame times) can vary between different presentations, potentially leading to inefficiencies in the RAN, such as prematurely putting the WTRU out of low-power mode before a new burst begins.

[0094] In the example, billing might be based on a higher resolution demo, which could lead to overcharging users, especially in situations with poor network conditions and where low-resolution demos are mostly used. High-resolution demos may require certain network services (e.g., PDU sets and / or burst support), which may not be necessary for low-resolution demos.

[0095] Using existing mechanisms to switch the QoS profile to be applied may not be well-suited for this task. In an example, an existing mechanism might include a WTRU requesting a PDU session modification, which applies new QoS parameters to the QoS flow. This mechanism can be inefficient because the profile may change frequently (e.g., several times per second in some cases). This could result in the use of more network resources than necessary (e.g., overhead from control plane signaling involving the WTRU, SMF, PCF, UPF, and RAN).

[0096] This mechanism may not synchronize well with changes to the demo; for example, new QoS parameters may not be applied in time to be used with the initial PDU of the transmission demo (e.g., a new demo). This could result in transmission loss when switching between two demos.

[0097] Therefore, support for ABR services in XR may be required. This support should enable the RAN to effectively and / or accurately apply different QoS processing to different parts of the service flow, depending on which media presentation is being transmitted through that flow.

[0098] Support for ABR services can be implemented for XR in 5G networks. The network can know the QoS parameters of each presentation in the media stream. The network can identify which media presentation is currently being transmitted on the media stream. The network can apply the QoS parameters associated with the currently transmitted presentation. Billing can be fair and correspond to the QoS parameters actually applied to each part of the service.

[0099] Enabling 5G networks to provide applications with prompts (e.g., and / or equivalent, commands) about which demo should be selected can (e.g., globally) improve the efficiency of networks used for multiple concurrent ABR flows. This can be achieved by improving network efficiency, for example, by balancing network resource usage and stabilizing the ABR algorithm between multiple concurrent ABR sessions across different WTRU groups and application servers (AS).

[0100] Adaptive QoS configuration and operation can be provided. Networks such as 5G networks can be enhanced to support a feature, which can be referred to herein as adaptive QoS. Adaptive QoS can enable support for ABR and resolve one or more network issues. In the example, if a QoS stream supports adaptive QoS for downlink traffic, a QoS profile and / or one or more alternative QoS profiles can be provided to the RAN node (e.g., gNodeB), where all or some of the provided QoS profiles may include a presentation identifier (e.g., a new presentation identifier). If a QoS stream supports adaptive QoS for uplink traffic, QoS rules and / or one or more alternative QoS rules can be provided to the WTRU. Some (e.g., all) of the provided QoS rules may include a new presentation identifier. The presentation identifier (e.g., a new presentation identifier) ​​can be associated with a specific presentation of the content transmitted over the QoS stream, belonging to its QoS profile or QoS rule. The term "presentation" can refer to a representation of a media stream (the same content at different levels of detail) or alternative content (equivalent content, such as different views of the same scene). The term "presentation" can refer to a presentation of any application data stream, where the application data stream may be transmitted at discrete and / or pre-known different rates. For example, the term "demonstration" can refer to rate marking of an application data stream, where the rate marking is based on flow characteristics determined by the application. An example of application-determined flow characteristics is the urgency or criticality of the flow at that moment. In this example, the sending application might determine that it is handling a complex scenario at this moment, requiring a longer processing time than usual at the sender and / or receiver; therefore, the sending application marks the application stream with a demonstration ID corresponding to a "critical" rate mark. The 5G network (e.g., UPF) can identify demonstrations transmitted in PDUs in real time and / or can transmit the PDU and the identified demonstration ID to the RAN node. The 5G network can transmit the PDU and apply QoS processing using QoS parameters from the QoS profile associated with the identified demonstration ID. For uplink traffic, the WTRU can identify demonstrations transmitted in PDUs in real time and / or can transmit the PDU to the RAN node for QoS processing using QoS rules associated with the identified demonstration ID.

[0101] The adaptive QoS mechanisms described herein can be applied to XR services (e.g., some demonstrations use PDU-based QoS, while others do not), and also to other types of media services (e.g., haptic / media / video streaming) and other types of services. Furthermore, typically in a service data stream, media flows in one direction, while feedback (e.g., acknowledgments and measurements) flows in the other. If the media is transmitted downlink, adaptive QoS can be applied to DL services (e.g., in UPF and RAN). If the media is transmitted uplink, adaptive QoS can be applied to UL services (e.g., in WTRU).

[0102] Figure 2 The main stages for configuring and operating adaptive QoS are shown, and relevant new information elements are highlighted.

[0103] At point 1, the Application Provider (AP) (e.g., via the AF) can configure the 5G network for adaptive QoS. The AP can configure the 5G network using an Adaptive QoS Configuration IE (e.g., QoS parameters / profiles / rules / PDR packet detection rules), which includes a demo ID, an indication of UPF-based selection of QoS parameters, a method for demo detection of the UPF and / or WTRU, and an Adaptive QoS Feedback Configuration, which can be used by the Policy Control Function (PCF) to configure Policy and Charging Control (PCC) rules. Based on the rules configured in the PCF, the SMF can configure the RAN, UPF, and / or WTRU for adaptive QoS using a QoS profile including the demo ID, PDR, and / or QoS rules.

[0104] At two points, the 5G network (e.g., the UPF for downlink and the WTRU for uplink) can identify the presentation of the PDU being transmitted. The UPF sends the PDU to the RAN in a GTP-U message, which includes the PDU presentation ID in the GTP-U header.

[0105] At three locations, the RAN node (e.g., downlink) and / or WTRU (e.g., uplink) apply QoS processing suitable for the transmitted demonstration.

[0106] At four points, the UPF (and / or RAN node and / or WTRU) sends adaptive QoS feedback, such as usage information including the demo ID, adaptive QoS demo information, and / or adaptive QoS demo selection prompts. The SMF can use this feedback to communicate with the billing function.

[0107] SMF and / or UPF can provide AF / AS with usage information, demonstration information, and / or adaptive QoS tips, and influence applications (e.g., AF / AS can use this feedback for demonstration selection or access selection). In some embodiments proposed herein, the concept of alternative QoS profiles is extended to support multiple alternative QoS profiles, which the RAN can select based on demonstrations currently being transmitted in user plane services, rather than on QoS profiles that can be satisfied.

[0108] Networks (e.g., 5G networks) can be configured for adaptive QoS. Application providers can use demo IDs to identify demos transmitted over the network. In the examples, HTTP streaming protocols and MOQ protocols can use demo IDs to identify each available demo. In the examples, while the RTP protocol may not use fixed demos, it is possible, for example, to implement the methods described here, that application providers can use demo IDs to identify different sets of transmission rate and quality settings that the RTP sender can use. In any of these cases, in the control plane, the application provider can provide the network, such as to the NEF / PCF (Network Exposure Function / Policy Control Function), with a list of available demos and associated demo IDs and QoS configurations. In the user plane, the application provider can also provide the network, such as to the UPF, with a demo ID and / or transmission rate and quality settings corresponding to the demo currently being transmitted. The method of providing demo IDs to the network is described below. Demo IDs provided by the application provider to the 5G network can be derived from existing application-layer demo IDs. For example, a presentation (e.g., Dynamic Adaptive Streaming (DASH) in HTTP) can be referred to as a representation of the AP using different codecs and / or maximum spatial and / or temporal resolutions, which can be requested by the client using a Uniform Resource Identifier (URI). In this case, the AP can use a hash value from the URI as the presentation ID, or reference the index number of the Nth representation, or a number derived from the display resolution, such as 720, 1080, 1440, 2048, and 4096.

[0109] The AF can use APIs enhanced for adaptive QoS to configure 5G networks for adaptive QoS. In examples, NEF service APIs such as Nnef_AFsessionWithQoS_Create can be enhanced to include a set of demo IDs, which can be associated with (e.g., default or alternative) QoS references and / or QoS parameters. Nnef_AFsessionWithQoS_Create can be enhanced to include additional adaptive QoS configuration elements, such as indications for using adaptive QoS features for UL, DL, or both UL and DL. As a result of the AF using APIs enhanced for adaptive QoS, the NEF and / or PCF can configure PCC rules that enable QoS within the PCF.

[0110] Adaptive QoS Configuration IEs can be provided by the AF and / or configured in QoS-enabled policy rules in the 5G network (e.g., PCC rules enabling adaptive QoS in the PCF). During the establishment or modification of QoS flows, the Adaptive QoS Configuration IE can be provided by the SMF to the RAN, UPF, and / or WTRU. Adaptive QoS Configuration IEs may include one or more features, including but not limited to adaptive QoS profiles, adaptive QoS rules, and adaptive QoS PDRs.

[0111] Adaptive QoS Configuration IEs can include adaptive QoS profiles. These are collections of QoS profiles (e.g., one QoS profile and one or more alternative QoS profiles), where all or some QoS profiles include a demo ID (or are otherwise associated with a demo ID). The demo ID indicates which demo the associated QoS profile should be applied to. QoS profiles can also include general QoS profile IEs, including, for example, 5QI, allocation and maintenance priorities, PDU set QoS parameters (including PDU set delay budget (PSDB), PDU set error rate (PSER), PDU set integrated processing information (PSIHI), reflecting QoS attributes, guarantees, and maximum stream bit rate, etc.

[0112] The adaptive QoS configuration IE can include adaptive QoS rules. These are a collection of QoS rules and / or (optionally) QoS flow-level QoS parameters, where (e.g., all or some) QoS rules (and / or QoS flow-level QoS parameters) can include a demo ID (or otherwise associated with a demo ID). The demo ID can indicate which demo the associated QoS rule (and / or QoS flow-level QoS parameter) should apply to. QoS rules can also include general QoS rule IEs, including, for example, 5QI, packet filter set priority values, rule identifiers, etc. One of the QoS profiles can be the default QoS profile. This can be (e.g., explicitly) signaled in the adaptive QoS configuration IE. This can be (e.g., alternatively) determined implicitly. For example, the first QoS profile in the set can be the default QoS profile. The first (e.g., and / or unique) QoS profile without a demo ID can (e.g., alternatively) be the default QoS profile. The default QoS profile can be used if the PDU does not have a demo ID and / or if the RAN node may not meet the requirements of the QoS profile needed for the PDU based on the included demo ID.

[0113] Adaptive QoS configuration IEs can include adaptive QoS PDRs. These can be a collection of UL and / or DL ​​PDRs, where one or more PDRs can include a demo ID (or otherwise associated with a demo ID). The demo ID can indicate which demo the associated PDR should apply to. A PDR can also include typical PDR IEs, including, for example, rule IDs, priority, source interface, packet filters, application identifiers, 5QI, protocol descriptions, etc. A PDR can include a list of demo IDs in a flow identified by a PDR (e.g., a PDR associated with a Packet Forwarding Control Protocol (PFCP) session). This list can indicate to the UPF that only those demo IDs are valid for this flow. This list of demo IDs can correspond to demo IDs configured in the RAN and associated with a QoS profile.

[0114] Adaptive QoS indications (e.g., including UL and DL indications) can be used to indicate whether adaptive QoS is applied to the uplink, downlink, or both. For the downlink, the indication can indicate that the UPF is allowed to detect presentations sent by the PDU and / or, for example, signaling via the presentation ID, select the QoS profile that the RAN should apply to the PDU. For the uplink, the indication can indicate that the WTRU is allowed to detect presentations sent by the PDU and / or select the QoS rules that should be applied to the PDU for uplink transmissions.

[0115] A demonstration detection method (IE) (e.g., including UL and DL methods) can be used to indicate a method or protocol by which a node (e.g., WTRU or UPF) can determine the demonstration ID associated with a PDU. For example, it can store different values ​​corresponding to a specific RTP extension header, a specific Multiplexed Application Substratum (MASQUE) with QUIC encryption extension, a specific MOQ extension, a Programming Application Programming Interface (API), or any other protocol. The value of this IE can indicate from which protocol field the WTRU and / or UPF read the demonstration ID and which PDU(s) are associated with the demonstration ID.

[0116] The Adaptive QoS Feedback Configuration IE can be used to request 5GS nodes (e.g., RAN nodes, UPF, SMF, PCF, NEF) to provide adaptive QoS feedback to the AF / AS and / or charging system. This IE can include a description of the allowed types of feedback messages, as well as constraints on the feedback (e.g., maximum / minimum message rate). The Adaptive QoS Feedback Configuration IE can include parameters such as the importance of a QoS flow relative to other flows, which can help the RAN / UPF determine which flows should be increased / decreased / maintained.

[0117] In the example (e.g., an alternative), the QoS profile and / or QoS rules may include multiple demo IDs and multiple QoS parameters. The RAN node / WTRU may first match the QoS profile / rules (e.g., the protocol used and the source and destination IP addresses and ports of the PDU). The RAN node / WTRU can then find a matching demo ID among the available demo IDs. The RAN node / WTRU can then select the QoS parameters associated with the matching demo ID. (E.g., slightly different) data structures may be used. The same principle as associating a demo ID with a set of QoS parameters corresponding to a specific QoS treatment can be used.

[0118] The WTRU can send a PDU session establishment or modification request message to the SMF, which includes an adaptive QoS indication to indicate that the WTRU supports adaptive QoS indications (e.g., for UL, DL, or both) and / or requests the use of adaptive QoS indications if the network allows. In the example, the adaptive QoS indication may be implicit and / or not included in the message (e.g., because the WTRU is known to support adaptive QoS features and / or because the WTRU application is known to benefit from adaptive QoS).

[0119] Upon receiving a PDU session establishment or modification request message (e.g., explicitly or implicitly) that includes an adaptive QoS indication, the SMF can configure the RAN, UPF, and / or WTRU for adaptive QoS. Once this message is received, the SMF can, for example, obtain the PCC rules corresponding to the requested QoS flow / PDU session from the PCF. For example, the SMF can determine whether adaptive QoS is supported for UL, DL, or both UL and DL based on the adaptive QoS indication in the PCC (e.g., an indication from the PCC) and / or based on the PDU session establishment / modification message (e.g., an indication from the WTRU). For example, for each direction (UL / DL), if both indications from the PCC and WTRU indicate the use of adaptive QoS for that direction, the SMF can determine to use adaptive QoS. If there is no indication from the WTRU (e.g., if it is implicit), the SMF can determine to use adaptive QoS for each direction based on the indication from the PCC. If the SMF determines that adaptive QoS will be used for the DL, the SMF may send one or more of the following to the RAN: an adaptive QoS indication, an adaptive QoS profile from a PCC rule (e.g., in a PDU session establishment / modification response), and / or an adaptive QoS feedback configuration. The SMF may send one or more of the following to the UPF (e.g., in an N4 rule): an adaptive QoS indication, a demonstration detection method (IE), an adaptive QoS PDR from a PCC rule, and an adaptive QoS feedback configuration. If the SMF determines that adaptive QoS will be used for the UL, the SMF may send one or more of the following to the WTRU (e.g., in a PDU session establishment / modification response): an adaptive QoS indication; a demonstration detection method (IE); an adaptive QoS rule from a PCC rule; and an adaptive QoS feedback configuration. If the SMF determines that adaptive QoS will not be used on the DL and / or UL, it may send a QoS profile, a PDR, and / or QoS rules without a demonstration ID (without a demonstration ID, some QoS profiles / PDRs / rules may become useless or redundant and may not be sent).

[0120] Based on the N4 rules from the SMF, the UPF can determine to use adaptive QoS for QoS flows. If adaptive QoS is indicated, the UPF can configure its demonstration detection algorithm based on the demonstration detection method (IE). The UPF can further apply PDRs, some of which include the demonstration ID.

[0121] Based on messages from the SMF, the RAN node can determine whether to use adaptive QoS for a QoS flow. If adaptive QoS is indicated, the RAN node can apply QoS profiles, some of which include a demo ID. The RAN node can configure itself to detect the demo ID based on the GTP-U header and look up the applicable QoS profile based on the demo ID. In the example, the RAN node may not meet the requirements of one or more adaptive QoS profiles included in the adaptive QoS configuration IE. For example, the RAN node may not meet the Guaranteed Stream Bit Rate (GFBR) requirement for one of the profiles. If a QoS flow is being established, such as through a PDU session or PDU session modification, the SMF can send an adaptive QoS configuration IE to the RAN node. The RAN node can determine that it may not meet one or more parameters or requirements in the provided profiles. The RAN node can accept the QoS flow, but it can send an indication to the SMF that it may not meet one or more profiles. If any adaptive QoS profile is not met, the RAN node can reject the establishment or modification of the QoS flow. Some applications may require some minimum level of adaptability (e.g., alternatively). In the example, the decision to reject and / or accept a QoS flow may be based on this minimum requirement. For example, if the network can serve at least three adaptive QoS profiles, then the RAN node can (e.g., only) accept QoS flows.

[0122] Based on messages from the SMF, the WTRU can determine whether to use adaptive QoS for QoS flows. If adaptive QoS is indicated, the WTRU can apply QoS rules, some of which may include the demo ID. The WTRU can configure its demo detection algorithm based on the demo detection method (IE). The WTRU can also configure itself to look up applicable QoS rules based on the demo ID.

[0123] Demos can be identified for adaptive QoS. For example, if using the DASH protocol, the decision to transmit a given demo can be made by the media receiver (e.g., a WTRU application). In this case, the media receiver requests a specific demo for a portion of the stream (e.g., a segment of the media stream) from the media sender. Alternatively, if using the MOQ protocol, the decision to transmit a given demo can be made by the media sender (e.g., an AS). In this case, the media receiver and sender can agree on the set of demos to use (e.g., during session establishment or using out-of-band means), and the media sender can switch from one demo to another at specific points in the stream(s), for example, based on the media sender's assessment of available bandwidth, which can be provided by the congestion control algorithm portion of the media transport protocol (e.g., MOQ).

[0124] A PDU presentation ID can indicate a presentation associated with a PDU (e.g., in the case where the PDU presentation ID is transmitted in the PDU header for each media PDU associated with a presentation), or a presentation associated with multiple PDUs (e.g., in the case where the PDU presentation ID is transmitted in a control message and / or can be applied to a set of PDUs identified in the control message, for example, using a sequence number or timestamp present in the PDU header). For example, a PDU presentation ID can be associated with one or more PDUs.

[0125] A PDU presentation ID can be associated with one or more PDUs. For example, a new PDU presentation ID in the header of a GTP packet can indicate a presentation associated with a PDU transmitted in the GTP packet (e.g., a media packet transmitted in the PDU). This can be used in GTP packets from UPF to RAN, from RAN to UPF, and / or from AS to UPF.

[0126] A PDU presentation ID can be associated with one or more PDUs. For example, a new PDU presentation ID in the RTP extension header (e.g., in the PDU set RTP extension header) can indicate a presentation associated with a PDU (e.g., a media packet transmitted in an RTP packet).

[0127] A PDU presentation ID can be associated with one or more PDUs. For example, using a new PDU presentation ID in the MASQUE or MOQ stream header (e.g., alternatively) can indicate a presentation associated with all data transmitted in this MOQ or QUIC stream or PDU set.

[0128] A PDU presentation ID can be associated with one or more PDUs. For example, a new PDU presentation ID in a MASQUE or MOQ message can indicate a presentation associated with all data transmitted in a set of PDUs identified in the message or in an MOQ or QUIC stream (e.g., utilizing an MOQ or QUIC stream ID).

[0129] A PDU presentation ID can be associated with one or more PDUs. For example, a new PDU presentation ID in an RTP (ROQ) datagram message using MASQUE, MOQ, or QUIC can indicate a presentation associated with a PDU (e.g., a media packet transmitted in an HTTP datagram) or a set of PDUs (e.g., a group of media packets transmitted in multiple HTTP datagrams associated with the same set of PDUs).

[0130] A PDU presentation ID can be associated with one or more PDUs. For example, using a new PDU presentation ID in the UDP or IP option (e.g., alternatively) can indicate a presentation associated with a PDU (e.g., a media packet transmitted in a UDP or IP payload).

[0131] A PDU presentation ID can be associated with one or more PDUs. For example, a message that includes the presentation ID and a reference to the PDU, PDU group, or PDU set can indicate a presentation transmitted by that PDU / PDU group / PDU set.

[0132] A PDU demo ID can be associated with one or more PDUs. For example, a new message including the demo ID from the AS / AF via the control plane (e.g., using the PCF or NEF API) can indicate the demo associated with the PDU, where the demo ID is further sent from the Network Exposure Function (NEF) to the PCF, from the PCF to the SMF, and from the SMF to the UPF. From the AS / AF's perspective, the demo ID can be provided to the 5GS via a service enablement layer (e.g., an edge or XR enablement layer). In one example, the AS can set the demo ID via an edge enablement server, which can then transmit the demo ID to the NEF.

[0133] The PDU presentation ID can correspond to (e.g., be equal to or can be mapped to) the QoS flow presentation ID configured for that QoS flow. For example, the QoS flow presentation ID can be included in the PCC rule within the adaptive QoS configuration IE defined above. In the example, the PDU presentation ID can (e.g., implicitly) be associated with the PDU (e.g., if the PDU presentation ID exists in the PDU's header). In the example, the PDU presentation ID may not (e.g., implicitly) be associated with the PDU. In this case, the message including the PDU presentation ID can include identifiers of the target PDU(s), which can be, for example, a QUIC or MOQ flow ID, multiple timestamps, or multiple sequence numbers indicating the last and / or first PDU associated with the PDU presentation ID.

[0134] For DL ​​services, the UPF can use any of the following methods to identify the presentation of the transmission: the UPF can read the PDU presentation ID from the header of the PDU; the UPF can receive the PDU presentation ID in the message identifying the PDU; or the UPF can detect the presentation associated with the PDU, for example, using an estimation heuristic or using an AI-based algorithm (e.g., with the support of NWDAF), for example, using PDU timing and size information as input.

[0135] UPF can determine which presentation detection method to use based on the presentation detection method IE indicated by SMF in the N4 rule message.

[0136] For UL services, the WTRU can use any of the following methods to identify the transmission demonstration: the WTRU can read the PDU demonstration ID from the header of the PDU; the WTRU can receive the PDU demonstration ID in the message identifying the PDU; or the WTRU application can provide the PDU demonstration ID associated with the PDU in a programming API function call (e.g., passing the PDU and the PDU demonstration ID as parameters).

[0137] WTRU can determine which demonstration detection method to use based on the demonstration detection method IE indicated by SMF in the PDU session establishment / modification message.

[0138] For DL ​​services, the UPF can send a PDU to the RAN by including the PDU demonstration ID in the header of the GTP-U packet that includes the PDU, where the value of the PDU demonstration ID provided in the GTP-U header corresponds to the demonstration detected by the UPF.

[0139] If the presentation changes during streaming, the UPF can send a presentation change notification to the SMF, indicating the new PDU presentation ID. This can be useful in typical media delivery scenarios where the transmitted presentation may change relatively infrequently (e.g., every few seconds or minutes). Upon receiving this indication, the SMF can send a presentation update indication (including the new PDU presentation ID) to the AF via the PCF and / or NEF. This indication allows the application provider to control the quality assurance of its service. In the example, based on this type of indication, the application provider could decide to switch the streaming delivery for some of its users to another radio access technology.

[0140] Adaptive QoS can be applied. When a DL PDU is received, the RAN node (e.g., gNodeB) can read, for example, the PDU demo ID associated with the PDU in the GTP-U header. If a PDU demo ID is found, the RAN node can use the PDU demo ID and / or other common IEs (such as the protocol and the source and destination IP addresses and ports of the PDU) as input to search for matching service filters and demo IDs. If a matching service filter and demo ID are found, the RAN node can select QoS parameters associated with the matching service filter and demo ID, and / or can perform PDU transmission while applying the QoS processing indicated by those QoS parameters. If no matching service filter and / or demo ID is found, the RAN node can search for matching service filters without a demo ID to obtain a default set of QoS parameters. The RAN node can perform transmission while applying the QoS processing indicated by those QoS parameters.

[0141] In the example, the RAN may be allowed to override QoS profile allocation decisions based on the presentation ID sent by the UPF. There may be situations where the RAN node decides not to use the QoS profile suggested by the UPF via the presentation ID. For example, the presentation ID might indicate that additional resources must be added for the PDU, but the RAN might decide not to add resources and / or allocate a smaller amount of network resources. In the example, the RAN node can notify the SMF, UPF, or AS / AF (e.g., via the SMF) of this change.

[0142] Upon receiving a UL PDU, the WTRU can obtain the PDU presentation ID associated with that PDU, for example, using the method described here based on the presentation detection method IE. The WTRU can use the PDU presentation ID and / or other common IEs (e.g., protocol and / or the PDU's source and destination IP addresses and ports) as input to search for matching QoS rules with matching presentation IDs. If a matching QoS rule with a presentation ID is found, the WTRU can select that matching QoS rule, and / or the WTRU can perform a PDU transfer while simultaneously applying the QoS processing indicated by that QoS rule. If no matching QoS rule with a presentation ID is found, the WTRU can search for matching QoS rules without a matching presentation ID to obtain a default QoS rule. The WTRU can then perform a transfer while simultaneously applying the QoS processing indicated by that QoS rule.

[0143] Adaptive QoS feedback can be provided. Feedback from the RAN / UPF can be usage information. To enable billing based on accurate QoS usage, the SMF can send an Enhanced Usage Reporting Rule (URR) to the UPF, where the enhanced URR (e.g., associated with a PDR including the demo ID IE) includes an indication to use adaptive QoS reporting (e.g., a new indication). Based on this indication, the UPF can provide the SMF with a usage report, including network resource usage information associated with the demo ID and one or more of the following (e.g., the amount of PDU size transmitted): QoS Flow ID, 5QI, WTRU ID (e.g., Subscription Permanent Identifier (SUPI), Subscriber Hidden Identifier (SUCI), General Public Subscription Identifier (GPSI)), and WTRU IP address. The SMF can then send a message via the PCF / NEF to the billing system and / or AF / AS based on this information (e.g., aggregating the amount of transmitted PDU size for a given set of QoS parameters using the PDU demo ID and adaptive QoS configuration). This allows the 5GS to bill customers based on the actual QoS applied to the transmitted demo.

[0144] In the example (e.g., an alternative system), if the demo ID IE exists in the PDR associated with the URR, the indication to use adaptive QoS reporting in the URR can be implicit. In the example (e.g., alternatively), the WTRU and / or RAN nodes can send usage reports (e.g., to the SMF, PCF, or billing system) including network resource usage information and the demo ID to achieve accurate billing when using adaptive QoS.

[0145] Feedback from the RAN / UPF can be a demonstration selection prompt or indication. The UPF, WTRU, and / or RAN nodes can determine to send adaptive QoS feedback, for example, based on an adaptive QoS feedback configuration IE from the SMF (e.g., in an N4 message or PDU session establishment / modification response). The adaptive QoS feedback configuration IE can instruct the sending of one or more types of feedback messages, such as reports, prompts, or informational messages.

[0146] If one or more triggers are activated, the UPF, WTRU, and / or RAN can determine to send an adaptive QoS feedback prompt message to the SMF.

[0147] In one embodiment, if network congestion is detected or predicted, an adaptive QoS feedback prompt message can be sent. The UPF / WTRU / RAN can identify some adaptive QoS flows (e.g., those with lower priority and / or those transmitting demonstrations with high bandwidth usage) that can be scaled down (e.g., transmitted at a lower resolution, or more generally, transmitted as another demonstration requiring less data transmission). In this example scenario, the UPF / WTRU / RAN can send a scaled-down prompt.

[0148] In one embodiment, if low network usage is detected, an adaptive QoS feedback alert message can be sent. The UPF / WTRU / RAN can identify some adaptive QoS flows (e.g., higher priority, and / or delivery of demos with low bandwidth usage) that can be scaled up. In this example, the UPF / WTRU / RAN can send a scaled-up alert.

[0149] In one embodiment, if frequent PDU demo ID changes are detected, an adaptive QoS feedback message can be sent. The UPF / WTRU / RAN can decide to increase system stability by sending a prompt to maintain a stable demo ID and instructing the AF / AS to maintain the same demo ID for a certain period of time or duration.

[0150] In one embodiment, UPF / WTRU / RAN may further rely on heuristic or AI / ML algorithms to determine whether to send an adaptive QoS cue feedback message, and the nature (type and content) of the feedback message.

[0151] If a changed PDU demo ID is detected (e.g., if the value of a PDU demo ID that normally remains stable over time changes from one demo ID to another), the UPF, WTRU, and / or RAN can determine to send an adaptive QoS feedback message to the SMF.

[0152] SMF can be configured (e.g., by PCF) to use the new "Policy Control Request Trigger".

[0153] For example, if the SMF receives a notification (e.g., from the UPF or RAN) that the demonstration ID associated with a flow's PDU has been changed, it can trigger a demonstration ID change indication. If this trigger is activated, the SMF can send the new demonstration ID to the PCF. The PCF (e.g., via the NEF) can then send the new demonstration ID, along with other existing IEs such as packet delay changes, data rates, and round-trip delay measurements, to the AF in a QoS monitoring and control message. The AF / AS can use this information to manage delivery quality and cost (e.g., to take actions such as selecting new access technologies for new or some current clients / WTRUs).

[0154] In another example, if the SMF receives a notification (e.g., from the UPF or RAN) that includes a presentation selection prompt (e.g., up, down, stable, or a specific presentation ID), it can trigger the presentation selection prompt. If the trigger is activated, the SMF can send a presentation selection prompt (e.g., a new presentation ID or an indication to increase / decrease / maintain a presentation) to the PCF. The PCF (e.g., via the NEF) can send the presentation prompt to the AF in a QoS monitoring and control message or another type of message.

[0155] If a demo selection prompt or instruction message is received, the media receiver or sender may set (e.g., by the sender) or request (e.g., by the receiver) a demo change based on the message, and / or may refrain from making or requesting a demo change for a duration specified in the message. This behavior enables adaptive media streaming sessions to share the network with other services (including other adaptive media streaming sessions) in a fair and stable manner.

[0156] In one (e.g., alternative) embodiment, the WTRU can send a presentation selection prompt or indication message to the WTRU application via the user plane (e.g., using a programming API), which the WTRU application can use to control the sending or requesting of a presentation. In another example (e.g., alternatively), the UPF can send a presentation selection prompt or indication message to the AS via the user plane (e.g., using a MASQUE message, UDP or IP options, or another user plane message), which the AS can use to control the sending or requesting of a presentation.

[0157] It can provide adaptive QoS configuration and operation. Figure 3A and Figure 3B This is a signal flow diagram illustrating an exemplary process of adaptive QoS configuration and operation according to one embodiment. Different stages (AEs) typically occur in this order, but not necessarily sequentially, and not all stages will necessarily occur within a single media session (e.g., C occurs if there is DL media, and D occurs if there is UL media). Each stage may have its own trigger.

[0158] Phase (A) illustrates the adaptive QoS configuration of the AP. This phase is triggered if the AP decides to configure adaptive QoS for, for example, media sessions.

[0159] In A.1, AF 116 can send API messages to NEF 114 to set QoS for a service flow (e.g., Nnef_AFsessionWithQoS_Create). API messages can include adaptive QoS configuration IEs.

[0160] In A.2, NEF 114 can send a request to PCF 112 to set QoS for service flows, including adaptive QoS configuration IE.

[0161] In A.3, PCF 112 can save the adaptive QoS configuration IE in the PCC rule.

[0162] Phase (B) illustrates the establishment of a QoS flow using adaptive QoS. This phase is triggered if a WTRU application initiates a connection to AS 116.

[0163] In B.1, the WTRU application can initiate a connection to the media server (AS), which can trigger the WTRU 102 to send a PDU session establishment or modification request to the SMF108 (via the AMF 106), which may include an adaptive QoS indication that can instruct the WTRU 102 to support and / or request the use of adaptive QoS.

[0164] In B.2, SMF 108 can obtain PCC rules that include an adaptive QoS configuration IE, which may include a demo ID (e.g., during policy association).

[0165] In B.3, the SMF can send an N4 session modification request to the UPF (e.g., including an adaptive QoS configuration IE containing a demo ID).

[0166] In B.4, based on the adaptive QoS configuration IEs (e.g., adaptive QoS PDR, adaptive QoS indication, demonstration detection method, adaptive QoS feedback configuration) in the N4 message, the UPF 110 can configure itself for adaptive QoS, including demonstration detection and adaptive QoS feedback. In B.5, the UPF 110 can send a response to the SMF 108.

[0167] In B.6, SMF 108 can send a PDU session establishment or modification response to WTRU 102 via AMF 106 and RAN 104, which may include an adaptive QoS configuration IE, which may include a demo ID.

[0168] In B.7, based on a portion of the adaptive QoS configuration IE (e.g., adaptive QoS profile, adaptive QoS indication, adaptive QoS feedback configuration), RAN 104 can configure itself for adaptive QoS, including demonstration-based QoS parameter selection and adaptive QoS feedback.

[0169] Phase (C) illustrates adaptive QoS operation on downlink services. This phase is triggered if the AS acting as the media sender can send a media PDU to WTRU 102.

[0170] In C.1, AS 116 may send a media PDU including a PDU presentation ID, or a media PDU otherwise associated with a PDU presentation ID, to WTRU 102 via UPF 110 (e.g., via another message including the PDU presentation ID and an ID corresponding to the PDU or a group of PDUs including the PDU).

[0171] In C.2, UPF 110 detects the demo ID associated with the PDU, for example, by retrieving the demo ID from the PDU header or other methods described herein.

[0172] In C.3, UPF 110 can send a GTP-U message to RAN node 104 that includes the PDU and PDU demonstration ID (e.g., in the GTP-U message header).

[0173] In C.4, RAN node 104 can select applicable QoS parameters based on the PDU presentation ID from the GTP-U header. In C.5, the RAN node can use the selected QoS parameters to send PDUs to WTRU 102. Although in Figure 3B The example is not shown, but as discussed herein, if the RAN 104 node decides that it may not apply the selected QoS parameters, the RAN node may apply QoS parameters corresponding to (e.g., lower resolution) the presentation (e.g., less stringent), and / or the RAN node may send a notification message to the SMF 108 (not shown) to indicate this decision. The SMF may further notify the PCF (not shown), which in turn may notify the AF / AS. As a result, the AS may modify the presentation it sends to the WTRU to accommodate the network services that are effectively provided. Figure 3B (Not shown in the image).

[0174] Phase (D) illustrates adaptive QoS operation on uplink services. This phase may be triggered if the WTRU acting as the media sender sends a media PDU to the AS.

[0175] In step D.1, the WTRU application can determine to send a PDU to the AS. The WTRU can detect the PDU demonstration ID, can select QoS rules based on the detected PDU demonstration ID, and / or can use the selected QoS rules to send the PDU to RAN 104 (step D.2). In step D.2, the demonstration ID can be sent along with the PDU (e.g., using a Layer 2 header field). In an example (e.g., alternatively), the demonstration ID may not be sent in step D.2, and / or the RAN can detect the demonstration ID, for example, based on the QoS parameters used by the WTRU to send the PDU.

[0176] Upon receiving or detecting a demonstration ID, in step D.3, RAN node 104 can send a PDU to UPF 110 in a GTP-U message that includes the PDU demonstration ID. In step D.4, UPF 110 can record the demonstration ID associated with the PDU (e.g., to make it available for future usage reports) and can use the demonstration ID to send feedback messages. In step D.5, UPF 110 can forward the PDU to AS 116.

[0177] Phase (E) illustrates adaptive QoS feedback. In this example, the UPF sends a feedback message. This phase begins based on a trigger within the UPF. In other examples ( Figure 3B (not shown in the image), the RAN or WTRU can send feedback messages based on triggers in the RAN or WTRU, respectively.

[0178] In E.1, the UPF 110 can determine whether it should send a feedback message (e.g., periodic usage reports, presentation information based on changes in the presentation ID, or presentation tips based on an algorithm or heuristic using the presentation ID). In E.2, the UPF 110 can send feedback messages to the SMF 108 via N4.

[0179] In E.3, SMF 108 can use feedback messages. For example, if the feedback is a usage report, the SMF can associate usage information with QoS parameters corresponding to the demo ID, and / or can forward the usage information or aggregated usage information to the billing system. For example, if the feedback is demo information or a demo selection prompt message, the SMF forwards the feedback message to the PCF based on a policy control request configured by the PCF. The PCF can forward the feedback message to the AF (e.g., via NEF) based on the AF's event registration, and the AF can use the feedback information described herein.

[0180] UPF assistance can be provided with adaptive media stream QoS. Figure 4 This is a flowchart illustrating a first exemplary process of adaptive media streaming based on at least some of the principles described above. At 401, the UPF can receive a message from the SMF associated with the stream, instructing the UPF to detect which QoS profile should be applied to the PDUs, PDU sets, or PDU groups of the stream. This message may contain N4 rules associated with the stream. The detection of which QoS profile to apply can take several forms, including detecting such an indication in the header of the associated PDU(s), receiving it in a separate message, or calculating it using an algorithm based on available service or PDU information.

[0181] In 403, the UPF can, for example, receive at least one PDU of the stream from the AF.

[0182] In 405, UPF can detect the presentation ID associated with the flow (e.g., in the PDU header, in a separate message, or using an algorithm), which indicates QoS selection.

[0183] In section 407, the UPF can send a message (e.g., a GTP-U message) to the RAN that includes a demo ID and a QoS flow ID. The QoS flow ID identifies the QoS profile to be applied to the PDU included in the (e.g., GTP-U) message. This allows the RAN to apply a QoS profile suitable for the detected demo, which can improve the QoE of end users while improving the network operator's network resource utilization efficiency.

[0184] In some embodiments, the UPF may provide feedback to the SMF indicating that a demo version of the flow may be more suitable than the current demo version. This is illustrated at 409. This indication may include, for example, information about the level of traffic / congestion in the network.

[0185] Figure 5 This is a flowchart illustrating a second exemplary process for adaptive media streaming based on at least some of the principles described above.

[0186] In 501, RAN nodes can receive (e.g., from the SMF of the core network) a set of QoS profiles of QoS flows identified by QoS flow IDs, as well as associated presentation IDs of at least some QoS profiles and indications that allow the core network (e.g., UPF) to change the QoS of the flow.

[0187] In 503, the RAN node can receive (e.g., from the UPF) packets that include a PDU and a header, which includes the PDU demo ID (which is associated with the QoS profile) and the QoS flow ID.

[0188] In 505, RAN nodes can use the PDU presentation ID and (for example, possibly) other PDU characteristics (e.g., source / destination IP address and port, protocol) to determine the QoS profile associated with the presentation ID.

[0189] In step 507, the RAN node applies the selected QoS profile to the QoS flow to send the PDU to the destination WTRU.

[0190] In some embodiments, the RAN node may provide feedback to the core network (e.g., SMF), such as an indication that a demo version might be more suitable for the flow than the current demo version. This is illustrated at 509. This indication may include, for example, a report message describing the resource usage associated with each demo ID. This enables billing of adaptive media transports based on the actual QoS parameters used to send the PDUs.

[0191] This feedback may (for example, alternatively) include a demo selection prompt, which indicates the expected behavior from the application (used by the core network to select a new demo).

[0192] The feedback may (for example, alternatively) include a demo information message indicating a detected change in the demo ID.

[0193] It can provide SMF assistance for QoS of adaptive media. Figure 6 This is a flowchart illustrating a third exemplary process of adaptive media streaming based on at least some of the principles described above.

[0194] At 601, the SMF may receive PDU session establishment or modification messages. These messages may include, for example, indications of using adaptive QoS for the PDU session and / or the requested flow. The SMF may obtain relevant PCC rules (e.g., from the PCF), including some of the following: (a) an indication allowing the UPF to change which QoS profile to apply; (b) one or more alternative QoS profiles associated with a demo ID; (c) a protocol ID indicating the method by which the UPF detects demos transmitted in the DL PDU; and (d) a protocol ID indicating the method by which the WTRU detects demos transmitted in the UL PDU. At 605, the SMF may receive (e.g., from the UPF, the RAN, or the WTRU) notifications that include a demo ID (e.g., a per-demo usage report and / or demo information message) or a demo selection prompt as described above.

[0195] In section 607, in response to the first notification, the SMF may send a second instruction to the Policy Control Function (PCF). For example, if the received instruction includes a network resource usage report corresponding to the demo ID, the SMF may send a notification to the billing system that includes service usage information corresponding to the QoS parameters identified by the demo ID.

[0196] If the received instruction includes a demo ID or a demo selection prompt (e.g., a prompt to increase or decrease the demo resolution / size, a prompt to use a specific demo, a prompt to keep the current demo for a given time), the SMF may send a notification to the WTRU and / or PCF / NEF (and may send a notification to the AF), including the demo ID and / or demo selection prompt. Applications (e.g., AS or WTRU applications) may further use the demo ID or prompt to select or request, or avoid selecting or requesting, a demo.

[0197] Although features and elements have been provided above in specific combinations, those skilled in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. This disclosure is not limited to the specific embodiments described herein, which are intended to illustrate various aspects. Many modifications and variations can be made without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. No element, action, or instruction used in the description of this application should be construed as critical or essential to the invention unless expressly provided so. Based on the foregoing description, functionally equivalent methods and apparatuses within the scope of this disclosure, in addition to those methods and apparatuses listed herein, will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terms of the appended claims together with the full scope of the equivalents granted by such claims. It will be understood that this disclosure is not limited to specific methods or systems.

[0198] For simplicity, the foregoing embodiments are discussed in terms of the terminology and structure of devices with infrared capabilities (e.g., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0199] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or multiple images displayed on a time-based basis. As another example, if mentioned herein, the term "user equipment" and its abbreviation "WTRU" (e.g., "UE"), the term "remote," and / or the term "head-mounted display" and its abbreviation "HMD" may mean or include (i) a wireless transmitting and / or receiving unit (WTRU); (ii) any of the various embodiments of a WTRU; (iii) a device with wireless and / or wired capabilities (e.g., tetherable), particularly configured with some or all of the constructs and functionalities of a WTRU; (iii) a device with wireless and / or wired capabilities configured with fewer than all the constructs and functionalities of a WTRU; or (iv) something like that. Figure 1A-1D Details of an example WTRU, which may represent any WTRU described herein, are provided. As another example, the various embodiments disclosed above and below are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be utilized, and some or all of this disclosure and the various disclosed embodiments can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adaptive, realistic experience.

[0200] The methods provided herein can 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 via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROMs and digital multifunction discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, MME, EPC, AMF, or any host.

[0201] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the wide variety of applicable embodiments, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the appended claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source, such as a battery, that provides any suitable voltage.

[0202] Furthermore, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices including processors are indicated. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to actions and symbolic representations of operations or instructions can be executed by various CPUs and memories. Such actions and operations or instructions may be referred to as “executed,” “computer-executed,” or “CPU-executed.”

[0203] Those skilled in the art will appreciate that the actions and symbolic representations of operations or instructions include the CPU's manipulation of electrical signals. Electrical systems represent data bits that can lead to the eventual conversion or reduction of electrical signals and are maintained at memory locations in a memory system, thereby reconfiguring or otherwise altering the operation of the CPU and other signal processing. The memory location maintaining the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs mentioned above, and other platforms and CPUs may support the provided methods.

[0204] Data bits can also be maintained on computer-readable media, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems. Computer-readable media can include cooperative or interconnected computer-readable media that reside exclusively on a processing system or are distributed across multiple interconnected processing systems, which can be located locally or remotely. It should be understood that the embodiments are not limited to the memories mentioned above, and other platforms and memories can support the provided methods.

[0205] In the illustrative embodiments, any operations, processes, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0206] There is little difference between the hardware and software implementations of various aspects of the system. The use of hardware or software is often (but not always; in some contexts, the choice between hardware and software may become important) a design choice representing a cost-efficiency trade-off. Various means can be available to implement the processes and / or systems and / or other technologies (e.g., hardware, software, and / or firmware) described herein, and the preferred means can vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are paramount, the implementer may choose a primarily hardware and / or firmware-based approach. If flexibility is paramount, the implementer may choose a primarily software-based approach. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0207] The foregoing detailed description has illustrated various embodiments of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. As such block diagrams, flowcharts, and / or examples encompass one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or virtually any combination thereof. In one embodiment, several portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be implemented, in whole or in part, equivalently in an integrated circuit, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or virtually any combination thereof, and that designing the circuit system and / or writing code for the software and / or firmware according to this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed as a variety of program products, and that the illustrative embodiments of the subject matter described herein are applicable regardless of the specific type of signal-bearing medium used for actual distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media, such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc., and transmission media, such as digital and / or analog communication media (e.g., optical fibers, waveguides, wired communication links, wireless communication links, etc.).

[0208] Those skilled in the art will recognize that it is common practice in the art to describe devices and / or processes in the manner set forth herein, and then to integrate such described devices and / or processes into data processing systems using engineering practice. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system typically includes one or more system unit housings, video display devices, memories such as volatile and non-volatile memories, processors such as microprocessors and digital signal processors, computing entities such as operating systems, drivers, graphical user interfaces, and applications, one or more interactive devices such as touchpads or screens, and / or control systems including feedback loops and control motors (e.g., feedback for listening to position and / or speed, control motors for moving and / or adjusting components and / or quantities). Typical data processing systems can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0209] The topics described herein sometimes illustrate different components included within or connected to different other components. It will be understood that the architectures depicted are merely examples, and many other architectures can indeed be implemented to achieve the same functionality. Conceptually, any arrangement of components that achieve the same functionality is effectively “associated” to achieve the desired functionality. Therefore, any two components combined in this document to achieve a particular functionality can be considered “associated” with each other to achieve the desired functionality, regardless of the architecture or intermediate components. Similarly, any two components so associating can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be so associating can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of operational coupling include, but are not limited to, physically matable and / or physically interactive components and / or wirelessly interactive and / or logically interactive components.

[0210] Regarding the use of virtually any plural and / or singular terms in this document, those skilled in the art may appropriately translate from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / multiple permutations may be clearly illustrated herein.

[0211] Those skilled in the art will understand that, generally, the terms used herein, especially those used in the appended claims (e.g., the body of the appended claims), are typically “open-ended” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “at least having,” the term “including” should be interpreted as “comprising but not limited to,” etc.) and / or “permissive” terms (e.g., the terms “is” and / or “are” can be interpreted as “can” and / or “may,” the term “referring” can be interpreted as “can refer to” and / or “may refer to,” the term “receive” can be interpreted as “can receive” and / or “may receive,” the term “support” can be interpreted as “can support” and / or “may support,” the term “dock” can be interpreted as “can dock” and / or “may dock,” etc.). The term “transmit” can be interpreted as “can dock” and / or “may dock”, “can transmit” and / or “may transmit”; the term “send” can be interpreted as “can send” and / or “may send”; the term “not referent” (and / or similar) can be interpreted as “may not refer” and / or “may not refer”; the term “do not receive” (and / or similar) can be interpreted as “may not receive” and / or “may not receive”; the term “do not support” (and / or similar) can be interpreted as “may not support” and / or “may not support”; the term “do not dock” (and / or similar) can be interpreted as “may not dock” and / or “may not dock”; the term “do not transmit” (and / or similar) can be interpreted as “may not transmit” and / or “may not transmit”; the term “do not send” (and / or similar) can be interpreted as “may not send” and / or “may not send”, etc. Those skilled in the art will further understand that if an intent is to be introduced in a particular number of claims, such intent will be expressly stated in the claims, and if no such statement is made, such intent does not exist. For example, in cases where only one item is intended, the term "single" or similar language may be used. To aid understanding, the appended claims and / or the description herein may include the use of introductory phrases "at least one" and "one or more" to introduce the recitation of a claim. However, the use of such phrases should not be construed as implying that a claim recitation introduced by the indefinite article "a" or "an" limits any particular claim that includes such an introductory claim recitation to including only one such recitation, even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce the recitation of a claim.Furthermore, even if the specific number described in the introduced claims is explicitly stated, those skilled in the art will recognize that such a description should be interpreted as meaning at least the number described (e.g., the simple description of "two descriptions" without other modifiers means at least two descriptions, or two or more descriptions). Moreover, in cases similar to the use of the convention "at least one of A, B, and C, etc.", generally, such a structure is intended to mean that those skilled in the art will understand the convention (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In cases similar to the use of the convention "at least one of A, B, or C, etc.", generally, such a structure is intended to mean that those skilled in the art will understand the convention (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will further understand that any separate words and / or phrases that actually represent two or more optional terms, whether in the specification, claims, or drawings, should be understood to envision the possibility of including one term, one term, or two terms. For example, the phrase “A or B” will be understood to include the possibility of including “A” or “B” or “A and B”. Furthermore, as used herein, the term “any” followed by a list of multiple items and / or multiple item categories is intended to include, individually or in combination with other items and / or other item categories, “any one,” “any combination,” “any plurality,” and / or “any combination of plurality.” Additionally, as used herein, the term “set” is intended to include any number of items, including zero. Additionally, as used herein, the term “quantity” is intended to include any quantity, including zero. And as used herein, the term “multiple” is intended to be synonymous with “multiple.”

[0212] Furthermore, when features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member or subgroup of the Markush Group.

[0213] As those skilled in the art will understand, for any and all purposes, such as providing a written description, all scopes disclosed herein also include any and all possible subscopes and combinations thereof. Any listed scope can be readily considered sufficiently descriptive and enables the decomposition of the same scope into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily decomposed into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “up to,” “at least,” “greater than,” “less than,” etc., includes the listed numbers and refers to a scope that can subsequently be decomposed into subscopes as discussed above. Finally, as those skilled in the art will understand, a scope includes members of each individual. Thus, for example, a group having 1-3 units means a group having 1, 2, or 3 units. Similarly, a group having 1-5 units means a group having 1, 2, 3, 4, or 5 units, and so on.

[0214] Furthermore, the claims should not be construed as limited to the order or elements provided, unless otherwise stated. Additionally, the use of the term "means for..." in any claim is intended to refer to... The claim format is either device plus function, and any claim without the term "device for..." is not intended to be so.

[0215] For example, suitable processors include general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), field-programmable gate arrays (FPGAs), any other type of integrated circuit (IC) and / or state machines.

[0216] WTRU can be used in conjunction with hardware and / or software-implemented modules, including software-defined radio (SDR) and other components such as cameras, video camera modules, video phones, speakerphones, vibration devices, speakers, microphones, TV transceivers, hands-free headsets, keyboards, Bluetooth modules, FM radio units, near field communication (NFC) modules, liquid crystal display (LCD) units, organic light-emitting diode (OLED) display units, digital music players, media players, video game player modules, internet browsers, and / or any wireless local area network (WLAN) or ultra-wideband (UWB) modules.

[0217] Although various embodiments have been described with reference to the communication system, it is conceivable that these systems can be implemented in software on a microprocessor / general-purpose computer (not shown). In some embodiments, the functionality of one or more of the various components can be implemented in software that controls the general-purpose computer.

[0218] Furthermore, although the present invention has been described and illustrated with reference to specific embodiments, the invention is not limited to the details shown. Instead, various modifications to the details can be made within the scope of the claims without departing from the invention.

Claims

1. A first network node for providing adaptive media streaming, the first network node comprising: Processor, the processor being configured to: Define one or more demonstration detection rules; Receive a first message from a second network node, wherein the first message includes a Protocol Data Unit (PDU) and indicates a first demonstration; Detect the first presentation based on PDU and one or more presentation detection rules; Determine the presentation identifier (ID) associated with the first presentation; The demo ID is determined to indicate a change from the second demo to the first demo; Based on the determination that the demo ID indicates a change from the second demo to the first demo, a second message is sent to the third network node, wherein the second message indicates a change from the second demo to the first demo; and A third message is sent to a fourth network node, wherein the third message includes the PDU and indicates the first demo and the demo ID.

2. The first network node of claim 1, wherein, The demonstration is at least one of resolution, codec, or application-determined rate markers.

3. The first network node of claim 1, wherein, The processor is also configured to: Receive one or more demonstration detection rules from a third network node.

4. The first network node of claim 1, wherein, The first message also includes a detection process and one or more IDs, wherein the demo ID is detected from the demo according to the detection process, and wherein the demo ID comes from the one or more IDs.

5. The first network node of claim 1, wherein, The demonstration detection rules can be based on one or more input business characteristics.

6. The first network node of claim 1, wherein, The third message also indicates resource usage, presentation selection prompts, or changes to the presentation ID associated with the presentation ID.

7. A method for providing adaptive media streaming, performed by a first network node, the method comprising: Define one or more demonstration detection rules; Receive a first message from a second network node, wherein the first message includes a Protocol Data Unit (PDU) and indicates a first demonstration; Detect the first presentation based on PDU and one or more presentation detection rules; Determine the presentation identifier (ID) associated with the first presentation; The demo ID is determined to indicate a change from the second demo to the first demo; Based on the determination that the demo ID indicates a change from the second demo to the first demo, a second message is sent to the third network node, wherein the second message indicates a change from the second demo to the first demo; and A third message is sent to a fourth network node, wherein the third message includes the PDU and indicates the first demo and the demo ID.

8. The method of claim 7, wherein, The demonstration is at least one of resolution, codec, or application-determined rate markers.

9. The method of claim 7, wherein, The processor is also configured to: Receive one or more demonstration detection rules from a third network node.

10. The method of claim 7, wherein, The first message also includes a detection process and one or more IDs, wherein the demo ID is detected from the demo according to the detection process, and wherein the demo ID comes from the one or more IDs.

11. The method of claim 7, wherein, The demonstration detection rules can be based on one or more of the input business characteristics.

12. The method of claim 7, wherein, The third message also indicates resource usage, presentation selection prompts, or changes to the presentation ID associated with the presentation ID.

Images