Adaptive LCP associated with WTRU-autonomous time synchronization with drift detection and network feedback

Abstract

Systems, methods, and instrumentalities may synchronize dependent Protocol Data Unit (PDU) sets at access Stratum (AS) layers. A Wireless Transmit / Receive Unit (WTRU) may receive configuration information from a network node, indicating one or more of: a logical channel prioritization (LCP) action, maximum duration, drift size threshold, or drift duration threshold. The WTRU may receive an indication of a first PDU set for a first flow, a second PDU set for a second flow, and a dependency between the flows. The WTRU may determine a drift size or a duration based on a flow periodicity and a PDU set arrival time, and apply an LCP action based on the drift size or duration exceeding one or more of the thresholds.

Description

ADAPTIVE LCP ASSOCIATED WITH WTRU-AUTONOMOUS TIME SYNCHRONIZATION WITH DRIFTDETECTION AND NETWORK FEEDBACKCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 535,032, filed August 28, 2023, U.S. Provisional Application No. 63 / 535,035, filed August 28, 2023, U.S. Provisional Application No. 63 / 535,037, filed August 28, 2023, U.S. Provisional Application No. 63 / 535,040, filed August 28, 2023, and U.S. Provisional Application No. 63 / 535,041, filed August 28, 2023, the disclosures of which are incorporated herein by reference in its entirety.BACKGROUND

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

[0003] Systems, methods, and instrumentalities may be configured for achieving synchronization between dependent Protocol Data Unit (PDU) sets at access Stratum (AS) layers. A Wireless Transmit / Receive Unit (WTRU) may receive, from a network node, configuration information. The configuration information may indicate one or more of: a logical channel prioritization (LCP) action, a maximum duration, a drift size threshold, or a drift duration threshold. The WTRU may receive an indication. The received indication may indicate: a first Protocol Data Unit (PDU) set associated with a first flow, a second PDU set associated with a second flow, and a dependency between the first flow and the second flow. The WTRU may determine one or more of a drift size or a drift duration based on a periodicity of a flow and an arrival time of a PDU set. The WTRU may, based on the dependency and that the drift size is larger than the drift size threshold or the drift duration is larger than the drift duration threshold: apply the LCP action.

[0004] The received indication may indicate a third flow. The first flow may be associated with a first logical channel (LCH), the second flow may be associated with a second LCH, and the third flow may be associated with a third LCH. A priority associated with the third LCH may be higher than a priority associated with the second LCH. The application of the LCP action may prioritize the second LCH over the third LCH. The WTRU may determine a time associated with the application of the LCP action. The WTRU may send, to the network node, an indication of the determined time. The determined time may be determined based on one or more of the drift size, a PDU set size associated with the PDU set, a PDU set delay bound (PSDB) associated with the PDU set, a number of PDUs in the PDU set, or an amount of data in a buffer of the WTRU.

[0005] The indication sent to the network node may include an indication of an impacted LCH. The impacted LCH may be impacted based on a priority of a first or second LCH changing for a time period, and the time period may be a function of the drift duration. The dependency associated with the first flow and the second flow may indicate that data associated with the first flow is not to be processed unless data associated with the second flow is received. The LCP action may include one or more of an LCP configuration or an LCP restriction. The drift size may include a time difference between the second flow being received and the first flow being received. The drift duration may include a time period during which data packets associated with the second flow arrive after a drift associated with the second flow begins. The LCP action may be applied on one or more of the first flow, the second flow, or an additional flow.BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0007] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0008] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0009] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.DETAILED DESCRIPTION

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

[0011] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a ON 106 / 115, a public switched telephone network (PSTN) 108, the I nternet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the 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 a “ST A”, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g, remote surgery), an industrial device and applications (e.g, a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0012] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the other networks 112. 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, a NR NodeB, a site controller, an access point (AP), a wireless router,and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0013] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change overtime. The cell may further be divided into cell sectors. In examples, 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 for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. In examples, beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

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

[0016] In an 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).

[0017] In an 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).

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

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

[0020] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. 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 an 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 utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

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

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

[0023] 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). In examples, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

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

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

[0026] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. In examples, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an 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.

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

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

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

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

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

[0032] 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. In examples, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0033] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and / or simultaneous. The full duplex radio may include aninterference 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., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

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

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

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

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

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

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

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

[0041] The CN 106 may facilitate communications with other networks. In examples, 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. In examples, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

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

[0043] In representative embodiments, the other network 112 may be a WLAN.

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

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

[0046] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0048] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0049] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11n, 802.11 ac, 802.11af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

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

[0051] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

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

[0053] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. In examples, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g, containing varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0054] 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 the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. In examples, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0055] 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 of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

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

[0057] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. In examples, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of Non-Access Stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. In examples, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. 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.

[0058] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

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

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

[0061] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. In examples, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0062] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. In examples, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or may perform testing using over-the-air wireless communications.

[0063] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. In examples, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0064] Configuration(s) referred to herein, such as configurations that are received at a WTRLI, may refer to configuration information.

[0065] The description is provided for exemplary purposes and does not limit, in any way, the applicability of the methods described herein to other wireless technologies. The term network may refer to one or more gNBs, which may be associated with one or more transmission / reception points (TRPs), or to any other node in a radio access network (RAN).

[0066] The term extended Reality (XR) may be an umbrella term for types of immersive experiences including Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR), and the realities interpolated among them. Virtual Reality (VR) may be a rendered version of a delivered visual and audio scene. The rendering may be designed to mimic visual (e.g., stereoscopic 3D) and audio sensory stimuli of the real world as naturally as possible to an observer or user as they move within the limits defined by the application. Augmented Reality (AR) may be when a user is provided with additional information or artificially generated objects / items or content overlaid upon their current environment. Mixed Reality (MR) may be an advanced form of AR where virtual elements are inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene. XR may include (e.g., all) real-and- virtual combined environments and human-machine interactions generated by computer technology and wearables.

[0067] Immersion (e.g., in the context of XR applications / services) may refer to the sense of being surrounded by the virtual environment and providing the feeling of being physically and spatially located in the virtual environment. The levels of virtuality may range from partial sensory inputs to fully immersive multi-sensory inputs leading to a virtual reality practically indiscernible from actual reality.

[0068] A WTRU may correspond to an XR device / node which may come in form factors. A WTRU (e.g., an XR WTRU) may include, but may not be limited to one or more of the following: Head Mounted Displays (HMD), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with positional tracking and camera, wearables, haptic gloves, haptic body suit, haptic shoes, etc. An XR WTRU may be envisioned based on XR device functions (e.g., as a display, camera, sensors, sensor processing, wireless connectivity, XR / Media processing and power supply) to be provided by one or more devices, wearables, actuators, controllers and / or accessories. One or more device / nodes / WTRUs may be grouped into a collaborative XR group for supporting any of XR applications / experience / services.

[0069] In XR services and applications, the traffic may consist of data / PDUs which may be associated with an application data unit (ADU), PDU set, or data burst. In examples, the PDUs belonging to a PDU set may be associated with segments or components of a video frame or a video slice. A data burst may include one or more PDU sets that may be transmitted / received over a time window. In examples, a number of PDUs in an PDU set or data burst transmitted in UL and / or received in DL may be dependent on the type of the media frame (e.g., 3D video frame, audio frame).

[0070] In XR applications, the WTRU may transmit XR traffic including one or more PDUs / PDU sets in UL (e.g., pose, gesture, video data) and / or receive XR traffic in DL (video, audio, haptics). The traffic may be transmitted and / or received periodically or aperiodically in one or more data flows (e.g., QoS flows). During UL transmissions, XR traffic may arrive from application layer at WTRU and / or from different devices / terminals / WTRUs (e.g., via sidelink) at different time instances. The XR traffic may be characterized by attributes, such as variable payload sizes per PDU set, variable number of PDUs per PDU set, variable per-PDU / PDU set level importance, and levels of inter-dependencies between PDUs / PDUs sets. The XR traffic (e.g., PDU / PDU sets) received by the WTRU may experience delays, jitter, data rate, and loss rate. For QoS and high user experience (QoE), data transmission / reception and associated functions (e.g., prioritization, multiplexing, scheduling) may be done on a timely basis with XR awareness (e.g., awareness of PDU set attributes).

[0071] A WTRU supporting an XR experience may receive data units (e.g., PDUs, PDU sets, data bursts, bitstreams) from higher layers or different devices, such as AR glasses and haptics gloves (e.g., via SL). The data units, which may have variable payload sizes, different periodicity, jitter and different interdependencies, may be further processed and transmitted by the WTRU in the UL.

[0072] Modifications related to capacity may include one or more of the following: multiple Configured Grant (CG) Physical Uplink Shared Channel (PUSCH) transmission occasions in a period of a single CG PUSCH configuration, dynamic indication of unused CG PUSCH occasion(s) based on Uplink Control Information (UCI) by the WTRU, buffer status report (BSR) modifications including at least new BSR Table(s), delay reporting of buffered data in uplink, and discard operation of PDU sets for DL and UL. Modification to power savings may include DRX support of XR frame rates corresponding to non-integer periodicities (e.g., through at least semi-static mechanisms, e.g., Radio Resource Control (RRC) signaling). Modifications for XR awareness include signaling by CN of semi-static information per QoS flow (e.g., PDU set QoS parameters), dynamic information per PDU set (PDU set information and Identification) and End ofData Burst indication, and provisioning by WTRU of XR traffic assistance information, e.g., periodicity and UL traffic arrival information.

[0073] In XR traffic, there may be dependencies between: PDUs of a PDU set, PDU sets (e.g., different PDU set), flows (e.g., different flows), and WTRUs (e.g., different WTRUs).

[0074] Synchronization between the dependent data to determine that data is delivered within a time window of their dependent data may be used at low layers (e.g., lower layers). Synchronized delivery may be determined between data in the UL and DL.

[0075] At the low layers, the WTRU may reduce the drift between two correlated PDU sets. A Synchronization (sync) requirement / threshold may include a maximum time (e.g., measured in ms) and / or distance (e.g., measured in number of slots) between two dependent PDU sets (e.g., between last PDU of one PDU set and last PDU of a dependent PDU set) that can be tolerated by the application. A drift may be when the time window between last PDU of one PDU set and a last PDU of a dependent PDU set is larger than the sync requirement (e.g., from the application) states. The two PDU sets may be in the same or different flows. A drift size may include the amount (e.g., a time difference) by which the time window between two dependent PDU sets exceeds the max sync requirement from the application (e.g., the time difference between the second flow being received and the first flow being received). The drift duration may include the time period the drift lasts is expected to last (e.g., a time period during which data packets associated with the second flow arrive after a drift associated with the second flow begins).

[0076] An adaptive Logical Channel Prioritization (LCP) may maintain time synchronization (e.g., NW controlled, UL). One or more of the following may be included, which may be associated with NW-control: an indication; a mapping table (e.g., the WTRU may receive information on drift (e.g., size / duration) and the WTRU may apply a config based on drift size / duration); and / or a Medium Access Control (MAC) Control Element (CE) from NW may indicate to the WTRU the action to apply.

[0077] LCP adaptations may be NW controlled (e.g., WTRU configured with table). A WTRU may receive configuration information from the NW (e.g., where herein NW may be a NW entity, and a NW entity may be a base station) relating to Logical Channels (LCHs) (e.g., priority, Prioritized Bit Rate (PBR), Bucket Size Duration (BSD)) / LCP configurations, table mapping drift size / duration, and LCP action / LCP restriction / LCH selection. The WTRU may receive PDU sets (e.g., from an application), e.g., in flow A and flow B and an indication of dependencies between flow A and flow B. For example, the WTRU may receive a first PDU set via flow A and a second PDU set (e.g., which has dependencies with the PDU set receivedvia flow A) via flow B. The WTRU may transmit data in UL and send an indication to NW to assist NW in determining drift (e.g., the indication may include PDCP marking of sequence numbers, an indication of dependency between correlated PDU sets, an indication of sequence number of dependent flow B, etc.). The WTRU may receive assistance info / feedback from network (e.g., information on drift si ze / du ration, for example with associated ID). The WTRU may select / activate LCP action / LCP restriction / LCH based on a mapping table (e.g., if drift size > x, the WTRU may perform a configured / associated action).

[0078] LCP adaptations may be NW controlled (e.g., comprising an indication from NW). The WTRU may receive a configuration from NW relating to LCHs (priority, PBR) / LCP configurations. The WTRU may receive PDU sets (e.g., from an application), e.g., in flow A and flow B and an indication of dependencies between flow A and flow B. The WTRU may transmit data in UL and send an indication to NW to assist NW in determining drift (e.g., the indication may include PDCP marking of sequence numbers, an indication of dependency between correlated PDU sets, an indication of sequence number of dependent flow B, etc.). The WTRU may receive a switch indication from the network, (e.g., a binary indication / action, e.g., indication to switch to different LCP configuration). The WTRU may select LCP configuration / LCH accordingly.

[0079] LCP adaptations may be NW controlled (e.g., the WTRU may receive an indication from NW). The WTRU may receive configuration from NW relating to LCHs / LCP configurations and / or LCP restrictions. The NW may preconfigure sets of LCPs (e.g., LCP 1 , 2, 3) and / or LCHs (e.g., LCH 1 , 2, 3). The WTRU may receive PDU sets (e.g., from application), e.g., in flow A and flow B, and an indication of dependencies between flow A and flow B. The WTRU may transmit data in UL and send an indication to the NW to assist the NW in determining drift (e.g., the indication may include PDCP marking of sequence numbers, an indication of dependency between correlated PDU sets, an indication of sequence number of dependent flow B, etc.). The WTRU may receive an indication from the network on LCH / LCP action / LCP restriction to apply (e.g., in MAC CE) and a corresponding duration to apply (e.g, the NW may send an LCP ID, LCH ID, and / or LCP restriction ID). The WTRU may select / activate LCP action / LCP restriction / LCH accordingly.

[0080] Features described herein may be associated with a WTRU autonomous adaptive LCP (e.g, UL). The WTRU may receive a configuration (e.g, configuration information) from the NW (e.g, a network node) relating to (e.g, indicating) LCHs (e.g, priority, PBR), an LCP action (e.g, one or more of an LCP restriction or configuration (e.g, LCP configuration)), an associated max duration T, and / or a drift threshold Td. For example, the drift threshold may include (e.g, as described herein) one or more of a drift sizethreshold or a drift duration threshold. In examples, the WTRU may receive PDU sets (e.g., from an application), e.g., in flow A and flow B and an indication of dependenc(ies) between flow A and flow B. For example, the WTRU receiving the PDU sets may include the WTRU receiving an indication indicating a first PDU set associated with a first flow, a second PDU set associated with a second flow, and a dependency between the first flow and the second flow. The indication may indicate a third flow. The first flow may be associated with a first logical channel (LCH), the second flow may be associated with a second LCH, and the third flow may be associated with a third LCH. A priority associated with the third LCH may be higher than a priority associated with the second LCH.

[0081] The WTRU may determine a drift size / duration. (e.g., based on periodicity of flow against an arrival time of a PDU set). The drift size / duration may include a drift in arrival time between PDU set(s) arriving via flow A and PDU set(s) arriving via flow B. If drift > Td (e.g., the drift size being larger than the drift size threshold or the drift duration being larger than the drift duration threshold), the WTRU may determine to apply the adaptive LCP action by prioritizing LCH associated with the data of a correlated flow (e.g., lower priority LCH) for time t, where t < T. For example, application of an LCP action (e.g., an adaptive LCP action) may occur on (e.g., may be applied to) one or more of the first flow, the second flow, or an additional flow (e.g., the third flow)). The application of the LCP action may prioritize the second LCH over the third LCH. The WTRU may determine to apply the adaptive LCP action based on the dependency between the first flow and the second flow. For example, due to the dependency, the WTRU may prioritize the second LCH over the third LCH even though the third LCH has been indicated as having a higher priority than the second LCH. Determination of t may be based on the drift size, a PDU set size (e.g., associated with the PDU set), a PDU Set Delay Bound (PSDB) (e.g., associated with the PDU set), a number PDUs in PDU set, and / or an amount of data in WTRU buffer. If t > T, the WTRU may send an indication to NW. The WTRU may send an indication to NW on (e.g., indicating) t. The WTRU may send an indication of an impacted LCH (e.g., the impacted LCH may be impacted based on a priority of a first LCH or a second LCH changing for a time period, and the time period may be a function of the drift duration). If drift < Td, the WTRU may apply an LCP (e.g., a legacy LCP).

[0082] The WTRU may trigger BSR (e.g., UL) based on data in its buffer as well as dependent data that may not have arrived. The WTRU may receive a config from the NW relating to BSR (e.g., one or more sets of resources that the WTRU is not expected to use, I D / index) . The WTRU may receive PDU set 1 , information on PDU set 2 (e.g., an indication that PDU set 2 is dependent on PDU set 1), and / or an inter PDU-set sync requirement (e.g., max allowed drift), for example from an application. If PDU set 2 is in itsLCH (e.g., the LCH that PDU set 2 is mapped to), the WTRLI may send a regular BSR. If PDU set 2 is not in its LCH, the WTRU may trigger BSR based on volume of PDU set 1 and send to the NW an indication of dependent PDU set 2 (e.g., expected size (min, max, STD), PSDB, remaining time with respect to max allowed drift). The WTRU may receive a Dynamic Grant (DG) from NW. The WTRU may receive PDU set 2 (e.g., from an application). If the payload of PDU set 1 and PDU set 2 < DG grant size, the WTRU may report on unused resources (e.g., resource ID / index via UCI). The WTRU may send data (e.g., PDU set 1 and PDU set 2) using a DG resource. If the payload of PDU set 1 and PDU set 2 > DG grant size, the WTRU may send an indication to the NW (e.g., SR / BSR).

[0083] Drift alignment may be for DC (e.g., DL). The WTRU may be configured to align / extend DRX active time to align with drift (e.g., for DC). The WTRU may receive a configuration from the network to support multiple DRX preconfigurations, including one or more of: DRX1 for nodel and DRX2 for node2, threshold ThAB to maintain synchronization; or remaining DRX active time Threshold, t. The WTRU may receive from nodel PDU set A1 and an indication to use A1 as a reference PDU set. The WTRU may determine remaining time with respect to ThAB to maintain synchronization. If PDU set B1 is not received within threshold ThAB, and an active / inactivity timer window for DRX2 from node2 is approaching (e.g., remaining time on activity timer < t ms), the WTRU may determine changes to DRX2 from node2 configuration (e.g., the WTRU activates a (e.g., another) DRX config aligned with drift size to extend the PDCCH monitoring window). The WTRU may send to node2 an indication on DRX adjustment (e.g., via MAC CE). In examples, UCI may apply to ongoing PDU sets.

[0084] Features described herein may be associated with Hybrid Automatic Repeat Request (HARQ) retransmission (e.g., UL). The WTRU may determine a mapping of the PDUs of associated PDU sets to multiple Transport Blocks (TBs) based on the sync time window and timing of the PUSCH occasions. The WTRU may implicitly provide info to the NW on the sync time window by indicating the HARQ process IDs of TBs that include the PDUs of the PDU sets. The WTRU may receive, from the NW, a set of HARQ process IDs for indicating associated TBs. The WTRU may receive, e.g., from a higher layer, PDUs of two or more PDU sets and information on the sync time window (e.g., start offset, duration) associated with the PDU sets. The WTRU may receive, e.g., in Downlink Control Information (DCI), resources for multi-TB transmission with multiple PUSCH occasions. The WTRU may determine the mapping of the PDUs of associated PDU sets to multiple TBs and the configured HARQ process IDs based on the sync time window and timing of the PUSCH occasions. The WTRU may transmit an indication (e.g., in UCI) on the HARQ process IDs of associated TBs and info on the sync time window (e.g., TBs including a PDU ofassociated PDU sets may indicate the HARQ process ID of the reference / first TB). The WTRU may transmit the TBs (e.g, TB1 and TB2) that include PDUs from two or more associated PDU sets. The WTRU may receive feedback (e.g., acknowledgment (ACK)Znegative acknowledgment (NACK) and a set of DG resources for retransmitting one or more NACKed TBs (e.g., timing of the DG resources for retransmission may be within sync time window). The WTRU retransmit the NACKed TBs using the DG resources.

[0085] Drift detection / measurement may be performed at the WTRU and / or NW for UL and DL traffic. Adaptive LCP may comprise LCP parameters and / or configurations that are adapted to mitigate the impact of a detected / measured drift between dependent data. A BSR may be triggered by taking into account data that may be dependent on the data in the WTRU buffer and / or data that the data in the WTRU buffer may be dependent on, e.g, to maximize probability of dependent data being multiplexed in the same MAC PDU.

[0086] DRX alignment may be performed to align / extend DRX active time to align with a detected / measured drift.

[0087] Features described herein may be associated with HARQ retransmissions. The WTRU may determine the mapping of the PDUs of associated PDU sets to multiple TBs based on the sync time window and timing of the PUSCH occasions. The WTRU may implicitly provide info to the NW on the sync time window by indicating the HARQ process IDs of TBs comprising the PDUs of the PDU sets.

[0088] The network may include any of a base station (e.g, gNB, TRP, RAN node, access node), core network function (e.g, AMF, SMF, PCF, NEF) and application function (e.g, edge server function, remote server function), for example.

[0089] Flows may correspond to any of: QoS flows or data flows (e.g, flow of data consisting of one or more PDUs, PDU sets or data bursts, which may be inter-dependent with one and another and / or associated with one or more QoS requirements, e.g, latency, data rate, reliability, Round Trip Time (RTT) latency). Different flows originating from a common application / experience source and / or intended to a common destination device / WTRU or group of associated devices / WTRU may be referred to associated flows or correlated flows.

[0090] Throughout the embodiments herein, a data unit may refer to any of: one or more frames (e.g, media / video / audio frame or slice / segment), PDUs, PDU sets, data bursts, group of frames / PDUs / PDU- sets / data bursts, bitstreams. Such data units, which may be transmitted or received by the WTRUsequentially (e.g., one after the other) or in parallel (e.g., over different channels / links / resources) may or may not be inter-dependent with each other.

[0091] Throughout the embodiments herein, forwarding configuration may correspond to any of the following: radio bearers (e.g., data radio bearer (DRB), signaling radio bearers (SRB), transport radio bearer, PDU set bearer); logical channels (LCHs), logical channel groups (LCGs); configuration parameters in the individual layers within the AS protocol stack (e.g., Service Data Adaptation Protocol (SDAP), PDCP, Radio Link Control (RLC), MAC, Physical Layer (PHY), protocol layers); parameters associated with logical channel prioritization (LCP) (e.g., priority, PBR, BSD), Bandwidth Parts (BWPs), carriers, radio links / interfaces (Uu links, SLs); radio resources (e.g., a set of one or more frequency / time / spatial resources such as symbols, slots, subcarriers, resource elements or beams). In examples, radio resources may be associated with configurated grants (CG), dynamic grants (DG) and / or any other resource grants or grant free resources.

[0092] In examples, (e.g., illustrations and / or descriptions), PDU set 1 may refer to one or more PDU sets with similar PDU set level QoS requirements (e.g., same or similar PSDB1, PDU Set Error Rate (PSER) 1 (PSER1), PSII indication, etc.). PDU set 2 may refer to one or more PDU sets with similar PDU set level QoS requirements (e.g., same or similar PSDB2, PSER2, PSII indication, etc.). PDU set 1 may not necessarily refer to a single / singular PDU set. For PDU set 2, PDU set 3, etc., PDU set 1 may be a PDU set type I or a PDU set type II . For PDU set 2, PDU set 3, PDU set A, PDU set B, etc., which may be a PDU set type I or a PDU set type II. Type I PDU sets, for example, may not tolerate loss / delay of a PDU within the PDU set (e.g., loss / delay outside of the bounds of the PSDB for a PDU of the PDU set may render the remaining PDUs of the PDU set useless since the application may need the PDUs (e.g., all of the PDUs) of the PDU set to decode the PDU set). Type II PDU sets may tolerate loss / delay of PDUs within the PDU set.

[0093] PDU sets and the associated characteristics / properties may refer to any of the following. A PDU set may include one or more data units (e.g., PDUs) associated with a media unit or a video frame / slice. Such data units within a PDU set or data burst may be inter-dependent with each other at the application layer and / or lower layers (e.g., AS-layers). The attri butes / properties of a PDU set may be different with each other in terms of, for example, the number of PDUs in a PDU set, payload sizes, intra-PDU set correlation, importance / priority of the data units, status of transmission (e.g., percentage of PDUs of one or more data units transmitted / received successfully), and effective data rate and / or effective reliability associated with transmission.

[0094] In examples, such atributes associated with PDU sets may be visible at one or more lower layers (e.g., at PDCP, RLC, MAC, PHY sub-layers / layers) for supporting (e.g., additional) actions (e.g., prioritizing, mapping to an LCH, multiplexing into one or more TBs, scheduling) based on any of the following: the actions may be supported based on markings in the data units. In examples, such markings may include sequence numbers, IDs, indexes, timestamps, and time offset values (e.g., with respect to a reference time) in the header of data units. Such markings may be made by higher layers, a preceding sub- layer / layer, and / or a device / WTRU.

[0095] The actions may be supported based on reception of an indication, such as a control PDU (e.g., application / higher / NAS layer indication, PDCP control PDU, RLC control PDU, MAC CE, DCI / UCI). Such indication may be received by a WTRU from a preceding / higher layer, from a device / WTRU (e.g., over SL), and from a network, for example.

[0096] The actions may be supported based on mapping of the data units from a higher layer to a configuration associated with a lower layer. In examples, the WTRU may have visibility of higher layer atribute(s) at a low (e.g., lower) layer when mapping the PDUs to one or more radio bearers, logical channels (LCHs), TBs or HARQ processes that may be configured to provide similar forwarding treatment.

[0097] The actions may be supported based on tracking of the atributes of the PDUs at a buffer associated with a sublayer, radio bearer logical channel, or HARQ processes. In examples, the WTRU may track the atributes associated with a PDU set based on the time elapsed since the reception of a first PDU of a PDU set, the remaining time for the PDUs of a PDU set for meeting PSDB, jiter between the arrival one or more PDUs within / across PDU sets, and / or a percentage / payload size of remaining PDUs of a PDU set expected to be received.

[0098] The actions may be supported based on restrictions associated with the sublayer, radio bearer, logical channel, and / or HARQ process to which the data units of PDU sets may be mapped to. In examples, the WTRU may have visibility of the data units and determine the corresponding actions (e.g., perform prioritization per LCP, perform mapping to restricted CG configurations, TBs, HPIs) based on the configured restrictions associated with the one or more sublayers, radio bearers and / or LCHs to which the data units may be mapped to.

[0099] A data burst may refer to the data produced by the application in a short period of time, comprising PDUs from one or more PDU sets. The atributes, associations, and inter-dependencies (e.g., intra-PDU set and / or inter-PDU set), including the start / end indication of a PDU set / data burst (e.g., viasequence number, start / end indication, timestamp), start / end time, duration, payload sizes, periodicity, importance / priority and QoS (e.g., PSDB), may be visible to the AS-layers (e.g., with associated IDs) and / or handled at the AS layers with the awareness of the association during data transmission in UL and reception in DL.

[0100] Regarding an application / high layer importance / priority, the different PDUs in a PDU set or PDUs (e.g., all PDUs) in a PDU set may be associated with different importance / priority values. Such importance value may correspond to spatial importance (e.g., spatial position of the video frame whose data is carried by the PDU / PDU set, where PDUs / PDU set carrying Field of View (FoV) spatial positions may be associated with higher spatial importance than non-FoV spatial positions) or temporal importance (e.g., time sequence of the video / application frame whose data is carried by the PDU / PDU set, where PDUs / PDU sets carrying base video frames, such as l-frame, may be associated with higher temporal importance than differential video frames such as P-frame / B-frame). Such importance values may be visible to the Access Stratum (AS) layers during data transmission and reception.

[0101] Regarding a QoS / data flow, the PDUs / PDU sets of an application may be encoded and delivered by the application to WTRU (in UL) or network (in DL) via one or more QoS / data flows. In this regard, the different QoS flows carrying the PDUs / PDU sets associated to an XR application / experience may be visible to the AS-layers and / or handled at the AS layers with the awareness of such association during data transmission and reception.

[0102] In examples, one or more of the following traffic characteristics and PDU set-level QoS requirements may apply. A PDU set Delay Budget (PSDB) may be a time between reception of the first PDU (e.g., at the UPF in DL, at the WTRU in UL) and the successful delivery of the last arrived PDU of a PDU set (e.g., at the WTRU in DL, at the UPF in UL). PSDB may be an (e.g., optional) parameter, and, when provided, the PSDB may supersede the Packet Delay Budget (PDB).

[0103] A PDU set Integrated Handling Indication (PSIHI) may indicate whether (e.g., all) PDUs of the PDU set are included (e.g, needed) for the usage of a PDU set by application layer.

[0104] A PDU set Error Rate (PSER) may be an upper bound for a rate of non-congestion related PDU set losses between RAN and the WTRU.

[0105] Jitter may refer to variation with respect to an expected time instance during which one or more data units may be received or transmitted. In examples, for a set of data units that may be expected to be received periodically at different periodic time instances, jitter may refer to the variation with respect to theperiodic time instances (e.g., for a data unit that may be received T1 ms in advance or T2 ms later than an expected time instance at T, the jitter range may be T2 - T1 ). Jitter may refer to an instantaneous value or a statistical value (e.g., average, variance, standard deviation, max / min).

[0106] Remaining delay may refer to the time duration remaining for receiving or transmitting one or more PDUs of a PDU set before the PSDB. Remaining delay may be referred to as the time to live (TTL) associated with a PDU set.

[0107] As described herein, multi-PUSCH CG may correspond to one or more configured resources or configured grant (CG) configurations, where a CG configuration may include a set of consecutive or non- consecutive PUSCH occasions per slot and / or per CG period. A multi-PUSCH CG may include one or more CG periods (e.g, a CG period may repeat periodically with a certain periodicity value). A CG period in a multi-PUSCH CG may include one or more consecutive or non-consecutive slots. A slot in a CG period of a multi-PUSCH CG may include one or more consecutive or non-consecutive PUSCH occasions. A PUSCH occasion in a slot / CG period of a multi-PUSCH CG may consist of one or more consecutive or non- consecutive symbols with a certain symbol length (e.g, time domain resources). A PUSCH occasion may consist of one or more resource blocks or resource block groups in the frequency domain.

[0108] As described herein, PUSCH usage may refer to any of the number, location, position or timing of one or more PUSCH occasions in one or more slots or periods, which may be associated with one or more multi-PUSCH CG configurations.

[0109] Features described herein may be associated with synchronization. A Synchronization (sync) requirement may be a maximum time (e.g, measured in ms) and / or distance (e.g, measured in number of slots) between two dependent PDU sets (e.g, between a last PDU of one PDU set and a last PDU of a dependent PDU set) that can be tolerated by the application. A drift may be when the time window between last PDU of one PDU set and last PDU of a dependent PDU set is larger than the sync requirement (e.g, from the application) stipulates. The two PDU sets may be in the same or different flows. A drift size may be the amount by which the time window between two dependent PDU sets exceeds the max sync requirement from the application. A drift duration may be the time period the drift lasts / is expected to last. As described herein, drift may refer to drift size and / or duration. Dependent data may refer to one or more of the following for one or more WTRUs: dependent PDUs within a PDU set; dependent PDU sets; and / or dependent flows. Dependent data may refer to uplink and / or downlink traffic.

[0110] Dependencies may be determined in XR traffic. The WTRU may send to the NW information to assist the NW in determining that there are dependencies in UL data. In examples, the WTRU may receive information from the application on dependencies between two flows and the WTRU may send the information to the network. In examples, the WTRU may determine that there are dependencies in the UL data, e.g., the WTRU may determine that PDUs received together and / or within a short period of time of one another are dependent on each other. The WTRU may transmit this information to the NW.

[0111] In examples, the WTRU may mark PDUs received together and / or within a short period of time of one another as being part of a PDU set, e.g., by adding markings / sequence numbers to the PDUs of the PDU set. Such markings / sequence numbers may be added to the header of the PDU set (e.g., PDCP header). In examples, the WTRU may (e.g., instead of doing in-band marking of the PDUs / PDU sets) send via separate signaling (e.g., MAC CE, UCI) an indication to the NW for the NW to determine the dependencies between the PDUs / PDU sets. In examples, (1 , 2, 3) may correspond to PDU 3 of PDU set 2 of Flow 1 .

[0112] In examples, the WTRU may have determined and / or received information from the application on the dependency between two flows, e.g., there being a dependency between flow A and flow B. In examples, the WTRU may have determined and / or received information from the application on the dependency of PDU sets within flows. In examples, there may be a dependency between PDU set A1 of flow A and PDU set B1 of flow B; in examples, there may be a dependency between PDU set A1 and PDU set A2 of flow A and PDU set B1 of flow B; in examples, there may be a dependency between PDU set A1 of flow A and PDU sets B1, B2, B3 of flow B, etc.

[0113] In examples, the WTRU may determine dependency between PDU set 1 and PDU set 2 and / or the WTRU may receive information on dependencies from an application between PDU set 1 and PDU set 2 (e.g., PDU set 1 from Flow 1 and PDU set 2 from Flow 2; the WTRU may receive information from an application on there being a dependency between Flow 1 and Flow 2).

[0114] In examples, a PDU set may reference another PDU set. In examples, a P-frame may reference its dependent l-frame, e.g., in the header of the P-frame. In examples, the header of PDU set a may have information on PDU set 2 which may be dependent on PDU set 1 .

[0115] Drift may be detected / measured for UL / DL traffic by the WTRU. In examples, the WTRU may receive an indication of the drift (e.g., drift size, drift duration) from the application. In examples, the driftdetectio n, measurement and reporting of the measurement value may happen at the WTRU and / or NW (e.g., detected and measured at the WTRU; detected and measured at the NW; detected at the WTRU, (indicated to the NW), measured at the NW with the value reported back to the WTRU; detected at the NW, (indicated to the WTRU), measured at the WTRU with the value reported back to the NW; etc.).

[0116] Drift may refer to drift value and / or drift duration. In examples, if the delay difference between two flows is to be 15ms or less, and the actual / measured delay difference between the two flows is 20ms, the drift size may be 20 - 15 = 5ms. The drift may last for 10ms, for example, resulting in a drift duration = 10ms.

[0117] In examples, for DL traffic, the WTRU may receive an indication of the drift size / duration from the NW and / or application server. In examples, the WTRU may measure the drift size / duration based on reception of the data in the DL. In examples, the WTRU may receive an indication from the NW / application on the periodicity of flow A. Based on the periodicity knowledge, the WTRU may expect arrival of PDU sets from flow A at (e.g., certain) time instants. If the WTRU does not receive PDU sets from flow A at those time instants, the WTRU may determine that there is a drift. The time difference between when the WTRU expects to receive the PDU sets from flow A (e.g., based on knowledge of periodicity of flow A) and when the WTRU actually receives the PDU sets from flow A may represent the drift size, for example.

[0118] For UL traffic, the WTRU may measure the drift size / duration for UL traffic in one or more of the following ways: the WTRU may determine drift size / duration for UL traffic. In examples, an instantaneous determination may be made (e.g., based on time sync requirements (from app) and actual arrival time of dependent PDU set (e.g., PDU set B1); e.g., based on time difference between periodicity of flow B and actual arrival time of dependent PDU set (e.g., PDU set B1)). An average determination may be made (e.g., for past N PDU sets of flow B with respect to flow A). The drift size / duration for UL traffic may be made based on buffer overflow (e.g., if LCH 1 has data from flow A and LCH 2 has data from flow B).

[0119] The drift size / duration for UL traffic may be made based on the time synchronization requirements (e.g., that the WTRU received from the application in the WTRU) and the actual arrival time of the dependent PDU set.

[0120] In examples, the WTRU may have received information from the application on the sync requirements between flow A and flow B. Based on the sync requirements and the actual arrival time of a dependent PDU set, the WTRU may determine that there is a drift and estimate the drift size. In examples, the WTRU may have received information from the application on a sync requirement between flow A withPDU sets A1 , A2, A3, and so on, and flow B with PDU sets B1, B2, B3, and so on. There may be a one-to- one correspondence for the dependency, e . g. , PDU Set (PS) A1 or flow A is dependent on PS B1 of flow B. When the WTRU receives PS A1 (e. g. , from the XR application in the WTRU), the WTRU may start a timer T (the length of which may correspond to or be a function of the sync requirements). At the expiry of T, if the WTRU has not received PS B1 (e.g., from the XR application in the WTRU), the WTRU may determine that there is a drift. The time difference between the expiry of timer T and the time at which the WTRU actually receives PS B1 may constitute the size of the drift. The WTRU may do this measurement (e.g., a spot check) for (e.g., all) instances of dependency (e.g., start timer T on reception of PDU set A2 and check if PDU set B2 is received within the time sync requirements, and start timer T on reception of PDU set A3 to check that B3 is received on time, etc.). In examples, the WTRU may be configured to do this spot check periodically, for example, every 40ms, 100ms, etc., and / or every n number of slots. In examples, the WTRU may do this spot check on reception of an indication from the NW.

[0121] The drift size / duration for UL traffic may be made based on the time difference between periodicity of a flow and actual arrival time of dependent data.

[0122] In examples, the WTRU may have received information from the application on the periodicity of flow B (e.g., in terms of bitrate, number of PDUs and / or PDU sets per second). Based on this information, the WTRU may start a timer T (e.g., the length of which may correspond to or be a function of interval between two respective PDU sets from the periodicity knowledge). In examples, the WTRU may start timer T on reception of PDU set A1 (e.g., from an application in the WTRU). The WTRU may expect to receive A2 before expiry of timer T. If the WTRU has not received A2 (from the application in the WTRU) by the expiry of T, the WTRU may determine that there is a drift. The time difference between the expiry of timer T and the time at which the WTRU actually receives PS A2 may constitute the size of the drift.

[0123] The drift size / duration for UL traffic may be made based on any one or more of time synchronization requirements, information of periodicity of data / flow, and the actual arrival time of the dependent PDU set.

[0124] In examples, the WTRU may do this measurement (e.g., spot check) for (e.g., all) instances of dependency (e.g., start timer T on reception of PDU set A1 and check if PDU set A2 is received within the time sync requirements, and then start timer T on reception of PDU set A2 to check that A3 is received on time, etc.). In examples, the WTRU may be configured to do the spot check periodically, for example, every 40ms, 100ms, etc. and / or every n number of slots. In examples, the WTRU may do the spot check on reception of an indication from the NW.

[0125] In examples, the WTRU may determine that there is a drift and measure the size of the drift based on a measurement (e.g., based on time difference between arrival of PS A1 and PS A2 from the application in the WTRU). In examples, the WTRU may determine that there is a drift and measure the size of the drift based on more than one measurement, e.g., the WTRU may measure the time difference between arrival of PS A1 and PS A2 and the time different between arrival PS A2 and PS A3 and the time different between arrival PS A3 and PS A4 from the application, etc., and do an average over (e.g., all) the measurements to determine that there is indeed a drift. The determination of the size of the drift may be taken / averaged over several measurements.

[0126] In examples, the WTRU may determine that there is a drift and measure the size of the drift based on a measurement. In the event that there is a drift, the WTRU may make a measurement to confirm the existence of the drift. In examples, if PS A2 arrives late with respect to PS A1 , the WTRU may determine there is a drift after measuring the arrival time of PS A3 with respect to PS A2. In examples, if PS A2 arrives late with respect to PS A1 , the WTRU may determine there is a drift after measuring the arrival time of PS A3 with respect to PS A2 and PS A4 with respect to PS A3, etc.

[0127] As described herein, WTRU receives PDU sets, Reception of PDU sets at WTRU, Arrival of PDU sets may be used in the context of UL traffic, and may refer to the WTRU receiving the PDU sets from the application (e.g., in the WTRU or in a tethered UD). PDU sets may be referred to as PDUs and / or data. In examples, the WTRU may determine that there is a drift and the size of the drift based on N past PDU sets of one flow with respect to the corresponding dependent PDU sets of another flow. In examples, the WTRU may determine that there is a drift based on buffer overflow. In examples, LCH 1 may have data from flow A, and LCH 2 may have data from flow B, and the WTRU may know about dependencies between flow A and flow B and / or LCH 1 and LCH 2. If there is buffer overflow for LCH 2, the WTRU may determine that there is a drift.

[0128] Drift may be detected / measured in UL / DL by the NW. For DL traffic, the NW may detect / measure drift based on indications from the application server. In examples, the WTRU may send indications to the NW on a drift / drift size, which the WTRU may detect / measure based on late arrival of PDUs / PDU sets in the DL.

[0129] For UL traffic, the WTRU may receive information on the drift from the application. The WTRU may send an indication on the drift to the NW. For UL traffic, the WTRU may send information to the NW to enable / allow the NW to determine that there is a drift and what the drift size, for example, by adding markings / sequence numbers to the PDUs of the PDU set. Such markings / sequence numbers may beadded to the header of the PDU set (e.g., PDCP header). In examples, the WTRU may (e.g., instead of doing in-band marking of the PDUs / PDU sets) send via separate signaling (e.g., MAC CE, UCI) an indication to the NW for the NW to determine that there is a drift between dependent PDU sets.

[0130] In examples, where the drift may be detected / measured at the NW, the WTRU may receive feedback / assistance information from the NW following the drift detection / measurement. The feedback / assistance information may include information on the size of the drift and / or the duration of the drift. In examples, the NW may receive information from the application server on the drift size and / or duration. In examples, the NW may determine the drift size based on delayed arrival of data and estimate the drift duration based on, for example, knowledge of past traffic.

[0131] In examples where the NW may detect and / or measure the drift, the NW may send to the WTRU information on the drift, e.g., drift size and / or (e.g., expected) duration and / or the resulting action to take (e.g., any one or more of the LCP adaptations as described for herein).

[0132] Resulting WTRU actions may include LCP configuration(s) / LCH(s) switching / LCP restriction(s). The WTRU may be configured or may receive an indication from the network to perform one or more actions, referred to as an LCP-related action and / or special LCP-related action, to achieve synchronization between multiple flows. The WTRU may receive such an indication from the NW in any of MAC CE / DCI / other DL signaling to perform the one or more actions, and / or the WTRU may measure the drift (e.g., size and / or duration of the drift) and based on the drift (e.g., size and / or duration), the WTRU may determine to perform the one or more actions. The actions may include one or more of the following.

[0133] The actions may include prioritizing logical channel (LCH) with dependent data. In examples, the WTRU may be configured with LCH 1 , LCH 2 and LCH 3 where the respective priorities of LCH 1 , LCH 2 and LCH 3 are of the highest, medium and lowest priority respectively, e.g., LCH 1 has priority 1, LCH 2 has priority 2 and LCH 3 has priority 3. Data in LCH 1 and LCH 3 may be dependent on each other, e.g., data in LCH 1 may not be decoded unless data in LCH 3 is received. The WTRU may prioritize the content of LCH 1 up to the PBR and the content of LCH 2 up to the PBR and the content of LCH 3 up to the PBR.

[0134] Given the dependency between the data in LCH 1 and LCH 3, the WTRU may prioritize LCH 3 over LCH 2 (e.g., when LCH 2 may have a higher priority than LCH3) to account for the dependency and take the data from LCH 3 (e.g., up to its PBR) to multiplex into the MAC PDU.

[0135] In examples, the WTRU may prioritize the data in an LCH to match the priority value of another LCH containing the dependent data. In examples, when multiplexing data in an LCH buffer into a MACPDU or transport block (TB), the priority value applied to the data in an LCH may be the same or comparable to the priority value applied when multiplexing a dependent data in an LCH.

[0136] In examples, the WTRU may prioritize the data consisting of one or more PDUs of a first PDU set to match the priority of another LCH containing one or more PDUs of a second PDU set, which may be dependent on the first PDU set, when meeting certain conditions. The conditions may include any of the following: drift size is less / greater than a threshold value associated with the synchronization requirement; remaining delay of the first and / or second PDU set (e.g., with respect to PSDB values of the associated PDU sets) is less / greater than a threshold; and / or importance value of the first and / or second PDU is less / greater than a threshold.

[0137] The actions may include selecting an LCH / LCP configuration / LCP restriction configuration. The WTRU may have been preconfigured with multiple LCHs, out of which an LCHs may be ‘reserved’ for dependent data. The WTRU may select the LCH reserved for dependent data to map the dependent data. In examples, the WTRU may have been preconfigured with multiple LCP configurations.

[0138] In examples, one of the (e.g., different) LCP configurations that the WTRU may have been preconfigured with may involve (e.g., different) LCH parameters (e.g., different PBR, priority), and the WTRU may adjust the LCH parameters to accommodate the dependent data. In examples, the WTRU may select an LCH and / or a LCP configuration which contains an LCH with a higher PBR such that dependent PDU sets from the logical channel are multiplexed into the MAC PDU. In examples, if the PBR is large enough such that dependent PDU sets mapped to that logical channel is less than the PBR, the dependent data may be multiplexed into the MAC PDU. In examples, the WTRU may select an LCH and / or a LCP configuration which contains an LCH with a higher priority such that dependent PDU sets from the logical channel are multiplexed into the MAC PDU.

[0139] In examples, the WTRU may have been preconfigured with one or more LCP restrictions. In examples, an LCH may be temporarily blocked by the NW. In examples, the WTRU may be configured with LCH 1 , LCH 2 and LCH 3, where the respective priorities of LCH 1 , LCH 2 and LCH 3 are of the highest, medium and lowest priority respectively (e.g., LCH 1 has priority 1 , LCH 2 has priority 2 and LCH 3 has priority 3). In examples, data in LCH 1 and LCH 3 may be dependent on each other (e.g., data in LCH 1 may not be decoded unless data in LCH 3 is also received). The NW may temporarily block LCH 2 such that the dependencies are met.

[0140] In examples, the NW may determine to temporarily block an LCH based on the PDU set parameter(s) for the PDU set mapped to the LCH or to another LCH. In examples, if the TTL (time to live), e.g., the remaining time with respect to the PSDB, for a PDU set mapped to LCH 3 is almost expiring, the NW may temporarily block LCH 2 to prioritize LCH 3 such that the PSDB of the PDU set mapped to LCH 3 is met.

[0141] In examples, a grant may be reserved for dependent data (e.g., dependent PDU set). In examples, the WTRU may receive grants reserved for services / types of data. In examples, grants (e.g., CG configurations) may be reserved for LCHs with dependent data.

[0142] The actions may include requesting the NW for one or more new LCH(s) / LCP configuration(s) / LCP restriction configuration(s). In examples, the WTRU may send a request to the NW requesting the NW to configure a new LCP configuration (e.g., LCHs with new priority, BSD, PBR, etc.) that best enables the WTRU to maintain synchronization between the dependent data. In examples, the WTRU may receive a dynamic indication from the NW on the new LCP configuration and / or parameters associated with the new LCP configuration (e.g., new priority, PBR, or BSD values to apply for one or more LCHs).

[0143] The actions may include applying one or more LCP restriction(s). In examples, the WTRU may block an LCH (of a higher priority) temporarily so that dependent data from a lower priority LCH may be multiplexed into a MAC PDU.

[0144] The actions may include using an LCG that accounts for dependencies. In examples, a WTRU may be configured with an LCG for dependent data and / or for use in the examples of drift. In the event that the WTRU detects a drift or that the drift is larger than a preconfigured threshold, the WTRU (e.g., MAC entity in the WTRU) may group LCHs with dependent PDU sets in the LCG for dependent data. The WTRU may trigger a BSR using the LCG to maximize chances of dependent data being multiplexed in the same / adjacent TB(s).

[0145] In examples, the WTRU may receive an indication to apply the resulting actions indefinitely or until further notice. In examples, the WTRU may receive an indication to apply a LCP restriction until further notice. In examples, an indication may include a time duration for applying the resulting action (e.g., apply LCP restriction Y where the LCH with non-dependent data is blocked for a period of 50ms). In examples, the WTRU may receive an indication form the NW on the duration for which the resulting action should be applied.

[0146] An LCP (Logical Channel Prioritization) configuration may include one or more of the following: LCHs (e.g., number of LCH, LCH IDs), LCHs reserved for dependent data, LCHs per LCP configuration, parameters of a respective LCH (e.g., priority, PBR, BSD), prioritization rules, prioritization restrictions, association between LCHs and configured resources, association between two or more LCHs, etc.

[0147] An Adaptive LCP may maintain time synchronization (e.g., NW controlled). In examples, the WTRU may receive configuration information from the NW (e.g., wherein NW may be a NW entity, and a NW entity may be a base station) relating to LCHs (e.g., with its respective priority, PBR, BSD). The WTRU may receive one or more PDU sets from the application (e.g., in flow A and flow B) and an indication of dependencies between flow A and flow B. The WTRU may receive from the application indication of a drift, and / or the WTRU may detect / measure the drift. The WTRU may transmit the data in the UL to the NW. The WTRU may send to the NW an indication to assist the NW in determining that there is a drift and / or measuring the size of the drift (e.g., the indication may include PDCP marking of sequence numbers taking into account the dependencies). On determination that there is a drift, the WTRU may receive from the NW a simple indication including one or more of the following.

[0148] The indication may include a switch indication. In examples, the WTRU may be configured with two LCP configurations, a default configuration for normal operation, and an LCP configuration for operation when the NW detects drift. The WTRU may use the default configuration until reception of a switch indication from the NW. In examples, if there is a drift (e.g., either from WTRU receiving an indication from the NW on the presence of a drift or from WTRU detecting / measuring the drift), the WTRU may receive an indication to switch to LCP configuration Y. In examples, if the drift size is larger than a threshold, the WTRU may receive an indication to switch to LCP configuration Z. In examples, if the drift duration is longer than a threshold, the WTRU may receive an indication to switch to LCP configuration A for a time duration of T1. Such a switch indication may be received in RRC signaling, MAC CE or DCI.

[0149] The indication may include a switch indication with the LCH and / or LCP configuration and / or LCP restriction (e.g., LCH ID, LCP ID, LCP restriction ID) (e.g., switch to a different LCH and / or LCP configuration and / or LCP restriction).

[0150] The WTRU may receive the switch indication after the NW has determined that there is a drift and / or after the NW has measured that the drift is larger than a threshold. In examples, the WTRU may receive a switch indication from the NW after the WTRU has informed the NW of a drift that the WTRU has measured / detected.

[0151] In examples, the WTRU may be configured with a table with options for actions, e.g., select an LCP configuration, apply an LCP restriction etc. based on an indication of the drift (e.g., from an indication of the presence of a drift and / or when the drift size is larger than a threshold, where such indication may be received from the NW or determined by the WTRU based on measurements of the drift). In examples, if there is a drift (e.g., from the WTRU receiving an indication from the NW on the presence of a drift or from the WTRU detecting / measuring the drift), the WTRU may apply LCP configuration Y. In examples, if the drift size is larger than a threshold, the WTRU may apply LCP configuration Z. In examples, if the drift duration is longer than a threshold, the WTRU may apply LCP configuration A for a time duration of T1 .

[0152] LCP adaptations may be NW controlled (e.g., comprising an indication from the NW. The WTRU may receive configuration from the NW relating to LCHs (priority, PBR) / LCP configurations. The WTRU may receive PDU sets (e.g., from an application), e.g., in flow A and flow B and an indication of dependencies between flow A and flow B. The WTRU may transmit data in UL and send an indication to NW to assist NW in determining drift, (e.g., the indication may include PDCP marking of sequence numbers, an indication of dependency between correlated PDU sets, an indication of sequence number of dependent flow B, etc.). The WTRU may receive a switch indication from the network, (e.g., binary indication / action, e.g., indication to switch to different LCP configuration). The WTRU may select an LCP configuration / LCH accordingly.

[0153] LCP adaptations may be NW controlled (e.g., the WTRU may receive an indication from the NW. The WTRU may receive a configuration from the NW relating to LCHs / LCP configurations, and / or LCP restrictions. The NW may preconfigure sets of LCPs (e.g., LCP 1 , 2, 3) and / or LCHs (e.g., LCH 1 , 2, 3).The WTRU may receive PDU sets (e.g., from the application), e.g., in flow A and flow B and an indication of dependencies between flow A and flow B. The WTRU may transmit data in UL and send an indication to the NW to assist the NW in determining drift (e.g., the indication may include PDCP marking of sequence numbers, an indication of dependency between correlated PDU sets, an indication of sequence number of dependent flow B, etc.). The WTRU may receive an indication from the network on LCH / LCP action / LCP restriction to apply (e.g., in MAC CE) and a corresponding duration to apply (e.g., the NW may send LCP ID, LCH ID, and / or LCP restriction ID). The WTRU may select / activate an LCP action / LCP restriction / LCH accordingly.

[0154] LCP adaptations may include the WTRU being configured with a table. The WTRU may receive a configuration from the NW on LCHs (e.g., priority, PBR, BSD) / LCP configurations, a table mapping drift size / duration and an LCP action / LCP restriction / LCH selection, and thresholds related to drift size, e.g., x.The WTRU may receive PDU sets from an application, e.g., in flow A and flow B, and an indication of dependencies between flow A and flow B. The WTRU may transmit data in UL and send an indication to the NW to assist the NW in determining drift (e.g., PDCP marking of sequence numbers and dependency between correlated PDU sets, sequence number of dependent flow B, etc.). The WTRU may receive assistance info / feedback from the network, (e.g., information on drift size / duration (with associated ID)). The WTRU may select / activate an LCP action / LCP restriction / LCH based on mapping table (e.g., if drift size > Threshold x, the WTRU may do a configured / associated action (e.g., use a (e.g., different) LCH and / or LCP configuration and / or LCP restriction).

[0155] An LCP-related action may include using a (e.g., special) LCG to account for dependencies. The WTRU may be configured with an LCG for dependent data. The WTRU may trigger a BSR using the LCG to maximize chances of dependent data being multiplexed in the same / adjacent TBs. The WTRU may receive a config from the NW on LCP configurations (e.g., LCG 0-3 = legacy, LCG 4 for dependent data) and thresholds related to drift size, e.g., x. The WTRU may receive an indication on the drift from the NW. If the drift size > Threshold x, the WTRU (e.g., MAC entity in the WTRU) may group LCHs with dependent PDU sets in one LCG, e.g., LCG 4 (e.g., WTRU sends BSR with LCG ID 4). The WTRU may send an indication to the NW on changes to LCP behavior, (e.g., activation of LCG 4 for dependent data, time duration for using LCG 4). The indication may be sent as part of BSR for example. The WTRU may receive a grant from the NW. The WTRU may multiplex data into the grant. The WTRU may transmit dependent data using the grant.

[0156] An adaptive LCP may maintain time synchronization (e.g., WTRU autonomous). In a WTRU autonomous example, the WTRU may determine the size / duration of the drift as described herein. The WTRU may receive from the application information on the drift size / duration. Since the NW is the entity receiving the data (in the UL), the WTRU may receive an indication of a drift from the NW. The WTRU may receive from the network one or more of the following.

[0157] The WTRU may receive from the network configuration for a ‘special’ LCP-related action to account for / mitigate the impact of the drift, e.g, LCP restrictions, LCHs, LCP configurations as described herein. In examples, the WTRU may receive from the network an associated maximum duration T for which the WTRU is allowed to apply / activate the LCP restrictions described herein, LCHs, and LCP configurations to account for / mitigate the impact of the drift. In examples, the maximum duration T may be indicated to the WTRU by the NW in terms of a time duration (e.g, s, ms) and / or number of slots. The WTRU may receivea time duration T for an LCP-related action to mitigate drift and / or the WTRU may receive time duration Ti’s, where a Ti may be associated to an LCP-related action.

[0158] In examples, a maximum time duration T that an LCP configuration X may be applied for may be 50ms; in examples, a maximum time duration T that an LCP restriction Y may be applied for may be 100ms; etc. In examples, the WTRU may determine the length of time t for which to apply / activate the (e.g., special) LCP-related action, where t may be a function of the drift duration, for example. The length of time t for which the WTRU applies / activates the ‘special’ LCP-related action may be less than or equal to T, the maximum duration T for which the WTRU is allowed to apply / activate the aforementioned LCP restrictions, LCHs, and LCP configurations. Length of time t may be estimated by the WTRU in terms of time units (e.g., s, ms) and / or number of slots.

[0159] The WTRU may receive from the network a length of time t for which to apply / activate an LCP- related action to account for / mitigate the impact of the drift. The WTRU may receive from the network thresholds corresponding to drift. In examples, drift threshold Td may assist in determining whether to apply the LCP-related action.

[0160] If drift size > Td, the WTRU may apply an LCP restriction A whereby the LCH with dependent data is prioritized at the expense of the LCH with non-dependent data for a time. In examples, a threshold may correspond to drift duration / length, TL. If drift duration > TL, the WTRU may apply an LCP restriction B whereby the WTRU may use grants (e.g., grants from a configured grant configuration) to multiplex dependent data to minimize the impact of the drift.

[0161] The WTRU may receive from the network a reconfiguration related to LCP. In examples, if the NW determines that the WTRU is experiencing (e.g., frequent) drifts and / or drifts of considerable size, the NW may send to the WTRU reconfigurations for LCP restrictions and / or LCHs and / or LCP configurations. In examples, the NW may configure an LCH reserved for dependent data to minimize drift. In examples, the NW may increase the LCH parameters (e.g., priority, PBR) of (e.g., all) the LCHs at the LCH or the LCH parameters reserved for dependent data. In examples, the NW may send a (e.g., new) LCP restriction to the WTRU to block an LCH with non-dependent data for a duration of (e.g., some) time.

[0162] In examples, a time duration may exist for which to apply reconfiguration. In examples, the reconfiguration by the NW may apply indefinitely (e.g., until further reconfiguration) and / or for a time period (e.g., for the next 500ms). In examples where the reconfiguration applies for a time period, the NW may send the applicable time period to the WTRU.

[0163] The WTRU may send to the NW one or more of the following. The WTRU may send to the NW information on drift, e.g, drift size and / or duration. The WTRU may send to the NW LCP-related action that the WTRU determines to apply / activate to account for / mitigate the impact of the drift, e.g., LCP restrictions, LCHs, LCP configurations, e.g., in terms of the LCH ID if the WTRU determines to use / prioritize an LCH and / or in terms of a LCP config ID if the WTRU is configured with multiple LCP configurations and the WTRU determines to activate an (e.g., particular) LCP configuration to mitigate the impact of the drift. The WTRU may send to the NW a length of time t for which the WTRU determines to apply / activate an LCP- related action to account for / mitigate the impact of the drift. The WTRU may send to the NW impacted parameter(s) from the detection / measurement / mitigation of the drift.

[0164] In examples, the WTRU may be configured with LCH 1 , LCH 2 and LCH 3, where the respective priorities of LCH 1 , LCH 2 and LCH 3 are of the highest, medium and lowest priority respectively, e.g, LCH 1 has priority 1, LCH 2 has priority 2 and LCH 3 has priority 3. Data in LCH 1 and LCH 3 may be dependent on each other, e.g, data in LCH 1 may not be decoded unless data in LCH 3 is received. The WTRU may prioritize the content of LCH 1 up to the PBR and the content of LCH 2 up to the PBR and the content of LCH 3 up to the PBR. To mitigate the impact of the drift, the WTRU may temporarily prioritize content of LCH 3 over content of LCH 2 to maintain the dependencies. If the current configuration results in a drift, the WTRU may inform the NW of the impacted LCH, e.g, that LCH 3 is prioritized over LCH 2 for a (e.g, some) time. The WTRU may provide the reason for the temporary prioritization (e.g, to mitigate the impact of the drift).

[0165] The NW may in response send a reconfiguration to the WTRU, for example, to adjust the priority of LCH 3 such that the priority of LCH 3 becomes greater than the priority of LCH 2. The reconfiguration by the NW may apply indefinitely (e.g, until further reconfiguration) and / or for a time period (e.g, for the next 500ms). In examples where the reconfiguration applies for a time period, the NW may send the applicable time period to the WTRU.

[0166] The length of time t may be determined. The WTRU may determine the length of time t for which to apply / activate LCP-related action to account for / mitigate the impact of the drift based on one or more of the following: drift size; drift duration; PDU set size; PSDB; remaining time with respect to PSDB (e.g, TTL); number of PDUs in PDU set; amount of data in WTRU buffer (e.g, in PDCP buffer and / or RLC buffer and / or MAC buffer); and / or amount of grants available (e.g, number and / or size of MAC PDU available (e.g, with no data) that the WTRU may use to multiplex data).

[0167] In examples, where the length of time t may be larger than the associated maximum duration T for which the WTRU may apply / activate the LCP-related action, the WTRU may send an indication to the network regarding the length of time t. In examples, the indication may be a simple indication to indicate that t > T, and / or the indication may indicate the amount by which t is larger than T. In examples, the WTRU may do one or more of the following.

[0168] The WTRU may activate another LCP-related action. In examples, if the associated maximum duration T for one LCP-related action 1 is t1 , and the associated maximum duration T for another LCP- related action 2 is t2, where t2 > t1 , and if the WTRU’s preferred choice may have been action 1 , the WTRU may determine to activate action 2, especially if action t < t2. The WTRU may activate the same LCP-related action for the associated maximum duration T. In examples, the WTRU may activate the LCP- related action for a time T if T < t.

[0169] Features described herein may be associated with a WTRU autonomous adaptive LCP (e.g., UL). The WTRU may receive a configuration (e.g., configuration information) from the NW (e.g., a network node) relating to (e.g., indicating) LCHs (e.g., priority, PBR), an LCP action (e.g., one or more of an LCP restriction or configuration), an associated max duration T, and / or a drift threshold Td. For example, the drift threshold may include (e.g., as described herein) one or more of a drift size threshold or a drift duration threshold. In examples, the WTRU may receive PDU sets (e.g., from an application), e.g., in flow A and flow B and an indication of dependenc(ies) between flow A and flow B. For example, the WTRU receiving the PDU sets may include the WTRU receiving an indication indicating a first PDU set associated with a first flow, a second PDU set associated with a second flow, and a dependency between the first flow and the second flow. The indication may indicate a third flow. The first flow may be associated with a first logical channel (LCH), the second flow may be associated with a second LCH, and the third flow may be associated with a third LCH. A priority associated with the third LCH may be higher than a priority associated with the second LCH.

[0170] The WTRU may determine a drift size / duration. (e.g., based on periodicity of flow against an arrival time of a PDU set). The drift size / duration may include a drift in arrival time between PDU set(s) arriving via flow A and PDU set(s) arriving via flow B. If drift > Td (e.g., the drift size being larger than the drift size threshold or the drift duration being larger than the drift duration threshold), the WTRU may determine to apply the adaptive LCP action by prioritizing LCH associated with the data of a correlated flow (e.g., lower priority LCH) for time t, where t < T. The application of the LCP action may prioritize the second LCH over the third LCH. The WTRU may determine to apply the adaptive LCP action based on thedependency between the first flow and the second flow. For example, due to the dependency, the WTRU may prioritize the second LCH over the third LCH even though the third LCH has been indicated as having a higher priority than the second LCH. Determination of t may be based on the drift size, a PDU set size (e.g, associated with the PDU set), a PDU Set Delay Bound (PSDB) (e.g., associated with the PDU set), a number PDUs in PDU set, and / or an amount of data in WTRU buffer. If t > T, the WTRU may send an indication to NW. The WTRU may send an indication to NW on (e.g., indicating) t. The WTRU may send an indication of an impacted LCH (e.g., the impacted LCH may be impacted based on a priority of a first LCH or a second LCH changing for a time period, and the time period may be a function of the drift duration). If drift < Td, the WTRU may apply an LCP (e.g., a legacy LCP).

[0171] The WTRU may trigger BSR based on availability of data in its buffer. The WTRU may trigger BSR based on the presence of data in its buffer as well as availability of dependent data that may not have arrived but is expected to arrive (e.g., as opposed to triggering BSR only based on availability of data in its buffer). The WTRU may have sufficient resources for transmitting dependent data such that the dependent data is received by the receiving entity within the required synchronization time window.

[0172] The WTRU may receive one or more of the following from the network. The WTRU may receive a configuration from the network relating to BSR. The configuration from the network on BSR may include one or more sets of resources that the WTRU is not expected to use (e.g., in terms of resource index / ID), e.g., that the WTRU is expected to use in examples of there being dependent data and / or examples where the WTRU may mitigate the impact of drift and determine that the dependent PDU sets are delivered within the time synchronization requirements from the application. The configuration from the network relating to BSR may include when to use the BSR (e.g., when the WTRU has dependent data; when the WTRU has important data; and / or when importance of dependent data or part thereof is above a preconfigured threshold received from the network). Importance (e.g., importance metric) of dependent data or part thereof may be above a preconfigured threshold received from the network when, for example, PSI of both PDU set 1 and PDU 2 is above a threshold, and / or when PSI of either PDU set 1 and PDU 2 is above a threshold.

[0173] The WTRU may receive one or more of the following from the application. The WTRU may receive PDU sets (data) from the application; information on PDU sets (e.g., PSI, dependency information between PDU sets); and / or Inter PDU set sync requirements (e.g., maximum allowed drift).

[0174] The WTRU may be configured to check the status of dependent PDU set. Before sending the BSR, the WTRU may check the status of a dependent data in its buffer. In examples, if there aredependencies between PDU set A and PDU set B, and the WTRU has received in its buffer (e.g., from the application layer) PDU set A, the WTRU may be configured to check the status of PDU set B and do one or more of the following. If PDU set B is in its LCH buffer, the WTRU may send a regular BSR with a BSR index pointing to the sum of the volume / size / number of PDUs of PDU set A and PDU set B, e.g., based on the data volume calculation. If PDU set B is not in its LCH buffer, the WTRU may trigger the BSR based on volume / size / number of PDUs of PDU set A and send to the NW an indication of dependent PDU set B, e.g., expected size (min, max, STD), PSDB, remaining time with respect to max allowed drift, etc.

[0175] The WTRU may determine whether to trigger a secondary BSR such that the requirement on synchronization time window for receiving PDU sets from multiple flows are met. In examples, the WTRU may determine to trigger a default BSR and / or a secondary BSR based on the presence of PDUs of PDU sets from one or more XR traffic flows and based on whether or not the WTRU expects to receive additional PDUs of a PDU set from a dependent traffic flow after a configured period of time. The low (e.g., lower) layers in the WTRU, e.g., MAC layer, may receive PDUs of one or more PDU sets belonging to a traffic flow generated from an XR application. The WTRU, e.g., MAC layer, may expect to receive PDUs of one or more PDU sets belonging to another flow which are dependent (e.g., generated from the same XR application) to the set of PDUs which belong to the flow received. The WTRU may aim for PDU sets belonging to the multiple and dependent flows to arrive at the receiving entity (e.g., MAC layer the network) within the required synchronization time window. Depending on the availability of the dependent data / PDU set, the WTRU may trigger the secondary BSR which may indicate the need for (e.g., additional) resource grants to accommodate the data / PDU sets present in the buffer and the dependent data / PDU sets which have not arrived in the buffer.

[0176] In examples, the WTRU may be configured with more than one BSR table. The WTRU may use a (e.g., legacy) and / or XR-specific BSR table to indicate the amount of data in the WTRU buffer and another BSR table to indicate the dependent data that may not be in its buffer but that may be dependent on the data that is in its buffer and / or that the data in its buffer may be dependent on. The WTRU may send two BSR to the network, a BSR based on data in the WTRU’s buffer and a BSR based on data not in its buffer but dependent on the data that is in its buffer and / or that the data in its buffer may be dependent on. In examples, the WTRU may be configured to send one or more special BSRs, which may allow the WTRU to indicate two indices (versus a (e.g., legacy) BSR whereby the WTRU may indicate an index that most closely corresponds to the volume of data in its buffer). An index may correspond to the amount of data in the WTRU buffer (e.g., PDCP buffer, RLC buffer, LCH buffer, MAC buffer) that the WTRU may havedetermined based on the data volume calculation. An index (e.g., other index) may correspond to the amount of data that may be dependent on the data that is in the WTRU buffer and / or that the data in the WTRU buffer may be dependent on.

[0177] In examples, the WTRU may receive, from the network, configuration information for triggering a secondary BSR based on the expectation of additional data / PDUs of a PDU set from a dependent flow which have not arrived at the buffer. The configuration information may include a default set of resources corresponding a default BSR and a set of secondary resources corresponding to a secondary BSR for accommodating late arriving dependent data. The WTRU may receive a set of rules and / or restrictions for triggering the secondary BSR. The set of rules and / or restrictions based on which the WTRU may trigger the secondary BSR may include one or more of the following:

[0178] The WTRU may trigger the secondary BSR if one or more dependent data / PDU set is expected to arrive to the low (e.g., lower) layer (e.g., LCH) after a duration of time. The WTRU may trigger the secondary BSR if there is one or more PDU set belonging to an independent application / traffic and which may have higher priority level relative to an inter dependent PDU set. The WTRU may trigger the secondary BSR if the priority level of an interdependent PDU set relative to at least one of the interdependent PDU sets exceeds a priority threshold.

[0179] The WTRU may receive, from an XR application, PDU sets from one or more flows and explicit or implicit information from application / high layers / network for assisting or indicting the dependency between different data flows. The PDU set related information may include information on the PDU sets’ profile (e.g., relative importance of the PDU sets, payload size, etc.). The information may be received periodically or aperiodically / dynamically in RRC signaling, MAC CE, DCI, NAS-layer signalizing, and / or application layer signaling, for example.

[0180] In examples, the WTRU may determine whether one or more PDU sets received are dependent to each other and / or generated from a common application / service based on explicit and / or implicit parameters / identifiers detectable by the WTRU in the data flows. The parameters / identifiers for determining the dependency between PDU sets from multiple flows may be configured in the WTRU (e.g., via RRC signaling, NAS-layer signaling or application layer signaling), for example. The parameters / identifiers used by WTRU for identifying the dependency between data PDU sets from multiple flows may include of one or more of the following:

[0181] The parameters / identifiers used by the WTRU may include identifiers / IDs associated with flows and / or an application the PDU sets belong to. In examples, the WTRU may determine PDU set A from a first flow, and a PDU set B from a second flow may be associated with an application when the WTRU detects a common ID associated with the application within the PDUs (e.g., in header and / or payload) of PDU set A and PDU set B. The ID of the application may be preconfigured in the WTRU, for example.

[0182] The parameters / identifiers used by WTRU may include Priority / i mportance info associated with the PDU sets. In examples, the WTRU may determine PDU set A, and PDU set B may be associated with an application based on detection of common and / or similar priority / importance indications in the PDUs (e.g., in header and / or payload) of PDU set A and PDU set B. In examples, the WTRU may determine the PDU sets that may be associated when the priority / importance indications detected by the WTRU (e.g., in PDU header or payload) may be above / below one or more priority / importance threshold values.

[0183] The parameters / identifiers used by the WTRU may include temporal / timing information in interdependent PDU sets. In examples, the WTRU may determine PDU set A, and PDU set B may be associated when one or more PDUs in PDU set A and one or more PDUs in PDU set B may be received by the WTRU within a time duration / window. The time duration / window may correspond to the time difference between the reception time of a PDU in PDU set A (e.g., at t1 ) and the reception time of a PDU in PDU set B (e.g., at t2), for example. The WTRU may determine PDU set A and PDU set B may be associated when the time difference (e.g., t2 - 11) is less than a time duration / window threshold value. In examples example, the WTRU may determine PDU set A and PDU set B are associated based on the common format and / or granularity of the timing information (e.g., timestamps) carried in the PDUs associated with the PDU sets.

[0184] The parameters / identifiers used by the WTRU may include spatial / pose information in associated flows. In examples, the WTRU may determine PDU set B and PDU set B are associated when the PDUs carrying the spatial information correspond to common spatial parameters. The spatial parameters, for example, may include any of the following: direction / orientation of FoV of the user / UE / devices, slice / tile of the video / media frame, location info (e.g., coordinates), pose info, etc. The spatial parameters may be determined by the WTRU based on detection on (e.g., certain) PDUs transporting spatial information (e.g., pose / control PDU which may be identified by WTRU based on data type identifiers) or detection of other PDUs which may contain spatial information within the PDUs (e.g., in header and / or payload), for example.

[0185] In examples, the WTRU may determine to trigger a secondary BSR if one or more of the conditions are met. The WTRU may trigger the secondary BSR if one or more of the following conditions are met. The WTRU may trigger the secondary BSR if one or more PDU sets have arrived at the low (e.g.,lower) layers (e.g., at LCH) while at least one dependent PDU set is expected to arrive. In examples, the low (e.g., lower) layer (e.g., LCH) in the WTRU may have received, e.g., from application layer, PDU set A belonging to flow 1 while it is waiting to receive PDU set B. PDU set B may belong to flow 2 and may be dependent to PDU set A. To meet the PSDB requirement and maintain the PDU set synchronization time window, the WTRU may trigger the secondary BSR based on the volume PDU set A and the expected volume / size of PDU set B.

[0186] The WTRU may trigger the secondary BSR if the low (e.g., lower) layer (e.g., LCH) in the WTRU receives one or more PDU sets not related to the XR application but has a higher priority / importance level relative to an interdependent PDU sets belonging to a common application or related applications. In examples, the low (e.g., lower) layer (e.g., LCH) in the WTRU may receive, e.g., from the application layer, PDU set A belonging to flow 1 and PDU set B belonging to flow 2, which may be dependent to PDU set A. The low (e.g., lower) layer may have received one or more i ndependent / u nrelated PDU sets which may have a higher priority / importance level relative to PDU set B. The arrival of an independent PDU set with a higher priority relative to PDU set A or PDU set B may delay scheduling of PDU set A or PDU set B for UL transmission since the BSR may be based on the information on the independent PDU set with a higher priority level and one of the dependent PDU sets (PDU set A or PDU set B).

[0187] In examples, after sending the secondary BSR, the WTRU may receive resource grant (e.g., DG) allocated for transmitting PDU set A and PDU set B which may have arrived at the lower layer (e.g., LCH) during the triggering of the secondary BSR and reception of resource grant. If the resource granted after triggering of the secondary BSR is larger than the combined volume / payload size of PDU set A and PDU set B, as well as independent PDU set assigned the same LCH as PDU set A (e.g., due to having higher or similar importance level), the WTRU may send an indication (e.g., via UCI) informing the network regarding the remaining / unused resources. The WTRU may use the resource granted for transmitting PDU set A and PDU set B ensuring arrival at the receiving entity within the synchronization time window. If the resource granted after triggering of the secondary BSR is not enough to accommodate the combined volume / payload size of PDU set A, PDU set B, and an independent PDU set assigned the same LCH as PDU set A (e.g., due to having higher or similar importance level), the WTRU may send a scheduling request and / or a new BSR for transmitting (e.g., all) available PDU sets in its buffer.

[0188] In examples where the WTRU may have been configured with one or more resource sets that the WTRU is expected to use to handle dependencies in the XR traffic and / or to mitigate the impact of the drift, the WTRU may not need (e.g., all) the resource sets. The WTRU may send an indication to the gNB (e.g.,via UCI or MAC CE) on the unused resource set(s), e.g., in terms of resource set ID(s). The NW may adjust the number and / or size of the resource set(s) that the WTRU is configured with.

[0189] A DRX active time may be adjusted for aligning a time drift between the PDU sets from two nodes in DC. In (e.g., legacy) DC, the WTRU may be configured with two MAC entities in which one MAC entity may correspond with a first node / cell group (e.g., MCG) and a second MAC entity corresponds with a second node / cell group (e.g., SCG). Two (e.g., separate) DRX configurations may be provided to the WTRU by the first and second nodes / cell groups independently of each other. When the WTRU is expected to receive multiple and dependent traffic flows, e.g., PDU set A and an associated PDU set B where PDU set A belongs to flow 1 and PDU set B belongs to flow 2 such that a (e.g., each) flow is arriving from the two separate nodes / cell groups in DC, a drift between flows may occur. Since the receiving MAC entities in the WTRU monitor PDCCH independently for receiving PDU set A and PDU set B, the WTRU may determine that the DRX active time is aligned with the drift occurring during reception / transmission of PDU set A and PDU set B.

[0190] The WTRU may be configured to perform one or more of the following. The WTRU may receive configuration from the network to support multiple DRX configurations, including a default DRX configuration (e.g., DRX1 from nodel and DRX2 from node2, a threshold (e.g., ThAB, to maintain synchronization), and a threshold value t (e.g., related to the remaining DRX active time). The WTRU may receive PDU set A from nodel which may include an indication to use PDU set A as a reference PDU set. The WTRU may determine remaining time relative to ThAB for maintaining a synchronization time window between PDU set A and PDU set B. If PDU set B1 is not received within threshold ThAB, and active / inactivity timer window for DRX2 from node2 is approaching (e.g., remaining time on activity timer < t ms), the WTRU may determine changes to DRX2 from node2 configuration (e.g., the WTRU may activate a DRX configuration aligned with drift size to extend the PDCCH monitoring window). The WTRU may send to node2 an indication on DRX adjustment (e.g., via MAC CE). A UCI may be applied to ongoing PDU sets.

[0191] The WTRU may determine the DRX configuration to use in one of the two nodes in DC to align DRX active time with a timing drift between the data / PDU sets transmitted from a node. The WTRU in DC mode may determine the adjustment which may be made on one of the two DRX configurations corresponding to the two nodes it is connected to when receiving PDU sets which are dependent to each other and which are received within a synchronization time window. Based on a timing drift occurring between PDU sets originating from the two separate nodes, the WTRU may select a DRX configuration,e. g . , from preconfigured set of DRXs, which may align to the drift that is occurring, so that the synchronization timing window requirement is maintained.

[0192] To mitigate the impact of the drift and / or realign the traffic with the drift size / duration, resulting WTRU actions may include one or more of the following for the one or more nodes / gNBs / TRPs that the WTRU may have Uu links with the WTRU actions may include activating and / or requesting for activation from the NW for a (e.g., different) DRX configuration (e.g., out of a list of DRX configurations that the WTRU may have been preconfigured with). In examples, a different DRX configuration may align with the DL traffic given the detected / measured drift which may have been measured / detected at the WTRU and / or gNB. The WTRU may request for a different DRX configuration from the NW.

[0193] In examples, if a DRX configuration does not have a better alignment with the DL traffic given the detected / measured drift, the WTRU may request / activate an (e.g., different) DRX configuration from the NW.

[0194] The WTRU may extend a length and / or request from the NW for an extension of the length of onDuration timer for existing (e.g., currently activated) DRX configurations. In examples, the WTRU may determine that applying an extension to the length of the onDuration timer for the currently activated DRX configuration may allow for alignment of the downlink traffic with the drift.

[0195] The WTRU may extend a length and / or request from the NW for extension of the length of inactivity timer for existing (e.g., currently activated) DRX configurations. In examples, the WTRU may determine that applying an extension to the length of the inactivity timer for the currently activated DRX configuration may allow for alignment of the downlink traffic with the drift.

[0196] The WTRU may activate and / or request from the NW for activation of a timer (e.g., Inactivity timer 2) following the end of the (e.g., current) active time. In examples, the WTRU may determine that activating a timer (e.g., Inactivity timer 2, onDuration timer 2) for the currently activated DRX configuration immediately after the end of the currently activated timer (e.g., Inactivity timer, onDuration timer) may allow for alignment of the downlink traffic with the drift.

[0197] The WTRU may shorten and / or request from the NW for the shortening of the length of the current timer (e.g., onDuration timer) and lengthen and / or request from NW for the lengthening of the length of the next timer (e.g., next onDuration timer). In examples, due to the presence of a drift, the DL traffic may be delayed to a later time. The WTRU may determine to shorten the length of the current onDuration time, and elongate the length of the next onDuration timer to align the downlink traffic with the drift.

[0198] The WTRU may apply an offset to the start of the next timer (e.g., for the onDuration time). In examples, the WTRU may determine that applying an offset to the start of the next onDuration timer may allow for alignment of the downlink traffic with the drift. In examples, the WTRU may determine to apply the offset to the start of the onDuration timer for one instance of the onDuration timer. In examples, the WTRU may determine to apply the offset to the start of the onDuration timer for multiple instances of the onDuration timer, for example, based on information on the drift (e.g., drift size and / or duration), in which case the WTRU may also send an indication to the network regarding the number of instances and / or time period to apply the offset to the onDuration timer.

[0199] In examples, the resulting action from the WTRU to change a DRX parameter(s) and / or configuration(s) may be transient, for example, based on the duration and / or expected duration of the drift. Following the (e.g, following the expected) end of the drift, the WTRU may fall back to the default DRX configuration. In examples, the resulting action from the WTRU to change a DRX parameter(s) and / or configuration(s) may be permanent (e.g, until a reconfiguration is received from the NW).

[0200] In examples, the WTRU may receive configuration information from the network based on which the WTRU may selectin a DRX configuration / parameter when receiving PDU sets multiple flows from a node. The configuration information received by the WTRU may include one or more of the following.

[0201] The configuration information received by the WTRU may include sets of possible configurations / parameters related to the DRX corresponding to the two nodes. In examples, the WTRU may receive initial and / or default set of DRX configuration / parameters for a node and one or more sets of possible parameters that may be used for adapting the timing drift between PDU sets arriving from a node. In examples, the sets of preconfigured DRX related parameters the WTRU may select from may include: drx-onDurationTimer, drx-ShortCycle, drx-SlotOffset, and / or drx-lnactivityTimer.

[0202] The configuration information received by the WTRU may include threshold values related to the time window after the reception of a PDU set from a first node during which a PDU set from a second node may be expected to be received. In examples, the WTRU may receive a threshold value, ThAB, which may be related to the duration of time spent, after receiving PDU set A from nodel , before receiving PDU set B from node2. If the duration of time spent before receiving PDU set B is long, the requirement for receiving PDU set A and PDU set B within a synchronization time window may not be met.

[0203] The configuration information received by the WTRU may include threshold values related to the remaining time, tr, in the active DRX period. In examples, after receiving PDU set A from node 1 , theWTRU (e.g., MAC layer corresponding to node 2) may start a timer to determine the remaining time left on DRX’s active period.

[0204] The WTRU may receive the configuration information, via AS layer signaling (e.g., RRC signaling / messages, MAC CE or DCI) or Non-AS (NAS) layer signaling (e.g., PDU session related messages), for example.

[0205] In examples, the WTRU may receive PDU set A from node 1 and a corresponding information which indicates that PDU set A may be regarded as a reference. The indication may inform the WTRU that the arrival time of PDU set A may be regarded as a reference based on which the synchronization time window between PDU set A from node 1 and PDU set B from node 2 can be measured and for triggering the timer which measures the remaining time left on the DRX active period. The WTRU may determine the remaining time, relative to the synchronization time window, for receiving PDU set B from node 2. In examples, the WTRU may determine the remaining time based on a timer which is triggered after receiving PDU set A. In examples, the WTRU may determine the remaining time based on a prediction of the expected arrival time of PDU set B. In examples, the WTRU may be able to predict the arrival time of PDU set 2 based on information (e.g., spatial information, pose information, temporal information), acquired from PDU set A, and the information regarding the association and / or dependency between PDU set A and PDU set B (e.g., PDUs in PDU set B may be triggered by PDUs in PDU set A).

[0206] In examples, the WTRU may determine whether to maintain the initial / default set of DRXs for a node in DC or select a DRX configuration for a nodes to align with a drift which might be occurring during reception of PDU set A and PDU set B. After PDU set A from node 1 is received by the corresponding MAC entity at the WTRU, the WTRU may determine on using a DRX configuration for the MAC entity at the WTRU connected to node 2 if PDU set B, which is dependent on PDU set A, is not received within the configured threshold, ThAB, time duration, and if the remaining time in the active time of the DRX corresponding to node 2 is below the time threshold, tr. The WTRU may select a DRX configuration for the MAC entity corresponding to node 2 to extend the WTRU’s active period for PDCCH monitoring, and so the PDU set B is received within the required synchronization time window between PDU set A and PDU set B.

[0207] In examples, the WTRU may select the DRX configuration and / or parameters to use for the MAC entity of the WTRU connected to node 2 from a set of available configurations and / or parameters which aligns the DRX active period with a measured timing drift occurring between the PDU sets arriving from node 1 and node 2. The WTRU may select the configuration and / or parameter to adjust and extend the DRX active period based on the WTRU’s prediction on the expected arrival time of PDU set B. The WTRUmay send an indication to the network (e.g., in UCI, MAC CE) regarding the selection of the new DRX configuration for node 2 and start monitoring PDCCH from node 2 using the newly configured DRX.

[0208] Features described herein may be associated with HARQ retransmission. In examples, the WTRU may determine whether and how to map / multiplex PDUs of associated PDU sets to one or more TBs and how to associate the TBs to different HARQ processes based on the sync time window threshold and the timing of the allocated resources (e.g., PUSCH occasions). The WTRU may implicitly or explicitly provide information to the NW on the sync time window / threshold and / or indication of the HARQ process IDs associated with the TBs containing PDUs from associated PDU sets. Synchronization may be maintained between PDUs sets in different flows and / or to avoid drift between the PDUs of correlated or associated PDU sets. The drift, for example, may refer to the time difference between the reception of the PDUs of different associated PDU sets in one or more flows.

[0209] An example applied by the WTRU for mappi ng / multiplexi ng the PDUs from associated PDU sets to one or more TBs and HARQ processes may include one or more of the following. The WTRU may receive configuration information from the NW that may include any of the following. The configuration information from the NW may include a set of HARQ processes and associated parameters. In examples, the WTRU may receive a first subset and a second subset of one or more HARQ processes. The first subset may be unrestricted / unconditional and / or may be used when transmitting a TB (e.g., TBs containing non-XR traffic). The second subset may be conditional and / or may be used when transmitting a bundle / multiple TBs which may be carrying the PDUs of associated PDU sets (e.g., TBs carrying inter- dependent / correlated XR traffic).

[0210] The HARQ processes, in the subsets, may be associated with one or more of the following parameters: I D / index, number of HARQ retransmissions, validity time duration for HARQ process (e.g., retransmission timer), and / or priority value. In examples, the HARQ process IDs for the first subset may have a different start offset value and / or ID range / space compared to the HARQ process IDs of the second subset.

[0211] The configuration information from the NW may include conditions for using HARQ processes (IDs) associated with the TBs carry XR traffic (e.g., PDUs of associated PDU sets). The configuration information may include one or more of the following: type of data units (e.g., PDUs / PDU sets with specific marking or indication related to dependency, synchronization, PSI HI) ; importance / priority of PDUs / PDU set (e.g., greater than a threshold value); payload sizes of inter-dependent / correlated PDUs / PDU sets (e.g., greater / less than a threshold value); priority value of the one or more LCHs configured to receive the PDUsof associated PDU sets (e.g, greater than a threshold value); QoS (e.g., PSDB, PSER) associated with inter-dependent / correlated PDUs / PDU set (e.g., greater / less than a threshold value); duration of synchronization time window between inter-dependent / correlated PDUs / PDU set (e.g., max tolerable delay difference between PDUs of two correlated PDU sets may be less than a threshold value); and / or remaining time of inter-dependent / correlated PDUs / PDU set (e.g., with respect to PSDB, and / or synchronization time window) is less than a threshold value.

[0212] The configuration information from the NW may include a resource for UL transmission. In examples, the WTRU may receive resources for UL transmission of one or more TBs. Such resources may include DG resources (e.g., single DCI or multiple DCIs scheduling multiple PUSCH occasions) or CG resources (e.g., multi-PUSCH CG configuration).

[0213] The WTRU may receive from a higher layer or application PDUs from two or more associated PDU sets, and information about the PDU sets. Such information may include any of the following: The information may include a synchronization time window / threshold (e.g., start offset value, window length / duration) corresponding to the transmission / reception of the PDUs of associated PDU sets; the information may include a synchronization threshold: a max tolerable drift value between the PDUs of associated PDU sets in one or more flows; and the information may include PDU set information including: payload size, PSDB, etc.

[0214] The WTUR may determine the mappi n g / mu Itiplexi ng of the PDUs of associated PDU sets to one or more TBs. In examples, the WTRU may perform mapping / multiplexing by using / assigning a minimum possible number of consecutive TBs to the PDUs of the associated PDU sets to allow the TBs to be within the synchronization time window / threshold during UL transmission (e.g., to avoid / minimize the drift among the TBs). Furthermore, for a small (e.g., smaller) the sync time window threshold, the PDU sets data may be assigned to TBs that are consecutive or non-spread in time / frequency (e.g., so that the TBs may experience similar channel conditions during UL transmission from the WTRU). The WTRU may take into account one or more of the following, when mapping / multiplexing the PDUs / PDU sets to TBs: PDU set payload size, PSDB, and timing of the PUSCH occasions (e.g., K2 values).

[0215] The WTRU may assign HARQ process IDs to the TBs carrying the PDUs of associated PDU sets. Such assignment may be made, for example, from the subset of HARQ processes, which may be conditional or dedicated for the TBs carrying the PDUs of associated PDU sets. In examples, the WTRU may have to create a subset of HARQ process IDs that are dedicated for associated PDU sets if the subset of HARQ process IDs is not configured by the NW. The WTRU may divide the subset of HARQ process IDsdedicated for associated PDU sets into small (e.g., smaller) groups for a group of associated PDU sets. The division may take into account choosing the HARQ process IDs such that they may be implicitly identified by the NW as associated with a bundle of TBs comprising of PDUs belonging to a group of associated PDU sets.

[0216] The WTRU may transmit an indication to the NW (e.g., in UCI, or MAC CE) including information on any of the following: HARQ process IDs of TBs carrying PDUs of associated PDU sets, IDs of TBs (e.g., flag / marking / ID in UCI multiplexed with the TB) carrying associated PDU sets, and info on the synchronization time window / threshold (e.g., index of a preconfigured window, start offset, length / duration, threshold value / index / ID). In examples, the indication may be by referring to the HARQ process ID of a reference TB (e.g., first TB) in one or more of the bundle of TBs containing PDUs from associated PDU sets. In examples, a list of HARQ process IDs may be indicated for the associated PDU sets.

[0217] The WTRU may transmit the TBs containing PDUs from two or more associated PDU sets. The WTRU may receive an indication (e.g., in DCI) from the NW, containing info on NDI flag associated with the HARQ processes and / or DG resources for retransmission of TBs. If the timing of the allocated DG resources (e.g., K2 values) for retransmission of TBs are within the sync time window / threshold, within the PSDB of the associated PDU sets, and / or within / beyond time durations of a configured timer, the WTRU may retransmit the TBs using the DG resources allocated.

[0218] In examples, the WTRU may determine whether to use CG or DG resources for the retransmission of TBs carrying PDUs of associated PDU sets based on the sync time window / threshold and the timing of configured CG PUSCH occasions and assigned DG PUSCH resources for retransmission. The WTRU may be able to determine which resources to use when performing retransmissions of the TBs based on information that may not be available to the NW, such as the sync time window / threshold, for example. In examples, the WTRU may determine whether to use CG or DG resources for retransmitting TBs where one or more of the following may be performed.

[0219] The WTRU may receive a CG configuration information from the NW (e.g., number of PUSCH occasions per slot / period, periodicity value). The WTRU may receive the CG timer values (e.g., for retransmissions) for the one or more CG PUSCH occasions. The WTRU may receive a threshold value associated with remaining time for retransmission of TBs carrying PDUs of PDU sets. The WTRU may receive from a higher layer or application, PDUs from two or more associated PDU sets and information about them that may include: a sync time window / threshold of the associated PDU sets; and / or PDU set information including: payload size, PSDB, etc.

[0220] The WTRU may transmit the TBs containing PDUs from two or more associated PDU sets using multiple CG PUSCH occasions. The transmission of TBs may be made upon assigning the TBs to the different HARQ processes.

[0221] The WTRU may receive an indication (e.g., in DCI) from the NW containing info on an NDI flag associated with the HARQ processes and / or DG resources for retransmission of TBs. If the WTRU receives, in the indication, DG resources for retransmitting at least a subset of TBs carrying PDUs of associated PDU sets, the WTRU may estimate the remaining time for successful retransmission of the TBs without incurring a drift based on the sync time window / threshold and the PSDB threshold. In examples, after the WTRU transmits TB1 and TB2 carrying data from the associated PDU sets, the WTRU may receive an indication from NW that TB1 was transmitted and that TB2 was not transmitted and is to be retransmitted (e.g, the indication from NW may not indicate that the NDI flag is reset and / or that DG is allocated for retransmission). In examples, the WTRU may estimate the remaining time for retransmission by considering the minimum of the sync time window / threshold (e.g, to avoid incurring a drift) and the time remaining until PSDB expires (e.g, to avoid not meeting the PSDB requirements) upon the reception of the NW indication.

[0222] The WTRU may determine whether the timing of the DG resources allocated for retransmission (e.g, via K2 value) may be used to meet the synchronization threshold and / or PSDB threshold requirements. If the remaining time for retransmission without incurring a drift is not greater than the remaining time until the allocated DG resources are available for retransmission by a configured threshold value, the WTRU may determine whether the next available CG resources may be used to meet the synchronization threshold and / or PSDB threshold requirement based on the estimated remaining time for successful retransmission and the timing of the next available CG occasion.

[0223] If the remaining time for successful retransmission without incurring a drift is greater than the remaining time until the next available CG resources by a configured threshold value, the WTRU may use the nearest available CG resources for retransmitting the TBs. The WTRU may send an indication (e.g, in UCI) on usage of CG resources for retransmitting the TBs. In examples, the WTRU may indicate in the CG resources that the TBs included are retransmissions via the HARQ process IDs and / or NDI flag info (e.g, in UCI).

[0224] Systems, methods, and instrumentalities may be configured for achieving synchronization between dependent Protocol Data Unit (PDU) sets at access Stratum (AS) layers. A Wireless Transmit / Receive Unit (WTRU) may receive, from a network node, configuration information relating toLogical Channels (LCHs). The configuration information may indicate a priority, a Logical Channel Procedure (LCP) restriction, a max duration, and / or a drift threshold. The WTRU may receive an indication of Protocol Data Unit (PDU) sets. The PDU sets may include a first flow and a second flow. The WTRU may determine a drift size and / or a drift duration based on a comparison of a periodicity of a flow against an arrival time of a PDU set. If a drift is larger than the drift threshold, the WTRU may determine / apply an adaptive LCP restriction by prioritizing an LCH associated with data of a correlated flow.

[0225] The adaptive LCP restriction may be applied for a determined time, and the WTRU may be configured to send, to the network node, an indication of the determined time. The indication sent to the network node may include an indication of an impacted LCH. The impacted LCH may include the prioritized LCH.

[0226] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMSWhat is claimed is:1 . A Wireless Transmit / Receive Unit (WTRU) comprising: a processor configured to: receive, from a network node, configuration information, wherein the configuration information indicates one or more of: a logical channel prioritization (LCP) action, a maximum duration, a drift size threshold, or a drift duration threshold; receive an indication, wherein the received indication indicates: a first Protocol Data Unit (PDU) set associated with a first flow, a second PDU set associated with a second flow, and a dependency between the first flow and the second flow; determine one or more of a drift size or a drift duration based on a periodicity of the first flow and an arrival time of the first PDU set; and based on the dependency and that the drift size is larger than the drift size threshold or the drift duration is larger than the drift duration threshold: apply the LCP action.

2. The WTRU of claim 1 , wherein the received indication indicates a third flow, wherein the first flow is associated with a first logical channel (LCH), the second flow is associated with a second LCH, and the third flow is associated with a third LCH, wherein a priority associated with the third LCH is higher than a priority associated with the second LCH, and wherein the application of the LCP action prioritizes the second LCH over the third LCH.

3. The WTRU of claim 1 , wherein the processor is further configured to: determine a time associated with the application of the LCP action; and send, to the network node, an indication of the determined time.

4. The WTRU of claim 3, wherein the determined time is determined based on one or more of the drift size, a PDU set size associated with the PDU set, a PDU set delay bound (PSDB) associated with the PDU set, a number of PDUs in the PDU set, or an amount of data in a buffer of the WTRU.

5. The WTRU of claim 3, wherein the indication sent to the network node further comprises an indication of an impacted LCH, and wherein the impacted LCH is impacted based on a priority of afirst or second LCH changing for a time period, and wherein the time period is a function of the drift duration.

6. The WTRU of claim 1 , wherein the dependency associated with the first flow and the second flow indicates that data associated with the first flow is not to be processed unless data associated with the second flow is received.

7. The WTRU of claim 1 , wherein the LCP action comprises one or more of an LCP configuration or an LCP restriction.

8. The WTRU of claim 1 , wherein the drift size comprises a time difference between the second flow being received and the first flow being received, and wherein the drift duration comprises a time period during which data packets associated with the second flow arrive after a drift associated with the second flow begins.

9. The WTRU of claim 1 , wherein the LCP action is applied on one or more of the first flow, the second flow, or an additional flow.

10. A method for a Wireless T ransmit / Receive Unit (WTRU) comprising: receiving, from a network node, configuration information, wherein the configuration information indicates one or more of: a logical channel prioritization (LCP) action, a maximum duration, a drift size threshold, or a drift duration threshold; receiving an indication, wherein the received indication indicates: a first Protocol Data Unit (PDU) set associated with a first flow, a second PDU set associated with a second flow, and a dependency between the first flow and the second flow; determining one or more of a drift size or a drift duration based on a periodicity of the first flow and an arrival time of the first PDU set; and based on the dependency and that the drift size is larger than the drift size threshold or the drift duration is larger than the drift duration threshold: applying the LCP action.11 . The method of claim 10, wherein the received indication indicates a third flow, the first flow is associated with a first logical channel (LCH), the second flow is associated with a second LCH, andthe third flow is associated with a third LCH, wherein a priority associated with the third LCH is higher than a priority associated with the second LCH, and wherein the application of the LCP action prioritizes the second LCH over the third LCH.

12. The method of claim 10, wherein the method further comprises: determining a time associated with the application of the LCP action; and sending, to the network node, an indication of the determined time.

13. The WTRU of claim 12, wherein the determined time is determined based on one or more of the drift size, a PDU set size associated with the PDU set, a PDU set delay bound (PSDB) associated with the PDU set, a number of PDUs in the PDU set, or an amount of data in a buffer of the WTRU.

14. The WTRU of claim 12, wherein the indication sent to the network node further comprises an indication of an impacted LCH, and wherein the impacted LCH is impacted based on a priority of a first or second LCH changing for a time period, and wherein the time period is a function of the drift duration.

15. The WTRU of claim 10, wherein the dependency associated with the first flow and the second flow indicates that data associated with the first flow is not to be processed unless data associated with the second flow is received.

Images