RAN Support for XR Applications

Abstract

Systems, methods, and means for assistance to a radio area network (RAN) for an augmented reality (XR) application are described herein. A wireless transmit / receive unit (WTRU) can be configured to receive a configuration message from a network node. The configuration message can indicate a connected mode discontinuous reception (CDRX) active duration, can indicate that the CDRX active duration may be extended, and can determine uplink augmented reality media (XRM) data to be sent to the network node. The WTRU can determine an amount of time for extending the CDRX active duration based on properties of the uplink XRM data. The WTRU can send assistance information to the network node. The assistance information can indicate a request to extend the CDRX active duration by an amount of time.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 324,463, filed March 28, 2022, the disclosure of which is incorporated herein by reference in its entirety. [Background technology]

[0002] Mobile communications using wireless communications continue to evolve. The fifth generation of mobile communications radio access technology (RAT) may be referred to as 5G new radio (NR). The previous (conventional) generation of mobile communications RAT may be, for example, fourth generation (4G) long term evolution (LTE). Summary of the Invention

[0003] Systems, methods, and means for radio area network (RAN) support for eXtended Reality (XR) applications are described herein.

[0004] A wireless transmit / receive unit (WTRU) may be configured to receive a configuration message from a network node. The configuration message may indicate a connected mode discontinuous reception (CDRX) active duration (e.g., a first CDRX active duration) and may indicate that the CDRX active duration may be extended. The WTRU may determine uplink data (e.g., uplink extended reality media (XRM) data) to be sent to the network node. The WTRU may determine a length of time for extending the first CDRX active duration based on properties of the uplink XRM data. The WTRU may send assistance information to the network node. The assistance information may indicate a request to extend the first CDRX active duration by a length of time. The WTRU may receive a confirmation message from the network node. The confirmation message may indicate a second CDRX active duration. The WTRU may receive (eg, monitor) a physical downlink control channel (PDCCH) transmission during the second CDRX active duration.

[0005] In an embodiment, the second CDRX active duration may be equal to the first CDRX active duration extended by the requested amount of time, or may be a different CDRX active duration than the first CDRX active duration extended by the requested amount of time. The second CDRX active duration may be measured relative to one or more of a number of CDRX cycles, a duration in ms, a duration in symbols, a duration in slots, a duration in subframes, a duration in frames, the start of another CDRX cycle, or a duration indicated by the WTRU.

[0006] In an embodiment, the property of the uplink data may indicate that the uplink data includes uplink attitude information. The property of the uplink data may indicate a motion-to-photon (MTP) parameter or a total round-trip time parameter. In an embodiment, the MTP parameter or the total round-trip time parameter may be based on a configured MTP latency requirement. In an embodiment, the MTP parameter or the total round-trip time parameter may be based on header information included with the uplink data. In an embodiment, the length of time to extend the first CDRX active duration may be determined based on a difference between the MTP parameter and a time remaining in the first CDRX active duration.

[0007] In an embodiment, the WTRU may be further configured to receive downlink XRM data from the network during the extended CDRX active duration, the downlink XRM data being received in response to the uplink data, and the WTRU may be further configured to send the uplink data to the network node during the second CDRX active duration.

[0008] The network node may be configured to determine an uplink packet delay budget (PDB) value associated with a first quality of service (QoS) flow and a downlink PDB value associated with a second QoS flow. The uplink PDB value and the downlink PDB value may be equal. The network node may determine a packet delay for the first QoS flow and the second QoS flow. The network node may adjust the uplink PDB value and the downlink PDB value based on the packet delay. The network node may modify at least one of a QoS profile, a QoS rule, or a service data flow (SDF) template based on the adjustment.

[0009] In an embodiment, based on the packet delays obtained for the first QoS and the second QoS flow, the network node may determine that the uplink PDB value is too low. Based on the uplink PDB value being too low, the network node may increase the uplink PDB value and decrease the downlink PDB value. In an embodiment, based on the packet delays obtained for the first QoS and the second QoS flow, the network node may determine that the uplink PDB value is too high. Based on the uplink PDB value being too high, the network node may decrease the uplink PDB value and increase the downlink PDB value. In an embodiment, based on the packet delays obtained for the first QoS and the second QoS flow, the network node may determine that the downlink PDB value is too low. Based on the downlink PDB value being too low, the network node may decrease the uplink PDB value and increase the downlink PDB value. In an embodiment, based on the packet delays obtained for the first QoS and the second QoS flow, the network node may determine that the downlink PDB value is too high. Based on the downlink PDB value being too high, the network node may increase the uplink PDB value and decrease the downlink PDB value. [Brief description of the drawings]

[0010] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1A is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] 1 is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Diagram 2] 1 illustrates an example of energy consumption for different WTRU activities. [Diagram 3] Illustrates an example of a DRX cycle. The CDRX parameters can be used to configure a short CDRX cycle and / or a long CDRX cycle. [Figure 4] Illustrate an example virtual reality (VR) use case. [Diagram 5] Illustrate an example of CDRX timing. [Figure 6] Illustrate an example of CDRX jitter. [Figure 7] Illustrate examples of frame sizes. [Figure 8] Illustrates an example of uplink / downlink (UL / DL) cooperation. [Figure 9] Illustrates examples of one or more goals for conserving power. [Figure 10] 1 illustrates an example of power savings for a WTRU. [Figure 11] 1 illustrates example transmission options for assistance information from a WTRU. [Figure 12] 1 illustrates an example of linked Quality of Service (QoS) flows for extended reality (XR) / media services. [Figure 13] 1 illustrates an example of a linked QoS flow using one or more QoS Flow Id (QFI) lists. [Figure 14] 1 illustrates an example of a WTRU configured to periodically change a starting offset time for CDRX to align with data reception based on an applied frame rate for the data. [Figure 15]1 illustrates an example where a WTRU changes the On / Active duration in a subsequent CDRX cycle when it detects a trigger event during a CDRX cycle. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0012] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station" and / or "STA," may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, wireless paging, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (loT) devices, watches or other wearable head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

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

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

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

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

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

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

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

[0020] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0021] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as an office, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.11, to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.15, to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0022] The RAN 104 / 113 may communicate with the CN 106 / 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 of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as, for example, different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high level security functions such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0023] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may use the same RAT as the RANs 104 / 113 or a different RAT.

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

[0025] Figure 1B is a system diagram illustrating an example 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 source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0026] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0027] The transmit / receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) over the air 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 IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

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

[0030] The processor 118 of the WTRU 102 may be coupled to and may receive user-entered data from 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). 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 and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

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

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

[0033] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

[0035] 1C is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As mentioned above, the RAN 104 may use E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

[0036] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0037] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As shown in FIG 1C, the eNodeBs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0038] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0039] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0040] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNodeB handover, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

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

[0042] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 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.

[0043] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, in certain representative embodiments, it is contemplated that such a terminal may use a wired communications interface (e.g., temporarily or permanently) with the communications network.

[0044] In an exemplary embodiment, the other network 112 may be a WLAN.

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

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

[0047] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

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

[0049] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including certain capabilities, for example, support for (e.g., support only for) certain and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0050] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a 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 configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah embodiment, the primary channel may be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration may depend on the status of the primary channel. For example, if the primary channel is active due to a STA (that only supports the 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered active even though most of the frequency band may remain dormant and available.

[0051] In the United States, the available frequency bands that can be used by 802.11ah are 902MHz to 928MHz. In South Korea, the available frequency bands are 917.5MHz to 923.5MHz. In Japan, the available frequency bands are 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz depending on the country code.

[0052] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As mentioned above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 113 may also communicate with the CN 115.

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

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

[0055] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0056] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

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

[0058] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. The network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0059] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

[0061] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 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 an embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0062] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0063] The emulation device may be designed to implement one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and / or may use terrestrial wireless communication to implement the tests.

[0064] The one or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0065] References herein to a timer may refer to determining a time or determining a period of time. References herein to a timer expiry may refer to determining that a time has occurred or that a time period has expired. References herein to a timer may refer to a time, a time period, a tracking time, a tracking time period, etc. References to legacy technology or legacy handover may refer to legacy technology or legacy versions of technology such as LTE compared to NR, e.g., an earlier version / release of technology (e.g., an earlier NR release) compared to a later version / release of technology (e.g., a later NR release).

[0066] References herein to specific I, B, and P frame types for video transmission are exemplary frame types. I-frames may be understood as a frame type that is a reference frame. A reference frame may be a frame of compressed video that is used to define future frames. A reference frame may rely on intraframe compression techniques. B-frames and P-frames may be understood as non-reference frames that may rely on interframe coding with a reference frame. P-frames may be coded from previous I-frames and / or P-frames. B-frames may be coded from previous or future I-frames.

[0067] Systems, methods, and means for support in a Radio Area Network (RAN) for Extended Reality (XR) applications are described herein.

[0068] A wireless transmit / receive unit (WTRU) may be configured to receive a configuration message from a network node. The configuration message may indicate a connected mode discontinuous reception (CDRX) active duration (e.g., a first CDRX active duration) and may indicate that the CDRX active duration may be extended. The WTRU may determine uplink data (e.g., uplink augmented reality media (XRM) data) to be sent to the network node. The WTRU may determine a length of time for extending the first CDRX active duration based on properties of the uplink XRM data. The WTRU may send assistance information to the network node. The assistance information may indicate a request to extend the first CDRX active duration by a length of time. The WTRU may receive a confirmation message from the network node. The confirmation message may indicate a second CDRX active duration. The WTRU may receive (e.g., monitor) a physical downlink control channel (PDCCH) transmission during the second CDRX active duration.

[0069] In an embodiment, the second CDRX active duration may be equal to the first CDRX active duration extended by the requested amount of time, or may be a different CDRX active duration than the first CDRX active duration extended by the requested amount of time. The second CDRX active duration may be measured relative to one or more of a number of CDRX cycles, a duration in ms, a duration in symbols, a duration in slots, a duration in subframes, a duration in frames, the start of another CDRX cycle, or a duration indicated by the WTRU.

[0070] In an embodiment, the property of the uplink data may indicate that the uplink data includes uplink attitude information. The property of the uplink data may indicate a motion-to-photon (MTP) parameter or a total round trip time parameter. In an embodiment, the MTP parameter or the total round trip time parameter may be based on a configured MTP latency requirement. In an embodiment, the MTP parameter or the total round trip time parameter may be based on header information included with the uplink data. In an embodiment, the length of time to extend the first CDRX active duration may be determined based on a difference between the MTP parameter and a time remaining in the first CDRX active duration.

[0071] In an embodiment, the WTRU may be further configured to receive downlink XRM data from the network during the extended CDRX active duration, the downlink XRM data being received in response to the uplink data. The WTRU may be further configured to send the uplink data to the network node during the second CDRX active duration.

[0072] The network node may be configured to determine an uplink packet delay budget (PDB) value associated with a first Quality of Service (QoS) flow and a downlink PDB value associated with a second QoS flow. The uplink PDB value and the downlink PDB value may be equal. The network node may determine packet delay for the first QoS flow and the second QoS flow. The network node may adjust the uplink PDB value and the downlink PDB value based on the packet delay. The network node may modify at least one of a QoS profile, a QoS rule, or a service data flow (SDF) template based on the adjustment.

[0073] In an embodiment, based on the packet delays obtained for the first QoS and the second QoS flow, the network node may determine that the uplink PDB value is too low. Based on the uplink PDB value being too low, the network node may increase the uplink PDB value and decrease the downlink PDB value. In an embodiment, based on the packet delays obtained for the first QoS and the second QoS flow, the network node may determine that the uplink PDB value is too high. Based on the uplink PDB value being too high, the network node may decrease the uplink PDB value and increase the downlink PDB value. In an embodiment, based on the packet delays obtained for the first QoS and the second QoS flow, the network node may determine that the downlink PDB value is too low. Based on the downlink PDB value being too low, the network node may decrease the uplink PDB value and increase the downlink PDB value. In an embodiment, based on the packet delays obtained for the first QoS and the second QoS flow, the network node may determine that the downlink PDB value is too high. Based on the downlink PDB value being too high, the network node may increase the uplink PDB value and decrease the downlink PDB value.

[0074] The assistance information may be provided by the WTRU to assist the network. The assistance information may be used by the network or by the WTRU to select between one or more connected mode discontinuous reception (CDRX) configurations. The assistance information may be used by the network or by the WTRU to minimize wasteful over-the-air transmissions. The assistance information may be provided by a user plane function (UPF), an access stratum (AS), or a network data analytics function (NWDAF) to assist the network in optimizing the CDRX configuration. A mechanism may be provided to signal the assistance information from the WTRU to the network. A PDU header (e.g., a new PDU header) in a quality of service (QoS) flow may enable the assistance information to be sent between the WTRU and the network.

[0075] A mechanism may be provided for linking QoS flows. A mechanism may be provided that can be provided to address stringent round trip time (RTT) requirements for linked QoS flows. The mechanism determines when to send uplink (UL) traffic based on a transmission (e.g., preferred transmission) opportunity and the QoS characteristics of the QoS flows. A mechanism may be provided for the WTRU to change the CDRX configuration based on one or more metrics or events. A mechanism may be provided for the WTRU to select a CDRX configuration (e.g., a new CDRX configuration) based on one or more metrics or events.

[0076] Examples of CDRX may be provided herein. A WTRU (e.g., a typical WTRU) may be involved in activities (e.g., several activities) during its normal operation. The activities may be divided into five broad categories: deep sleep, periodic activities in idle mode, periodic activities in connected mode, data transmission and reception, and control channel monitoring (e.g., while in connected mode or while in connected mode during the CDRX active duration). In an embodiment, control channel monitoring may refer to an activity in which the WTRU cannot be involved in any uplink or downlink data transmission, but can monitor a control channel, such as a PDCCH transmission, and receive DCI from a RAN node. In an embodiment, control channel monitoring may refer to receiving a PDCCH transmission during an extended active duration. Examples of DCI include DL and / or UL scheduling information. Power consumption studies have shown that the WTRU may consume a large amount of power during this latter activity.

[0077] FIG. 2 illustrates an example of energy consumption for different WTRU activities. As shown in FIG. 2, control channel monitoring may account for approximately 55% of the WTRU power consumption (even though it may account for less than 10% of the WTRU's activity). To address this power consumption, the network may configure connected mode DRX for the WTRU. CDRX may control when the WTRU stops PDCCH monitoring (e.g., to save power). CDRX may have an on-off cycle, during which the WTRU may monitor the PDCCH during the on duration and the WTRU may stop monitoring the PDCCH during the off duration. The network may indicate that DCI cannot be sent to the WTRU during the WTRU's off duration. The on duration of the cycle, also known as the active time, may be variable. The on duration of the cycle may be extended based on UL or DL ​​activity. In some technologies, such as NR, WTRU support for CDRX may be required, but WTRU activation and configuration may be controlled by the RAN node through RRC signaling. If the RAN node configures CDRX, it may be considered active and the WTRU may follow the CDRX for power savings.

[0078] FIG. 3 illustrates an example of a discontinuous reception (DRX) cycle. CDRX parameters can be used to configure a short CDRX cycle and a long CDRX cycle. The start time of the on-period of the long CDRX cycle and the periodicity of these on-periods can be controlled by a configurable parameter (drx-LongCycleStartOffset) (shown in FIG. 3 as "On-Period Start Offset" and "Long Cycle Duration"). The configurable parameter "On-Period Start Offset" can allow the RAN node to spread out the on-periods of different WTRUs in time. This can provide the RAN node with some flexibility in scheduling these different WTRUs. The short CDRX cycle can have a maximum duration controlled by a short cycle timer. If the short cycle timer expires, the long cycle can be used (e.g., as shown between 0 and t1 in FIG. 3).

[0079] The on-duration may be provided by a CDRX parameter drx-onDurationTimer. If (e.g., at any time) the WTRU is monitoring the DCI and receives a DL transmission (e.g., a new DL transmission), the WTRU may start or restart an inactivity timer (drx-InactivityTimer). The inactivity timer may be associated with a duration. The duration associated with the inactivity timer may extend the active duration of the WTRU (e.g., the active time at time t2 shown in FIG. 3). The extended active duration (e.g., extended active time) may allow the WTRU to wake up and receive any potential retransmissions. The extended active time may allow (e.g., may allow) some flexibility in the RAN node in sending additional transport blocks to the WTRU (e.g., because the RAN node may have more than one transport block waiting to be transmitted to the WTRU). If the active time is extended, if a short CDRX cycle is configured, the subsequent cycle may start as a short CDRX cycle. The subsequent cycle may start (e.g., may alternatively start) as a long CDRX cycle.

[0080] The configuration of the CDRX parameters may allow the RAN node to trade off WTRU power savings against latency. In an embodiment, CDRX parameters that result in a large off period may provide significant power savings to the WTRU. However, if the RAN node happens to miss a WTRU active time, the RAN node may wait until the next active time to communicate with the WTRU. If the CDRX parameters are configured to result in a large active time (e.g., in contrast), the RAN node may be able to communicate with the WTRU (e.g., more easily). However, the power saving gain may be minimized. In such a case, if the RAN node knows that no additional communications to the WTRU are pending, the RAN node may send a control message to the WTRU during the WTRU's active time. This control message may inform the WTRU to shorten its active time and immediately go to an off period. This may be accomplished through the MAC CE (e.g., as shown in FIG. 3 at time t3).

[0081] CDRX may be a MAC procedure and may be considered a property of the WTRU. CDRX may not be related to any particular data radio bearer (DRB) or signaling radio bearer (SRB) that may be configured for the WTRU. CDRX may apply to configured DRBs and SRBs (e.g., to all configured DRBs and SRBs). The configured CDRX parameters may not be tied (e.g., may not be tightly coupled) to the characteristics of the traffic to or from the WTRU.

[0082] The serving cells of the MAC entity may be configured by the RRC in a DRX group (e.g., two DRX groups) with DRX parameters (e.g., separate DRX parameters). If DRX groups (e.g., two DRX groups) are configured, each serving cell may be assigned (e.g., uniquely assigned) to one of the groups (e.g., two groups).

[0083] In addition to the on / off pattern (e.g., as illustrated in FIG. 3), there may be an opportunity for a microsleep period. In an embodiment, after the WTRU receives a transport block but fails to decode it, the WTRU may request a retransmission. There may be a delay before the gNB can send a retransmission. During this delay, the WTRU may go into microsleep. The microsleep may be managed by timers (e.g., two additional timers, such as a hybrid automatic repeat request (HARQ) RTT timer and a HARQ retransmission timer).

[0084] Table 1 below shows possible values ​​for the configurable CDRX parameters.

[0085] [Table 1]

[0086] 4 illustrates an example of a virtual reality (VR) use case. Examples of the use case and exemplary media characteristics may be provided herein. In a VR use case (e.g., as shown in FIG. 4), where the WTRU may be a VR headset and a video feed for the VR headset may be provided by an application server, communication between the VR headset may occur over a network (e.g., a 5G network).

[0087] An example of a VR use case is described below: A user may change posture. In an embodiment, a user may rotate his / her head. Posture information may be captured by a sensor. The posture information may be sent to an application server as UL information. The application server may process the posture information and generate VR information (e.g., new VR information) for the headset. The VR information generated by the application server may include both video and audio frames. The application server may generate (e.g., may also generate) other user plane data. The video frames, audio frames, and user plane data may be sent to the VR headset as downlink information. The VR headset may process the video and audio frames, which may be provided to the user.

[0088] In an example use case, a VR headset may require and / or use both uplink and downlink transmissions. Example characteristics of traffic in a VR use case may be one or more of the following: - Uplink attitude information: Typically small, but periodic (e.g., every 4 ms). - Downlink video information: mostly consists of video frames. The frame rate may depend on the quality (e.g. 60 / 90 / 120 frames per second (fps)). The size of the frames may be variable and may be very large. The importance of the frames may be variable, i.e. some video frames may be more important than others. - Downlink audio information: Typically periodic (e.g., every 20 ms), with little variation in size, and usually small.

[0089] In some cases (e.g., changes in posture information), DL transmissions may be triggered by UL transmissions. In order for the end user to have good QoE, there may be a latency requirement between the physical movement of the user's head, which may result in a change in posture information (sometimes referred to as motion), and the updated images (sometimes referred to as photons) in the VR headset. There may also be a latency requirement (e.g., similarly) between the physical movement of the user's head (motion) and the updated sound waves (sometimes referred to as "sound") from the head-mounted speakers reaching the end user's ears. Exemplary characteristics may be one or more of: a motion-to-photon latency in the range of 7ms to 15ms, and a motion-to-sound latency of <20ms, while maintaining a required resolution of up to 8K, giving a user data rate of up to 1Gbit / s.

[0090] An example of QoS may be provided (e.g., QoS in 5GS). In an embodiment (e.g., in 5GS), QoS granularity may be applied per QoS flow. A QoS flow may be the lowest level of granularity in a system (e.g., a 5G system) and may be where policies and charging are enforced. QoS parameters and characteristics may be associated with a QoS flow. Each QoS flow may be identified by a QFI, which may be unique within a packet data unit (PDU) session. The RAN node may establish a DRB for each QoS flow, or the RAN node may combine two or more QoS flows into the same DRB. One or more SDFs, e.g., IP flows, may be mapped to a QoS flow. Traffic (e.g., all traffic) within the same QoS flow may receive the same treatment.

[0091] The QoS characteristics of a QoS flow may include a packet data budget (PDB) and a packet error rate (PER). The PDB may provide (e.g., define) an upper bound on when packets may be delayed between the WTRU and a user plane function (UPF). The PER may provide (e.g., define) an upper bound on the rate of PDUs (e.g., IP packets) that are processed by a transmitter of a link layer protocol but not successfully delivered to upper layers by a corresponding receiver.

[0092] Improved power savings may be provided. CDRX may be a static configuration procedure. The WTRU may be configured with a single DRX configuration for the serving cell, on cycle, timer, etc. This static configuration may not be suitable for XR / media services. This may result in at least four problems: timing problems, jitter problems, frame size problems, and UL / DL coordination problems. Enhancements may be needed to provide assistance to the RAN nodes to minimize the adverse effects of these problems and maximize power savings for XR / media services.

[0093] FIG. 5 illustrates an example of CDRX timing. Improvements to address CDRX timing may be provided herein. FIG. 5 shows a VR headset use case with three service data flows (posture, video, and audio). The RAN node may map these flows to one or more DRBs. In an embodiment (e.g., in FIG. 5), a video frame rate may be assumed to be 60 frames per second (fps), which may result in a video frame arriving at the RAN node approximately every 16.67 ms. The RAN node may attempt to match the DRX cycle to this frame rate (e.g., to help avoid video frame delays). However, Table 1 shows that there may not be a DRX cycle that can match this frame rate. The granularity of the DRX cycle is per millisecond, so a DRX cycle of 16 ms or 17 ms may be defined, but these DRX cycles may result in certain frames arriving at the RAN node outside of the WTRU's active time. These video frames may be delayed until a subsequent active time. Note that although shown for 60 fps, the same issues can occur at frame rates of 90 fps and 120 fps.

[0094] FIG. 6 illustrates an example of CDRX jitter. Improvements to address CDRX jitter may be provided herein. FIG. 6 shows a VR headset use case (e.g., the same VR headset use case) with three service data flows (posture, video, and audio) and a frame rate of 60 fps. Video frames may travel from the application server to the UPF over a data network, and from the UPF to the RAN node over (e.g., over) a transport network. As a result, there may be an inherent jitter in the arrival of video frames at the RAN node. Some video frames may have interframe timing less than 16.67 ms, while other video frames may have interframe timing greater than 16.67 ms. Even if the CDRX cycle matches the video frame rate, this jitter may mean that some video frames may arrive early while others may arrive late. In the latter case, the video frame may be delayed (e.g., may need to be delayed) to wait for the next active time.

[0095] FIG. 7 illustrates an example of frame sizes. Improvements to address frame sizes may be provided herein. FIG. 7 shows a VR headset use case (e.g., the same VR headset use case) with three service data flows (posture, video, and audio) and a frame rate of 60 fps. The video frames may be very large and of different sizes and importance. The RAN node may send these frames over the air interface via multiple terrestrial transmissions. These transmissions (e.g., each of these transmissions) may trigger an inactivity timer in the WTRU and extend the active time of the WTRU. Extending the WTRU active time may result in smaller power savings opportunities (e.g., because the DRX cycle is required to be relatively short to match the frame rate).

[0096] FIG. 8 illustrates an example of UL / DL cooperation. Improvements to address UL / DL cooperation may be provided herein. FIG. 8 shows a VR headset use case (e.g., the same VR headset use case) with three service data flows (e.g., posture, video, and audio) and a frame rate of 60 fps. At time t1, the user may rotate his / her head, which may result in posture information being sent to the application server. This transmission may occur in active time 1. The application server may respond with an updated video frame, which may arrive at the RAN node at time t2. This video frame may be delayed (e.g., may need to be delayed) until the next active time (e.g., because the WTRU is no longer in active time). In an embodiment, the time between motion (e.g., sending posture information) and photon (e.g., displaying an updated video frame) may be greater than the motion-to-photon requirement for these applications.

[0097] How service data flows are mapped to QoS flows for XR / media services may be defined (e.g., may need to be defined). An XR / media service may consist of multiple service data flows. A service data flow may be mapped to several QoS flows (e.g., based on the processing required for these service data flows). QoS characteristics (e.g., new QoS characteristics) may be defined (e.g., may need to be defined) for an XR / media service SDF that is mapped to a QoS flow. Service data flows of an XR / media service may be tightly coupled (e.g., in addition). In an embodiment, a UL service data flow carrying posture information may be linked to a downlink service data flow carrying video frame information or audio frame information. QoS characteristics (e.g., new QoS characteristics) may be defined (e.g., may need to be defined) to address these linked QoS flows. WTRU and network behavior may be defined (e.g., may need to be defined) if the QoS requirements of one of the linked flows are not met.

[0098] Improvements regarding UL active time may be provided. A WTRU may have many reasons to send UL traffic. This may include user plane data (e.g., attitude information), scheduling requests, CSI reports, HARQ ACKs, buffer status reports, power margin reports, etc. Independent transmission opportunities for these forms of UL traffic (e.g., each of these forms) may limit the sleep time at the WTRU. It has been proposed that the transmission of UL signals / data may be limited within a period (referred to as UL active time). In doing so, the WTRU is more likely to enter a deeper sleep. An enhancement may be needed to provide assistance to the RAN node so that the UL active time can be efficiently configured.

[0099] FIG. 9 illustrates an example of an objective for saving power. A basic CDRX cycle may be split between an on period (or active time) and an off period. An objective for maximizing power saving may be to keep the active time as short as possible and minimize the number of cycles in which the active time is extended (e.g., as shown in FIG. 9). To achieve these objectives, one or more of the following may be proposed: assistance information provided by the WTRU to assist the network; assistance information provided by the UPF to assist the network in optimizing the CDRX configuration; a mechanism for signaling assistance information from the WTRU to the network; a PDU header (e.g., a new PDU header) in the QoS flow to enable assistance information to be sent between the WTRU and the network; a mechanism for linking QoS flows; a mechanism for addressing stringent RTT requirements for linked QoS flows; a mechanism for determining when to send UL traffic based on a transmission opportunity (e.g., a preferred transmission opportunity) and the QoS characteristics of the QoS flow; or a mechanism for the WTRU to change the CDRX configuration or select a CDRX configuration (e.g., a new CDRX configuration) based on one or more metrics or events.

[0100] With regard to assistance information that the WTRU may provide to assist the network, examples of assistance information may include one or more of power state, Group of Picture (GOP) structure, active time extension, or which QoS flows are linked. In an embodiment, the assistance information may be used by the network to optimize the CDRX configuration. In an embodiment, the assistance information may be used by the WTRU to select between one or more CDRX configurations. In an embodiment, the assistance information may be used to minimize wasteful over-the-air transmissions. Wasteful over-the-air transmissions may refer to PDU transmissions over the air interface (between the WTRU and the RAN node) that are not necessary or are inconsistent / mismatched with respect to the CDRX configuration used by the WTRU. In an embodiment, the WTRU may have missed receiving a video I-frame. The WTRU may not need to receive any future video P-frames that rely on this I-frame as a reference (e.g., in this case).

[0101] Assistance information may be provided. For example, assistance information may be provided by the UPF to assist the network in optimizing the CDRX configuration. A mechanism may be provided for signaling assistance information from the WTRU to the network. A PDU header in the QoS flow may be provided that may enable assistance information to be sent between the WTRU and the network. A mechanism may be provided for linking QoS flows. A mechanism may be provided for addressing stringent RTT requirements for linked QoS flows. A mechanism may be provided for determining when to send UL traffic based on preferred transmission opportunities and QoS characteristics of the QoS flows. A mechanism may be provided for the WTRU to change or select a CDRX configuration based on one or more metrics or events.

[0102] The PDUs associated with a single video frame may be referred to as a burst set or burst of PDUs. These PDUs may arrive at the UPF as bursts or may be generated as bursts at the WTRU. These PDUs may need to be received correctly at the WTRU or UPF (e.g., all may need to be received correctly). If the PDUs are not received correctly at the WTRU or UPF, the video frame they are intended to carry may not be rendered correctly. This idea may be described with respect to a video frame, but may apply to any burst of PDUs that may need to be received correctly (e.g., all may need to be received correctly) to be useful. These PDUs may also be referred to as a PDU set (e.g., PDU set). A PDU set may consist of one or more PDUs that carry the payload of one unit of information generated at the application level (e.g., a frame or video slice for an XRM service), which may be of the same importance requirement at the application layer. The PDUs in a PDU set (e.g., all PDUs) may be required by the application layer to use the corresponding unit of information. In an embodiment, the application layer may be able to recover (eg, still recover) parts of an information unit if some PDUs are missing.

[0103] The terms application server and application function can be used interchangeably. Examples of power savings may be provided. In an embodiment, a RAN node may be provided with assistance information to enable the RAN node to one or more of: configure CDRX parameters to better suit XR / media service traffic, dynamically change CDRX parameters as conditions change for transmission and reception of XR / media service traffic, or provide the WTRU with multiple CDRX configurations, each configuration tailored to a particular condition for transmission and reception of XR / media service traffic. These conditions typically refer to events that are monitored at the WTRU and may be affected by CDRX (e.g., the WTRU moves from battery power to mains / wall power). Further example conditions are described below.

[0104] FIG. 10 illustrates an example of power savings for a WTRU. At 0, it may be assumed that the WTRU is configured with one or more CDRX configurations. The RAN node may base the configuration decision on QoS profile information received in a PDU session establishment or modification. At 1, the WTRU may receive configuration information (e.g., from a network node) for assistance information (e.g., via a configuration message). In an embodiment, the configuration information may include thresholds, averaging windows, timers, etc. The configuration may depend on the type of assistance information provided by the WTRU. At 2, the WTRU may monitor conditions based on the received configuration information. These conditions may trigger certain events in the WTRU. At 3a, certain conditions (e.g., from set a) may trigger the WTRU to send assistance information to the network node. This information may enable the RAN node to determine whether the CDRX parameters of an existing configuration need to be modified, whether a new CDRX configuration for the WTRU needs to be added, or whether an existing configuration needs to be deleted. At 3b, the WTRU may receive a new / modified CDRX configuration from the network node. In 4a, a certain condition (e.g., from set b) may trigger the WTRU to autonomously change from one CDRX configuration to another CDRX configuration or autonomously change CDRX parameters of a CDRX configuration. In 4b, the WTRU may send an indication to the RAN node that it has changed the CDRX configuration or changed parameters of the CDRX configuration (e.g., via indicating a request to extend the CDRX active duration (e.g., the first CDRX active duration) by an amount of time). The RAN node may then approve the request (e.g., confirm the extended CDRX active duration).

[0105] Examples of assistance information provided by a WTRU are described herein. The WTRU can provide assistance information that can be used by the network. The WTRU can monitor one or more metrics or events and send one or more types of information signals to the network. In response, the network can take some action. For example, the network can do one or more of the following: change the CDRX configuration, change the CDRX configuration for a period of time, change the CDRX configuration until another event occurs, configure multiple CDRX configurations, discard PDUs, or change the scheduling of some PDUs. If the WTRU is configured with multiple CDRX configurations, the WTRU can monitor one or more metrics or events and autonomously change from one configured CDRX configuration to another configured CDRX configuration. If a certain event occurs (e.g., if a monitored metric is below a threshold), the WTRU can be configured to send assistance information, autonomously change from one configured CDRX configuration to another configuration, or change parameters of the CDRX configuration. The WTRU may (eg, alternatively) be configured to send assistance information to the network, or to periodically change from one configured CDRX configuration to another.

[0106] The type of assistance information may be a current power status. The WTRU may provide this information as a percentage of the battery level or as a relative indication of the battery level (e.g., good, medium, bad). The WTRU may provide a threshold for determining the relative indication. The WTRU may report the power status periodically or based on some trigger event. In an embodiment, the WTRU may report the power status when the WTRU moves from mains / wall power to battery power, from battery power to mains / wall power, or when the power status falls below a first threshold or exceeds a second threshold.

[0107] The type of assistance information may be an indication of whether the WTRU wants the network to maximize throughput, or minimize delay, or maximize power savings. The RAN node action for CDRX may depend on the WTRU preferences. The WTRU may make this decision based on traffic priority, current battery status, user-supplied preferences received via a graphical user interface, etc.

[0108] The type of assistance information may be an indication of whether further transmissions on the QoS flow may be temporarily discarded. In an embodiment, the WTRU may have failed to decode a video I-frame. The WTRU may not be able to decode any P or B-frames based on this I-frame. The WTRU may make this decision based on an indication from the application. The application may inform the PDU layer about the missing I-frame. The WTRU may make this decision based on knowledge of which transport blocks carry I-frame information. The WTRU may determine that a transport block carrying I-frame data has failed for HARQ transmission. The WTRU may make this decision based on knowledge of which RLC PDUs carry I-frame information. Based on a sequence number, the WTRU may determine that an RLC PDU carrying I-frame information is missing. The WTRU may signal the network to discard future PDUs on a particular QoS flow. The WTRU may specify to discard a fixed number of future PDUs received on this QoS flow. In an embodiment, the WTRU may specify to discard future PDUs received on this QoS flow for a fixed duration. In an embodiment, the WTRU may specify to discard future PDUs received on this QoS flow until the next I frame is received on this QoS flow. In an embodiment, the network may decide to autonomously stop discarding PDUs (e.g., when the network receives a PDU for this QoS flow that is an I frame). In an embodiment, the WTRU may indicate to the network that PDUs (e.g., all PDUs) of the identified PDU set may be discarded, or a signal to the network may indicate that PDUs (e.g., all PDUs) of the identified flow of PDU set may be discarded.

[0109] The type of assistance information may be an indication of whether the WTRU supports multiple CDRX configurations and desires to activate multiple CDRX configurations. This may enable the RAN node to configure multiple simultaneous CDRX configurations for the WTRU. The WTRU may signal which QoS flows may be considered as a group for CDRX configuration.

[0110] The type of assistance information can be an indication of how the network should handle traffic from the QoS flow. The WTRU may prefer that the downlink traffic of the QoS flow be sent (e.g., only be sent) via a single terrestrial transmission. In an embodiment, for video traffic at 120 fps, HARQ layer retransmissions may be too slow. If (e.g., such is the case) an initial transmission fails, the WTRU may request that terrestrial HARQ retransmissions not be attempted. In an embodiment, the WTRU may prefer to minimize the transmission time of DL transmissions. This indication may signal to the RAN node that it should try to maximize the transport block size and avoid sending traffic over multiple transport blocks. In an embodiment, the WTRU may signal how much traffic from the QoS flow can be delayed before transmission to the WTRU. The WTRU may signal these indications as a result of dynamically changing conditions at the WTRU.

[0111] The type of assistance information (e.g., uplink Augmented Reality Media (XRM) data) may be an indication that the WTRU may remain in active time. The WTRU may send this indication (e.g., to a network node) if the WTRU's power status changes. In an embodiment, if the WTRU becomes mains / wall powered or the battery status exceeds a (pre)configured threshold, the WTRU may signal to the network that it may remain in active mode, e.g., to facilitate scheduling by the RAN node. The WTRU may send this indication (e.g., uplink XRM data) if the WTRU has transmitted uplink attitude information and may expect an updated video frame in response. To meet stringent motion-to-photon requirements (e.g., in this case), the WTRU may decide not to follow the configured CDRX and remain in active mode. The RAN node may use this information to attempt to schedule an updated video frame as soon as possible. As part of this information, the WTRU may include an indication (e.g., uplink XRM data) as to how long the WTRU intends to remain awake (e.g., to extend the CDRX active duration). In an embodiment, this may be in terms of number of cycles, duration in milliseconds, duration in symbols, duration in slots, duration in subframes, duration in frames, until the start of the next cycle, or until the WTRU sends a duration indication (e.g., another indication that the WTRU can return to following a CDRX cycle).

[0112] The type of assistance information may be an indication of whether the traffic of the QoS flow is WTRU driven, server driven, or both. In an embodiment, a WTRU driven flow may not result in significant DL traffic unless triggered by an uplink transmission. In an embodiment, a server driven flow may not result in significant UL traffic unless triggered by an uplink transmission. If an uplink transmission cannot trigger any DL transmission, the RAN node may use this information to maximize power savings. In an embodiment, in the WTRU driven case, the RAN node may configure the WTRU with a DRX configuration (e.g., two DRX configurations). The DRX configuration may include a first DRX configuration and a second DRX configuration. The first DRX configuration may be used when DL video traffic is expected due to uplink activity. The second DRX configuration may be used when DL video traffic is not expected. The second DRX configuration may provide the WTRU with more sleep opportunities and power savings. If the assistance information indicates that the traffic is WTRU driven, the WTRU and the RAN node may use a first DRX configuration when there is uplink activity and may use a second DRX configuration when there is no uplink activity.

[0113] The type of assistance information may be an indication of the traffic profile of the QoS flow. In an embodiment, for video, the WTRU may provide an indication of the size of the GOP (number of frames between successive I-frames). The WTRU may provide an indication of the GOP structure, such as the number of B-frames and P-frames between I-frames. The WTRU may provide an indication of the frame rate. The WTRU may provide an indication of the size of the I-frames, B-frames, and P-frames.

[0114] The type of assistance information may be an indication as to which QoS flows are linked (eg, such that activity on one QoS flow may be linked to a second QoS flow).

[0115] The type of assistance information may be an observed jitter of the generated traffic of the SDF or QoS flow. The WTRU may monitor the generated traffic on the SDF or QoS flow and may indicate the jitter between the arrival of a frame and the expected arrival of the frame. This indication may be an average of the jitter calculation over a window. The indication may be calculated in the PMF of the WTRU and sent to the network (e.g., RAN node, UPF). The RAN node may use this indication to decide to extend the active time. The RAN node may determine that most frames have a jitter of K ms. Instead of extending the active time (e.g., always), the RAN node may decide to change the cycle start time to dynamically compensate.

[0116] A video frame (e.g., a single video frame) may be sent over multiple IP packets. As a result, the IP packets that make up a video frame may be generated in bursts at the WTRU. The IP packets of a burst need to be sent to the UPF before the next burst of IP packets.

[0117] The type of assistance information that the WTRU can provide can provide whether the generated PDUs of an SDF flow or a QoS flow belong to the same burst arrival. The WTRU can tag the PDUs of the burst (e.g., all PDUs) with an identifier. This identifier can be used by the RAN node or UPF to decide to discard certain PDUs of the QoS flow. In an embodiment, the RAN node or UPF can decide to discard PDUs (e.g., all PDUs) that may be associated with the identifier (e.g., because a previous PDU associated with the identifier was not delivered successfully and subsequent PDUs may not be useful).

[0118] Examples of assistance information provided by the UPF are described herein. The UPF can send at least the following types of assistance information to the base station to assist in CDRX operations:

[0119] A type of assistance information may be the observed jitter of traffic arriving on the service data flow. The UPF may monitor the traffic arriving on the service data flow and may indicate the jitter between the arrival of a frame and the expected arrival of the frame. This indication may be an average of the jitter calculation over a window. This may be calculated in the PMF of the UPF and sent to the network RAN ​​node or the WTRU. The RAN node may use this to decide to extend the active time. The RAN node may (e.g., alternatively) determine that most frames have a jitter of K ms. Instead of extending the active time (e.g., always), the RAN node may decide to change the cycle start time to dynamically compensate.

[0120] A single video frame can be sent over multiple IP packets. As a result, the IP packets that make up a video frame may arrive in bursts at the UPF. The IP packets of a burst may be sent to the WTRU before the next burst of IP packets. A second type of information that the UPF can provide is whether arriving service data flow packets belong to the same burst arrival. The UPF can tag the packets of the burst (e.g., all packets) with an identifier. This indication can be used by the RAN node to discard certain packets of the QoS flow.

[0121] Examples of assistance information provided from an application server or application function are described herein: The application server may send at least the following types of assistance information to the network to aid in CDRX operations:

[0122] The first type of assistance information may be an indication of whether the XR application supports multiple CDRX configurations. This may enable the RAN node to configure multiple simultaneous CDRX configurations for the WTRU. The application server may signal which QoS flows may be considered as a group for CDRX configuration.

[0123] The type of assistance information may be an indication of how the network should handle traffic from a QoS flow. The application server may signal a preference that downlink traffic of the QoS flow be sent (e.g., only be sent) via a single terrestrial transmission. In an embodiment, for video traffic at 120 fps, HARQ layer retransmissions may be too slow. If (e.g., such is the case) an initial transmission fails, the XR application may prefer that terrestrial HARQ retransmissions not be attempted. In an embodiment, the application server may signal a preference to minimize transmission time of DL transmissions. This indication may signal to the RAN node that it should try to maximize the transport block size and avoid sending traffic over multiple transport blocks. In an embodiment, the application server may signal how much traffic from the QoS flow may be delayed before transmission to the WTRU.

[0124] The type of assistance information may be an indication of whether the traffic of the QoS flow is WTRU driven, server driven, or both. In an embodiment, a WTRU driven flow may not result in significant DL traffic unless triggered by an uplink transmission. In an embodiment, a server driven flow may not result in significant UL traffic unless triggered by an uplink transmission. The RAN node may use this information to maximize power savings in the absence of an uplink transmission to trigger any DL transmission. In an embodiment, in the WTRU driven case, the RAN node may configure the WTRU with a DRX configuration (e.g., two DRX configurations). The DRX configurations may include a first DRX configuration and a second DRX configuration. The first DRX configuration may be used for uplink activity when DL video traffic is expected. The second DRX configuration may be used when no DL video traffic is expected. The second DRX configuration may provide the WTRU with more sleep opportunities and power savings. If the assistance information indicates that the traffic is WTRU driven, the WTRU and the RAN node may use a first DRX configuration when there is uplink activity and may use a second DRX configuration when there is no uplink activity.

[0125] The type of assistance information can be an indication of the traffic profile of the QoS flow. In an embodiment, for video, the application server can provide an indication of the size of the GOP (the number of frames between successive I-frames). The application server can provide an indication of the GOP structure, such as the number of B-frames and P-frames between I-frames. The application server can provide an indication of the frame rate. The application server can provide an indication of the frame size distribution (of I-frames, B-frames and P-frames).

[0126] The type of assistance information may be an indication of which service data flows (SDFs) or QoS flows are linked (e.g., so that activity on one SDF or QoS flow may be linked to a second SDF or QoS flow).

[0127] The application server may provide the assistance information by calling the NEF API. The NEF API may be used to provide an XRM communication pattern and an XRM traffic profile related to the XR / media service for the WTRU. The XRM communication pattern and XRM traffic profile related information may be used (e.g., may be used later) by the SMF to provide assistance to the RAN.

[0128] The procedure used to configure information about an XRM service can be modeled after the external parameter provisioning procedure.

[0129] Inputs to the NEF API may include one or more of a service identifier, an XRM communication pattern associated with the service, or an XRM traffic profile that may identify whether DL traffic is WTRU-driven or server-driven. The XRM communication pattern may include at least the following information: frame rate, group of pictures (GOP) structure, or frame size distribution. The XRM traffic profile may indicate whether a UL transmission triggers a DL transmission from the application server. The XRM traffic profile may be part of the XRM communication pattern.

[0130] The UDM can store XRM communication patterns and XRM traffic profiles associated with XRM services. The UDM can classify this information as "SMF related" (e.g., according to the principles of the external parameter provisioning procedure). The SMF can take this information, combine / merge overlapping parameters for the WTRU, and derive CN-assisted RAN information. The latter can be sent to the RAN node, for example, so that the RAN node can optimize Uu resource allocation and CDRX configuration.

[0131] Examples of assistance information provided by a network data analysis function (NWDAF) are described herein. The NWDAF can provide (e.g., can provide) assistance information to aid in CDRX operations. The NWDAF can collect information from the WTRU, UPF, RAN nodes, application servers, and / or other network functions. The NWDAF can generate (e.g., can then generate) assistance information as output to provide to the network to help CDRX operations.

[0132] Typical inputs to the NWDAF may include one or more of the following: delay or jitter from the WTRU to the RAN node, delay or jitter from the RAN node to the UPF, delay or jitter from the WTRU to the UPF, delay or jitter from the UPF to the RAN node, delay or jitter from the RAN node to the WTRU, delay or jitter from the UPF to the WTRU, PDU set size (e.g., number of PDUs in an I frame, number of PDUs in a B frame, number of PDUs in a P frame), a power savings measure for the WTRU (e.g., the RAN node may provide an indication of the ratio of off time to active time), or the RAN node or the WTRU may provide the average number of HARQ transmissions for a transport block.

[0133] Typical outputs to the NWDAF may include one or more of the following: average DL jitter, average PDU set size (e.g., for I, B, and P frames), GOP structure, or frame rate. These outputs may be sent to the RAN node to modify / add / remove the CDRX configuration of the UE. These outputs may be used (e.g., may also be used) by the SMF to modify the QoS rules provided to the WTRU, the QoS profile provided to the RAN node, or the SDF template provided to the UPF.

[0134] Examples of new signaling to support assistance information may be provided herein. Based on the type of information that may be sent from the WTRU, the signaling from the WTRU may be extended to include one or more of the following: power status, an indication of WTRU preference for maximizing throughput, minimizing delay, or maximizing power savings, an indication to temporarily discard packets of a QoS flow, an indication of support for multiple DRX or single DRX, an indication of QoS flows that may be grouped for CDRX configuration, an indication to stay in active time, GOP information (size and structure), information about linked QoS flows, observed jitter for the QoS flows or SDFs, or an indication of whether PDUs belong to the same burst arrival.

[0135] Figure 11 illustrates example transmission options for assistance information from the WTRU. The assistance information from the WTRU can be sent to the network using one or more of the following transmission options. Figure 11 shows four such options, which are further described below, including a single action taken by the network (the RAN node changing the CDRX configuration). This can be extended to other network actions taken at the UPF and / or the WTRU.

[0136] In the transmission option, the WTRU may provide a certain type of assistance information to the RAN node (eg, directly) using RRC signaling. The type of assistance information may be mapped to a new IE.

[0137] In the transmission option, the WTRU may provide a certain type of assistance information to the AMF via NAS signaling. The type of information may be mapped to an IE (e.g., a new IE) in an existing NAS-MM message or a new NAS-MM message.

[0138] In the transmission option, the WTRU may provide a certain type of assistance information to the SMF via NAS signaling. The type of information may be mapped to an IE (e.g., a new IE) in an existing NAS-SM message or a new NAS-SM message. In an embodiment, the information may be carried in a PDU Session Establishment Request message or a PDU Session Modification Request message. The SMF may provide a certain type of information (e.g., a PDB or an adjustment to the PDB) to the RAN node through the AMF. In an embodiment, the SMF may generate a QoS profile (e.g., a new QoS profile) or modify an existing QoS profile according to the provided information (e.g., a PDB or an adjustment to the PDB). The QoS profile is provided (e.g., then provided) by the SMF through the AMF to the RAN node. In an embodiment, the SMF may generate a QoS rule (e.g., a new QoS rule) or modify an existing QoS rule according to the provided information (e.g., a PDB or an adjustment to the PDB). The QoS rule is provided (e.g., then provided) to the WTRU through the AMF. In an embodiment, the SMF may generate an SDF template (e.g., a new SDF template) or modify an existing SDF template according to the provided information (e.g., a PDB or adjustments to the PDB). The SDF template may be provided (e.g., may then be provided) to the UPF in an N4 message.

[0139] In the transmission option, the WTRU may provide certain types of information to an application server or application function over a user plane connection. The application server or application function may provide this information to the PCF, AMF, or SMF using the NEF, depending on the type of information. In an embodiment, if the information directly affects the CDRX configuration, the information may be provided to the AMF, which may forward it to the RAN node.

[0140] PDU headers (e.g., new PDU headers) in the QoS flow may be required to enable some of the actions the network can take in response to the type of information provided by the WTRU and the UPF. In an embodiment, these new headers may include one or more of the following: frame type, priority, SDF ID, or burst identifier.

[0141] In the case of frame type, an indication of whether the PDU being carried over the QoS flow is from an I frame, a non-I frame, a B frame, or a P frame may be included. The WTRU or UPF may make this determination based on the indication carried in the SDF PDU, which may be based on deep packet inspection of the SDF PDU, which may be based on known GOP and frame timing, or which may be based on the number of SDF PDUs received. For the latter, the WTRU or UPF may assume that I frames are likely to result in a significantly larger number of SDF PDUs compared to B and P frames.

[0142] The priority may include an indication of the priority of the PDUs being carried via the QoS flow.

[0143] In the case of the SDF ID, an identifier for the SDF that generated the PDU and is being carried over this QoS Flow may be included. The SDF ID may be unique within each QoS Flow.

[0144] For the burst identifier, the WTRU and UPF may tag each PDU of a QoS flow that belongs to a single frame or a single slice with the same identifier. In an embodiment, this may be a sequence number. The PDUs of one burst (e.g., all PDUs) may have the same sequence number. The PDUs of the next burst (e.g., all PDUs) have the next sequence number. The WTRU and UPF may determine the PDUs that belong to the same burst based on an indication carried in the SDF PDU, which may be based on deep packet inspection of the SDF PDU, based on a known GOP, or based on frame timing.

[0145] FIG. 12 illustrates an example of linked QoS flows for XR / media services. Examples related to QoS flows for XR / media services may be provided herein. XR / media services may have unique traffic characteristics and QoS requirements. This mapping of such characteristics and requirements to a QoS model (e.g., a 5G QoS model) may benefit from certain extensions. In an embodiment, several SDFs may be linked, where traffic on one flow may trigger traffic on a second flow (e.g., posture information on SDF1 triggers video information on SDF2, as shown in FIG. 12). Because traffic on the SDFs (e.g., these two SDFs) may be quite different, these flows may be mapped to different QoS flows. A network (e.g., a 5G network) may need to handle QoS flows (e.g., two QoS flows) together (e.g., to meet MTP requirements for XR / media services).

[0146] Each QoS flow may be identified by a QoS flow identifier (QFI), and each QoS flow may be associated with a QoS profile. The QoS profile may be used by the WTRU, the RAN node, and the UPF to determine how to treat the PDUs carried in the QoS flow. A QoS flow may be the smallest granularity for which a system (e.g., a 5G system) provides QoS support. This QoS support may be based on the QoS profile associated with the QoS flow. Both the UPF and the WTRU may maintain a mapping of SDFs to QoS flows.

[0147] Examples of linking QoS flows may be provided. At least the following examples may be used to link one or more SDFs.

[0148] In an embodiment of linking, the QoS profile may include an indication within the QoS profile that is linked (e.g., common to all QoS profiles). In an embodiment, the QoS profile may include a QoS Profile ID (QoS ProfileID, QPI), as shown in the table below. The QoS profiles that are linked (e.g., all QoS profiles) may share the same QPI. The network entity may know which QoS flows are linked because these QoS flows may have QoS profiles that share the same QoS Profile ID. The QoS Profile ID may be provided by the SMF to the WTRU in the QoS rule and to the UPF in the QoS enforcement rule.

[0149] Table 2 may provide a linking method for the modified QoS profile.

[0150] [Table 2]

[0151] FIG. 13 illustrates an example of linked QoS flows using a QFI list. In an embodiment of linking, a QoS rule or QoS enforcement rule can have an attribute (e.g., a new attribute) that contains a list of linked QoS flows. Linked QoS flows can be identified by their QFIs. For example, FIG. 13 shows three QoS flows identified by QFI1, QFI2, and QFI3, all of which are linked.

[0152] In a linking embodiment, the QoS rule provided to the WTRU and the SDF template (e.g., PDR or QoS enforcement rule) provided to the UPF may include an indication of the linked SDFs. In an embodiment, the QoS rule may provide the WTRU with a mapping of SDFs to QoS flows. The QoS rule may be extended to include (e.g., also include), for each SDF, a list of linked SDFs. The WTRU may (e.g., may then) determine which QoS flows are linked based on the mapping from SDFs to QoS flows and the list of linked SDFs.

[0153] Examples of QoS parameters (e.g., new QoS parameters) in the QoS profile of XR / media services may be provided. A system (e.g., a 5G system) may incorporate QoS and increase its capabilities to meet stringent QoS requirements for XR / media services. This may improve the system's ability to meet these requirements. These parameters (e.g., additional parameters) may be derived from at least the following:

[0154] The QoS parameters for a QoS flow of an XR / media service may be an indication of the type of traffic carried by the flow. In an embodiment, this may be an indication of whether the traffic in the QoS flow is attitude information, audio information, video information, or some other type of information. The type of traffic may be indicated (e.g., may also be indicated) through a numerical index, in which case the mapping of indexes to traffic types may be pre-configured in the system (e.g., a 5G system). If the flow carries more than one type of traffic, the indication may include a list of supported traffic types. The indication may (e.g., alternatively) include a highest priority traffic type. Receipt or transmission of a PDU with a QoS flow ID (QFI) indicating that the traffic is of a certain type may be an optional indication to the WTRU or base station that UL or DL ​​traffic (e.g., additional UP or DL ​​traffic) may be expected and the CDRX configuration may be changed accordingly.

[0155] The QoS parameters for a QoS flow of an XR / media service may be an indication of the direction of the traffic carried by the flow. In an embodiment, this may be an indication of whether the traffic is primarily from the WTRU to the UPF (UL), from the UPF to the WTRU (DL), or bidirectional (WTRU to the UPF and from the UPF to the WTRU).

[0156] The QoS parameters for a QoS flow of an XR / media service may be an indication of the priority of the SDF traffic carried by the flow, or the priority of the type of traffic carried in the flow. This may be an indication of the relative priority of the SDF traffic or traffic type (e.g., high, low, medium). This may (e.g., alternatively) be a numerical indication of the priority. In an embodiment, a higher number may indicate a higher priority, or a lower number may indicate a higher priority.

[0157] The QoS parameter for the QoS flow of the XR / media service may be an indication of the total RTT allowed. In an embodiment, this may refer to the time from a WTRU UL transmission to the receipt of a DL transmission triggered by this WTRU UL transmission. In an embodiment, this may refer to the sum of the PDB for the WTRU UL transmission and the PDB budget for the DL transmission triggered by this WTRU UL transmission. This QoS parameter may be associated with the linked QoS flow.

[0158] The QoS parameter for a QoS flow of an XR / media service may be an indication of a preferred instantaneous block error rate (BLER) or a residual BLER for a transport block carrying the service data flow.

[0159] The QoS parameters for a QoS flow of an XR / media service may be an indication of how the RAN node may handle terrestrial retransmissions for this QoS flow. In an embodiment, the QoS parameters may specify a maximum number of terrestrial retransmissions or may specify that the RAN node may not allow any terrestrial retransmissions.

[0160] The QoS parameters for a QoS flow of an XR / media service may be an indication of the maximum jitter tolerated for the traffic of the QoS flow.

[0161] The QoS parameters for a QoS flow of an XR / media service may be an indication of the frame rate and GOP structure for the SDF carrying the video traffic.

[0162] An example of the impact of round trip time (RTT) on linked QoS flows may be provided. In an embodiment where the XR / media service has linked QoS flows with RTT parameters (e.g., RTT requirements), the PDB parameters may be appropriately set for each of the linked QoS flows (e.g., the first QoS flow and the second QoS flow). For example, there may be a PDB (e.g., UL PDB) for UL traffic (e.g., associated therewith) on one QoS flow (e.g., the first QoS flow), and there may be a PDB (e.g., DL PDB) for DL ​​traffic (e.g., associated therewith) on a linked QoS flow (e.g., the second QoS flow) triggered by uplink traffic. The RTT parameters may be assumed to be evenly split between the PDBs of both QoS flows (e.g., the UL PDB associated with the first QoS flow is equal to the DL PDB associated with the second QoS flow).

[0163] It may be advantageous to dynamically change the PDBs of linked QoS flows (e.g., dynamically change the UL PDB and / or DL ​​PDB) based on some measured packet delay of each of the linked QoS flows (e.g., the first QoS flow and the second QoS flow). In an embodiment, if the UL packet delay falls (e.g., consistently falls) below the PDB for a QoS flow (e.g., the first QoS flow) carrying UL traffic (e.g., the UL PDB is too high), the network may reduce the PDB for this QoS flow (e.g., the first QoS flow) and may increase the PDB for the linked QoS flow (e.g., the second QoS flow) carrying DL traffic triggered by the UL transmission. In an embodiment, if the UL packet delay exceeds (e.g., consistently exceeds) the PDB for a QoS flow (e.g., a first QoS flow) carrying UL traffic (e.g., the UL PDB is too low), the network can increase the PDB for this QoS flow (e.g., a first QoS flow) and decrease the PDB for a linked QoS flow (e.g., a second QoS flow) carrying DL traffic triggered by the UL transmission. In an embodiment, if the DL packet delay exceeds (e.g., consistently exceeds) the PDB for a QoS flow (e.g., a second QoS flow) carrying DL traffic triggered by the UL transmission (e.g., the DL PDB is too low), the network can decrease the UL PDB for the first QoS flow and increase the PDB for a linked QoS flow (e.g., a second QoS flow) carrying DL traffic triggered by the UL transmission. In an embodiment, if the DL packet delay falls (e.g., is consistently below) the PDB for a QoS flow (e.g., a second QoS flow) carrying DL traffic (e.g., the DL PDB is too high), the network may increase the UL PDB for the first QoS flow and may decrease the PDB for the linked QoS flow (e.g., a second QoS flow) carrying DL traffic triggered by the UL transmission.

[0164] The UPF may measure packet delay and obtain an average packet delay for QoS Flow 1 (e.g., the first QoS flow). This measurement may be performed by the PMF at the UPF. The UPF may send the average packet delay measurement to the SMF. If the average packet delay is less than the UL PDB, the SMF may decide to reduce the PDB for QoS Flow 1 (e.g., the first QoS flow) and increase the PDB for the linked QoS flow (e.g., QoS Flow 2 or the second QoS flow). The UPF or RAN node may determine that some packets of QoS Flow 1 exceed the PDB and are being discarded. The UPF or RAN node may send an indication of the number of discarded packets. The SMF may decide to increase the PDB for QoS Flow 1 and decrease the PDB for the linked QoS flow (QoS Flow 2). The WTRU, the RAN node, and the UPF may be notified of the change in the PDB, so that the QoS flows may receive different QoS treatment.

[0165] The WTRU may measure packet delay and obtain an average packet delay for QoS Flow 3. This measurement may be performed by the PMF at the WTRU. The WTRU may send the average packet delay measurement to the SMF via a session management (SM) message. If the average packet delay is below the PDB, the SMF may decide to reduce the PDB for QoS Flow 3 and increase the PDB for the linked QoS flow (QoS Flow 4). The WTRU or the RAN node may determine that some packets of QoS Flow 3 exceed the PDB and are being discarded. The WTRU or the RAN node may send an indication of the number of discarded packets to the SMF. The SMF may decide to increase the PDB for QoS Flow 3 and decrease the PDB for the linked QoS flow (QoS Flow 4). The WTRU, the RAN node, and the UPF may be notified of this change in the PDB and the QoS flows may receive different QoS treatment. The WTRU may send the SM message periodically. The WTRU may (e.g., alternatively) send a SM message if the obtained average packet delay exceeds a (pre-)configured threshold or if the number of dropped packets exceeds a (pre-)configured threshold. The WTRU may send the message if requested by the network.

[0166] The WTRU may add markings (e.g., new markings) to packets of the QoS flow (e.g., to aid in dynamically modifying the PDB of the QoS flow). In an embodiment, this may include a timestamp of when the packet of the QoS flow is generated. This timestamp may be added to the header of the packet. The WTRU may include (e.g., additionally include) an indication of the obtained average packet delay for the linked QoS flow. The obtained average packet delay may be added to the header of the packet. The RAN node and the UPF may use this to modify the PDB of the linked QoS flow.

[0167] Information (e.g., additional information) may be added to the PDU headers of linked QoS flows that have RTT requirements (to help the system (e.g., a 5G system) determine when to discard PDUs that cannot meet the RTT parameters associated with these linked QoS flows). An entity (UE, RAN node, or UPF) in the system (e.g., a 5G system) may be able to determine whether a PDU can meet the RTT parameters associated with the linked QoS flows. The RTT parameters may be associated with different PDUs (e.g., two different PDUs). The two different PDUs may be PDU_1 and PDU_2. PDU_1, which is an "initiating PDU", may be sent over one QoS flow. PDU_2, which is a "response PDU", may be sent over the linked QoS flow. For example, the WTRU may send PDU_1 at time T1, and the RTT parameters may be set to 15 ms for the linked QoS flows. If PDU_2 arrives at the UPF at time T1+16 ms, this PDU may be too late to meet the RTT parameters. As a result, the system (e.g., a 5G system) cannot process this PDU and the PDU may be discarded. To allow an entity in the system (e.g., a 5G system) to make this decision, it may be proposed that the PDU header includes the time when the PDU was originally generated, which may be referred to as the round trip start time (RTStartTime).

[0168] In an embodiment, the WTRU can create PDU_1 for QoS flow 1 at time T1. The WTRU can set RTStartTime to T1. This time can be included in the PDU rule. When PDU_1 arrives at the UPF, the UPF stores the RTStartTime of PDU_1 and as a result, it can be used for PDU_2 via the linked QoS flow. When the UPF receives traffic on the SDF of the linked QoS flow (PDU_2), the UPF can retrieve the stored RTStartTime and include the RTStartTime in the PDU header. Based on the RTStartTime, entities (e.g., all entities (WTRU, RAN node, UPF)) can determine how much time the network has left for the processing of PDU_2. That is, the entity can determine the difference between the current time (T2) and the RTStartTime (T1). If T2 - T1 > RTT parameter, the entity can discard the PDU. If T2 - T1 < RTT, the difference (RTT (T2 - T1)) can be used by the entity to adapt the processing given to this PDU. If the difference is small, the PDU can receive some preferential treatment.

[0169] In an embodiment, the UPF can create PDU_1 for QoS flow 1 at time T1. The UPF can set RTStartTime to T1. This time can be included in the PDU rule. When PDU_1 arrives at the WTRU, the WTRU can store the RTStartTime of PDU_1 and, as a result, use it for PDU_2 via the linked QoS flow. When the WTRU generates traffic on the SDF of the linked QoS flow (PDU_2), the WTRU can retrieve the stored RTStartTime and include the RTStartTime in the PDU header. Based on the RTStartTime, entities (e.g., all entities (WTRU, RAN node, UPF)) can determine how much time the network has left for the processing of PDU_2. That is, when the entity determines the difference between the current time (T2) and the RTStartTime (T1). If T2 - T1 > RTT parameter, the entity can discard the PDU. If T2 - T1 < RTT, the difference (RTT (T2 - T1)) can be used by the entity to adapt the processing given to this PDU. If the difference is small, the PDU can receive some preferential treatment.

[0170] Examples regarding UL active time can be provided herein. If the WTRU has a PDU to send (e.g., as described herein), the WTRU can associate the PDU with a QoS flow and a 5QI marking. The 5QI marking can be used by the WTRU and the lower layers of the network (e.g., the base station and the UPF) to determine what QoS processing may be required for the packet. Each 5QI can be associated with a PDB. The PDB can define an upper limit for the time by which a packet can be delayed between the WTRU and the N6 endpoint in the UPF. The PDB can be used to support the configuration of scheduling and link layer functions (e.g., setting of scheduling priority weights and HARQ target operating points).

[0171] In a system (e.g., a current 5G system) design, the WTRU can send a PDU when it is ready to be sent, unless a higher priority PDU is waiting to be sent. The WTRU cannot buffer (e.g., delay) a PDU unless there is a higher priority PDU in the queue.

[0172] The WTRU may be configured with an UL active time that represents a period during which the UE may prefer to send UL data (e.g., as described herein). DL data may be periodic (e.g., may be periodic) and the WTRU may be configured with an on duration or active time when the WTRU may monitor the PDCCH for DL ​​data (e.g., as described herein). It may be preferable (e.g., may be preferred) for the WTRU to send UL data during the active time. Sending data during the active time may be preferred because it may reduce the number of WTRU wake-up events. In an embodiment, sending data during the active time may reduce cases where the WTRU may need to wake up (e.g., wake up once) to send data and then wake up again to receive data at a later time.

[0173] When a PDU is received from higher layers, the WTRU may be configured to delay or buffer the PDU until a preferred transmission opportunity approaches. Examples of preferred transmission opportunities are the WTRU's UL Active Time and On Duration.

[0174] The WTRU may use the 5QI that may be associated with the PDU and the amount of time until the next preferred transmission opportunity to determine whether to delay or buffer the packet. In an embodiment, the WTRU may decide not to delay or buffer a PDU associated with a 5QI value of 80 (e.g., because the value 80 indicates a relatively small PDB of only 10 ms).

[0175] In an embodiment, the WTRU may decide to delay or buffer PDUs associated with a 5QI value of 10 (eg, because a value of 10 indicates a relatively large PDU of only 1100 ms).

[0176] In an example embodiment, the WTRU may decide to delay or buffer a PDU associated with a 5QI value of 79 (e.g., because a value of 79 indicates a PDB of 50 ms) when a preferred transmission opportunity is approaching in only 8 ms. The WTRU may determine that the buffering delay is a sufficiently low percentage of the entire PDB.

[0177] In an example embodiment, when a preferred transmission opportunity is approaching at 40 ms, the WTRU may determine not to delay or buffer the PDU associated with a 5QI value of 79 (e.g., because a value of 79 indicates a PDB of 50 ms). The WTRU may determine that the buffering delay is too large a percentage of the entire PDB.

[0178] The WTRU may receive information from the network that may be used by the WTRU to determine how much of the entire PDB may be used by the WTRU to buffer PDUs and send the PDUs at a preferred transmission opportunity. The WTRU may use the information from the network to determine how long a packet may be buffered. This information may be a percentage value. The information may be received in a NAS-SM container in a PDU Session Establishment Accept or PDU Session Modification message. The information may be associated with a QoS flow of the PDU session (e.g., all QoS flows) or there may be separate information associated with each QoS rule of the PDU session.

[0179] The WTRU may receive delay measurements from the UPF via PMF signaling. The delay measurements may indicate the delay between the WTRU and the UPF. The WTRU may use these measurements to determine how long a PDU may be buffered. In an example, the WTRU may determine that a PDU with a PDB of 50 ms may be buffered for up to 6 ms (e.g., because the delay measurements from the UPF indicate that a PDU may experience a 40 ms delay between the WTRU and the UPF (e.g., the WTRU may assume that 4 ms can be used for extra margin)).

[0180] Examples of CDRX adaptation may be provided. The WTRU may change CDRX configuration parameters or select a CDRX configuration to (re)align with data transmission / reception. In an embodiment, the WTRU may be configured with one or more CDRX configurations, which may periodically change parameters associated with the CDRX configurations or may select a CDRX configuration (e.g., a new CDRX configuration) based on a realignment periodicity value. The WTRU may be configured by the network with a first set of configurations (e.g., a default / initial CDRX configuration and / or a default set of parameters associated with the CDRX configurations), which the WTRU may use initially upon receiving those configurations (via a configuration message from a network node). The WTRU may (also) be configured with a second set of configurations (e.g., an alternative set of CDRX configurations, parameters, and / or parameter values), which the WTRU may periodically change based on the configured realignment periodicity value. Either the CDRX configuration or the CRDX parameters may be used by the WTRU to receive data in the DL or send data in the UL in one or more data flows.

[0181] Parameters associated with the CDRX configuration configured in the WTRU may include at least one of the following: an offset start time period for starting a CDRX cycle; a CDRX cycle duration; an on / active duration (e.g., the number of time periods / occasions that the WTRU monitors for PDCCH, and the number that the WTRU can indicate may be extended); or an inactivity duration (e.g., the number of time periods / occasions that the WTRU remains active after receiving a PDCCH).

[0182] When changing any of the parameter values ​​and / or the CDRX configuration, the WTRU may send an indication to the network indicating at least one of the parameter ID / index, the parameter value, or the CDRX configuration. The WTRU may use the corresponding parameters if it receives a confirmation indication from the network node and / or after expiration of the configured duration. The corresponding parameters may include a second CDRX active duration. The second CDRX active duration may be the first CDRX active duration extended by a requested length of time, or a CDRX active duration different from the first CDRX active duration extended by a requested length of time. The corresponding parameters may be the updated parameters (e.g., the extended first CDRX active duration) or a second CRDX configuration (e.g., a new CRDX configuration with a different CDRX active duration). If a reject indication is received from the network, the WTRU may revert to using the first configuration set (e.g., the default / initial CDRX configuration and / or a default set of parameters).

[0183] In an embodiment, a parameter of a CDRX configuration may be associated with a frame rate corresponding to data expected to be received or sent by the WTRU. For video data having a frame rate of 60 frames per second (fps), the WTRU may be expected to periodically receive data in the UL with a periodicity value of 1 / 60 or 16.66 ms. To receive such video data, the WTRU may be configured with a CDRX configuration having parameter values ​​of, for example, 16 ms for the CDRX cycle duration and 2 ms for the on / active duration. When using such a CDRX configuration, after some time periods / occasions during which the WTRU may receive data in the DL during the on / active duration, the CDRX configuration may become misaligned with respect to the frame rate (possibly due to a non-integer periodicity value corresponding to the frame rate). The WTRU may be configured with a realignment periodicity value of 64 ms or 4 consecutive on / active durations such that (for example, in this case) the WTRU may periodically change any of the parameters (e.g., offset start time period or on / active duration) or may select a second CDRX configuration (e.g., a new CDRX configuration). The configured realignment periodicity may be based on aiding information such as frame rate.

[0184] 14 illustrates an example of a WTRU configured to periodically change a starting offset time for CDRX to align with data reception based on the frame rate applied for the data. Such an approach (e.g., as illustrated in FIG. 14) can enable the WTRU to realign reception of data with reception of the frame rate when using updated parameter values ​​or a second CDRX configuration (e.g., a new CDRX configuration).

[0185] FIG. 15 illustrates an example where a WTRU changes a CDRX configuration in a subsequent CDRX cycle when it detects a triggering event during a CDRX cycle. The changed CDRX configuration may result in an updated on / active duration. In an embodiment, the WTRU may change parameters associated with a first CDRX configuration (e.g., an initial CDRX configuration) or select a second CDRX configuration (e.g., a new CDRX configuration) if it detects a triggering event (e.g., possibly at any time during a CDRX cycle). The triggering event may include one or more of connectivity / session (re)configuration, receiving a higher layer / application layer indication, changing / updating data flows per application, measuring jitter, measuring a radio link, detecting a change in WTRU movement, or detecting a change in power status.

[0186] In the case of connectivity / session (re)configuration, the triggering event may be the receipt or sending of any signaling message associated with the (re)configuration of the RRC connection, RRC state, PDU session, and application layer session.

[0187] For receipt of an upper layer / application layer indication, the trigger event may be receiving an indication from a NAS layer or application hosted at the WTRU or network node (e.g., properties of uplink XRM data may be indicated) indicating one or more of the following changes in the next data over one or more CDRX cycles: a motion-to-photon latency (MTP) parameter, a total round trip time parameter, a data type (e.g., the next frame changes from a P / B frame to an I frame), a failed upper layer frame (e.g., the application layer failed to decode an I frame), a traffic characteristic (e.g., the number of PDUs in a PDU set may be expected to be above / below a threshold, a PDU may be expected to be above / below a threshold, the frame rate increases / decreases), a priority of the data (e.g., the priority value of a PDU or PDU set may be expected to be above / below a threshold), or a QFI or any QoS indication / marking (e.g., a QFI value may be expected to be greater / less than a threshold).

[0188] When modifying or updating data flows on a per application basis, the triggering event may be the addition of one or more new flows and / or the release of existing flows associated with the application.

[0189] In the case of jitter measurements, a trigger event may be when a measured jitter value (e.g., the difference between the expected time period when data is expected to be received and the actual time period when the data is received) in one or more data flows rises above / falls below a threshold value.

[0190] In the case of wireless link measurements, the trigger event may be when the RSRP, RSRQ, and RSSI measurements of a signal, channel, beam, carrier, link, etc. (possibly associated with one or more data flows transmitted / received by the WTRU) rise above / fall below some threshold.

[0191] In the case of detection of a change in WTRU movement (e.g., as indicated by uplink XRM data), a trigger event may be when the uplink XRM data includes uplink attitude information (e.g., orientation information) or when an attitude / positioning measurement (e.g., location information, attitude in 6DoF) goes above / below an attitude / position threshold.

[0192] In the case of detection of a change in power status, the triggering event may be when the power status transitions from mains / wall power to battery. The WTRU may place an upper limit on the active time to maximize power savings. In the case of detection of a change in power status, the triggering event may be (e.g., may be) when the power status transitions from battery to mains / wall power. The WTRU may use a second DRX configuration that has fewer power savings opportunities.

[0193] When changing any of the parameter value and / or the CDRX configuration and / or the CDRX active time, the WTRU may send an indication to the network indicating one or more of the ID / index of the parameter, the parameter value, the duration for extending the CDRX active time (e.g., the first CDRX active time), or the CDRX configuration. The WTRU may use the corresponding updated parameters when it receives a confirmation indication from the network and / or after expiration of the configured duration. The updated parameters may include a second CDRX active duration. The second CDRX active duration may be the first CDRX active duration extended by the requested length of time, or may be a different CDRX active duration than the first CDRX active duration extended by the requested length of time. The updated parameters may include a second CDRX configuration (e.g., a new CDRX configuration). If a reject indication is received from the network, the WTRU may revert to using the first CDRX configuration (e.g., a default / initial CDRX configuration and / or a default set of parameters). In the network response, the network may indicate to use a different ID / index of the parameter, a different parameter value, a different duration for extending the CDRX active time, or a different CDRX configuration.

[0194] In an embodiment, the WTRU may change parameters of the CDRX configuration, extend the first CDRX active time, or change to a second CDRX configuration (e.g., a new CDRX configuration) upon detecting any changes to the motion-to-photon (MTP) or RTT latency. Such MTP latency may typically be measured between the transmission of UL data during the first on / active duration and the reception of DL data (e.g., possibly associated with the UL data) during the second on / active duration.

[0195] In an embodiment, the WTRU may be configured by the network with one or more CDRX configurations targeting XRM services having MTP or RTT latency requirements. The CDRX configurations may enable the WTRU to request the network to extend the CDRX active time to meet the MTP latency (or RTT latency) requirements. The WTRU may be configured (e.g., may be configured) with the MTP latency (or RTT latency) requirements of the XRM services.

[0196] The WTRU may be configured with a CDRX configuration that may enable the WTRU to request the network to extend the CDRX active time. In an embodiment, the WTRU may determine that the uplink XRM data is from an SDF that requires low MTP latency. The WTRU may determine (e.g., may determine) that a downlink XRM response is expected in the next K milliseconds based on a configured MTP latency (or RTT latency) requirement. In an embodiment, the WTRU may inspect a header of the uplink XRM data and determine that the header includes an indication that downlink XRM data is expected in response to the uplink XRM data. The header may include (e.g., may include) an indication that downlink data is expected within the next K milliseconds. The K milliseconds may be referred to as a motion-to-photon latency (MTP) parameter or a total round-trip time parameter. The WTRU may determine to extend the CDRX active duration when the MTP parameter is greater than the time remaining in the current CDRX active time. The WTRU may determine that it may not be in the CDRX active time in the next K milliseconds and may request to extend the CDRX active time. In an embodiment, the WTRU may determine that the current CDRX active time is expected to end in K1 ms and that DL XRM traffic may arrive in K ms (K>K1). The WTRU may request to extend the CDRX active time for a duration of (K-K1) ms (e.g., such that the WTRU is within the CDRX active time when DL XRM data is expected).

[0197] In an embodiment, the WTRU may be configured by the network with one or more CDRX configurations based on statistical information related to MTP latency (e.g., average, standard deviation, minimum, maximum) provided either by the WTRU in the assistance information (e.g., a property of the uplink XRM data is an MTP latency associated with the uplink XRM data) or by a CN entity (e.g., UPF, AMF, SMF) to a serving base station in the RAN. The WTRU may (e.g., also) be configured with one or more MTP thresholds (e.g., corresponding to a maximum or minimum difference in latency from an average / expected MTP latency value) associated with the CDRX configurations, which MTP thresholds may indicate the effectiveness of using the CRDX configuration when transmitting and receiving data within the MTP latency.

[0198] The WTRU may be initially configured with a first CDRX configuration (e.g., initial CDRX configuration) having a CDRX cycle duration of 16 ms (e.g., a time difference between a first time period and a last time period in a CDRX cycle is 16 ms), which may be aligned with an average MTP latency value of 17 ms. The first CDRX configuration (e.g., initial CDRX configuration) may enable the WTRU to transmit UL data during a first time period of an on / active duration (t1) of a CDRX cycle, transition to a sleep mode after expiration of the on / active duration, and receive DL data during a first time period of an on / active duration (t1+16 ms) of a subsequent CDRX cycle. When CDRX is configured, the WTRU may determine the MTP latency based on a measurement of the time difference between transmission and reception of associated data or based on another indication received from the application / NAS layer. The WTRU may compare the measured MTP latency in a CDRX cycle with a configured threshold to determine whether the CDRX configuration is valid for transmitting or receiving data in a subsequent CDRX cycle. If the WTRU determines that the MTP latency is above / below the configured MTP threshold, the WTRU may change parameters of the first CDRX configuration (e.g., the initial CDRX configuration) or select a second CDRX configuration (e.g., a new CDRX configuration) so that data transmission / reception can be aligned with the determined MTP latency.

[0199] In an embodiment, the WTRU may know the type of frame (I, B, P) to expect based on an indication from higher layers. If a failed transport block occurs on an I frame or if higher layers indicate a failed I frame reception, the WTRU may stop processing future receptions from the data radio bearer until it receives an indication from higher layers that the next I frame is expected. The WTRU may inform (e.g., additionally inform) the RAN node that future transmissions on this radio bearer may be suspended.

[0200] Although the above-described features and elements are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or may be used in various combinations with or without the other features and elements.

[0201] It will be appreciated that while the implementations described herein may take into account 3GPP-specific protocols, the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, while the solutions described herein take into account LTE, LTE-A, new radio (NR), or 5G-specific protocols, it will be appreciated that the solutions described herein are not limited to this scenario and may be applicable to other wireless systems.

[0202] The above-described processes may be implemented in a computer program, software, and / or firmware embodied in a computer-readable medium for execution by a computer and / or a processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or 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, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as Compact Disc (CD)-ROM disks, and / or Digital Versatile Disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, a terminal, a base station, a Radio Network Controller (RNC), and / or any host computer.

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: a processor, the processor comprising: receiving a configuration message from a network node, the configuration message indicating a first connected mode discontinuous reception (CDRX) active duration and indicating that the first CDRX active duration may be extended; determining uplink data to be sent to the network node; determining an amount of time for extending the first CDRX active duration based on a property of the uplink data; sending assistance information to the network node, the assistance information indicating a request to extend the first CDRX active duration by the amount of time; receiving a confirmation message from a network node, the confirmation message indicating a second CDRX active duration; and receiving a physical downlink control channel (PDCCH) transmission during the second CDRX active duration.

2. The WTRU of claim 1 , wherein the uplink data is uplink extended reality media (XRM) data.

3. The second CDRX active duration is: the first CDRX active duration extended by the requested length of time; or The WTRU of claim 1 , wherein the first CDRX active duration is equal to a different CDRX active duration than the first CDRX active duration extended by the requested amount of time.

4. 2. The WTRU of claim 1, wherein the second CDRX active duration is measured relative to one or more of a number of CDRX cycles, a duration in ms, a duration in symbols, a duration in slots, a duration in subframes, a duration in frames, a start of another CDRX cycle, or a duration indicated by the WTRU.

5. 10. The WTRU of claim 1, wherein the processor is further configured to receive downlink XRM data from the network during the extended CDRX active duration, the downlink XRM data being received in response to the uplink data.

6. The WTRU of claim 1 , wherein the property of the uplink data indicates that the uplink data includes uplink attitude information.

7. The WTRU of claim 1 , wherein the property of the uplink data indicates a motion-to-photon (MTP) parameter or a total round-trip time parameter.

8. The WTRU of claim 7 , wherein the MTP parameter or the total round trip time parameter is based on a configured MTP latency requirement.

9. The WTRU of claim 7 , wherein the MTP parameter or the total round trip time parameter is based on header information included with the uplink data.

10. 8. The WTRU of claim 7, wherein the amount of time for extending the first CDRX active duration is determined based on a difference between the MTP parameter and a time remaining in the first CDRX active duration.

11. The processor, The WTRU of claim 1 , further configured to send the uplink data to the network node during the second CDRX active duration.

12. 1. A method implemented in a wireless transmit / receive unit (WTRU), comprising: receiving a configuration message from a network node, the configuration message indicating a first connected mode discontinuous reception (CDRX) active duration and indicating that the first CDRX active duration may be extended; determining uplink data to be sent to the network node; determining an amount of time for extending the first CDRX active duration based on a property of the uplink data; sending assistance information to the network node, the assistance information indicating a request to extend the first CDRX active duration by the amount of time; receiving a confirmation message from a network node, the confirmation message indicating a second CDRX active duration; receiving a physical downlink control channel (PDCCH) transmission during the second CDRX active duration.

13. The method of claim 12 , wherein the uplink data is uplink augmented reality media (XRM) data.

14. The second CDRX active duration is: the first CDRX active duration extended by the requested length of time; or 13. The method of claim 12, wherein the first CDRX active duration extended by the requested amount of time is equal to a different CDRX active duration.

15. 13. The method of claim 12, wherein the second CDRX active duration is measured relative to one or more of a number of CDRX cycles, a duration in ms, a duration in symbols, a duration in slots, a duration in subframes, a duration in frames, a start of another CDRX cycle, or a duration indicated by the WTRU.

16. 13. The method of claim 12, further comprising receiving downlink XRM data from the network during the extended CDRX active duration, the downlink XRM data being received in response to the uplink data.

17. The method of claim 12 , wherein the property of the uplink data indicates that the uplink data includes uplink attitude information.

18. The method of claim 12 , wherein the property of the uplink data indicates a motion-to-photon (MTP) parameter or a total round-trip time parameter.

19. The method of claim 18 , wherein the MTP parameter or the total round trip time parameter is based on a configured MTP latency requirement.

20. The method of claim 18, wherein the MTP parameter or the total round trip time parameter is based on header information included with the uplink data.

21. 20. The method of claim 18, wherein the amount of time to extend the first CDRX active duration is determined based on a difference between the MTP parameter and a time remaining in the first CDRX active duration.

22. sending the uplink data to the network node during the second CDRX active duration; The method of claim 12 further comprising:

23. A network node for managing QoS flows, comprising: a processor, the processor comprising: determining an uplink packet delay budget (PDB) value associated with a first Quality of Service (QoS) flow and a downlink PDB value associated with a second QoS flow, the uplink PDB value and the downlink PDB value being equal; determining a packet delay for the first QoS flow and the second QoS flow; adjusting the uplink PDB value and the downlink PDB value based on the packet delay; and modifying at least one of a QoS profile, a QoS rule, or a service data flow (SDF) template based on the adjustment.

24. The processor, determining that the uplink PDB value is too low based on the packet delays obtained for the first QoS and the second QoS flows; 24. The network node of claim 23, further configured to: increase the uplink PDB value and decrease the downlink PDB value based on the uplink PDB value being too low.

25. The processor, determining that the uplink PDB value is too high based on the packet delays obtained for the first QoS and the second QoS flows; 24. The network node of claim 23, further configured to: decrease the uplink PDB value and increase the downlink PDB value based on the uplink PDB value being too high.

26. The processor, determining that the downlink PDB value is too low based on the packet delays obtained for the first QoS and the second QoS flows; 24. The network node of claim 23, further configured to: decrease the uplink PDB value and increase the downlink PDB value based on the downlink PDB value being too low.

27. The processor, determining that the downlink PDB value is too high based on the packet delays obtained for the first QoS and the second QoS flows; 24. The network node of claim 23, further configured to: increase the uplink PDB value and decrease the downlink PDB value based on the downlink PDB value being too high.

Images