Method and apparatus for triggering buffer status reporting based on changes in sensing metrics
By determining the percentage of buffer data based on the QoS, CBR, or WTRU sensing type of the flexible radio bearer in a wireless communication system, the accuracy problem of the BSR triggering mechanism is solved, and data transmission efficiency is improved.
Patent Information
- Application Number
- CN202480024762.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-02-14
- Filing Date
- 2024-02-14
- Publication Date
- 2025-11-21
AI Technical Summary
In existing wireless communication systems, the buffer status report (BSR) triggering mechanism is difficult to accurately reflect the amount of data carried by the flexible radio, resulting in low data transmission efficiency.
Based on the Quality of Service (QoS) of the Flexible Radio Bearer, the Sidelink Channel Busy Rate (CBR), or the WTRU sensing type, determine the percentage of data in the buffer and send a Buffer Status Report (BSR) when the percentage is less than 100% to optimize data reporting.
It improves the accuracy and efficiency of data transmission and optimizes the data transmission process in wireless communication systems.
Smart Images

Figure CN121002984A_ABST
Abstract
Description
[0001] Cross Reference to Related Applications This application claims the benefit of U.S. Provisional Application No. 63 / 445,578, filed February 14, 2023, the contents of which are incorporated by reference herein. SUMMARY
[0002] A wireless transmit / receive unit (WTRU) and method implemented therein are described. The WTRU is in mode 2 and is configured with a flexible radio bearer configured with a Uu logical channel and a sidelink logical channel. Based on a trigger for transmitting a buffer status report (BSR) for one or more buffers containing an amount of data, the WTRU determines a percentage of the amount of data stored in the one or more buffers to report for the Uu logical channel of the flexible radio bearer based on one or more of a quality of service (QoS) configured for the flexible radio bearer, a sidelink channel busy ratio (CBR), or a type of sensing the WTRU is configured to perform. The WTRU transmits the BSR reporting the determined percentage of the data in the one or more buffers based on the determined percentage being less than one hundred percent. BRIEF DESCRIPTION OF DRAWINGS
[0003] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings wherein like reference numbers indicate similar elements and wherein: FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented; FIG. 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used within the communications system 100 of FIG. 1A illustrated in FIG. 1; FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used within the communications system 100 of FIG. 1A illustrated in FIG. 1; FIG. 1D is a system diagram illustrating a further example RAN and a further example CN that can be used within the communications system 100 of FIG. 1A illustrated in FIG. 1; FIG. 2 is a schematic diagram of a user plane protocol stack of Layer 2 (L2) WTRU-to-Network Relay; FIG. 3 is a schematic diagram of a control plane protocol stack of L2 WTRU-to-Network Relay; FIG. 4is a schematic diagram of a protocol view for split bearer for dual connectivity (DC); FIG. 5 is a schematic diagram of a protocol stack for carrier aggregation (CA); FIG. 6 is a schematic diagram of an example protocol stack for multi-path. There can be some issues with directly using the carrier aggregation model for multi-path; FIG. 7 is a flowchart of an example method for reporting BSR for a WTRU configured in mode 2 with a flexible bearer configured with a Uu logical channel (or direct path) and a sidelink logical channel (or relay path); FIG. 8 is a flowchart of an example method for triggering a Uu BSR based on a change in sensing results since the last reported BSR, implemented in a WTRU configured in mode 2 with multi-path; FIG. 9 is a flowchart of an example method for triggering a dedicated SR based on the results of events on SL, implemented in a WTRU; and FIG. 10 is a flowchart of an example method for triggering a BSR based on the amount of data received at a split bearer, implemented in a WTRU configured in mode 2 with multi-path on SL and configured with at least one radio bearer that can be sent on both paths. DETAILED DESCRIPTION
[0004] FIG. 1A is a schematic diagram illustrating an example communications system 100 in which one or more disclosed embodiments can be implemented. The communications system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 can employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform spread orthogonal frequency division multiplexing (ZT-UW-DFT-S-OFDM), unique-word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.
[0005] As FIG. 1AAs shown, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which can be referred to as a "station" (STA)) can be configured to transmit and / or receive wireless signals, and can 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 (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot or other wireless devices operating in an industrial and / or an automated processing chain context), a consumer electronics device, a device operating on a commercial and / or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, 102d can be interchangeably referred to as a UE.
[0006] The communication system 100 can also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b can be any type of device configured to wirelessly interface 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, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b can be a base transceiver station (BTS), a Node-B, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation Node-B, such as gNode B (gNB), a new radio (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 can include any number of interconnected base stations and / or network elements.
[0007] The base stations 114a can be part of the RAN 104, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base stations 114a and / or the base stations 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrums. A cell can provide coverage for a wireless service to a particular geographic area, which can be relatively fixed or can change over time. The cell can further be divided into cell sectors. For example, the cell associated with a base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, one for each sector of the cell. In an embodiment, the base station 114a can employ multiple-input multiple-output (MIMO) technology and can use multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.
[0008] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can employ any suitable radio access technology (RAT).
[0009] More specifically, as noted above, the communications system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 116 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed Uplink (UL) Packet Access (HSUPA).
[0010] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).
[0011] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as NR Radio Access, which can establish the air interface 116 using NR.
[0012] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE wireless access and NR wireless access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).
[0013] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can 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 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
[0014] FIG. 1AThe base station 114b in such a scenario can be a wireless router, Home Node B, Home eNode B, or access point, for example, and can utilize any suitable RAT for facilitating wireless connectivity access in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106. FIG. 1A
[0015] The RAN 104 can be in communication with the CN 106, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1C, the RAN 104 and / or the CN 106 can be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which can employ a NR radio technology, the CN 106 can also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology. FIG. 1A
[0016] The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide infrastructure for the provision of voice telephony. The Internet 110 can include a global system of interconnected computer networks and devices that use the Transmission Control Protocol (TCP) / Internet Protocol (IP) suite of protocols to facilitate communications and exchange of data between devices. The networks 112 can include wired or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include another CN managed by a different network
[0017] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 can include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102a, 102b, 102c, 102d can include a transceiver 150a FIG. 1A The WTRU 102c shown in Figure 1C can be configured to communicate with the base station 114a using a cellular-based radio technology and the base station 114b using an IEEE 802 radio technology.
[0018] FIG. 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B The WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
[0019] The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While FIG. 1B The processor 118 and the transceiver 120 are depicted as separate components, but can be integrated together in an electronic package or chip.
[0020] The transmit / receive element 122 can be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 can be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.
[0021] Although the transmit / receive element 122 is depicted in the WTRU 102 FIG. 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
[0022] The transceiver 120 can be configured to modulate information to be transmitted by the transmit / receive element 122 and to demodulate information received by the transmit / receive element 122. As indicated above, the WTRU 102 can be a multi-mode device. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.
[0023] The processor 118 of the WTRU 102 can be coupled to, and can receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 can access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
[0024] The processor 118 can receive power from the power source 134, and can be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 can be any suitable device for powering the WTRU 102. For example, the power source 134 can include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
[0025] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or
[0026] The processor 118 can further be coupled to other peripherals 138 that can 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 can 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 an augmented reality (VR / A R) device, an activity tracker, and the like. The peripherals 138 can include one or more sensors. The sensors can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, and the like.
[0027] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals associated with the particular subframe can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and / or substantially eliminate self-interference and / or cross- interference due to concurrent transmission and reception. In an embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all signals associated with the particular subframe is time divided.
[0028] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 employs an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.
[0029] The RAN 104 can include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 can include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c can implement MIMO technology. Thus, the eNode-B 160a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.
[0030] Each of the eNode-Bs 160a, 160b, 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown, the eNode-Bs 160a, 160b, 160c can communicate with one another over an X2 interface. FIG. 1C
[0031] FIG. 1C The CN 106 can include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166, as shown. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.
[0032] The MME 162 can be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 can provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.
[0033] The SGW 164 can be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
[0034] The SGW 164 can be connected to the PGW 166, which can provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
[0035] The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide infrastructure for the provision of voice, video, and / or data services to users. The CN 106 can include IP gateways, such as an IP multimedia subsystem (IMS), that serve as an interface between the CN 106 and the PSTN 108. The other networks 112 can include other wired or wireless networks that are owned and / or operated by other service providers.
[0036] Although WTRUs are described in FIG. 1A to FIG. 1D representative embodiments as wireless terminals, it is contemplated that in certain representative embodiments such a terminal can use (e.g., temporarily or permanently) a wired communication interface with the communication network.
[0037] In representative embodiments, the other networks 112 can be a WLAN.
[0038] A WLAN in Infrastructure Basic Service Set (BSS) mode can have an Access Point (AP) which can be used by one or more stations (STAs) associated with the AP to obtain connectivity to each other or to external networks outside the BSS. The AP can have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS can arrive through the AP and can be delivered to the STAs by the AP. Traffic that originates from STAs to destinations outside the BSS can be sent to the AP to be delivered to respective destinations depending on the traffic characteristics and network conditions. For example, if the traffic is for an Internet of Things (IoT) service, the traffic can be sent to the AP to be delivered to the IoT server. The AP can be an evolved-legacy AP (eAP) that is configured to support legacy STAs and / or non-legacy STAs (e.g., High Efficiency (HE) STAs). The eAP can be configured to support downlink (DL) multi-user multiple input multiple output (MU MIMO), downlink OFDMA, uplink (UL) MU MIMO, and / or uplink OFDMA.
[0039] When using an 802.11 ac infrastructure mode of operation or similar, the AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example, in 802.11 systems. For CSMA / CA, a STA including the AP (e.g., each STA) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. Only one STA can transmit in a given BSS at any given time.
[0040] High Throughput (HT) STAs can use 40 MHz wide channels for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.
[0041] Very High Throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining contiguous 20MHz channels. A 160MHz channel can be formed by combining 8 contiguous 20MHz channels, or by combining two non-contiguous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can be passed through a segment parser that can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be done on each stream separately. The streams can be mapped on to the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Medium Access Control (MAC).
[0042] Sub-1 GHz modes of operation are supported by 802.11af and 802.11ah. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11η and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / Machine Type Communication (MTC) such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, e.g., limited capabilities, including support for (e.g., only support) certain and / or limited bandwidths. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).
[0043] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11η, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA among all STAs operating in the BSS that supports the smallest bandwidth operating mode. In the example of 802.11ah, for a STA (e.g., MTC type device) that supports (e.g., only supports) 1 MHz mode, the primary channel can be 1 MHz wide, even though the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, e.g., due to a STA (which only supports 1 MHz operating mode) transmitting to the AP, then all available frequency bands can be considered busy, even though most of the available frequency bands are still idle.
[0044] In the United States, the available frequency bands that 802.11ah can use are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6 MHz to 26 MHz.
[0045] FIG. 1D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As
[0046] The RAN 104 can include gNBs 180a, 180b, 180c, although it will be appreciated that the RAN 104 can include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c can implement MIMO technology. For example, gNBs 180a, 108b can utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c can implement carrier aggregation technology. For example, the gNB 180a can transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum while the remaining component carriers can be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).
[0047] The WTRUs 102a, 102b, 102c can use transmission associated with a scalable numerology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary from different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or lasting different lengths of absolute time).
[0048] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can use signals
[0049] Each of the gNBs 180a, 180b, 180c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, networking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and / or the like. As shown, the gNBs 180a, 180b, 180c can communicate with one another over an Xn interface. FIG. 1D As shown, the gNBs 180a, 180b, 180c can be in communication with the AN 180a, 180b, 180c over an N2 interface.
[0050] FIG. 1DThe illustrated CN 106 can 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 the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.
[0051] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can be responsible for authenticating WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing the WTRU 102a, 102b, 102c registration area, terminating non-access stratum (NAS) signaling, mobility management, and the like. Network slicing can be used by the AMF 182a, 182b to customize CN support for WTRUs 102a, 102b, 102c based on the type of service being accessed by the WTRU 102a, 102b, 102c. For example, different network slices can 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 MTC access, and the like. The AMF 182a, 182b can provide control plane functions to access the RAN 104 and to access other RANs (not shown) using other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.
[0052] The SMF 183a, 183b can be connected to AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b can also be connected to UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 182b. The SMF 183a, 183b can perform other functions, such as managing and allocating IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. The PDU session type can be IP-based, non-IP based, Ethernet-based, and the like.
[0053] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which can provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.
[0054] The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telecommunication networks that can provide
[0055] In view of FIG. 1A to FIG. 1D And FIG. 1A to FIG. 1D The functions of the eNode-B 160a, 160b, 160c, the RNC 142a, 142b, the MME 162, the SGW 164, the PGW 166, the gNBs 180a, 180b, 180c, the AMF 182a, 182b, the UPF 184a, 184b, the SMF 183a, 183b, the DN 185a, 185b, and / or any other device described herein can be performed by one or more emulation devices (not shown). The emulation device can be an apparatus that is configured to emulate one or more of the functions described herein. For example, the emulation device can be used to test other devices and / or to emulate a network and / or WTRU functions.
[0056] The one or more emulation devices can perform the one or more, or all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices can be utilized in a testing environment to test system functionality as part of integration testing, system testing, developer testing, and the like.
[0057] The one or more emulation devices can perform the one or more, or all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices can be utilized in a testing environment to test system functionality as part of integration testing, system testing, developer testing, and the like.
[0058] FIG. 2 is a diagram of a Layer 2 (L2) user plane protocol stack 200 of a WTRU-to-Network Relay 400. FIG. 3 is a diagram of a Layer 2 (L2) control plane protocol stack 300 of a WTRU-to-Network Relay 400. In FIG. 2 and FIG. 3 In the example shown, for both the user plane 200 and the control plane 300, a Sidelink Relay Adaptation Protocol (SRAP) sublayer 202, 304 sits above a Radio Link Control (RLC) sublayer 204, 304 at both the PC5 interface 220 and the Uu interface 230. Uu Service Data Adaptation Protocol (SDAP) 210, Packet Data Convergence Protocol (PDCP) 212, 213, and Radio Resource Control (RRC) 310 can terminate between the L2 U2N Remote WTRU 500 and a base station 600 (e.g., gNB), while SRAP 202, 302, RLC 204, 304, MAC 206, 306, and Physical Layer (PHY) 208, 308 can terminate in each hop using the link between the L2 U2N Remote WTRU 500 and the L2 U2N Relay WTRU 400, as well as the link between the L2 U2N Relay 400 WTRU and the base station 600.
[0059] For L2 U2N relay 400, SRAP sublayer 202 over PC5 hop 220 is only used for bearer mapping purposes. For relaying messages from L2 U2N remote WTRU 500 over broadcast control channel (BCCH) and paging control channel (PCCH), SRAP sublayer 303 is not present over PC5 hop 320. For messages from L2 U2N remote WTRU 500 over SRBO, SRAP header is not present over PC5 hop 220, but SRAP header is present over Uu hop 230 for both DL and UL.
[0060] A sidelink (SL) WTRU can be configured to operate in mode 1 or mode 2. In mode 1, a WTRU can be scheduled by the network over the sidelink, e.g., using downlink control information (DCI) for sidelink grant. In mode 2, a WTRU can perform resource selection and / or reselection to schedule sidelink resources.
[0061] Mode 2 resource selection can be further characterized by potential use of sensing. A WTRU that supports sensing can use sensing results or an indication of sidelink control information (SCI) transmissions (which are pre-reserved resources) over a period of time to select a set of resources for transmission. Resource selection can include determining a set of available resources based on sensing results and comparing observed RSRP of SCI to a threshold value, which depends on the priority of the transmission to be made during sensing and the priority of transmissions announced by other SCI. For a single transmission, or for multiple periodic transmissions announced by pre-reservation indication in SCI, a WTRU can randomly select resources for transmission if a certain percentage of resources are deemed available. When there are insufficient resources available to perform random selection, a WTRU can increase its availability threshold, e.g., by 3 dB, until a sufficient amount of resources are deemed available.
[0062] Mode 2 resource selection can be further subject to congestion control. In mode 2, a WTRU can measure channel busy ratio (CBR). Based on CBR, a WTRU can be configured with some transmission limits, such as maximum number of retransmissions, modulation coding scheme (MCS), and / or maximum number of sub-channels, to avoid further increase in congestion when CBR is high. Congestion parameters can be further conditioned on the priority of transmissions, such that high priority transmissions can be subject to less congestion control limits.
[0063] Enhancements to NR SL relaying can continue in Release 18. One of the features that can be included in the discussion is support for multi-path with relaying, where a remote WTRU can connect to the network via a direct path and an indirect path, which has the potential to improve reliability / robustness as well as throughput. Such multi-path relaying can also be used for WTRU aggregation, where a WTRU can connect to the network via a direct path using a non-standardized WTRU-WTRU interconnection and via another WTRU. WTRU aggregation can provide applications that require high UL bitrates on 5G terminals in cases where the ordinary WTRU is too limited by the UL WTRU transmission power to reach the required bitrates, especially at the edge of the cell. Additionally, WTRU aggregation can improve the reliability and stability of the service, as well as reduce its latency. In such cases, if the channel conditions of the terminal are deteriorating, another terminal can be used to compensate for the instability of the traffic performance due to the channel condition changes.
[0064] FIG. 4 is a schematic diagram of a protocol view for a split bearer 700 for dual connectivity (DC). In DC, a WTRU 702 can be served by two nodes 704 and 706, each of which includes a set of cells referred to as a master cell group (MCG) and a secondary cell group (SCG). For example, a bearer can be associated with either the MCG or the SCG only, or can be configured as a split bearer, as shown in FIG. 4 .
[0065] As with any bearer, and as shown in the example in FIG. 4 , the WTRU 702 will have one PDCP entity 708 associated with it. On the network side, a peer PDCP entity 710 terminates at one of the gNBs (704 in FIG. 4 ), which can be the master gNB or the secondary gNB. In the DL, the CN can send data to the gNB 704 where the PDCP terminates, and this can depend on whether the network sends the data directly to the WTRU 708 via the link between the gNB 704 and the WTRU 702 or forwards the PDCP PDUs to the gNB 706, such as via the Xn interface. The gNB will send the data to the WTRU via its own link to the WTRU.
[0066] In the UL, the WTRU 702 can be configured with one of the paths as the primary path and the other as the secondary path. A threshold, often referred to as the UL split buffer threshold, can also be configured. If the UL buffer size for this bearer is less than the threshold, the PDCP 708 will only push data to the RLC associated with the primary path. However, if the buffer size becomes greater than the threshold, the WTRU can push data to either path (e.g., to the left to the WTRU 500, as shown inFIG. 3 Figure 8 shows an example of a protocol stack 800 for carrier aggregation (CA). In CA, data in a bearer 502 can be transmitted in any carrier. Logical channels at the MAC layer 504 can transmit data in either of the two carriers in a flexible manner, or can be configured with duplicated logical channels to allow CA duplication with carrier restrictions.
[0067] FIG. 5 Figure 8 shows an example of a protocol stack 800 for carrier aggregation (CA). In CA, data in a bearer 502 can be transmitted in any carrier. Logical channels at the MAC layer 504 can transmit data in either of the two carriers in a flexible manner, or can be configured with duplicated logical channels to allow CA duplication with carrier restrictions.
[0068] Triggers for Uu and SL buffer status reporting (BSR) can be similar to each other. For example, a BSR can be triggered if for the activated cell group, any of the following events occurs: (1) uplink data belonging to a logical channel group (LCG) becomes available to the MAC entity 504 and either (a) the UL data belongs to a logical channel with a higher priority than any logical channel (that belongs to any LCG) containing available UL data, or (b) no logical channel belonging to an LCG contains any available UL data, in which case the BSR can be referred to herein as a regular BSR A; (2) UL resources are allocated and the number of padding bits is equal to or larger than the size of a BSR MAC control element (CE) plus its subheader, in which case the BSR can be referred to herein as a padding BSR; and / or (3) a timer expires, in which case the BSR can be referred to herein as a periodic BSR. When regular BSR trigger events occur for multiple logical channels simultaneously, each logical channel can trigger a separate regular BSR. periodicBSR - Timer Triggers for Uu and SL buffer status reporting (BSR) can be similar to each other. For example, a BSR can be triggered if for the activated cell group, any of the following events occurs: (1) uplink data belonging to a logical channel group (LCG) becomes available to the MAC entity 504 and either (a) the UL data belongs to a logical channel with a higher priority than any logical channel (that belongs to any LCG) containing available UL data, or (b) no logical channel belonging to an LCG contains any available UL data, in which case the BSR can be referred to herein as a regular BSR A; (2) UL resources are allocated and the number of padding bits is equal to or larger than the size of a BSR MAC control element (CE) plus its subheader, in which case the BSR can be referred to herein as a padding BSR; and / or (3) a timer expires, in which case the BSR can be referred to herein as a periodic BSR. When regular BSR trigger events occur for multiple logical channels simultaneously, each logical channel can trigger a separate regular BSR.
[0069] A WTRU can trigger resource selection and / or reselection in mode 2 based on the following. If a transmission (TX) resource selection and / or reselection check procedure is triggered on a selected resource pool for a sidelink procedure, the MAC entity can: (1) if the physical sidelink control channel (PSSCH) and second-stage SCI on the PSSCH for all transmissions of a MAC PDU for one or more any selected sidelink grant are not within a SL discontinuous reception (DRX) active time with a destination having data to transmit; or (2) if SL_RESOURCE_RESELECTION_COUNTER = 0 and when SL_RESOURCE_RESELECTION_COUNTER When equal to 1, the MAC entity randomly selects a value in the interval [0, 1] with equal probability that is higher than the RRC in sl-ProbResourceKeepconfigured by RRC or reconfigured; or (3) if there is no selected sidelink grant on the selected resource pool; or if during the last second, the MAC entity has not performed any transmission or retransmission on any resource indicated in the selected sidelink grant; or (4) if sl-ReselectAfter is configured, and the number of consecutive unused transmission opportunities on the resources indicated in the selected sidelink grant (which increments by 1 when no resource of the selected sidelink grant is used within the resource reservation interval) is equal to sl-ReselectAfter ; or (5) if the selected sidelink grant cannot accommodate the RLC SDU by using the maximum allowed MCS configured by RRC in sl-MaxMCS-PSSCH associated with the selected MCS table, and the WTRU chooses not to segment the RLC SDU; or (6) if the (multiple) transmission(s) with the selected sidelink grant cannot meet the remaining PDB of data in the logical channel, and the MAC entity chooses not to perform the (multiple) transmission(s) corresponding to a single MAC PDU: clear the selected sidelink grant associated with the sidelink process, if available, and trigger TX resource selection or reselection. Whether to perform segmentation or sidelink resource reselection if the selected sidelink grant in (5) cannot accommodate the RLC SDU can be up to WTRU implementation. Whether to perform one or multiple transmissions corresponding to a single MAC PDU, or sidelink resource selection if the remaining PDB is not met in (6) can be up to WTRU. Whether to trigger TX resource selection or reselection can be up to WTRU implementation, e.g., due to latency requirements of the triggered MAC CE.
[0070] A possible configuration of a WTRU is to perform SL transmission to a relay WTRU while being configured in mode 2. In this case, the WTRU can be scheduled over Uu by the network, but can perform its own scheduling over sidelink. For a WTRU’s bearers, bearers configured only on Uu path or SL path are clear whether the WTRU should report BSR to the network. However, it can be less clear how to handle SR / BSR reporting for data associated with flexible bearers, especially regarding how much data to report to the network in Uu BSR, and thus how the triggers for Uu SR / BSR can interact with the WTRU’s autonomous scheduling of these bearers over SL in mode 2.
[0071] In DC, PDCP can determine whether to push data in MCG or SCG entirely based on buffer state, and this can be determined by the WTRU implementation to determine which RL channel to push how much data. In multipathing for remote WTRUs, it may be desirable to allow a more flexible approach where data can be flexibly routed to either path based on authorized availability (similar to carrier aggregation). However, directly applying the carrier aggregation model to multipathing can present some problems. Specifically, it may be difficult to define logical channels where data available on such logical channels can be flexibly sent to SL (relay) paths or Uu (direct paths), because logical channels in Uu and logical channels on sidelinks may have very different configurations in RRC. Instead, it is assumed that a more flexible (CA-based) scheduling multipathing protocol stack can use, for example... FIG. 6 The architecture shown.
[0072] FIG. 6 This is a schematic diagram of the example protocol stack 900 for multipathing. FIG. 6 In the example shown, a single RLC entity 602, capable of flexibly sending data via either the SL or Uu path, is configured with two separate logical channels 604 and 606. The SL logical channel 604 can be used for data transmission via the indirect path, and the Uu logical channel 606 can be used for data transmission via the direct path. The Uu logical channel 606 can be configured or function like a conventional Uu logical channel, while the SL logical channel 604 can be configured and function like an SL logical channel. Replication can also be supported by having the RLC entity 602 send PDUs to both paths and both logical channels to send data on their respective interfaces (Uu and SL). In the embodiments described herein, the following terminology may be used, taking into account the mapping to... FIG. 6 The partitioned DRB in the illustrated architecture can actually include two separate logical channels, which is not the case for carrier aggregation where a single logical channel is assumed. The Uu RBS (e.g., for strict latency) can be configured to transmit data via Uu. The sidelink RBS (e.g., for long-latency data) can be configured to transmit data via a sidelink. Flexible RBs, such as... FIG. 6 The flexible RB 608 in the system (e.g., for medium latency data and high reliability) can be configured to send data via Uu or a side link based on specific conditions.
[0073] It is assumed that the embodiments described herein are primarily applicable to flexible radio bearers, such as FIG. 6 As shown, they can dynamically send data via any path without requiring RRC reconfiguration. However, without loss of generality, the embodiments can also be applied to Uu RBs and sidelink RBs.
[0074] FIG. 7 is a flowchart 750 of an example method of reporting a BSR for a WTRU configured with a flexible bearer in mode 2, the flexible bearer configured with a Uu logical channel (or direct path) and a sidelink logical channel (or relay path). In FIG. 7 In the example shown, the WTRU determines an amount or percentage of buffered data to report for a Uu BSR for a multipath radio bearer based on at least one sensing metric (752). The sensing metric can be or include one or more of a QoS of the bearer, a SL CBR, and / or a sensing type. Based on the amount or percentage of data being less than 100% (754) (or less than the entirety of the buffer), the WTRU can send a BSR indicating the determined amount or percentage (756). The WTRU can assume that data not reported in the BSR can be used as input for resource selection and / or reselection for the SL or relay path (758). If the determined amount or percentage of data is 100% or the entirety of the buffer, the WTRU can send a BSR as it normally would for a single path radio bearer (i.e., send a BSR based on the entirety of the amount of buffered data) (760).
[0075] A WTRU can be configured with at least one radio bearer that can be transmitted on both paths in mode 2 over the SL, and configured with a multipath. When higher priority data arrives at the WTRU and / or a trigger for a periodic BSR, the WTRU can determine a percentage of buffer status to report for each radio bearer over Uu based on at least one sensing metric, such as a QoS, a SL CBR, and / or a sensing type. For example, the sensing type can mean whether the WTRU is performing partial sensing, full sensing, random selection, or has WTRU assistance. The QoS can refer to a priority or latency configured for the bearer. With respect to the CBR, for example, the WTRU can select one of a plurality of configured percentages associated with a CBR range in which the measured CBR falls. For Uu, the WTRU can report a BSR equal to the percentage of actual buffer status corresponding to the determined percentage for that radio bearer. If needed, the WTRU can trigger resource selection and / or reselection, which assumes the amount of data available for transmission is determined by the amount of BSR not reported. The WTRU can transmit data on the SL in the selected resources, if applicable.
[0076] In some embodiments, the WTRU can report a subset of the buffer status in the BSR. For example, the WTRU can report an amount that can be less than or equal to the amount of buffered data for a logical channel or channel group associated with a multi-path. Such operation can be performed only for flexible bearers. The WTRU can report the full buffer status for logical channels (LCHs) / LCGs associated with Uu RBs and can report a subset of the buffer status for flexible bearers. The WTRU can determine the subset of the buffer status or how to report the subset based on one or a combination of the following: an AL condition, a sensing result, an indication from a relay WTRU, a QoS configured for a bearer, a QoS flag or identity associated with each PDU in the WTRU buffer, a cell or group of cells controlling the remote WTRU compared to the relay, a primary path of the bearer itself or another bearer (e.g., SRB), and / or a type of SL channel (e.g., whether the sidelink is licensed or unlicensed). For example, the SL condition can include CBR, a sensing result, a SL RSRP measured with the relay WTRU, and / or a CR.
[0077] Regarding CBR, for example, the WTRU can determine the amount in the subset, a percentage of the total BSR to report, or specific data to include in the buffer status based on the measured CBR. For another example, the WTRU can be configured with a percentage of the total buffer status and report only the amount corresponding to the percentage based on the measured CBR. For example, the WTRU can be configured with a table that maps CBR ranges to percentages of BSR to report. Embodiments described herein that refer to the use of percentages of buffer status can also be extended to configure absolute values or ranges of BSR amount to report. For example, for CBR within a first configured range, the amount of buffer status reported should be such that the remaining portion does not exceed a configured number of bytes.
[0078] Regarding sensing results, for example, the WTRU can determine the amount in the subset, the percentage of the total BSR to report, or the specific data to include in the buffer status based on any criteria associated with the sensing results. This can include the sensing type, the percentage of available resources, failed resource selection, and / or detected pre-emption. Regarding the sensing type, for example, the range (e.g., range of CBR or other range), percentage, or absolute value (e.g., for the reported buffer status) can be different depending on whether the WTRU performs mode 2 transmission with full sensing, partial sensing, random selection, and / or whether the WTRU can utilize sensing results provided by a peer WTRU. Regarding failed resource selection, for example, the same rule can apply to the number of times the WTRU fails to determine a sufficient percentage (e.g., x%) of resources for resource selection. Regarding detected pre-emption, for example, the same rule can apply to the number of times the WTRU has detected pre-emption and the WTRU.
[0079] Regarding SL RSRP measured with a relay WTRU, for example, the WTRU can be configured with a first range of SL RSRP (for which a first percentage of the total buffer status is reported as buffer status) and a second range of SL RSRP (for which a second percentage of the total buffer status is reported as buffer status).
[0080] Regarding CR, for example, the WTRU can determine the amount in the subset, the percentage of the total BSR to report, or the specific data to include in the buffer status based on the measured CR or the configured CR limit. For example, the WTRU can report buffer status with additional / more data (larger subset) reported in the Uu BSR when the WTRU reaches the CR limit. For example, the WTRU can report a different percentage when the CR limit is reached, or can use a different method to determine the threshold when the CR limit is reached compared to when the limit is not reached.
[0081] For example, the indication from the relay WTRU can include the RRC state of the relay WTRU, flow control indication at the relay WTRU, Uu channel conditions seen by the relay WTRU, and / or indication of handover, SL-RLF, etc. (e.g., in NotificationMessageSidelink) made by the relay WTRU.
[0082] Regarding the RRC state of the remote WTRU (e.g., such as a WTRU in RRC_IDLE / RRC_INACTIVE), the remote WTRU can report all buffer status of the flexible bearers in the Uu BSR, while the remote WTRU can report only a subset of the buffer status of the flexible bearers in the Uu BSR when the relay WTRU is in RRC_CONNECTED. The subset can be determined using the methods herein. For example, the remote WTRU can be aware of the RRC state of the relay WTRU explicitly (using PC5-RRC signaling) or implicitly based on signaling of other parameters, behaviors, etc.
[0083] Regarding flow control indication at the relay WTRU, if the relay WTRU sends a flow control message (e.g., indicating a flow control problem), or indicates that the latency associated with the relay is above a threshold, the remote WTRU can report all buffer status associated with the flexible bearers in the Uu BSR. The relay WTRU can continue to report all buffer status until another flow control message is sent indicating that the flow control problem is resolved. For example, the remote WTRU can calculate a first subset for a first type of flow control message received or a period of time after a first flow control condition (using a first set of rules herein), and can calculate a second subset for a second type of flow control message received or a period of time after a second flow control condition (using a second set of rules herein).
[0084] Regarding Uu channel conditions seen by the relay WTRU, for example, the remote WTRU can receive an indication of the Uu channel conditions (e.g., cell-level RSRP, CSI, estimated latency, estimated bandwidth), and can calculate a first amount for a subset for a first condition and a second amount for a subset for a second condition.
[0085] Regarding indication of handover, SL-RLF, etc. by the relay WTRU, for example, the remote WTRU can report all buffer status associated with the flexible bearers in the Uu BSR after receiving a message (e.g., NotificationMessageSidelink) from the relay WTRU (e.g., indicating HO, SL RLF, etc.). The relay WTRU can continue to report all buffer status in the Uu BSR until another NotificationMessageSidelink is received or until a message from the network is received (e.g., reconfiguration), or indefinitely.
[0086] Regarding QoS for bearer configuration, for example, under certain conditions herein, if a flexible bearer is associated with certain QoS conditions (e.g., has a priority greater than a threshold, is configured to do so by explicit / implicit configuration parameters in the bearer configuration, etc.), the remote WTRU can report the full buffer status of the flexible bearer.
[0087] For example, the QoS flag or identification associated with each PDU in the WTRU buffer can include a PDU set delay budget (PSDB) and / or a PDU set or PDU set type. For example, the remote WTRU can report only data in its buffer for which the PSDB is below a threshold or a certain amount of computation. For another example, the remote WTRU can report only data in its buffer for which the PDU set type is a certain type.
[0088] Regarding the cell or cell group controlling the remote WTRU compared to the relay, for example, the remote WTRU can have different rules to report buffer status associated with a flexible bearer in the Uu BSR depending on whether the remote WTRU cell (for the direct path) is the same as the cell of the relay WTRU or is in the same configured cell group. For example, in the same cell case, the remote WTRU can report the full buffer status in the Uu BSR, while for the different cell case, the remote WTRU can report a subset of the buffer status (based on some rules herein). For example, in the same cell case, the remote WTRU can use a first table of percentages vs. CBR, for example, while in the different cell case, the remote WTRU can use a second table.
[0089] Regarding the primary path, for example, the remote WTRU can have different rules to report buffer status associated with a flexible bearer in the Uu BSR depending on whether the primary path of that bearer or the primary path of the SRB is configured to be direct or indirect.
[0090] Regarding the type of SL channel, for example, the remote WTRU can have different rules to report buffer status associated with a flexible bearer in the Uu BSR depending on whether the SL path is on a licensed channel or an unlicensed channel. For example, for a licensed SL channel, the remote WTRU can use a first table of percentages vs. CBR, for example, while in an unlicensed SL channel, the remote WTRU can use a second table.
[0091] In some embodiments, the WTRU can report a suggested split of the BSR, such as by an explicit percentage, by two separate BSR quantities (a first quantity suggested on Uu and a second quantity suggested on SL), or similar mechanisms for reporting such a split. The WTRU can determine the split using any of the above methods for determining a subset quantity. However, in addition to reporting a suggested split, the WTRU can also report the full buffer status for the flexible bearers.
[0092] In some embodiments, the WTRU can determine the data to be used for resource selection and / or reselection (i.e., the input to the mode-2 resource selection mechanism) based on the quantities reported in the Uu BSR or the reported / suggested split. Specifically, the WTRU can report a portion of the overall buffer status to be reported in the Uu BSR and can use the remaining portion as the amount of data to input into the resource selection algorithm. Alternatively, the WTRU can determine whether the data should be used as available data for resource selection and / or reselection or not depending on whether the data is reported in the Uu BSR. Specifically, if only certain data is reported in the Uu BSR, the remaining data can be used for resource selection and / or reselection.
[0093] The resource selection and / or reselection triggers can also depend on such data split. Specifically, the WTRU can only provide to the resource selection algorithm the data types (e.g., PDU set types) that are not reported in the buffer status in the Uu BSR.
[0094] The WTRU can trigger a Uu BSR when a mode-2 sensing metric changes by a preconfigured amount since the last reported BSR. The WTRU can be configured with multiple paths in mode-2 on the SL and with at least one radio bearer that can be transmitted on both paths. Upon transmitting a Uu BSR containing data for the bearers configured on both paths, the WTRU can determine one or more sensing metrics. For example, the one or more sensing metrics can be or include a percentage of available resources during resource selection, a measured CBR, and / or an amount of dB required to reach a certain availability (e.g., 20%). The WTRU can monitor the one or more sensing metrics after each last reported BSR and can determine whether the metrics have changed when preparing to transmit the next BSR. If the value of one or more metrics changes by a QoS-related configured amount, the WTRU can trigger a MAC CE transmission on the Uu. The metric change can be determined based on the QoS of the most stringent flexible radio bearer that had data reported in the last BSR. The WTRU can also perform one or more of the following: compute a buffer status and transmit a Uu BSR and / or transmit a MAC CE indicating the change in the one or more sensing metrics. The buffer status can be computed or determined, e.g., using any of the above methods.
[0095] FIG. 8 is a flowchart 800 of an example method to trigger a Uu BSR based on a change in sensing results since the last reported BSR, implemented in a WTRU that is configured with multiple paths in mode 2. In FIG. 8 In the example shown, the method includes determining one or more sensing metrics when transmitting a Uu BSR including data for bearers configured on a sidelink (SL) path and a Uu path (802). Based on a value of the one or more sensing metrics changing by a configured amount since the last reported BSR (which depends on the quality of service (QoS)) (804), the WTRU can trigger a (MAC) control element (CE) on Uu (806) and perform at least one of: calculating a buffer status and transmitting a Uu BSR (808) and / or transmitting a MAC CE indicating the change in the one or more sensing metrics (810).
[0096] Embodiments described herein with respect to triggering a BSR can be applicable to a WTRU in multiple paths. In some embodiments, the WTRU can be configured with multiple path bearers and / or the WTRU can have data available for transmission on a flexible bearer. Additionally, while embodiments described with respect to FIG. 8 described herein can be applicable to a non-multiple path WTRU for which the trigger can be for a Uu BSR and / or a SL BSR. In some embodiments, the WTRU can trigger a Uu BSR, for example, due to a measured condition on the SL changing. The condition can be similar to the conditions that trigger a calculated BSR to change or the amount / percentage / part used to determine the buffer status to report in the Uu BSR, as described in detail above. For example, the new trigger for transmitting a Uu BSR can be obtained from: CBR, one or more sensing results, SL RSRP, CR, last calculated percentage, and / or a suggested split for the Uu BSR, detection of a SL radio link failure (RLF), or a combination of any of these factors. Additionally or alternatively, the just listed triggers can be used to trigger resource selection.
[0097] When the new trigger for sending a Uu BSR is obtained from CBR, for example, if the WTRU has data available for transmission in a flexible logical channel and the CBR changes by a configured amount (e.g., increases or decreases) compared to the last reported BSR, changes by a configured amount (e.g., increases or decreases) compared to when the data arrived in the buffer, changes by a configured amount (e.g., increases or decreases) compared to when the WTRU last calculated the data split between SL and Uu, as used herein; increases to a configured value when it was previously below that value; and / or decreases to a configured value when it was previously above that value, the WTRU can trigger a Uu BSR.
[0098] When the new trigger for sending a Uu BSR is obtained from one or more sensing results, for example, if the WTRU detects pre-emption, it can trigger a Uu BSR, which can be further qualified depending on whether the WTRU can meet the latency requirements of the data due to pre-emption. For another example, if listen-before-talk (LBT) fails on SL, the WTRU can trigger a Uu BSR, assuming SL is operating on unlicensed spectrum. For another example, if the WTRU receives a sensing result or an indication from another WTRU related to a sensing result, such as an indication that the resources selected by the remote WTRU are being used by another WTRU, it can trigger a Uu BSR. For yet another example, if the WTRU fails a number of resource selection procedures, the WTRU can trigger a Uu BSR, such that the failure can be equivalent to finding an insufficient amount (e.g., 20%) of available resources after availability determination.
[0099] When the new trigger for sending a Uu BSR is obtained from SL RSRP, for example, when the SL RSRP determined by the remote WTRU or indicated by the relay WTRU to the remote WTRU is below a threshold, the WTRU can trigger a Uu BSR.
[0100] When the new trigger for sending a Uu BSR is obtained from CR, for example, if the CR exceeds a threshold or if the WTRU reaches a CR limit, or the CR is a certain value from the CR limit, the WTRU can trigger a Uu BSR.
[0101] When the new trigger for sending a Uu BSR is obtained from the last calculated percentage and / or suggested split of a Uu BSR, for example, if the WTRU detects a change in the calculated percentage split or percentage of the overall BSR to be reported in a Uu BSR, it can trigger a Uu BSR.
[0102] When the new trigger for sending a Uu BSR is obtained from detection of SL radio link failure (RLF), for example, if the WTRU detects SL RLF with the relay WTRU and / or it decides to keep the relay connection, it can trigger a Uu BSR.
[0103] In some embodiments, the WTRU can trigger a Uu BSR due to receiving a message from the relay and possibly a condition associated with the content / property of the message. Such a message can be one or more of the following: an indication of a change in status at the relay, a discovery message, a flow control message or a flow control message from the relay WTRU and / or a NotificationMessageSidelink message indicating an event at the relay, such as (but not limited to): a handover (HO) made by the relay, a relay reselection, an inability to initiate an RRC connection and / or an inability to initiate a Uu RL indication. For example, due to a NotificationMessageSidelink message indicating a HO made by the relay, the WTRU can trigger a Uu BSR. For another example, due to an indication from the relay WTRU that it is changing RRC state (e.g., from RRC CONNECTED to RRC IDLE / RRC INACTIVE), the WTRU can trigger a Uu BSR. For yet another example, due to data now being able to route through the sidelink, when the WTRU receives a flow control message from the relay WTRU (the message indicating a flow control problem at the relay WTRU to indicate a larger buffer status associated with the Uu or indicating a mitigation of the problem to indicate a smaller buffer status associated with the Uu), it can trigger a Uu BSR.
[0104] The trigger associated with the Uu BSR and / or resource selection and / or reselection can further cause the WTRU to determine, due to the trigger, whether to trigger only the Uu BSR, only the resource selection and / or reselection or both. Such a determination can be based on one or more of the following: CBR, one or more sensing results, sidelink RSRP, CR, QoS of data in the buffer, QoS flag associated with new data, amount of data in the buffer or amount of new data, last computed percentage / Uu BSR suggested split and / or a message received from the relay WTRU (e.g., prior to the trigger).
[0105] In some embodiments, based on the conditions, the WTRU can trigger Uu BSR or resource selection and / or reselection or both. In some embodiments, the conditions for deciding between Uu BSR and / or resource selection and / or reselection can be the same as the one or more conditions described above for deciding between triggering Uu BSR or resource selection and / or reselection. For example, after the conditions associated with triggering Uu BSR or resource selection and / or reselection (e.g., legacy triggers defined in the background or any new triggers described herein), the WTRU can determine whether to trigger Uu BSR and / or resource selection and / or reselection based on one of the conditions described herein, such as measured sidelink conditions or a message from the WTRU.
[0106] For example, when the conditions for triggering Uu BSR and / or resource selection and / or reselection, the WTRU can determine whether to trigger Uu BSR and / or trigger resource selection and / or reselection based on measured SL CBR. For example, if the CBR is below a threshold, the WTRU can trigger resource selection and / or reselection. Otherwise, if the CBR is above the threshold, the WTRU can trigger Uu BSR. For example, if the WTRU has data available for transmission and new data arrives with a priority higher than any available data in its buffer, the WTRU can trigger Uu BSR when the CBR is above the threshold. Otherwise, the WTRU can trigger resource selection and / or reselection. For example, if the WTRU has no data available for transmission and new data arrives, the WTRU can trigger Uu BSR when the CBR is above the threshold, otherwise trigger resource selection and / or reselection.
[0107] For another example, when the conditions for triggering Uu BSR, such as legacy conditions, are met, the WTRU can determine whether to trigger Uu BSR or trigger resource selection and / or reselection based on the last sensing result. For example, if the WTRU experienced multiple failed sensing (x% of available resources initially) before the trigger and needs to increase the RSRP threshold to achieve x% of available resources, the WTRU can trigger Uu BSR. Otherwise, the WTRU can trigger resource selection and / or reselection.
[0108] For another example, when the conditions for triggering Uu BSR, such as legacy conditions, are met, the WTRU can determine whether to trigger Uu BSR or trigger resource selection and / or reselection based on the SL-RSRP measured by the relay. For example, if the SL-RSRP is below a threshold, the WTRU can trigger Uu BSR. Otherwise, it can trigger resource selection and / or reselection.
[0109] For another example, when a condition for triggering a Uu BSR (such as a legacy condition) is met, the WTRU can determine whether to trigger a Uu BSR or a resource selection and / or reselection based on a QoS flag associated with the new data to be transmitted. For example, if the PSDB is below a threshold, the WTRU can trigger a Uu BSR. Otherwise, it can trigger a resource selection and / or reselection.
[0110] For another example, when a condition for triggering a Uu BSR (such as a legacy condition) is met, the WTRU can determine whether to trigger a Uu BSR or a resource selection and / or reselection based on a measured CR. For example, if the CR is above a threshold, the WTRU can trigger a Uu BSR. Otherwise, it can trigger a resource selection and / or reselection.
[0111] For another example, when a condition for triggering a Uu BSR (such as a legacy condition) is met, the WTRU can determine whether to trigger a Uu BSR or a resource selection and / or reselection based on a previous message received by the relay and / or a condition at the relay associated with the message. For example, if the relay WTRU indicates a Uu RLF, a HO, a flow control problem, etc. causes such a condition that data needs to be routed over the Uu of the flexible bearer, the remote WTRU can trigger a Uu BSR after a legacy trigger. On the other hand, if such a condition caused by a message received from the relay WTRU is resolved (e.g., the HO is completed, the Uu RLF is resolved using reestablishment, the flow control problem is resolved), the WTRU can trigger a Uu BSR.
[0112] For yet another example, when a condition for triggering a Uu BSR (such as a legacy condition) is met, the WTRU can determine whether to trigger a Uu BSR or a resource selection and / or reselection based on a QoS of the data in the buffer or the new data of the triggering event. For example, if the priority of the data is above a threshold, the WTRU can trigger a Uu BSR. Otherwise, it can trigger a resource selection and / or reselection. For example, the flexible bearer can be configured with a condition of whether to trigger a Uu BSR or a resource selection and / or reselection or further conditions associated with triggering which one.
[0113] In some embodiments, upon a trigger, the WTRU can trigger a Uu BSR or resource selection and / or reselection based on a configuration aspect from the network. One example can be the primary path of a bearer itself. For example, the WTRU can be configured with a primary path. Upon a legacy trigger for Uu BSR and / or resource selection and / or reselection, if the primary path of the bearer or SRB is Uu, the WTRU can trigger a Uu BSR, and if the primary path is SL / indirect, the WTRU can trigger resource selection and / or reselection.
[0114] The conditions described herein can further decide whether to trigger a Uu BSR and resource selection and / or reselection simultaneously. For example, based on the amount of new data arrived, the WTRU can decide to trigger a Uu BSR or resource selection and / or reselection (in case the amount of new data is below a threshold) or whether to trigger a Uu BSR and resource selection and / or reselection simultaneously (in case the amount of new data is above a threshold) based on the primary path configuration.
[0115] In some embodiments, instead of or in addition to relay resource selection and / or reselection, legacy triggers for relay resource selection and / or reselection can also be used to initiate a Uu BSR. Such legacy triggers can be any of the triggers described herein, where such triggers can be applicable to ordinary SL WTRUs performing SL transmission in mode 2. For example, if a trigger occurs (which would normally initiate resource selection and / or reselection for SL WTRUs performing SL transmission in mode 2), instead of or in addition to relay resource selection and / or reselection, the WTRU in the multipath can trigger a Uu BSR instead of triggering resource selection and / or reselection. This can be the case, for example, if the relay WTRU has at least one flexible bearer. Additionally or alternatively, this can be the case, for example, if the relay WTRU has data waiting for flexible bearer processing. Additionally or alternatively, this can be the case, for example, if the amount of data / QoS waiting for flexible bearer processing meets some conditions. Similarly, in some embodiments, instead of or in addition to a Uu BSR, legacy triggers for Uu BSR can be used to trigger relay resource selection and / or reselection.
[0116] A WTRU can be configured with a dedicated SR resource and can trigger such SR under conditions with mode 2 resource selection. A WTRU that is configured with multiple paths in mode 2 over the SL and configured with at least one radio bearer that can be transmitted over both paths can receive a configuration of a dedicated SR related to a condition associated with mode 2 resource allocation. Such reception can be or include one or more of: triggering pre-emption of a periodic reserved resource that allows transmission from the at least one bearer; receiving a conflict indication from a peer WTRU associated with a periodic resource that allows transmission from the at least one bearer; experiencing a SL RLF; and / or receiving a SL WTRU indication (e.g., HO) from a peer WTRU. Upon the condition being met, the WTRU can transmit a dedicated Uu SR.
[0117] FIG. 9 FIG. 9 is a flowchart 900 of an example method of triggering a dedicated SR based on a result of an event over the SL, implemented in a WTRU. The method can be configured with multiple paths in mode 2 over the sidelink (SL) and configured with at least one flexible radio bearer configured with a Uu logical channel and a SL logical channel. In some embodiments, the WTRU can be configured with a dedicated SR resource. In some embodiments, the WTRU can be configured with a dedicated Uu SR resource. FIG. 9 In the example shown, the WTRU can receive a configuration of a dedicated Uu SR related to a condition associated with mode 2 resource selection and / or reselection (902). Upon the condition being met, the WTRU can transmit a dedicated Uu SR (904). Examples of receiving a configuration are described in the paragraphs above and in more detail below.
[0118] In some embodiments, a WTRU can perform a dedicated transmission to the network due to an event over the SL, such as when the WTRU is configured with multiple paths and / or when the WTRU has a flexible bearer. For example, such a message can be a SR, a PUCCH transmission, a RACH, a MAC CE, or a RRC message. In the embodiments described herein, a dedicated SR is assumed. However, the aspects can be applicable to any other message.
[0119] In some embodiments, the WTRU can be configured with one or more dedicated SR resources for indicating the SL event to the network when in multipath. Alternatively, the WTRU can be configured to use one of the existing / configured SR resources (e.g., SR for highest priority Uu LCH, SR for SL CSI reporting, etc.). In some embodiments, the WTRU can be configured with a single dedicated SR resource and can be configured with conditions for triggering the SR, such that any of the conditions described herein can be used. For example, the WTRU can trigger the dedicated SR if it determines pre-emption of a periodically reserved resource that allows transmission from at least one flexible bearer. For another example, the WTRU can trigger the dedicated SR if it receives a collision indication from a peer WTRU that is associated with a periodically resource that allows transmission from at least one flexible bearer. For another example, the WTRU can trigger the dedicated SR if it determines SL-RLF through a relay WTRU. For yet another example, the WTRU can trigger the dedicated SR if it receives a message (e.g., NotificationMessageSidelink) from a peer WTRU that indicates, for example, HO of a relay WTRU, Uu RLF of a relay WTRU, etc.
[0120] In some embodiments, the WTRU can be configured with multiple dedicated SR resources and can select the SR resource based on the evaluated condition. For example, the WTRU can trigger a first SR under a first condition (e.g., flow control issue) and a second SR under a second condition (e.g., SL RLF). For example, the WTRU can trigger different SRs that correspond to different levels of issues on the SL or different amounts of data needed to compensate for issues on the SL on the Uu. For example, the WTRU can trigger a first SR if the CBR changes by a first amount and a second SR if the CBR changes by a second amount. For example, the WTRU can trigger a first SR if it decides to split data by a first amount and a second SR if it decides to split data by a second amount.
[0121] A WTRU can trigger a Uu BSR based on an amount of new data arriving to a flexible radio bearer over a configured time period, a QoS of the bearer, and a measured CBR. For example, a WTRU configured in mode 2 over SL with multiple paths and configured with at least one radio bearer that can be transmitted over two paths can be configured by the network with a threshold amount of new data associated with a flexible radio bearer. The WTRU can determine the threshold amount of new data to transmit based on the QoS (e.g., priority) of the bearer and the CBR. If the WTRU receives an amount of new data to transmit for the bearer over a predefined time period that exceeds the determined threshold amount, the WTRU can trigger and / or transmit a Uu BSR to the network.
[0122] Embodiments described herein can introduce new triggers for Uu BSR and / or relay selection and / or reselection. Such new triggers can apply to WTRUs in multiple paths. For example, such new triggers can only apply to data arriving to a flexible bearer. Alternatively, embodiments described herein can apply to legacy Uu WTRUs or SL WTRUs when Uu BSR or SL BSR is triggered separately without assuming multiple paths. Legacy regular BSRs can be triggered based on one or more of the following conditions: data available for use by a logical channel that has a higher priority than any other logical channel that has data available for transmission and / or no logical channel has data available for transmission.
[0123] FIG. 10 is a flowchart 1000 of an example method of triggering a BSR based on an amount of new data received at a split bearer, implemented in a WTRU configured in mode 2 over SL with multiple paths and configured with at least one radio bearer that can be transmitted over two paths. Data can become available for transmission by using a flexible radio bearer, and the WTRU can determine whether an amount of data that becomes available for transmission over a configured time period exceeds a threshold amount (1002). If so, the WTRU can trigger a legacy Uu BSR for the full amount of buffered data (1004). If not, the WTRU can trigger a Uu BSR based on a percentage of buffered data to transmit over Uu (1006).
[0124] In some embodiments, legacy conditions for triggering legacy or “regular” Uu BSRs can be defined in terms of the amount of data arriving to a logical channel. For example, a WTRU can trigger a regular BSR if a minimum amount of data is available for a logical channel (that has a higher priority than any other logical channel that has data available for transmission). The WTRU can be configured with such a minimum amount of data. The configuration can further be specific to priority (e.g., a first minimum amount can be configured for a first priority and a second minimum amount can be configured for a second priority). Additionally or alternatively, such a minimum amount can be defined in terms of a time period for data to arrive. For example, a WTRU can trigger a BSR if a minimum amount of data is available for a logical channel (that has a higher priority than any other logical channel that has data available for transmission) within a configured time window. In another example, a WTRU can trigger a BSR if no logical channel has data available for transmission and a minimum amount of data arrives (possibly within a configured time period) for a logical channel.
[0125] In some embodiments, new conditions based on data amount can be added as the only condition for triggering a BSR. For example, a WTRU can trigger a BSR if new data arrives to a bearer (such as a flexible bearer) and the amount of data is above a threshold. Alternatively, a WTRU can trigger a BSR if new data arrives to a bearer and the amount of data that arrives within a configured time period is above a threshold.
[0126] In the new triggers described above, the conditions or parameters (e.g., the amount of data to trigger a BSR and / or the time window to consider) can further depend on SL conditions and / or QoS. For example, one or a combination of the following can be used by a WTRU to determine the threshold amount of data and / or the time window: CBR, CR, SL RSRP, priority, and / or QoS related flags such as PSDB or PDU type. For example, a WTRU can be configured with different threshold amounts of data depending on CBR, CR, SL RSRP, priority, or any combination thereof. For another example, a WTRU can be configured with a threshold amount of data that arrives (that has a PSDB below a threshold, has a particular PDU type, etc.). For yet another example, whether a WTRU is to trigger a Uu BSR or not based on the arrival of a threshold amount of data can depend on conditions related to the aforementioned factors (e.g., only when CBR is above a threshold, etc.).
[0127] In some embodiments, the WTRU can trigger resource reselection based on conditions related to the Uu BSR described herein. For example, the WTRU can trigger resource selection and / or reselection when the WTRU changes the mechanism for determining the buffer status to be reported in the Uu BSR (possibly for the flexible bearer). For example, the WTRU can trigger resource selection and / or reselection due to any of the triggers described herein, such as a trigger for moving from reporting the full buffer status to the Uu BSR to reporting a portion of the buffer status to the Uu BSR (and vice versa). For example, the WTRU can trigger resource selection and / or reselection when the percentage or absolute amount of the Uu BSR to be reported changes from one amount to another, from one percentage to another, or from one calculation mechanism to another. In another example, the WTRU can trigger resource selection and / or reselection based on any of the triggers related to the amount of data arriving to the flexible bearer, such as similar or identical to the triggers that trigger the Uu BSR. For example, the WTRU can trigger resource selection and / or reselection if a minimum amount of data arrives to the flexible bearer, such as within a configured time period.
[0128] While features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer- readable media include electronic signals (optical, electrical or electromagnetic) that are transmittable through a wired or wireless communication connection. Examples of computer-readable media include, but are not limited to, a read only memory (ROM), random access memory (RAM), register, cache, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). Portions of software methods described herein, or elements thereof, can be stored and transported within any computer-readable medium for practice by or in connection with an apparatus, system or device described or claimed in this document and / or any combination thereof. The processor can execute the described software or elements in real-time.
Claims
1. A method implemented in a wireless transmit / receive unit (WTRU) configured with a flexible radio bearer in mode 2, the flexible radio bearer configured with a Uu logical channel and a sidelink (SL) logical channel, the method comprising: determining, based on a trigger for transmitting a buffer status report (BSR) for one or more buffers containing an amount of data, a percentage of the amount of the data stored in the one or more buffers to report for the Uu logical channel of the flexible radio bearer based on one or more of a quality of service (QoS) configured for the flexible radio bearer, a sidelink channel busy ratio (CBR), or a type of sensing the WTRU is configured to perform; and transmitting the BSR reporting the determined percentage of the data in the one or more buffers based on the determined percentage being less than one hundred percent.
2. The method of claim 1, further comprising using data not reported in the BSR as an input for resource selection or resource reselection for the SL logical channel.
3. The method of claim 1 or 2, wherein the QoS configured for the flexible radio bearer comprises at least one of a priority or a latency configured for the flexible radio bearer.
4. The method of any one of claims 1-3, wherein determining, based on the SL CBR, a percentage of the amount of data stored in the one or more buffers to report for the Uu logical channel of the flexible bearer further comprises: selecting one of a plurality of configured percentages associated with a CBR range in which the measured CBR falls.
5. The method of any one of claims 1 to 4, wherein the type of sensing comprises at least one of partial sensing, full sensing, or assisted sensing.
6. The method of any one of claims 1 to 5, wherein the BSR comprises one or more of a report of an amount of a subset of the data stored in the one or more buffers, the determined percentage, or the data to be included.
7. A wireless transmit / receive unit (WTRU) comprising: a processor; and a transceiver, wherein the processor and the transceiver are configured to determine, based on a trigger for transmitting a buffer status report (BSR) for one or more buffers containing an amount of data, a percentage of the amount of the data stored in the one or more buffers to report for a Uu logical channel of a flexible radio bearer based on one or more of a quality of service (QoS) configured for the flexible radio bearer, a sidelink channel busy ratio (CBR), or a type of sensing the WTRU is configured to perform; and wherein the transceiver and the processor are further configured to transmit the BSR reporting the determined percentage of the data in the one or more buffers based on the determined percentage being less than one hundred percent.
8. The WTRU of claim 7, wherein the processor and the transceiver are further configured to use data not reported in the BSR as an input for resource selection or resource reselection for a SL logical channel.
9. The WTRU of any one of claims 7 or 8, wherein the QoS for the flexible radio bearer configuration comprises at least one of a priority or a latency for the flexible radio bearer configuration.
10. The WTRU of any one of claims 7-9, wherein the processor and transceiver are further configured to determine the percentage of the amount of the data stored in the one or more buffers to report for the Uu logical channel of the flexible bearer based on the SL CBR by selecting one of a plurality of configured percentages associated with a CBR range in which the measured CBR falls.
11. The WTRU of any one of claims 7-10, wherein the sensing type comprises at least one of partial sensing, full sensing, or assisted sensing.
12. The WTRU of any one of claims 7-11, wherein the BSR comprises one or more of a report of an amount of a subset of the data stored in the one or more buffers, the determined percentage, or the data to include.