Method, architecture, apparatus and system for measurement and adjustment of interdependent flow characteristics

Abstract

In one embodiment, a method may be implemented in a WTRU. The WTRU may send request information to a first network element, the request information indicating a request to execute a replication policy for information associated with the first flow and the second flow, where the first flow and the second flow may be interdependent. The WTRU may send first information in a first flow to a first network element, and may receive replicated first information from a second flow from the first network element, where the first flow and the second flow may be interdependent. The WTRU may determine one or more interdependent stream characteristics associated with the first stream and the second stream based on the first information and the replicated first information. The WTRU may transmit second information associated with one or more interdependent flow characteristics.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Patent Application No. 63 / 453,809, filed March 22, 2023, which is incorporated herein by reference in its entirety. Technical Field

[0002] This disclosure is generally directed to the fields of communications, software, and coding, including, for example, methods, architectures, apparatuses, and systems for measuring and adjusting the characteristics of co-dependent streams. Background Technology

[0003] Extended reality (XR) can include, for example, either augmented reality (AR) or virtual reality (VR). In XR services and applications such as, for example, interactive AR and VR, a wireless transmit / receive unit (WTRU) can interact with an XR server, for example, running on an edge computing network element, to offload computationally intensive tasks, such as those for video rendering or anti-collusion computing. The embodiments described herein are designed with the foregoing in mind. Summary of the Invention

[0004] This document describes methods, architectures, apparatuses, and systems for measuring and adjusting interdependent flow characteristics. In one embodiment, a WTRU including circuitry is described, comprising, for example, a processor, memory, a transmitter, and a receiver (e.g., a transceiver) operatively coupled to the processor. The circuitry can be configured to send a request message to a first network element indicating a request to execute a replication strategy for information associated with a first and a second flow, wherein the first and second flows may be interdependent. The circuitry can be configured to receive acknowledgment information from the first network element to confirm the request message. The circuitry can be configured to send first information to the first network element in the first flow and receive first information about the replication from the second flow from the first network element. In various embodiments, the first and second flows may be interdependent and associated with an application. The circuitry can be configured to determine one or more interdependent flow characteristics associated with the first and second flows based on the first information and the first information about the replication. In one example, the circuitry can be configured to determine that the interdependent flow characteristics satisfy, for example, QoS budget conditions associated with the application. The circuit can be configured, for example, to send second information associated with the one or more interdependent flow characteristics to a second network element based on determining that the interdependent flow characteristics can satisfy the QoS budget conditions.

[0005] In one embodiment, a method can be implemented in a WTRU. The method can include sending request information to a first network element, the request information indicating a request to perform a replication policy of information associated with a first flow and a second flow, where the first flow and the second flow can be interdependent. The method can include receiving acknowledgement information from the first network element acknowledging the request information. The method can include sending first information to the first network element in the first flow and receiving replicated first information from the second flow from the first network element. In various embodiments, the first flow and the second flow can be interdependent and associated with an application. The method can further include determining one or more interdependent flow characteristics associated with the first flow and the second flow based on the first information and the replicated first information. In one example, the method can further include determining that the interdependent flow characteristics can satisfy, for example, a QoS budget condition associated with the application. The method can further include sending second information associated with the one or more interdependent flow characteristics to a second network element, for example, based on determining that the interdependent flow characteristics can satisfy the QoS budget condition. BRIEF DESCRIPTION OF DRAWINGS

[0006] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings wherein: Figure 1A is a system diagram illustrating an example communications system; Figure 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used within the communications system 100 shown in Figure 1A; Figure 1A is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used within the communications system 100 shown in Figure 1A; Figure 1C is a system diagram illustrating another example RAN and another example CN that can be used within the communications system 100 shown in Figure 1A; Figure 1A Figure 1D is a system diagram illustrating another example RAN and another example CN that can be used within the communications system 100 shown in Figure 1A; Figure 1A Figure 2 is a diagram illustrating two examples of XR applications; Figure 3 is a diagram illustrating an example of quality of service (QoS) flow information carried in a transport layer; Figure 4 ​​is a diagram illustrating an example method for measuring and adjusting interdependent flow characteristics; Figure 5 is a diagram illustrating an example of different QoS / QoE characteristics for measurement and adjustment; Figure 6 is a diagram illustrating an example of different timing measurements for QoS / QoE characteristic measurement; Figure 7 is a diagram illustrating an example method for delay measurement based on either of Real-Time Protocol (RTP) and Real-Time Control Protocol (RTCP) marking time stamps; Figure 8 is a diagram illustrating an example method for QoS / QoE delay adjustment exposure in forward / reverse RTP flow marking; Figure 9 is a diagram illustrating an example method for delay measurement and adjustment of interdependent flows; and Figure 10 is a diagram illustrating another example method for delay measurement and adjustment of interdependent flows. DETAILED DESCRIPTION

[0007] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples can be practiced without some or all of these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the following description. Also, embodiments and examples

[0008] Example Communication System The methods, apparatus and systems provided herein are well suited to communications involving both wired and wireless networks. With respect to Figures 1A-1D An overview of various types of wireless devices and infrastructure are provided, where various elements of the network can utilize, perform, be arranged according to, adapted for, and / or configured for the methods, apparatus and systems provided herein.

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

[0010] As shown Figure 1A The communications system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which can be referred to as a “station” and / or a “STA” ) can be configured to transmit and / or receive wireless signals, and can include (or be) 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 (IoT) 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 or other wireless devices operating in an industrial and / or an automated processing chain environments), a consumer electronics device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

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

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

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

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

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

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

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

[0018] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, 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.

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

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

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

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

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

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

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

[0026] Although the transmit / receive element 122 is depicted in the WTRU 102 Figure 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

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

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

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

[0030] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 can receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 can acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0031] The processor 118 can further be coupled to other elements / peripherals 138, which can include one or more software and / or hardware modules / units required to provide additional features, functionality and / or wired or wireless connectivity. For example, the elements / peripherals 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (e.g., 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, an electronic game player module, an Internet browser, a virtual reality and / or an augmented reality (VR / A R) device, an activity tracker, and the like. The elements / peripherals 138 can include one or more sensors that can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a posture sensor, a biological sensor, and / or a humidity sensor.

[0032] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for both uplink (e.g., for transmissions) and downlink (e.g., for reception) can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and / or eliminate self-interference and / or cross- interference that can occur during concurrent transmission and reception. In one embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for either uplink (e.g., for transmissions) or downlink (e.g., for reception)).

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

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

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

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

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

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

[0039] The SGW 164 can be connected to the PGW 166, which can provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0040] The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide

[0041] Although WTRUs are described in Figures 1A-1D representative embodiments as wireless terminals, it is contemplated that in certain representative embodiments such terminals can use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

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

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

[0044] When using an 802.11 ac infrastructure mode of operation or a similar mode of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a wide bandwidth of 20 MHz) or a dynamically set width via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, a carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs, including the AP (e.g., each of the STAs) can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA can back off. Only one STA can transmit at any given time in a given BSS.

[0045] High Throughput (HT) STAs can use 40 MHz wide channels 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.

[0046] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can be parsed into two streams by a segment parser. The inverse fast Fourier transform (IFFT) and time domain processing can be done on each stream separately. The streams can be mapped on to the two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described 80+80 configuration operations can be reversed, and the combined data can be sent to the medium access control (MAC) layer, entity, etc.

[0047] 802.11af and 802.11ah support sub-1 GHz modes of operation. The channel operating bandwidths and carriers in 802.11af and 802.11ah are reduced relative to those used in 802.11η and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support metering type control / Machine Type Communication (MTC), such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, e.g., limited capabilities, including support (e.g., only support) for certain and / or limited bandwidths. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0048] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11η, 802.11ac, 802.11af, and 802.11ah include a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by one of the STAs operating in the BSS that supports the smallest bandwidth operating mode. In the example of 802.11ah, for a STA (e.g., a MTC type device) that supports (e.g., only supports) a 1 MHz mode, the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, e.g., due to a STA (which only supports a 1 MHz operating mode) transmitting to the AP, then the entire available frequency band can be considered busy, even though most of the frequency band remains idle and can be available.

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

[0050] Figure 1D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As described above, the RAN 113 can utilize NR radio technologies to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 can also be in communication with the CN 115.

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

[0052] The WTRUs 102a, 102b, 102c can use transmission associated with scalable numerology to communicate with gNBs 180a, 180b, 180c. For example, the OFDM symbol spacing and / or the OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including a variable number of OFDM symbols and / or lasting a variable length of absolute time).

[0053] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize signal s in an unlicensed frequency band (e.g., such as the IEEE 802.1 1 band) to communicate with gNBs 180a, 180b, 180c. In the non-standalone configuration, the WTRUs 102a, 102b, 102c can communicate / wirelessly couple to gNBs 180a, 180b, 180c while also communicating / wirelessly coupling with another RAN, such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c can implement DC principles to substantially simultaneously communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c can serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput to WTRUs 102a, 102b, 102c.

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

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

[0056] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and can serve as the control node. For example, the AMF 182a, 182b can be responsible for authenticating the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the WTRU 102a, 102b, 102c registration area, termination of NAS signaling, mobility management, and the like. The AMF 182a, 182b can utilize network slicing to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service being utilized, such as for ultra-reliable low-latency (URLLC) access, for enhanced massive mobile broadband (eMBB) access, for MTC access, and / or the like. The AMF 182a, 182b can provide control plane functionality such as for switching the WTRUs 102a, 102b, 102c between RANs 113 using different radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as Wi-Fi.

[0057] The SMF 183a, 183b can be connected to AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b can also be connected to the UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating IP address

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

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

[0060] In view of Figures 1A-1D And Figures 1A-1D In view of the respective descriptions of the above, one or more or all of the functions described herein with respect to any of the following can be performed by one or more emulation elements / devices (not shown): WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other element / device(s) described herein. An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device can be used to test other devices and / or to emulate a network and / or WTRU functionality.

[0061] The one or more emulation devices can perform one or more, or all, of the functions while implemented as part of a wired and / or wireless communication network for testing one or more other implementations of the devices within the communication network. The one or more emulation devices can perform one or more, or all, of the functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation devices can be directly coupled to the other devices under test, and / or can perform testing using over-the-air, wireless communication.

[0062] The one or more emulation devices can perform one or more, or all, of the functions while not implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices can be utilized in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement test scenarios for testing one or more components. The one or more emulation devices can be test equipment. The emulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas).

[0063] For clarity, throughout the embodiments described herein, a threshold, a (e.g., threshold) value, configuring the (e.g., threshold) value, and the like, with respect to (e.g., greater than or less than) the (e.g., threshold) value, describe meeting, failing to meet, (e.g., QoS budget) conditions, and configuring condition parameter(s). For example, meeting a (e.g., QoS budget) condition can be described as being above a (e.g., threshold) value, while failing to meet a (e.g., QoS budget) condition can be described as being below a (e.g., threshold) value. The embodiments described herein are not limited to threshold-based conditions. Other conditions and parameter(s) of any kind, such as, for example, belonging or not belonging to a range of values, can be applicable to the embodiments described herein.

[0064] Throughout the embodiments described herein, (e.g., configuration) information can be described as being received by a WTRU from a network, for example, through system information or via any kind of protocol message. Although not explicitly mentioned throughout the embodiments described herein, the same (e.g., configuration) information can be pre-configured in the WTRU (e.g., via any kind of pre-configuration method, such as, for example, via factory settings), such that this (e.g., configuration) information can be used by the WTRU without being received from the network.

[0065] Throughout the embodiments described herein, the terms "serving base station," "base station," "gNB," "network" can be used interchangeably to denote any network element, such as for example, a network element acting as a serving base station. The embodiments described herein are not limited to gNBs, and are applicable to any other type of serving base station.

[0066] Throughout the embodiments described herein, any network element of a RAN or core network (CN) can be referred to herein as a "network."

[0067] Throughout the embodiments described herein, 'a' and 'an' and similar phrases are to be interpreted as 'one or more' and 'at least one.' Similarly, any term ending in '(-one or more)' is to be interpreted as 'one or more' and 'at least one.' The term'may' is to be interpreted as 'e.g., can.'

[0068] The symbol ' / ' (e.g., forward slash) can be used to denote 'and / or,' where, for example, 'A / B' can imply 'A and / or B.'

[0069] Throughout the embodiments described herein, the expressions "invoke a function (e.g., of an API)" and "send information (e.g., a request to invoke a function (e.g., of an API)) indicating a function (e.g., of an API)" can be used interchangeably to denote that a request message indicating one or more parameters of the invoked function can be sent to a network element, and a response message indicating one or more response parameters of the invoked function can be received from the network element.

[0070] Throughout the embodiments described herein, the expression "expose information to a network" can be used interchangeably with "send information to a network element" to denote that the information can be made available to (e.g., transmitted to) a network element in a message that can be directed to and / or can be processed by the network element for forwarding to another network element (e.g., the network element is the ultimate destination of the message), where the exposed information can be intercepted and processed by the network element based on, for example, packet inspection techniques.

[0071] Throughout the embodiments described herein, the terms "request (or response)" and "send a request (or response)" can be used interchangeably with the expression "send information indicating a request (or response)."

[0072] Throughout the embodiments described herein, the term "interdependent flows" can be used to refer to at least a first flow and a second flow pair having a certain degree of dependency to meet, for example, QoS (e.g., QoE) targets for an application based on the interdependent flows. The terms "first flow" and "forward flow" can be used interchangeably throughout the embodiments described herein. The terms "second flow," "reverse flow," and "backward flow" can be used interchangeably throughout the embodiments described herein. The embodiments described herein can be applicable to more than one forward flow that depends on (e.g., is affected by, is associated with) a reverse flow.

[0073] SUMMARY In the embodiments described herein, a WTRU can correspond to any XR device (e.g., network element), which can be in a wide variety of form factors. Examples of a WTRU (e.g., an XR WTRU) can include, but are not limited to, any of the following: a head-mounted display (HMD), optical see-through glasses, camera see-through HMD for either AR or VR, a mobile device with position tracking and cameras, a wearable device, and the like. For example, there can be different types of XR WTRUs based on (e.g., different) XR device functionalities, such as, for example, any of the following to be provided by one or more devices, wearable devices, actuators, controllers, and / or accessories: displays, cameras, sensors, sensor processing, wireless connectivity, XR / media processing, and power. One or more devices (e.g., network elements, WTRUs) can be grouped into a collaborative XR group for supporting any of XR applications, XR experiences, and XR services.

[0074] In XR services and applications, such as, for example, either AR or VR with interactivity, a WTRU can interact (e.g., exchange information) with an XR server running, for example, on an edge computing network element to offload, for example, compute-intensive tasks for video rendering or anti-collusion computation. In an example of rendering between a WTRU and an edge network element, an XR WTRU can transmit, for example, in an uplink (UL) transmission, any of tracking information, sensor information, gesture information, and interactivity information to an XR server. The XR server can generate an XR scene based on the information received from the XR WTRU, for example. The XR server can rasterize an XR viewport, can perform XR pre-rendering, and can generate XR media, which can be encoded and delivered, for example, in a downlink (DL) transmission, to the XR WTRU. The XR WTRU can receive and decode the XR media. The XR WTRU can perform (e.g., recent) pose correction to address changes in pose and can render the XR viewport (e.g., the XR media in the XR viewport).

[0075] XR applications can have (e.g., strict) round-trip expectations (e.g., requirements) in order to provide a certain level of Quality of Experience (QoE) to the end user, such as, for example, a photon motion (e.g., end-to-end latency) of twenty milliseconds.

[0076] Rendering any of XR videos and XR scenes can be associated with offloading processing to more powerful computing units, for example, in case the WTRU does not include enough computing resources. Two examples are described herein, in which at least part of the processing can be done in an edge server to meet WTRU expectations (e.g., requirements).

[0077] Figure 2 Figures illustrating two examples 21, 22 of XR applications. In a first example 21, an optical see-through device can have limited computing and battery resources. In case the user runs an AR application, the AR glasses can communicate in any standalone way and via the WTRU to transmit its user pose (e.g., capture and) to an edge application server. In turn, the server application can process the video stream to render with respect to the received pose and can send the video stream back to the AR glasses (e.g., via the WTRU) to render on the glasses. In a second example 22, a video see-through device can transmit a first video stream to an edge application server, which can compute overlaid graphical information on top of the received video before sending the rendered video stream back to the VR headset (e.g., video see-through device).

[0078] Overview of 5G core API exposure for round-trip latency An application function (AF) can invoke an application programming interface (API) such as, for example, Npcf_PolicyAuthorization in order to provide a 5G core (5GC) with a round-trip (RT) latency (e.g., requirement, budget) for any of an uplink stream and a downlink stream. For example, the RT latency (e.g., requirement, budget) can indicate an allowable sum of a downlink delay and an uplink delay. The uplink delay and the downlink delay can be a delay between a WTRU and a network termination point, which can be referred to herein as N6 (such as, for example, a network element running a UPF). The 5GC can monitor the delay on the associated downlink and uplink paths and can adjust a packet delay budget on any of the downlink path and the uplink path to meet the RT latency (e.g., requirement, budget). For example, in case the delay on the uplink path is observed to be greater than the delay on the downlink path, the 5GC can provision a larger packet delay budget on the uplink path and a smaller packet delay budget on the downlink path if the sum of the two values does not exceed the RT latency (e.g., requirement, budget).

[0079] 5GC APIs can not be used to control end-to-end round-trip time latency (e.g., delay between WTRU and application server). 5GC can be unaware of the latency between N6 termination point and application server.

[0080] Pre-configured QoS settings can not be well suited for XR applications that can maintain QoE based on variable network usage. Processing and bandwidth for video streams produced by edge servers can be variable and can depend on any of user pose changes and complexity of rendered scenes. Underlying network can manage its resources based on pre-configured QoS flow resource allocation between application and network.

[0081] Real-time delay QoS / QoE expectations (e.g., requirements, targets) can not be (e.g., only) satisfied at the application level. End-user QoS / QoE expectations (e.g., requirements, targets) including high quality timely content, strict RTT latency (such as motion-to-photon) can not be satisfied by the application through post-processing by increasing buffers or through pose correction such as, for example, asychronous time warp. For example, real-time communication and protocols can be used to satisfy real-time expectations (e.g., requirements, targets). Not satisfying these real-time expectations (e.g., requirements, targets) can result in any of packet loss and poor QoE for end-user.

[0082] End-user QoE can be considered globally, rather than from independently configured flows: WTRU can interact with network (e.g., RAN / CN) to establish different independent uplink and downlink flows, for example, to allocate or adjust QoS for flows regarding any of uplink and downlink packet delay budget (PDB) settings. End-user QoE can depend on round-trip characteristics (e.g., requirements) including uplink flows transmitted by WTRU and downlink flows transmitted by application server.

[0083] Remote edge server can not interact (e.g., directly interact) with network (e.g., RAN / CN) to configure flows. XR applications can involve split rendering to meet strict device, application, and latency targets (e.g., requirements). For these settings, WTRU can interact with edge server to provide an application that can configure one or more forward and / or reverse flows. For example, WTRU can (e.g., only) interact with network via RAN and can not be able to measure how different flows affect QoE to enforce the above targets (e.g., requirements).

[0084] The network can not share network capabilities with the application. For example, an XR application can request network resources that can be shared and adjusted among different users and applications according to available resources that can be limited and scarce. The network can adjust resources for power saving purposes. The network can not know at a given time whether an application can expect more resources, or whether the network can have allocated resources that can not be used.

[0085] Stream Overview Different media data service streams are shown in Figure 2 For example, a forward media stream illustrated as “Stream 1” and a “reverse media stream” illustrated as “Stream 2” can be referred to as dependent or interdependent, based on the reverse media stream being built from input from the forward media stream.

[0086] A “forward” (e.g., data, media) stream can refer to a unidirectional stream (e.g., uplink in the example of Figure 2 ) with, for example, an acknowledgment (ack) in the other direction. A “reverse” (e.g., data, media) stream can refer to a unidirectional stream (e.g., downlink in the example of Figure 2 ) with, for example, an acknowledgment (ack) in the other direction.

[0087] As Figure 2 illustrated, the forward stream can be an applicable (e.g., media) stream, for example, including any of user pose, user interaction data. The reverse stream can be another applicable (e.g., media) stream, for example, including any of a rendered video stream and updated scene state for XR.

[0088] Either of the forward stream and the reverse stream can include any transport protocol connection (same or different). Either of the forward stream and the reverse stream can be transmitted over (e.g., based on) any of a reliable (e.g., Transmission Control Protocol (TCP), Quick User Datagram Protocol (UDP) Internet Connections (QUIC)) and an unreliable (e.g., UDP) transport.

[0089] In a first example, the forward stream can include a first Real-Time Protocol (RTP) stream and the reverse stream can include a second RTP stream.

[0090] In a second example, the forward stream can include an RTP stream and the reverse stream can include a TCP connection.

[0091] In a third example, the forward stream can include a first QUIC connection and the reverse stream can include a second QUIC connection.

[0092] Embodiments described herein can be applicable to interdependent application flows between more than two devices (e.g., network elements), such as, for example, between a WTRU, an edge network element, and a server network element. For clarity, embodiments are described herein by describing any processing performed after an edge server as being performed by the edge server. Embodiments described herein can be applicable to any other configuration in which edge processing can be distributed over more than one network element.

[0093] SUMMARY According to different embodiments described herein, a WTRU (e.g., a client application running in the WTRU) can A) configure a server-side application (e.g., a server-side application running in a (e.g., edge, cloud) network element) to measure interdependent applicable / network flow characteristics (e.g., metrics) and / or interdependent applicable QoE characteristics (e.g., metrics) for a roundtrip communication including sending and receiving information about interdependent forward and reverse flows, and B) expose relevant interdependent flow information and adjustments to a network layer.

[0094] In a first embodiment, a client WTRU application can communicate with a server to determine interdependent roundtrip flow characteristics according to the following steps: In a first step, the client WTRU application can send interdependent flow information to the server-side application in a forward flow.

[0095] In a second step, the server receiving interdependent flow information identified in the forward flow from the WTRU can trigger the server-side application to prepare a duplication to a reverse flow, where the interdependent flow information can include an interdependent flow marker information element (IE).

[0096] In a third step, the server-side application can receive a first application data unit from the forward flow, can output a second application data unit associated with the interdependent flow marker IE.

[0097] In a fourth step, the server-side application can process the second application data unit, and can instruct the server to duplicate the interdependent flow information in the reverse flow.

[0098] In a fifth step, receiving interdependent flow information identified in the reverse flow from the server can trigger the WTRU to process one or more interdependent flow roundtrip characteristics, where the interdependent flow information can include an interdependent flow marker IE.

[0099] In a sixth step, the WTRU can determine one or more interdependent flow round trip characteristics based on the received interdependent flow information.

[0100] In a first example, the interdependent flow information can include (e.g., indicate) an interdependent flow timestamp set by the WTRU when sending a forward flow packet. The WTRU can calculate an interdependent flow round trip time (RTT) characteristic based on a current timestamp value and the indicated interdependent flow timestamp (e.g., value).

[0101] In a second example, the interdependent flow information can include an interdependent flow marker IE. The WTRU can calculate one or more interdependent flow round trip time characteristics based on a measurement of a timestamp before sending the interdependent flow marker IE in a forward flow packet and a timestamp when the interdependent flow marker IE is received in a reverse flow packet.

[0102] In a second embodiment, a client WTRU application can interact with the network layer to expose any of QoS information and QoS adjustments based on any of (i) interdependent flow association, and (ii) interdependent flow information and adjustment exposure (based on WTRU assistance information and / or related forward / reverse flow markers and / or through any 5G core network API, e.g., via NEF (network exposure function) or PCF (policy control function).

[0103] Figure 3 is a diagram illustrating an example of QoS flow information carried in the transport layer. In one example, a client application and a server application can configure the transport layer to A) enable QOS measurements 31, 32, and B3) expose adjustments 33, 34 to the network layer. The client application can provide information 35 to the WTRU directly for B1) flow dependency association or B2 (e.g., as an alternative) to expose adjustments. In one example, the WTRU can forward the information to the RAN using, for example, the UEAssistanceInformation message as described in 3GPP TS 38.331, “NR; Radio Resource Control (RRC); Protocol specification (V17.0.0). In another example, (not represented in Figure 3 In order to expose adjustment information, the WTRU can forward the adjustment information to the core network based on core network messages, e.g., via any of NEF and PCF API messages.

[0104] In a 3GPP network embodiment, a WTRU can interact with a RAN base station to access a core network (CN). The WTRU can transmit forward stream packets in an uplink via the RAN and via a UPF in the CN to an application server. The application server can transmit reverse stream packets in a downlink via the UPF and via the RAN to the WTRU. For this embodiment, the WTRU can expose interdependent stream information and / or adjust in a forward stream to the RAN or via the RAN to the 3GPP CN, or in a reverse stream via the UPF to the 3GPP CN or via the 3GPP CN to the RAN, as described in Tables 1 and 2.

[0105] In a wireless LAN network embodiment, a WTRU can interact with a WLAN access point to access either of a 3GPP access network and a non-3GPP access network. The WTRU can transmit / receive forward / reverse stream packets via or from the WLAN access point. For this embodiment, the WTRU can expose QoS / QoE information and / or QoS / QoE adjustment to the WLAN access point or to the 3GPP CN or non-3GPP network via the 3GPP access network or via the non-3GPP access network.

[0106] Any of the UPF, non-3GPP access network, and any network element interconnecting the WTRU and the application server can be configured to receive a reverse stream marking from the application server for applying QoS / QoE adjustment rules.

[0107] Figure 4 FIG. 4 is a diagram illustrating an example method 400 for measuring and adjusting interdependent stream characteristics.

[0108] As shown at 410, any of a WTRU application, a server-side application, and a network can configure an exposure policy for the WTRU to expose interdependent stream characteristics.

[0109] As shown at 420, any of the WTRU application and the server-side application can expose interdependent stream information, e.g., based on (e.g., inserting) marking information.

[0110] As shown at 430, the WTRU can measure interdependent stream characteristics according to the interdependent stream information.

[0111] As shown at 440, the WTRU can determine network characteristic adjustments according to any of the interdependent stream characteristics measurement and policy settings.

[0112] As shown at 450, the WTRU can expose or communicate the network characteristic adjustments to the network.

[0113] The network can apply the change as shown at 460.

[0114] Embodiments described herein can be applicable to transport protocols capable of round trip communication including interdependent forward and reverse flows. The application layer can interact with the network layer to measure real-time network characteristic changes and adjust network characteristics with respect to allocated network resources based on the measured real-time network characteristic changes. Embodiments described herein can allow for improved quality of service based on real-time resource adjustments to reduce loss of packets. Embodiments described herein can allow the application to provide the network layer with means to detect unused resources that can be reallocated to other applications or deallocated, for example, to save energy.

[0115] Overview of QoE characteristics for measurement and adjustment Figure 5 is a diagram illustrating examples of different QoS / QoE characteristics for measurement and adjustment. Embodiments described herein can allow a WTRU to measure QoS / QoE characteristics illustrated with solid lines in real-time and estimate a delay to meet its round trip QoS expectations or provide a desired QoE experience. For example, the WTRU can measure any of a forward trip time 51, a reverse trip time 52, and a round trip time 53.

[0116] The RAN and / or CN can measure characteristics illustrated with dashed lines, such as, for example, any of an uplink trip delay, a downlink trip delay, a RAN portion of the uplink trip delay, and a CN portion of the uplink trip delay. For example, the WTRU can communicate with the RAN to set (e.g., adjust) an UL / DL delay budget for independent flows, or the WTRU can request an adjustment to the UL / DL delay to meet its application QoE.

[0117] Figure 6 is a diagram illustrating examples of different timing measurements for QoS / QoE characteristic measurement.

[0118] Embodiments are described herein with examples of packet delay (forward trip delay, reverse trip delay, round trip delay) as interdependent flow characteristics, where packet delay refers to a delay between transmission of a packet and reception of the packet. Embodiments described herein can be applicable to any other type of delay, such as, for example, packet delay variation, inter-packet delay, and inter-packet delay variation.

[0119] Throughout the embodiments described herein, the expressions "forward / reverse / round trip time" and "forward / reverse / round trip delay" can be used interchangeably to indicate a duration of a forward / reverse / round trip of a packet.

[0120] Table 1, first column, describes different interdependent flow timestamps. Table 1, second column, describes how different interdependent flow timestamps can be used for the measurement of related interdependent flow (e.g., delay). Table 1, third column, describes which entity can insert interdependent flow information (e.g., timestamps, any of time), while Table 1, fourth column, describes which entity can read interdependent flow information (e.g., timestamps and any of time). Table 1, fifth column, describes the operations performed by the WTRU and server to provide interdependent flow time (e.g., delay).

[0121] Table 1: Interdependent flow information timestamps and timing measurements.

[0122] Table 2, first column, describes the relationship between interdependent flow times (e.g., delay) as described in Table 1, second column. Table 2, second column, describes the related interdependent flow information / characteristics that can be derived from the delay shown. Table 2, third column, describes the source of the information, e.g., which entity (WTRU and / or server) can expose interdependent flow information, e.g., based on marking a transport packet, which is visible to the underlying network layer. Table 2, fourth column, describes the client (e.g., destination) that receives the interdependent flow information, and Table 2, fifth column, describes the operations used to expose the interdependent flow information between the source and client. Figure 5

[0123] Table 2, Exposure of interdependent flow information to the network.

[0124] Example of WTRU determining interdependent round trip flow characteristics (e.g., metrics) based on receiving information from the forward flow that is duplicated in the reverse flow The WTRU can determine one or more interdependent flow round trip characteristics based on sending and receiving interdependent flow information.

[0125] ​In one embodiment, the interdependent flow information can include (e.g., indicate) an interdependent flow round trip timestamp, which can be sent by the WTRU in the forward flow and can be copied by the server in the reverse flow. The interdependent flow round trip timestamp can be referred to herein as a forward timestamp. The WTRU can receive the forward timestamp sent and copied by the server and can determine (e.g., calculate) the interdependent round trip time (RTT) from the elapsed time between the receipt of the forward timestamp and the current timestamp value. This embodiment can be referred to as stateless, based on the WTRU not saving data.

[0126] In another embodiment, the interdependent flow information can include (e.g., indicate) an interdependent flow marker IE to be used as an identifier (e.g., marker) of the packet including the interdependent flow marker. The WTRU can determine (e.g., calculate) the interdependent flow round trip time characteristic based on measuring (e.g., logging) the time (e.g., timestamp) before the interdependent flow marker IE is sent in the forward flow packet and the time (e.g., timestamp) when the interdependent flow marker IE is received in the reverse flow packet. The marker (e.g., in the flow marker IE) can include any (e.g., random) value known and shared between the WTRU and the server, for example, in a setup phase. The WTRU can keep (e.g., store) the original timestamp value associated with the sent marker. This embodiment can be referred to as stateful, based on the WTRU saving data (e.g., between sending the packet in the forward flow and receiving the corresponding packet in the reverse flow).

[0127] In another embodiment, the interdependent flow information can include one or more different timestamps as described in Table 1, in accordance with the delay that the WTRU can calculate as described herein.

[0128] In a first example, the WTRU can set and insert a forward flow timestamp, or the same round trip timestamp as described above. The receipt of the forward flow timestamp (e.g., receiving the interdependent flow information from the WTRU indicating the WTRU request for the forward flow timestamp) can trigger the server to process the request. The interdependent flow information in the forward flow can include an "interdependent flow" forward flow timestamp IE marker. The server can determine (e.g., calculate) the forward flow delay from the (e.g., current) server time minus the forward flow timestamp value. The server can send a packet including information indicating the forward flow delay, for example, inserted into a dedicated field of the packet in the interdependent reverse flow. The delay can be an "interdependent flow" forward flow delay IE marker in the reverse flow.

[0129] In a second example, the WTRU can send information to the server indicating a request for a reverse stream timestamp. The information can include (e.g., indicate) a "Dependent Stream" reverse stream timestamp request IE to the server. Reception of the "Dependent Stream" reverse stream timestamp request IE can trigger the server to insert information indicating a reverse timestamp value into packets of the reverse stream. The server can insert a "Dependent Stream" reverse stream timestamp IE marker into the reverse stream belonging to the dependent stream. Based on reception of the "Dependent Stream" reverse stream timestamp IE marker, the WTRU can determine (e.g., calculate) the reverse stream delay as a function of the current WTRU time minus the received reverse timestamp value.

[0130] In one embodiment, the different delay calculations described herein can allow the WTRU to determine (e.g., calculate) the round trip delay of the dependent stream as a function of Figure 5 The illustrated server delay portion (e.g., contribution). In one example, the WTRU can send information to the server indicating a server delay contribution portion of the round trip delay of the dependent stream. The WTRU can send a server delay IE marker in the forward stream to carry the server delay value to the server.

[0131] In one embodiment, the WTRU can determine a frequency to obtain (e.g., calculate) the round trip characteristics of the dependent stream. The WTRU can send or update a dependent stream frequency IE (e.g., indicating a value of the dependent stream frequency) to the server. The server can use the frequency value to trigger reception of any other dependent stream information described herein.

[0132] In one embodiment, the WTRU and server application can configure a policy to communicate dependent stream information to the other side. The dependent stream information can be provided based on any of a (e.g., regular) sampling frequency basis, applicable data information, and (e.g., specific) header type or information in the received stream packets (either of the forward stream and the reverse stream).

[0133] In one embodiment, the dependent stream information can include packet number (e.g., count) information (which includes, for example, packet count / number continuation from the forward stream and the reverse stream) to allow the network to calculate the dependent stream timing described in Table 1.

[0134] In one embodiment, the dependent stream information can include a dependent stream marker IE value encoded, for example, with an algorithm. An example can include a transition pattern of a spin bit value from "0" to "1" or from "1" to "0". After (e.g., each) round trip, the transmitter can change the pattern or toggle the spin bit value.

[0135] Example of using RTP / RTCP interdependent stream time stamp marking for interdependent round trip delay measurement An example implementation is described herein based on receiving a time stamp in the RTP header of a reverse stream, which can be a copy or replication of a time stamp that has been sent in the RTP header in the forward stream.

[0136] For example, round trip QoS / QoE can be measured (e.g., determined) based on inserting QoE information into one or more RTP frames of the stream. The QoS / QoE information can not be inserted into every RTP frame of the stream.

[0137] Figure 7 is a diagram illustrating an example method for delay measurement based on any of Real-time Protocol (RTP) and Real-time Control Protocol (RTCP) marking time stamps.

[0138] Configuration phase As shown at 71, an application running between the WTRU and the server can establish two interdependent streams, such as, for example, a first (e.g., forward) stream (e.g., based on RTP for carrying pose information from the WTRU to the application server) and a second (e.g., reverse) stream (e.g., based on RTP for carrying XR rendered video from the application server to the WTRU).

[0139] As shown at 72, the WTRU (e.g., application) can send request information to the application server indicating a request to implement (e.g., enforce) a time stamp replication policy (e.g., rule), including a policy (e.g., rule) identifying a means of the interdependent stream time stamp IE in the forward stream, when and where to obtain the time stamp in the forward stream, and where to replicate the value of the interdependent stream time stamp IE in the reverse stream. The request information can include one or more parameters indicating any of one or more first forward stream parameters, one or more second forward stream parameters, and one or more action rule parameters.

[0140] The one or more first forward stream parameters can indicate any of an RTP header extension type and an RTP payload type including an interdependent stream time stamp IE field containing a current time stamp value (e.g., indicating a time at which an RTP packet has been transmitted in the forward stream) measured, for example, by the WTRU prior to (e.g., when transmitting) the forward stream packet. For example, the one or more first parameters can include a first (e.g., forward) stream identifier.

[0141] The one or more second reverse flow parameters can indicate any of an RTP header extension type and an RTP payload type that includes a Dependent Stream Timestamp IE field (e.g., to be) used to insert a previous (e.g., copied) timestamp value. For example, the one or more second parameters can include a second (e.g., reverse) stream identifier.

[0142] The one or more action rule parameters can indicate an action rule for instructing a reverse RTP transport layer (e.g., in an application server) to copy a timestamp according to any of the following examples.

[0143] In a first example, the action rule parameter can indicate mirroring a timestamp value of a received forward stream to (e.g., all of) the RTP packets of a reverse stream. For example, a hook can be created between a received timestamp memory and a transmitted timestamp memory.

[0144] In a second example, the action rule parameter can indicate sending back a timestamp in one or more first RTP packets of a corresponding dependent second stream. For example, a first (e.g., initial) RTP packet of a newly rendered pose stream.

[0145] In a third example, the action rule parameter can indicate sending back a timestamp in (e.g., all of) the RTP packets of a corresponding dependent second stream (e.g., all packets of a newly rendered pose stream).

[0146] In a fourth example, the action rule parameter can indicate sending back a timestamp in a number X of RTP packets after a new timestamp can have been received. X can be an integer configured (e.g., shared) between a WTRU and a server.

[0147] As shown at 73, the application server can send an acknowledgement information to the WTRU for acknowledging the request information, from which the Dependent Stream Timestamp IE can be received. For example, the application server can apply a policy rule in the reverse stream.

[0148] Measurement Phase As shown at 74, the WTRU can determine (e.g., either compute and derive) a current timestamp value from the system, and can write (e.g., insert) the timestamp value into a Dependent Stream Timestamp IE of an RTP / RTCP header of a packet of a forward stream, for example. For example, the WTRU can insert information (such as, for example, a specific header type value within the header) indicating that either the timestamp information and the Dependent Stream Marker IE can be sent, for example, to trigger a server action.

[0149] As shown at 75, the reception of any of the interdependent flow timestamp information, (e.g., specific) RTP header type, and (e.g., specific) interdependent flow marker IE can trigger the application server to read the timestamp value from the interdependent flow timestamp IE field of the RTP header of the received forward flow and can implement (e.g., activate) the corresponding policy rules established (e.g., indicated, requested by the WTRU) with the WTRU, such as, for example, (i) copying the timestamp value in the interdependent flow timestamp IE field of the RTP header in the backward flow, (ii) updating the RTP header type (e.g., if appropriate), and (iii) transmitting the packet in the backward flow.

[0150] As shown at 76, the reception of any of the interdependent flow timestamp IE, (e.g., specific) RTP header type, and (e.g., specific) interdependent flow marker IE can trigger the WTRU to read the timestamp value from the interdependent flow timestamp IE field of the RTP header of the backward flow.

[0151] As shown at 77, the WTRU can determine any of the round trip delay and round trip delay variation based on calculating a current round trip time and a previous round trip time based on comparing a currently received interdependent flow timestamp and a previously received interdependent flow timestamp.

[0152] In one embodiment, the RTCP message exchange between the WTRU and the application server can be used to provide the WTRU with the round trip QoS / QoE metrics. The RTCP messages can be sent asynchronously, where the RTP information can be sent (with the content information) synchronously. RTCP can be referred to as a control protocol used to provide QoS metrics for RTP. The RTCP messages can be sent less frequently than the RTP packets to reduce the number of control packets.

[0153] Example of exposing service flow dependencies by a WTRU to a network In one embodiment, the application program can interact with the network layer to expose to the network (RAN / CN) the dependencies between different flows belonging to the application program. For example, the application program can share information between the WTRU and the server to identify the interdependent flows. Sharing information related to the dependencies between different flows of the application program can be performed at the establishment of the application program flows, such as, for example, any of the RTCP, RTP, QUIC, and TCP flows in any of the forward and backward directions.

[0154] In one embodiment, the application can create associated information such as, for example, interdependent flow identifiers, which indicate that the interdependent flows can be associated (e.g., dependent). The associated information (e.g., interdependent flow identifiers) can be passed (e.g., exposed) to the network with information of the (e.g., each) flow identified as interdependent, such as, for example, the forward and reverse flows as described herein. The interdependent flow identifiers can include, for example, a multi-modal service identifier (multi-modal service ID).

[0155] In one embodiment, the application can expose information of the (e.g., each) flow identified as interdependent, such as, for example, the forward and reverse flows as described herein, to the network. The network can create and maintain interdependent flow information identifiers that are associated with the dependent flow information, and can return the interdependent flow identifiers to the application (e.g., send information indicating the interdependent flow identifiers back to the application). The application that exposes information to the network can be a WTRU application, which can invoke either of the PCF and NEF APIs. The application that exposes information to the network can be a server-side application, which can invoke either of the PCF and NEF APIs.

[0156] In one example, the application can expose interdependent flow identifiers for further network configuration in the same information exposure as when exposing interdependent flow measurements and / or interdependent flow adjustments of the interdependent flow information (e.g., characteristics) according to Table 1 and / or Table 2. For example, any of the interdependent flow information according to either of Table 1 and Table 2 can be exposed (e.g., transmitted) to the network (e.g., CN / RAN) and / or application server. For example, the interdependent flow identifiers can be used by the network to retrieve the corresponding interdependent flow information. For example, in the case of network update configuration, for example, when the network can update the delay budget related to at least a portion of the interdependent flows, the network can inform the application of the interdependent flow identifiers (e.g., send information indicating the interdependent flow identifiers).

[0157] In one embodiment, a WTRU (e.g., application) can obtain QoS flow identifiers that belong to the same or different PDU sessions, and can transmit information indicating the corresponding dependent QoS flow identifiers to the network (CN / RAN) with, for example, additional dependent (e.g., associated) information. The transmission to the network can be performed by sending information to, for example, an application server, which can then invoke either of the NEF and PCF APIs to send the information to the network.

[0158] In one embodiment, the network can create and maintain interdependent flow information identifiers that associate dependent QoS flow identifiers with additional dependency information, and can return the dependent flow identifiers to the WTRU (e.g., application). The WTRU (e.g., application) can pass (e.g., send) these dependent flow identifiers for further configuration of QoE / QoS dependency.

[0159] In one embodiment, the additional dependency information can include interdependent characteristics of global or different QoS rules according to any of the following examples.

[0160] In a first example, the additional dependency information can indicate the direction of dependency (e.g., forward / uplink for a first flow and reverse / downlink for a second flow). According to any of the embodiments described herein, the application between the WTRU and the server can be aware of and share interdependent flow information to identify forward and reverse flows.

[0161] In a second example, the additional dependency information can indicate QoS flow rules and associated QoS flow rule identifiers (QFI). As described herein, the application can interact with the network to expose interdependent flow information including, for example, determining the mapping of QoS flow rules including QFI to interdependent flows in forward or reverse directions.

[0162] In a third example, the additional dependency information can indicate the configuration of packet set filters used to identify packet flows. As described herein, the application can interact with the network to determine packet filters used to detect uplink and / or downlink interdependent flows. For example, in an RTP embodiment, the packet filters can include five-tuples containing RTP protocol information.

[0163] In a fourth example, the additional dependency information can indicate one or more interdependent round-trip QoS flow parameters including any of guaranteed maximum (minimum, maximum) bit rates associated with forward and / or reverse flows to satisfy one or more desired latency (e.g., delay). For example, considering a latency of 20 milliseconds for uplink and 30 milliseconds for downlink, the round-trip can be set to 50 milliseconds. The application can have, for example, latency expectations that do not exceed motion-to-photon timing for XR applications to achieve end-user acceptable QoE. Application QoS expectations can drive the network to configure interdependent round-trip QoS flow parameters.

[0164] Examples of WTRU and network configuration policies to expose interdependent flow information In one embodiment, the WTRU and / or network can arbitrarily configure, establish, and agree to expose interdependent flow information (e.g., characteristics) described herein, e.g., including any of round trip time, round trip delay adjustment, round trip delay budget variation, forward time, forward delay adjustment, forward delay budget variation, reverse time, reverse delay adjustment, and reverse delay budget variation according to Table 2.

[0165] Exposing interdependent flow information (e.g., characteristics) to the network (RAN / CN / UPF) can be used to adjust any of the uplink / forward trip delay (RAN part, CN part), downlink / reverse trip delay (RAN part, CN part), and round trip delay, which can include forward uplink and reverse downlink, enabling the network (RAN / CN / UPF) to determine and select adjustments in uplink, downlink, or both flows at a time to meet a target round trip delay.

[0166] In one embodiment, the WTRU and / or network can arbitrarily configure, establish, and agree to expose delay budgets for one or more measured interdependent flow delays (UL / DL / round trip) including any of the following examples.

[0167] In a first example, the delay budget can include any of a desired standard delay and a desired median delay budget.

[0168] In a second example, the delay budget can include one or more delay budget ranges (minimum, median, maximum).

[0169] In a third example, the delay budget can include one or more delay budget thresholds to trigger sending a message (lower critical limit, upper critical limit).

[0170] In a fourth example, the delay budget can include a communication pattern of sending assistance information and adjustments, such as a periodic pattern with, e.g., a sampling frequency and / or an aperiodic pattern associated with an event trigger (e.g., an aperiodic pattern associated with, e.g., a delay budget threshold and a current delay value).

[0171] In one embodiment, the WTRU and / or network can arbitrarily configure, establish, and agree to expose delay adjustments for one or more measured interdependent flow delays (UL / DL / round trip) including any of the following examples.

[0172] In a first example, the delay adjustment can indicate a delay adjustment reduction. The application can measure and expect or predict that the measured delay (UL / DL / round trip) can be reduced, e.g., to meet an end-to-end latency target.

[0173] In a second example, the delay adjustment can indicate a delay adjustment increase. The application can measure and expect or predict that the delay (UL / DL / round trip) can be relaxed, e.g., to indicate to the network to save bandwidth and / or energy.

[0174] In a third example, the delay adjustment can indicate a delay prediction, including any of a confidence estimate of the prediction and an expected timing of the prediction. The WTRU application can predict that the delay can increase based on an expected forward / reverse flow bandwidth change and / or based on a buffer / processing delay change.

[0175] In a fourth example, the delay adjustment can indicate any of a reached delay range and threshold (any of lower and upper bounds, any of a useless lower bound, a critical upper bound) In one embodiment, the WTRU and / or network can arbitrarily configure, establish and agree on a delay measurement method, e.g., based on any of the following measurement method parameters.

[0176] In a first example, the delay measurement method parameter can include a duration of the measurement.

[0177] In a second example, the delay measurement method parameter can include a type of the measurement (e.g., periodic, event triggered).

[0178] In a third example, the delay measurement method parameter can include a number of times to measure the delay and a reporting period. For example, the WTRU can observe that the delay can reach a lower bound limit or an upper bound limit for a duration and / or can measure that the delay can reach the limit multiple times. This parameter can allow to avoid measurement errors or peak variations that the application can have to cope with over time.

[0179] In a fourth example, the delay measurement method parameter can include a measurement statistical mode, indicating how the delay measurement can be performed with a corresponding parameter (e.g., any of a standard deviation, a mean, a median, a maximum).

[0180] In one embodiment, the WTRU and / or network can arbitrarily configure, establish and agree to expose a mutual dependence of the flow delay budget change (uplink / downlink / round trip) for one or more measurements, including (i) a standard deviation / change, (ii) a mean deviation / change, (iii) a median deviation / change, (iv) a minimum and maximum deviation / change, and (v) any of a probability distribution (Gaussian, normal) including a set of probability values.

[0181] In one embodiment, the RAN / CN can report to the WTRU an effective adjustment or adjustment feedback on the expected adjustment that the network can have applied to the WTRU-exposed interdependent flow characteristics. The feedback information can include an indication of the location where the adjustment can have been completed (RAN part / CN part). The feedback information can include any of a delay feedback for uplink / forward travel time adjustment, a delay feedback for downlink / reverse travel time adjustment (RAN part / CN part), and a round-trip delay adjustment that is the sum of the forward / uplink and reverse / downlink adjustments.

[0182] In one embodiment, the WTRU can send a WTRU assistance message (e.g., as described in clause § 5.7.4 “NR; Radio Resource Control (RRC); Protocol specification” (V17.0.0) of 3GPP TS 38.331) to expose the interdependent flow information, characteristics, or adjustments. For example, the WTRU assistance message can include any information to identify the interdependent flow according to any embodiment described herein.

[0183] In one embodiment, the WTRU and / or network can arbitrarily configure, establish, and agree to expose the interdependent flow information (e.g., characteristics) described herein (e.g., including any parameter described in Table 2, second column) by marking packets (e.g., inserting marking information into packets) in the forward flow and / or reverse flow. An application can write (e.g., insert, include) one or more network layer visible (e.g., accessible) markings (of any network element responsible for handling the forward flow and / or reverse flow). Examples of packet marking information can include one or more information elements in the flow according to any of the following examples.

[0184] In a first example, the marking information can be associated with a (e.g., specific, updated) protocol header type value, indicating that the packet can include the marking information.

[0185] In a second example, the marking information can be associated with a (e.g., specific, updated) bit field position where a (e.g., specific, updated) bit field value of the marking information can be read.

[0186] In a third example, the marking information can be associated with a (e.g., new) protocol header extension type, indicating that the packet can include the marking information.

[0187] For example, according to any of the embodiments described herein, the presence of flow marking information associated with (e.g., indicative of a request for) any of a delay adjustment and a budget change can trigger (e.g., indicate a request to) the network to read one or more adjustment delay / change marking values from the application. For example, the presence of an associated interdependent flow information identifier or information element marker can trigger (e.g., indicate a request to) the network to read one or more adjustment delay / change marking values from the application.

[0188] In one embodiment, any of the round-trip, forward, and reverse delay adjustments (and / or budget changes) as described herein can be associated with one or more (e.g., different) QoS rules.

[0189] In a first example, the QoS rules can include a QoS flow rule and an associated QoS flow rule identifier (QFI). The application can interact with the network to expose interdependent flow information including, for example, a determination of a mapping of the QoS flow rule including the QFI to an interdependent flow in a forward direction and / or a reverse direction.

[0190] In a second example, the QoS rules can include a configuration of a packet set filter to identify a packet flow marker. The application can interact with the network to determine one or more packet filters to be used to detect (e.g., determine) an uplink and / or downlink interdependent delay adjustment (e.g., and / or budget change). The packet filter can include first (e.g., five-tuple) information including protocol information (e.g., RTP) and second (e.g., additional) information to detect (e.g., indicate) a delay adjustment (e.g., and / or budget change) from the application.

[0191] In a third example, the QoS rules can include one or more interdependent round-trip QoS flow parameters including any of a guaranteed maximum range (minimum, maximum) bit rate associated with a forward flow and / or a reverse flow to satisfy one or more desired round-trip / forward / reverse delay budgets. For example, considering a latency of 20 milliseconds for the uplink and 30 milliseconds for the downlink, a round-trip delay can be set to 50 milliseconds. The application can have, for example, a latency expectation of no more than the motion-to-photon timing for an XR application to achieve an end user acceptable QoE.

[0192] Examples of QoE delay adjustment exposure in forward / reverse RTP flow marking Figure 8is a diagram illustrating an example method for QoS / QoE delay adjustment exposure in forward / reverse RTP flow marking. In one example, a WTRU can transmit forward / reverse flow marking to expose (as described herein) flow information and adjustments for an uplink forward flow to a RAN and / or for a downlink reverse flow to a UPF.

[0193] As shown by the application and network policy exposure configuration at 810, a WTRU and server application can identify a forward (e.g., uplink) flow and a reverse (e.g., downlink) flow that are interdependent, and can configure policies for marking the forward and reverse flows according to any of the embodiments described herein. The WTRU and server can be configured to insert and / or replicate selected QoS / QoE information and adjustments.

[0194] The WTRU and / or network can arbitrarily configure, establish, and agree to expose interdependent flow information (e.g., characteristics) according to any of the following examples, for example, for any of the following: (i) detecting (e.g., indicating) interdependent flow information or information element marking, and detecting (e.g., indicating) delay adjustment / variation marking in a forward flow and / or reverse interdependent flow.

[0195] In a first example, the exposed interdependent flow information can include a marker indicating an interdependent flow identifier. In an RTP example, the marker can include an RTP header type (e.g., interdependent flow information identifier) to trigger.

[0196] In a second example, the exposed interdependent flow information can include a forward (e.g., uplink) flow marker. In an RTP example, the forward flow marker can include an RTP header type to trigger any of the delay adjustment requests according to Table 2.

[0197] In a third example, the exposed interdependent flow information can include a reverse (e.g., downlink) flow marker. In an RTP example, the reverse flow marker can include an RTP header type to trigger any of the delay adjustment requests according to Table 2.

[0198] As shown at 820, the WTRU and / or server can expose interdependent flow information (e.g., based on marker information).

[0199] As shown by the delay measurement at 830, the WTRU can measure one or more interdependent flow characteristics (e.g., QoE / QoS delay) according to any of the embodiments described herein.

[0200] As shown by the delay adjustment at 840, the WTRU can determine to request (increment / decrement) a delay budget at the RAN side to the network and / or at the CN side to the UPF, according to the (e.g., applicable) measurements and the policy settings shown at 810.

[0201] As shown by the network adjustment flag at 850, the WTRU can insert a flag information into a packet in the forward stream, where the flag information can indicate any of a delay adjustment request and a budget change request.

[0202] In a first example, the flag information can indicate a request to adjust a forward link parameter. For RTP, inserting the flag information can include inserting an RTP header type, e.g., to indicate a forward delay budget adjustment request to the network. For RTP, inserting the flag information can further include writing (e.g., inserting) a forward (e.g., uplink) delay adjustment value in any of a corresponding RTP header field and bit field.

[0203] In a second example, the flag information can indicate a request to adjust a reverse link (e.g., downlink) parameter. As described in Table 2, the WTRU can first communicate (e.g., transmit information indicating) any of the delay adjustment(s) and the budget change(s) to the server, e.g., by flagging the forward stream (e.g., inserting the flag information into a packet of the forward stream) to flag the adjustment in the reverse stream. According to any of the embodiments described herein, the server can replicate the interdependent stream adjustments received in the forward (e.g., uplink) stream intended for the reverse stream. For RTP, inserting the flag information can include inserting an RTP header type (e.g., to indicate a reverse delay budget adjustment request). For RTP, inserting the flag information can further include writing a received forward (e.g., downlink) adjustment value in a corresponding RTP header field and bit field of the reverse stream.

[0204] As shown by the network policy implementation at 860, any of an uplink policy and a downlink policy can be implemented. For example, for uplink policy implementation, the RAN can be triggered by the reception of a specific header type of a forward delay budget request. The RAN can obtain the requested uplink policy adjustment, and can implement the received requested uplink policy adjustment. For example, for downlink policy implementation, the UPF can be triggered by the reception of a specific header type of a reverse delay budget request. The UPF can obtain the requested downlink policy adjustment, and can implement the received requested downlink policy adjustment.

[0205] Example method including delay measurement and adjustment Figure 9is a diagram illustrating an example method for delay measurement and adjustment of interdependent flows. According to any of the embodiments described herein, the measurement can be performed based on, for example, a marked timestamp packet inside the RTP. According to any of the embodiments described herein, the adjustment can be performed by the network based on any of a forward flow mark exposure and a reverse flow mark exposure.

[0206] As shown at 910, the WTRU and network can interact to configure a delay exposure policy, for example, including any of a delay budget and a delay budget change threshold.

[0207] As shown at 920, the WTRU can measure one or more interdependent flow characteristics, such as, for example, a round trip delay.

[0208] As shown at 930, the WTRU can send a packet in the forward flow including any of measurement request information and timestamp information.

[0209] As shown at 931, the server can trigger a measurement request.

[0210] As shown at 932, the server can replicate and / or insert the timestamp information into the reverse flow.

[0211] As shown at 935, (for example, any of the WTRU and server) can determine that the measured interdependent flow characteristic (for example, round trip delay) can not satisfy a QoS (for example, delay) budget. For example, the measured interdependent flow characteristic (for example, round trip delay) can have reached (and / or be greater than) a threshold.

[0212] As shown at 940, the WTRU can send QoS (for example, delay) adjustment information to the network.

[0213] As shown at 941, the network can trigger a QoS (for example, delay) adjustment.

[0214] As shown at 942, the network can adjust QoS (for example, delay) characteristic(s).

[0215] As shown at 950, the server can trigger a QoS (for example, delay) adjustment of the reverse flow, for example, based on receiving a request from the forward flow.

[0216] As shown at 951, the server can replicate a request (for example, received from the WTRU) to adjust the reverse flow.

[0217] As shown at 952, the network can trigger a delay adjustment in the reverse flow (for example, send adjustment information indicating a delay adjustment in the reverse flow).

[0218] As shown at 953, the network can adjust the QoS (e.g., latency) characteristic(s).

[0219] Examples of QoS / QoE measurements that trigger core network policy adjustment requests In one example, an application server (such as, for example, an AF network element) can receive a message from a WTRU indicating a round-trip latency measurement. For example, the application server can determine (e.g., calculate) a dependent flow round-trip delay measurement based on a message received from the WTRU (e.g., a hosted application).

[0220] The application server can determine the dependent flow round-trip delay measurement. The application server can determine that the total round-trip time can not satisfy a delay budget condition (such as, for example, exceeding an allowable amount of delay) related to a configured delay budget.

[0221] In one example, the application server can determine that the round-trip time of the dependent flow measurement can not allow a desired quality of experience to be maintained, or conversely, for example, can not strictly require the round-trip time of the dependent flow measurement while allowing the desired quality of experience to be maintained. Based on this determination, the application server can invoke a 5GC API (such as, for example, Nnef_AFsessionWithQoS as described in 3GPP TS 23.501, “System Architecture for the 5G System (5GS)” (V18.0.0)) to adjust the (e.g., allowable) dependent flow round-trip delay that the 5GC can assume (e.g., is expected from the 5GC). For example, in the case that the application server determines that the measured dependent flow round-trip delay exceeds a limit of two milliseconds, the application server can invoke the API to indicate to the network that the (e.g., assumed) dependent flow round-trip delay can be reduced by two milliseconds. The 5GC can determine how to adjust the packet delay budget on either of the uplink path and the downlink path. In another example, in the case that the application server determines that the measured dependent flow round-trip delay satisfies a budget condition (e.g., within a tolerance range and / or below a threshold), the application server can invoke a 5GC API (e.g., Nnef_AFsessionWithQoS) to increase the allowable dependent flow round-trip delay that the 5GC can assume (e.g., is expected from the 5GC). This can allow the 5G system to have more flexibility in how network resources are used.

[0222] Figure 10is a diagram illustrating an example method 1000 for delay measurement and adjustment of interdependent flows. The method 1000 can be implemented in a WTRU. The WTRU can include circuitry including, for example, any of a processor, a memory, a transmitter, and a receiver (e.g., transceiver) operably coupled to the processor to perform the method 1000. In one example, the WTRU can send request information to a first network element, the request information indicating a request to perform a replication policy of information associated with a first flow and a second flow. In various embodiments, the first flow and the second flow can be interdependent. In one example, the WTRU can receive acknowledgement information from the first network element to acknowledge the request information. As shown at 1010, the WTRU can send first information to the first network element in the first flow. As shown at 1020, the WTRU can receive replicated first information from the second flow from the first network element. In various embodiments, the first flow and the second flow can be interdependent, can be associated with an application. As shown at 1030, the WTRU can determine one or more interdependent flow characteristics associated with the first flow and the second flow based on the first information and the replicated first information. In various embodiments, the WTRU can determine that the interdependent flow characteristics can satisfy, for example, a QoS budget condition associated with the application. As shown at 1050, the WTRU can send second information indicating the one or more interdependent flow characteristics (e.g., associated with the one or more interdependent flow characteristics) to, for example, a second network element, for example, based on determining that the interdependent flow characteristics can satisfy the QoS budget condition.

[0223] In various embodiments, the request information can indicate any of one or more first flow parameters, one or more second flow parameters, and one or more action rule parameters.

[0224] In various embodiments, the first information can include timestamp information indicating a time at which a first packet including the first information has been sent.

[0225] In various embodiments, the first information can include interdependent flow marker information identifying the first packet in which the first information has been included.

[0226] In various embodiments, the one or more interdependent flow characteristics can include any of a forward trip delay, a reverse trip delay, and a round trip delay.

[0227] In various embodiments, the second information can be sent to a second network element (e.g., a second network element in any of a RAN and a core network), which can be different from the first network element.

[0228] In various embodiments, the second network element can be the first network element. In various embodiments, the second information can be inserted into a second packet of the first flow directed to the first network element, where the second information can be intercepted by a third network element responsible for processing either of the first flow and the second flow between the WTRU and the first network element.

[0229] In various embodiments, the second information can include association information indicating that the first flow can be associated with the second flow.

[0230] In various embodiments, the second information can further indicate one or more interdependent flow characteristics (e.g., determined).

[0231] In various embodiments, the second information can further indicate a request for network policy adjustment associated with either of the first flow and the second flow.

[0232] In various embodiments, the WTRU can determine that the interdependent flow characteristics can satisfy a QoS budget condition.

[0233] In various embodiments, the second information can be transmitted (e.g., to the second network element) based on the interdependent flow characteristics satisfying the QoS budget condition.

[0234] In various embodiments, the requested network policy adjustment can be associated with a first latency adjustment to the first flow.

[0235] In various embodiments, the requested network policy adjustment can be associated with a second latency adjustment to the second flow.

[0236] In various embodiments, the interdependent flow characteristics can include latency. In various embodiments, the interdependent flow characteristics can satisfy a QoS budget condition (e.g., associated with an application) in the event that the latency is above a first threshold. In various embodiments, the requested network policy adjustment can include reducing latency in either of the first flow and the second flow.

[0237] In various embodiments, the interdependent flow characteristics can include latency. In various embodiments, the interdependent flow characteristics can satisfy a QoS budget condition (e.g., associated with an application) in the event that the latency is below a second threshold. In various embodiments, the requested network policy adjustment can include not strictly requiring (e.g., reducing, decreasing) latency in either of the first flow and the second flow.

[0238] Any features, variations, or embodiments described for the method are compatible with apparatus devices including means for processing the disclosed method, with devices including a processor, a transmitter and a receiver operatively coupled to the processor, configured to process the disclosed method, with computer program products including program code instructions, and with non-transitory computer-readable storage media storing program instructions.

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

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

[0241] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" can refer to any one of a snapshot, a single image, and / or multiple images displayed on a time basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE," the term "remote," and / or the term "head-mounted display" and its abbreviation "HMD" can mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of the various embodiments of a WTRU; (iii) a device with wireless and / or wired capabilities (e.g., tetherable), particularly configured with some or all of the structure and functions of a WTRU; (iii) a device with wireless and / or wired capabilities configured with fewer than all the structure and functions of a WTRU; or (iv) such. References herein Figures 1A-1DDetails of example WTRUs that can be representative of any of the WTRUs described herein are provided. As another example, the various embodiments disclosed above and below are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be utilized, and some or all of the present disclosure and various disclosed embodiments can be modified accordingly without undue experimentation. Examples of such other devices can include drones or other devices configured to stream information to provide an adaptive reality experience.

[0242] Furthermore, the methods provided herein can be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (optical, electrical or the like) and computer- readable storage media. Examples of computer-readable storage media include, but are not limited to, removable floppy disks, RAM disks, solid state RAM, solid state ROM, or the like. The processor in association with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0243] Variations of the methods, apparatus and systems provided above are possible without departing from the scope of the present disclosure. In light of the various embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the appended claims. For example, the embodiments provided herein include handheld devices that can include or be used with any suitable voltage source, such as a battery or the like, that provides any suitable voltage.

[0244] Furthermore, in the embodiments provided above, reference is made to processing platforms, computing systems, controllers, and other devices that include processors. These devices can include at least one central processing unit ("CPU") and 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 can be performed by the various CPUs and memories. Such acts and operations or instructions can be referred to as being "executed," "computer executed" or "CPU executed."

[0245] Those of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system representations, such as a motherboard or separate processors with electrical communication, represent data bits that can be maintained in a storage location, such as a memory location, registered on a high-speed clock, and that can be retrieved by the CPU or other processor as needed. The

[0246] Data bits can also be maintained on computer-readable media 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 can include cooperating or interconnected computer-readable media, which exist exclusively on the processing system, or distributed among multiple interconnected processing systems, which can be located locally or remotely from the processing system. It is understood that the embodiments are not limited to the above-mentioned memory, and that other platforms and memory can support the provided methods.

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

[0248] There is little distinction between the implementation of various aspects of the system in terms of hardware and software implementations. The use of hardware or software is generally (but not always, in that in certain contexts the choice between hardware and software can become significant) a design choice representing cost vs. efficiency tradeoffs. There can be various vehicles by which processes and / or systems and / or other technologies described herein can be effected (e.g., hardware, software, and / or firmware), and the preferred vehicle can vary with the context in which the processes and / or systems and / or other technologies are deployed. For example, if efficiency and / or speed of the processes are a priority, then an implementation that consists essentially of hardware and / or firmware can be preferred. On the other hand, if flexibility is the priority, then an implementation that consists essentially of software can be preferred. Alternatively, combinations of hardware, software, and / or firmware can be selected that offer a balance between the techniques. The specification has thus used functional and / or procedural language that can be translated to illustrative

[0249] The foregoing detailed description has set forth various embodiments of the devices and / or processes via the use of block diagrams, flowcharts, and / or examples. Insofar as such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, it will be understood by those within the art that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented, individually and / or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In one embodiment, several portions of the subject matter described herein can be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and / or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a CD, DVDs, digital tape, computer memory, etc., and 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.).

[0250] Those skilled in the art will recognize that the description of apparatus and / or process herein described is typically made in the context of the apparatus and / or process being integrated into a data processing system, in the manner described herein. That is, at least a portion of the apparatus and / or process described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system can include one or more of the following: a system unit housing, a video display device, 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 from position sensors and / or velocity sensors and control motors to move and / or adjust components and / or quantities). A typical data processing system can be implemented utilizing any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0251] The subject matter described herein sometimes illustrates different components included in, or connected with, different other components. It is to be understood that the depicted architectures are merely examples, and that in fact many other architectures can implement the same functions. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermediate components. Likewise, any two components so associated can 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 can also be viewed as being "operably couplable", to each other to achieve the desired functionality. Specific examples of 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.

[0252] With respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate the plural and / or singular terms to a singular and / or plural form, as appropriate, in context and / or application. For the sake of clarity, various singular / plural arrangements can be set forth herein.

[0253] Those skilled in the art will understand that, generally, the terminology used herein, particularly in the appended claims (e.g., the body of the appended claims), is generally intended as “open” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “at least having,” the term “comprising” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will further understand that if the intention is to introduce a specific quantity recited in the claim, such intention will be explicitly stated in the claim, and if such a statement is not made, such intention does not exist. For example, the term “single” or similar language may be used where only one item is intended. To aid understanding, the appended claims and / or the description herein may include the use of introductory phrases “at least one” and “one or more” to introduce the recitation of the claim. However, the use of such phrases should not be construed as implying that the introduction of a claim recount by the indefinite article "a" or "an" limits any particular claim that includes such an introduction to include only one such embodiment, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "an" or "one" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce a claim recount. Furthermore, even if the specific number of recounts in an introduced claim is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as indicating at least a number of recounts (e.g., the simple statement "two recounts" without other modifiers indicates at least two recounts, or two or more recounts). Furthermore, in cases involving conventions such as "at least one of A, B, and C," this structure is generally intended to enable those skilled in the art to understand the convention (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In cases involving conventions such as "at least one of A, B, or C," this structure is generally intended to enable those skilled in the art to understand the convention (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will further understand that any separate words and / or phrases that actually represent two or more optional terms, whether in the specification, claims, or drawings, should be understood to be intended to include the possibility of including one, any, or both terms. For example, the phrase "A or B" will be understood to include the possibility of including "A" or "B" or "A and B."Also, as used herein, the term "any" followed by a listing of a plurality of items and / or categories of items, is intended to refer to "any of the individual items and / or categories of items," "any of the individual items and / or categories of items" used in any combination, and / or "any combination of individual items and / or categories of items." In addition, as used herein, the term "set" is intended to include any number of items, including zero. Further, as used herein, the term "number" is intended to include any number, including zero. And as used herein, the term "multi" is intended to be synonymous with "multiple," as in "multiple copies."

[0254] Further, where a feature or aspect of the disclosure is described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0255] As those skilled in the art will appreciate, all ranges disclosed herein are also intended to encompass any and all possible sub-ranges and combinations of sub-ranges thereof, for any and all purposes. Any listed range can be easily reduced to, and / or combined to form, a smaller range. As a non-limiting example, a range of "1 to 10" can be easily reduced to, and / or combined, to form a range of "2 to 5." Any listed range can be easily reduced to, and / or combined, to form a smaller range that is next-to-smallest, next-to-larger, "exact," or possibly useful in other ways. All ranges disclosed and taught herein are "open" ranges in that the end points are not included. All languages suggesting the inclusion of only the end points shall be interpreted to only include the end points. All language, such as "up to," "at or up to," and the like, includes the end point that is in range. Finally, all ranges are inclusive of the endpoints, unless expressly indicated otherwise.

[0256] Also, the claims should not be read to require the orderly recitation of elements in any particular order unless such order is explicitly recited in the claim. Further, the use of terms such as "first," "second," etc., are used to identify elements whose order cannot otherwise be ascertained based on the context in which the terms are used, unless such order is explicitly recited in the claim. or means-plus-function claim format, and are not to be interpreted to require or enable means-plus-function or step-plus-function claims, unless such claims are explicitly recited.

Claims

1. A wireless transmit / receive unit (WTRU) comprising circuitry configured to: A request message is sent to a first network element, the request message indicating a request to execute a replication strategy for information associated with the first and second streams, wherein... The first stream and the second stream are interdependent; Receive confirmation information from the first network element to confirm the request information; Send first information to the first network element in the first stream; Receive first information copied from the second stream from the first network element; Based on the first information and the copied first information, determine one or more interdependent flow characteristics associated with the first flow and the second flow; as well as Send second information to the second network element indicating the characteristics of the one or more interdependent flows.

2. The WTRU according to claim 1, wherein, The request information indicates any one of one or more first-stream parameters, one or more second-stream parameters, and one or more action rule parameters.

3. The WTRU according to any one of claims 1 to 2, wherein, The first information includes timestamp information, which indicates the time when the first packet including the first information was sent.

4. The WTRU according to any one of claims 1 to 2, wherein, The first information includes interdependent flow tag information, wherein the interdependent flow tag information identifies a first group that includes the first information.

5. The WTRU according to any one of claims 1 to 4, wherein, The one or more interdependent flow characteristics include any one of forward travel delay, reverse travel delay, and round-trip travel delay.

6. The WTRU according to any one of claims 1 to 5, wherein, The second network element is different from the first network element.

7. The WTRU according to any one of claims 1 to 5, wherein, The second network element is the first network element, wherein the circuit configured to send the second information includes circuitry configured to insert the second information into a second packet of a first stream directed to the first network element, and wherein the second information is to be intercepted by a third network element responsible for processing either the first stream or the second stream between the WTRU and the first network element.

8. The WTRU according to any one of claims 1 to 7, wherein, The second information includes association information indicating that the first stream is associated with the second stream.

9. The WTRU according to any one of claims 1 to 8, wherein, The second information further indicates the one or more interdependent flow characteristics.

10. The WTRU according to any one of claims 1 to 9, wherein, The second information further indicates a request for network policy adjustment associated with either the first flow or the second flow.

11. The WTRU according to any one of claims 1 to 10, wherein, The circuit is configured to determine whether interdependent flow characteristics satisfy QoS budget conditions.

12. The WTRU according to claim 11, wherein, The circuitry configured to send the second information includes circuitry configured to send the second information based on interdependent flow characteristics that satisfy the QoS budget conditions.

13. The WTRU according to any one of claims 10 to 12, wherein, The requested network policy adjustment is associated with a first latency adjustment for the first stream.

14. The WTRU according to any one of claims 10 to 13, wherein, The requested network policy adjustment is associated with a second delay adjustment for the second stream.

15. The WTRU according to any one of claims 11 to 14, wherein, The interdependent flow characteristics include latency, wherein the interdependent flow characteristics satisfy the QoS budget condition when the latency is higher than a first threshold, and wherein the requested network policy adjustment includes reducing the latency in either the first flow or the second flow.

16. The WTRU according to any one of claims 11 to 14, wherein, The interdependent flow characteristics include latency, wherein the interdependent flow characteristics satisfy the QoS budget condition when the latency is below a second threshold, and wherein the requested network policy adjustment includes not strictly requiring latency in either the first flow or the second flow.

17. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: A request message is sent to a first network element, the request message indicating a request to execute a replication strategy for information associated with a first stream and a second stream, wherein the first stream and the second stream are interdependent; Receive confirmation information from the first network element to confirm the request information; Send first information to the first network element in the first stream; Receive first information copied from the second stream from the first network element; Based on the first information and the replicated first information, determine one or more interdependent flow characteristics associated with the first flow and the second flow; and Send second information to the second network element indicating the characteristics of the one or more interdependent flows.

18. The method according to claim 17, wherein, The request information indicates any one of one or more first-stream parameters, one or more second-stream parameters, and one or more action rule parameters.

19. The method according to any one of claims 17 to 18, wherein, The first information includes timestamp information, which indicates the time when the first packet including the first information was sent.

20. The method according to any one of claims 17 to 18, wherein, The first information includes interdependent flow tag information, wherein the interdependent flow tag information identifies a first group that includes the first information.

Images