[go: up one dir, main page]

WO2025097013A1 - Procédés et appareil de prise en charge de débit binaire adaptatif pour trafic xr dans des réseaux de communication - Google Patents

Procédés et appareil de prise en charge de débit binaire adaptatif pour trafic xr dans des réseaux de communication Download PDF

Info

Publication number
WO2025097013A1
WO2025097013A1 PCT/US2024/054205 US2024054205W WO2025097013A1 WO 2025097013 A1 WO2025097013 A1 WO 2025097013A1 US 2024054205 W US2024054205 W US 2024054205W WO 2025097013 A1 WO2025097013 A1 WO 2025097013A1
Authority
WO
WIPO (PCT)
Prior art keywords
rendition
pdu
qos
message
wtru
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2024/054205
Other languages
English (en)
Inventor
Xavier De Foy
Michael Starsinic
Magurawalage Chathura SARATHANDRA
Ahmed Hamza
Rocco Di Girolamo
Srinivas GUDUMASU
Achref METHENNI
Kevin DILALLO
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Patent Holdings Inc
Original Assignee
InterDigital Patent Holdings Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by InterDigital Patent Holdings Inc filed Critical InterDigital Patent Holdings Inc
Publication of WO2025097013A1 publication Critical patent/WO2025097013A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures

Definitions

  • This disclosure pertains to procedures, methods, architectures, apparatus, systems, devices, and computer program products for, and/or directed to supporting adaptive bit rates for extended Reality (XR) traffic in communication networks, and particularly 5G networks.
  • XR extended Reality
  • a first network node e.g., UPF
  • the first network node may include a processor configured to determine one or more rendition 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 indicates a first rendition.
  • the first rendition may be detected based on the PDU and the one or more rendition detection rules.
  • a rendition identification (ID) may be determined to be associated with the first rendition.
  • the rendition ID may be determined to indicate a change from a second rendition to the first rendition.
  • a second message may be sent to a third network node (e.g., SMF) based on the determination that the rendition ID indicates the change from the second rendition to the first rendition.
  • the second message may indicate the change from the second rendition to the first rendition.
  • a third message may be sent to a fourth network node (e.g., RAN).
  • the third message may include the PDU and may indicate the first rendition and the rendition ID.
  • the rendition is at least one of a resolution or a codec.
  • the one or more rendition detection rules may be received from the third network node (e.g., SMF).
  • the first message may include a detection method and one or more a plurality of IDs, wherein the rendition ID is detected from the rendition in accordance with the detection process, and wherein the rendition ID is from the one or more IDs.
  • the rendition detection rules may be based on one or more of input traffic characteristics.
  • the third message further indicates a resource usage associated with the rendition ID, a rendition selection hint, and a change in the rendition ID.
  • FIG. 1 A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.
  • FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.
  • WTRU wireless transmit/receive unit
  • FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.
  • RAN radio access network
  • CN core network
  • FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.
  • FIG. 2 is a diagram illustrating phases for adaptive Quality of Service (QoS) configuration and operation in accordance with embodiments.
  • QoS Quality of Service
  • FIG. 3 is a signal flow diagram describing an exemplary procedure illustrating adaptive QoS configuration and operation in accordance with embodiments.
  • FIG. 4 is a flowchart illustrating a process for adaptive media streaming.
  • FIG. 5 is a flowchart illustrating another process for adaptive media streaming.
  • FIG. 6 is a flowchart illustrating another process for adaptive media streaming..
  • FIGs. 1A-1 D An overview of various types of wireless devices and infrastructure is provided with respect to FIGs. 1A-1 D, where various elements of the network may utilize, perform, be arranged in accordance with and/or be adapted and/or configured for the methods, apparatuses and systems provided herein.
  • FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented.
  • the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.
  • the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
  • the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT- Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA single-carrier FDMA
  • ZT UW DTS-s OFDM zero-tail unique-word DFT- Spread OFDM
  • UW-OFDM unique word OFDM
  • FBMC filter bank multicarrier
  • the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a ON 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment.
  • the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like.
  • UE user equipment
  • PDA personal digital assistant
  • HMD head-mounted display
  • a vehicle a drone
  • the communications systems 100 may also include a base station 114a and/or a base station 114b.
  • Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 110, and/or the other networks 112.
  • the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
  • the base station 114a may be part of the RAN 104/113, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc.
  • BSC base station controller
  • RNC radio network controller
  • the base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum.
  • a cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, i.e. , one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple-input multiple output
  • beamforming may be used to transmit and/or receive signals in desired spatial directions.
  • the base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.).
  • the air interface 116 may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like.
  • the base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 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).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE- Advanced Pro (LTE-A Pro).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • LTE-A Pro LTE- Advanced Pro
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access, which may establish the air interface 116 using New Radio (NR).
  • a radio technology such as NR Radio Access, which may establish the air interface 116 using New Radio (NR).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies.
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles.
  • DC dual connectivity
  • the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., an eNB and a gNB).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
  • IEEE 802.11 i.e., Wireless Fidelity (WiFi)
  • IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA2000 1X, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for
  • the base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
  • WLAN wireless local area network
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell.
  • the base station 114b may have a direct connection to the Internet 110.
  • the base station 114b may not be required to access the Internet 110 via the CN 106/115.
  • the RAN 104/113 may be in communication with the CN 106/115, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d.
  • the data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like.
  • QoS quality of service
  • the CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
  • the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/113 or a different RAT.
  • the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.
  • the CN 106/115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112.
  • the PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite.
  • the networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers.
  • the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104/113 or a different RAT.
  • the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links).
  • the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
  • FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG.
  • the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.
  • GPS global positioning system
  • the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like.
  • the processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
  • the processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116.
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
  • the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
  • the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
  • the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122.
  • the WTRU 102 may have multi-mode capabilities.
  • the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.
  • the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit).
  • the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128.
  • the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
  • the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
  • the processor 118 may receive power from the power source 134 and may be configured to distribute and/or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the WTRU 102.
  • the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
  • the processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
  • location information e.g., longitude and latitude
  • the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
  • the processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like.
  • FM frequency modulated
  • the peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.
  • a gyroscope an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.
  • the WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the 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 either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118).
  • the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the uplink (e.g., for transmission) or the downlink (e.g., for reception)).
  • a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the uplink (e.g., for transmission) or the downlink (e.g., for reception)).
  • FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 104 may also be in communication with the CN 106.
  • the RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment.
  • the eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the eNode-Bs 160a, 160b, 160c may implement MIMO technology.
  • the eNode-B 160a for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink (UL) and/or downlink (DL), and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
  • the CN 106 shown in FIG. 1 C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
  • MME mobility management entity
  • SGW serving gateway
  • PGW packet data network gateway
  • the MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node.
  • the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like.
  • the MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.
  • the SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface.
  • the SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c.
  • the SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
  • the SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • packet-switched networks such as the Internet 110
  • the CN 106 may facilitate communications with other networks.
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
  • the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108.
  • IMS IP multimedia subsystem
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • the WTRU is described in FIGS. 1 A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.
  • the other network 112 may be a WLAN.
  • a WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP.
  • the AP may have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS.
  • Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs.
  • Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations.
  • Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA.
  • the traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic.
  • the peer-to-peer traffic may be sent between (e.g., directly between) the source and destination ST As with a direct link setup (DLS).
  • the DLS may use an 802.11e DLS or an 802.11 z tunneled DLS (TDLS).
  • a WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other.
  • the IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.
  • the AP may transmit a beacon on a fixed channel, such as a primary channel.
  • the primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling.
  • the primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP.
  • Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in in 802.11 systems.
  • the STAs e.g., every STA, including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off.
  • One STA (e.g., only one station) may transmit at any given time in a given BSS.
  • High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.
  • VHT STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels.
  • the 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels.
  • a 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration.
  • the data, after channel encoding may be passed through a segment parser that may divide the data into two streams.
  • Inverse Fast Fourier Transform (IFFT) processing, and time domain processing may be done on each stream separately.
  • IFFT Inverse Fast Fourier Transform
  • the streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA.
  • the above-described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).
  • MAC Medium Access Control
  • Sub 1 GHz modes of operation are supported by 802.11af and 802.11 ah.
  • the channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11 ac.
  • 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum
  • 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum.
  • 802.11 ah may support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area.
  • MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths.
  • the MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).
  • WLAN systems which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel.
  • the primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS.
  • the bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode.
  • the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes.
  • Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.
  • STAs e.g., MTC type devices
  • NAV Network Allocation Vector
  • the available frequency bands which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.
  • FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment.
  • the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 113 may also be in communication with the CN 115.
  • the RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment.
  • the gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the gNBs 180a, 180b, 180c may implement MIMO technology.
  • gNBs 180a, 180b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c.
  • the gNB 180a may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
  • the gNBs 180a, 180b, 180c may implement carrier aggregation technology.
  • the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum.
  • the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology.
  • WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).
  • CoMP Coordinated Multi-Point
  • the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum.
  • the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and/or lasting varying lengths of absolute time).
  • TTIs subframe or transmission time intervals
  • the gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration.
  • WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c).
  • WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point.
  • WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band.
  • WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c.
  • WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously.
  • eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.
  • Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink (UL) and/or downlink (DL), support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.
  • UPF User Plane Function
  • AMF Access and Mobility Management Function
  • the CN 115 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
  • SMF Session Management Function
  • the AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node.
  • the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU (Protocol Data Unit) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like.
  • network slicing e.g., handling of different PDU (Protocol Data Unit) sessions with different requirements
  • Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c.
  • different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and/or the like.
  • URLLC ultra-reliable low latency
  • eMBB enhanced massive mobile broadband
  • MTC machine type communication
  • the AMF a82a, 182b may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.
  • radio technologies such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.
  • the SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface.
  • the SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface.
  • the SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b.
  • the SMF 183a, 183b may perform other functions, such as managing and allocating a WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like.
  • a PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.
  • the UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.
  • the CN 115 may facilitate communications with other networks.
  • the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108.
  • IMS IP multimedia subsystem
  • the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.
  • DN local Data Network
  • one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a- b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown).
  • the emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein.
  • the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.
  • the emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment.
  • the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network.
  • the one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network.
  • the emulation device may be directly coupled to another device for purposes of testing and/or may performing testing using over-the-air wireless communications.
  • the one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network.
  • the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components.
  • the one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.
  • RF circuitry e.g., which may include one or more antennas
  • XR traffic handling by wireless networks and PDU sets may be provided. It may be challenging for wireless networks to carry media flows, especially for applications with high-throughput and/or low latency requirements, such as video conferencing and Extended Reality (XR). Wireless networks may implement techniques to improve network capacity and energy efficiency, as well as reduce the impact of packet losses on user experience. For example, wireless networks, such as 5G networks, may handle groups of packets based on how critical they are to the user experience. Some groups of data packets may hold application data units that are handled (e.g., decoded) together by the application, and/or that are referred to as a PDU (Packet Data Unit) set. A PDU set may, for example, correspond to the PDUs carrying a single complete Network Application Layer (NAL) unit.
  • NAL Network Application Layer
  • the network may perform differentiated and/or integrated QoS handling of XR traffic. This may include prioritizing some PDU sets over others during congestion.
  • the network may use the fact that application data units may depend on other application data units to be handled and/or decoded by the application (e.g., P-frames depend on l-frames, and enhancement layers depend on base layers).
  • the network may selectively drop data packets that depend on an already lost application data unit.
  • the network may limit wake-up time (e.g., of radios) to transmit and/or receive data.
  • the packet scheduler e.g., in RAN nodes
  • WTRUs may synchronize their transmission and/or listening times using information on the size and/or periodicity of traffic, as well as delay budget and/or expected jitter specific to the application.
  • the RAN may perform differentiated/integrated QoS handling of XR traffic based on differentiated and/or integrated handling Information Elements (lEs) associated with a flow and/or PDU sets inside the flow.
  • Differentiated/integrated Handling lEs include PDU Set QoS Parameters that are received via the control plane and PDU Set Information that was received via the user plane.
  • PDU set information may be sent by the UPF to the RAN node via a GTP-U header of a user plane packet.
  • PDU set information may be provided by a WTRU application through the Service Data Adaptation Protocol (SDAP) interface.
  • SDAP Service Data Adaptation Protocol
  • PDU set IE may be used to represent lEs described herein as PDU set information and PDU set QoS parameters.
  • PDU set information may include a PDU Set ID.
  • This IE may be an identifier of a PDU set, which may uniquely identify the PDU set within the flow, at least for a duration corresponding to the transmission time of PDUs between sender and receiver.
  • This IE may be, for example, a numerical ID, a timestamp, etc.
  • PDU set information may include a start and/or end of a PDU set indication. These lEs may identify the first and/or last PDU(s) of a PDU set.
  • PDU set information may include a PDU sequence number within a PDU Set.
  • This IE may identify a PDU within a PDU set, for example, a numerical ID starting at 0 for the first PDU and incremented by 1 for each PDU in the set.
  • PDU set information may include a PDU Set size. This IE may hold the total number of PDUs, the cumulative length of all the PDUs in the set, and/or the cumulative length of all PDU payload (e.g., transport payload) in the PDU set.
  • PDU set information may include a PDU set importance. This IE may be a numerical value indicative of the importance level of a PDU set within a service flow (e.g., from highest priority value 0 to lowest priority value 255). RAN may use it for PDU set level packet discarding in presence of congestion.
  • PDU set information may include an end-of-burst indication.
  • This IE may indicate that a PDU or a PDU set is the last PDU or PDU set of a burst.
  • This IE may include lEs indicating the amount of time before a (e.g., the next) burst.
  • PDU set QoS parameters may be a set of parameters to configure the QoS handling of a flow.
  • PDU set QoS parameters may include PDU set information and/or may include a PDU Set Error Rate (PSER). This IE value may correspond to error rates applicable to PDU sets (e.g., where a PDU set loss corresponds to an event, where at least a PDU of the set may not be transmitted). This IE may be used to configure the (e.g., acceptable) error rate for PDU sets of a service flow or QoS flow in the RAN.
  • PSER PDU Set Error Rate
  • PDU set QoS parameters may include a PDU Set Delay Budget (PSDB).
  • PSDB PDU Set Delay Budget
  • This IE value may correspond to the acceptable delay for transmitting a full PDU set (e.g., from the reception of the first PDU of the set, to the transmission of the last PDU of the set).
  • This IE may be used to configure the delay budget for a service flow or QoS flow in the RAN.
  • PDU set QoS parameters may include a PDU Set Integrated Handling Information (PSI HI). This IE may indicate whether all PDUs of the set are needed by the application.
  • PSI HI PDU Set Integrated Handling Information
  • PDU set QoS parameters may include a burst periodicity.
  • This IE value may designate the period of a data burst for this flow (e.g., transmission period for consecutive independent frames in a video stream, e.g., transmission period for a group of pictures).
  • PS Identification which may be the determination of which PDU Set a PDU belongs to, along with the identification of PS lEs that are associated with this PDU set.
  • PS QoS Handling e.g., PS Handling or PSH
  • PSH PS Handling
  • Adaptive media streaming may be provided.
  • the concept of media rendition (e.g., often referred to as “rendition” herein) may be used in media streaming.
  • a media stream may be transmitted using one or several available resolutions and bitrates for the content.
  • a version (e.g., each version) of the media content, for example, associated with one resolution and bitrate, may be called a rendition.
  • a media sender may stream different renditions and/or may switch between one rendition and another rendition dynamically during a streaming session.
  • Media streaming following this dynamic selection and switching between renditions may be designated as Adaptive Bit Rate (ABR) streaming.
  • ABR Adaptive Bit Rate
  • Media content may be structured to enable switching between renditions at specific positions in the stream, delimiting media segments that are time-aligned across renditions and/or that may be decoded independently from earlier content.
  • HTTP streaming protocols such as dynamic adaptive streaming over HTTP (DASH), LL- DASH, and HTTP live streaming (HLS), may enable a client to request a specific rendition from the sender.
  • the Media over QUIC (MOQ) protocol may enable the sender to switch between a set of renditions, agreed between a sender and receiver, based on the current link capacity, for example, as determined by a congestion control algorithm.
  • the Real-Time Transport Protocol (RTP) protocol (e.g., including variants such as RTP over QUIC (ROQ)) may allow for flexibly adapting to different network conditions.
  • RTP may work in conjunction with the Real-Time Control Protocol (RTCP), which may be used for monitoring and/or control of an RTP session.
  • RTCP Real-Time Control Protocol
  • an RTP sender may adjust the transmission parameters, such as the transmission rate or quality settings.
  • An (e.g., alternative) QoS profile may be a combination of QoS parameters (e.g., Packet Delay Budget (PDB), Packet Error Rate (PER), and/or others), to which the application traffic may be able to adapt.
  • Multiple (e.g., alternative) QoS profiles may be (e.g., optionally) provided to a RAN node, for a Guaranteed Bit Rate (GBR) QoS flow. If the main QoS profile is not able to be fulfilled by the RAN, the RAN may start applying a (e.g., alternate) QoS profile, and/or notify the SMF with a reference to the (e.g., alternative) QoS profile that the RAN may fulfill.
  • Adaptive Bit Rate may be used to stream content over a 5G network.
  • a given ABR traffic flow may transmit, over time, different renditions of portions of a media flow. The throughput requirements of such flows may evolve over time.
  • the ABR traffic flow may use the available bandwidth to provide the best Quality of Experience (QoE) for the user.
  • QoE Quality of Experience
  • the QoS used for such traffic may be multimedia-specific (e.g., 5QI “2” for live streaming, “3” for real-time gaming, etc.).
  • the 5G network may be enhanced to handle XR traffic, which has both high throughput and low latency requirements.
  • XR-related enhancements may limit energy and/or network resource usage, while maintaining an acceptable QoE for the end user. These enhancements may include support for PDU set-based differentiated QoS handling and/or leveraging traffic periodicity to reduce energy consumption.
  • XR-related enhancements may not include support for ABR. The (e.g., same) QoS profile may be applied to traffic for different renditions.
  • a PSDB dimensioned for a low-quality rendition may be too short for a high- quality rendition, resulting in artificially increasing the reported PDU Set Error Rate (PSER).
  • PSER PDU Set Error Rate
  • a PSDB dimensioned for a high-quality rendition may be too large for a low-quality rendition, resulting in delaying the delivery of PDUs and reducing the time during which the WTRU may be placed in low-power mode.
  • the burst period (e.g., video frame time) may vary between different renditions, potentially resulting in inefficiencies in the RAN, for example, where the WTRU is put out of low-power mode too early before the start of a new burst.
  • charging may be based on the higher resolution rendition, which may result in effectively overcharging the user, especially in cases where the network conditions are bad and mostly low-resolution renditions are used.
  • High resolution renditions may require some network services (e.g., PDU set and/or traffic burst support) that are not needed for lower resolution.
  • existing mechanisms may include requesting, by the WTRU, a PDU session modification requesting new QoS parameters to be applied to the QoS flow.
  • Such mechanisms may be inefficient because the rendition may change often (e.g., in some cases several times per seconds). This may result in using more network resources than is necessary (e.g., overhead from control plane signaling involving the WTRU, SMF, PCF, UPF and RAN).
  • Such mechanisms may not be well synchronized with a change of rendition, for example, (e.g., new) QoS parameters may not be applied on time to be used with the initial PDUs transporting a rendition (e.g., a new rendition). This may result in transmission losses during a transition between two renditions.
  • (e.g., new) QoS parameters may not be applied on time to be used with the initial PDUs transporting a rendition (e.g., a new rendition). This may result in transmission losses during a transition between two renditions.
  • Support for ABR traffic for XR may be therefore desired. Such support should enable the RAN to efficiently and/or accurately apply different QoS handling to different portions of a traffic flow, depending on which media rendition is transmitted over the flow.
  • Support may be enabled for ABR traffic for XR in 5G networks.
  • the network may be aware of the QoS parameters for each rendition in a media flow.
  • the network may identify which media rendition is currently transmitted over a media flow.
  • the network may apply the QoS parameters associated with the currently transmitted rendition. Charging may be fair and correspond to the QoS parameters actually applied to each portion of the traffic.
  • the efficiency of a network used for multiple concurrent ABR flows may be improved (e.g., globally) by enabling the 5G network to provide a hint (e.g., and/or, equivalently, a command) to the application about which rendition should be selected. This may enable improving the network efficiency, for example, by balancing network resource usage and stabilizing the ABR algorithm between multiple concurrent ABR sessions between different sets of WTRUs and an Application Server (AS).
  • AS Application Server
  • a network such as a 5G network
  • a network may be enhanced to support a feature, which may be the feature referred herein as adaptive QoS.
  • Adaptive QoS may enable support for ABR and address one or more network issues.
  • the RAN node e.g., a gNodeB
  • the RAN node may be provided with a QoS profile and/or one or more alternative QoS profiles, where all or some of the provided QoS profiles may include a rendition identifier (e.g., a new rendition identifier).
  • the WTRU may be provided with a QoS rule and/or one or more alternative QoS rules.
  • Some (e.g., all) of the provided QoS rules may include a new rendition identifier.
  • the rendition identifier (e.g., new rendition identifier) may associate the QoS profile or QoS rule it belongs to with a specific rendition of the content transmitted over the QoS flow.
  • the term rendition may relate to the representation (same content at different levels of detail) or alternative content (equivalent content such as a different view for the same scene) of a media stream.
  • the term “rendition” may relate to the rendition of any application data flow, where the application data flow may be transmitted at different rates, discrete, and/or known in advance.
  • the term “rendition” may relate to a rate marking of the application data flow, where the rate marking is based on an application-determined characteristic of the flow.
  • An example of application-determined characteristic of the flow is the urgency, or criticality of the flow at this moment in time.
  • the sending application may determine that at this moment in time the application is processing a complex scene, which requires a larger processing time than usual at the sender and/or receiver, and therefore the sending application marks the application flow with a rendition ID corresponding to a “critical” rate marking.
  • the 5G network may identify in real time the rendition transmitted in a PDU, and/or may communicate the PDU and identified rendition ID to the RAN node.
  • the 5G network may transmit the PDU and may apply QoS handling, using the QoS parameters from the QoS profile associated with the identified rendition ID.
  • the WTRU may identify in real time the rendition transmitted in a PDU, and/or may transmit the PDU to the RAN node applying QoS handling, using the QoS rules associated with the identified rendition ID.
  • the adaptive QoS mechanisms described herein may be applied to XR traffic (e.g., where some renditions use a PDU set-based QoS, and where some renditions do not use a PDU-set based QoS), and also to other types of media traffic (e.g., haptics/media/video streaming), and other types of traffic. Furthermore, usually in a service data flow, media will flow in one direction, and feedback (e.g., acknowledgements and measurements) may flow in the other direction. If the media is sent downlink, adaptive QoS may be applied on DL traffic (e.g., in UPF and RAN). If the media is sent uplink, adaptive QoS may be applied on UL traffic (e.g., in WTRU).
  • DL traffic e.g., in UPF and RAN
  • adaptive QoS may be applied on UL traffic (e.g., in WTRU).
  • FIG. 2 illustrates the major phases for configuring and operating adaptive QoS and highlights related new information elements.
  • the Application Provider (e.g., through the AF) may configure the 5G network for adaptive QoS.
  • the AP may configure the 5G network with adaptive QoS configuration lEs (e.g., QoS parameters/profiles/rules/PDRs Packet Detection Rules) including a rendition ID, indication for UPF to select QoS parameters based on rendition, methods for rendition detection by UPF and/or WTRU, adaptive QoS feedback configuration), which may be used by the Policy Control Function (PCF) to configure Policy and Charging Control (PCC) rules.
  • PCF Policy Control Function
  • PCC Policy and Charging Control
  • the SMF may configure the RAN, UPF, and/or WTRU for adaptive QoS, using QoS profiles, PDRs, and/or QoS rules including a rendition ID.
  • the 5G network may identify the transmitted rendition of a PDU.
  • the UPF transmits to the RAN, the PDU in a GTP-U message including the PDU rendition ID in the GTP-U header.
  • the RAN node e.g., downlink
  • WTRU e.g., uplink
  • the UPF (and/or RAN node and/or WTRU) sends adaptive QoS feedback, such as usage information including a rendition ID, adaptive QoS rendition information, and/or an adaptive QoS rendition selection hint.
  • the SMF may use the feedback for communicating with a charging function.
  • the SMF and/or UPF may provide usage information, rendition information, and/or an adaptive QoS hint to the AF/AS and influence the application (e.g., the AF/AS may use this feedback for rendition selection or access selection).
  • the concept of alternate QoS profile is extended to support multiple alternate QoS profiles that the RAN may select, not based on the QoS profile that may be fulfilled, but based on the rendition currently transmitted in the user plane traffic.
  • the network may be configured for adaptive QoS.
  • a rendition ID may be used by an application provider to identify a rendition transmitted over a network.
  • HTTP streaming protocols and the MOQ protocol may enable identifying each available rendition with a rendition ID.
  • the RTP protocol may not use fixed renditions, it may be possible, e.g., for the purpose of implementing the methods described herein, for the application provider to identify, using a rendition ID, different sets of transmission rates and quality settings that may be used by an RTP sender.
  • the application provider may provide to the network, e.g., to the NEF/PCF (Network Exposure function/Policy Control Function), a list of the available renditions and the associated rendition ID and QoS configuration.
  • the application provider may also provide to the network, e.g., to the UPF, the rendition ID corresponding to the currently transmitted rendition and/or transmission rate and quality settings.
  • the methods to provide rendition IDs to the network are described hereinafter.
  • the rendition ID provided by the application provider to the 5G network may be derived from an existing application-layer rendition ID.
  • renditions may be referred to as representations by the AP, using different codecs and/or maximum spatial and/or temporal resolution, which may be requested by clients using a Universal Resource Indicator (URI).
  • URI Universal Resource Indicator
  • the AP could use a hash value from a URI as a rendition ID, or an index number referring to the Nth representation, or a number derived from the display resolution such as 720, 1080, 1440, 2048, and 4096.
  • the AF may configure the 5G network for adaptive QoS using an API enhanced for adaptive QoS.
  • a NEF service API such as Nnef_AFsessionWithQoS_Create may be enhanced to include a set of rendition IDs, which may be associated with a (e.g., default or alternative) QoS reference and/or set of QoS parameters.
  • Nnef_AFsessionWithQoS_Create may be enhanced to include other adaptive QoS configuration lEs, such as an indication to use the adaptive QoS feature for UL, DL, or both UL and DL.
  • the NEF and/or PCF may configure a QoS-enabled PCC rule in the PCF.
  • Adaptive QoS configuration lEs may be provided by the AF and/or configured in a QoS- enabled policy rule in a 5G network (e.g., adaptive QoS-enabled PCC rules in PCF).
  • Adaptive QoS configuration lEs may be provided by the SMF, to the RAN, UPF, and/or WTRU, during the establishment or modification of a QoS flow.
  • Adaptive QoS configuration lEs may include one or more features including, but not limited to, adaptive QoS profiles, adaptive QoS rules, adaptive QoS PDRs.
  • Adaptive QoS configuration lEs may include adaptive QoS profiles.
  • QoS profiles e.g., a QoS profile and a one or more of alternative QoS profiles
  • QoS profiles may also include usual QoS profile lEs, including, for example 5QI, allocation and retention priority, PDU set QoS parameters (including PDU Set Delay Budget (PSDB), PDU Set Error Rate (PSER), PDU Set Integrated Handling Information (PSI HI), reflective QoS attributes, guaranteed and maximum flow bit rates, etc.
  • PSDB PDU Set Delay Budget
  • PSER PDU Set Error Rate
  • PSI HI PDU Set Integrated Handling Information
  • Adaptive QoS configuration lEs may include adaptive QoS rules. These are a set of QoS rules and/or (e.g., optionally) QoS Flow level QoS parameters where (e.g., all or some) QoS rules (and/or QoS Flow level QoS parameters) may include a rendition ID (or are otherwise associated with a rendition ID). The rendition ID may indicate for which rendition the associated QoS rule (and/or QoS Flow level QoS parameters) should be applied.
  • the QoS rules may also include usual QoS rule lEs, including, for example, a 5QI, packet filter set precedence value, rule identifier, etc.
  • One of the QoS profiles may be a default QoS profile. This may be (e.g., explicitly) signaled in the Adaptive QoS configuration lEs. This may be (e.g., alternatively) implicitly determined.
  • the first QoS profile in the set may be the default QoS profile.
  • the first (e.g., and/or only) QoS profile without a rendition ID may (e.g., alternatively) be the default QoS profile.
  • the default QoS profile may be used if the PDU has no rendition ID and/or if the RAN node may not meet the requirements of the QoS profile needed for the PDU based on the included rendition ID.
  • Adaptive QoS configuration lEs may include adaptive QoS PDRs. These may be a set of UL and/or DL PDRs, where one or more of the PDRs may include a rendition ID (or is otherwise associated with a rendition ID). The rendition ID may indicate for which rendition the associated PDR should be applied.
  • the PDRs may also include usual PDR lEs, including, for example, a rule ID, precedence, source interface, packet filter, application identifier, 5QI, protocol description, etc.
  • a PDR may include a list of rendition IDs that may be present in the flow identified by the PDR (e.g., the PDR associated with the Packet Forwarding Control Protocol (PFCP) session). This list may indicate to the UPF that only those rendition IDs may be valid for this flow. This list of rendition IDs may correspond to the rendition IDs configured into the RAN and associated with a QoS profile.
  • PFCP Packet Forwarding Control Protocol
  • An adaptive QoS indication (e.g., including an UL indication and DL indication) may be used to indicate the use of adaptive QoS for uplink, downlink, or both uplink and downlink.
  • this indication may indicate that the UPF is permitted to detect a rendition transmitted by a PDU and/or select, for example, through the signaling of a rendition ID, the QoS profile that should be applied by the RAN on a PDU.
  • this indication may indicate that the WTRU is permitted to detect a rendition transmitted by a PDU and/or select the QoS rule that should be applied on a PDU for uplink transmission.
  • a rendition detection method IE may be used to indicate a method or protocol by which a node (e.g., WTRU or UPF) may determine the rendition ID associated with a PDU. For example, it may hold different values corresponding to a specific RTP extension header, a specific Multiplexed Application Substrate over QUIC Encryption (MASQUE) extension, a specific MOQ extension, a programmatic Application Programing Interface (API), or any other protocols.
  • the value of this IE may instruct the WTRU and/or UPF from which protocol field to read a rendition ID and which PDU(s) are associated with the rendition ID).
  • An adaptive QoS feedback configuration IE may 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 to the charging system.
  • This IE may include a description of the allowed types of feedback messages, as well as constraints on the feedback (e.g., maximum/minimum rates of messages).
  • the adaptive QoS feedback configuration IE may include parameters such as the importance of the QoS flow compared to other flows, which may help RAN/UPF determine which flow should be increased/decreased/maintained.
  • QoS profiles and/or QoS rules may include multiple rendition IDs and multiple QoS parameters.
  • the RAN node/WTRU may first match the QoS profile/rule (e.g., using protocol and source and destination IP addresses and ports of the PDU).
  • the RAN node/WTRU may find a matching rendition ID among the available rendition IDs.
  • the RAN node/WTRU may select the QoS parameters associated with the matching rendition ID.
  • A e.g., slightly
  • the same principle of associating a rendition ID with a set of QoS parameters corresponding to a specific QoS handling may be used.
  • a WTRU may send to an SMF, a PDU session establishment or modification request message including an adaptive QoS indication to indicate that the WTRU supports adaptive QoS indication (e.g., for UL, DL, or both) and/or requests to use adaptive QoS indication if permitted by the network.
  • the adaptive QoS indication may be implicit and/or not included in the message (e.g., because the WTRU is known to support the adaptive QoS feature and/or because the WTRU application is known to benefit from adaptive QoS).
  • a SMF may configure the RAN, UPF, and/or WTRU for adaptive QoS upon reception of a PDU session establishment or modification request message (e.g., explicitly or implicitly) including an adaptive QoS indication.
  • the SMF upon reception of the message, may obtain a PCC rule corresponding to the requested QoS flow/PDU session, e.g., from the PCF.
  • the SMF may determine, for example, from the adaptive QoS indication in PCC (e.g., an indication from PCC) and/or from the PDU session establishment/modification message (e.g., an indication from WTRU), whether to support adaptive QoS for UL, DL or both UL and DL.
  • the SMF may determine to use adaptive QoS if, for this direction, both indications from PCC and WTRU indicate to use adaptive QoS. If there is no indication from the WTRU (e.g., if it is implicit), the SMF may determine to use adaptive QoS for each direction based on the indication from the PCC. If the SMF determines to use adaptive QoS for DL, the SMF may send, to the RAN, one or more of an adaptive QoS indication, the adaptive QoS profiles from the PCC rule (e.g., in PDU session establishment/ modification response), and/or adaptive QoS feedback configuration.
  • an adaptive QoS indication e.g., the adaptive QoS profiles from the PCC rule (e.g., in PDU session establishment/ modification response), and/or adaptive QoS feedback configuration.
  • the SMF may send to the UPF (e.g., in N4 rules), one or more of an adaptive QoS indication, rendition detection method IE, adaptive QoS PDRs from the PCC rule, and adaptive QoS feedback configuration. If the SMF determines to use adaptive QoS for UL, the SMF may send to the WTRU (e.g., in PDU session establishment/ modification response), one or more of an adaptive QoS indication; rendition detection method IE; adaptive QoS rules from the PCC rule; adaptive QoS feedback configuration.
  • the WTRU e.g., in PDU session establishment/ modification response
  • the SMF may send QoS profiles, PDRs, and/or QoS rules without including rendition IDs (some of the QoS profiles/PDRs/rules may become useless or redundant without rendition ID and may not be sent).
  • the UPF may determine to use adaptive QoS for the QoS flow. If adaptive QoS is indicated, the UPF may configure its rendition detection algorithm based on the rendition detection method IE. The UPF may further apply the PDRs, some of which include a rendition ID.
  • the RAN node may determine to use adaptive QoS for the QoS flow. If adaptive QoS is indicated, the RAN node may apply the QoS profiles, some of which include a rendition ID. The RAN node may configure itself to detect the rendition ID based on the GTP- U headers, and look-up applicable QoS profiles based on the rendition ID. In examples, the RAN node may not be able to meet the requirements of one or more of the adaptive QoS profiles included in the Adaptive QoS configuration lEs. For example, the RAN node may not be able to meet the Guaranteed Flow Bit Rate (GFBR) requirement for one of the profiles.
  • GFBR Guaranteed Flow Bit Rate
  • the SMF may send the adaptive QoS configuration IE to the RAN node.
  • the RAN node may determine that it may not meet the parameters or requirements of one or more of the provided profiles.
  • the RAN node may accept the QoS flow, but it may send an indication to the SMF that includes the one or more profiles that it may not meet.
  • a RAN node may reject the establishment or modification of a QoS flow if it may not meet any of the adaptive QoS profiles.
  • Some applications may require some minimum level of adaptability (e.g., alternatively).
  • the reject and/or accept decision for QoS flows may be based on this minimum requirement.
  • the RAN node may (e.g., only) accept the QoS flow if the network may provide service for at least three adaptive QoS profiles.
  • the WTRU may determine to use adaptive QoS for the QoS flow. If adaptive QoS is indicated, the WTRU may apply the QoS rules, some of which may include a rendition ID. The WTRU may configure its rendition detection algorithm based on the rendition detection method IE. The WTRU may configure itself to look-up applicable QoS rules based on the rendition ID.
  • the transmitted rendition may be identified for Adaptive QoS.
  • the decision to transmit a given rendition may be taken by the media receiver (e.g., WTRU application), for example, if using the DASH protocol.
  • the media receiver requests from the media sender a specific rendition for a portion of the flow (e.g., for a segment of the media stream).
  • the decision to transmit a given rendition may be taken be the media sender (e.g., AS), for example, if using the MOQ protocol.
  • the media receiver and sender may agree to use a set of renditions (e.g., during a session setup phase or using out-of-band means), and the media sender may switch from one rendition to another at a specific point in the stream(s), e.g., based on the media sender evaluation of the available bandwidth, which may be provided by a congestion control algorithm part of the media transport protocol (e.g., MOQ).
  • a congestion control algorithm part of the media transport protocol e.g., MOQ
  • a PDU rendition ID may indicate the rendition associated with a PDU (e.g., in cases where the PDU rendition ID is transmitted in a PDU header for each media PDU associated with a rendition), or with multiple PDUs (e.g., in cases where the PDU rendition ID is transmitted in a control message, and/or may apply to a set of PDUs identified in the control message, for example, using a sequence number or timestamp present in PDU headers).
  • a PDU rendition ID may be associated with one or more PDUs, for example.
  • a PDU rendition ID may be associated with one or more PDUs, for example, using a new PDU rendition ID in the header of a GTP packet, which may indicate a rendition associated with the PDU transported in the GTP packet (e.g., with the media packet transmitted in the PDU). This may be used in GTP packets from the UPF to the RAN, from the RAN to the UPF, and/or from the AS to the UPF.
  • a PDU rendition ID may be associated with one or more PDUs, for example, using (e.g., alternately) a new PDU rendition ID in a RTP extension header (e.g., in a PDU set RTP extension header) may indicate a rendition associated with the PDU (e.g., with the media packet transmitted in the RTP packet).
  • a PDU rendition ID may be associated with one or more PDUs, for example, using (e.g., alternately) a new PDU rendition ID in a MASQUE or MOQ stream header may indicate a rendition associated with all data transported in this MOQ or QUIC stream or PDU set.
  • a PDU rendition ID may be associated with one or more PDUs, for example, using (e.g., alternately) a new PDU rendition ID in a MASQUE or MOQ message may indicate a rendition associated with all data transported in a MOQ stream or QUIC stream or PDU set identified in the message (e.g., with a MOQ or QUIC stream ID).
  • a PDU rendition ID may be associated with one or more PDUs, for example, using (e.g., alternately) a new PDU rendition ID in a MASQUE, MOQ, or RTP over QUIC (ROQ) datagram message may indicate a rendition associated with the PDU (e.g., with the media packet transmitted in the HTTP datagram) or PDU set (e.g., with a group of media packets transmitted in multiple HTTP datagrams associated with a same PDU set).
  • a new PDU rendition ID in a MASQUE, MOQ, or RTP over QUIC (ROQ) datagram message may indicate a rendition associated with the PDU (e.g., with the media packet transmitted in the HTTP datagram) or PDU set (e.g., with a group of media packets transmitted in multiple HTTP datagrams associated with a same PDU set).
  • a PDU rendition ID may be associated with one or more PDUs, for example, using (e.g., alternately) a new PDU rendition ID in a UDP or IP option may indicate a rendition associated with the PDU (e.g., with the media packet transmitted in the UDP or IP payload).
  • a PDU rendition ID may be associated with one or more PDUs, for example, using (e.g., alternately) a message including a rendition ID and a reference to a PDU, group of PDUs, or PDU set may indicate the rendition transported by this PDU/group of PDUs/PDU set.
  • a PDU rendition ID may be associated with one or more PDUs, for example, using (e.g., alternately) a new message including a rendition ID from AS/AF through the control plane (e.g., using a PCF or NEF API) may indicate the rendition associated with the PDU, where the rendition 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.
  • NEF Network Exposure Function
  • the rendition ID may be provided to the 5GS through a service enablement layer (e.g., edge or XR enablement layer).
  • the AS may set the rendition ID through an edge enabler server, which may communicate the rendition ID to the NEF.
  • a PDU rendition ID may correspond (e.g., is equals to or may be mapped to) a QoS flow rendition ID configured for this QoS flow.
  • the QoS flow rendition ID may be included in a PCC rule in an adaptive QoS configuration IE defined hereinbefore.
  • the PDU rendition ID may be (e.g., implicitly) associated with a PDU (e.g., if the PDU rendition ID is present in a header of the PDU).
  • the PDU rendition ID may not be (e.g., implicitly) associated with a PDU.
  • the message may include an identifier of the target PDU(s), which may be, for example, a QUIC or MOQ stream ID, timestamp(s), or sequence number(s) indicating the last and/or first PDU associated with the PDU rendition ID.
  • an identifier of the target PDU(s) which may be, for example, a QUIC or MOQ stream ID, timestamp(s), or sequence number(s) indicating the last and/or first PDU associated with the PDU rendition ID.
  • a UPF may identify the transmitted rendition using any of the following methods: the UPF may read the PDU rendition ID in a header in the PDU; the UPF may receive the PDU rendition ID in a message that identifies the PDU; or the UPF may detect the rendition associated with a PDU, e.g., using an estimation heuristic or using an Al-based algorithm (e.g., with support from NWDAF), for example, using PDU timing and size information as input.
  • the UPF may determine which rendition detection method to use based on the rendition detection method IE indicated by the SMF in an N4 rule message.
  • a WTRU may identify the transmitted rendition using any of the following methods: the WTRU may read the PDU rendition ID in a header in the PDU; the WTRU may receive the PDU rendition ID in a message that identifies the PDU; or the WTRU application may provide the PDU rendition ID associated with the PDU in a programmatic API function call (e.g., passing PDU and PDU rendition ID as parameters).
  • a programmatic API function call e.g., passing PDU and PDU rendition ID as parameters.
  • the WTRU may determine which rendition detection method to use based on the rendition detection method IE indicated by the SMF in the PDU session establishment/modification message.
  • the UPF may transmit the PDU to the RAN by including a PDU rendition ID in the header of the GTP-U packet, including the PDU, where the value of the PDU rendition ID provided in the GTP-U header corresponds to the rendition detected by the UPF.
  • the UPF may send a rendition change notification to the SMF indicating the new PDU rendition ID. This may be useful in typical media transmission scenarios, where the rendition being transmitted may change relatively rarely (e.g., every few seconds or minutes).
  • the SMF may send a rendition update indication (including the new PDU rendition ID) to the AF through the PCF and/or NEF. This indication may enable the application provider to control quality assurance for its service. In examples, based on indications of this type, the application provider may decide to switch the streaming delivery for some of its users to another radio access technology.
  • Adaptive QoS may be applied.
  • the RAN node e.g., gNodeB
  • the RAN node may read the PDU rendition ID associated with the PDU, e.g., in the GTP-U header. If a PDU rendition ID is found, the RAN node may search for a matching traffic filter and rendition ID using as input the PDU rendition ID and/or other usual lEs (such as protocol and source and destination IP addresses and ports of the PDU). If a matching traffic filter and rendition ID is found, the RAN node may select the QoS parameters associated with the matching traffic filter and rendition ID, and/or may perform the PDU transmission while applying QoS handling as indicated by those QoS parameters.
  • the RAN node may search for a matching traffic filter without rendition ID to obtain a default set of QoS parameters.
  • the RAN node may perform transmission while applying QoS handling as indicated by those QoS parameters.
  • the RAN may be allowed to override the QoS profile allocation decision based on the rendition ID sent by the UPF.
  • the RAN node may decide not to use the QoS profile suggested by the UPF via the rendition ID.
  • the rendition ID may indicate that resources must be increased for the PDU, but the RAN may decide that resources may not be increased and/or may allocate a lower amount of network resource.
  • the RAN node may inform the SMF, UPF, or AS/AF (e.g., through SMF) of this change.
  • the WTRU may obtain the PDU rendition ID associated with the PDU, for example, using a method described herein based on the rendition detection method IE.
  • the WTRU may search for a matching QoS rule with a matching rendition ID using as input the PDU rendition ID and/or other usual lEs (e.g., such as protocol and/or source and destination IP addresses and ports of the PDU). If a matching QoS rule with a rendition ID is found, the WTRU may select the matching QoS rule with a rendition ID, and/or the WTRU may perform the PDU transmission while applying QoS handling as indicated by this QoS rule.
  • lEs e.g., such as protocol and/or source and destination IP addresses and ports of the PDU.
  • the WTRU may search for a matching QoS rule without matching rendition ID, to obtain a default QoS rule.
  • the WTRU may perform transmission while applying QoS handling as indicated by this QoS rule.
  • Adaptive QoS feedback may be provided.
  • Feedback from RAN/UPF may be usage information.
  • the SMF may send an enhanced Usage Reporting Rule (URR) to the UPF, where an enhanced URR (e.g., associated with PDRs including a rendition ID IE) includes an indication (e.g., a new indication) to use adaptive QoS reporting.
  • URR Usage Reporting Rule
  • the UPF may provide usage reports to the SMF, including network resource usage information (e.g., amount of transmitted PDU size) associated a rendition ID and with one or more of: QoS flow ID, 5QI, a WTRU ID (e.g., Subscription Permanent Identifier (SUPI), Subscriber Concealed Identifier (SUCI), Generic Public Subscription Identifier (GPSI)), and WTRU IP address.
  • the SMF may send messages based on this information to the charging system and/or to the AF/AS through PCF/NEF (e.g., aggregating the amount of transmitted PDU size for a given set of QoS parameters, using the PDU rendition ID and Adaptive QoS configuration lEs). This may enable the 5GS to charge customers based on the actual QoS applied to the transmitted renditions.
  • the indication to use adaptive QoS reporting in a URR may be implicit, if a rendition ID IE is present in a PDR associated with the URR.
  • the WTRU and/or RAN node may send a usage report (e.g., to the SMF, PCF, or charging system), including network resource usage information and a rendition ID, to enable accurate charging if adaptive QoS is used.
  • Feedback from a RAN/UPF may be a rendition selection hint or indication.
  • the UPF, WTRU, and/or RAN node may determine to send adaptive QoS feedback, e.g., based on an adaptive QoS feedback configuration IE from the SMF (e.g., in an N4 message or a PDU session establishment/modification response).
  • the adaptive QoS feedback configuration IE may indicate to send one or more types of feedback messages, such as usage reports, hints, or information messages.
  • the UPF, WTRU and/or RAN may determine to send an adaptive QoS feedback hint message to the SMF if one or more triggers are activated.
  • an adaptive QoS feedback hint message may be sent if network congestion is detected or predicted.
  • the UPF/WTRU/RAN may identify some adaptive QoS flows (e.g., with lower priority, and/or transmitting a rendition with high bandwidth usage) that may be scaled down (e.g., that may be transmitted with a lower resolution or more generally with another rendition that requires less data to be transmitted).
  • UPF/WTRU/RAN may send a hint to scale down.
  • an adaptive QoS feedback hint message may be sent if a low network usage condition is detected.
  • the UPF/WTRU/RAN may identify some adaptive QoS flows (e.g., which higher priority, and/or transmitting a rendition with low bandwidth usage) that may be scaled up.
  • UPF/WTRU/RAN may send a hint to scale up.
  • an adaptive QoS feedback hint message may be sent if frequent PDU rendition ID changes are detected.
  • the UPF/WTRU/RAN may decide to increase system stability by sending a hint to keep a stable rendition ID, along with a time or duration indicating for how long the AF/AS should maintain the same rendition ID.
  • the UPF/WTRU/RAN may further rely on a heuristic or AI/ML algorithm to determine if to send an adaptive QoS hint feedback message, and the nature (type and content) of the feedback message.
  • the UPF, WTRU and/or RAN may determine to send an adaptive QoS feedback information message to the SMF, if a changed PDU rendition ID is detected (e.g., if the value of the PDU rendition ID, which is generally stable over time, changes from one rendition ID to another).
  • the SMF may be configured (e.g., by the PCF) to use new “Policy Control Request Triggers”.
  • a rendition ID change indication may be triggered if the SMF receives a notification (e.g., from UPF or RAN) that the rendition ID associated with PDUs of a flow was changed. If this trigger is activated, the SMF may send the new rendition ID to the PCF.
  • the PCF e.g., through NEF
  • the AF/AS may use this information to manage the delivery quality and cost (e.g., taking actions, such as selecting new access technologies for new or some current clients/WTRUs).
  • a rendition selection hint may be triggered if the SMF receives a notification (e.g., from the UPF or RAN) including a rendition selection hint (e.g., up, down, stable, or a specific rendition ID). If this trigger is activated, the SMF may send the rendition selection hint (e.g., a new rendition ID or an indication to increase/decrease/maintain the rendition) to the PCF.
  • the PCF e.g., through NEF
  • a media receiver or sender may set (e.g., by sender) or request (e.g., by receiver) a rendition change based on the message and/or may refrain from making or requesting rendition changes for the duration specified in the message.
  • This behavior may enable adaptive media streaming sessions to share the network with other traffic (including other adaptive media stream sessions) in a fair and stable manner.
  • the WTRU may send a rendition selection hint or indication message over the user plane to the WTRU application (e.g., using a programmatic API), which the WTRU application may use to control the sent or requested rendition.
  • the WTRU application e.g., using a programmatic API
  • the UPF may send a rendition selection hint or indication message over the user plane to the AS (e.g., using a MASQUE message, UDP or IP option or another user-plane message), which the AS may use to control the sent or requested rendition.
  • FIG. 3A and FIG. 3B are a signal flow diagram describing an exemplary procedure illustrating adaptive QoS configuration and operation in accordance with an embodiment.
  • the different phases (A-E) typically occur in this order, but not necessarily sequentially and not necessarily all of them will occur in one media session (e.g., C occurs if there is DL media, and D occurs if there is UL media).
  • Each phase may have its own trigger.
  • Phase (A) illustrates adaptive QoS configuration by an AF. It is triggered if the AP decides to configure adaptive QoS, e.g., for a media session.
  • the AF 116 may send to the NEF 114 an API message to set QoS for a traffic flow (e.g., Nnef_AFsessionWithQoS_Create).
  • the API message may include adaptive QoS configuration lEs.
  • the NEF 114 may send the request to set QoS for a traffic flow to the PCF 112, including the adaptive QoS configuration lEs.
  • the PCF 112 may save the adaptive QoS configuration lEs in a PCC rule.
  • Phase (B) illustrates the setup of a QoS flow using adaptive QoS. It is triggered if the WTRU application initiates a connection with the AS 116.
  • a WTRU application may initiate a connection with a media server (AS), which may trigger the WTRU 102 to send to the SMF 108 (through the AMF 106), a PDU session establishment or modification request, which may include an adaptive QoS indication, which may indicate that the WTRU 102 supports and/or requests to use adaptive QoS.
  • AS media server
  • the SMF 108 may obtain a PCC rule including an adaptive QoS configuration IE, which may include rendition IDs (e.g., during policy association).
  • the SMF may send to UPF an N4 session modification request (e.g., including an adaptive QoS configuration IE including rendition IDs).
  • an N4 session modification request e.g., including an adaptive QoS configuration IE including rendition IDs.
  • the UPF 110 may configure itself for adaptive QoS, including rendition detection and adaptive QoS feedback.
  • the UPF 110 may send a response to the SMF 108.
  • the SMF 108 may send to the WTRU 102, through the AMF 106 and RAN 104, a PDU session establishment or modification response, which may include an adaptive QoS configuration IE, which may include rendition IDs.
  • a PDU session establishment or modification response which may include an adaptive QoS configuration IE, which may include rendition IDs.
  • the RAN 104 may configure itself for adaptive QoS, including rendition based QoS parameters selection and adaptive QoS feedback.
  • the adaptive QoS configuration IE e.g., adaptive QoS profiles, adaptive QoS indication, adaptive QoS feedback configuration
  • Phase (C) illustrates adaptive QoS operation on downlink traffic. It is triggered if an AS, acting as a media sender, may send a media PDU towards the WTRU 102.
  • the AS 116 may send, to the WTRU 102 via the UPF 110, a media PDU including a PDU rendition ID, or a media PDU otherwise associated with a PDU rendition ID (e.g., via another message including the PDU rendition ID and an ID corresponding to the PDU or a group of PDUs including the PDU).
  • the UPF 110 detects the rendition ID associated with the PDU, for example, by retrieving the rendition ID from a PDU header or other method described herein.
  • the UPF 110 may send to the RAN node 104 a GTP-U message including the PDU and a PDU rendition ID (e.g., in the GTP-U message header).
  • the RAN node 104 may select the applicable QoS parameters based on PDU rendition ID from the GTP-U header.
  • the RAN node may use the selected QoS parameters to transmit the PDU to the WTRU 102.
  • the RAN node may apply (e.g., less stringent) QoS parameters corresponding to a (e.g., lower resolution) rendition, 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 may notify the AF/AS.
  • the AS may change the rendition it sends to the WTRU, to adapt to the network service that is effectively provided (not shown in FIG. 3B).
  • Phase (D) illustrates adaptive QoS operation on uplink traffic. It may be triggered if a WTRU, acting as a media sender, sends a media PDU towards the AS.
  • the WTRU app may determine to send a PDU to the AS.
  • the WTRU may detect the PDU rendition ID, may select a QoS rule based on the detected PDU rendition ID and/or may use the selected QoS rule to transmit the PDU to the RAN 104 (step D.2).
  • the rendition ID may be transmitted along with the PDU (e.g., using a layer-2 header field).
  • the rendition ID may not be transmitted at D.2, and/or the RAN may detect the rendition ID, for example, based on the QoS parameters used to transmit the PDU by the WTRU.
  • the RAN node 104 may transmit the PDU to the UPF 110 in a GTP-U message that includes the PDU rendition ID.
  • the UPF 110 may record the rendition ID associated with the PDU (e.g., to have it available for future usage reports) and may use the rendition ID for sending a feedback message.
  • the UPF 110 may forward the PDU towards the AS 116.
  • Phase (E) illustrates adaptive QoS feedback.
  • the UPF sends the feedback message. This phase starts based on a trigger in the UPF.
  • the RAN or WTRU may send a feedback message based on a trigger in the RAN or WTRU, respectively.
  • the UPF 110 may determine that it should send a feedback message (e.g., usage report periodically, rendition information based on a change of rendition ID, or rendition hint based on an algorithm or heuristic using rendition ID).
  • a feedback message e.g., usage report periodically, rendition information based on a change of rendition ID, or rendition hint based on an algorithm or heuristic using rendition ID.
  • the UPF 110 may send a feedback message over N4 to the SMF 108.
  • the SMF 108 may use the feedback message. For example, if the feedback is a usage report, the SMF may associate the usage information with the QoS parameters corresponding to the rendition ID, and/or may forward the usage information or an aggregate usage information to the charging system. For example, if the feedback is a rendition information or rendition selection hint message, the SMF, based on a Policy Control Request Trigger configured by the PCF, forwards the feedback message to the PCF. The PCF may, based on event registration by the AF, forward (e.g., through the NEF) the feedback message to the AF, which may use the feedback information as described herein.
  • FIG. 4 is a flowchart illustrating a first exemplary process for adaptive media streaming in accordance with at least some of the principles set forth hereinabove.
  • a UPF may receive a message from the SMF associated with a flow indicating that the UPF should detect which QoS profile should be applied to a PDU, PDU set, or group of PDUs of the flow.
  • the message may contain N4 rules associated with the flow.
  • the detection of which QoS profile to apply may 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 traffic or PDU information.
  • the UPF may receive, for example, from an AF, at least one PDU of the flow.
  • the UPF may detect a rendition ID associated with the flow indicative of the QoS selection (e.g., in the header of the PDU, in a separate message or using an algorithm).
  • the UPF may transmit a message (e.g., a GTP-U message) to the RAN including the rendition ID and a QoS Flow ID identifying the QoS profile to apply to the PDU including in the (e.g., GTP-U) message.
  • a message e.g., a GTP-U message
  • the RAN may apply a QoS profile appropriate for the detected rendition, which may enable improving QoE for the end user while improving network resource usage efficiency for the network operator.
  • the UPF may provide feedback to the SMF indicative of a rendition version that might be more suitable for the flow than the current rendition version. This is illustrated at 409. This indication may include, for instance, information as to the level of traffic/congestion in the network.
  • FIG. 5 is a flowchart a flowchart illustrating a second exemplary process for adaptive media streaming in accordance with at least some of the principles set forth hereinabove.
  • a node of a RAN may receive (e.g., from the SMF of the core network) a set of QoS profiles for a QoS flow identified by a QoS flow ID, along with associated rendition IDs for at least some of the QoS profiles and an indication that the core network (e.g., UPF) is permitted to change the QoS of the flow.
  • a QoS flow ID e.g., from the SMF of the core network
  • the core network e.g., UPF
  • the RAN node may receive (e.g., from the UPF), a packet including a PDU, and a header, the header including a PDU rendition ID (the rendition ID being associated with a QoS profile), and a QoS flow ID.
  • the RAN node may use the PDU rendition ID and (e.g., possibly) other PDU characteristics (e.g., source/destination IP address and port, protocol) to determine a QoS profile associated with a rendition ID.
  • PDU rendition ID e.g., possibly
  • other PDU characteristics e.g., source/destination IP address and port, protocol
  • the RAN node applies the selected QoS profile to the QoS flow to transmit the PDU to the destination WTRU.
  • the RAN node may provide feedback to the core network (e.g., the SMF), such as an indication of a rendition version that might be more suitable for the flow than the current rendition version. This is illustrated at 509. This indication may include, for instance, a report message describing the resource usage associated with each rendition ID. This may enable charging of adaptive media transmission based on the actual QoS parameters used to transmit the PDUs.
  • the core network e.g., the SMF
  • This indication may include, for instance, a report message describing the resource usage associated with each rendition ID. This may enable charging of adaptive media transmission based on the actual QoS parameters used to transmit the PDUs.
  • the feedback may (e.g., alternately) comprise a rendition selection hint indicating a desired behavior from the application (to be used by the core network for selecting a new rendition).
  • the feedback may (e.g., alternately) comprise a rendition information message indicating a change in the detected rendition ID.
  • FIG. 6 is a flowchart illustrating a third exemplary process for adaptive media streaming in accordance with at least some of the principles set forth hereinabove.
  • the SMF may receive a PDU session establishment or modification message.
  • the PDU session establishment or modification message may include, for instance, an indication to use adaptive QoS on the PDU session and/or for the requested flows.
  • the SMF may obtain related PCC rules (e.g., from PCF) including some of the following: (a) an indication that the UPF is permitted to change which QoS Profile is applied; (b) one or more alternate QoS profile associated with a rendition ID; (c) a protocol ID indicating a method for the UPF to detect the rendition transmitted in a DL PDU; and (d) a protocol ID indicating a method for the WTRU to detect the rendition transmitted in a UL PDU.
  • PCC rules e.g., from PCF
  • the SMF may receive (e.g., from the UPF or from the RAN or WTRU) a notification that includes a rendition ID (e.g., a per-rendition usage report and/or a rendition information message) or a rendition selection hint as previously described.
  • a rendition ID e.g., a per-rendition usage report and/or a rendition information message
  • a rendition selection hint as previously described.
  • the SMF may transmit to a Policy Control Function (PCF) a second indication responsive to the first notification. For example, if the received indication included a network resource usage report corresponding to a rendition ID, the SMF may transmit a notification to a charging system including traffic usage information corresponding to QoS parameters identified by the rendition ID.
  • PCF Policy Control Function
  • the SMF may transmit a notification to the WTRU and/or to the PCF/NEF (which may send a notification to the AF), including the rendition ID and/or rendition selection hint.
  • the application e.g., AS or WTRU application
  • infrared capable devices for example, infrared emitters and receivers.
  • the embodiments discussed are not limited to these systems but may be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves such as acoustic waves.
  • video or the term “imagery” may mean any of a snapshot, single image and/or multiple images displayed over a time basis.
  • the terms “user equipment” and its abbreviation “WTRU” e.g., “UE”
  • the term “remote” and/or the terms “head mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmit and/or receive unit (WTRU); (ii) any of a number of embodiments of a WTRU; (iii) a wireless-capable and/or wired-capable (e.g., tetherable) device configured with, inter alia, some or all structures and functionality of a WTRU; (iii) a wireless-capable and/or wired-capable device configured with less than all structures and functionality of a WTRU; or (iv) the like.
  • WTRU wireless transmit and/or receive unit
  • any of a number of embodiments of a WTRU e.g., a wireless-capable and/or wired-capable (e.g., tetherable) device configured with, inter
  • FIGs. 1A-1 D Details of an example WTRU, which may be representative of any WTRU recited herein, are provided herein with respect to FIGs. 1A-1 D.
  • various disclosed embodiments herein supra and infra are described as utilizing a head mounted display.
  • a device other than the head mounted display may be utilized and some or all of the disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other device may include a drone or other device configured to stream information for providing the adapted reality experience.
  • the methods provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor.
  • Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media.
  • Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, MME, EPC, AMF, or any host computer.
  • processing platforms, computing systems, controllers, and other devices that include processors are noted. These devices may include at least one Central Processing Unit (“CPU”) and memory.
  • CPU Central Processing Unit
  • memory In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or instructions may be referred to as being “executed”, “computer executed” or “CPU executed”.
  • the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU.
  • An electrical system represents data bits that may cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU’s operation, as well as other processing of signals.
  • the memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs and that other platforms and CPUs may support the provided methods.
  • the data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (RAM)) or non-volatile (e.g., Read-Only Memory (ROM)) mass storage system readable by the CPU.
  • the computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the provided methods.
  • any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium.
  • the computer-readable instructions may be executed by a processor of a mobile unit, a network element, and/or any other computing device.
  • a signal bearing medium examples include, but are not limited to, the following: a recordable type of medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc., and a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).
  • a recordable type of medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc.
  • a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).
  • a typical data processing system may generally include one or more of a system unit housing, a video display device, a memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, computational entities such as operating systems, drivers, graphical user interfaces, and applications programs, one or more interaction devices, such as a touch pad or screen, and/or control systems including feedback loops and control motors (e.g., feedback for sensing position and/or velocity, control motors for moving and/or adjusting components and/or quantities).
  • a typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing/communication and/or network computing/communication systems.
  • any two components so associated may also be viewed as being “operably connected”, or “operably coupled”, to each other to achieve the desired functionality, and any two components capable of being so associated may also be viewed as being “operably couplable” to each other to achieve the desired functionality.
  • operably couplable include but are not limited to physically mateable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components.
  • the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.”
  • the terms “any of” followed by a listing of a plurality of items and/or a plurality of categories of items, as used herein, are intended to include “any of,” “any combination of,” “any multiple of,” and/or “any combination of multiples of” the items and/or the categories of items, individually or in conjunction with other items and/or other categories of items.
  • the term “set” is intended to include any number of items, including zero.
  • the term “number” is intended to include any number, including zero.
  • the term “multiple”, as used herein, is intended to be synonymous with “a plurality”.
  • a range includes each individual member.
  • a group having 1-3 cells refers to groups having 1 , 2, or 3 cells.
  • a group having 1-5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so forth.
  • Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs); Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine.
  • DSP digital signal processor
  • ASICs Application Specific Integrated Circuits
  • ASSPs Application Specific Standard Products
  • FPGAs Field Programmable Gate Arrays
  • the WTRU may be used in conjunction with modules, implemented in hardware and/or software including a Software Defined Radio (SDR), and other components such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a Near Field Communication (NFC) Module, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wide Band (UWB) module.
  • SDR Software Defined Radio
  • other components such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Des systèmes, des procédés, des dispositifs et des instrumentalités sont décrits pour fournir une diffusion multimédia adaptative. Un premier nœud de réseau (par exemple, UPF) peut être fourni. Le premier nœud de réseau peut comprendre un processeur configuré pour déterminer une ou plusieurs règles de détection de rendu. Un premier message peut être reçu en provenance d'un second nœud de réseau (par exemple, AS). Le premier message peut comprendre une unité de données de protocole (PDU) et indique un premier rendu. Le premier rendu peut être détecté sur la base de la PDU et de la ou des règles de détection de rendu. Une identification de rendu (ID) peut être déterminée comme étant associée au premier rendu. L'ID de rendu peut être déterminé pour indiquer un changement d'un second rendu vers le premier rendu. Un second message peut être envoyé à un troisième nœud de réseau (par exemple, SMF) sur la base de la détermination que l'ID de rendu indique le changement du second rendu vers le premier rendu.
PCT/US2024/054205 2023-11-02 2024-11-01 Procédés et appareil de prise en charge de débit binaire adaptatif pour trafic xr dans des réseaux de communication Pending WO2025097013A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202363547053P 2023-11-02 2023-11-02
US63/547,053 2023-11-02

Publications (1)

Publication Number Publication Date
WO2025097013A1 true WO2025097013A1 (fr) 2025-05-08

Family

ID=93607624

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/054205 Pending WO2025097013A1 (fr) 2023-11-02 2024-11-01 Procédés et appareil de prise en charge de débit binaire adaptatif pour trafic xr dans des réseaux de communication

Country Status (1)

Country Link
WO (1) WO2025097013A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018175855A1 (fr) * 2017-03-23 2018-09-27 Vid Scale, Inc. Mesures et messages visant à améliorer une expérience de diffusion en continu adaptative sur 360 degrés
US20230283789A1 (en) * 2022-05-16 2023-09-07 Intel Corporation Efficient hypertext transfer protocol (http) adaptive bitrate (abr) streaming based on scalable video coding (svc)
WO2023192094A1 (fr) * 2022-03-28 2023-10-05 Interdigital Patent Holdings, Inc. Synchronisation de flux multimodaux

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018175855A1 (fr) * 2017-03-23 2018-09-27 Vid Scale, Inc. Mesures et messages visant à améliorer une expérience de diffusion en continu adaptative sur 360 degrés
WO2023192094A1 (fr) * 2022-03-28 2023-10-05 Interdigital Patent Holdings, Inc. Synchronisation de flux multimodaux
US20230283789A1 (en) * 2022-05-16 2023-09-07 Intel Corporation Efficient hypertext transfer protocol (http) adaptive bitrate (abr) streaming based on scalable video coding (svc)

Similar Documents

Publication Publication Date Title
EP4470176A1 (fr) Surveillance et rapport de performance pour prendre en charge une opération aiml
US20240196265A1 (en) Pdu-based priority level determination within a downlink qos flow
EP4659427A1 (fr) Communications associées à une importance relative
EP4631273A1 (fr) Transmissions en liaison montante utilisant une priorité basée sur un ensemble de pdu dans un flux qos
WO2025097013A1 (fr) Procédés et appareil de prise en charge de débit binaire adaptatif pour trafic xr dans des réseaux de communication
US20250358676A1 (en) Active discarding based on pdu set correlation
WO2025240128A1 (fr) Système et procédés d'activation de caractéristiques d'ensemble d'unités pdu basée sur une analyse
WO2025072513A1 (fr) Gestion de changements dynamiques dans des modèles de trafic dans la dl
WO2025072710A1 (fr) Gestion de changements dynamiques des habitudes de transmission dans la dl
WO2025240695A1 (fr) Changement de périodicité de trafic dynamique et configuration de surveillance de paramètres n6
WO2024233978A1 (fr) Procédés, architectures, appareils et systèmes pour permettre un accès à trajets multiples sensible à la réalité étendue
WO2025045809A1 (fr) Procédés, architectures, appareils et systèmes pour intelligence artificielle distribuée
WO2025035098A1 (fr) Ensembles de pdu dl avec atsss
WO2024194149A1 (fr) Procédés, architectures, appareils et systèmes destinés à la mesure et à des ajustements de caractéristiques de flux co-dépendants
WO2025213085A1 (fr) Rapport d'utilisation de données amélioré pour applications xrm
WO2025240213A1 (fr) Procédés, architectures, appareils et systèmes pour permettre l'orientation, la commutation, la division de trafic d'accès synchronisé
WO2024211840A1 (fr) Surveillance de gigue basée sur des tampons de niveau d'ensemble de pdu et des niveaux d'importance
WO2024233262A1 (fr) Procédés, architectures, appareils et systèmes de détermination de division de budget de retard de paquet pour des relais wtru à wtru
WO2024211581A1 (fr) Attribution de ressources de réseau sur la base d'informations de retard
WO2024163877A1 (fr) Importance relative et facteur de rejet associés à la détermination de l'éligibilité de rejet de paquets
WO2025072619A1 (fr) Procédés, architectures, appareils et systèmes pour des optimisations en fonction d'une correction d'erreur directe de couche d'application
WO2025024100A1 (fr) Procédé et nœud réseau pour planification sensible au retard pour flux d'ensembles d'unités de données de protocole (pdu)
WO2024211582A1 (fr) Attribution de ressources de réseau sur la base d'informations de budget de retard d'ensemble d'unités de données de protocole (pdu) (psdb)
WO2024206798A1 (fr) Dispositifs de réseau associés à une transmission fiable d'ensembles de pdu
WO2025024278A1 (fr) Procédés, architectures, appareils et systèmes d'information sur les changements de qualité de service dans des éléments de réseau dans des réseaux ido

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24809802

Country of ref document: EP

Kind code of ref document: A1