Methods, architectures, apparatus, and systems for measuring and adjusting interdependent flow characteristics

Abstract

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

Description

Technical Field

[0001] Cross - Reference to Related Applications

[0001] This application claims the benefit of U.S. Patent Application No. 63 / 453,809, filed Mar. 22, 2023, which is hereby incorporated by reference in its entirety.

[0002] Technical Field

[0002] This disclosure generally relates to the fields of communication, software, and coding, including methods, architectures, devices, and systems, for example, for measuring and adjusting interdependent flow characteristics.

Background Art

[0003] Background

[0003] Extended Reality (XR) can include, for example, either Augmented Reality (AR) or Virtual Reality (VR). For example, in XR services and applications such as interactive AR or VR, a Wireless Transmit / Receive Unit (WTRU) can interact with an XR server running on an edge computing network element to offload computationally intensive tasks such as video rendering or collision prevention calculations. The embodiments described herein are designed with the above in mind.

Summary of the Invention

[0004] Summary

[0004] Methods, architectures, apparatus and systems for measuring and tuning interdependent flow characteristics are described herein. In one embodiment, a WTRU is described herein that includes, for example, a circuit including a processor, memory operably coupled to the processor, a transmitter and a receiver (e.g., a transceiver). The circuit may be configured to transmit request information to a first network element indicating a request to enforce a replication policy of information associated with a first flow and a second flow, and the first flow and the second flow may be interdependent. The circuit may be configured to receive acknowledgment information from the first network element to acknowledge the request information. The circuit may be configured to transmit first information in the first flow to a first network element and to receive replicated first information from the second flow from the first network element. In various embodiments, the first flow and the second flow may be interdependent and associated with an application. The circuit may be configured to 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. For example, the circuit may be configured to determine whether an interdependent flow characteristic can satisfy, for example, a QoS budget condition associated with an application. Based on the determination that an interdependent flow characteristic can satisfy a QoS budget condition, the circuit may be configured to transmit, for example, second information associated with one or more interdependent flow characteristics to a second network element.

[0005]

[0005] In one embodiment, the method may be implemented in a WTRU. The method may include sending request information to a first network element indicating a request to enforce a replication policy for information associated with a first flow and a second flow, the first flow and the second flow may be interdependent. The method may include receiving acknowledgment information from the first network element to acknowledge the request information. The method may include sending first information in the first flow to a first network element and receiving replicated first information from the second flow from the first network element. In various embodiments, the first flow and the second flow may be interdependent and associated with an application. The method may 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 may further include determining whether the interdependent flow characteristics can satisfy, for example, a QoS budget condition associated with an application. The method may further include, for example, transmitting second information associated with one or more interdependent flow characteristics to a second network element based on a determination that the interdependent flow characteristics can satisfy QoS budget conditions.

[0006] Brief explanation of the drawing

[0006] A more detailed understanding can be obtained from the following detailed description, given as an example, in conjunction with the drawings attached to this specification. The figures in such drawings, as well as the detailed description, are examples. Therefore, the figures (Fig.) and detailed description should not be considered limiting, and other equally valid examples are possible and may exist. Furthermore, similar reference numbers ("References") in the figures indicate similar elements. [Brief explanation of the drawing]

[0007] [Figure 1A]

[0007] This is a system diagram showing an exemplary communication system. [Figure 1B]

[0008] Figure 1A is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system illustrated. [Figure 1C]

[0009] Figure 1A is a system diagram showing exemplary radio access networks (RANs) and exemplary core networks (CNs) that may be used within the communication system illustrated. [Figure 1D]

[0010] This is a system diagram showing further exemplary RANs and further exemplary CNs that may be used within the communication system illustrated in Figure 1A. [Figure 2]

[0011] This figure shows two examples of XR applications. [Figure 3]

[0012] This figure shows an example of quality of service (QoS) flow information transmitted at the transport layer. [Figure 4]

[0013] This figure shows an exemplary method for measuring and adjusting interdependent flow characteristics. [Figure 5]

[0014] This figure shows examples of different QoS / QoE characteristics for measurement and adjustment. [Figure 6]

[0015] This figure shows an example of different timing measurements for QoS / QoE characteristic measurement. [Figure 7]

[0016] This figure illustrates an exemplary method of delay measurement based on either Real-Time Protocol (RTP) or Real-Time Control Protocol (RTCP) marked timestamps. [Figure 8]

[0017] This figure illustrates an exemplary method for publishing QoS / QoE delay adjustments in forward / reverse RTP flow marks. [Figure 9]

[0018] This figure shows an exemplary method for delay measurement and adjustment for interdependent flows. [Figure 10]

[0019] This figure shows another exemplary method for delay measurement and adjustment for interdependent flows. [Modes for carrying out the invention]

[0008] Detailed explanation

[0020] The following description includes some specific details to provide a detailed understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be implemented without some or all of the specific details described herein. In other examples, well-known methods, procedures, components and circuits are not described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be implemented in place of or in combination with embodiments and other examples described, disclosed or otherwise explicitly, implicitly and / or essentially provided herein (collectively, “provided”). Various embodiments are described and / or claimed herein in which an apparatus, system, device, etc. and / or any element thereof implements an operating process, algorithm, function, etc. and / or any part thereof, but it should be understood that any embodiment described and / or claimed herein assumes that the any apparatus, system, device, etc. and / or any element thereof is configured to implement any operation, process, algorithm, function, etc. and / or any part thereof.

[0009]

[0021] Exemplary communication system

[0022] The methods, apparatus, and systems provided herein are well suited to communications, including both wired and wireless networks. Outlines of various types of wireless devices and infrastructure are provided with respect to Figures 1A to 1D, and various elements of a network may utilize, implement, be arranged in accordance with, and / or adapt and / or configure for that purpose the methods, apparatus, and systems provided herein.

[0010]

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

[0011]

[0024] As shown in FIG. 1A, the communication system 100 may 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 should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 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 may be referred to as “stations” and / or “STAs”, may be configured to transmit and / or receive wireless signals, and may be user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in relation to industrial and / or automated processing chains), home appliances, devices operating in commercial and / or industrial wireless networks, etc. (or may be any of these). Any of the WTRUs 102a, 102b, 102c, and 102d may interchangeably be referred to as a UE.

[0012]

[0025] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver base stations (BTS), node B (NB), e-node B (eNB), home node B (HNB), home e-node B (HeNB), g-node B (gNB), NR node B (NR NB), site controllers, access points (AP), wireless routers, etc. Although base stations 114a and 114b are depicted as single elements, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0013]

[0026] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), and relay nodes. Base stations 114a and / or base stations 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be called cells (not shown). These frequencies may exist in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. Cells may provide coverage of radio services to a particular geographic area that may be relatively fixed or change over time. Cells may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology, and may utilize multiple transceivers per sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0014]

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

[0015]

[0028] More specifically, as described above, the communication system 100 can be a multi-access system and can employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and the WTRUs 102a, 102b, 102c within the RAN 104 / 113 can implement a radio technology such as a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) that can establish the radio 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).

[0016]

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

[0017]

[0030] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as NR radio access, which can establish a radio interface 116 using New Radio (NR).

[0018]

[0031] In one embodiment, base station 114a and WTRU 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRU 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the radio interface utilized by WTRU 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNB and gNB).

[0019]

[0032] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Advanced High Speed ​​Data Rate (EDGE), and GSM EDGE (GERAN).

[0020]

[0033] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home e-node B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in localized areas such as offices, homes, vehicles, campuses, industrial facilities, aerial walkways (e.g., for use by drones), and roads. In one embodiment, base stations 114b and WTRUs 102c, 102d may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base stations 114b and WTRUs 102c, 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d may utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN106 / 115.

[0021]

[0034] RAN104 / 113 may communicate with CN106 / 115, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, and / or implement high-level security functions such as user authentication. Although not shown in Figure 1A, it should be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs employing the same or different RATs as RAN104 / 113. For example, in addition to being connected to RAN104 / 113 which may utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0022]

[0035] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, and 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing conventional telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) within the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs that may employ the same RAT as RAN104 / 114 or a different RAT.

[0023]

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

[0024]

[0037] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138. It should be understood that the WTRU 102 may include any partial combination of the above elements while maintaining consistency with one embodiment.

[0025]

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

[0026]

[0039] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the radio interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In one embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It should be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.

[0027]

[0040] In Figure 1B, the transmit / receive element 122 is depicted as a single element, but the WTRU 102 may include any number of transmit / receive elements 122. For example, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the radio interface 116.

[0028]

[0041] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capabilities. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0029]

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

[0030]

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

[0031]

[0044] The processor 118 may also be coupled to a 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 instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the radio interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information by any suitable location determination method while maintaining consistency with one embodiment.

[0032]

[0045] The processor 118 may be further coupled to other elements / peripherals 138, which may include one or more software modules and / or hardware modules that provide additional characteristics, functions and / or wired or wireless connectivity. Examples of elements / peripherals 138 include accelerometers, e-compasses, satellite transceivers, digital cameras (e.g., for photography and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, and the like. The elements / peripherals 138 may include one or more sensors, which may be one or more of gyroscopes, accelerometers, Hall effect sensors, magnetometers, compass sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors and / or humidity sensors.

[0033]

[0046] WTRU102 may include a full-duplex radio (for example, one in which the transmission and reception of some or all of the signals associated with a particular subframe for both uplink (e.g., transmission) and downlink (e.g., reception) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference either through hardware (e.g., chokes) or through processor-based signal processing (e.g., through a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio that transmits and receives some or all of the signals (for example, one associated with a particular subframe for either uplink (e.g., transmission) or downlink (e.g., reception)).

[0034]

[0047] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 employs E-UTRA wireless technology and can communicate with WTRU102a, 102b, and 102c via the wireless interface 116. RAN104 can also communicate with CN106.

[0035]

[0048] RAN104 may include e-nodes B160a, 160b, and 160c, but it should be understood that RAN104 may include any number of e-nodes B while maintaining consistency with one embodiment. Each of the e-nodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the radio interface 116. In one embodiment, e-nodes B160a, 160b, and 160c may implement MIMO technology. For example, e-node B160a may use multiple antennas to transmit radio signals to and receive radio signals from WTRU102a.

[0036]

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

[0037]

[0050] The CN106 shown in Figure 1C may 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 above elements is depicted as part of CN106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0038]

[0051] The MME162 can be connected to each of the e-nodes B160a, 160b, and 160c within RAN104 via the S1 interface and can function as a control node. For example, the MME162 may be responsible for user authentication of WTRU102a, 102b, and 102c, bearer activation / deactivation, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0039]

[0052] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c within RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can also perform other functions such as anchoring the user plane during handovers between e-nodes B, triggering paging when DL data is available for WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0040]

[0053] SGW164 can be connected to PGW166, thereby providing WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0041]

[0054] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional land communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0042]

[0055] In Figures 1A to 1D, the WTRU is described as a wireless terminal; however, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (e.g., temporarily or permanently).

[0043]

[0056] In a typical embodiment, the other network 112 may be a WLAN.

[0044]

[0057] A WLAN in Infrastructure Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with those APs. APs may have access to or interfaces with a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic originating outside the BSS and destined for an STA may arrive via an AP and be delivered to the STA. Traffic originating from an STA to a destination outside the BSS may be sent to an AP and delivered to its respective destination. Traffic between STAs within the BSS may be transmitted via an AP; for example, a source STA may send traffic to an AP, and the AP may deliver the traffic to a destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted (e.g., directly) between a source STA and a destination STA using a Direct Link Setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with one another. The IBSS communication mode may sometimes be referred to herein as the “ad hoc” communication mode.

[0045]

[0058] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be of a fixed width (e.g., a wide bandwidth of 20 MHz) or a width that is dynamically set via signal transmission. The primary channel may be the operating channel of the BSS, and an STA may be used to establish a connection with the AP. In certain typical embodiments, for example, a Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented in an 802.11 system. In the case of CSMA / CA, an STA, including the AP (e.g., any STA), may sense the primary channel. If the primary channel is sensed / detected by a particular STA and / or determined to be busy, that particular STA may backoff. In a given BSS, one STA (e.g., only one station) may transmit at any given time.

[0046]

[0059] A high-throughput (HT) STA can use a 40MHz wide channel for communication, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0047]

[0060] Ultra-high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. 160MHz channels can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels, which may be called an 80+80 configuration. In the 80+80 configuration, the channel-coded data can pass through a segment parser that can split the data into two streams. Inverse fast Fourier transform (IFFT) and time-domain processing can be performed separately for each stream. The streams can be mapped to two 80MHz channels, and the data can be transmitted by the transmitting STA. The receiver of the receiving STA can reverse the operation described above for the 80+80 configuration, and the combined data can be transmitted to a medium access control (MAC) layer, entities, etc.

[0048]

[0061] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV white space (TVWS) spectrum, while 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / MTC, such as machine-type communication (MTC) devices in a macro coverage area. MTC devices may have limited functionality, including support for specific and / or limited bandwidths (e.g., support only). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0049]

[0062] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode from among all STAs operating in the BSS. In the 802.11ah example, even if the AP and other STAs in the BSS support operating modes of 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidths, the primary channel may be 1MHz wide for an STA (e.g., an MTC type device) that supports 1MHz mode (e.g., only 1MHz mode). Carrier sensing and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if an STA (which only supports 1MHz operating mode) has its primary channel busy transmitting to an AP, the entire available frequency band may be considered busy, even though a large portion of the frequency band remains idle and could potentially be available.

[0050]

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

[0051]

[0064] Figure 1D is a system diagram illustrating RAN113 and CN115 according to one embodiment. As described above, RAN113 employs NR radio technology and can communicate with WTRU102a, 102b, and 102c via the radio interface 116. RAN113 can also communicate with CN115.

[0052]

[0065] RAN113 may include gNB180a, 180b, and 180c, but it should be understood that RAN113 may include any number of gNBs while maintaining consistency with one embodiment. Each gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the radio interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 180b can use beamforming to transmit signals to and / or receive signals from WTRU102a, 102b, and 102c. Thus, for example, gNB180a can use multiple antennas to transmit and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, and the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multipoint (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0053]

[0066] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable neurology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or lasting for varying absolute times).

[0054]

[0067] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can use one or more gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in an unauthorized band. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate / connect with gNB180a, 180b, and 180c, while also communicating / connecting with other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, enodes B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0055]

[0068] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to address wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interaction between NR and E-UTRA, routing of user plane data to user plane functions (UPF) 184a and 184b, and routing of control plane information to access and mobility management functions (AMF) 182a and 182b. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0056]

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

[0057]

[0070] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c within RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may be responsible for user authentication of WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of services used by WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low-latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and / or services for MTC access. The AMF182a and 182b may provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0058]

[0071] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic passing through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policies and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0059]

[0072] UPF184a and 184b can be connected to one or more gNB180a, 180b, and 180c in RAN113 via the N3 interface, thereby providing WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184a and 184b can perform other functions such as packet routing and forwarding, enforcement of user plane policies, support for multi-homed PDU sessions, handling of user plane QoS, buffering of downlink packets, and providing mobility anchoring.

[0060]

[0073] CN115 can facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. In addition, CN115 may provide WTRU102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via UPF184a, 184b through an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0061]

[0074] With regard to Figures 1A-1D and the corresponding descriptions in Figures 1A-1D, one or more of the functions described herein with respect to one or more of the WTRU102a-d, base stations 114a-b, e-nodes B160a-c, MME162, SGW164, PGW166, gNB180a-c, AMF182a-b, UPF184a-b, SMF183a-b, DN185a-b and / or any other elements / devices described herein may be implemented by one or more emulation elements / devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0062]

[0075] Emulation devices may be designed to perform one or more tests on other devices in a laboratory and / or operator network environment. For example, one or more emulation devices may perform one or more or all functions in a fully or partially implemented and / or deployed state as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more or all functions in a temporarily implemented / deployed state as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for testing purposes and / or may perform tests using wireless communications.

[0063]

[0076] One or more emulation devices may perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test scenario in a test laboratory and / or an undeployed (e.g., test) wired and / or wireless communication network to perform testing of one or more components. One or more emulation devices may be test equipment. Wireless communication via direct RF coupling and / or RF circuitry (e.g., which may include one or more antennas) may be used by an emulation device to transmit and / or receive data.

[0064]

[0077] For clarity, satisfying a condition (e.g., QoS budget), failing to satisfy a condition, and configuring a condition parameter are described throughout the embodiments described herein as relating to thresholds (e.g., being greater than or less than a value (e.g., threshold), configuring a value (e.g., threshold), etc.). For example, satisfying a condition (e.g., QoS budget) may be described as being greater than a value (e.g., threshold), and failing to satisfy a condition (e.g., QoS budget) may be described as being less than a value (e.g., threshold). The embodiments described herein are not limited to threshold-based conditions. Any other kind of conditions and parameters (e.g., being within or outside a range of values) may be applicable to the embodiments described herein.

[0065]

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

[0066]

[0079] Throughout the embodiments described herein, the terms “serving base station,” “base station,” “gNB,” and “network,” collectively “gNB,” may be used interchangeably to specify any network element, such as a network element that functions 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.

[0067]

[0080] Throughout the embodiments described herein, any network element of the RAN or core network (CN) may be referred to herein as “Network”.

[0068]

[0081] Throughout the embodiments described herein, “one (a)” and “one (an)” and similar phrases should be interpreted as “one or more” and “at least one.” Similarly, any term ending in the suffix “(s)” should be interpreted as “one or more” and “at least one.” The term “can / may” should be interpreted as “for example, can / may.”

[0069]

[0082] The symbol " / " (e.g., a forward slash) may be used herein to represent "and / or", for example, "A / B" may imply "A and / or B".

[0070]

[0083] Throughout the embodiments described herein, the expressions “call a function (e.g., an API)” and “send information (e.g., a call request) indicating a function (e.g., an API)” may be used interchangeably to specify that a request message indicating one or more parameters of the called function may be sent to a network element, and a response message indicating one or more response parameters of the called function may be received from the network element.

[0071]

[0084] Throughout the embodiments described herein, the expression “disclose information to a network” is used interchangeably with “transmit information to a network element” to specify that information may be made available to a network element (e.g., transmitted) in a message that may be directed to a network element (e.g., the network element to which the message is ultimately destined) and / or a message that may be processed by a network element that is forwarded to another network element, and the disclosed information may be intercepted and processed by the network element, for example, based on packet inspection techniques.

[0072]

[0085] Throughout the embodiments described herein, the terms “request (or response)” and “send a request (or response)” may be used interchangeably with the expression “send information indicating a request (or response).”

[0073]

[0086] Throughout the embodiments described herein, the term “interdependent flow” may be used, for example, to refer to at least a first and second flow that have dependency levels to satisfy the QoS (e.g., QoE) objectives of an application based on interdependent flows. The terms “first flow” and “forward flow” may be used interchangeably throughout the embodiments described herein. The terms “second flow,” “reverse flow,” and “backward flow” may be used interchangeably throughout the embodiments described herein. Embodiments described herein may be applicable to two or more forward flows (e.g., impacting, related) depending on the reverse flow.

[0074]

[0087] overview

[0088] In the embodiments described herein, a WTRU can correspond to any XR device (e.g., a network element) which may be in various form factors. Examples of a WTRU (e.g., an XR WTRU) may include, but are not limited to, a head-mounted display (HMD), optical see-through glasses, a camera see-through HMD for either AR or VR, a mobile device with position tracking and a camera, or a wearable. There may be different types of XR XTRUs, for example, based on (e.g., different) XR device functions provided by one or more devices, wearables, actuators, controllers and / or accessories, such as a display, camera, sensors, sensor processing, wireless connectivity, XR / media processing and power supply. One or more devices (e.g., a network element, a WTRU) may be grouped into a collaborative XR group to support any of XR applications, XR experiences and XR services.

[0075]

[0089] For example, in XR services and applications such as interactive AR and VR, the WTRU can interact (e.g., exchange information) with an XR server running on an edge computing network element to offload computationally intensive tasks such as video rendering or collision avoidance calculations. In one example of rendering between the WTRU and an edge network element, the XR WTRU can send tracking information, sensor information, gesture information, and interactivity information to the XR server via an uplink (UL) transmission. For example, the XR server may generate an XR scene based on the information received from the XR WTRU. The XR server can rasterize the XR viewport, perform XR pre-rendering, generate XR media, which can be encoded and delivered to the XR WTRU via a downlink (DL) transmission. The XR WTRU can receive and decode the XR media. The XR WTRU can perform pose correction (e.g., up-to-date) to address changes in pose and render (e.g., XR media in the XR viewport).

[0076]

[0090] XR applications may have (e.g., strict) round-trip expectations (e.g., requirements) to provide an end user with a certain level of perceived quality (QoE), such as motion-to-photon latency of 20 milliseconds (e.g., end-to-end latency).

[0077]

[0091] Rendering either XR video or XR scenes may be associated with offloading the process to a more powerful computing unit, for example, if the WTRU does not contain sufficient computing resources. Two examples are described herein in which at least part of the processing may be performed on edge servers to meet the expectations (e.g., requirements) of the WTRU.

[0078]

[0092] Figure 2 shows two examples 21, 21 of XR applications. In the first example 21, the optical see-through device may have limited computing and battery resources. When a user runs an AR application, the AR glasses can communicate either in a standalone manner or via a WTRU to capture the user's pose and send it to an edge application server (e.g., capture). The server application can then process the video stream for rendering regarding the received pose and send the video stream to the AR glasses (e.g., via a WTRU) for rendering on the glasses. In the second example 22, the video see-through device may send the first video stream to an edge application server, which may compute graphical information to be superimposed on top of the received video before sending the rendered video stream to a VR headset (e.g., the video see-through device).

[0079]

[0093] Overview of the 5G Core API Release Regarding Round-Trip Latency

[0094] An Application Function (AF) can call an Application Programming Interface (API) (e.g., Npcf_Policy Authorization) to provide the 5G Core (5GC) with round-trip (RT) latency (e.g., requirements, budget) for either uplink or downlink flows. For example, the RT latency (e.g., requirements, budget) may represent the acceptable sum of downlink and uplink delays. Uplink and downlink delays can be the delays between the WTRU and the network termination point (e.g., the network element performing the UPF), and may be referred to herein as N6. The 5GC can monitor the associated downlink and uplink path delays and adjust the packet delay budget for either the downlink or uplink path to satisfy the RT latency (e.g., requirements, budget). For example, if it is observed that the latency on the uplink path is greater than the latency on the downlink path, 5GC can provision a larger packet delay budget on the uplink path and a smaller packet delay budget on the downlink path, provided that the sum of the two values ​​does not exceed the RT latency (e.g., requirement budget).

[0080]

[0095] The 5GC API does not necessarily have to be used to control end-to-end round-trip time latency (e.g., delay between the WTRU and the application server). 5GC may not be aware of the latency between the N6 termination point and the application server.

[0081]

[0096] Pre-configured QoS settings may not be well-suited for XR applications, which can be due to variable network usage to maintain QoE. Processing and bandwidth of video streams generated by edge servers can be variable, depending on either user pose changes or the complexity of scene rendering. The underlying network can manage its resources based on pre-configured QoS flow resource allocation between the application and the network.

[0082]

[0097] Real-time delayed QoS / QoE expectations (e.g., requirements, goals) may not be met at the application level (e.g., application level only). End-user expectations for QoS / QoE (e.g., requirements, goals), including time-sensitive high-quality content and strict RTT delays such as motion-to-photon, may not be met by increasing buffers in the application or by post-processing pause corrections such as asynchronous time warp. For example, real-time communications and protocols may be used to meet real-time expectations (e.g., requirements, goals). Failure to meet these real-time expectations (e.g., requirements, goals) can result in packet loss and a decrease in end-user QoE.

[0083]

[0098] End-user QoE may be considered globally, rather than from the perspective of independent configuration flows. WTRUs interact with the network (e.g., RAN / CN) to establish different, independent uplink and downlink flows and may assign or adjust the QoS of flows with respect to, for example, uplink and downlink packet delay budget (PDB) settings. End-user QoE may depend on round-trip characteristics (e.g., requirements), including uplink flows transmitted by the WTRU and downlink flows transmitted by application servers.

[0084]

[0099] Remote edge servers may not interact with the network (e.g., RAN / CN) (e.g., directly) to configure flows. XR applications may involve segmented rendering to meet stringent device, application, and latency targets (e.g., requirements). In these configurations, the WTRU can provide applications that can interact with the edge server to configure one or more forward and / or reverse flows. For example, the WTRU may only be able to interact with the network via the RAN and may not be able to measure how different flows might affect QoE to achieve the above objectives (e.g., requirements).

[0085]

[0100] Networks may not share network capabilities with applications. For example, an XR application may request network resources that may be shared and coordinated between different users and applications according to available resources that may be limited and insufficient. Networks may also coordinate resources for energy-saving purposes. A network may not be aware at any given time whether an application could request more resources or whether resources that may not be used by the network have been allocated.

[0086]

[0101] Flow Overview

[0102] Different media data service flows are shown in Figure 2. For example, the forward media flow, shown as "Flow 1," and the reverse media flow, shown as "Flow 2," can be referred to as dependent or interdependent based on the reverse media flow, which is constructed from the input from the forward media flow.

[0087]

[0103] A "forward" (e.g., data, media) flow may refer to a one-way flow that acknowledges in the reverse direction (e.g., an uplink in the example in Figure 2). A "reverse" (e.g., data, media) flow may refer to a one-way flow that acknowledges in the reverse direction (e.g., a downlink in the example in Figure 2).

[0088]

[0104] As shown in Figure 2, the forward flow may be an associated (e.g., media) flow that includes, for example, user poses or user interaction data. The reverse flow may be another associated (e.g., media) flow that includes, for example, a rendered video stream or an updated XR scene state.

[0089]

[0105] Both forward and reverse flows may include any transport protocol connection (same or different). Both forward and reverse flows may be transported via (or based on) any of the following: trusted (e.g., Transport Control Protocol (TCP), Quick User Data Protocol (UDP) Internet connection (QUIC) and untrusted (e.g., UDP) transports.

[0090]

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

[0091]

[0107] In the second example, the forward flow may include an RTP stream, and the reverse flow may include a TCP connection.

[0092]

[0108] In the third example, the forward flow may include a first QUIC connection, and the reverse flow may include a second QUIC connection.

[0093]

[0109] The embodiments described herein may be applicable to interdependent application flows between three or more devices (e.g., network elements), such as between a WTRU, an edge network element, and a server network element. For clarity, embodiments described herein are described by assuming that any processing performed behind an edge server is performed by the edge server. The embodiments described herein may be applicable to any other configuration in which edge processing may be distributed across two or more network elements.

[0094]

[0110] overview

[0111] A WTRU (e.g., a client application running on the WTRU) can, in different embodiments described herein, configure a server-side application (e.g., running on a network element (e.g., an edge network element, a cloud network element)) to measure interdependent application / network flow characteristics (e.g., metrics) and / or interdependent related QoE characteristics (e.g., metrics) in round-trip communications, including sending and receiving information in interdependent forward and reverse flows, and B) expose relevant interdependent flow information and coordination to the network layer.

[0095]

[0112] In the first embodiment, a client WTRU application may communicate with the server to determine interdependent round-trip flow characteristics according to the following steps.

[0096]

[0113] In the first step, the client WTRU application can send interdependent flow information to the server-side application via forward flow.

[0097]

[0114] In the second step, the server's receipt of identified interdependent flow information in the forward flow from the WTRU can trigger the server-side application to prepare for replication to the reverse flow, and the interdependent flow information may include interdependent flow mark information elements (IE).

[0098]

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

[0099]

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

[0100]

[0117] In the fifth step, the receipt of identified interdependent flow information in the reverse flow from the server can trigger the processing of one or more interdependent flow round-trip characteristics by the WTRU, and the interdependent flow information may include interdependent flow marks IE.

[0101]

[0118] In the sixth step, the WTRU can determine one or more interdependent flow round-trip characteristics from the received interdependent flow information.

[0102]

[0119] In the first example, the interdependent flow information may include (e.g., may be shown) an interdependent flow timestamp set by the WTRU when sending a forward flow packet. The WTRU can calculate the interdependent flow round-trip time (RTT) property from the current timestamp value and the shown interdependent flow timestamp (e.g., value).

[0103]

[0120] In the second example, the interdependent flow information may include an interdependent flow mark IE. The WTRU can calculate one or more interdependent flow round-trip time characteristics from measurements of the timestamp before the interdependent flow mark IE is sent in the forward flow packet and the timestamp when the interdependent flow mark IE is received in the reverse flow packet.

[0104]

[0121] In the second embodiment, the client WTRU application can interact with the network layer to (i) associate interdependent flows, and (ii) publish either QoS information and QoS adjustments based on either WTRU support information and / or associated forward / reverse flow marks and / or via any 5G core network API, such as NEF (Network Exposure Function) or PCF (Policy Control Function).

[0105]

[0122] Figure 3 shows an example of QoS flow information transmitted at the transport layer. In one example, a client application and a server application can configure the transport layer to A) enable QoS measurements 31 and 32 and B3) expose adjustment values ​​33 and 34 to the network layer. The client application can directly provide information 35 to the WTRU to B1) associate flow dependencies or B2) (for example, as an alternative) expose adjustments. In one example, the WTRU can forward the information to the RAN using UE support information messages, such as those described in 3GPP TS38.331, “NR; Radio Resource Control (RRC); Protocol specification (V17.0.0)”. In another example (not shown in Figure 3), to expose adjustment information, the WTRU may forward the adjustment information to the core network based on core network messages, for example via either NEF and PCF API messages.

[0106]

[0123] In a 3GPP network embodiment, the WTRU can interact with the RAN base station to access the core network (CN). The WTRU can transmit forward flow packets uplink through the RAN and to the application server via the UPF within the CN. The application server can transmit reverse flow packets downlink through the UPF and through the RAN to the WTRU. In this embodiment, the WTRU may expose interdependent flow information and / or coordination in forward flows to or through the RAN to the 3GPP CN or reverse flows to or through the UPF to the 3GPP CN, ​​as described in Tables 1 and 2.

[0107]

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

[0108]

[0125] Any network element interconnecting the UPF, non-3GPP access network, and WTRU, as well as the application server, may be configured to receive reverse flow marks from the application server in order to apply QoS / QoE adjustment rules.

[0109]

[0126] Figure 4 shows an exemplary method 400 for measuring and adjusting interdependent flow characteristics.

[0110]

[0127] As shown in 410, the WTRU application, server-side application, and network can configure the WTRU's exposure policy to expose interdependent flow characteristics.

[0111]

[0128] As shown in 420, either the WTRU application or the server-side application may expose interdependent flow information based on, for example, marking information (e.g., insertion).

[0112]

[0129] As shown in 430, WTRU can measure interdependent flow characteristics from interdependent flow information.

[0113]

[0130] As shown in 440, WTRU can determine network characteristic adjustments based on either interdependent flow characteristic measurements or policy settings.

[0114]

[0131] As shown in 450, the WTRU may publish or communicate adjustments to network characteristics.

[0115]

[0132] As shown in 460, the network can apply changes.

[0116]

[0133] The embodiments described herein may 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 variations in real-time network characteristics and, based on the measured variations in real-time network characteristics, adjust network characteristics with respect to allocated network resources. The embodiments described herein may enable improved quality of service based on real-time resource adjustment to reduce packet loss. The embodiments described herein may enable an application to provide the network layer with means for detecting unused resources that can be reallocated to other applications or deallocated, for example, to conserve energy.

[0117]

[0134] Overview of QoE characteristics of measurement and adjustment

[0135] Figure 5 shows an example of different QoS / QoE characteristics for measurement and adjustment. Embodiments described herein may enable a WTRU to measure QoS / QoE characteristics, shown as linear, in real time, estimate delays, and either meet its round-trip QoS expectations or provide the expected QoE experience. For example, a WTRU may measure any of the forward-trip time 51, reverse-trip time 52, and round-trip time 53.

[0118]

[0136] The RAN and / or CN can measure characteristics indicated by dotted lines, such as uplink trip delay, downlink trip delay, the RAN portion of the uplink trip delay, and the CN mart of the uplink trip delay. For example, the WTRU can communicate with the RAN to set (e.g., adjust) the UL / DL delay budget for an independent flow, or the WTRU can request adjustment of the UL / DL delay to meet the QoE of its application.

[0119]

[0137] Figure 6 shows an example of different timing measurements for QoS / QoE characteristic measurement.

[0120]

[0138] As an example of interdependent flow characteristics, embodiments involving packet delay (forward trip delay, reverse trip delay, round trip delay) are described herein, where packet delay refers to the delay between the transmission of a packet and the reception of a packet. Embodiments described herein may also be applicable to any other types of delay, such as packet delay variation, inter-packet delay, and inter-packet delay variation.

[0121]

[0139] Throughout the embodiments described herein, the terms “forward / reverse / round trip time” and “forward / reverse / round trip delay” may be used interchangeably to specify the duration of a packet’s forward / reverse / round trip.

[0122]

[0140] The first column of Table 1 lists the timestamps of different interdependent flows. The second column of Table 1 describes how different interdependent flow timestamps may be used to measure related interdependent flow time (e.g., delay). The third column of Table 1 describes which entities can insert interdependent flow information (e.g., timestamp or time), and the fourth column of Table 1 describes which entities can read interdependent flow information (e.g., timestamp or time). The fifth column of Table 1 describes the actions taken by the WTRU and the server to provide interdependent flow time (e.g., delay).

[0123] [Table 1]

[0124] [Table 2]

[0125]

[0141] The first column of Table 2 describes the relationships between interdependent flow times (e.g., delays), as shown in the second column of Table 1. The second column of Table 2 describes the relevant interdependent flow information / characteristics due to the delays shown in Figure 5. The third column of Table 2 describes the source of the information, for example, which entities (WTRU and / or servers) may expose the interdependent flow information, and whether it may be visible to the underlying network layer, for example, based on transport packet markings. The fourth column of Table 2 describes the clients (e.g., destinations) that receive the interdependent flow information, and the fifth column of Table 2 describes the actions between the source and client for exposing the interdependent flow information.

[0126] [Table 3]

[0127] [Table 4]

[0128] [Table 5]

[0129] [Table 6]

[0130] [Table 7]

[0131] [Table 8]

[0132]

[0142] An example where WTRU determines interdependent round-trip flow characteristics (e.g., metrics) based on receiving information replicated from forward flow to reverse flow.

[0143] WTRU can determine one or more interdependent flow round trip characteristics based on the transmission and reception of interdependent flow information.

[0133]

[0144] In one embodiment, interdependent flow information may include (for example, shown) an interdependent flow round-trip timestamp that can be transmitted by the WTRU in the forward flow and replicated by the server in the reverse flow. The interdependent flow round-trip timestamp may be referred to herein as a forward timestamp. The WTRU can receive the forward timestamp transmitted and replicated by the server and can determine the interdependent round-trip time (RTT) from the elapsed time between the receipt of the forward timestamp and the current timestamp value. This embodiment may be referred to as stateless based on the fact that the WTRU does not store data.

[0134]

[0145] In another embodiment, interdependence flow information may include (e.g., indicate) an interdependence flow mark IE used as an identifier (e.g., marker) for packets containing the interdependence flow mark. The WTRU can determine (e.g., calculate) the interdependence flow round-trip time characteristics based on measuring (e.g., logging) the time before (e.g., a timestamp) the interdependence flow mark IE is sent in a forward flow packet and the time when (e.g., a timestamp) the interdependence flow mark IE is received in a reverse flow packet. The mark (e.g., within the flow mark IE) may include any (e.g., random) value that is known and shared between the WTRU and the server, for example, during the setup phase. The WTRU may retain (e.g., store) the original timestamp value associated with the sent mark. This embodiment may be called stateful based on the WTRU stored data (e.g., between the transmission of the packet in the forward flow and the reception of the corresponding packet in the reverse flow).

[0135]

[0146] In another embodiment, the interdependent flow information may include one or more different timestamps, as listed in Table 1, depending on the delays that the WTRU can calculate as described herein.

[0136]

[0147] In the first example, the WTRU may set and insert a forward flow timestamp or the same round-trip timestamp as described above. For example, receiving a forward flow timestamp from a WTRU, since the WTRU receives interdependent flow information indicating a WTRU request for a forward flow timestamp, may trigger the server to process the request. The interdependent flow information in the forward flow may include an "interdependent flow" forward flow timestamp IE mark. The server may determine (e.g., calculate) the forward flow delay by subtracting the forward flow timestamp value from the server time (e.g., current time). The server may send a packet containing information indicating the forward flow delay, which is inserted into a dedicated field in the packet in an interdependent reverse flow, for example. The delay may be an "interdependent flow" forward flow delay IE mark in the reverse flow.

[0137]

[0148] In the second example, the WTRU may send information to the server indicating a reverse flow timestamp request. This information may include (e.g., indicate) a “mutually dependent flow” reverse flow timestamp request IE to the server. Receipt of the “mutually dependent flow” reverse flow timestamp request IE may trigger the server to insert information indicating the reverse timestamp value into the reverse flow packet. The server may insert the “mutually dependent flow” reverse flow timestamp IE mark into the reverse flow belonging to the mutually dependent flow. Based on the receipt of the “mutually dependent flow” reverse flow timestamp IE mark, the WTRU may determine (e.g., calculate) the reverse flow delay by subtracting the received reverse flow timestamp value from the current WTRU time.

[0138]

[0149] In one embodiment, the different delay calculations described herein may enable the WTRU to determine (e.g., calculate) the server delay portion (e.g., contribution), as shown in Figure 5. In one example, the WTRU may send information to the server indicating the server delay contribution portion with respect to interdependent flow round trip delays. The WTRU may send a server delay IE mark in the forward flow to transport the server delay value to the server.

[0139]

[0150] In one embodiment, the WTRU can determine a frequency for acquiring (e.g., calculating) interdependent flow round-trip characteristics. The WTRU can transmit or update the interdependent flow frequency IE (e.g., indicating a value for the interdependent flow frequency) to the server. The server can use the frequency value to trigger the reception of any other interdependent flow information described herein.

[0140]

[0151] In one embodiment, the WTRU and the server application can configure a policy to communicate interdependent flow information to the other side. Interdependent flow information may be provided based on (e.g., a regular) sampling frequency criterion, relevant data information, and (e.g., a specific) header type or information within the received flow packet (either forward or reverse flow).

[0141]

[0152] In one embodiment, the interdependent flow information may include packet numbering (e.g., count) information, including, for example, the continuation of packet counting / numbering from forward and reverse flows, so that the network can calculate the interdependent flow timings listed in Table 1.

[0142]

[0153] In one embodiment, interdependent flow information may include, for example, an algorithm-encoded interdependent flow mark IE value. An example may include a transition pattern of spin bit values ​​from "0" to "1" or from "1" to "0". The sender may change the pattern or toggle the spin bit value after each round trip.

[0143]

[0154] Example of measuring interdependent round-trip delays using timestamp markings for RTP / RTCP interdependent flows.

[0155] Exemplary implementations are described herein based on the reception of a timestamp in the RTP header of a reverse flow, which may be a copy or duplicate of a timestamp that may have been transmitted in the RTP header in the forward flow.

[0144]

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

[0145]

[0157] Figure 7 shows an exemplary method of delay measurement based on either Real-Time Protocol (RTP) or Real-Time Control Protocol (RTCP) marked timestamps.

[0146]

[0158] Configuration Phase

[0159] As shown in 71, an application running between the WTRU and the server may establish two interdependent flows, for example, a first (e.g., forward) flow (e.g., based on RTP for transporting pause information from the WTRU to the application server) and a second (e.g., reverse) flow (e.g., based on RTP for transporting XR rendered video from the application server to the WTRU).

[0147]

[0160] As shown in 72, a WTRU (e.g., an application) may send request information to the application server indicating a timestamp replication policy (e.g., a rule), a policy (e.g., a rule) that includes means for identifying dependent flow timestamps IE in a forward flow, the time and place where a timestamp should be obtained in the forward flow, and where the value of the dependent flow timestamp IE should be replicated in the reverse flow. The request information may include one or more parameters indicating one or more first forward flow parameters, one or more second forward flow parameters, and one or more action rule parameters.

[0148]

[0161] One or more first forward flow parameters may indicate either an RTP payload type or an RTP header extension type, which may include, for example, an interdependent flow timestamp IE field containing a current timestamp value measured by the WTRU before (e.g., when) the forward flow packet was sent (e.g., indicating the time the RTP packet was sent in the forward flow). For example, one or more first parameters may include a first (e.g., forward) flow identifier.

[0149]

[0162] One or more second reverse flow parameters may indicate an RTP header extension type that includes an RTP payload type and an interdependent flow timestamp IE field (for example, used) for inserting a previous (for example, duplicated) timestamp value. For example, one or more second parameters may include a second (for example, reverse) flow identifier.

[0150]

[0163] One or more action rule parameters may indicate an action rule to instruct the reverse RTP transport layer (e.g., within the application server) to replicate the timestamp, according to one of the following examples.

[0151]

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

[0152]

[0165] In the second example, the action rule parameter might indicate that a timestamp should be returned in one or more first RTP packets of the corresponding dependent second flow, for example, the first (e.g., initial) RTP packet of a newly rendered paused stream.

[0153]

[0166] In the third example, the action rule parameter may indicate that a timestamp should be returned for all RTP packets (e.g., all packets of the corresponding dependent second flow, e.g., all packets of the newly rendered pause stream).

[0154]

[0167] In the fourth example, the action rule parameter may indicate that, if applicable, a timestamp should be returned in X RTP packets after a new timestamp is received. X can be an integer configured (e.g., shared) between the WTRU and the server.

[0155]

[0168] As shown in 73, the application server can send acknowledgment information to the WTRU to acknowledge the request information, and the interdependent flow timestamp IE may be received from the WTRU. For example, the application server can apply policy rules in the reverse flow.

[0156]

[0169] Measurement phase

[0170] As shown in 74, the WTRU can determine the current timestamp value from the system (either by calculating or retrieving it) and write (e.g., insert) the timestamp value into the interdependent flow timestamp IE in the RTP / RTCP header of the forward flow packet. For example, the WTRU may insert information (e.g., a specific header type value in the header) indicating that either the timestamp information or the interdependent flow mark IE may be sent to trigger a server action.

[0157]

[0171] As shown in 75, the reception of any of the interdependent flow timestamp information, (e.g., a specific) RTP header type, and (e.g., a specific) interdependent flow mark IE can trigger the application server to read the timestamp value from the timestamp IE field of the RTP header of the received forward flow, and to enforce (e.g., activate) the corresponding policy rules established using the WTRU (e.g., requested as indicated by the WTRU), such as (i) duplicating the timestamp value in the interdependent flow timestamp IE field of the RTP header in the reverse flow, (ii) updating the RTP header type (e.g., where appropriate), and (iii) sending the packet in the reverse flow.

[0158]

[0172] As shown in 76, the reception of any of the interdependent flow timestamp IE, (e.g., a specific) RTP header type, and (e.g., a specific) interdependent flow mark IE may trigger the WTRU to read the timestamp value from the interdependent flow timestamp IE field of the RTP header of the reverse flow.

[0159]

[0173] As shown in 77, the WTRU can determine either round-trip delay or round-trip delay variation based on calculating the current and previous round-trip times by comparing the current and previously received interdependent flow timestamps.

[0160]

[0174] In one embodiment, round-trip QoS / QoE metrics can be provided to the WTRU using RTCP message exchange between the WTRU and the application server. RTCP messages may be sent asynchronously, in which case RTP information may be sent synchronously (with content information). RTCP may be called a control protocol that provides QoS metrics to RTP. To reduce the number of control packets, the frequency of RTCP messages may be lower than that of RTP packets.

[0161]

[0175] An example of WTRU exposing service flow dependencies to the network.

[0176] In one embodiment, an application can interact with the network layer to expose dependencies between different flows belonging to the application to the network (RAN / CN). For example, an application can share information between a WTRU and a server to identify interdependent flows. Sharing information about dependencies between different flows of an application can occur, for example, when establishing application streams such as RTCP, RTP, QUIC, and TCP streams in either the forward or reverse direction.

[0162]

[0177] In one embodiment, an application can create association information, such as a dependency flow identifier, that indicates that interdependent flows may be associated with (e.g., depend on). The association information (e.g., the dependency flow identifier) ​​can be transmitted to the network (e.g., exposed) along with information about the flows identified as interdependent (e.g., each) (e.g., forward flows and reverse flows as described herein). The dependency flow identifier may include, for example, a multimodal service identifier (multimodal service ID).

[0163]

[0178] In one embodiment, an application may expose information about flows (e.g., each) identified as interdependent (e.g., forward flows and reverse flows as described herein) to the network. The network may create and maintain interdependent flow information identifiers that associate dependent flow information and may return the interdependent flow identifiers to the application (e.g., by sending information indicating them). An application that exposes information to the network may be a WTRU application that can call either the PCF or NEF API. An application that exposes information to the network may be a server-side application that can call either the PCF or NEF API.

[0164]

[0179] For example, an application may publish interdependent flow identifiers for further network configuration in the same information disclosure that publishes interdependent flow measurements and / or interdependent flow information (e.g., characteristics) according to Table 1 and / or Table 2. For example, any interdependent flow information according to either Table 1 or Table 2 may be published (e.g., transmitted) to the network (e.g., CN / RAN) and / or application servers. For example, interdependent flow identifiers may be used by the network to retrieve corresponding interdependent flow information. For example, if the network updates its configuration, for example, if the network can update the delay budget associated with at least some of the interdependent flows, the network may notify the application using the interdependent flow identifiers (e.g., transmit information indicating this).

[0165]

[0180] In one embodiment, a WTRU (e.g., an application) can obtain QoS flow identifiers belonging to the same or different PDU sessions and send information indicating the corresponding dependent QoS flow identifiers, along with additional dependency (e.g., association) information, to the network (CN / RAN). Transmission to the network may be performed, for example, by sending the information to an application server, which may then send the information to the network by calling either the NEF or PCF API.

[0166]

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

[0167]

[0182] In one embodiment, additional dependency information may include global or different QoS rule interdependencies, according to one of the following examples.

[0168]

[0183] In the first example, additional dependency information may indicate the direction of the dependency (e.g., forward / uplink in the first flow and reverse / downlink in the second flow). Applications between the WTRU and the server may grasp and share interdependent flow information to identify forward and reverse flows, according to any embodiment described herein.

[0169]

[0184] In the second example, additional dependency information may indicate a QoS flow rule and its associated QoS flow rule identifier (QFI). As described herein, an application may expose interdependent flow information, including interacting with the network to determine the mapping of QoS flow rules, including QFIs, to interdependent flows in, for example, forward or reverse directions.

[0170]

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

[0171]

[0186] In the fourth example, additional dependency information may indicate one or more interdependent round-trip QoS flow parameters, including one or more guaranteed, maximum, range (minimum, maximum) bit rates associated with forward and / or reverse flows, to satisfy one or more expected latencies (e.g., delays). For example, considering latencies of 20 milliseconds on the uplink and 30 milliseconds on the downlink, the round trip may be set to 50 milliseconds. An application may have expected latencies that do not exceed motion-to-photon timing in XR applications, for example, to achieve QoE acceptable to the end user. Application QoS expectations may enable the configuration of interdependent round-trip QoS flow parameters in the network.

[0172]

[0187] An example of a WTRU that configures a network policy to expose interdependent flow information.

[0188] In one embodiment, the WTRU and / or network may configure, establish and publish interdependent flow information (e.g., characteristics) as described herein, including, for example, any of the following: round trip time, round trip delay adjustment, round trip delay budget variation, forward trip time, forward trip delay adjustment, forward trip delay budget variation, reverse trip time, reverse trip delay adjustment, and reverse trip delay budget variation, as described in Table 2.

[0173]

[0189] By publishing interdependent flow information (e.g., characteristics) to the network (RAN / CN / UPF), it is possible to adjust any of the uplink / forward trip delays (RAN portion, CN portion), downlink / reverse trip delays (RAN portion, CN portion), and round trip delays, which may include forward uplinks and reverse downlinks, enabling the network (RAN / CN / UPF) to determine and select which uplink, downlink, or both flows to adjust in the time required to meet the target round trip delay.

[0174]

[0190] In one embodiment, the WTRU and / or network may configure, establish, and agree on the disclosure of delay budgets for one or more measured interdependent flow delays (UL / DL / round trips), including any of the following examples:

[0175]

[0191] In the first example, the delay budget may include either the expected standard delay or the expected median delay budget.

[0176]

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

[0177]

[0193] In the third example, the delay budget may include one or more delay budget thresholds (allowable lower limit, allowable upper limit) that trigger the sending of the message.

[0178]

[0194] In the fourth example, the delay budget may include a communication mode for transmitting support information and adjustments such as a periodic mode having a sampling frequency and / or an event trigger, and an aperiodic mode associated with a delay budget threshold and the current delay value.

[0179]

[0195] In one embodiment, the WTRU and / or network may configure, establish, and agree on the publication of delay adjustments for one or more measured interdependent flow delays (UL / DL / round trips), including any of the following embodiments:

[0180]

[0196] In the first example, delay adjustment may indicate a reduction in delay adjustment. The application may measure, anticipate, or predict that it can reduce the measured delay (UL / DL / round trip) to meet an end-to-end latency target, for example.

[0181]

[0197] In the second example, delay adjustment may indicate an increase in delay adjustment. The application may measure, anticipate, or predict that delay (UL / DL / round trip) can be mitigated to indicate to the network, for example, that bandwidth and / or energy will be saved.

[0182]

[0198] In the third example, delay adjustment may represent delay predictions that include either a confidence estimate of the prediction or the expected timing of the prediction. A WTRU application may predict that delays may increase based on expected forward / reverse flow bandwidth variations and / or buffering / processing delay variations.

[0183]

[0199] In the fourth example, the delay adjustment may indicate either the delay range or the threshold reached (either a lower and upper limit, an unusable lower limit, or an acceptable upper limit).

[0184]

[0200] In one embodiment, the WTRU and / or network may configure, establish, and agree on a delay measurement method based, for example, on any of the following measurement method parameters.

[0185]

[0201] In the first example, the delay measurement method parameter may include the measurement duration.

[0186]

[0202] In the second example, the delay measurement method parameters may include the type of measurement (e.g., periodic, event-triggered).

[0187]

[0203] In the third example, the delay measurement method parameters may include the number of times the delay is measured and the number of times the period is reported. For example, WTRU may observe that the delay can reach a lower or upper limit over a period of time, and / or measure several times the number of times the delay can reach its limit. This parameter may help avoid measurement errors or peak fluctuations that the application may have to deal with over a period of time.

[0188]

[0204] In the fourth example, the delay measurement method parameter may include a measurement statistics mode that indicates how the delay measurement can be performed with the corresponding parameter (e.g., standard deviation, mean, median, or maximum value).

[0189]

[0205] In one embodiment, the WTRU and / or network may configure, establish and agree on the disclosure of delayed budget variance for one or more measured interdependent flows, which includes any of the following probability distributions (Gaussian, normal) including (i) standard deviation / variance, (ii) mean deviation / variance, (iii) median deviation / variance, (iv) minimum and maximum deviation / variance, and (v) a set of probability values.

[0190]

[0206] In one embodiment, the RAN / CN may report to the WTRU effective adjustments or adjustment feedback that the network can apply with respect to desired adjustments of interdependent flow characteristics published by the WTRU. The feedback information may include indications of where adjustments may have been made (RAN portion / CN portion). The feedback information may include uplink / forward trip time adjustment delay feedback, downlink / reverse trip time adjustment delay feedback (RAN portion / CN portion), and round-trip delay adjustment as a sum of forward / uplink and reverse / downlink adjustments.

[0191]

[0207] In one embodiment, a WTRU may transmit a WTRU support message (for example, as described in Section 5.7.4, “NR; Radio Resource Control (RRC); Protocol specification” (V17.0.0) of 3GPP TS 38.331) to disclose interdependent flow information, characteristics, or coordination. For example, a WTRU support message may include any information for identifying interdependent flows, in accordance with any embodiment described herein.

[0192]

[0208] In one embodiment, the WTRU and / or network may be configured, established, and agreed to expose interdependent flow information (e.g., characteristics) described herein (e.g., including any parameters listed in the second column of Table 2) by marking (e.g., inserting marking information) packets in forward and / or reverse flows. An application may write (e.g., insert, include) one or more marks that may be visible (e.g., accessible) to the network layer (of any network element responsible for processing forward and / or reverse flows). An example of packet marking information may include one or more informational elements in a flow, as shown in any of the following examples.

[0193]

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

[0194]

[0210] In the second example, the marking information may be associated with a bitfield location (e.g., Identified, Updated) from which the bitfield value (e.g., Identified, Updated) of the marking information can be read.

[0195]

[0211] In the third example, marking information may be associated with (for example, a new) protocol header extension type, indicating that packets may contain marking information.

[0196]

[0212] For example, the presence of flow mark information associated with (e.g., indicating) either delay adjustment and budget variation according to any embodiment described herein may trigger the network to read one or more adjustment delay / variation mark values ​​from the application (e.g., may indicate a request to the network). For example, the presence of associated interdependent flow information identifiers or information element marks may trigger the network to read one or more adjustment delay / variation mark values ​​from the application (e.g., indicate a request to the network).

[0197]

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

[0198]

[0214] In the first example, a QoS rule may include a QoS flow rule and an associated QoS flow rule identifier (QFI). An application may interact with the network to expose interdependent flow information, including determining the mapping of QoS flow rules, including QFIs, to interdependent flows in the forward and / or reverse directions.

[0199]

[0215] In the second example, the QoS rule may include configuring a packet set filter to identify packet flow marks. An application may interact with the network to determine one or more packet filters used to detect (e.g., determine) interdependent delay adjustments (and / or budget fluctuations, for example) on the uplink and / or downlink. A packet filter may include first (e.g., a five-tuple) information containing protocol information (e.g., RTP) and second (e.g., additional) information to detect (e.g., indicate) delay adjustments (and / or budget fluctuations, for example) from the application.

[0200]

[0216] In the third example, a QoS rule may include one or more interdependent round-trip QoS flow parameters, including one of the guaranteed, maximum, range (minimum, maximum) bit rates associated with the forward and / or reverse flows, in order to satisfy one or more expected round-trip / forward-trip / reverse-trip delay budgets. For example, considering delays of 20 milliseconds on the uplink and 30 milliseconds on the downlink, the round-trip delay may be set to 50 milliseconds. The application may have expected latencies that do not exceed motion-to-photon timing in XR applications, for example, to achieve QoE acceptable to the end user.

[0201]

[0217] Example of QoE delay adjustment publicly available for forward / reverse RTP flowmarks.

[0218] Figure 8 shows an example of how QoS / QoE delay adjustments are published in forward / reverse RTP flow marks. In one example, a WTRU can transmit forward / reverse flow marks to publish flow information and adjustments (as described herein) for uplink forward flows to the RAN and / or downlink reverse flows to the UPF.

[0202]

[0219] As shown in 810 of the Application and Network Policy Publication Configuration, the WTRU and server applications can identify forward (e.g., uplink flows) and interdependent reverse (e.g., downlink) flows, and can configure policies for marking forward and reverse flows according to any embodiment described herein. The WTRU and server may be configured to insert and / or replicate selected QoS / QoE information and adjustments.

[0203]

[0220] WTRUs and / or networks may configure, establish and agree to expose interdependent flow information (e.g., characteristics) to either (i) detect (e.g., indicate) interdependent flow information or information element marks, or to detect (e.g., indicate) delay adjustment / variation marks in forward flows and / or reverse interdependent flows, in accordance with any of the following examples.

[0204]

[0221] In the first example, the disclosed interdependent flow information may include a mark indicating the interdependent flow identifier. In the RTP example, the mark may include the triggering RTP header type (e.g., the interdependent flow information identifier).

[0205]

[0222] In the second example, the disclosed interdependent flow information may include forward (e.g., uplink) flow marks. In the RTP example, the forward flow marks may include RTP header types that trigger any delay adjustment requests, as shown in Table 2.

[0206]

[0223] In the third example, the disclosed interdependent flow information may include reverse (e.g., downlink) flow marks. In the RTP example, the reverse flow marks may include RTP header types that trigger any delay adjustment requests, as shown in Table 2.

[0207]

[0224] As shown in 820, the WTRU and / or server may expose interdependent flow information (for example, based on marking information).

[0208]

[0225] As shown in delay measurement 830, the WTRU can measure one or more interdependent flow characteristics (e.g., QoE / QoS delay) according to any embodiment described herein.

[0209]

[0226] As shown in 840 of the delay adjustment, the WTRU can determine the delay budget to request (increment / decrement) from the RAN and / or CN sides for UPF from the (e.g., applicable) measurement and policy settings shown in 810.

[0210]

[0227] As shown in Network Adjustment Marking 850, a WTRU may insert marking information into packets in a forward flow, and the marking information may indicate either a delay adjustment request or a budget change request.

[0211]

[0228] In the first example, the marking information may indicate a request for adjustment of forward link parameters. In the case of RTP, inserting marking information may include inserting an RTP header type, for example, indicating a request for forward delay budget adjustment to the network. In the case of RTP, inserting marking information may further include writing (e.g., inserting) a forward (e.g., uplink) delay adjustment value into either the corresponding RTP header field or bit field.

[0212]

[0229] In the second example, the marking information may indicate a request for adjustment of reverse link (e.g., downlink) parameters. As shown in Table 2, the WTRU may first communicate either delay adjustment and budget variation to the server (e.g., send information to the server indicating either delay adjustment and budget variation) by marking the forward flow for marking adjustment in the reverse flow (e.g., inserting the marking information into the packet). The server may replicate the interdependent flow adjustment received in the forward (e.g., uplink) flow targeting the reverse flow according to any embodiment described herein. In the case of RTP, inserting the marking information may include inserting an RTP header type (e.g., indicating a reverse delay budget adjustment request). In the case of RTP, inserting the marking information may further include writing the received forward (e.g., downlink) adjustment value to the corresponding RTP header field and bit field of the reverse flow.

[0213]

[0230] As shown in Network Policy Enforcement 860, either uplink or downlink policies may be enforced. For example, in the case of uplink policy enforcement, the RAN may be triggered by the receipt of a header type specific to a forward delay budget request. The RAN can obtain the requested uplink policy adjustment and enforce the received requested uplink policy adjustment. For example, in the case of downlink policy enforcement, the UPF may be triggered by the receipt of a header type specific to a reverse delay budget request. The UPF can obtain the requested downlink policy adjustment and enforce the received requested downlink policy adjustment.

[0214]

[0231] Exemplary method including delay measurement and adjustment

[0232] Figure 9 shows an exemplary method for delay measurement and adjustment for interdependent flows. Measurement may be performed, for example, based on timestamp packet marking within the RTP, according to any embodiment described herein. Adjustment may be performed by the network based on either forward or reverse flow marking according to any embodiment described herein.

[0215]

[0233] As shown in 910, the WTRU and the network may interact to configure a delayed publishing policy that includes, for example, a delayed budget and a delayed budget fluctuation threshold.

[0216]

[0234] As shown in 920, WTRU can measure one or more interdependent flow characteristics, such as round-trip delay.

[0217]

[0235] As shown in 930, a WTRU can send a packet containing either measurement request information or timestamp information in a forward flow.

[0218]

[0236] As shown in 931, the server can trigger a measurement request.

[0219]

[0237] As shown in 932, the server may duplicate and / or insert timestamp information in reverse flow.

[0220]

[0238] As shown in 935, it may be determined (e.g., by either the WTRU or the server) that the measured interdependent flow characteristics (e.g., round-trip delay) may not meet the QoS (e.g., delay) budget. For example, the measured interdependent flow characteristics (e.g., round-trip delay) may reach (and / or exceed) a threshold.

[0221]

[0239] As shown in 940, the WTRU can transmit QoS (e.g., delay) adjustment information to the network.

[0222]

[0240] As shown in 941, the network may trigger QoS (e.g., delay) adjustments.

[0223]

[0241] As shown in 942, the network can be tuned for QoS (e.g., latency) characteristics.

[0224]

[0242] As shown in 950, the server may trigger QoS adjustments (e.g., delay) for the reverse flow based, for example, on the receipt of a request from the forward flow.

[0225]

[0243] As shown in 951, the server may duplicate requests (e.g., received from a WTRU) to coordinate a reverse flow.

[0226]

[0244] As shown in 952, the network may trigger delay adjustments in reverse flow (for example, by sending adjustment information).

[0227]

[0245] As shown in 953, the network can be tuned for QoS (e.g., delay) characteristics.

[0228]

[0246] Example of QoS / QoE measurement triggering a core network policy adjustment request

[0247] For example, an application server (e.g., an AF network element) can receive messages from a WTRU indicating round-trip latency measurements. For instance, the application server may determine (e.g., calculate) interdependent flow round-trip latency measurements based on messages received from a WTRU (e.g., a hosted application).

[0229]

[0248] The application server can determine interdependent flow round-trip delay measurements. The application server can determine if the total round-trip time may fail to meet the delay budget conditions related to the configured delay budget (e.g., exceeding the allowable delay amount).

[0230]

[0249] For example, an application server may determine that the round-trip time of interdependent flow measurement may prevent the maintenance of the expected quality of experience, or conversely, that the round-trip time of interdependent flow measurement can be mitigated while, for example, maintaining the expected quality of experience. Based on this determination, the application server may call a 5GC API (e.g., Nnef_AFsessionWithQoS as described in 3GPP TS23.501, “System Architecture for the 5G System (5GS)” (v18.0.0)) to adjust the round-trip delay of interdependent flows assumed by 5GC (e.g., expected by 5GC) (e.g., acceptable). For example, if the application server determines that the measured round-trip delay of interdependent flows exceeds the limit by 2 milliseconds, the application server may call the API to indicate to the network that the (e.g., assumed) round-trip delay of interdependent flows can be reduced by 2 milliseconds. 5GC can determine how to adjust the packet delay budget on either the uplink or downlink path. In another example, if an application server determines that the measured round-trip delay of interdependent flows meets budget conditions (e.g., is within acceptable limits and / or below a threshold), the application server can call a 5GC API (e.g., Nnef_AFsessionWithQoS) to increase the acceptable round-trip delay of interdependent flows that can be assumed (e.g., expected) by 5GC. This can allow 5G systems to have more flexibility regarding how network resources may be used.

[0231]

[0250] Figure 10 shows an exemplary method 1000 for delay measurement and adjustment for interdependent flows. Method 1000 can be implemented in a WTRU. The WTRU may include, for example, a circuit that includes a processor, memory operably coupled to the processor, a transmitter and a receiver (e.g., a transceiver) to perform Method 1000. In one example, the WTRU may transmit request information to a first network element indicating a request to enforce a replication policy for information associated with a first flow and a second flow. In various embodiments, the first flow and the second flow may be interdependent. In one example, the WTRU may receive acknowledgment information from the first network element to acknowledge the request information. As shown in 1010, the WTRU may transmit first information in the first flow to the first network element. As shown in 1020, the WTRU may receive replicated first information from the second flow from the first network element. In various embodiments, the interdependent first and second flows may be associated with an application. As shown in 1030, the WTRU can determine one or more interdependent flow characteristics associated with the first and second flows based on the first information and the replicated first information. In various embodiments, the WTRU may determine that the interdependent flow characteristics can satisfy, for example, the QoS budget conditions associated with the application. As shown in 1050, based on the determination that the interdependent flow characteristics can satisfy the QoS budget conditions, the WTRU may transmit, for example, second information (e.g., associated) indicating one or more interdependent flow characteristics to a second network element.

[0232]

[0251] In various embodiments, the request information may represent one or more first flow parameters, one or more second flow parameters, and one or more action rule parameters.

[0233]

[0252] In various embodiments, the first information may include timestamp information indicating the time when a first packet containing the first information may have been transmitted.

[0234]

[0253] In various embodiments, the first information may include interdependent flow mark information that identifies a first packet that may have contained the first information.

[0235]

[0254] In various embodiments, one or more interdependent flow characteristics may include forward trip delay, reverse trip delay, and round trip delay.

[0236]

[0255] In various embodiments, the second information may be transmitted to a second network element that may differ from the first network element (for example, either a RAN or a core network).

[0237]

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

[0238]

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

[0239]

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

[0240]

[0259] In various embodiments, the second information may further indicate network policy adjustment requests associated with either the first or second flow.

[0241]

[0260] In various embodiments, the WTRU may determine that the interdependent flow characteristics can satisfy the QoS budget conditions.

[0242]

[0261] In various embodiments, the second information may be transmitted (for example, to a second network element) based on interdependent flow characteristics that satisfy QoS budget conditions.

[0243]

[0262] In various embodiments, the requested network policy adjustment may be associated with a first delay adjustment for a first flow.

[0244]

[0263] In various embodiments, the requested network policy adjustment may be associated with a second delay adjustment for a second flow.

[0245]

[0264] In various embodiments, interdependent flow characteristics may include latency. In various embodiments, interdependent flow characteristics may satisfy a QoS budget condition (e.g., associated with an application) when the latency exceeds a first threshold. In various embodiments, the requested network policy adjustment may include reducing latency in either the first or second flow.

[0246]

[0265] In various embodiments, interdependent flow characteristics may include latency. In various embodiments, interdependent flow characteristics may satisfy a QoS budget condition (e.g., associated with an application) if the latency falls below a second threshold. In various embodiments, the requested network policy adjustment may include mitigating (e.g., reducing, decreasing) latency in either the first or second flow.

[0247]

[0266] Any characteristics, variations, or embodiments described with respect to the method are compatible with apparatus devices including means for processing the disclosed method, processors, devices including transmitters and receivers operably coupled to a processor and configured to process the disclosed method, computer program products including program code instructions, and non-temporary computer-readable storage media for storing program instructions.

[0248]

[0267] While the above provides characteristics and elements in specific combinations, those skilled in the art will understand that each characteristic or element can be used individually or in any combination with other characteristics and elements. This disclosure should not be limited to the specific embodiments described in this application, which are intended as examples of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from the spirit and scope. Elements, actions or instructions used in the description of this application should not be construed as important or essential to the invention unless so expressly provided. In addition to those enumerated herein, functionally equivalent methods and apparatus within the scope of this disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to be included in the appended claims. This disclosure should be limited only by the appended claims and the entire scope of equivalents to which such claims are entitled. It should be understood that this disclosure is not limited to any particular method or system.

[0249]

[0268] For the sake of simplicity, the embodiments described above have discussed the terminology and structure of infrared-compatible devices, i.e., infrared emitters and receivers. However, the embodiments discussed are not limited to these systems and may be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves such as acoustic waves.

[0250]

[0269] It should also be understood that the terms used herein are intended only to illustrate specific examples and are not intended to be limiting. Where used herein, the terms “video” or “image” may mean any of a snapshot, a single image, and / or multiple images displayed on a time basis. As another example, where referred herein, the terms “user equipment” and its abbreviation “UE,” the terms “remote” and / or the terms “head-mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmit and / or receive unit (WTRU), (ii) any of a number of embodiments of a WTRU, (iii) a wireless and / or wired (e.g., tetherable) device comprising some or all of the structures and functions of a WTRU, (iii) a wireless and / or wired device comprising structures and functions less than all of the structures and functions of a WTRU, or (iv) similar. Details of exemplary WTRUs that may represent any WTRU enumerated herein are provided herein with respect to Figures 1A to 1D. As another example, the various embodiments disclosed above and below in this specification are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays may be used, and that some or all of the disclosed and various embodiments may be modified as appropriate without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide a tailored reality experience.

[0251]

[0270] In addition, the methods described herein may be implemented in computer programs, software, or firmware embedded in a computer-readable medium for execution by a computer or processor. Examples of computer-readable mediums include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital multi-purpose disks (DVDs). A processor may be used, together with software, to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0252]

[0271] Modifications of the methods, apparatus, and systems provided above are possible without departing from the scope of the present invention. Considering the diverse range of applicable embodiments, it should be understood that the exemplary embodiments are merely examples and should not be construed as limiting the scope of the following claims. For example, embodiments provided herein include a handheld device, which may include or be used with any suitable voltage source, such as a battery, providing any suitable voltage.

[0253]

[0272] Furthermore, in the embodiments described above, other devices including processing platforms, computing systems, controllers, and processors may be noted. These devices may include at least one central processing unit ("CPU") and memory. In accordance with the practice of those skilled in the art of computer programming, references to symbolic representations of actions and behaviors or instructions may be carried out by various CPUs and memories. Such actions and behaviors or instructions may be referred to as "executed," "computer-executed," or "CPU-executed."

[0254]

[0273] Those skilled in the art will understand that actions and symbolically represented operations or instructions involve the manipulation of electrical signals by the CPU. An electrical system represents data bits that, as a result, can cause the transformation or reduction of electrical signals and the retention of data bits at memory locations within a memory system, thereby reconfiguring or modifying the CPU's operation and other signal processing. A memory location where data bits are retained is a physical location having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the methods provided.

[0255]

[0274] Data bits may 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 systems readable by a CPU. Computer-readable media may include collaborative or interconnected computer-readable media that reside exclusively on a processing system or are distributed among multiple interconnected processing systems, which may be local or remote to the processing system. It should be understood that embodiments are not limited to the memory described above, and other platforms and memories may support the methods provided.

[0256]

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

[0257]

[0276] There is little distinction between hardware and software implementations of a system configuration. The use of hardware or software is generally a design choice representing a trade-off between cost and efficiency (though not always, as in certain situations the choice between hardware and software may be important). Various media can be used to achieve the processes, and / or systems, and / or other technologies described herein (e.g., hardware, software, and / or firmware), and the preferred medium may vary depending on the context in which the processes, and / or systems, and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are paramount, they may primarily choose hardware and / or firmware media. If flexibility is the top priority, the implementer may primarily choose software implementation. Alternatively, the implementer may choose any combination of hardware, software, and / or firmware.

[0258]

[0277] In the detailed description above, various embodiments of the apparatus and / or process have been illustrated using block diagrams, flowcharts and / or examples. To the extent that such block diagrams, flowcharts and / or examples include one or more functions and / or operations, it will be understood by those skilled in 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 substantially any combination thereof. In one embodiment, some parts of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs) and / or other integrated formats. However, a person skilled in the art will recognize that some aspects of the embodiments disclosed herein can be implemented, in whole or in part, equally 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 substantially any combination thereof, and that designing circuits and / or writing software and / or firmware code is well within the skill of a person skilled in the art in view of this disclosure. In addition, a person skilled in the art will understand that the mechanisms of the subject matter described herein can be delivered as various forms of program products, and that exemplary embodiments of the subject matter described herein apply regardless of the specific type of signal-carrying medium used to actually carry out the delivery. Examples of signal-carrying mediums include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, and computer memory, and transmission media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0259]

[0278] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes as described herein and then, using engineering practice, to integrate such described devices and / or processes into data processing systems. That is, at least some of the devices and / or processes described herein can be integrated into data processing systems through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system may generally include a system unit housing, video display devices, memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, computing entities such as operating systems, drivers, graphical user interfaces and application programs, one or more interaction devices such as touchpads or screens and / or feedback loops, and one or more control systems including control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented using any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0260]

[0279] The subject matter described herein may include different components that are contained within or connected within other different components. Such illustrated architectures are merely examples, and it should be understood that in practice, many other architectures can be implemented to achieve the same function. Conceptually, any arrangement of components to achieve the same function is substantially "associated" in such a way that the desired function can be achieved. Therefore, any two components combined to achieve a particular function, regardless of architecture or intermediate components, can be considered "associated" with each other in such a way that the desired function is achieved. Similarly, any two components thus associated can also be considered "operably connected" or "operably coupled" with each other to achieve the desired function, and any two components that can be associated in such a way can also be considered "operably coupled" with each other to achieve the desired function. Specific examples of operably coupled components include, but are not limited to, physically matable and / or physically interacting components, and / or wirelessly interactable and / or wirelessly interacting components, and / or logically interacting and / or logically interactable components.

[0261]

[0280] With regard to virtually all use of plural and / or singular terms herein, those skilled in the art can paraphrase from plural to singular and / or singular to plural as appropriate to the context and / or use. For clarity, various singular / plural substitutions may be explicitly stated herein.

[0262]

[0281] In general, it will be understood by those skilled in the art that the terms used herein, and in particular in the appended claims (e.g., the text of the appended claims), are generally intended to be “open” terms (for example, the term “contains” should be interpreted as “contains but not limited,” the term “has” should be interpreted as “has at least one,” and the term “contains” should be interpreted as “contains but not limited,” etc.). Furthermore, if the description of an introduced claim is intended to be a certain number, such intention will be explicitly stated in the claim, and if such statement is not present, it will be understood by those skilled in the art that such intention does not exist. For example, if only one item is intended, the term “single” or a similar term may be used. For the sake of understanding, the following descriptions in the appended claims and / or herein may include the use of the introductory phrases “at least one” and “one or more” to introduce the description of a claim. However, the use of such phrases should not be interpreted as implying that any particular claim containing such introduced claims is limited to only one embodiment containing such introduced claims, even if the same claim contains the introductory phrase "one or more" or "at least one" and an indefinite article such as "one or more" or "one or one" (for example, "one or one" and / or "one or one" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claims. In addition, even if a particular number of introduced claims is explicitly stated, a person skilled in the art will recognize that such a statement should be interpreted as meaning at least the stated number (for example, a literal enumeration of "two lists" without other modifying phrases means at least two lists or two or more lists).Furthermore, when expressions similar to "at least one of A, B, and C" are used, such structures are generally intended to be understood by those skilled in the art (for example, "a system having at least one of A, B, and C" would include, but is not limited to, A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together). When expressions similar to "at least one of A, B, or C" are used, such structures are generally intended to be understood by those skilled in the art (for example, "a system having at least one of A, B, or C" would include, but is not limited to, A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together). Furthermore, it will be understood by those skilled in the art that virtually any separating words and / or phrases presenting two or more alternative terms should be understood as construing the possibility of including one of the terms, either or both of the terms, whether in descriptions, claims, or drawings. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.” Furthermore, the term “any,” as used herein, followed by a list of multiple items and / or multiple item categories, is intended to include “any one,” “any combination,” “any multiple,” and / or “any combination of multiples” of items and / or categories of items, individually or in conjunction with other items and / or other item categories. Furthermore, the term “set,” as used herein, is intended to include any number of items, including zero. Furthermore, the term “number,” as used herein, is intended to include any number, including zero. Also, the term “multiple,” as used herein, is intended to be synonymous with “multiple.”

[0263]

[0282] In addition, if any characteristics or aspects of the disclosure are described from the perspective of the Markush group, a person skilled in the art will recognize that the disclosure is also described from the perspective of any individual member or subgroup of the members of the Markush group.

[0264]

[0283] As will be understood by those skilled in the art, for all purposes, for example from the perspective of providing a written description, all ranges disclosed herein include any possible sub-ranges and combinations of those sub-ranges. Any recited range can be readily recognized as being fully described and enabling the same range to be divided, for example, into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range described herein can be readily broken down into, for example, lower thirds, middle thirds, and upper thirds. Similarly, as will be understood by those skilled in the art, all language such as "up to", "at least", "greater than", "less than", etc. refers to a range that includes the recited number and can be subsequently divided into sub-ranges as described above. Finally, as will be understood by those skilled in the art, a range includes each individual member. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, etc.

[0265]

[0284] Further, the claims should not be read as being limited to the order or elements provided unless the contrary is stated. Further, the use of the term "means for" in any claim is intended to invoke 35 U.S.C. § 112, paragraph 6 or a means-plus-function claim format, and no claim without the term "means for" is so intended.

Claims

1. A wireless transmit / receive unit (WTRU) including a circuit, wherein the circuit is Sending request information to a first network element indicating a request to implement a replication policy for information associated with the first flow and the second flow, wherein the first flow and the second flow are interdependent, The first network element receives acknowledgment information to acknowledge the request information, Transmitting the first information in the first flow to the first network element, The first network element receives the first information replicated from the second flow, Based on the first information and the replicated first information, one or more interdependent flow characteristics associated with the first flow and the second flow are determined, Transmitting to a second network element the second information indicating one or more interdependent flow characteristics. A wireless transmit / receive unit (WTRU) configured to perform the following actions.

2. The WTRU according to claim 1, wherein the requested information indicates one or more first flow parameters, one or more second flow parameters, and one or more action rule parameters.

3. The WTRU according to claim 1 or 2, wherein the first information includes timestamp information indicating the time when the first packet containing the first information was transmitted.

4. The WTRU according to claim 1 or 2, wherein the first information includes interdependent flow mark information that identifies a first packet containing the first information.

5. The WTRU according to any one of claims 1 to 4, wherein the one or more interdependent flow characteristics include a forward trip delay, a reverse trip delay, and a round trip 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, and the circuit configured to transmit the second information includes the circuit configured to insert the second information into a second packet of the first flow directed to the first network element, and the second information is intercepted by a third network element responsible for processing either the first flow or the second flow 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 flow is associated with the second flow.

9. The WTRU according to any one of claims 1 to 8, wherein the second information further indicates 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 the interdependent flow characteristics satisfy the QoS budget condition.

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

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

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 flow.

15. The WTRU according to any one of claims 11 to 14, wherein the interdependent flow characteristics include a delay, the interdependent flow characteristics satisfy the QoS budget condition when the delay exceeds a first threshold, and the requested network policy adjustments include reducing 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 a delay, the interdependent flow characteristics satisfy the QoS budget condition if the delay falls below a second threshold, and the requested network policy adjustments include mitigating latency in either the first flow or the second flow.

17. A method implemented in a wireless transmitter / receiver unit (WTRU), Sending request information to a first network element indicating a request to implement a replication policy for information associated with the first flow and the second flow, wherein the first flow and the second flow are interdependent, The first network element receives acknowledgment information to acknowledge the request information, Transmitting the first information in the first flow to the first network element, The first network element receives the first information replicated from the second flow, Based on the first information and the replicated first information, one or more interdependent flow characteristics associated with the first flow and the second flow are determined, Transmitting to a second network element the second information indicating one or more interdependent flow characteristics. A method that includes this.

18. The method according to claim 17, wherein the requested information indicates one or more first flow parameters, one or more second flow parameters, and one or more action rule parameters.

19. The method according to claim 17 or 18, wherein the first information includes timestamp information indicating the time when a first packet containing the first information was transmitted.

20. The method according to claim 17 or 18, wherein the first information includes interdependent flow mark information that identifies a first packet containing the first information.

Images