Layer 2 processing in wireless systems

Abstract

A wireless transmit / receive unit WTRU may be configured with one or more data scheduling units (DSUs). A DSU may be configured with a DSU type. A DSU type may be associated with a priority. A WTRU may apply a priority between DSUs of the same type and / or across DSUs of different types. A WTRU may consider DSU type of when determining priority between two or more DSUs. A DSU may be used to transmit data. A DSU may be associated with a transmission status. WTRU may transmit information regarding one or more DSUs to a network node in a buffer status report.

Description

LAYER 2 PROCESSING IN WIRELESS SYSTEMSCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 617,998, filed January 5, 2024, the entire contents of which are hereby incorporated by reference as if fully set forth.BACKGROUND

[0002] Immersivity can be conceptualized broadly as the combination of video and interactivity at various levels of realism. Immersive services include extended Reality (XR)-based applications which in turn comprise varying levels of combinations between real and / or virtual elements from Mixed Reality (MR) focusing on Augmented Reality (AR) and / or Augmented Virtuality (AV) up to entirely Virtual Reality (VR) applications.

[0003] Immersive applications may be characterized by high data rates, for example, for support of immersive / 360-degree 2D / 3D video (e.g., high efficiency video coding (HEVC), Multiview (MV) -HEVC, moving picture experts’ group (MPEG) versatile video coding (WC), video point cloud coding (VPCC), MPEG immersive video (MiV), etc.). Immersive applications may also involve audio streaming, low latency for supporting conversational, and / or user interactivity requirements (e.g., to support viewport-dependent streaming and / or haptics functions as well as bounded jitter and transport delays to keep application data and control within the synchronization requirements of the various bitstreams).

[0004] Failure to meet the end-to-end quality of service (QoS) requirements for such a service, or for one of more of its bitstream(s), may lead to degradation of overall quality of experience (QoE) for the user. Contrary to best effort data transfers (e.g., web browsing, streaming applications such as video, real-time interactive audio applications such as voice over internet protocol (Vol P), or combinations of the above such as video-based conferencing) where degradation of the QoS leads to perceptual annoyances that only impact a user’s satisfaction, degradation of the QoE for immersive applications where the human sensory system is more involved can additionally lead to user fatigue, motion sickness and other discomfort (both physical and psychological). Discomfort, which has a higher dependency on individual user’s sensitivity than non-immersive services, may cause a service or a device (e.g., a head mounted display) to become commercially unappealing or even practically unusable.SUMMARY

[0005] A layer 2 protocol stack can support data transfers for data.

[0006] A service and / or a session may include a number of separate bitstreams with various QoS requirements that combine together to create the overall QoE of the application. Adaptation and / or impairments to a given bitstreams may impact overall QoE differently.

[0007] A bitstream may include a number of flows and / or packets with various QoS requirements that create the QoE for a given aspect of the application (e.g., the quality of rendering, composition, complexity of the experience). Adaptation and / or impairments to a given packet, packet flow may impact overall QoE differently.

[0008] Application-level QoE may be considered elastic. For example, a baseline end-user experience can be met at different bitrate targets possibly characterized by high dynamicity and larger variance in bitrate, where a suitable compound bitrate may be further characterized by discrete steps.

[0009] Per-PDU treatment, processing and QoS differentiation can be relational to other PDUs. A flexible data transfer framework can dynamically support QoS adaptation as a function of the systems / application target QoE operating point using Data Scheduling Units (DSUs) with one or more characteristics as discussed herein.

[0010] A wireless transmit / receive unit (WTRU) may receive configuration information that indicates a set of QoS parameters associated with a DSU. DSUs may be parametrized, configurable (e.g., using configuration information) and / or may assigned to a QoS type (e.g., best-effort service, real-time services, immersive services, sensory data, and / or control signaling). A set of QoS parameters associated with a DSU parameters may be dynamically (e.g., for a period of time) modified (e.g., by a change of per DSU QoS parameters set assigned to a given target QoE-level). DSU depth (e.g., in terms of PDU units), PDU sizes (e.g., in terms of bytes), bitrates and latency bound may be related to WTRU capabilities. The WTRU may determine that one or more PDUs are associated with a DSU based on QoS parameters of the PDUs and / or DSU. The WTRU may transmit one or more PDUs associated with the DSU in accordance with the DSU.

[0011] Inter-DSU and / or intra-DSU dependencies may be configured for time, bitrate, and / or data transfer success criteria. Intra-DSU dependency may be similar to intra-flow and / or inter-packet dependencies. For example, dependencies may exist between different (possibly encoded in the packet / PDU) packets of the same media (e.g., different packets of the same video frame, different frames of the same video stream, different enhancement layers of the same media stream). Inter-DSU dependency may be similar to interflow and / or inter-media dependency (e.g., dependencies between bitstreams of different media types, suchas video, audio, haptics, sensory, etc.). The framework may support and / or enable probing of link capacity, up / downwards bitrate adaptations and / or application awareness.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0014] FIG. 1C 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.

[0015] 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.

[0016] FIG. 2 is a diagram illustrating a generalized model of data scheduling units (DSUs).

[0017] FIG. 3 is a diagram showing an exemplary procedure for considering time remaining during logical channel prioritization (LCP).DETAILED DESCRIPTION

[0018] 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. For example, 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.

[0019] 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 CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosedembodiments 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 WTRU.

[0020] 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 I nternet 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.

[0021] 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 over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one 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. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0022] 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).

[0023] 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. For example, 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).

[0024] I n 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).

[0025] I n 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).

[0026] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, 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).

[0027] 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 forMobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0028] 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.

[0029] 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. For example, 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.

[0030] 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 wiredand / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0031] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with 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.

[0032] FIG. 1 B 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.

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

[0034] 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. For example, 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 willbe appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0035] 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.

[0036] 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 IEEE 802.11 , for example.

[0037] 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 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. 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).

[0038] 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. For example, 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.

[0039] 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 locationinformation 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.

[0040] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an 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.

[0041] 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 an interference management unit 139 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). 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)).

[0042] FIG. 1C 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.

[0043] 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 implementMIMO 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.

[0044] 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 DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0045] 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.

[0046] 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. For example, 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.

[0047] 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.

[0048] 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.

[0049] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or 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.

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

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

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

[0053] 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 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.

[0054] 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.

[0055] 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).

[0056] 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.11 ac. 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).

[0057] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by one or more (e.g., all) STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among one or more (e.g., 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 theprimary 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.

[0058] 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.

[0059] 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.

[0060] 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. For example, 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, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on 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. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

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

[0062] 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. For example, 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.

[0063] 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. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0064] 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.

[0065] 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. For example, 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 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. For example, differentnetwork 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.

[0066] 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.

[0067] 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.

[0068] The CN 115 may facilitate communications with other networks. For example, 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.

[0069] 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-ab, 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 ormore, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0070] 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. For example, 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.

[0071] 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. For example, 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.

[0072] QoS handling in radio access may be based on logical pipes, where packets associated to a given pipe are treated in the same manner in terms of QoS functions, priorities, delays, and target bitrates for that pipe (e.g., data radio bearers (DRBs)).

[0073] Additionally, or alternatively, basic application-related dependencies may be introduced from the perspective of data units that may be part of a larger application-level data unit, for example, to further optimize the use of radio resources using assumptions related to various traffic patterns. In an example, data may be transported as different IP packets, where each packet carries information related to the same video frame. The determination of what PDUs may be associated to a given PDU set may be left to terminal implementation.

[0074] For a given data radio bearer, the WTRU may use associations between different packet data units (PDUs) to treat one or more PDU as an extended data unit (e.g., selectively dropping all unacknowledged PDUs within a set if at least one PDU in that set cannot be successfully transmitted within the constraints of the radio bearer it is assigned to). For example, conditions for selectively discarding PDUs in a PDU setthat have not yet been transmitted may include bearer specific service data unit (SDU) discard timer expires and / or if hybrid automatic repeat request (HARQ) is unsuccessful for such PDU in the set.

[0075] Such mechanisms are thus focusing on optimizing the usage of radio resources, in addition to providing the baseline QoS service of the associated DRB. Such optimization is driven by the awareness of whether the usefulness of the transmission of a PDU that may depend on the success of the transmission of another PDU with a given data radio bearer (e.g., within the same logical QoS handling).

[0076] QoS Class Identifier (QCI) may be defined as an index into a table of standardized values for the Packet Delay Budget (PDB), the Packet Loss Error Rate (PLER) and / or a Priority of a given flow, where a flow is associated to a service. For example, some QCI values are best suited for guaranteed bit rate (GBR) services such as conversational voice, video, streaming or real-time gaming whereas other values are for non-GBR services such as best-effort TCP-based services or audio / video with support for buffering of data.

[0077] The QCI framework may be extended to the 5G QoS Identifier (5QI) framework, adding multiple additional combination of values for the QCI parameters as well as adding a few parameters such as “default averaging window”, “default maximum data burst volume” for GBR and non-GBR services as well as for delay-critical GBR. PLER is also renamed to Packet Error Rate (PER).

[0078] NR additionally defines QoS parameters for Allocation and Retention Priority (ARP), Reflective QoS Attribute (RQA), notification control, flow bit rates (e.g., Guaranteed Flow Bit Rate (GFBR) and Maximum Flow Bit Rate (MFBR)), Aggregate Bit Rates per session maximum (Session-AMBR) or per WTRU maximum (UE-AMBR) as well as Maximum Packet Loss Rate (MPLR).

[0079] The QoS parametrization is based on the following principles: (1) Admission control in core network and setup for a new session, service and flows defines an upper bound in terms of data rates; (2) Admission control in the radio access relies on the parametrization determined for the service to guarantee QoS levels; (3) Scheduling in the radio access considers that there are either sufficient radio resources to serve the agreed upon QoS and / or time can be an “elastic” resource otherwise. Alternatively, data can be dropped (e.g., upon expiration of SDU discard timer).

[0080] Delay-sensitive applications are assumed to not exceed their QoS requirements, to not significantly deviate (or have means to significantly deviate) from their target jitter, latency, and bitrate requirements, to adjust their bitrate in an end-to-end manner and / or to perform error concealment when packets are missing (e.g., lost or not received in time).

[0081] The concept of a PDU set has been introduced where a PDU Set is composed of one or more PDUs carrying the payload of one unit of information generated at the application level (e.g., a frame or video slice for XRM Services). In some examples, all PDUs in a PDU Set are needed by the application layer to use the corresponding unit of information. In other implementations, the application layer can still recover parts (e.g., all or some) of the information unit, when some PDUs are missing. For the uplink, the identification of PDU sets, data bursts and PSI is left to WTRU implementation.

[0082] For a PDU Set in a QoS flow for which the PDU set Integral handling indication (PSI H I) is set, when one PDU of that PDU set is known to either be lost or associated to a discarded SDU, all remaining PDUs of that PDU Set could be discarded at the transmitter to free up radio resources.

[0083] The PDU Set Delay Budget (PSDB) may be defined as the time between reception of the first PDU (at the user plane function (UPF) in downlink (DL), at the WTRU in uplink (UL)) and the successful delivery of the last arrived PDU of a PDU Set / ePDU set (at the WTRU in DL, at the UPF in UL). The PSDB is an optional parameter and when provided, the PSDB may supersede the PDB.

[0084] The semantics of the fields of the real-time transport protocol (RTP) Header Extension for the marking of PDU Set and End of Bursts in the downlink may be defined as follows. The End PDU of the PDU Set [E] (1 bit) may be a flag that shall be set to 1 for the last PDU of the PDU Set and set to 0 for all other PDUs of the PDU Set. The End of Data Burst [EDB] (3 bits) field may be 3 bits in length. The EDB may indicate the end of a Data Burst. The 3 bits encode the End of Data Burst indication. The PDU Set Importance [PSI] (4 bits) field may indicate the importance of this PDU Set compared to other PDU Sets within the same QoS flow. Lower values may indicate a higher importance PDU Set, with the highest importance PDU Set indicated by 0 and the lowest importance PDU Set indicated by 15. The PDU Set Sequence Number [PSSN] (10 bits) field may encode the sequence number of the PDU Set to which the current PDU belongs acting as a 10-bit numerical identifier for the PDU Set. The PDU Sequence Number within a PDU Set [PSN] (6 bits) field may indicate the sequence number of the current PDU within the PDU Set. The PSN may be set to 0 for the first PDU in the PDU Set and incremented monotonically for every PDU in the PDU set in order of transmission from the sender. The PDU Set Size [PSSize] (24 bits) may indicate the total size of all PDUs of the PDU Set to which this PDU belongs. The PSSize field may be optional and / or subject to an SDP signaling offer / answer negotiation, where the Application Server may indicate whether it will be able to provide the size of the PDU Set for that RTP stream. If the PSSize field is not enabled, the field may not be present. If the PSSize field is enabled, but the Application Server is not able to determine the PDU Size for a particular PDU Set, the Application Server may set the value to 0 inall PDUs of that PDU Set. The PSSize may indicate the size of a PDU Set including RTP / UDP / IP header encapsulation overhead of its corresponding PDUs. The PSSize may be expressed in bytes.

[0085] The layer 2 protocol stack may support priorities between data pipes (e.g., radio bearers) while meeting data rates. The system may also support other verticals and services requiring various enhancements based on the old protocol stack.

[0086] The layer 2 protocol stack may include support for one or more of the following: scheduling data with “no later than” guarantees (e.g., latency bound data transmissions) including meeting sensory, immersive QoE requirements, and / or high bitrates / guaranteed bit rates. Support for scheduling around both target bitrates and maximum data burst volume (MDBV) may be provided. If a logical pipe is served with resources allocated based on average data rates, there may be no guarantee that excess data from data bursts can be served for a given WTRU. If a logical pipe is served with resources allocated based on maximum data volume peak rate, more radio resources may be assigned to a given WTRU unnecessarily, reducing system capacity. Security may be implemented more flexibly, including per-PDU or on a subset of a PDU up to a given amount. Support for forward error correction (FEC) and / or other network-level coding method may be provided, for example, to manage tradeoffs between reliability of the data transfer and the latency requirements. Additionally, or alternatively, support for generic, flexible data transfer plane may be provided (e.g., processing between different data types (e.g., user plane, control plane, octet strings, others) can be harmonized).

[0087] A layer 2 protocol stack may support data transfers for data.

[0088] A service and / or a session may include a number of separate bitstreams with various QoS requirements that combine together to create the overall QoE of the application. Adaptation and / or impairments to a given bitstream may impact overall QoE differently.

[0089] A bitstream may include a number of flows and / or packets with various QoS requirements that create the QoE for a given aspect of the application (e.g., the quality of rendering, composition, complexity of the experience). Adaptation and / or impairments to a given packet, packet flow may impact overall QoE differently.

[0090] Application-level QoE may be considered elastic. For example, a baseline end-user experience may be met at different bitrate targets, for example, possibly characterized by high dynamicity and larger variance in bitrate. A suitable compound bitrate may be further characterized by discrete steps.

[0091] Per-PDU treatment, processing, and QoS differentiation may be related to other PDUs. A flexible data transfer framework may support (e.g., dynamically support) QoS adaptation as a function of thesystems / application target QoE operating point using Data Scheduling Units (DSU) with one or more characteristics as discussed herein.

[0092] DSUs may be parametrized, configurable (e.g., using configuration information), and / or assigned to a QoS type (e.g., best-effort service, real-time services, immersive services, sensory data, and / or control signaling). DSU QoS parameters (e.g., a set of QoS parameters associated with a DSU) may be dynamically modified (e.g., by a change of per DSU QoS parameters set assigned to a given target QoE- level). DSU depth (e.g., in terms of PDU units), PDU sizes (e.g., in terms of bytes), bitrates, and / or latency bound may be related to WTRU capabilities. Inter-DSU and / or intra-DSU dependencies may be configured for time, bitrate, and / or data transfer success criteria. Intra-DSU dependency may be similar to intra-flow and / or inter-packet dependencies (e.g., dependencies between different (possibly encoded in the packet / PDU) packets of the same media). Different packets of the same media may include different packets of the same video frame, different frames of the same video stream, and / or different enhancement layers of the same media stream. Inter-DSU dependency may be similar to inter-flow and / or inter-media dependency (e.g., dependencies between bitstreams of different media types). Different media types may include video, audio, haptics, sensory, etc. The framework may support and / or enable probing of link capacity, upward bitrate adaptation, downward bitrate adaptations, and / or application awareness.

[0093] The WTRU may be configured (e.g., via configuration information) with one or more Data Scheduling Units (DSUs). FIG. 2 shows a generalized model of a DSU for a data plane.

[0094] The WTRU may be configured with one or more DSU types. A DSU may be of a certain type, where such type may correspond to a specific configuration. Such configuration may comprise one or more parameters (e.g., QoS and / or QoE related parameters). For example, a DSU type may be configured for handling best-effort traffic, conversational / streaming traffic, and / or conversational immersive traffic with or without QoE elasticity (e.g., ability to mitigate loss of data and / or delay). A DSU type may be associated with an index (e.g., DSU0 may correspond to a first configuration, DSU1 may correspond to a second configuration, and DSUn may correspond to an nth configuration of the WTRU).

[0095] The WTRU may be configured with one or more extended PDU sets (ePDUs). The WTRU may be configured such that an ePDU is associated with at least QoS, QoE related parameters. An ePDU may represent a sequence of SDUs (e.g., one or more IP packets, service data application protocol (SDAP) PDUs, packet data convergence protocol (PDCP) PDUs and / or radio link control (RLC) PDUs). The WTRU may be configured such that a DSU type may include one or more ePDUs. Each PDU of an ePDU may be indexed according to its association to the ePDU and / or its sequence in the ePDU e.g., PDU0,0 mayrepresent the first PDU of the first ePDU of a DSU or, more generally PDUx,y may represent the yth PDU of the xth ePDU of a DSU.

[0096] The WTRU may be configured for a given DSU, DSU type, DSU instance and / or ePDU with at least one of the following parameters or values.

[0097] The WTRU may be configured with an Index (ID). The index may comprise the indexing information of the DSU for the data plane of the WTRU. The index may be similar to a sequence number and / or may be a of specific number of bits. The index may be a configuration aspect of the data plane that may represent the maximum number of DSU instances at any given time.

[0098] The DSU ID space, or the IDs maximum value, may be configured by RRC. The DSU ID space may be of a short (e.g., 8 bits) or long (e.g., 16 bits) format. The maximum value may be upper bounded by the WTRUs reported capabilities (e.g., one of the parameters that may indicate the maximum size of the WTRU data buffers). Shorter values of the maximum ID value may correspond to the maximum amount of data that may be undergoing transmission at any time. Longer values of the maximum ID may be preferable, for example, if the ID is used for security processing.

[0099] The index may continuously be incremented across various instances of the same DSU type. The DSU ID may be used for sequencing e.g., for security (integrity protection, ciphering) for example as part of larger sequencing information using concatenation with other sequencing elements described herein.

[0100] The WTRU may be configured with a QoE level parameter. The QoE level parameter may indicate the applicable set of QoS parameters applicable at a given time. The QoE-level may be per DSU type, (e.g., for a plurality of flows associated to the same QoE). The WTRU may be configured with one or more sets of QoS-related parameters, as described herein. Each set may be associated with a QoE level.

[0101] The WTRU may dynamically determine the applicable QoE-level from the reception of explicit signaling (e.g., physical downlink control channel (PDCCH), medium access control (MAC) control element (CE), and / or radio resource control (RRC)) and / or autonomously using specified logic (e.g., according to one or more of the embodiments discussed herein).

[0102] The WTRU may apply a lower QoE level if makes a determination as discussed herein. The WTRU may apply a lower QoE level, for example, if the WTRU determines that the transmission status for a DSU is set to “failed.” Some form of filtering may be applied (e.g., for a single DSU, for n1 out of n2 DSUs, and / or possibly within a specific amount of time or within a window of operation). Number of failed DSU and evaluation timing may be a configuration aspect of the WTRU (e.g., only for ePDUs of a DSUType that are within the applicable QoE level). For example, the WTRU may evaluate the status of ePDUO for a DSU type when QoS profile 0 is active and evaluate the status of ePDUO and ePDU1 for a DSU type when QoS profile 1 is active. The WTRU may evaluate the status of one or more (e.g., all) PDUs for ePDUx-1 and below with the status of ePDUx for a DSU type when QoS profile X is active.

[0103] The WTRU may apply a lower QoE level if the WTRU determines that the amount of available transmissions resources is decreasing (e.g., the WTRU is reconfigured with fewer carriers, is reconfigured to another cell (e.g., mobility even), is reconfigured with smaller bandwidth operation, uplink link adaptation parameters indicate less spectral efficient scheduling, HARQ retransmissions and operating point increases, reconfiguration and / or deactivation of configured grants that removes available resources, and / or etc.). The WTRU may be configured with radio resources profiles associated with a QoS profile. The WTRU may change its QoE level according to the determination of a change in radio configuration.

[0104] In examples, the WTRU may no longer consider data for a QoE-level higher than the determined applicable level as data available for transmission (e.g., when the WTRU determines that the criteria for applying a lower QoE level is satisfied) and report the new data amounts in a buffer status report (BSR)).

[0105] In examples, the WTRU may trigger a BSR, and / or a scheduling request (SR), when it determines that the criteria for applying a lower QoE level is satisfied and report it in a BSR.

[0106] The WTRU may apply a higher QoE level if the WTRU determines that the transmission status for a DSU is set to “complete” and / or “successful.” Some form of filtering may be applied (e.g., for a single DSU, for n1 out of n2 DSUs, and / or possibly within a specific amount of time or within a window of operation). The number of successful and / or completed DSUs and evaluation timing may be a configuration aspect of the WTRU. In examples, the WTRU may determine that the transmission status is set to “complete” or “successful” if (e.g., only if) there are ePDUs of a DSU Type that are outside the applicable QoE level. In examples, the WTRU may determine that the transmission status is set to “complete” or “successful” by evaluating (e.g., only by evaluating) the status of ePDUx+1 and above for a DSU type when QoS profile X is active.

[0107] In examples, the WTRU may start considering that data is available for transmission for the higher QoE-level when the WTRU determines that the criteria for applying a higher QoE level is satisfied. The WTRU may report that data is available for transmission for the higher QOE-level, for example, in a BSR.

[0108] In examples, the WTRU may trigger a BSR, and / or a SR, for example, when the WTRU determines that the criteria for applying a higher QoE level is satisfied. The WTRU may report that the criteria for applying a higher QoE level is satisfied in a BSR.

[0109] QoS-related parameters and / or parameter set(s) may correspond to QCIs, 5Qls, and / or equivalents. The WTRU may be configured with one or more of the parameters discussed herein.

[0110] The WTRU may be configured with a Prioritized bit rate (PBR) parameter. In examples, the WTRU may be configured with an amount of data to prioritize within a given period of time to achieve the target bit rate of the application.

[0111] The WTRU may be configured with a Guaranteed Bit Rate (GBR) parameter. In examples, the WTRU may be configured with a guaranteed amount of data to prioritize within a given period of time to achieve the guaranteed, possibly minimal, bit rate of the application.

[0112] The WTRU may be configured with a Latency Bound Bitrate (LBB) parameter. In examples, the WTRU may be configured with an amount of data to give absolute priority for a given period of time to meet the latency requirement of the application and possibly up to at least a target bit rate in combination.

[0113] The WTRU may be configured with a Maximum Data Burst Volume (MDBV) parameter. In examples, the WTRU may be configured with a maximum amount of data that may be transmitted within a given period of time (e.g., in excess of the PBR, GBR and / or LBB).

[0114] The WTRU may be configured with a maximum amount of time until successful transmission (MTST) parameter. The MTST may represent the time from which the data becomes available for transmission, the time there is a first data unit available for transmission for an ePDU, and / or for a DSU where the status of the transmission should be “successful” or “completed” before the MTST is exceeded.

[0115] The WTRU may be configured with a scheduling period parameter. The scheduling period may be expressed in units of time (e.g., milliseconds (ms)) or in units of physical layer intervals (e.g., orthogonal frequency domain multiplexing (OFDM) symbol, subslot, slot, TTI) and / or subframe (e.g., according to the numerology configuration of the resources applicable). For example, QoS, QoE, and DSU configuration may be per MAC instance of the WTRU configuration, and numerology of the radio resources may be common for a given MAC instance.

[0116] The WTRU may be configured with a Start / Start Offset parameter comprising a recurring time boundary. This boundary may be based on physical layer timing. This boundary may be recurring in time, to create logical time intervals that may be periodically recurring. Such timing may be a function of physical layer timing (e.g., single frequency network (SFN)-based, symbol / slot or subslots based). Using physical layer timing enables the gNB and the WTRU to identify the same scheduling periods.

[0117] In examples, the gNB may derive from the timing of the reception of a SR in combination with information in the buffer status report (BSR) the scheduling periods of the WTRU’s configuration for whichthe reported data must be transmitted to support the proper QoE level of the WTRUs application. The WTRU may report data amounts per DSU, per ePDU, and / or per scheduling period in the BSR.

[0118] The WTRU may apply a priority between DSUs of the same type and / or across DSUs of different types. How to apply priority may be a configuration aspect of the DSU type or of a given DSU instance. The WTRU may be configured with a priority, Pn, as described herein.

[0119] In examples, Pn may be applied to the DSU Type. The WTRU’s transmit, receive and / or other processing functions may apply priority per DSU type (e.g., the WTRU may consider the data associated to each ePDU of the same DSU type to be of equal priority).

[0120] In examples, Pn may be applied to a DSU instance. The WTRU’s transmit, receive and / or other processing functions may apply priority per DSU instance (e.g., the WTRU may consider the data associated to each ePDU of the same DSU instance to be of equal priority. Such priority may differ between DSUs of the same or different type).

[0121] In examples, Pn may be applied to an ePDU of a DSU Type. The WTRU’s transmit, receive and / or other processing functions may apply priority per ePDU for a given DSU Type (e.g., the WTRU may consider the data associated to each PDU of the same ePDU to be of equal priority for a given DSU type). Such priority may differ between ePDUs of the same or different DSU types.

[0122] In examples, Pn may be applied to an ePDU of a DSU instance. The WTRU’s transmit, receive, and / or other processing functions may apply priority per ePDU for a given DSU instance (e.g., the WTRU may consider the data associated to each PDU of the same ePDU to be of equal priority for a given DSU instance). Such priority may differ between ePDUs of the same of different DSU instances.

[0123] The WTRU may determine such priority dynamically, (e.g., as a function of time and / or as a function of application-level awareness) and / or based on WTRU implementation.

[0124] The WTRU may use such priority in other functions related to QoS such as SR, BSR, and / or logical channel priority (LCP).

[0125] In some applications, data of a first application type may be useful if (e.g., only if) data of a second type is also successfully received (e.g., some of the data available for transmission may be dependent on the successful transmission of other data).

[0126] The WTRU may be configured with one or more dependencies applied between two or more DSUs instances (e.g., DSUs of the same or of different types, and / or between ePDUs of the same and / or different DSU instances).

[0127] The WTRU may apply a dependency between DSUs of the same type and / or across DSUs of different types. The WTRU may perform a given function (e.g., multiplexing data in a transport block, reporting data available for transmission or the like, using relationship and / or dependencies between a plurality of DSUs).

[0128] The WTRU may determine how to process data associated with a given ePDU for a given scheduling period by evaluating one or more conditions associated with a second ePDU. The WTRU may apply a first processing if the condition is not met and may apply a second processing otherwise. In examples, PDUs of a first DSU may be considered for transmission if a condition associated to a second DSU is first satisfied (e.g., the first DSU is considered successfully “served”).

[0129] In examples, the WTRU may determine the PBR for data of a first DSU or ePDU as a function of the transmission status of a second DSU or ePDU. For example, the WTRU may determine that data of a first ePDU may be available for transmission and / or for multiplexing in a transport block if data of a second ePDU - which may be of a higher priority - has been served up to its target PBR and / or if specific transmission conditions have been met. For example, the WTRU may determine that data of a first ePDU is available for transmission if at least a certain amount of data from the ePDU has been multiplexed in a transport block (TB)), an amount of data is included in an initial hybrid automatic repeat request (HARQ) transmission, and / or the amount of data has been successfully transmitted (e.g., based on HARQ feedback, RLC acknowledgement or similar).

[0130] In examples, the WTRU may determine that the PBR for the first ePDU is 0 for a given period if or when the conditions associated with the dependency with a second ePDU have not been met (e.g., the WTRU cannot multiplex data from the first DSU in a TB before such condition is met and / or before the next period).

[0131] In examples, the WTRU may serve data associated to a first DSU for a given scheduling period if data from a second DSU has been served up to the second DSU’s PBR and / or if the DSU has been served successfully (e.g., if a sufficient amount of data from the DSU has been positively acknowledged).

[0132] In examples, the WTRU may determine the priority of data associated to a first ePDU as a function of the transmission status (e.g., PBR, delay, time in buffer, priority, outcome of the transmission of data for the second DSU, etc.) of a second DSU. Similar to the dynamic determination of the PBR described above, a first ePDU may be dynamically assigned a lower priority for a given period if or when the conditions associated with the dependency with a second ePDU have not been met (e.g., the WTRU maytreat the associated data according to a lower priority level until such condition is met and / or before the next period).

[0133] A DSU may be served when another DSU has been served up to a certain condition (e.g., if a certain condition is met). In examples, said certain condition may be met if x out of y PDUs of the other DSU have been successfully transmitted, where the number x may be based on the media type and / or the coding characteristics.

[0134] The DSU may be associated with one or more criteria that determine the status of the DSU. In examples, the status of an DSU may be according to any of the embodiments discussed herein.

[0135] The status of the transmission of a DSU may be set to “failed” if there is still data available for transmission (or expected to become available) but at least one or more of the QoS requirements for the DSU and / or one or more of the QoS requirements of the constituent data units as part of the DSU (e.g., QoS requirements of constituent PDU(s), PDU set(s), ePDU set(s), etc.) have not been met within the required time (e.g., only if there is no such data that is not ongoing transmission). In examples, the status may be set to “failed” for a given DSU if (e.g., only if) it has not previously been set to “successful” or “completed.” In examples, the status may be set to “failed” for a given DSU if the time / latency bound associated with the DSU has been reached. In examples, the status may be set to “failed” for a given DSU if the time / latency bound associated with the DSU is within a preconfigured window of being exceeded. In examples, the status may be set to “failed” for a given DSU if the time / latency bound associated with any constituent data unit of the DSU (e.g., PDB of one or more PDUs of the DSU, PSDB of one more ePDU sets of the DSU, etc.) has been exceeded. In examples, the status may be set to “failed” for a given DSU if the time / latency bound associated with any constituent data unit of the ePDU set (e.g., PDB of one or more PDUs of the ePDU set, PSDB of one or more ePDU sets of the DSU, etc.) is within a window of being exceeded. In examples, the status may be set to “failed” for a given DSU if a certain number of constituent data units of the ePDU set have not met their respective QoS requirements (e.g., a number > N, where N > 1 , of PDUs within the ePDU set were not transmitted within their respective PDB, or a number > M, where M > 1 , of ePDU sets within the DSU were not transmitted within their respective PSDB, etc.). Additionally, or alternatively, in examples, the status may be set to “failed” for a given DSU if another criterion with higher priority has first been reached (e.g., if another DSU with higher priority was prioritized over this DSU for multiplexing into a transport block).

[0136] The status of the DSU transmission may be set to “pending” if there is still data available for transmission (or expected to become available) within the QoS requirement of the DSU instance (e.g.,within the delay bound, within the PBR, etc.). In examples, the status of the DSU transmission may be “pending” if not set to one of: “PBR satisfied,” “Delay satisfied,” “successful,” or “completed.”

[0137] The status of the DSU transmission may be set to “PBR satisfied.” The WTRU may determine that the PBR of the DSU has been satisfied. For example, the WTRU may determine that the PBR for the DSU is satisfied if one or more (e.g., all) the ePDUs of the DSU have their respective PBR satisfied. The WTRU may determine these criteria using ePDUs (e.g., only ePDUs) that are within the current QoE-level of the DSU. For example, the WTRU may determine that a sufficient amount of data has been multiplexed in one or more transport block(s) for transmission. The WTRU may determine the applicable PBR based on the applicable QoE-level and / or QoS parameters. The WTRU may determine the applicable amount of data to consider based on the status of PDUs and / or ePDUs within the applicable QoE-level and / or QoS parameters. For example, the WTRU may consider the amount of data transmitted for PDUx,y where X is equal to [0, QoE-level] and Y is equal to the minimum amount of PDUs for the xth ePDU to successfully complete the transmission of the ePDU.

[0138] The status of the DSU transmission may be “Delay satisfied.” The WTRU may determine that the delay of the DSU has been satisfied. For example, the WTRU may determine that the delay for the DSU is satisfied if one or more (e.g., all) the ePDUs of the DSU have their respective delay requirement satisfied. The WTRU may determine these criteria using ePDUs (e.g., only ePDUs) that are within the current QoE- level of the DSU. For example, similar to the criteria of “PBR satisfied” described above, the WTRU may make this determination of a set of the DSUs data. The WTRU may determine that the delay is satisfied for such amount of data if the corresponding transport blocks have been successfully transmitted (e.g., using HARQ acknowledgement (ACK) or radio link control (RLC) ACK). Whether or not the WTRU uses the latter criteria may be a configuration aspect of the WTRU.

[0139] The status of the DSU transmission may be set to “successful” or “completed.” In examples, the transmission of data associated with one DSU may be successful when at least a minimum amount of data associated with that DSU has been multiplexed on a TB. Additionally, or alternatively, the transmission of data associated to one DSU may be completed and the status of DSU transmission may be set to “successful” or “completed” in circumstances including but not limited to one or more of the following: when a sufficient amount of (e.g., all or a portion of) its associated data has been transmitted; when there is no data to transmit; when there is no data left to transmit; when data (e.g., only data) for which a discard operation has been triggered is left in the ePDU; and / or when a sufficient amount of (e.g., all or a portion of) data associated with a dependent DSU has been transmitted.

[0140] In examples, if the ePDU is configured to transport data that requires successful reception of yO out of the total y1 PDUs of ePDUx, the WTRU may determine the status of the ePDU as “successful” if at least yO PDUs of the ePDU have been multiplexed in a transport block for transmission. In examples, the WTRU may determine the status of the ePDU as “successful,” if e.g., only if) the TB is transmitted within the delay requirement of the ePDU. In examples, the WTRU may determine the status of the ePDU as “successful,” if (e.g., only if) one or more (e.g., all) the concerned TBs have at least been included in an initial HARQ transmission. In examples, the WTRU may determine the status of the ePDU as “successful,” if (e.g., only if) one or more (e.g., all) concerned TBs have been either included in an initial HARQ transmission and / or positively HARQ acknowledged. In examples, the WTRU may determine the status of the ePDU as “successful,” if (e.g., only if) one or more (e.g., all) concerned TBs have been positively HARQ acknowledged.

[0141] In examples, yO may be less than y1 (e.g., if data of the ePDU includes application-level FEC). In examples, yO may be equal to y1, (e.g., as a default configuration of the ePDU).

[0142] The WTRU may use the ePDU status to assess an inter-ePDU dependency within a given DSU and / or across ePDUs of different DSUs. The inter-ePDU dependency may be configured.

[0143] The WTRU may be configured with at least one ePDU.

[0144] The WTRU’s configuration for an ePDU may include one or more of the following parameters.

[0145] The WTRU’s configuration for an ePDU may include an index. The index may indicate indexing information of the ePDU in the DSU. The index may be similar to a sequence number and may be a specific number of bits. The index may be a configuration aspect of the DSU that represents the maximum number of ePDUs for the DSU. In such cases, the index may be incremented (e.g., continuously incremented) across various instances of the same DSU type.

[0146] The WTRU’s configuration for an ePDU may include a Priority. The Priority may indicate priority of the data within the ePDU. Such priority may be absolute across one or more (e.g., all) DSU instances, or relative to ePDUs (e.g., only ePDUs) of the same DSU. In the latter case, the DSU instance may be associated with its own priority information (e.g., when processing is applied between DSUs).

[0147] The WTRU’s configuration for an ePDU may include a PBR. The PBR may be applied per scheduling period. For example, ePDUO may be equal to GBRmin of the service and / or data associated to a given type of data flow / media, while the sum of the respective PBR values across one or more (e.g., all) ePDUx may equal to GBRmax for that data associated with the DSU type and / or DSU instance.

[0148] The WTRU’s configuration for an ePDU may include one or more Dependencies. One or more dependencies (e.g., as described herein) may be applied to an ePDU. In examples, a first ePDUy may be configured to have PBR set to zero unless the WTRU determines that the status of a second ePDUx (where y > x) of the same DSU is “successful” or “PBR / Delay satisfied.” In examples, the second ePDU may be associated with a different DSU instance.

[0149] The WTRU’s configuration for an ePDU may include a Status. The ePDU may be associated with criteria that determine the status of the ePDU. In examples, the status of an ePDU may be according to one or more of the criteria discussed herein.

[0150] The status of the transmission of an ePDU may be set to “failed” if there is still data available for transmission (or expected to become available) but at least one or more of the QoS requirement for the ePDU has not been met within the required time. In examples, the status of the transmission of an ePDU may be set to “failed,” if (e.g., only if) there is no such data that is not ongoing transmission. In examples, the status may be set to failed for a given ePDU if (e.g., only if) it has not previously been set to “successful” or “completed.” In examples, the status may be set to failed for a given ePDU if the time / latency bound associated with the ePDU set (e.g., PSDB) has been reached. In examples, the status may be set to failed for a given ePDU if the time / latency bound associated with the ePDU set (e.g., PSDB) is within a preconfigured window of being exceeded. In examples, the status may be set to failed for a given ePDU if the time / latency bound associated with any constituent data unit of the ePDU set (e.g., PDB of one or more PDUs of the ePDU set) has been exceeded. In examples, the status may be set to failed for a given ePDU if the time / latency bound associated with any constituent data unit of the ePDU set (e.g., PDB of one or more PDUs of the ePDU set) is within a window of being exceeded. In examples, the status may be set to failed for a given ePDU if a certain number of constituent data units of the ePDU set have not met their respective QoS requirements (e.g., a number > N, where N > 1 of PDUs within the ePDU set were not transmitted within their respective PDB). Additionally, or alternatively, in examples, the status may be set to failed for a given ePDU if other criteria with higher priority have first been reached (e.g., if other data with higher priority was prioritized over this ePDU set for multiplexing into a transport block).

[0151] The status of the ePDU transmission may be set to “pending” if there is still data available for transmission (or expected to become available) within the QoS requirement of the ePDU instance (e.g., within the delay bound, within the PBR, etc.). For example, the status of the ePDU may be set to “pending” if not set to one of: “PBR satisfied,” “Delay satisfied,” “successful,” or “completed.”

[0152] The status of the ePDU transmission may be set to “PBR satisfied,” for example, if the WTRU determines that the PBR of the ePDU has been satisfied. For example, the WTRU may determine that a sufficient amount of data has been multiplexed in one or more transport block(s) for transmission. The WTRU may determine the applicable PBR based on the applicable QoE-level and / or QoS parameters. The WTRU may determine the applicable amount of data to consider based on the status of PDUs and / or ePDUs within the applicable QoE-level and / or QoS parameters. For example, the WTRU may consider the amount of data transmitted for PDUx,y where X is equal to [0, QoE-level] and Y is equal to the minimum amount of PDUs for the xth ePDU to successfully complete the transmission of the ePDU.

[0153] The status of the ePDU transmission may be set to “Delay satisfied” (e.g., if the WTRU determines that the delay for the DSU has been satisfied). For example, similar to the criteria of “PBR satisfied” described above, the WTRU may make this determination of a set of the DSUs data. In examples, the WTRU may determine that the delay is satisfied for such amount of data if the corresponding transport blocks have been successfully transmitted (e.g., HARQ ACK, RLC ACK). Whether or not the WTRU uses the latter criteria may be a configuration aspect of the WTRU.

[0154] The status of the ePDU transmission may be set to “successful” or “completed.” In examples, the transmission of data associated with one ePDU may be successful when at least a minimum amount of data, or PDUs of the ePDU, have been multiplexed on a TB. Additionally, or alternatively, the transmission of data associated to one ePDU may be completed when a sufficient amount of (e.g., all of) its associated data has been transmitted, when there is no data to transmit, when there is no data left to transmit and / or when data (e.g., only data) for which a discard operation has been triggered is left in the ePDU.

[0155] In examples, if the ePDU is configured to transport data that requires successful reception of yO out of the total y1 PDUs of ePDUx, the WTRU may determine the status of the ePDU as “successful” or "completed" if at least yO PDUs of the ePDU have been multiplexed in a transport block for transmission. In examples, the WTRU may determine the status of the ePDU as “successful” or “completed” if (e.g., only if) the TB is transmitted within the delay requirement of the ePDU. In examples, the WTRU may determine the status of the ePDU as “successful” or “completed,” if (e.g., only if) one or more (e.g., all) the concerned TBs have at least been included in an initial HARQ transmission. In examples, the WTRU may determine the status of the ePDU as “successful” or “completed,” if (e.g., only if) one or more (e.g., all) concerned TBs have been either included in an initial HARQ transmission and / or positively HARQ acknowledged. In examples, the WTRU may determine the status of the ePDU as “successful” or “completed,” if (e.g., only if) one or more (e.g., all) concerned TBs have been positively HARQ acknowledged.

[0156] In examples, yO may be less than y1 (e.g., if data of the ePDU includes application-level FEC). In examples, yO may be equal to y1 (e.g., as a default configuration of the ePDU).

[0157] The WTRU may use the ePDU status to assess an inter-ePDU dependency within a given DSU and / or across ePDUs of different DSUs. The inter-ePDU dependency may be configured.

[0158] The ePDU may include of one or more PDUs. Each PDU may be configured with a Sequence number (SN). The SN may be a of specific number of bits. The SN may be a configuration aspect of the ePDU that represents the maximum number of PDUs for the ePDU. The SN may be used for security (e.g., encryption, ciphering and / or authentication). The SN may be combined with the ePDU ID and / or with the DSU ID to create a longer sequence number used with the applicable security key. In examples, the SN may continuously be incremented across various instances of the same DSU type.

[0159] The WTRU may be configured with a maximum number of PDUs for the ePDU in the DSU. The WTRU may be configured with a maximum size for PDUs in an ePDU.

[0160] In examples, the WTRU may be configured with a Security configuration (e.g., per DSU type). The WTRU may be configured with a security algorithm (e.g., for ciphering). The WTRU may be configured with an integrity protection algorithm. The WTRU may be configured with one or more security keys (e.g., initial keys and / or key derivation parameters). In examples, the WTRU may be aware of a security context. In examples, the WTRU may maintain and apply the security configuration per DSU type. The WTRU may include coverage for ciphering and / or integrity protection. The WTRU may be configured with the number of octets to cover per PDU, and / or per transport block, for example, if a transport block includes (e.g., only includes) PDUs of the same ePDU I DSU type.

[0161] The DSU index may be combined with the ePDU index and / or with the PDU SN to determine the sequence number to be used in the security algorithm, together with the applicable security key. An additional sequencing set of bits may be used to increase the size of the SN, to minimize the frequency of the update for the security key needed once the SN wraps around, by itself or in combination with the other sequencing information.

[0162] In examples, DSU transfer success may be defined as a function of latency bound, applicable bitrate and redundancy coding and / or error correction coding.

[0163] In examples, DSU A is successfully transferred (e.g., in the UL or DL) if X PDUs out of Y (e.g., the total number of constituent PDUs of DSU A) are successfully transferred within a time window no later than the latency bound at the applicable bitrate (e.g., min bitrate).

[0164] In examples, DSU transfer success may be defined as a function of latency bound, applicable bitrate and redundancy coding / error correction coding.

[0165] In examples, DSU A is successfully transferred (e.g., in the UL or DL) if X PDUs out of Y (e.g., the total number of constituent PDUs of DSU A) are successfully transferred within a time window no later than the latency bound at the applicable bitrate (e.g., min bitrate).

[0166] The WTRU may be configured to associate one or more PDUs with a given DSU. A DSU may include one or more PDU(s) associated with the DSU according to at one or more of the following: PDU priority (e.g., priority of each PDU is the same and / or within a configured range of priorities) and / or target bitrate (e.g., target bitrate associated to the transmission of a PDU is the same and / or within a configured range of bitrates).

[0167] In examples, the WTRU may associate PDUs that have a common priority of transmission for a given bitrate. The WTRU may associate a group of PDUs which may include of one or more sub-groups ofPDUs (e.g., one or more PDU sets) where each sub-group has a common priority of transmission for a given bitrate. The WTRU may associate a group of PDUs with a common priority of transmission for a given bitrate. The WTRU may associate a group of PDUs with similar PDU-level QoS requirements and / or attributes (e.g., reliability, latency, target error rate).

[0168] A DSU may account for associations and inter-dependencies between its constituent one or more PDUs (e.g., ‘i ntra-DSU’ dependencies). A DSU may account for associations and dependencies between its constituent one or more PDUs and one or more PDUs of another DSU, (e.g., an adjacent and / or previous and / or subsequent DSU). For example, a ‘subsequent’ ‘data bucket’ may refer to another DSU generated by the application / higher layer immediately after the original ‘data bucket’

[0169] DSUs may have a semi-static configuration. The semi-static configuration may indicate one or more of: a type (e.g., AKA priority), relationships within a DSU, and / or relationship between two or more DSUs. In a dynamic configuration, a GBR may translate into a packet delay budget (PDB) and / or a PBR while also considering a delay bound.

[0170] Decoupled data may be reported with a delay bound irrespective of dependency to other data.For example, a WTRU may be capable of reporting data (e.g., with delay bound) without knowing that there is other data with the same dependency. A BSR may have an implicit “slot” for delay bound and / or explicit T bound indication with data and could be relative to timing of a grant for BSR, and / or SFN boundary.

[0171] Several types of dependencies may exist in the traffic including one or more of the following: I ntra- DSU dependencies (e.g., dependencies between constituent packets of a DSU, and / or Dependenciesbetween groups / sets of PDUs / PDU sets / ePDU sets within a DSU corresponding to a bitrate); and / or Inter- DSU dependencies (e.g., dependencies between different DSUs).

[0172] Any one or more of the dependencies may be determined by the WTRU and / or known / communicated to the WTRU based on one or more of: markings added at the application or SDAP or at a new layer above / below SDAP; arrival times; data type(s); QoS flow; and / or an explicit indication from an application.

[0173] In examples, markings may be added to the DSU (e.g., in a header of a constituent packet of the DSU) and / or sent via separate signaling (e.g., metadata via a control PDU) to indicate attributes of the DSU (e.g., importance, priority, reliability, delay budget, etc.). In examples, the lower layers may read the markings and determi ne / infer intra / inter DSU dependencies from the markings. In examples, Sequence Numbering (SN) markings added to the DSU (e.g., in a header of a constituent packet of the DSU) or sent via separate signaling (e.g., metadata via a control PDU). In examples, the lower layers may read the markings and determi ne / infer intra / inter DSU dependencies from the markings. In examples, PDUs 1, 2, 3 of a PDU set may be marked with (1 ,1), (1 ,2), (1 ,3), etc.

[0174] In examples, a WTRU may determine dependencies based on arrival times. Time keeping (e.g., at service data application protocol (SDAP) / packet data convergence protocol (PDCP)) may be with respect to time reference (e.g., SFN) time window start / end times. In examples, the lower layers may assume there are dependencies within two data units (e.g., two packets, PDU sets, ePDU sets, etc.) that arrive within a time window of each other.

[0175] The WTRU may transmit PDUs of first priority level for a given DSU (e.g., where the first priority may correspond to the baseline set of the DSU). The WTRU may transmit PDUs of second priority level for a given DSU (e.g., a dependent set of PDUs) if a specific condition is met. In examples, such conditions may correspond to the statuses of one or more PDUs of a higher priority in the same DSU and / or in a different DSU. In examples, such conditions may correspond (e.g., only) to the statuses of one or more PDUs associated to DSUs of the same DSU type.

[0176] A PDU set I ePDU set may include one or more PDUs with any one or more of the following properties, a common priority, px, of transmission for a given bitrate; a common latency bound of transmission for a given bitrate; a property that constitutes one frame and / or picture and / or data burst from the application perspective; and / or a property indicating being generated by the codec at once (e.g., within a short time interval of one another).

[0177] The delay bound may define an upper bound for the time that a DSU may be delayed in the L2 stack: In examples, the upper bound may be for the time between when a DSU is received at the L2 stack (e.g., SDAP in the UL, MAC in the DL) and when the DSU exits the L2 stack (e.g., MAC in the UL, SDAP in the DL). The delay bound of a DSU may be a function of a larger upper bound time budget for transmitting the DSU, referred to as ‘DSU Delay Budget’ (DDB). The DDB may correspond to an upper bound for the time that a DSU may be delayed between the WTRU and the N6 termination point at the user plane function (UPF). The DDB may correspond to an upper bound between the time the DSU is generated at the transmitter to when it is received at the receiver (e.g., including the over the air transmission time). The delay bound for a DSU may be a function of the PDB of the constituent packet(s) of the DSU and / or the PDU Set Delay Budget (PSDB) of the constituent PDU set. Each DSU / DSU instance or type thereof may have a fixed / constant delay bound.

[0178] A WTRU may receive (e.g., as part of RRC configuration, RRC configuration with handover, etc.) configuration for DSUs or types thereof, where a DSU or type thereof may be associated with one or more of the parameters as described herein. Each configuration may have a set of DSU(s) or types thereof, out of which a subset may be activated for use during the PDU session. These may be indicated by the DSU- Identity information element (IE) and / or ActivatedDSU-ldentity IE.

[0179] The WTRU may perform actions to configure the DSU or type thereof based a DSUConfig IE received from the network. This may include DSU addition, DSU modification, DSU release, etc. As part of the DSUConfig IE, there may be the DSU-ldentity IE which the network (NW) uses to indicate to the WTRU the DSU(s) or types thereof that can be used by the WTRU. In examples, the NW may determine the DSU(s) or types thereof for a session from information received from the core network (CN) during PDU session establishment. The NW may update the DSU(s) or types thereof if there is a need for it.

[0180] As part of DSU addition / modification, the WTRU may receive configuration from the NW to establish the PDCP entity and configure it for each new DSU-ldentity or ActivatedDSU-ldentity, establish the security (ciphering / integrity) based on the target radio access technology (RAT), and establish a service data application protocol (SDAP) entity if needed. As part of DSU release, the WTRU may be configured to release DSU-ldentity or ActivatedDSU-ldentity and the corresponding PDCP entity (e.g., if there is a 1 :1 mapping between PDCP entity and DSU or type thereof). The WTRU may also be configured to indicate the DSU release to other layers (e.g., SDAP or upper layers).

[0181] Throughout the session, the WTRU may receive L1 signaling from the NW that signals a change from one configuration to another. For DL traffic, this may be based on information received by the NWfrom the CN. For UL traffic, this may be based on information transmitted by the WTRU on the traffic (e.g., UL jitter, UL periodicity, end of data burst, end PDU of PDU set, etc.).

[0182] The WTRU may receive DSU configuration or an update thereof from the NW including but not limited to following any of the circumstances discussed herein. The WTRU may receive DSU configuration or an update thereof from the NW following PDU session establishment. The WTRU may receive DSU configuration or an update thereof from the NW following RRC (re)configuration. The WTRU may receive DSU configuration or an update thereof from the NW following a request from WTRU to NW. In examples, the WTRU may request DSU configuration or an update thereof from the network based on a WTRU measurement of UL traffic parameters and reporting the parameters to the NW (e.g., UL jitter, UL traffic periodicity, etc.). In examples, the WTRU may request DSU configuration or an update thereof from the network based on an indication from application of an upcoming surge in UL traffic. The WTRU may receive DSU configuration or an update thereof from the NW on detection of congestion at NW. The WTRU may receive DSU configuration or an update thereof from the NW on detection of congestion at the WTRU (e.g., based on buffer levels monitoring at the WTRU). The WTRU may receive DSU configuration or an update thereof from the NW based on WTRU location or a change thereof (e.g., at cell edge, the WTRU may select a DSU that can accommodate more PDUs to ensure that one or more (e.g., all) PDUs of a PDU set can be transmitted to the source gNB before handover). The WTRU may receive DSU configuration or an update thereof from the NW following a change in L1 or L3 measurements (e.g., based on reference signal received power (RSRP) measurements, etc.).

[0183] The delay bound may define an upper bound for the time that a DSU may be delayed in the L2 stack: In examples, the upper bound may be for the time between when a DSU is received at the L2 stack (e.g., SDAP in the UL, MAC in the DL) and when the DSU exits the L2 stack (e.g., MAC in the UL, SDAP in the DL). The delay bound for a DSU may be a function of a larger upper bound time budget for transmitting the DSU, referred to as ‘DSU Delay Budget’ (DDB). The DDB may correspond to an upper bound for the time that a DSU may be delayed between the WTRU and the N6 termination point at the UPF. The DDB may correspond to an upper bound between the time the DSU is generated at the transmitter to when it is received at the receiver (e.g., including the over the air transmission time). The delay bound for a DSU may be a function of the PDB (Packet Delay Budget) of the constituent packet(s) of the DSU and / or the PSDB (PDU Set Delay Budget) of the constituent PDU set.

[0184] Lower layers may refer to any layer within the Access Stratum (AS) protocol stack (e.g., service data application protocol (SDAP), packet data convergence protocol (PDCP), radio link control (RLC), medium access control (MAC), physical (PHY), and / or any other new protocol layer).

[0185] In legacy logical channel priority (LCP), after the WTRU receives an UL grant from the network, the WTRU selects the logical channel that satisfies conditions associated to the UL grant and meets any mapping restriction associated to the logical channel (e.g., allowedSCS-List, maxPUSCH-Duration). The WTRU then allocates resources to the selected logical channel based on priority and Bj of the selected logical channel.

[0186] The current LCP procedure does not consider any time related information. When data arrives in a higher priority logical channel (LCH), the WTRU always preferentially transmits the data, in some cases at the expense of data in a lower priority LCH which may have a smaller remaining time with respect to its respective delay budget. The current LCP procedure only allocates data to the logical channel selected initially. Even if the WTRU has additional data, it will not allocate to a logical channel not initially selected.

[0187] Delay-aware scheduling may be a mechanism to make the data and associated delay known to gNB or modify LCP priority dynamically. It may be based on one or more of: timestamping, + transmission delay requirement(s), and / or LCP (e.g., assuming gNB knows how to dimension the TBs and grants). In examples, the priority of data (e.g., PDU, PDU set, DSU) may change as a function of the time (e.g., remaining time, time spent in L2 buffer). For data having the same priority, the WTRU may select the data with the least remaining time for transmission and / or data of the DSU that is already ongoing HARQ transmission. The corresponding SR / BSR may be based on DSU Type / ID reported with non-zero data whereby the gNB may implicitly determine required the GBR, latency requirement of the reported data in the SR / BSR.

[0188] The WTRU may receive from the NW configuration (e.g., via RRC, MAC CE or DCI) including one or more of the following: Thresholds T1 for remaining time, thresholds T2 for time spent in L2 buffer, thresholds T3 for delay budget, and / or when to consider remaining time during LCP.

[0189] In examples, when the remaining time of data in LCH buffer is less than or equal to T1 , the WTRU may allocate resources to the data (e.g., even if data belongs to a lower priority LCH). In examples, the WTRU may multiplex (e.g., only multiplex) the data with the smallest remaining time value (e.g., PDU set with smallest remaining time with respect to PSDB) into the MAC PDU. In examples, the WTRU may multiplex any data with remaining time below T1 into the MAC PDU.

[0190] In examples, when time data spent in the L2 buffer is greater than T2, the WTRU may allocate resources to the data (e.g., even if data belongs to a lower priority LCH).

[0191] In examples, when the delay budget of data (e.g., PDB of PDU, PSDB of PDU set, delay bound of DSU) is less than T3, WTRU may allocate resources to the data (e.g., even if data belongs to a lower priority LCH). T3 may be a function of the PDB / PSDB / delay bound of DSU or types thereof that WTRU is configured with (e.g., WTRU may be configured to apply a smaller threshold T3 for a PDU versus a DSU).

[0192] In examples, the WTRU may receive a NW configuration indicating that the WTRU should consider remaining time if any of the thresholds discussed herein are configured. In examples, the WTRU may receive a NW configuration indicating that the WTRU should consider remaining time if any of the above thresholds are configured and their corresponding conditions are met (e.g., threshold is exceeded). In examples, the WTRU may receive a NW configuration indicating that the WTRU should consider remaining time depending on the type of traffic / service in the UL.

[0193] In examples, the WTRU may receive a NW configuration indicating that the WTRU should consider remaining time when the WTRU initiates PDU session establishment process by sending a request to the 5G CN. The WTRU may include the type of service / traffic that it wants to use in the session establishment request message so that the CN may do the appropriate configuration for the WTRU to receive the appropriate QoS (e.g., configure the DRBs according to the service / traffic requirements). The WTRU may receive an indication (e.g., from CN / NW / gNB) to consider remaining time during LCP based on the type of traffic / service that the WTRU would like to use (e.g., from the gNB through RRC (re)configuration). In examples, the WTRU may be configured to consider remaining time during LCP based on the type of service / traffic it wants to use (e.g., consider remaining time for URLLC or XR traffic, but not for eMBB traffic). In examples, the application layer may map data that requires special treatment in the AS layers to specific QoS flows, which are then processed by PDCP entities that are configured to account for remaining time (e.g., based on PDCP discardTimer). The WTRU may receive these mapping rules from the gNB / CN (e.g., similar to how the WTRU receives mapping rules for SDAP to map QoS flows to DRBs). When such data arrives at the MAC layer, the MAC may be able to distinguish the data based on SN allocated by PDCP and consider the remaining time associated to the data (e.g., in addition to priority, PBR, etc.) during LCP.

[0194] In LCP, the priority of data available for transmission may be a function of the remaining time. LCP may consider time information including one or more of the following, in addition to priority and Bj of the selected logical channel: delay budget of data buffered in LCH, remaining time with respect to delaybudget, time data has spent in L2 buffer, and / or remaining time with respect to a threshold configured by the network.

[0195] LCP may consider the delay budget of data buffered in LCH (e.g., PDB of PDU, PSDB of PDU set, DSU delay bound of DSD, etc.). In examples, the WTRU may allocate resource for data with the smallest delay budget.

[0196] LCP may consider the remaining time with respect to delay budget e.g., remaining time before expiry of the PDB / PSDB / DSU). In examples, the WTRU may allocate resource for data with the smallest remaining time with respect to its delay budget.

[0197] LCP may consider the time data has spent in L2 buffer. In examples, the WTRU may allocate resource for data that has been in the LCH buffer for the longest time period.

[0198] Additionally, or alternatively, LCP may consider the remaining time with respect to a threshold configured by the NW.

[0199] FIG. 3 depicts an exemplary procedure considering remaining time during LCP. Determining the remaining time may be done via timestamping and timekeeping at different layers of L2 (e.g., at SDAP, at PDCP, and / or at MAC).

[0200] Determining the remaining time may be done at SDAP. In examples, a new timer at SDAP may be started immediately after SDU / PDU enters SDAP. One new timer may be started for each SDAP SDU. Having a timer at SDAP may provide the advantage that timekeeping starts as soon as SDU enters L2. SDAP may convey the time spent by SDU / PDU in SDAP buffer to the PDCP entity.

[0201] Determining the remaining time may be done at PDCP. In examples, the existing PDCP discard timer may be reused for time keeping. One timer per PDCP SDU (e.g., as in legacy) and / or one timer per PDU set may be used. If there is one timer per PDCP SDU, remaining time may be calculated with respect to the PDB of the SDU / PDU. In examples, remaining time may be equal to PDB minus time spent in PDCP buffer (e.g., from PDCP discardTimer of SDU). In examples, remaining time may equal threshold T1 minus time spent in PDCP buffer (e.g., from PDCP discardTimer of SDU). Threshold T1 may be a function of the PDB of the packet. Threshold T 1 may always be configured to be less than the PDB of the packet since the PDB should account for the time for the packet to be delivered at the receiving end. Threshold T 1 may be configured. Threshold T 1 may be received from the NW. Additionally, or alternatively, the WTRU may be configured to determine threshold T 1 which is a function of and less than the PDB via a preconfigured formula (e.g., threshold T 1 may be equal to PDB of packet minus 20% of PDB of packet). If there is one timer per PDU set, the remaining time may be calculated with respect to the PSDB of the PDU set. Inexamples, if one or more (e.g., all) PDUs of the PDU set arrive at the L2 buffer at the same time, remaining time may be equal to PSDB minus time spent in PDCP buffer (e.g., from PDCP discardTimer of PDU set). In examples, if there is sequential arrival of PDUs of PDU set at the L2 buffer, remaining time may be equal to PSDB minus time spent in PDCP buffer by the first PDU of the PDU set (e.g., from PDCP discardTimer of the first PDCP SDU of PDU set that arrived at PDCP).

[0202] If WTRU receives a time information from SDAP (e.g., corresponding to the time spent in SDAP entity or time stamp at which SDU / PDU entered SDAP entity), WTRU may also account for the time spent in SDAP when determining remaining time. In examples, remaining time may be equal to PDB minus time spent in a PDCP buffer (e.g., from discardTimer + time spent in SDAP buffer). If assembling of the data (e.g., PDCP SDUs / PDUs / PDU sets) into the DSU is done at PDCP, the PDCP may consider the time information related to the data when selecting the appropriate DSU. In examples, the PDCP may consider selecting a DSU with a time bound that aligns with the remaining time of the data and / or the delay budget (PDB of packet, PSDB of PDU set) of data to be assembled into the DSU.

[0203] Determining the remaining time may be done at MAC (e.g., WIP). Since the MAC is where LCP happens and where PDUs / SDUs may get assembled into the DSU, time keeping may be based on a new timer at MAC. There may be one timer per MAC SDU or one timer per PDU set. The MAC may receive an indication from PDCP (e.g., time spent in PDCP buffer based on PDCP discardTimer). The MAC may take into account time spent in other L2 buffers when determining the remaining time of the data unit. In examples, remaining time of packet may equal PDB minus time spent in L2 buffer. In examples, time spent in L2 buffer may equal time spent in one or more of: an SDAP buffer, a PDCP buffer, an RLC buffer, a MAC buffer, etc.

[0204] Delay-bounded scheduling assumes there is dynamic synchronization between the gNB and WTRU for scheduler resource allocation for a given period. The gNB may signal back instant GBR for the current / next scheduling period, so that the WTRU can determine the available rate. The gNB may know how much data (e.g., exactly how much data) there is at most for any given time period. This method may enable dynamic setting from gNB to WTRU the QoS profile for upcoming periods (e.g., applicationawareness and rate adaptation).

[0205] Time may be managed at different layers of the protocol stack at different granularities via one or more of the following: slot; sub-frame, identified by a subframe number; frame, identified by a system frame number (SFN); hyper frame number (HFN) / hyper SFN; timestamps; and / or scheduling intervals (e.g., configured by the network) in terms of any one or more of the time parameters discussed herein.

[0206] Time may be managed via slot (e.g., NR slot has 14 symbols). Time may be managed via subframe, identified by a subframe number (e.g., using intervals of 1 ms). Time may be managed via frame, identified by a SFN (e.g., using intervals of 10ms).

[0207] Upon creation of a DSU instance, the DSU may be associated with one or more scheduling periods, with the latest period corresponding to the maximum time for successfully completing transmission of “enough data of the DSU” for a successful transmission of the DSU.

[0208] The gNB and WTRU may be synchronized with respect to each period based on system frame timing as described herein. This may create scheduling periods that will enable the NW to schedule transmissions from the WTRU using a dynamic PBR, PDB while implementing delay / time bound guarantees.

[0209] In LCP, an LCP logical step may be that data available for transmission across different DSUs includes data to be scheduled no later than at the next boundary and / or data from a DSU up to PBR for one or more (e.g., all) remaining available periods of the DSU.

[0210] The WTRU may be configured with a scheduling period to ensure the WTRU and the gNB are aligned on when (e.g., the SFN number, slot number) the scheduling period starts. The WTRU may be configured with a few options for the scheduling period cycle lengths (e.g., a SchedulingPeriodCycle may be any of: 10ms, 20ms, 32ms, 40ms, 64ms, 70ms, 80ms, 128ms, 160ms, 256ms, 320ms, 512ms, 640ms, 1024ms, 1280ms, 2048ms, 2560ms, 5120ms, 10240ms, etc.). The WTRU may be configured with a start offset (e.g., SchedulingPeriodCycleStartOffset) corresponding to each one (e.g., SchedulingPeriodCycleStartOffset may be defined as follows:SchedulingPeriodCycleStartOffset CHOICE { ms10 INTEGER(0..9), ms20 INTEGER(0..19), ms32 INTEGER(0..31), ms40 INTEGER(0..39), ms60 INTEGER(0..59), ms64 INTEGER(0..63), ms70 INTEGER^..69), ms80 INTEGER(0..79), ms128 INTEGER(0..127), ms160 INTEGER(0..159),ms256 INTEGER(0..255), ms320 INTEGER(0..319), ms512 INTEGER(0..511), ms640 INTEGER(0..639), ms1024 INTEGER(O..1023), ms1280 INTEGER(O..1279), ms2048 INTEGER(O..2O47), ms2560 INTEGER(0..2559), ms5120 INTEGER(0..5119), ms10240 INTEGER(O..10239) },.

[0211] The offset may serve as an easy / flexible way for the NW to delay the start of the scheduling period / interval. The offset may also serve as a ‘measurement gap’ during which no transmission and reception happens such that the WTRU can prioritize performing signal quality measurements during the offset interval. The NW may simply indicate a default offset value (e.g., of ‘0 ms’) if no offset to the scheduling period / interval is needed. The offset value may be defined in ms such that the scheduling period / interval may start at a subframe boundary providing the NW with more flexibility on when / where to start the scheduling period. In the case where an offset is applied to the scheduling period / interval, the WTRU may not transmit data during the offset. In examples, the periodicities may be defined as fixed across one or more (e.g., all) types of traffic. In examples, the periodicities may be different based on the type of traffic. In examples, for XR / video type traffic defined in terms of framerates which translate into non-integer periodicities, the WTRU may be configured with some non-integer SchedulingPeriodCycle values (e.g., 8.33ms, 16.67ms, 33.33ms, 66.33ms, etc.). The offset may be defined in terms of integer values or non-integer values to apply to video type traffic.

[0212] The WTRU may receive from the network the scheduling period cycle length and corresponding offset as part of the Scheduling-Period IE, (e.g., ms128 INTEGER(O) for a scheduling period of length 128ms with 0ms start offset). The WTRU may determine the subframe after which to start the scheduling period using a formula (e.g., [SFN x 10 + subframe number] modulo (SchedulingPeriodCycle) = (SchedulingPeriodCycleStartOffset).

[0213] In examples, the formula may be per DSU TYPE (e.g., DSU type ID) and / or DSU instance (e.g., DSU ID). Each DSU type and / or DSU instance may be associated to one or more scheduling period(s) as a function of the latency requirement for the given PBR of the DSU. The WTRU may subsequentlydetermine whether or not it may use a configured grant (CG) based on the scheduling period and agreed PBR. The WTRU may be configured with physical downlink control channel (PDCCH) occasions per scheduling period (e.g., to minimize blind decoding). In examples, each period may be associated with, for example, a period SN / ID which may be tied to a specific set of radio resources, where a DSU can be associated if the period ends before expiration of the timer and / or the timestamp plus Latency requirement.

[0214] The triggering condition for the WTRU to determine the scheduling period starting point and / or start a timer to keep track of the scheduling period may be any one or more of the following: RRC (re)configuration and / or reception of Scheduling-Period IE or an update thereof (e.g., via RRC, MAC CE, DCI). In examples, the Scheduling-Period IE may carry one or more of the following parameters: SchedulingPeriodCycle (e.g., defining the length of the scheduling period);SchedulingPeriodCycleStartOffset (e.g., defining the start offset to apply to the scheduling period); and / or a formula to apply to determine the subframe where to start the scheduling period.

[0215] The WTRU may be configured with one or more DSUs or types thereof with different parameters. For example, the MAC entity in the WTRU may be configured by the RRC layer with the scheduling period configuration. The entire scheduling period configuration may be sent in the Scheduling-Period IE.

[0216] In examples, the selection of the DSU or type thereof may be a function of the length of the scheduling period. For example, the WTRU may be configured with multiple DSUs or types thereof during RRC (re)configuration. Reception and / or update of information on the scheduling period from the network may trigger the WTRU to activate a subset of the DSU(s) it is configured with. For example, the WTRU may be configured to activate a DSU with a smaller time bound after receiving an indication from the network to apply a shorter scheduling period.

[0217] A NW may update scheduling periods / intervals or types thereof and / or offset based, at least in part, on a WTRU report. The NW may determine the scheduling periods and corresponding offsets. In some cases, the WTRU may have additional information on the ongoing / upcoming UL traffic (e.g., via information received from the application). The WTRU may transmit a request to the network to change the scheduling period and / or offset via any one or more of the means discussed herein.

[0218] The WTRU may report on its preferred scheduling period and preferred offset as part of RRC (re)configuration, for example, as part of PreferredSchedulingPeriodCycle and / or PreferredSchedulingPeriodCycleStartOffset). The values of PreferredSchedulingPeriodCycle and / or PreferredSchedulingPeriodCycleStartOffset may be in ms (milliseconds) (e.g., msO may correspond to 0, ms1 may correspond to 1 ms, ms2 may correspond to 2 ms, and so on). If the field is absent from theScheduling-Period IE, it may be interpreted as the WTRU having no preference for a change in either parameter.

[0219] The WTRU may report on its preferred scheduling period and preferred offset using multiple SR and / or BSR requests. Transmission of multiple SR and / or BSR requests to the NW within a short time interval may represent an indication to the network to alter (e.g., shorten or lengthen) the length of the scheduling period.

[0220] Transmission of a new BSR while there is an ongoing BSR for which any MAC PDU or a MAC PDU sufficiently large to accommodate a sufficient amount of (e.g., all of) the data in the WTRU buffer has not been allocated to the WTRU may represent an indication to the network to alter (e.g., shorten or lengthen) the length of the scheduling period.

[0221] Transmission of BSR requesting for a large grant from the NW may represent an indication to the network to alter (e.g., shorten or lengthen) the length of the scheduling period. In examples, such a BSR may be sent when buffer size is greater than a preconfigured threshold; or when buffer size for one / any LCG is greater than a preconfigured threshold. This may apply to both long BSR and short BSR. In examples, transmission of a BSR requesting for a large grant from the NW may represent an indication to the network to alter (e.g., shorten) the length of the scheduling period when buffer size for more than one LCG is greater than a preconfigured threshold. In examples, transmission of BSR requesting for a large grant from the NW may represent an indication to the network to alter (e.g., shorten or lengthen) the length of the scheduling period when buffer size for a minimum number of LCGs (e.g., > 2) are greater than a preconfigured threshold.

[0222] Transmission I reporting of other parameters to the NW may represent an indication to the network to alter (e.g., shorten or lengthen) the length of the scheduling period. In examples, the WTRU may compute jitter statistics for UL traffic and transmit information on the UL jitter to the network, which may result in a change in SchedulingPeriodCycleStartOffset for one or more (e.g., all) scheduling periods. In examples, the WTRU may receive an indication from the application of an increase in the instantaneous jitter for an upcoming time window. The WTRU may determine the number of scheduling periods that would be impacted by the increase in jitter in the UL. The WTRU may report to the NW the instantaneous jitter and / or the number of scheduling periods impacted. Other parameters that may be reported to the network that may indicate to the network to alter the length of the scheduling period include, but are not limited to: traffic periodicity, an end of data burst indicator, and / or an end PDU (e.g., of an ePDU set and / or a DSU).

[0223] The WTRU may receive from the NW an update of the scheduling period and / or corresponding offset following any one or more of the triggers discussed herein in terms of an update in the Scheduling- Period IE.

[0224] A WTRU may be configured with different types of scheduling periods / intervals. In some cases, there may be periods of data transmission followed by periods of inactivity. In some cases, the periods of data transmission may be uneven, with a surge data transmission in one period followed by a period of low data transmission. This may be the case for any combination of UL and / or DL (e.g., for both UL and DL, for UL only, for DL only, etc.). Changing the length and / or offset of the SchedulingPeriodCycle via an update of the Scheduling-Period IE may take a long time, involve (re)configuration, and may not be flexible enough.

[0225] As a result, the NW may additionally, or alternatively, configure another type of scheduling period, for example, the Short-SchedulingPeriodCycle. Configuration of the Short-SchedulingPeriodCycle may be optional. If not configured, the WTRU may simply follow the SchedulingPeriodCycle as usual. When the WTRU is configured with Short-SchedulingPeriodCycle, it may also be configured with the SchedulingPeriodCycle which is the default configuration.

[0226] In cases where the traffic flow is not dense, (e.g., where there is no or low data activity), or when the traffic flow is uniform / periodic (e.g., video traffic with constant periodicity) the WTRU may follow the SchedulingPeriodCycle. In cases where the traffic flow is non-uniform (e.g., non-periodic, quasi-periodic, periodic with non-uniform periodicity), the WTRU may be configured with both the SchedulingPeriodCycle and the Short-SchedulingPeriodCycle. The length of the Short-SchedulingPeriodCycle may be configured such that the length of the SchedulingPeriodCycle is an integer multiple of the length of the Short- SchedulingPeriodCycle.

[0227] The WTRU may determine the subframe after which to start the short scheduling period (e.g., using the formula [(SFN x 10) + subframe number] modulo (Short-SchedulingPeriodCycle) = (SchedulingPeriodCycleStartOffset) modulo (Short-SchedulingPeriodCycle)).

[0228] The short scheduling period cycle configuration that the WTRU receives from the NW (e.g., during RRC (re)configuration) may include one or more of the parameters discussed herein.

[0229] The short scheduling period cycle configuration that the WTRU receives from the NW may include a Short-SchedulingPeriodCycle parameter which defines the length of the short scheduling period (e.g., in milliseconds).

[0230] The short scheduling period cycle configuration that the WTRU receives from the NW may include a Short-SchedulingPeriodCycleTimer parameter which defines the length of time (e.g., in milliseconds) the WTRU should apply the short scheduling period cycle after the start of the short cycle.

[0231] The short scheduling period cycle configuration that the WTRU receives from the NW may include a Short-SchedulingPeriodCyclel ntervals parameter which may be configured as an integer number and defines the number of short scheduling cycles the WTRU should follow after the start of the short cycle.

[0232] The short scheduling period cycle configuration that the WTRU receives from the NW may include a Short-SchedulingPeriodCycleStartOffset parameter which may define an offset (e.g., in milliseconds) to apply to the short scheduling cycle. This field may be optional. If the WTRU is configured with the short scheduling cycle, the WTRU may be configured to either apply an offset value (e.g., of 0ms) to the short scheduling cycle or to use the same offset value indicated for the regular / default SchedulingPeriodCycle.

[0233] Following the expiry of S hort-Sched uli ngPeriodCycleTimer and / or after the number of Short- SchedulingPeriodCyclelntervals has elapsed, the WTRU may be configured to start the regular / default SchedulingPeriodCycle. In the event where both parameters are configured, the WTRU may be configured to always prioritize one over the other or it may be configured to start the regular / default SchedulingPeriodCycle following the expiry of the one that comes first.

[0234] In examples, the WTRU may be configured to start the default / regular SchedulingPeriodCycle after (e.g., immediately after) the end of the Short-SchedulingPeriodCycle (e.g., in the subframe following the last subframe covered by the Short-SchedulingPeriodCycle). In examples, the WTRU may apply a formula (e.g., the above formula) to determine the subframe after which to start the short scheduling period. In examples, the WTRU may be configured to apply the formula at the expiry of Short- SchedulingPeriodCycleTimer or Short-SchedulingPeriodCyclel ntervals, whichever comes first. In examples, the WTRU may be configured to apply the formula at a time before Short-Scheduling PeriodCycleTimer and / or Short-Sched uli ngPeriodCyclel ntervals, to minimize the amount of time not covered by any scheduling period. For example, if Scheduli ng PeriodCyclel ntervals is equal to n, the WTRU may be configured to apply the formula at short cycle number n-1 or short cycle number n-2 to determine the subframe after which to start the short scheduling period in advance.

[0235] In examples, the formula may be per DSU TYPE (e.g., DSU type ID) and / or DSU instance (e.g., DSU ID). Each DSU type and / or DSU instance may be associated to one or more short scheduling period(s) as a function of the latency requirement for the given PBR of the DSU. The WTRU may subsequently determine whether or not to use a CG based at least in part on the short scheduling periodand agreed PBR. The WTRU may be configured with PDCCH occasions per short scheduling period (e.g., to minimize blind decoding). In examples, each period may be associated with, for example, a period SN / ID which may be tied to a specific set of radio resources, where a DSU can be associated if the period ends before expiration of the timer and / or the timestamp plus Latency requirement.

[0236] There may be time periods not covered by any scheduling period / interval (e.g., regular / default scheduling period or short scheduling period). In examples, the time periods when switching from one scheduling period configuration to another and / or at the start of a PDU session may not be covered by any scheduling period / interval. In examples, the WTRU may be configured with one or more default DSU(s) or type(s) thereof (e.g., best effort DSU) that the WTRU may use for treatment of data in L2 and send a BSR based on the default DSU. In examples, the WTRU may simply use DRBs for treatment of data in L2 and send a BSR (e.g., as it would in the legacy system). In examples, the WTRU may be configured with a default scheduling period which the WTRU may start upon completing (e.g., immediately upon completing) RRC (re)configuration unless / until it receives Scheduling-Period IE from the gNB, as part of RRC (re)configuration messages or subsequent messages.

[0237] A WTRU may report its preferred scheduling period and / or offset to the NW. After RRC (re)configuration where the Scheduling-Period IE or an update thereof is received by the WTRU from the NW, the NW may already know the scheduling period that will be applied by the WTRU and the subframe after which the WTRU will start the scheduling period.

[0238] In examples, the WTRU may indicate its preferred scheduling period and / or offset to the NW as part of PreferredSchedulingPeriodCycle and / or PreferredSchedulingPeriodCycleStartOffset (e.g., based on WTRU knowledge of most up to data UL traffic information, and / or based on computation of UL jitter, UL periodicity, or some indication from the application.) Following reception of PreferredSchedulingPeriodCycle and / or PreferredSchedulingPeriodCycleStartOffset, the NW may perform RRC (re)configuration where the Scheduling-Period IE or an update thereof is transmitted to the WTRU. Similarly, the NW may already know the scheduling period that will be applied by the WTRU and the subframe after which the WTRU will start the scheduling period.

[0239] In examples, the WTRU may receive the Scheduling-Period IE or an update thereof (e.g., via RRC, MAC CE, DCI) which may also carry the SFN and / or subframe number at which to start the scheduling period.

[0240] In examples, the WTRU may be configured to switch between scheduling configurations based on NW-configured conditions as described herein or autonomously The WTRU may be configured to reportthe subframe number or SFN number after which the WTRU will start the scheduling period. This may be accompanied using additional parameters (e.g., scheduling period type (e.g., regular, or short scheduling period), scheduling period cycle length, scheduling period offset length, etc.).

[0241] A WTRU may be configured to switch between different scheduling periods / intervals or types thereof. The WTRU may be configured to switch different scheduling periods / intervals or types thereof based on an indication / update from application on UL traffic parameters (e.g., UL jitter, UL traffic periodicity, change in the number of traffic flows for multi-modality traffic). The WTRU may be configured to switch different scheduling periods / intervals or types thereof based on a change in measurement and / or computation of UL traffic parameters (e.g., UL jitter, UL traffic periodicity, change in the number of traffic flows for multi-modality traffic). In examples, the WTRU may be configured to switch different scheduling periods / intervals or types thereof if jitter is greater than a preconfigured threshold. In examples, the WTRU may be configured to switch different scheduling periods / intervals or types thereof based on a change in jitter (e.g., from a previous jitter computation) being greater than a preconfigured threshold. In examples, the addition of a traffic flow may require an update of the scheduling period to match the periodicity of the new traffic flow Indication / update from CN on DL traffic parameters (e.g., DL jitter, DL traffic periodicity).

[0242] A WTRU may be configured to align scheduling periods / intervals with traffic periodicity. In examples, the WTRU may be configured to align the traffic flow periodicity with the scheduling periods / intervals. If the periodicity is roughly constant (e.g., for XR / video traffic which tends to be periodic) and there is a SchedulingPeriodCycle that matches the traffic periodicity, the WTRU may select the SchedulingPeriodCycle periodicity that aligns with the traffic periodicity and send it to the NW as part of the PreferredSchedulingPeriodCycle and / or PreferredSchedulingPeriodCycleStartOffset.

[0243] A NW may configure scheduling groups to assist a scheduler in keeping track of scheduling periods at WTRU. In examples, the serving gNB may have a separate scheduling configuration for each WTRU, based on the traffic at the WTRU. In examples, the gNB may have one scheduling configuration application to one or more (e.g., all) the WTRUs it is serving to make it easier for the scheduler to keep track of the scheduling periods at the WTRU. In examples, there may be groups configured whereby the parameters (e.g., scheduling period lengths, offsets, etc.) in scheduling-ConfigGroupI are different to the parameters in scheduling-ConfigGroup2. Based on the traffic profile for different WTRUs it is serving, the gNB may determine the scheduling-ConfigGroup that the WTRU belongs to and send the appropriate parameters to the WTRU in RRC (re)configuration.

[0244] Synchronization methods may be used to align timers between WTRU and gNB. Frame timing and SFN may be aligned between the different nodes (e.g., gNB and WTRU) via Synchronization signals (e.g., PSS, SSS, and / or new synchronization / reference signals). Frame timing and SFN may be aligned between the different nodes (e.g., gNB and WTRU) via GPS (Global Positioning system) signals. Frame timing and SFN may be aligned between the different nodes (e.g., gNB and WTRU) via an exchange between a WTRU and gNB (e.g., via MIB, SIB (e.g., SIB1), RACH messages, etc.) An exchange between a WTRU and gNB may include one or more of the following: when to start / stop the relevant counter(s) / timer(s); what granularity to do timekeeping (e.g., slot, sub-frame, frame level); which incoming SDU(s) to timestamp and the timestamping granularity; how / when to configure the scheduling intervals; and / or etc.

[0245] The WTRU may receive from the network configuration on one or more DSUs or types thereof. Parameters that differentiate one DSU (or types thereof) from another may include any one or more of the following attributes of the DSU as listed herein. When selecting a DSU (or type thereof) to use, the WTRU may consider any one or more of the DSU attributes herein against the parameters of the data in the WTRU buffer (e.g., the WTRU may determine suitability of a DSU or type thereof based on whether the PDB and / or remaining time associated to the packet can be met by using a DSU with a certain time / latency bound). Parameters / attributes of the DSU of type thereof may include one or more of the parameters discussed herein.

[0246] Parameters / attributes of the DSU of type thereof may include a DSU size. Parameters / attributes of the DSU of type thereof may include a total number of packets that the DSU can support.Parameters / attributes of the DSU of type thereof may include a number of packets per PDU set that the DSU can support. Parameters / attributes of the DSU of type thereof may include a number of PDU sets that the DSU can support. Parameters / attributes of the DSU of type thereof may include a Delay / latency bound associated with DSU, (e.g., a maximum delay budget (e.g., Dboundx, Dboundy, Dboundz, ...) associated to a DSU or type) thereof. Parameters / attributes of the DSU of type thereof may include a priority of the DSU. For example, a priority (e.g., Px, Py, Pz, for DSU types X, Y, Z, etc.). Parameters / attributes of the DSU of type thereof may include a priority of constituent PDU sets within the DSU. Parameters / attributes of the DSU of type thereof may include Bitrates supported by DSU (e.g., min bitrate, max bitrate). In examples, parameters / attributes of the DSU of type thereof may include a minimum prioritized bitrate, PBRmin (e.g., equal to minimum required GBR for flow(s) (e.g., PBRxmin for DSU type x, PBRymin for DSU type y, etc.)) and optionally one of more prioritized bit rate levels (e.g., PBRxl , PBRx2, PBRx3, ..., PBRxmax, etc. for DSU type x). Parameters / attributes of the DSU of type thereof may include, optionally, a priority indicationfor each PBR value of the DSU. Parameters / attributes of the DSU of type thereof may include an indication of redundancy and / or error correction supported by the DSU (e.g., data volume that needs to be successfully transmitted (e.g., X out of Y PDUs) to allow successful decoding of the DSU). In examples, the data volume that needs to be successfully transmitted to allow successful decoding of the DSU may be X out of (X+Y) PDUs for a DSU of size (X+Y). In examples, the data volume that needs to be successfully transmitted to allow successful decoding of the DSU may be XO out of (XO+YO) PDUs for setO within a DSU. In examples, the data volume that needs to be successfully transmitted to allow successful decoding of the DSU may be X1 out of (X1+Y1) PDUs for set1 within a DSU. In examples, the data volume that needs to be successfully transmitted to allow successful decoding of the DSU may be (X1 +X0) out of (X1 + Y1 + XO+YO) PDUs for a DSU of size (X+Y). Parameters / attributes of the DSU of type thereof may include an importance of constituent PDU(s) I PDU sets of DSU. Parameters / attributes of the DSU of type thereof may include, optionally, a maximum number of packets per set (e.g., baseline or dependent) that can be accommodated per DSU type.

[0247] The WTRU may be configured to assemble packets into the DSU in a way to ensure that the attributes of the DSU are met in the treatment of the packets in lower layers. This may constitute differentiated treatment of packets or integrated treatment of the packets in the L2 stack.

[0248] Packet assembly may be based on WTRU matching QoS of packets with DSU attributes (e.g., dependencies, delay bound, bitrate, priority, etc. as listed at the top of this section under DSU or type thereof). Assembling of packets into the DSU may happen at any L2 layer (e.g., SDAP, PDCP, MAC, new layer, etc.) and may consider the one or more of the attributes of the packet discussed herein.

[0249] Packet attributes may include a QoS of packet (e.g., PDB, packet error rate (PER)). Packet attributes may include a QoS of a PDU set to which the packet belongs (e.g., PSDB, PDU set error rate (PSER)). Packet attributes may include a remaining time of the packet (e.g., with respect to PDB). Packet attributes may include a remaining time of the PDU set (e.g., with respect to PSDB). Packet attributes may include a time packet / PDU set spent in L2 buffer(s) (e.g., time since entering SDAP). Packet attributes may include a time since generation of packet / PDU set at application, etc. Packet attributes may include Traffic characteristics (e.g., traffic / service type (e.g., ultra-reliable low latency communications (URLLC), enhanced mobile broadband (eMBB), extended reality (XR), etc.); traffic periodicity (e.g., in ms); QoS (e.g., PDB, PSDB, PER, PSER, etc.); and / or forward error correction (FEC), redundancy, and / or ability for error control coding). Packet attributes may include scheduling period / interval lengths. Packet attributes mayinclude a scheduling cycle type (e.g., regular / default scheduling period vs short scheduling period). Packet attributes may include a scheduling period offset.

[0250] For the purpose of buffer status reporting, the WTRU (e.g., transmitting entity(ies) in WTRU, e.g., PDCP / RLC / MAC) may do a data volume calculation to determine the amount of UL data in the WTRU buffer. For the data volume calculation, the WTRU may consider one or more of the following parameters or values.

[0251] For the data volume calculation, the WTRU may consider the amount of data at the one or more PDCP entities which may include, without limitation, one or more of the following. Data at the one or more PDCP entities may include the PDCP SDUs for which no PDCP Data PDUs have been constructed. Data at the one or more PDCP entities may include the PDCP Data PDUs that have not been submitted to lower layers. Data at the one or more PDCP entities may include the PDCP Control PDUs; For AM DRBs, data at the one or more PDCP entities may include the PDCP SDUs to be retransmitted. For AM DRBs, Data at the one or more PDCP entities may include the PDCP Data PDUs to be retransmitted.

[0252] For the data volume calculation, the WTRU may consider the amount of data at the one or more RLC entities which may include, without limitation, one or more of the following. Data at the one or more RLC entities may include RLC SDUs and RLC SDU segments that have not yet been included in an RLC data PDU. Data at the one or more RLC entities may include RLC data PDUs that are pending for initial transmission. Data at the one or more RLC entities may include RLC data PDUs that are pending for retransmission (e.g., RLC AM). Data at the one or more RLC entities may include an indication of the size of one or more status PDUs if status PDUs have been triggered and are needed to be transmitted in the next transmission opportunity.

[0253] For the data volume calculation, the WTRU may consider the amount of data available for a logical channel (e.g., at MAC). For the data volume calculation, the WTRU may consider the amount of data available for a logical channel group (e.g., at MAC). For the data volume calculation, the WTRU may consider the number of DSUs (e.g., in the MAC / PDCP / RLC buffer) with data. For the data volume calculation, the WTRU may consider the number of sets in each DSU with data. For the data volume calculation, the WTRU may consider the size of the one or more DSUs with data.

[0254] For the data volume calculation, the WTRU may consider the volume of data in the one or more DSUs (e.g., in the MAC / PDCP / RLC buffer). In examples, the volume of data in the one or more DSUs may be in terms of bits / bytes and / or number of PDUs per set and / or number of PDUs per DSU. In examples,the volume of data in the one or more DSUs may be in terms of the maximum amount of data and / or number of PDUs that can be accommodated in a DSU.

[0255] For the data volume calculation, the WTRU may consider the volume of data that needs to be transmitted (e.g., X out of Y PDUs) to allow successful decoding of the DSU. In examples, the DSU may be successfully decoded if at least X out of (X+Y) PDUs for a DSU of size (X+Y) are transmitted. In examples, the DSU may be successfully decoded if at least X0 out of (X0+Y0) PDUs for setO within a DSU are transmitted. In examples, the DSU may be successfully decoded if at least X1 out of (X1+Y1) PDUs for set1 within a DSU are transmitted. In examples, the DSU may be successfully decoded if at least (X1 + X0) out of (X1 +Y1 +X0+ Y0) PDUs for a DSU of size (X+Y) are transmitted.

[0256] For the data volume calculation, the WTRU may consider the priority of DSU(s) with data. In examples, DSU X may be associated with a first priority for transmission while DSU Y may be associated with a second priority for transmission. The WTRU may be configured to include in a data volume calculation PDUs of a DSU with a priority above a threshold.

[0257] For the data volume calculation, the WTRU may consider the priority associated with set(s) of PDUs within the DSU. In examples, DSU X may have two sets of PDUs, set 0 with priority pO and set 1 with priority p2. DSU Y may have two sets of PDUs, set 2 with priority p1 and set 3 with priority p3. In examples, the values of pO, p1 , p2, and p3 may be such that pO > p1 > p2 > p3.

[0258] For the data volume calculation, the WTRU may consider the time bound associated with the DSU(s) with data. In examples, the WTRU may do the data volume calculation for the DSUs associated a smaller time bound for the next upcoming uplink transmission (e.g., if some DSUs have a larger time bound and can be transmitted at a later time (e.g., in subsequent uplink transmissions)). In examples, the WTRU may do more than one data volume calculation corresponding to DSUs with different time bounds. For example, a first data volume calculation may include the amount of data for one or more of (e.g., all of) the DSUs with a time bound t1, and a second data volume calculation may include the amount of data for one or more of (e.g., all of) the DSUs with a time bound t2. In examples t2 may be greater than t1 .

[0259] The WTRU may receive assistance information and / or configurations (e.g., from the network) that may be explicitly provided via dedicated signaling (e.g., RRC signaling, MAC CE), and / or broadcast in system information, to perform the data volume calculation. The assistance information may include, without limitation, one or more of the elements described herein.

[0260] A WTRU may determine when to perform data volume calculation.

[0261] In examples, the WTRU may perform data volume calculation, periodically, with one or more periodicities configured by the NW.

[0262] In examples, the WTRU may perform data volume calculation based on buffer status monitoring. In examples, when data in any one or more of L2 buffers exceeds a threshold (e.g., exceeds 30% of the buffer), the WTRU may be configured to perform data volume calculation.

[0263] A WTRU may determine what to include in the data volume calculation.

[0264] As part of the configuration, the WTRU may receive preconfigured thresholds corresponding to any of the parameters described herein.

[0265] In examples, the WTRU may receive a preconfigured threshold TY corresponding to amount of data available for an LCH / LCG (e.g., at MAC). The WTRU may include data (e.g., only include data) in an LCH / LCG if amount of data in that LCH / LCG is greater than TY. In examples, the WTRU may receive a preconfigured thresholds Tx corresponding to the X out of (X+Y) PDUs for a DSU of size (X+Y), The WTRU may include (e.g., only include) data X in data volume calculation if X is greater than a threshold. In examples, the WTRU may receive a preconfigured threshold TO corresponding to X0 out of (X0+Y0) PDUs for setO within a DSU. In examples, the data volume calculation may include (e.g., only include) data X0 in data volume calculation if X0 > TO. In examples, the WTRU may receive preconfigured thresholds corresponding to X1 out of (X1 +Y1 ) PDUs for set1 within a DSU.

[0266] The BSR procedure may be used to provide the serving gNB with information about the UL data volume (e.g., in terms of the DSU or part thereof) in the WTRU buffer (e.g., buffer in MAC entity) and request for one or more grants to transmit the data.

[0267] A WTRU may be configured for BSR and related signaling. To support BSR for informing the network about the data in the WTRU buffer, the WTRU may receive assistance information and / or configurations that may be explicitly provided via dedicated signaling (e.g., RRC signaling, MAC CE) and / or broadcast in system information of both. In examples, the WTRU may be configured with BSR parameters via any one or more of the signaling types discussed herein.

[0268] The WTRU may be configured with BSR parameters via RRC signaling (e.g., as part of the BSR- Config IE used to configure buffer status reporting). The WTRU may be configured with BSR parameters via MAC CE (e.g., for faster (re)configuration of the BSR configuration, switch to a different BSR configuration for reporting DSUs). The WTRU may be configured with BSR parameters via DCI (e.g., for faster (re)configuration of the BSR configuration, switch to a different BSR configuration for reporting DSUs).

[0269] The WTRU may be configured with multiple types of BSR including, without limitation: Regular BSR; Periodic BSR; Padding BSR; and / or Pre-emptive BSR. Pre-emptive BSR may convey the expected data rather than the data buffered (e.g., based on upcoming data in the WTRU buffer) to reduce UL scheduling latency.

[0270] As part of the configuration, the WTRU may receive one or more thresholds from the network, including without limitation one or more of the thresholds discussed herein.

[0271] As part of the configuration, the WTRU may receive thresholds corresponding to volume of UL data in the WTRU buffer and / or one or more DSU(s) and / or one or more sets of PDUs. In examples, the WTRU may be configured to trigger BSR when the data volume in a DSU exceeds the preconfigured volume threshold.

[0272] As part of the configuration, the WTRU may receive thresholds corresponding to the number of PDUs in the WTRU buffer and / or in the DSU and / or in the set. In examples, the WTRU may be configured to trigger BSR when the number of PDUs in a DSU in the WTRU buffer exceeds the preconfigured number of PDUs threshold.

[0273] As part of the configuration, the WTRU may receive thresholds corresponding to priority of UL data in the WTRU buffer (e.g., priority of set of PDUs (e.g., corresponding to a bitrate); and / or priority of DSU).In examples, the WTRU may be configured to trigger BSR when the priority of the UL DSU in the WTRU buffer exceeds the preconfigured priority threshold.

[0274] As part of the configuration, the WTRU may receive thresholds corresponding to the time bound associated with UL data in the WTRU’s buffer (e.g., time bound associated with DSU). In examples, the threshold may correspond to a time window within the time bound (e.g., 5 ms prior to expiry of the time bound associated with the DSU and / or 5 ms following the expiry of the time bound associated with the DSU) whereby constituent data (e.g, PDUs, PDU sets, ePDU sets) of the DSU not transmitted within the threshold (e.g, time window) may be considered as ‘failed’ transmission(s).

[0275] As part of the configuration, the WTRU may receive thresholds corresponding to bitrate associated with UL data in WTRU buffer. In examples, the thresholds may correspond to a minimum bitrate associated to a PDU set and / or DSU. In examples, the thresholds may correspond to a maximum bitrate associated to a PDU set and / or DSU. In examples, the thresholds may correspond to an average bitrate associated to a PDU set and / or DSU.

[0276] The WTRU may send a request for assistance i nformation / (re)config uration via any one or more of the following: UCI, SR, RACH messaging (e.g., MSG A, MSG 1 , MSG 3, MSG 5, etc.), PUSCH, MAC CE and / or RRC signaling.

[0277] The WTRU may report any one or more of the following items as part of the BSR. The WTRU may report the Amount of data in WTRU uplink buffer as part of the BSR. The WTRU may report the Result of the data volume calculation as part of the BSR. The WTRU may report the Upcoming data in WTRU buffer as part of the BSR. In examples, the first PDU and / or header in a DSU may include information on the total size of the DSU and / or total number of PDUs in the DSU. In examples, the first PDU and / or header in a set of PDUs may include information on the total size of the set and / or total number of PDUs in the set. The WTRU may report the number of DSUs with data to be transmitted in the UL as part of the BSR. The WTRU may report the amount of data in the one or more DSUs as part of the BSR. The WTRU may report the number of PDUs in the one or more DSUs as part of the BSR. The WTRU may report the number of sets with PDUs in the one or more DSUs as part of the BSR. The WTRU may report the amount of data in sets of PDUs in the one or more DSUs as part of the BSR. The WTRU may report metadata on data and / or upcoming data in WTRU buffer as part of the BSR. In examples, metadata may include one or more of the following: size, number of PDUs in DSU and / or set of PDUs, priority of set of PDUs within DSU, priority of DSU, time bound associated with DSU, bitrate(s) associated with DSU, bitrate(s) associated with set(s) of PDUs in the DSU, etc.

[0278] The WTRU may send a BSR to the network, including but not limited to, following any one or more of the circumstances and / or events discussed herein.

[0279] The WTRU may send a BSR to the network when uplink data becomes available to the MAC entity. The WTRU may send a BSR to the network when an amount of uplink data available to the MAC entity exceeds a threshold.

[0280] The WTRU may send a BSR to the network when uplink data for a logical channel (e.g., belonging to an LCG) becomes available to the MAC entity and this uplink data belongs to a logical channel with higher priority than the priority of any logical channel including available UL data. The WTRU may send a BSR to the network when UL data, for a logical channel (e.g., which belongs to an LCG), becomes available to the MAC entity and none of the logical channels (e.g., which belong to an LCG) includes any available UL data. The WTRU may send a BSR to the network when UL resources are allocated, and number of padding bits is equal to or larger than the size of the BSR MAC CE plus its subheader. In such a case the BSR may be referred to as 'Padding BSR'. The WTRU may send a BSR to the network followinga data volume calculation. The WTRLI may send a BSR to the network following a data volume calculation when the data volume exceeds a preconfigured threshold.

[0281] The WTRU may send a BSR to the network following a QoE and / or change in QoE. In examples, a QoE change and / or change in QoE may occur via QoE measurement at the WTRU (e.g., one or more QoE measurement collection jobs can be activated at the WTRU per service type by the NW / gNB / OAM / CN, and each QoE measurement configuration is uniquely identified by a QoE reference). In examples, a QoE change and / or change in the QoE may occur via an indication from the application.

[0282] The WTRU may send a BSR to the network periodically. In examples, the periodicity may be configured and / or triggered by the expiry of a timer (e.g., when periodicBS R-Timer expires).

[0283] The WTRU may send a BSR to the network on expiry of a timer. In examples, the expiry of a timer with timer value corresponding to the time bound associated with a DSU may trigger the WTRU to send a BSR to the network. In examples, expiry of a timer with timer value corresponding to a value t ms defined as a function of the time bound associated with a DSU may trigger the WTRU to send a BSR to the network. The value of t may be smaller than the time bound value. In examples, expiry of periodicBSR- Timer and / or retxBSR-Timer may trigger the WTRU to send a BSR to the network.

[0284] The WTRU may send a BSR to the network when one DSU has data to be transmitted in the UL. The WTRU may send a BSR to the network when a number of DSUs larger than a preconfigured threshold have data to be transmitted in the UL. The WTRU may send a BSR to the network when the data volume in one DSU is larger than a preconfigured threshold. The WTRU may send a BSR to the network when the collective data volume in more than one DSU is larger than a preconfigured threshold. The WTRU may send a BSR to the network when a number of sets of packets associated with one or more DSUs larger than a preconfigured threshold have data to be transmitted in the UL. The WTRU may send a BSR to the network when the data volume associated with one or more sets of PDUs in one or more DSUs is larger than a preconfigured threshold.

[0285] Transmitting a BSR MAC CE to the network may help to meet the minimum QoE when transmitting uplink data and / or adapt / probe for an increase or a decrease in the QoE level.

[0286] The WTRU may be configured with any one or more of the following BSR MAC CE formats: Short BSR; Long BSR; Short Truncated BSR; Long Truncated BSR; and / or New BSR for reporting DSUs.

[0287] The fields in the BSR MAC CE may include one or more of the following: DSU type (e.g., DSU type ID); DSU (e.g., DSU ID); LCG ID; LCG; Buffer size and / or amount of buffered / expected data per DSUor type thereof; One field / bit (e.g., in short BSR MAC CE) to indicate to use the same BSR table as previous transmission(s); One field to enable the probing mechanism.

[0288] In examples, the field used to enable the probing mechanism may report that successful transmission of data (e.g., implicitly) conveys a change in QoE level (e.g., an increase in QoE level).

[0289] In examples, the field used to enable the probing mechanism may report that unsuccessful transmission of data conveys a change in QoE level (e.g., a decrease in QoE level to satisfy the minimum PBR).

[0290] The WTRU may be configured with one or more BSR table(s) which may include any one or more of the following. A BSR table(s) may include Buffer size levels (e.g., in bytes) for different size buffer size fields. In examples, a buffer size level may comprise a 5-bit buffer size field allowing the WTRU to report data in 1 LCG. In examples, an index of 1 may correspond to a BS value of less than or equal to 10 bytes in the LCG indicated by the 3-bit LCG ID field. In examples, a buffer size level may comprise an 8-bit buffer size field allowing the WTRU to report data in up to 8 LCGs. A BSR table(s) may include Buffer size levels (e.g., in bytes) for different DSUs. A BSR table(s) may include Buffer size levels (e.g., in bytes) for different sets of PDUs within a DSU.

[0291] A WTRU may be triggered to send a Scheduling request. In examples, a WTRU may be triggered to send a Scheduling request when WTRU has some data to transmit but no UL grant from the NW to transmit the data. In examples, a WTRU may be triggered to send a Scheduling request periodically with periodicity configured by the NW (e.g., in RRC) regardless of whether it has data in that moment to transmit. In examples, a WTRU may be triggered to send a Scheduling request when a BSR (e.g., regular BSR) is triggered and WTRU does not have uplink resources for transmission of at least a BSR (e.g., regular BSR). In examples, a WTRU may be triggered to send a Scheduling request by any of the triggers applicable for triggering BSR (e.g., when uplink data becomes available to the MAC entity, when amount of uplink data available to the MAC entity exceeds a preconfigured threshold, etc.).

Claims

CLAIMS:1 . A wireless transmit / receive unit (WTRU) comprising a processor configured to: receive configuration information that indicates a set of quality of service (QoS) parameters associated with a data scheduling unit (DSU); determine that a first protocol data unit (PDU) is associated with the DSU, based on a QoS parameter associated with the first PDU; and transmit the first PDU in accordance with the DSU.

2. The WTRU of claim 1 , wherein the processor is further configured to: determine that a second PDU is associated with the DSU, based on a QoS parameter associated with the second PDU; and transmit the second PDU in accordance with the DSU.

3. The WTRU of claim 1 , wherein the processor is further configured to: determine that a second PDU is dependent on the first PDU, based on an indication of inter-packet dependency comprised in the first PDU or the second PDU.

4. The WTRU of claim 3, wherein the indication of inter-packet dependency indicates that the second PDU should be transmitted only after the first PDU has been successfully transmitted.

5. The WTRU of any of claims 1 to 4, wherein the processor is configured to associate a plurality of PDUs with the DSU; and multiplex the plurality of PDUs in a transport block based on the configuration information.

6. The WTRU of any of claims 1 to 5, wherein the processor is configured to: determine a period based on frame timing; and modify a QoS parameter of the set of QoS parameters associated with the DSU during the period, based on a change in a level of resource allocation associated with the period.

7. The WTRU of claim 6, wherein the QoS parameter that the processor is configured to modify is one of a priority, a target bitrate, a latency parameter, or a reliability parameter.

8. The WTRU of any of claims 1 to 7, wherein the DSU is associated with a plurality of PDUs based on (i) a priority associated with each PDU of the plurality of PDUs being within a configured range of priorities, or (ii) a target bitrate associated with each PDU of the plurality of PDUs being within a configured range of bitrates.

9. The WTRU of claim 8, wherein each PDU of the plurality of PDUs is associated with a same priority, the same priority being within the configured range of priorities.

10. The WTRU of any of claims 1 to 9, wherein the DSU is associated with a QoS type, wherein the QoS type corresponds to best-effort service, real-time service, immersive service, sensory data, or control signaling.

11. A method to be performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information that indicates a set of quality of service (QoS) parameters associated with a data scheduling unit (DSU) determining that a first protocol data unit (PDU) is associated with the DSU, based on a QoS parameter associated with the first PDU; and transmitting the first PDU in accordance with the DSU.

12. The method of claim 11 , further comprising: determining that a second PDU is associated with the DSU, based on a QoS parameter associated with the second PDU; and transmitting the second PDU in accordance with the DSU.

13. The method of claim 11 , further comprising: determining that a second PDU is dependent on the first PDU, based on an indication of interpacket dependency comprised in the first PDU or the second PDU.

14. The method of claim 13, wherein the indication of inter-packet dependency indicates that the second PDU should be transmitted only after the first PDU has been successfully transmitted.

15. The method of any of claims 11 to 14, further comprising: associating a plurality of PDUs with the DSU; and multiplexing the plurality of PDUs in a transport block based on the configuration information.

16. The method of any of claims 11 to 15, further comprising: determining a period based on frame timing; and modifying a QoS parameter of the set of QoS parameters associated with the DSU during the period, based on a change in a level of resource allocation associated with the period.

17. The method of claim 16, wherein the QoS parameter that is modified is one of a priority, a target bitrate, a latency parameter, or a reliability parameter.

18. The method of any of claims 11 to 17, wherein the DSU is associated with a plurality of PDUs based on (i) a priority associated with each PDU of the plurality of PDUs being within a configured range of priorities, or (ii) a target bitrate associated with each PDU of the plurality of PDUs being within a configured range of bitrates.

19. The method of claim 18, wherein each PDU of the plurality of PDUs is associated with a same priority, the same priority being within the configured range of priorities.

20. The method of any of claims 11 to 19, wherein the DSU is associated with a QoS type, wherein the QoS type corresponds to best-effort service, real-time service, immersive service, sensory data, or control signaling.

Images