System and method for sidelink communication

Abstract

Systems, methods, and instrumentalities are described herein that may be used to determine a destination for a sidelink transmission based on a priority of the transmission and / or other parameters associated with the transmission. In an example, if one or more logical channels associated with a destination have bucket size parameters that exceed a particular threshold and the one or more logical channels have the highest priority, the destination may be selected. Various other techniques are also described herein that relate to configuration and / or reporting of QoS information, selection of sidelink resources, use of minimum communication range, and the like.

Description

[0001] This application is a divisional application of the Chinese invention patent application with the application date of March 25, 2020, application number 202080023756.1, and invention name “System and method for side link communication”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 824,071 filed on March 26, 2019, U.S. Provisional Patent Application No. 62 / 840,805 filed on April 30, 2019, U.S. Provisional Patent Application No. 62 / 867,597 filed on June 27, 2019, U.S. Provisional Patent Application No. 62 / 886,161 filed on August 13, 2019, and U.S. Provisional Patent Application No. 62 / 930,943 filed on November 5, 2019, the contents of which are incorporated herein by reference. Background Art

[0004] The communication mode of the wireless transmit / receive unit (WTRU) may include vehicle communication, such as vehicle-to-everything (V2X) communication. Using vehicle communication, the WTRUs may communicate directly with each other. Use cases for V2X operation may include in-coverage scenarios (e.g., where the WTRU may receive assistance from the network to transmit and / or receive V2X messages), out-of-coverage scenarios (e.g., where the WTRU may use pre-configured parameters to transmit and / or receive V2X messages), and / or the like. Types of V2X communication may include vehicle-to-vehicle or V2V communication (e.g., vehicle WTRUs communicate directly with each other), vehicle-to-infrastructure or V2I communication (e.g., vehicle WTRUs communicate with roadside units (RSUs) or with base stations (eNBs or gNBs)), vehicle-to-network or V2N communication (e.g., vehicle WTRUs communicate with a core network), vehicle-to-pedestrian or V2P communication (e.g., vehicle WTRUs communicate with WTRUs under special conditions such as low battery capacity conditions), etc. Summary of the invention

[0005] Systems, methods, and means are described herein that may involve the selection of a destination (e.g., a destination ID or a destination address associated with a destination device) for a sidelink transmission. Such a transmission may utilize sidelink resources that are configured by a network or selected (e.g., autonomously) by a wireless transmit receive unit (WTRU), for example, from a preconfigured resource pool. The WTRU may select the destination based on one or more transmission parameters associated with the destination and / or a priority associated with the destination. In an example, the WTRU may identify one or more logical channels in response to determining that the one or more logical channels have data available for transmission and the corresponding bucket size parameter of the logical channel has a value greater than zero. Upon identifying the logical channel, the WTRU may select the first destination for the sidelink transmission if the first destination is associated with a first logical channel having a highest priority (e.g., a highest logical channel priority) among the one or more identified logical channels. The WTRU may then transmit data associated with the first logical channel to the first destination using at least a portion of the resources available to the WTRU.

[0006] The WTRU may identify a second logical channel (e.g., in addition to the first logical channel) from the one or more identified logical channels. The WTRU may multiplex transmissions of the second logical channel with transmissions of the first logical channel. The WTRU may select the second logical channel based on the second logical channel having a minimum communication range within a distance of the minimum communication range of the first logical channel and based on the second logical channel having a priority and bucket size parameter that exceeds a certain threshold.

[0007] The WTRU may determine that there is a second destination associated with a logical channel having the same highest priority and a bucket size parameter greater than zero. The WTRU may select the first destination instead of the second destination if the WTRU determines that selecting the first destination may result in fewer resources being used to transmit data that exceeds the bucket size requirement than selecting the second destination (e.g., selecting the first destination may result in fewer resources being used to transmit non-prioritized data than selecting the second destination).

[0008] The systems, methods, and means described herein may relate to the management of quality of service (QoS) requirements. The WTRU may use different messages to report QoS information for different data types. The WTRU may report buffer status for different data types, where different buffer status reports (BSRs) may have different logical channel to logical channel group mappings (LCH to LCG mappings). The WTRU may use different messages to report different QoS information. The WTRU may use a multiple-stage configuration (e.g., a multi-stage BSR) associated with QoS parameters and / or LCGs. The WTRU may be configured with multiple destination indexes for a destination, for example, so that the WTRU may transmit buffer status information with different QoS characteristics.

[0009] The WTRU may select an amount of resources and / or one or more carriers based on a given data rate. The WTRU may select one or more carriers for transmission that may satisfy a given data rate. The WTRU may perform carrier / resource reselection based on rate-related triggers. The WTRU may perform carrier and / or resource reselection based on metrics associated with resources used by a peer WTRU. The WTRU may send an indication of the performed carrier / resource reselection to a peer WTRU.

[0010] A minimum communication range may be defined for the WTRU. Logical channel prioritization (LCP) may be performed based on one or more LCH restrictions, which may be based on the suitability of transmissions associated with the minimum communication range. The WTRU may select data or LCH for transmission parameter selection. The WTRU may use a target minimum communication range, for example, to determine transmission parameters and / or generate network reports. Transmission parameters (e.g., MCS) may be selected to attempt to maximize a metric (e.g., spectral efficiency). The WTRU may determine candidate resources based on a target transport block size.

[0011] The WTRU may determine the amount of allowable resources based on a measurement of the data rate (e.g., the achievable data rate), which may be derived from a CQI report. The WTRU may reserve or select selected or reserved resources up to a maximum calculated rate based on the data rate requirements of the sidelink radio bearer (SLRB) associated with the WTRU. The WTRU may temporarily exceed the maximum rate of the selected resources. When the WTRU exceeds a specific data rate, the WTRU may be configured with different resource selection parameters for the sidelink process. The WTRU may distinguish between constant bit rate and non-guaranteed bit rate (non-GBR) SLRBs in the flow-to-SLRB mapping and / or in the rate calculation. The WTRU may restrict and / or prioritize a subset of SLRBs to use a specific SL process or SL carrier. The WTRU may calculate the maximum rate separately for different sidelink process types.

[0012] The WTRU may trigger resource reselection based on a failure or error condition associated with logical channel prioritization. The WTRU may determine one or more SL procedures on which to perform resource reselection based on one or more rate-related triggers. The WTRU may determine a reservation time (e.g., number of periods) for periodic reservation based on one or more QoS parameters.

[0013] The WTRU may be configured with one or more rules for destination address selection during logical channel prioritization. For example, the WTRU may be configured with rules indicating how the WTRU should combine conditions or criteria for destination selection. The WTRU may select a destination address based on the value of a QoS parameter associated with a logical channel for the destination. The WTRU may select a destination address based on whether the destination is associated with a maximum weighted bucket size parameter (e.g., bucket size Bj). The WTRU may select a destination address based on whether the selection can minimize data exceeding Bj (e.g., so that authorized use can be minimized, such as authorized use for non-prioritized bit rate data or authorized use that does not correspond to Bj>0). The WTRU may select a destination address based on whether the selection can satisfy one or more (e.g., most) configured bucket sizes. The WTRU may select a destination address based on whether the selection can satisfy the maximum number and / or majority of logical channels with pending data. The WTRU may select a destination address so that the bucket size or the total bucket size may be above a threshold. The WTRU may select a destination address based on a destination-specific bucket size. The WTRU may select a destination address based on a restriction on selecting the same destination address. The WTRU may select a destination address based on a timer such as a destination starvation avoidance timer.

[0014] The WTRU may determine which criteria to use (e.g., for destination selection) and / or the order in which the criteria are used based on the channel conditions. The WTRU may determine which criteria to use and / or the order in which the criteria are used based on the criticality of the conditions. The WTRU may be configured to give certain destinations a higher priority or weight when applying the decision criteria.

[0015] The WTRU may limit or prioritize transmissions associated with a minimum communication range that falls within a specific communication range of a first selected LCH. When the receiving WTRU is outside the minimum communication range (e.g., the minimum communication range associated with the SLRB), the transmitting WTRU may use best-effort transmission parameters. The receiving WTRU may send an indication of the location of the WTRU and / or whether the WTRU is inside or outside the minimum communication range (e.g., the minimum communication range associated with the SLRB). When the receiving WTRU is outside the minimum communication range (e.g., the minimum communication range associated with the SLRB), the transmitting WTRU may be configured with a different or alternative set of transmission-related parameters. When the receiving WTRU is outside the minimum communication range (e.g., the minimum communication range associated with the SLRB), the transmitting WTRU may modify the flow-to-bearer mapping of the flow.

[0016] The WTRU may determine the condition(s) under which a specific or exception resource pool may be used.The receiving WTRU may send HARQ feedback along with a transmission range indication.

[0017] The WTRU may change one or more starvation avoidance parameters and / or behaviors based on congestion conditions. In an example, starvation avoidance may refer to rules, operating parameters, behaviors, efforts, etc. applied by the network and / or the WTRU so that the WTRU may avoid or mitigate resource shortages for sending or receiving transmissions. The WTRU may decide whether to select the amount of data based on a bucket size parameter (e.g., Bj) based on a channel busy ratio. The WTRU may decide whether to increase the bucket size parameter value (e.g., Bj) based on a measured congestion level. The WTRU may calculate the bucket size parameter (e.g., Bj) differently based on the measured congestion level. The WTRU may select the amount of data based on a function of the bucket size parameter (e.g., Bj), and the function may depend on the measured congestion level.

[0018] The WTRU may be configured to change the SLRB configuration (e.g., RLC mode) based on the channel busy ratio. The WTRU may be configured to favor (e.g., give higher priority to) transmissions with lower minimum communication range during congestion control. The WTRU may select the SLRB configuration that best represents the QoS profile of the flow. The WTRU may implement one or more LCP range limits for minimum communication range. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which:

[0020] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0021] Figure 1B is a diagram showing that according to an embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within a communication system is shown;

[0022] Figure 1C is a diagram showing that according to an embodiment, Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown; and

[0023] Figure 1D is a diagram showing that according to an embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used within the communication system shown;

[0024] Figure 2 is a diagram illustrating an example scenario for destination selection.

[0025] Figure 3 is a diagram illustrating an example of destination selection. DETAILED DESCRIPTION

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

[0027] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a “station” and / or “STA”, which may be configured to transmit and / or receive wireless signals, and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, 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 device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices working in an industrial and / or automated process chain environment), consumer electronic devices, and devices working on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[0028] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102d. For example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, a New Radio (NR) Node B, a site controller, an access point (AP), a wireless router, and the like. Although each of the base stations 114a, 114b is depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

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

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

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

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

[0033] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology that may use new radio (NR) to establish the air interface 116, such as NR radio access.

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

[0035] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-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), and GSM EDGE (GERAN), among others.

[0036] Figure 1A The base station 114b in the example may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use any appropriate RAT to facilitate wireless connectivity in a local area, such as a business location, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In an embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, and the like). As Figure 1A As shown, the base station 114b may be directly connected to the Internet 110. Thus, the base station 114b does not need to access the Internet 110 via the CN 106 / 115.

[0037] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or may perform advanced security functions such as user authentication. Although in Figure 1AAlthough not shown, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104 / 113. For example, in addition to being connected to the RAN 104 / 113 employing NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0041] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, however it should be appreciated that the processor 118 and the transceiver 120 may also be integrated together in an electronic package or chip.

[0042] The transmit / receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive component 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in another embodiment, the transmit / receive component 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, the transmit / receive component 122 may be configured to transmit and / or receive RF and light signals. It should be appreciated that the transmit / receive component 122 may be configured to transmit and / or receive any combination of wireless signals.

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

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

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

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

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

[0048] The processor 118 may also be coupled to other peripheral devices 138, wherein the peripheral devices may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, frequency modulation (FM) radio units, digital music players, media players, video game console modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, and activity trackers, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geographic location sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors, etc.

[0049] The WTRU 102 may include a full-duplex radio in which the reception or transmission of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous for the radio. The full-duplex radio may include an interference management unit 139 that reduces and / or substantially eliminates self-interference by means of hardware (e.g., chokes) or by signal processing by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio that transmits and receives some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)).

[0050] Figure 1C 1 is a system diagram showing the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c using an E-UTRA radio technology over the air interface 116. The RAN 104 may also communicate with the CN 106.

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

[0052] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0053] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the aforementioned components is described as being part of the CN 106, it should be appreciated that any of these components may be owned and / or operated by an entity other than the CN operator.

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

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

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

[0057] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, and the IP gateway may serve as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0058] Although in Figures 1A-1D Although the WTRU is described as a wireless terminal, it should be appreciated that in certain representative embodiments, such a terminal may use a (eg, temporary or permanent) wired communication interface with a communication network.

[0059] In a representative embodiment, the other network 112 may be a WLAN.

[0060] A WLAN using an infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access or be connected to a distributed system (DS) or other types of wired / wireless networks that send traffic into and / or out of the BSS. Traffic originating from outside the BSS and destined for the STA may arrive through the AP and be delivered to the STA. Traffic originating from the STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS may be sent through the AP, for example, when the source STA may send traffic to the AP and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. The point-to-point traffic may be sent using a direct link establishment (DLS) between the source and destination STAs (e.g., directly therebetween). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z channelized DLS (TDLS)). For example, a WLAN using an independent BSS (IBSS) mode does not have an AP, and STAs (eg, all STAs) within or using the IBSS can communicate directly with each other. Here, the IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode.

[0061] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon on a fixed channel (e.g., a primary channel). The primary channel may have a fixed width (e.g., a bandwidth of 20 MHz) or a width that is dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access (CSMA / CA) with collision avoidance (e.g., in an 802.11 system) may be implemented. For CSMA / CA, STAs (e.g., each STA) including the AP may sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA may back off. In a specified BSS, there is one STA (e.g., only one station) transmitting at any given time.

[0062] A high throughput (HT) STA may communicate using a 40 MHz wide channel (eg, by combining a 20 MHz wide primary channel with a 20 MHz wide adjacent or non-adjacent channel to form a 40 MHz wide channel).

[0063] Very high throughput (VHT) STA can support channels with widths of 20MHz, 40MHz, 80MHz and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels or by combining two discontinuous 80MHz channels (this combination can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can be transmitted and passed through a segment parser, which can separate the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed separately on each stream. The stream can be mapped on two 80MHz channels, and the data can be transmitted by the STA performing the transmission. At the receiver of the STA performing the reception, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0064] 802.11af and 802.11ah support working modes below 1 GHz. Compared with 802.11n and 802.11ac, the channel working bandwidth and carrier used in 802.11af and 802.11ah are reduced. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC) (e.g., MTC devices in macro coverage areas). MTC devices can have certain capabilities, such as limited capabilities including support (e.g., only support) certain and / or limited bandwidths. MTC devices can include a battery, and the battery life of the battery is higher than a threshold (e.g., for maintaining a very long battery life).

[0065] For WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah), these systems include channels that can be designated as primary channels. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a certain STA, where the STA originates from all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the width of the primary channel can be 1MHz. 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., because a STA (which only supports the 1MHz operating mode) transmits to the AP), then even if most of the available frequency bands remain idle and available for use, the entire available frequency band can be considered busy.

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

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

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

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

[0070] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing other RANs (e.g., the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect to the gNB 180a, 180b, 180c while communicating / connecting to another RAN (e.g., the eNode-B 160a, 160b, 160c). For example, the WTRU 102a, 102b, 102c may communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c in a substantially simultaneous manner by implementing the DC principle. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRU 102a, 102b, 102c.

[0071] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network slicing, dual connectivity, implement interworking between NR and E-UTRA, route user plane data to a user plane function (UPF) 184a, 184b, and route control plane information to an access and mobility management function (AMF) 182a, 182b, and the like. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other through the Xn interface.

[0072] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may include a data network (DN) 185a, 185b. Although each of the aforementioned components is described as part of the CN 115, it should be understood that any of these components may be owned and / or operated by an entity other than the CN operator.

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

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

[0075] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which can provide the WTRUs 102a, 102b, 102c with access to packet-switched networks (e.g., the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions, such as routing and forwarding packets, implementing user plane policies, supporting multi-host PDU sessions, processing user plane QoS, buffering downlink packets, and providing mobility anchor processing, etc.

[0076] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the local data network (DN) 185a, 185b via an N3 interface connected to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b and through the UPF 184a, 184b.

[0077] In view of Figures 1A-1D and about Figures 1A-1D In accordance with the corresponding description of the present invention, one or more or all functions described herein in comparison with one or more of the following may be performed by one or more simulation devices (not shown): WTRU 102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN185ab and / or one or more other devices described herein. These simulation devices may be one or more devices configured to simulate one or more or all functions described herein. For example, these simulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0078] The simulation device can be designed to implement one or more tests about other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all functions while being implemented and / or deployed as a part of a wired and / or wireless communication network in whole or in part to test other devices inside the communication network. The one or more simulation devices can perform one or more or all functions while being temporarily implemented or deployed as a part of a wired and / or wireless communication network. The simulation device can be directly coupled to other devices to perform the test, and / or can use over-the-air wireless communication to perform the test.

[0079] One or more simulation devices can perform one or more functions, including all functions, while not being implemented or deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test lab and / or a test scenario of a wired and / or wireless communication network that is not deployed (e.g., testing) to implement tests on one or more components. The one or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication with the aid of RF circuits (e.g., which can include one or more antennas).

[0080] V2X communications may be performed in various modes (e.g., in at least two modes). In a first mode, a network (e.g., an eNB or gNB) may provide a WTRU with a scheduling allocation assignment for V2X transmissions (e.g., for V2X sidelink transmissions). The first mode may be referred to herein as NR Mode 1 (and / or simply Mode 1), LTE Mode 3 (e.g., or simply Mode 3), and / or a network scheduled transmission mode. In a second mode, the WTRU may autonomously select resources from a configured (e.g., pre-configured) resource pool. The second mode may be referred to herein as LTE Mode 4 (e.g., or simply Mode 4), NR Mode 2 (e.g., or simply Mode 2 and / or by reference to various sub-modes such as 2a, 2b, 2c, 2d, etc.), and / or an autonomous scheduling mode. Multiple types of resource pools may be defined, including, for example, a receive pool that the WTRU may monitor to receive V2X transmissions, and / or a transmit pool from which the WTRU may select resources for transmitting information (e.g., in an autonomous scheduling mode, such as Mode 4). For WTRUs configured to operate in certain modes (eg, Mode 3), transmit pools may not be configured or may not be used.

[0081] A resource pool (e.g., for V2X communications) may be signaled (e.g., semi-statically or semi-persistently) to the WTRU, e.g., via radio resource control (RRC) signaling. In certain modes (e.g., in an autonomous scheduling mode, such as Mode 4), the WTRU may perform sensing (e.g., measurements) before selecting resources from a resource pool (e.g., from an RRC configured transmit pool). Dynamic resource pool reconfiguration may or may not be supported. The resource pool configuration may be carried in a system information block (SIB) via dedicated RRC signaling, etc.

[0082] New Radio (NR) systems can support a variety of use cases, such as enhanced mobile broadband (eMBB) and / or ultra-high reliability and low latency communications (URLLC). NR systems can support enhanced V2X (eV2X) communications. eV2X communication services may include services for safety and non-safety scenarios, such as sensor sharing, autonomous driving, vehicle platooning, and / or remote driving. Different eV2X services may have different performance requirements. For example, a 3ms latency may be required in some eV2X services.

[0083] One or more of the following use cases may be supported. Vehicle platooning may be supported to enable vehicles to dynamically form groups that travel together. One or more (e.g., all) vehicles in the convoy may receive data (e.g., periodic data) from a lead vehicle, e.g., to conduct convoy operations. Such data may allow the distance between vehicles to be shortened. For example, when measured in time terms, the gap distance between vehicles may be short (e.g., less than one second). This may allow vehicles following a lead vehicle to be driven autonomously.

[0084] Advanced driving may be supported to achieve semi-autonomous or fully autonomous driving. In these use cases, longer inter-vehicle distances may be assumed. (E.g., each) vehicle and / or RSU may share data obtained from local sensors with its nearby vehicles, for example, thereby allowing the vehicles to coordinate their trajectories or maneuvers. (E.g., each) vehicle may share its driving intentions with its nearby vehicles, for example, to promote safe driving, collision avoidance, and traffic efficiency.

[0085] Extended sensors can be supported to enable the exchange of raw or processed data, such as data collected by local sensors or live video / audio data, between vehicles, RSUs, pedestrian devices, V2X application servers, etc. As a result, the vehicle can enhance its perception of its environment beyond what the vehicle's own sensors can detect, so that the vehicle can have a more comprehensive view of the local situation.

[0086] Remote driving may be supported to enable a remote driver or V2X application to remotely operate a vehicle, e.g., for a person who cannot drive themselves or for maneuvering a remote vehicle in a hazardous environment. In examples (e.g., where environmental changes are limited and routes are predictable (such as for public transportation)), driving may utilize (e.g., based on) cloud computing. In such use cases, access to a cloud-based backend service platform may be considered.

[0087] A WTRU participating in a V2X service may support (e.g., simultaneously support) multiple wireless communication technologies (e.g., NR and LTE sidelink communication technologies).

[0088] As discussed herein, V2X communications may be performed in a network scheduled mode and / or an autonomous mode. Such an autonomous mode may include multiple sub-modes. For example, in a first sub-mode (e.g., mode 2a), the WTRU may autonomously select sidelink resources for transmission. In a second sub-mode (e.g., mode 2c), the WTRU may be configured with a network configuration authorization for sidelink transmission (e.g., similar to a type 1 authorization). In a third sub-mode (e.g., mode 2d), the WTRU may schedule sidelink transmissions for other WTRUs. Functions associated with different sub-modes may be combined (e.g., one sub-mode may be built into another sub-mode). For example, in mode 2b, the WTRU may be configured to assist other WTRUs in sidelink resource selection.

[0089] A WTRU performing V2X communication may use a broadcast mechanism at the application (AS) layer. A WTRU participating in V2X communication may be provided with an L2 destination ID (e.g., identifier) ​​from upper layers (e.g., layer 2 including the MAC layer). The L2 destination ID may correspond to a V2X service. The WTRU may include the L2 destination ID in a MAC header. Reception may be based on filtering MAC PDUs with an L2 destination ID that matches a service that the WTRU may be interested in.

[0090] A WTRU performing V2X communications may utilize unicast and / or multicast transmission mechanisms (e.g., when the relevant use case is associated with strict quality requirements such as those in vehicle platooning). Through unicast and / or multicast, the WTRU may utilize feedback from receiving devices (e.g., HARQ, CQI, etc.) to optimize transmission power and / or retransmissions to allow efficient use of resources and better control of quality of service (QoS), etc.

[0091] The WTRU may implement one or more QoS models established for V2X communications. For example, QoS on a communication interface (e.g., PC5 interface) may be supported with ProSe per-packet priority (PPPP). The application layer may be allowed to mark packets with PPPP, which may indicate the required QoS level. For example, by allowing a packet delay budget (PDB) to be derived based on PPPP, system performance objectives may be achieved.

[0092] Performance indicators and / or design goals associated with QoS may include one or more of: payload (e.g., in bytes), transmission rate (e.g., in messages / second), maximum end-to-end latency (e.g., in milliseconds), reliability (e.g., in percentage of successes or failures), data rate (e.g., in mbps), or minimum communication range (e.g., minimum required communication range, e.g., expressed in meters).

[0093] In some examples, a common set of service requirements may apply to V2X communications over different interfaces (e.g., PC5-based V2X communications and / or Uu-based V2X communications).

[0094] A unified QoS model may be implemented, for example, for PC5 and Uu. For example, a 5G QoS indicator (e.g., 5QI) may be used for V2X communications over PC5 so that the application layer may have a consistent way of indicating QoS requirements regardless of the link used.

[0095] For a WTRU with V2X capability, there may be multiple (e.g., three) types of services. These may include, for example, broadcast, multicast, and unicast. For unicast services, the same QoS model as for Uu may be used. For example, each unicast link may be considered a bearer and a QoS flow may be associated with the unicast link. One or more (e.g., all) QoS characteristics defined in 5QI and / or one or more parameters associated with the transmission data rate may be applied. The minimum communication range (e.g., minimum required communication range) may be considered a specific parameter used by PC5.

[0096] Similar considerations can apply to multicast services (eg, multicast can be viewed as a special case of unicast with multiple defined receivers of the service).

[0097] For broadcast services, the concept of bearer may not apply. Depending on the application requirements, each message may have different characteristics. Each packet of 5QIs can be used in a manner similar to PPPP or ProSe per packet reliability (PPPR). For example, one or more 5QIs may be marked with a packet (e.g., each packet). The characteristics described in 5.5QIs may represent one or more (e.g., all) characteristics of PC5 broadcast operations, including latency, priority, reliability, etc. A set of V2X broadcast-specific 5QIs (e.g., VQIs) may be defined for use with PC5.

[0098] In an example, V2X QoS requirements may be limited to PPPP and PPPR, which may represent latency requirements, priority requirements, and / or reliability requirements. In an example, data rate requirements and / or minimum communication range requirements may also be supported. Support for these requirements may be considered in the context of network scheduled operation (e.g., Mode 1 described herein) and / or WTRU autonomous operation (e.g., Mode 2 described herein). In network scheduled operation, the network may have or may obtain knowledge of the QoS requirements associated with the sidelink radio bearer (e.g., in order to appropriately schedule grants). In WTRU autonomous mode, QoS requirements may be considered for carrier selection and / or reselection.

[0099] The WTRU may report the QoS of data available in its buffer for appropriate scheduling by the network (e.g., in a network scheduling mode such as Mode 1 described herein). The WTRU may have data associated with different numbers of QoS or QoS-related parameters and may report buffer status associated with the data to the network. For example, the WTRU may receive a first type of data associated with only a single QoS parameter (e.g., PQI-PC5 quality indicator), a second type of data associated with two QoS parameters (e.g., PQI and data rate, PQI and range), and a third type of data associated with three QoS parameters (e.g., PQI, data rate, and range).

[0100] Although the examples described herein may be explained in terms of V2X communications, these examples and / or embodiments may be more generally applicable to other types of communications. For example, they may be applied to other types of sidelink communications, communications with network-based radio access network (RAN) nodes, and / or other types of direct device-to-device (D2D) communications.

[0101] As used herein, a data type may refer to data associated with a common set of one or more QoS parameters. The QoS parameters may indicate one or more quality characteristics associated with the data. When data for transmission is accommodated in the WTRU's buffer, the WTRU may receive quality characteristics associated with certain data from upper layers. Such quality characteristics may be provided to the WTRU along with (e.g., each) packet from the upper layer. Such quality characteristics may be received by the WTRU in association with a flow initiated from the upper layer. For example, the upper layer may initiate a flow and attach quality characteristics to the flow. The WTRU may receive quality characteristics in the form of each packet and flow ID from the upper layer.

[0102] The WTRU may report information related to the QoS of data in the WTRU's buffer using a single message or multiple messages. In the case of multiple messages, the QoS information may be of different types and / or formats and may be reported with different frequencies (e.g., periodicity) and / or triggers. The messages may include RRC messages, MAC control elements (CEs) including but not limited to buffer status reports (BSRs), and / or PHY layer signaling such as scheduling request (SR) indications on a physical uplink control channel (PUCCH).

[0103] The WTRU may report QoS information using a single message. The message may include multiple parts (e.g., multiple different parts). For example, the WTRU may report QoS information using a MAC CE with multiple information elements (IEs). The multiple IEs may have different formats and may include different information, depending on the QoS to be reported.

[0104] When referred to herein, using a different message (eg, for reporting QoS information) may include using one or more different IEs (eg, having a different format) of the message (eg, for reporting QoS information).

[0105] The WTRU may use different messages to report QoS information for different data types. In an example, the WTRU may report the presence of data (e.g., amount of data, buffer status, origination of data, etc.) in different messages and / or different message formats depending on the data type. For example, the WTRU may use a first message or a first portion of a message (e.g., having a specific format) to report a buffer status associated with a first data type. The WTRU may use a second message or a second portion of a message (e.g., having a specific format that may be different from the format of the first message) to report a buffer status associated with a second data type.

[0106] In an example, the WTRU may report a buffer status of data with one QoS parameter (e.g., PQI) using a first MAC CE (e.g., BSR) and report a buffer status of data associated with multiple QoS parameters (e.g., PQI and data rate, PQI and range, etc.) using a second MAC CE (e.g., BSR). The WTRU may indicate the message type of the message (e.g., in the form of a MAC CE type, an RRC message type, an explicit indication, etc.).

[0107] The messages described herein may have different attributes or formats. For example, the WTRU may report buffer status of different data types with different BSRs, and these BSRs may be associated with different logical channel (LCH) to logical channel group (LCG) mappings. These messages may be configured with different LCH to LCG mappings. These messages may be associated with different LCH sets and / or different types of LCH to LCG mappings.

[0108] For example, in a first message, the WTRU may report the buffer status of a first set of LCHs (e.g., only those LCHs associated with PQI) based on a first mapping of LCHs to LCGs. The WTRU may report the buffer status of each LCG, for example, by calculating the amount of data in all LCHs mapped to the LCG based on a first configuration. In a second message, the WTRU may report the buffer status of a second set of LCHs (e.g., LCHs associated with PQI and data rate). The second set of LCHs may have a different configuration LCH to LCG mapping.

[0109] The messages described herein may be of different types and / or in different formats. For example, the first message may be a MAC CE and the second message may be an RRC message. The messages may use different numbers of bits to report the buffer status of each LCG and / or may use different numbers of bits for the destination address (or for any other reporting element). The messages may not all include the same data field. For example, one or more of the messages may not have a particular field present (e.g., one or more messages may not include an indication of unicast / multicast / broadcast or a destination ID).

[0110] The WTRU may transmit a first message based on a trigger associated with a first data type, and may transmit a second message based on a trigger associated with a second data type. For example, the WTRU may only report the first message if data of the first data type arrives at the WTRU and / or the data may be associated with an LCG configured for the first data type. The WTRU may only report the second message if data of the second data type arrives at the WTRU and / or the data may be associated with an LCG configured for the second data type.

[0111] The WTRU may use different messages or different parts of messages to report QoS information of different characteristics (e.g., buffer status). For example, the WTRU may use a first message to report information related to a first QoS characteristic (e.g., PQI) and a second message to report information related to a second QoS characteristic (e.g., range), wherein a subset of the data associated with the second QoS characteristic may also be associated with the first QoS characteristic.

[0112] The WTRU may report the buffer status of data (e.g., all data) with at least one QoS parameter (e.g., PQI) in a MAC CE (e.g., in a BSR). In the example given above, if a subset of data reported in the first message is also associated with a second QoS characteristic (e.g., range), the WTRU may report information about the subset of data in a second message. The second message may include a MAC CE, which in turn may include one or more of the following information segments:

[0113] The MAC CE may include the amount of data associated with the second QoS characteristic (which may also be reported in the first message).

[0114] For example, if the WTRU is configured to use multiple LCH to LCG mappings and / or QoS to LCG mappings and selects an appropriate mapping from the configured mappings, the MAC CE may include specific rules for the LCH to LCG mapping used in the second message.

[0115] The MAC CE may include the amount of data reported in the first and second messages, or the amount of data reported in the second (or first) message that was not reported in the first (or second) message.

[0116] The MAC CE may include specific QoS characteristics (eg, range, data rate, etc.).

[0117] The MAC CE may include a reference or identifier identifying the corresponding first message (eg, a transaction ID, a time reference, or a message number / message index of the first message).

[0118] The MAC CE may include the logical channel group(s) for which the second message is providing information on additional QoS.

[0119] The MAC CE may include an explicit or implicit indication of a QoS value or a QoS value range associated with the second QoS characteristic.

[0120] If a subset of data previously reported in a first message is associated with a second QoS parameter reported by a second message, the WTRU may report the subset of data in a second message. For example, the WTRU may report a first message (e.g., a BSR) that provides a buffer status report for each LCG configured according to a first QoS parameter (e.g., a PQI). The WTRU may be configured with a set of LCHs, each of which may be associated with one or more values ​​of a first QoS parameter. The WTRU may be configured to have a mapping of LCHs to one or more LCGs and / or a mapping between the first QoS parameter and one or more LCGs. The WTRU may report the buffer status of each LCG in the BSR, which may be done, for example, by reporting the amount of data associated with the LCH mapped to the LCG. The WTRU may report in the second message (e.g., in the form of a MAC CE or by including an additional IE in the BSR) the amount of data available for transmission reported in the first message and associated with a second QoS parameter (e.g., a range). The WTRU may report the explicit value(s) of the second QoS parameter in the second message.

[0121] The WTRU may have data associated with only a first QoS parameter (e.g., PQI) and / or data associated with a first and a second QoS parameter (e.g., PQI and range). The WTRU may report a BSR for all of the data using a single message, which may be done, for example, by using different IEs to report data associated with only PQI and data associated with PQI and range. In an example (e.g., for data associated with only PQI), the WTRU may report one or more of the following: destination, LCG, or buffer status, where the LCG may correspond to a mapping of PQI to LCG as configured by the network. In an example (e.g., for data associated with both PQI and range), the WTRU may add one or more instances of a range parameter (e.g., which may be an associated buffer status or a buffer status percentage). The range parameter may include one or more of the following.

[0122] The range parameter may include an explicit indication of a range parameter (eg, range in meters) associated with some or all of the data reported for the LCG.

[0123] The scope parameter may include an index (eg, an index into a configured table) into a set of values ​​for the scope parameter that are associated with part or all of the data reported for the LCG.

[0124] The WTRU may indicate for one or more IEs (eg, for each IE) the format of the IE used (eg, whether a range parameter is included and / or how many range parameter values ​​are included). The WTRU may use another field in the BSR (eg, a destination index) to indicate the format of the IE.

[0125] The WTRU may report QoS information based on mappings between different QoS parameters and LCGs. The WTRU may be configured with a first mapping of a first QoS parameter (e.g., PQI) to one or more LCGs and / or a second mapping of a second QoS parameter (e.g., data rate) to one or more LCGs. The WTRU may report the amount of data associated with each LCG of the first mapping in a first message. The WTRU may report the amount of data associated with each LCG of the second mapping in a second message. The WTRU may report (e.g., in a first message, in a second message, or in a different message than the first or second message) the amount of data that may be associated with a particular LCG and may have been reported in both the first message and the second message. The WTRU may report (e.g., in a first message, in a second message, or in a different message than the first or second message) the total amount of data in the WTRU's buffer.

[0126] The WTRU may report QoS information based on a multi-stage configuration associated with QoS parameters and / or LCGs (e.g., in a multi-stage BSR). The WTRU may be configured to report QoS related information (e.g., buffer status) for a configured set of logical channel groups in multiple stages, so that the configuration of the LCG may not necessarily depend on the actual QoS parameters. For example, the WTRU may be configured with several LCGs, where each LCG may be bound to one or more QoS characteristics (e.g., PQI, rate, range, etc.).

[0127] In the first phase, the WTRU may report QoS information (e.g., buffer status) associated with a subset of one or more LCGs. The WTRU may report QoS information (e.g., buffer status) associated with a subset of one or more LCGs in some cases: any LCH belonging to the LCG(s) has available data in the buffer. In the second phase, the WTRU may report QoS information (e.g., buffer status) associated with each LCG, or only report QoS information (e.g., buffer status) associated with those LCGs for which the buffer status was reported in the corresponding subset of LCG(s) during the first phase.

[0128] The QoS information reported in a phase may be in the form of one or more of: an LCG (e.g., by index); an LCG subset (e.g., by index), whereby each LCG subset index may identify a set of indexed LCGs; the actual amount of data in the WTRU's buffer corresponding to the LCG or LCG subset; an indication that some data is available for transmission in the LCG or LCG subset (e.g., the WTRU may report the buffer status of the LCG as a percentage of the buffer status in a previous message); a percentage of a total amount of data, where the total amount of data may be reported separately or in a different phase; or any other QoS-related information discussed herein.

[0129] The WTU may report buffer status associated with a subset of LCGs (eg, each subset) in a first stage, and may report a percentage of the buffer status of each LCG in the LCG subset in a second stage (eg, relative to the buffer status reported in the first stage).

[0130] The WTRU may be configured, for example, by the network to have a mapping of QoS to (one or more) LCGs and / or a mapping of (one or more) LCGs to (one or more) subsets of LCGs. Such configuration may be in the form of an RRC configuration, a MAC CE, or other suitable form. For example, the WTRU may be configured to have a mapping of one or more QoS parameters to one or more LCGs. The mapping may indicate data associated with at least one QoS parameter (e.g., LCG1 = all data associated with PQI1, PQI2, and / or PQI3, regardless of the values ​​of other QoS parameters or whether the data is associated with the other QoS parameters). The mapping may indicate data associated with multiple QoS parameters (e.g., LCG1 = all data associated with PQI1 and data rate v1).

[0131] The WTRU may be configured to have a mapping of one or more LCGs to one or more LCG subsets. For example, the WTRU may be configured to have 64 LCGs. The WTRU may also be configured to map LCGs 1-8 to LCG subset 1, LCGs 9-16 to LCG subset 2, and so on.

[0132] The WTRU may be configured with multiple mappings and may change from one mapping to another based on network indication. For example, the WTRU may receive a set of configurations from the network (eg, via RRC) and may switch from one configuration to another upon receiving a MAC CE.

[0133] The WTRU may autonomously change the QoS to LCG mapping and / or LCG to LCG subset mapping. The WTRU may change (e.g., switch from one to another) within a subset of preconfigured mappings (e.g., provided by the network). The WTRU may indicate the selected mapping to the network, e.g., as part of signaling performed by the WTRU in the first phase. The WTRU may change the mapping based on one or more of the following.

[0134] The WTRU may change the mapping in response to new data arriving in the WTRU's buffer and / or based on current data in the WTRU's buffer. For example, the WTRU may determine a mapping of QoS to LCG(s) and / or LCG(s) to LCG subset(s) based on the data available for transmission in order to minimize the amount of information to be sent based on the number of LCG subsets or the number of LCGs for which buffer status is to be reported and / or based on the size of the report (e.g., BSR).

[0135] The WTRU may change the mapping based on the size of the grant from the network. For example, the WTRU may select a configuration regarding QoS to LCG(s) and / or LCG(s) to LCG subset(s) so that (e.g., during the first phase and / or the second phase as described herein) a corresponding report regarding QoS information may be transmitted using a corresponding grant from the network.

[0136] The WTRU may change the mapping based on the conditions of the sidelink (SL) channel. For example, the WTRU may select the configuration of QoS to (one or more) LCGs and / or (one or more) LCGs to (one or more) LCG subsets based on the current measurement of the constant bit rate (CBR), SL HARQ feedback, SL channel state information (CSI), SL radio resource management (RRM), and / or other similar SL measurements. The WTRU may provide a preliminary mapping of QoS to (one or more) LCGs under conditions where (one or more) QoS parameters can be met (e.g., low CBR), and may provide a more refined mapping of QoS to (one or more) LCGs under conditions where (one or more) QoS parameters may be more difficult to meet (e.g., high CBR).

[0137] The WTRU may be configured with multiple destination indexes (e.g., for transmitting buffer status information with different QoS characteristics to destinations). For example, the WTRU may be configured with multiple destination indexes for a single destination address (e.g., V2X L2 destination ID) and different sets of QoS information and / or buffer status may be reported using different destination indexes.

[0138] For example, the WTRU may be configured to have two destination indices (e.g., D1 and D2) associated with the same destination address (e.g., L2 destination ID). The WTRU may use D1 in the BSR to report to the destination the amount of data available for transmission, the amount of data being associated with a first QoS parameter (e.g., PQI). The WTRU may use D2 in the BSR to report to the destination the amount of data available for transmission, the amount of data being associated with a second QoS parameter (e.g., data rate).

[0139] Mode 2 transmissions (eg, autonomous transmissions) may be supported. An associated data rate may be calculated, selected, and / or reselected.

[0140] The WTRU may select an amount of resources and / or one or more carriers based on a data rate requirement, such as a data rate requirement associated with a transmission. The transmission may include one or more PDUs or packets to be transmitted, one or more logical channels, one or more sidelink radio bearers (SLRBs), one or more sidelink procedures, a number of transmissions associated with periodic data at the WTRU, and / or a transmission associated with aperiodic (e.g., one-time) transmissions at the WTRU.

[0141] The WTRU's selection of resources and / or number of carriers based on the associated data rate may include the WTRU selecting one or more of the following.

[0142] The WTRU may select a minimum, maximum and / or average number of time / frequency resources (eg, subchannels) to be used to perform transmissions, for example, over a configured time period.

[0143] The WTRU may select a minimum, maximum and / or average number of carriers, bandwidth parts (BWPs) and / or beams to be used to perform transmissions.

[0144] The WTRU may select a minimum, maximum and / or average number of sidelink processes to use to perform the transmission.

[0145] The WTRU may select a minimum, maximum and / or average number of times (eg, consecutive times) that the WTRU may reuse resources (eg, reserved resources) before performing procedures associated with resource acquisition (eg, sensing-based resource selection).

[0146] The WTRU may select a minimum, maximum and / or average number of frequency resources. The WTRU may select a periodic minimum, maximum and / or average number. Either or both of these selections may be associated with one or more periodic sidelink processes.

[0147] The WTRU may select the number of resources and / or carriers based on the achievable data rates for the resources and / or carriers (e.g., determined by the WTRU using associated CSI reports). For example, the WTRU may determine the range of achievable data rates based on the CQI associated with the resources and / or carriers over a configured (e.g., preconfigured) period. The WTRU may determine the range of achievable data rates based on a transport block size (TBS) configured (e.g., preconfigured) for one or more CQI values ​​(e.g., for each CQI value).

[0148] The range of achievable data rates as described herein may include one or more of a minimum data rate, a maximum data rate, an average data rate, or an x ​​percentile data rate. The x percentile data rate may refer to a data rate that is higher than x% of all determined data rates. For example, the median data rate may refer to the 50th percentile data rate.

[0149] The WTRU may determine its data rate requirement at a given time based on the number or set of SLRBs that are active or configured at the WTRU. The WTRU may determine its data rate requirement at a given time based on the corresponding data rates associated with one or more SLRBs or logical channels at the WTRU (e.g., the data rate associated with each SLRB or logical channel).

[0150] The WTRU may determine its data rate requirements based on a prioritized bit rate (PBR) and / or higher layer rate related parameters (e.g., guaranteed bit rate or GBR) configured (e.g., preconfigured) for any or all configured or active SLRBs at the WTRU. For example, the WTRU may determine its required data rate as the sum of the data rates of one or more (e.g., all) established (e.g., active) SLRBs associated with the GBR. Alternatively or additionally, the WTRU may be configured with corresponding data rate parameters for one or more SLRBs (e.g., data rate parameters for each SLRB) and may use a sum of such data rates across the SLRBs.

[0151] The resource selection described herein may be in the form of a ratio of the resources, carriers, BWPs, and / or beams used by the WTRU to the total number of available resources, carriers, BWPs, and / or beams. For example, the WTRU may be configured to have a maximum occupancy associated with a set of SLRBs based on a data rate or an aggregated data rate of the SLRBs.

[0152] Determining the amount of resources based on the data rate requirement for the transmission may be based on one or more configured or pre-configured rules. Such rule(s) may depend on other QoS requirements of the data, such as latency, priority, minimum communication range, and / or reliability. For example, the WTRU may be configured with different amounts of resources and / or carriers for a particular data rate requirement, depending on the priority, latency, reliability, and / or communication range and / or CBR of the data.

[0153] The WTRU may determine the number of sidelink processes allowed on a carrier based on the aggregate data rate of the SLRBs operating on the carrier.

[0154] The WTRU may determine the number of periodic time, frequency, and / or beam resources associated with the sidelink process that may be reserved during the resource selection procedure based on the aggregate data rate of the SLRBs mapped to the sidelink process. The number of time, frequency, and / or beam resources associated with the sidelink process that may be reserved may include the number of periods for which resources may be reserved without resource reselection.

[0155] The WTRU may determine an allowable (e.g., maximum) number of subchannels that may be selected by the WTRU (e.g., for a single transmission of a sidelink process associated with one or more SLRBs), the determination being based on the aggregate data rate of the SLRBs mapped to such transmissions. The WTRU may be configured with a maximum number of time / frequency resources (e.g., subchannels) that may be used by the WTRU over a fixed or configured (e.g., preconfigured) time window. The WTRU may select individual transmissions and / or SL processes within the time window such that the total number of resources selected within the window does not exceed a maximum value associated with the aggregate data rate of the associated SLRBs.

[0156] The WTRU may determine the number of carriers allowed for multi-carrier transmission based on the aggregate data rate of the SLRBs associated with the WTRU.

[0157] The WTRU may determine the maximum amount of resources it may select or transmit for a particular timeslot or group of timeslots, such as a channel occupancy ratio (CR) limit.

[0158] The WTRU may reserve and / or select resources based on a maximum resource rate (e.g., up to a maximum resource rate). The resources may be reserved or selected resources. The resource rate described herein may correspond to an amount of resources selected or reserved per time interval. The time interval may be predefined (e.g., configured) by the network and / or the WTRU.

[0159] At a given time, the WTRU may be configured with or may determine a maximum amount of time / frequency resources that the WTRU may select or reserve over a configured time period such that the WTRU may comply with the maximum rate of the selected resources. The WTRU may autonomously select or reserve (e.g., any) amount of time / frequency resources to transmit data in the WTRU's buffer as long as the WTRU does not exceed the maximum rate of the selected resources. Such a rate for the selected resources may be derived, for example, based on a data rate requirement associated with one, multiple, or all SLRBs (e.g., which may be associated with Mode 2 transmissions).

[0160] The WTRU may select a number of resources (e.g., resources associated with one or more sidelink procedures) that conform to the maximum rate of the selected resources. For example, the WTRU may perform resource selection for one or more periodic sidelink procedures such that the resulting rate of resources selected or reserved by the WTRU (e.g., the amount of resources per time interval) is less than or equal to the maximum rate of the selected resources.

[0161] The WTRU may determine the current rate of its selected resources by determining the total amount of resources selected for one or more (e.g., all) of its sidelink processes. For example, for a periodic sidelink process, the WTRU may determine the rate of selected resources as the sum of the number of resources per time interval using the size and periodicity of the resources reserved for one or more (e.g., all) processes. In an example (e.g., for a non-periodic sidelink process), the WTRU may maintain a count of the number of asynchronous resources selected over a time window and calculate the rate of selected resources for the process based on the count and / or the length of the time window.

[0162] The WTRU may use a combination of one or more of the following factors (eg, in addition to or instead of the rate requirement) to determine the maximum rate of the selected / reserved resources.

[0163] The WTRU may use the measured congestion of the resource pool (e.g., as indicated by the channel busy ratio or CBR) to determine the maximum rate of the selected / reserved resources. For example, the WTRU may be configured (e.g., pre-configured) with a mapping between a CBR range, an aggregate data rate requirement (e.g., over all SLRBs), and a maximum rate for the selected resources. The WTRU may determine the maximum rate of its selected resources based on the measured CBR, the aggregate rate requirement between the SLRBs configured or active at the WTRU, and the configured mapping.

[0164] The WTRU may determine the maximum rate of the selected / reserved resources using the QoS requirements of the configured or active (one or more) SLRBs of the WTRU. The QoS requirements may include priority, latency, reliability, communication range and / or other parameters in addition to or instead of data rate. For example, the WTRU may determine the number of SLRBs with priority, reliability and / or rate above a configured (e.g., preconfigured) threshold, and may determine the maximum rate of the selected resources based on the number of these SLRBs. For SLRBs with priority, reliability and / or rate greater than the threshold, the WTRU may be allowed to increase the rate of its allowed selected resources by a certain amount (e.g., relative to a default calculated amount). The WTRU may increase or decrease the data rate requirement configured for the SLRB by a factor (e.g., the value of the factor may depend on the QoS parameters).

[0165] The WTRU may determine the maximum rate of the selected / reserved resources using the maximum transmit power allowed or configured at the WTRU. For example, the WTRU may scale its allowed rate of the selected resources up or down based on the maximum transmit power configured or allowed at the WTRU.

[0166] The WTRU may use the MCS associated with the sidelink to determine the maximum rate of the selected / reserved resources. For example, the WTRU may determine a maximum MCS or target MCS for sidelink transmissions. Such an MCS may depend on one or more other factors described herein (e.g., the transmission speed of the WTRU). Such an MCS may be derived based on channel measurements (e.g., such as CQI for unicast cases). The WTRU may scale the maximum rate of the selected resources based on the MCS to be used for the sidelink transmission.

[0167] The WTRU may determine the maximum rate for the selected / reserved resources using a calculated value of the achievable data rate on a given carrier or for a particular selected (eg, configured) MCS (eg, as described herein).

[0168] The WTRU may use its transmission speed to determine the maximum rate of the selected / reserved resources. For example, the WTRU may increase or decrease its calculated maximum rate of the selected resources based on changes in the WTRU's transmission speed.

[0169] Under certain conditions, the WTRU may be allowed to exceed (e.g., temporarily exceed) the maximum rate of the selected resource. For example, the WTRU may be allowed to temporarily exceed the maximum rate of the selected resource based on a combination of one or more of the following.

[0170] If the measured channel busy ratio is below a threshold, the WTRU may be allowed to temporarily exceed the maximum rate of the selected resource.

[0171] Due to QoS requirements, the WTRU may be allowed to temporarily exceed the maximum rate of the selected resources. For example, if the maximum rate of the reserved resources cannot meet the QoS requirements (e.g., latency, rate, etc.) of the data buffered by the WTRU, the WTRU may be allowed to temporarily exceed the maximum rate of the selected resources.

[0172] When an asynchronous data transmission is triggered (eg, if the WTRU decides to initiate an asynchronous sidelink procedure), the WTRU may be allowed to temporarily exceed the maximum rate of the selected resources.

[0173] Depending on the number of activated or initiated SLRBs that meet certain QoS requirements (eg, in response to the number of such SLRBs exceeding a threshold), the WTRU may be allowed to temporarily exceed the maximum rate of the selected resource.

[0174] When data becomes available or buffered for one or more SLRBs that meet certain QoS requirements, the WTRU may be allowed to temporarily exceed the maximum rate of the selected resources.

[0175] The WTRU may be allowed to exceed the maximum rate of the selected resource for a period of time. Such a period of time may be configured (e.g., preconfigured) by the network, for example. For example, the WTRU may start a timer (e.g., as described above) upon an event that triggers the WTRU to exceed the determined maximum rate of the selected resource. The WTRU may continue to exceed the rate until the timer expires. The WTRU may be allowed to exceed the maximum rate of the selected resource for a period of a configured (e.g., preconfigured) number of SL processes. The WTRU may be allowed to exceed the maximum rate of the selected resource during one or more consecutive time windows (e.g., time periods). The WTRU may be configured with such time windows by the network. The WTRU may be configured to exceed the maximum rate of the selected resource once every N time windows (e.g., at most once every N time windows). If one or more conditions are met (e.g., CBR conditions and / or QoS requirements as described herein), the WTRU may be allowed to initiate a side link process that will cause the WTRU to exceed the maximum rate of the selected resource. For example, if the measured CBR is below a threshold and the WTRU initiates and / or has data for several SLRBs, the WTRU may initiate a new SL process and / or may perform resource reselection for a SL process. These SLRBs may not be configured with rate-related requirements, but may have priority or latency-related parameters that meet certain conditions (eg, pre-configured conditions).

[0176] The WTRU may be configured with resource selection parameters for the SL procedure. These parameters may differ depending on whether they are associated with an event that triggers the WTRU to exceed the maximum rate of the selected resources or whether they may cause the WTRU to exceed the maximum rate of the selected resources.

[0177] The WTRU may use different (eg, shorter or smaller) values ​​of the reselection counter for such SL procedures. The WTRU may use different rules (eg, based on whether the CBR is below a threshold) when deciding whether to perform resource reselection for such SL procedures.

[0178] The WTRU may distinguish between GBR SLRBs and non-GBR SLRBs in flow to SLRB mapping and / or rate calculation. The WTRU may be configured with a first type of SLRB and a second type of SLRB, wherein the first type of SLRB may allow rate enforcement and the second type of SLRB may not allow rate enforcement. The WTRU may determine the SLRB type based on the presence or absence of rate-related parameters. For example, a SLRB with configured rate-related parameters may be considered to be a SLRB with rate enforcement. A SLRB with a PBR greater than zero may be considered to be a SLRB with rate enforcement. A SLRB with a PBR equal to zero may be considered to be a SLRB without rate enforcement.

[0179] The WTRU may determine the maximum rate for the selected resources by a combination of rate-related parameters configured (eg, preconfigured) for one or more SLRBs (eg, for each SLRB). When calculating the total rate for the selected resources, the WTRU may only consider SLRBs that allow rate forcing.

[0180] The WTRU may be configured with a soft data rate requirement and / or a hard data rate requirement. The data rate requirement may be associated with a specific SLRB. For example, the WTRU may be configured with a hard data rate requirement for one SLRB (e.g., a SLRB with rate enforcement) and a soft data rate requirement for another SLRB (e.g., a SLRB without rate enforcement). The WTRU may be configured (e.g., pre-configured) with an indication of whether the SLRB data rate requirement is a soft data rate requirement or a hard data rate requirement. The WTRU may determine the total rate of the selected resource by treating the hard data rate requirement and the soft data rate requirement differently.

[0181] During calculation of the maximum rate for the selected resources, SLRBs with soft data rate requirements may be given different (eg, smaller) weight than SLRBs with hard data rate requirements.

[0182] Under certain conditions, SLRBs with soft data rate requirements may be ignored when calculating the rate of the selected resource. These conditions may be associated with (eg, may depend on) CBR, sensing results, channel quality, etc.

[0183] The WTRU may determine the maximum rate for the selected resource based on the rates attached to one or more SLRBs configured with rate enforcement. The WTRU may add a configured (e.g., preconfigured) or calculated amount or offset to the total rate of the SLRBs that are not configured with rate enforcement. The value of such an offset may depend on QoS parameters in the SLRB configuration, CBR, channel quality, speed, network indication (e.g., which may be used to dynamically enable or disable the offset), coverage, etc.

[0184] The WTRU may restrict and / or prioritize a subset of SLRBs to use a specific SL process or carrier.

[0185] The WTRU may associate a subset of SLRBs with a particular sidelink process or carrier, for example, based on one or more configured restrictions. In an example, the WTRU may perform sidelink resource selection for a periodic sidelink process that may be used for (e.g., only for) a subset of SLRBs or may be prioritized for use with the subset of SLRBs. The restrictions and / or prioritization rules for the SLRBs may be determined based on one or more of the following factors.

[0186] SLRB restriction and / or prioritization determination for SL processes or carriers may be based on the configured periodicity of the SLRBs. For example, the WTRU may be configured to map SLRBs associated with a periodicity subset onto SL processes selected with a particular periodicity.

[0187] The SLRB restriction and / or prioritization determination for a SL process or carrier may be based on a minimum communication range requirement. For example, a WTRU may select resources for a sidelink process associated with a particular minimum communication range (MCR) or a set of minimum communication ranges (MCRs). Selecting such resources to meet the minimum communication range may follow the examples described herein. Once selected, the sidelink process may be used by the WTRU for (e.g., only for) a SLRB associated with the minimum communication range or a set of minimum communication ranges.

[0188] SLRB restriction and / or prioritization for SL processes or carriers may be based on the broadcast type. For example, the WTRU may select resources for periodic sidelink processes associated only with a specific broadcast type (eg, unicast, multicast, or broadcast).

[0189] The SLRB restriction and / or prioritization determination for a SL process or carrier may be based on priority and / or latency-related QoS parameter(s) configured by upper layers. For example, the WTRU may be configured with a priority associated with one or more SLRBs (e.g., associated with each SLRB). The WTRU may perform resource selection for a sidelink process (e.g., a periodic sidelink process) associated with a particular priority or priority range. The WTRU may allow (e.g., only allow) SLRBs associated with the one or more priorities to be used for the SL process.

[0190] The WTRU may enforce restrictions on sidelink processes during an LCP procedure. In such a procedure, authorization of a particular sidelink process may allow (e.g., only allow) or prioritize the use of certain LCHs associated with a specific periodicity, range, playout type, priority, etc.

[0191] When determining the amount of resources, process and / or carrier to select, the WTRU may consider restrictions associated with the SLRBs and / or logical channels mapped to the sidelink processes and / or carriers. For example, the WTRU may select the maximum, minimum, or average amount of resources associated with a particular sidelink process based on the total PBR configured for the SLRBs that are allowed to be mapped to the particular sidelink process.

[0192] The WTRU may maintain different sidelink process types and calculate the selected resources separately for each type.

[0193] The WTRU may maintain one or more different types of sidelink procedures. The WTRU may be allowed to transmit data on a particular sidelink procedure type only for certain logical channels. For example, an SLRB may be associated with (e.g., only associated with) one or more types of sidelink procedures. A particular type of sidelink procedure may be associated with (e.g., allowed to carry data from (e.g., logical channels from) one or more of the following.

[0194] A particular type of sidelink process may be associated with certain QoS requirements. Such QoS requirements may include, for example, priority range, latency, minimum communication range, data rate, and / or reliability, etc. A particular type of sidelink process may be used depending on whether such QoS requirement or associated parameter(s) is present in the LCH configuration.

[0195] A particular type of sidelink process may be associated with a playout type (eg, unicast, multicast, or broadcast).

[0196] A specific type of side link process may be associated with a PHY layer configuration. For example, a SL process may be associated with a specific PHY layer configuration, such as a specific type of HARQ configuration (e.g., HARQ enabled or disabled), a specific type of RLM / RLF configuration, and / or a specific type of CQI measurement configuration (e.g., reference signal density, feedback frequency, etc.).

[0197] The WTRU may determine the maximum rate of the selected resources separately for each side link process type. The WTRU may determine the maximum rate of the selected resources based on the SLRB configured for that side link process type (e.g., based on the examples described herein). The WTRU may be configured with different rules for calculating the maximum rate of the selected resources, for example, depending on the side link process type.

[0198] The WTRU may use different rules (e.g., two different rules) to determine the amount of resources, for example, depending on the rate requirement. The WTRU may select the amount of resources based on whether the ultimately selected amount of resources is above or below a threshold. For example, the threshold may be determined based on the data rate requirement for the transmission.

[0199] The WTRU may select an initial amount of resources determined by the data rate requirement for the transmission (e.g., based on a configured or preconfigured mapping of data rate requirements to resource amounts). The WTRU may select additional resources beyond the initial amount of resources based on a mapping of CBR and / or priority to a maximum amount of resources.

[0200] The WTRU may select one or more carriers for transmission based on the necessary transmission data rate. For example, the WTRU may select one or more carriers for transmission with an associated data rate (e.g., transmission as defined herein), and the selection may be based on measurement (e.g., sensing) of resources on the carrier. The selection of such a carrier may be based on a determination that the carrier is capable of supporting the required data rate. Such a carrier may be selected to avoid the impact of the WTRU's own data rate on the data rates of other WTRUs operating on the carrier. The selection of such a carrier may be based on a combination of the above two factors. For example, the WTRU may be configured with (one or more) specific rules to determine whether a carrier can be selected / used for transmission based on the data rate requirements of the transmission and the sensing / measurement results of the associated carrier, as described herein.

[0201] The WTRU may select one or more carriers that can meet the data rate requirement based on measurements indicating that the relevant data rate can be supported.

[0202] The WTRU may select a carrier based on measurements indicating that the associated data rate can be met with the available resources. For example, the WTRU may select a carrier based on one or more of the following measurements on the carrier.

[0203] The WTRU may select a carrier based on resource occupancy on the carrier (e.g., based on a channel busy ratio or CBR). The WTRU may select a carrier based on a ratio of resources reserved / available over a future time period, whereby such future time period may depend on QoS characteristics of the transmission. The WTRU may select a carrier based on a measured number / ratio of available resources, which may include a certain number of contiguous (e.g., in time and / or frequency) resources. For example, the WTRU may measure a ratio of available resources that have at least x contiguous subchannels associated with them. The value of x may be configurable. The WTRU may select a carrier based on CSI associated with the resources of the carrier.

[0204] In an example (e.g., when the WTRU has a transmission associated with one or more SLRBs with a data rate of x), the WTRU may select a carrier for the transmission if the ratio of available resources on the carrier (e.g., as indicated by sensing / measurement results) is at least y. The WTRU may be configured with, for example, a table that maps values ​​of x to y.

[0205] In an example (e.g., when the WTRU has a transmission associated with one or more SLRBs with a data rate of x), the WTRU may select a carrier to use for the transmission if the SLRB(s) have a measured CBR below a configured threshold. The threshold may depend on x.

[0206] The WTRU may select one or more carriers to avoid affecting other WTRUs. The WTRU may select the carrier based on QoS measurements of other WTRUs that can be detected on the carrier. Such detection may be performed, for example, based on (e.g., by decoding) sidelink control information (SCI) sent by other WTRUs announcing future transmissions. The WTRU may select the carrier(s) so that high-rate transmissions do not affect other WTRUs that are also using the carrier. The WTRU may use a combination of criteria to select / not select a carrier for transmission. The configuration parameters in the criteria may depend on the relevant data rate. For example, the WTRU may select a carrier based on the configured number of WTRUs with (one or more) QoS parameters that meet a preconfigured criterion (e.g., at least x WTRUs with transmission latency / priority values ​​less than y values ​​are detected).

[0207] The WTRU may be configured to perform carrier / resource reselection based on one or more rate-related triggers (e.g., triggers related to the transmission rate). For example, such a trigger may be based on the WTRU determining that an attempt to meet a rate requirement associated with a transmission has failed. The trigger may include one or more of the following.

[0208] The trigger may include a change in a measurement of an achievable data rate on a carrier. For example, when the WTRU determines that the achievable data rate on a carrier on which the WTRU performs rate-dependent transmission has fallen below a threshold or has been lowered by a certain threshold, the WTRU may perform carrier / resource reselection. When the WTRU determines that the achievable data rate on the carrier has changed by at least a certain amount from an initial value (e.g., an initial value determined when the SLRB is established or modified), the WTRU may perform carrier / resource reselection. This initial amount may be determined based on the configuration and / or value of the achievable data rate itself. When the WTRU determines that the difference between the achievable data rate and the total required data rate of one or more (e.g., all) SLRBs has changed by a certain amount, the WTRU may perform carrier / resource reselection.

[0209] The trigger may include a change in the number of active transmissions (e.g., SLRBs) associated with a rate requirement. The trigger may be based on a calculation that the aggregated transmission rate requirement has changed by a certain amount. For example, the WTRU may perform carrier / resource reselection after initiating a SLRB with a specific rate requirement.

[0210] The trigger may include a change in the measured quality of the carrier(s) and / or resource(s) that the WTRU is using to perform a transmission (e.g., a transmission having a particular associated data rate). For example, the WTRU may perform a carrier / resource reselection after determining that the measured and / or reported quality of a set of resources has changed by a certain amount.

[0211] The trigger may include a change in the profile of QoS attributes used by other WTRUs (e.g., as detected via sensing / measurement). For example, a trigger may be based on a change in the number of WTRUs with a particular QoS attribute on the carrier exceeding a certain amount.

[0212] The trigger may include a failure or error condition detected during the LCP procedure. For example, the WTRU may determine that the amount of resources associated with one or more side link processes is too large or too small to meet the data rate requirements of the SLRB set. The WTRU may make this determination based on the results of the LCP procedure applied to the authorization of the one or more side link processes. The WTRU may make this determination based on the amount of data in the buffer associated with the LCH (e.g., an LCH explicitly configured with a data rate requirement). The WTRU may perform resource reselection when one or more of the following conditions are met.

[0213] The WTRU may perform resource reselection when the value of a bucket or buffer size parameter (eg, Bj or a similar bucket or buffer size parameter) associated with one or more LCHs remains positive or negative for a configured or predefined period of time.

[0214] When referred to herein, the term bucket size may refer to the amount of data to be sent (e.g., at an instance of channel prioritization (such as logical channel prioritization)). For example, the term bucket size may refer to the amount of data to be sent (e.g., at an instance of logical channel prioritization) for a given logical channel (e.g., logical channel j), for example, in order to meet the bit rate requirement (e.g., the prioritized bit rate requirement) of the logical channel. Bj may represent the bucket size of channel j (e.g., logical channel j). In an example, the bucket size or Bj (e.g., for logical channel j) may be determined based on a prioritized bit rate (PBR) and a bucket size duration (BSD) associated with the logical channel (e.g., based on the product of the PBR and the BSD, or PBR×BSD). For example, when a grant is used to send data associated with the logical channel, the value of the bucket size or Bj may change over time. In an example, Bj>0 at a given time may indicate that prioritized data is present in the bucket of the logical channel and / or that a grant should be used to transmit the prioritized data of the logical channel (e.g., in order to meet the data rate requirement of the logical channel). Bj<=0 may indicate that the data rate requirement associated with the logical channel has been met.

[0215] The WTRU may perform resource reselection when the value of a bucket size parameter (eg, Bj or a similar bucket size parameter) associated with one or more LCHs exceeds or is less than a configured or predefined threshold.

[0216] The WTRU may perform resource reselection when the value of a bucket size parameter (eg, Bj or a similar bucket size parameter) of one or more logical channels has increased over a configured or predefined number of LCP procedures or over a preconfigured or predefined time window.

[0217] The WTRU may perform resource reselection when the observed increase in a bucket size parameter (eg, Bj or a similar bucket size parameter) over multiple LCP procedures or over a time window is greater than a configured or predefined amount.

[0218] The WTRU may perform resource reselection when pending data from one or more SL logical channels is not included in any SL grant within a configured or predetermined time period.

[0219] The WTRU may perform resource reselection when the amount of data in a buffer associated with one or more logical channels (e.g., one or more logical channels associated with a particular data rate requirement) exceeds a threshold. The threshold may be based on or may be derived from one or more of the following: configured or predetermined, configured LCP parameters such as PBR, BSR, etc. for the one or more logical channels, the current size of the grant(s) associated with one or more configured SL processes, the period of one or more SL processes (e.g., the time between consecutive grants), the maximum allowable size of a grant (e.g., a one-time grant or a periodic grant), the number of subchannels in a BWP and / or carrier and / or the number of subchannels in a BWP and / or carrier set, a measured CBR, or a CQI report from a peer WTRU for a unicast or multicast link.

[0220] The WTRU may perform resource reselection if the amount of data in one or more buffers of a logical channel is greater than k*PBR*BSD, where k may be configurable or predetermined (e.g., configured or predetermined by the network), and BSD (bucket size duration) may indicate an amount of time during which data associated with the logical channel is buffered at PBR (prioritized bit rate) until the bucket size associated with the logical channel is reached.

[0221] If the amount of data in one or more buffers of a logical channel is greater than k*M*PBR, the WTRU may perform resource reselection, where M may represent the total grant size of one or more (e.g., all) pending SL grants or processes divided by the total number of logical channels, and k may be configurable or predetermined (e.g., configured or predetermined by the network).

[0222] If the PBR of the LCH is greater than k*M*f, the WTRU may perform resource reselection, where M may represent the total grant size or the average grant size of one or more periodic SL processes, f may represent the average frequency of one or more SL processes (e.g., how often they occur), and k may represent a configured or predetermined parameter (e.g., configured or predetermined by the network).

[0223] The WTRU may determine a SL process on which the WTRU may perform resource reselection. The WTRU may perform resource reselection on a SL process or a subset of SL processes following a reselection trigger related to a data rate. The WTRU may select one or more SL processes (e.g., from a configured set of SL processes) on which to perform resource reselection based on one or more of the following rules:

[0224] The WTRU may select the SL process(es) having the minimum or maximum grant size, or a SL process whose grant size has been configured to be associated with the QoS parameters configured for the LCH.

[0225] The WTRU may select the SL procedure whose next configured grant occurs first relative to the trigger for resource reselection.

[0226] The WTRU may select the SL process with the shortest / largest periodicity, or select the SL process whose periodicity has been configured to be associated with the QoS parameters configured for the LCH.

[0227] The WTRU may select a SL process that complies with (eg, conforms to) a mapping restriction or mapping preference between logical channels and SL processes. The mapping restriction or preference may be based on the periodicity of the traffic associated with the LCH and / or the periodicity of the SL process.

[0228] The WTRU may select a SL process such that any increase or decrease in the grant size associated with the SL process does not cause the WTRU to exceed a maximum configured grant size or fall below a minimum configured grant size for the SL process.

[0229] The WTRU may select a SL procedure initiated by the WTRU as a result of initiation of the LCH or SLRB.

[0230] The WTRU may select the SL procedure for which the reselection counter is the smallest or largest.

[0231] The WTRU may select one or more SL processes (e.g., any SL process) to which the LCH that triggered the reselection may be mapped. Such mapping may be configured based on a delay associated with the LCH configuration and / or a corresponding periodicity of the one or more SL processes.

[0232] The WTRU may trigger resource reselection on multiple SL processes in response to one or more (e.g., any) of the rate-related triggers described herein. For example, the WTRU may determine that performing resource reselection on one sidelink process may cause the WTRU to exceed the maximum reserved / selected data rate. In this case, the WTRU may select one or more other SL processes and perform resource reselection to reduce the total amount of reserved / selected resources to below the maximum reserved / selected data rate. If there are one or more SL processes associated with the least stringent QoS requirements (e.g., lowest priority), the WTRU may select such an association. The WTRU may select one or more SL processes with the largest current reselection counter.

[0233] The WTRU may determine whether to maintain the reserved resources and the amount of time to maintain the resources based on one or more QoS parameters. The WTRU may decide the amount of time to maintain the reserved resources for the sidelink process based on factors associated with the QoS requirements of one or more SLRBs mapped to the sidelink process. The WTRU may determine the number of periods (which may correspond to an amount of time) during which resources should be reserved based on one or more of a data rate-related parameter, a latency-related parameter, a minimum communication-related parameter, a random number selected by the WTRU, a preconfigured value or factor, a congestion-related parameter (e.g., a channel busy ratio), or the broadcast of (one or more) SLRBs currently operating.

[0234] The WTRU may determine a time period during which a set of resources may be reserved for a side link process. The WTRU may determine the number of times a set of resources may be reserved for a side link process. The WTRU may perform either or both of the above determinations during a resource selection process for the side link process. The WTRU may perform either or both of the foregoing determinations based on a total maximum rate of the reserved resources. The WTRU may be configured with a mapping between a calculated maximum rate of the reserved resources and the number of repetitions of the SL process. For example, the WTRU may be configured with a mapping between a maximum rate, a CBR, and / or a number of resources that may be reserved during a resource selection process for the SL process.

[0235] The WTRU may determine whether it may perform resource reselection for a sidelink process based on one or more (e.g., any) of the factors described herein. For example, the WTRU may determine whether it may reserve resources for a sidelink process based on whether the measured CBR is above or below a configured threshold when performing resource reselection for one or more SL processes.

[0236] Resource and / or carrier selection / reselection may be performed for unicast communications. For unicast communications, resources may be synchronized between multiple (e.g., two) WTRUs, for example, to avoid half-duplex issues between WTRUs. Carriers may be synchronized, for example, because a WTRU may transmit HARQ feedback for another WTRU's transmission, and the data and HARQ feedback may be on the same carrier.

[0237] The following may apply to multiple carriers (e.g., in the context of a WTRU operating on multiple carriers) and / or resources. The resources may include time / frequency / beam resources. Resource selection may include selecting a set of resources within a resource pool (e.g., which may be repeated periodically). Resource selection may include selection of a resource pool or resource pattern within a pool / pattern set.

[0238] A WTRU in a unicast link may be responsible for resource / carrier reselection. For example, one of two WTRUs may be denoted as the WTRU responsible for performing resource / carrier reselection. The responsible WTRU may be determined based on one or more of the following.

[0239] The responsible WTRU may correspond to a WTRU that is configured to perform a specific role in the link establishment procedure. For example, the responsible WTRU may be the WTRU that initiates the link establishment procedure.

[0240] The responsible WTRU may correspond to the WTRU with the lowest or highest value of the observed quality metric for unicast (e.g., with respect to a resource pool or a set of allowed resources). For example, multiple WTRUs may periodically exchange measured CBRs, and the responsible WTRU may be selected as the WTRU with the lowest or highest CBR.

[0241] The responsible WTRU may correspond to the WTRU with the highest or lowest value of a configured or preconfigured parameter or identifier. For example, the WTRU with the highest or lowest L2 ID may be denoted as the responsible WTRU.

[0242] The responsible WTRU may correspond to a WTRU having certain coverage characteristics with respect to the network and / or synchronization source. In an example, a WTRU synchronized with a synchronization source closest to the gNB (e.g., in terms of synchronization level) may be determined as the responsible WTRU. In an example, a WTRU with a better Uu RSRP at a given time may be denoted as the responsible WTRU.

[0243] The WTRU may perform carrier / resource reselection based on metrics associated with resources used by a peer WTRU. The WTRU may perform resource / carrier reselection based on certain triggers related to the peer WTRU (e.g., which may be related to QoS) and / or triggers related to resources used to communicate with the peer WTRU. The WTRU may perform resource / carrier reselection based on (e.g., as a result of) one or more of the following.

[0244] The WTRU may perform resource / carrier reselection based on receiving an indication or request to perform carrier / resource reselection. The WTRU may transmit / receive a carrier / resource reselection request to / from another WTRU. For example, the WTRU may perform carrier / resource reselection in response to receiving a request from another WTRU. The WTRU may transmit a carrier / resource reselection request to a peer WTRU in response to a change in the CBR or similar measurement of channel occupancy by the WTRU. The WTRU may transmit a carrier / resource reselection request to a peer WTRU based on a counter of the number of periodic or non-periodic data / PDUs transmitted by the WTRU reaching a preconfigured value. The WTRU may transmit a carrier / resource reselection request to a peer WTRU based on a change in the resource pool configuration at the WTRU. The WTRU may transmit a carrier / resource reselection request to a peer WTRU based on the WTRU being unable to transmit feedback (e.g., HARQ or CSI) to the peer WTRU using the currently configured carrier / resource (e.g., due to TX carrier restrictions). The WTRU may transmit a carrier / resource reselection request to a peer WTRU in response to data arriving at the WTRU (e.g., the data may have new / different QoS requirements). The WTRU may transmit a carrier / resource reselection request to a peer WTRU based on any other suitable trigger associated with the data rate mentioned herein.

[0245] The WTRU may perform resource / carrier reselection in response to receiving quality information from a peer WTRU, such as quality information related to configured resources and / or carriers for the peer WTRU. The WTRU may perform carrier / resource reselection based on quality information reported by the peer WTRU. The WTRU may transmit quality information, such as quality information associated with resources / carriers configured for use between the WTRU and the peer WTRU. Such quality information may include (one or more) CBR measurements and / or similar measurements of load on a resource and / or set of carriers configured for use between two WTRUs. Such quality information may include RSRP / RSRQ / CQI of known signals transmitted by the peer WTRU, etc. Such quality information may include measured RSSI of resources and / or resource sets on one or more carriers. Such quality information may include HARQ metrics, such as the number of HARQ ACK / NACKs for each resource or resource set associated with a carrier.

[0246] The WTRU may receive quality information from a peer WTRU and may perform carrier / resource reselection based on the quality information. For example, if the CBR reported by the peer WTRU is below a threshold, the WTRU may perform carrier / resource reselection. If the RSSI measured on a set of resources reported by the peer WTRU is below a threshold, the WTRU may perform carrier / resource reselection.

[0247] The WTRU may perform resource / carrier reselection based on its own resource quality measurements, which may include quality metrics measured by the WTRU itself on a set of resources. Such quality metrics may include (one or more) CBR measurements or similar measurements of load on a set of resources. Such quality metrics may include RSRP / RSRQ / CQI, etc. of known signals transmitted by peer WTRUs. Such quality metrics may include measured RSSI of resources and / or resource sets on one or more carriers. Such quality metrics may include HARQ metrics, such as the number of HARQ ACK / NACKs per resource or resource set associated with a carrier.

[0248] The WTRU may perform resource / carrier reselection based on a combination of quality information measured by the WTRU and quality information reported by a peer WTRU. The WTRU may perform carrier / resource reselection based on its own quality metrics and / or quality information reported by a peer WTRU. For example, the WTRU may determine a weighted average of some quality metric (e.g., CBR) between its own measured value(s) and the value(s) reported by a peer WTRU, and may perform resource reselection if the combined average is below a configured threshold.

[0249] The WTRU may send an indication of a performed carrier / resource reselection to a peer WTRU. The WTRU may perform a carrier / resource reselection and may send an indication of such selection / reselection to a peer WTRU. For example, the WTRU may send such an indication if the carrier / resource reselection may affect the resources / carrier used by the peer WTRU. For example, the WTRU may send such an indication if the carrier / resource reselection may affect the resources used by the peer to send HARQ feedback or when two WTRUs share a common carrier.

[0250] The indication regarding the carrier / resource reselection may include one or more new carriers / resources in a new set of carriers / resources selected by the WTRU, or a time at which the new carriers / resources may start to be used.

[0251] The WTRU may send an indication regarding carrier / resource reselection using one or more of the following: SL MACCE, SL RRC message, or an indication on a dedicated sidelink physical channel, such as an SCI with a specific field (e.g., having the content of the indication included in a physical sidelink shared channel or PSSCH).

[0252] Logical channel prioritization or LCP may take into account that a transmission may be sent to one or more destinations (e.g., one or more WTRUs). For example, an LCP may obtain data from multiple relevant destinations to satisfy a grant (e.g., a single grant). A WTRU may be configured with one or more destinations (e.g., a destination group or a destination set), for example, as a LCP restriction or as part of an LCP restriction.

[0253] In an example, a WTRU may be configured to have one or more destination addresses (e.g., a destination address group or a destination address set), such as an L2 destination ID. These destination addresses may be considered common from an LCP restriction point of view. In an example, a WTRU (e.g., a current WTRU) may multiplex PDUs for different destination addresses (e.g., different WTRUs connected to the current WTRU via a sidelink), provided that these destination addresses belong to a group or set (e.g., a configured set of destinations or WTRUs, or a configured set of destinations or WTRUs). In an example, a WTRU may be configured not to multiplex PDUs for destinations associated with different groups or sets in the same transmission.

[0254] The WTRU may be configured with a group or set of destination addresses in various ways, including, for example, upper layer (e.g., RRC) signaling. For example, the WTRU may receive information (e.g., configuration) about the L2 destination addresses associated with the group from upper layers (e.g., V2X layer, non-access stratum or NAS layer, RRC layer, etc.). The WTRU may derive information about one or more L2 destination addresses associated with the group based on upper layer signaling (e.g., based on signaling at the V2X layer, non-access stratum or NAS layer, RRC layer, etc.).

[0255] The WTRU may receive a configuration for a group or set of destination addresses from the network. For example, the WTRU may receive an RRC message from the network with a list of destination addresses that may be relevant (eg, the destination addresses may form or belong to a group).

[0256] The WTRU may be implicitly configured with a group or set of destination addresses, for example, based on an L2 destination ID (e.g., a string of bits that identifies different destination addresses or devices). For example, the WTRU may identify (e.g., determine) one or more WTRUs that may be part of the same group based on the relationship between the L2 destination IDs of these destinations (e.g., based on the destination addresses having a common set of MSBs or LSBs and / or based on some other inspection of the L2 destination IDs). The WTRU may provide such grouping under the condition that the L2 destination ID is associated with unicast and / or multicast. For example, multicast destination IDs may be grouped and unicast destination IDs may be grouped. In an example, the multicast ID may not be grouped with the unicast ID. In an example, the multicast ID may be grouped with the unicast ID, for example where the unicast ID is associated with a destination that is also associated with the multicast ID.

[0257] In an example, a grant may serve (e.g., may be designated for) a single destination, and this may result in starvation of lower priority destinations. For example, such a situation (e.g., resource starvation) may be during logical channel prioritization, when a destination address with the highest priority data is selected (e.g., to use the grant) and / or when a grant is filled with data associated only with the destination. The WTRU may be configured to select a destination address associated with a grant, the selection being based on (one or more) bucket sizes (e.g., bucket size parameters) associated with the destination, such as so that the destination may represent a single destination or a set of destinations based on one or more LCP restrictions associated with a set or group of destinations. In an example (e.g., when selecting a destination address for a grant), if multiple destinations are associated with the same group, the WTRU may select the multiple destinations. In an example (e.g., when selecting multiple destinations associated with the same group for a grant, or when performing destination selection based on the priority of the LCHs), the WTRU may consider multiple (e.g., all) LCHs associated with the same group of destinations together and decide whether the destination or group of destinations should be selected.

[0258] The WTRU may select (e.g., at the start of an LCP procedure) the logical channel(s) to be served by the grant by determining the prioritized bit rates of the one or more (e.g., all) logical channels associated with the destination. For example, the WTRU may select a destination address or a set of destination addresses, and the logical channel(s) associated with the one or more destination addresses may be processed based on a bucket size parameter (e.g., bucket size (Bj) associated with logical channel j) and / or a measurement of prioritized bit rate (PBR) of the logical channel(s) associated with the one or more destination addresses.

[0259] The WTRU may be configured to consider a subset of logical channels (e.g., only a subset) when evaluating criteria for destination address selection. Such a subset of logical channels may be defined based on specific QoS requirements (e.g., minimum communication range, priority, latency, etc.). For example, the WTRU may be configured to meet one or more criteria when selecting a destination address by considering only logical channels associated with a specific priority or a specific set of priorities. For example, such a priority or a set of priorities may be provided with a grant (e.g., for Mode 1), or the priority or set of priorities may be associated with an attribute of a resource selection result (e.g., for Mode 2).

[0260] In one or more (e.g., any) examples provided herein, the WTRU may be configured to consider logical channels that meet certain LCP restrictions (e.g., in addition to other criteria specified herein). For example, the WTRU may be configured with LCP restrictions based on grant type (e.g., a given logical channel may be allowed or not allowed to use a certain type of grant). In these cases, when selecting a destination address (e.g., to use a certain type of grant), the WTRU may consider LCHs that are allowed to use the certain type of grant, and the WTRU may not consider LCHs that are not allowed to use the certain type of grant. For example, when the WTRU is configured to perform destination selection based on a combination of priority and / or PBR (e.g., as described herein), the WTRU may consider LCHs that are allowed to use a certain type of grant.

[0261] The WTRU may select a destination address using one or more criteria described herein. For example, the WTRU may select a destination address associated with a logical channel having the highest priority and / or Bj>0. When selecting a destination address, the WTRU may use one or more criteria. For example, the WTRU may select a destination address using a first criterion. If more than one destination address satisfies the first criterion and / or if multiple destination addresses share the same parameter value associated with the first criterion, the WTRU may select a destination address using a second criterion. If no destination address satisfies the first criterion, the WTRU may select a destination address using a second criterion. These rules may be extended (e.g., generalized) to any number of criteria. For example, if more than one destination address satisfies the (n)th criterion, the WTRU may consider the (n+1)th criterion. Similarly, if no destination address satisfies the (n)th criterion, the WTRU may consider the (n+1)th criterion.

[0262] The WTRU may select a destination address for which Bj (e.g., the bucket size associated with a logical channel with pending data) has the largest non-zero value. If multiple destination addresses are associated with logical channels having the same Bj value, the WTRU may select the destination address with the highest priority. If multiple destination addresses are associated with respective logical channels (e.g., logical channels with pending data) having the same Bj value and the same priority, the WTRU may select the destination address (e.g., among the multiple logical channels) so that satisfying the grants for the (one or more) logical channels associated with the destination address (e.g., using the grants) will minimize the total amount of data selected for transmission that exceeds Bj for the logical channel associated with the selected destination address. For example, when multiple destination addresses are associated with respective logical channels having the same Bj value and the same priority, the WTRU may select a destination address that results in the smallest amount of grants being used for data transmission exceeding Bj (e.g., the sum of data transmitted on each logical channel j exceeding Bj is minimized).

[0263] Figure 2 It shows how the WTRU determines the destination for which a sidelink resource set (e.g., a granted set in mode 1 or an autonomously selected set of resources in mode 2) can be used. As shown, the WTRU may have six logical channels, LCH1-LCH6, which have available data to transmit. The data associated with each logical channel may include prioritized data (e.g., data that, if sent, would satisfy Bj associated with the logical channel) and / or non-prioritized data (e.g., data that, if sent, would exceed Bj associated with the logical channel), and each logical channel may be associated with a destination. For example, LCH1 and LCH2 may be associated with destination D1 and may have both prioritized data and non-prioritized data. LCH3 and LCH4 may be associated with destination D2 and may have only non-prioritized data. LCH5 and LCH6 may be associated with destination D3 and may have both prioritized data and non-prioritized data. In an example scenario, the six logical channels may have equal priority and the WTRU may, in response to determining that the side link resource set has become available, select D1 as the transmission destination because transmission to D1 may result in the least amount of grant being used for non-prioritized data (e.g., compared to transmission to D2 or D3).

[0264] For one or more of the criteria described herein (for determining a destination address), the WTRU may consider the amount of data that it may multiplex from one or more logical channels associated with the destination based on a subset of logical channels that meet certain QoS constraints. For example, when evaluating a criterion based on the amount of data multiplexed into a grant for a particular logical channel, the WTRU may consider that only data that is subject to the QoS requirements may be multiplexed into the grant.

[0265] The WTRU may select a destination address with a maximum or minimum value for a QoS parameter. For example, the WTRU may select a destination address that has pending data and is associated with a logical channel with a maximum or minimum value for a QoS-related parameter. For example, the WTRU may select a destination address that is associated with a logical channel with the highest priority from a set of logical channels with pending data (e.g., all logical channels). For example, the WTRU may select a destination address associated with a logical channel with a minimum delay budget. The QoS parameters used for the decision may be configured by an upper layer (e.g., a network or NAS layer). Other QoS parameters including reliability and minimum communication range may also be used for this purpose.

[0266] The WTRU may select (e.g., select only) one or more destinations whose bucket size (e.g., Bj) is greater than a threshold (e.g., greater than 0). In an example, the WTRU may select a destination address that has at least one logical channel that has pending data and Bj>0. The WTRU may select a destination address associated with the highest priority logical channel. For example, in the case where multiple destinations have (one or more) logical channels with Bj>0, the WTRU may select a destination address associated with the highest priority logical channel.

[0267] The WTRU may select one or more destinations with the largest bucket size (e.g., as represented by Bj) for the logical channel. In an example, the WTRU may select a destination address associated with a logical channel with pending data and a maximum bucket size (e.g., as represented by Bj) such that the bucket size is greater than a threshold (e.g., greater than 0). In an example (e.g., in the case where multiple destinations have (one or more) logical channels and the logical channels have the same bucket size), the WTRU may select the destination with the highest priority logical channel for a given grant.

[0268] The WTRU may select one or more destinations that have a maximum total bucket size (e.g., as represented by the sum of Bj) for all or a subset of the logical channels associated with each of the destination(s). In an example, the WTRU may select a destination address with a maximum total bucket size (e.g., the total bucket size of all logical channels associated with the destination). In an example, the WTRU may select a destination address with a maximum total bucket size among all logical channels (e.g., logical channels with pending data) where Bj>0. In an example (e.g., where multiple destinations have the same total bucket size), the WTRU may select a destination with a highest priority logical channel. In an example, the WTRU may select a destination address with a maximum total bucket size of logical channels that share a particular parameter value (e.g., have the same priority). For example, the WTRU may select a destination address with a maximum total Bj associated with a particular priority. The particular priority may correspond to a priority of a highest priority LCH with data available from a destination (e.g., among multiple destinations).

[0269] The WTRU may select destinations such that the amount of wasted resources associated with the grant may be reduced or minimized. For example, the WTRU may select destinations such that the difference between the size of the grant and the actual buffer size of one or more (e.g., all) logical channels associated with the destination may be reduced or minimized (e.g., in the case where the grant is larger than the total buffer size of the logical channels associated with the destination). In an example (e.g., when there is at least one destination with a total buffer size larger than the grant), the WTRU may select any of these destinations.

[0270] The WTRU may compare the total buffer sizes of the logical channels associated with each destination and select the destination with the largest total buffer size.

[0271] The WTRU may select a destination associated with the highest priority logical channel and having a bucket size greater than a certain threshold (e.g., Bj>0). In an example, the WTRU may select a destination address of the highest priority logical channel with Bj>0, and the WTRU may identify one or more logical channels having respective bucket size parameters (e.g., Bj) with values ​​greater than zero in response to determining that a set of resources are available for the WTRU to perform a transmission. The WTRU may also identify a logical channel with the highest transmission priority from the one or more logical channels. The WTRU may then select the destination associated with the highest priority logical channel as the destination for the transmission (e.g., as the destination for a usage grant). In an example (e.g., in a case where multiple destination addresses are associated with one or more logical channels with Bj>0 and the same priority), the WTRU may select a destination based on one or more of the following.

[0272] In an example where multiple destination addresses are associated with logical channels with Bj>0 and having the same priority, the WTRU may select a destination address in response to determining that the destination address is associated with a logical channel with Bj>0, where the particular logical channel has the largest Bj value among the multiple destination addresses (e.g., among the logical channels associated with the multiple destination addresses).

[0273] In an example where multiple destination addresses are associated with (one or more) logical channels with Bj>0 and the same priority, the WTRU may select the destination in response to determining that the destination has the largest total bucket size value (e.g., the total bucket size may correspond to the sum of the bucket sizes of all logical channels associated with the destination).

[0274] In the example where multiple destination addresses are associated with (one or more) logical channels with Bj>0 and the same priority, the WTRU may select the destination address based on any other conditions associated with the selection of the destination address described herein (e.g., based on a previous selection, based on the PRB, based on the bucket size, based on the destination of the maximum number of logical channels authorized that can satisfy Bj>0, etc.).

[0275] The WTRU may select a destination based on a previous selection. This may ensure fair selection of destinations associated with logical channel(s) with Bj>0. For example, the WTRU may determine a set of destination addresses associated with logical channels with Bj>0 and may select one or more destinations sequentially (e.g., in a round-robin manner) between different initiations of the LCP procedure upon grant reception. The sequential selection of destination addresses (e.g., logical channels with Bj>0) may be weighted to prioritize certain destinations based on one or more of the following:

[0276] The weighting may be based on the priority of the logical channel(s) with Bj>0, in an example, the destination with the highest priority logical channel may be served first in the sequence of destination addresses. In an example, the destination with the highest priority logical channel may be served more frequently in the sequence of destination addresses.

[0277] The weighting may be based on the value of Bj of the logical channel(s) associated with the destination.For example, the destination with the largest Bj or the largest total Bj may be served first or more frequently in the sequence of destination addresses.

[0278] The weighting may be based on a prioritized bit rate (PBR) or total PBR value of the destination. For example, the destination with the highest PBR value for a particular logical channel or the destination with the highest total PBR value (e.g., the sum of PBRs) on multiple (e.g., all) logical channels may be served first in the sequence, or may be served more often in the sequence.

[0279] The WTRU may select a destination based on PBR. For example, the WTRU may select a destination address that has the highest PBR for a particular logical channel or has the highest total PBR (e.g., the sum of PBRs) over multiple (e.g., all) logical channels. The WTRU may use such selection criteria under certain conditions (e.g., under the condition that both destinations are associated with one or more logical channels with Bj>0 and / or both destinations are associated with one or more logical channels with the highest priority among multiple destinations).

[0280] The WTRU may select a destination for which the grant can satisfy the maximum number of logical channels (e.g., logical channels with Bj>0). In an example, the WTRU may select a destination address such that, when applied to logical channels associated with the destination, the pending grant can satisfy the maximum number or percentage of logical channels with Bj>0 and / or a particular priority (e.g., logical channels associated with the destination). For example, a destination address may be selected such that it satisfies Bj>0 and / or the maximum number of logical channels with a priority greater than a particular threshold. For example, a destination address may be selected such that it satisfies the maximum number or percentage of logical channels with Bj>0 associated with the destination address, where the number or percentage of logical channels is associated with the highest priority among those logical channels with Bj greater than 0. For example, a destination address with more than one logical channel with Bj>0 may be selected for a particular grant in the following case: when the grant is used, the grant can satisfy all logical channels with Bj>0, then.

[0281] The WTRU may select the destination with the largest weighted Bj (e.g., bucket size). The WTRU may apply a weight (k) to the value of Bj associated with one or more logical channels (e.g., with each logical channel) and may select the destination address associated with the logical channel that has pending data and has the largest value of k*Bj>0 across all logical channels. The WTRU may select the destination address with the largest total value of k*Bj across all logical channels that have pending data and are associated with the destination. The WTRU may select the destination address with the largest total value of k*Bj across all logical channels associated with the destination and with Bj>0.

[0282] The WTRU may be configured with a weight (k) to be applied to one or more logical channels described herein. The WTRU may determine the weight based on one or more of the following.

[0283] The WTRU may determine the weight based on any relevant QoS parameters or priority of the logical channel. For example, the WTRU may apply a weight configured for a given priority, latency, reliability, minimum communication range, and / or other characteristics of the logical channel.

[0284] The WTRU may determine the weight based on the PRBs configured for the logical channel. For example, the WRU may determine the weight from the PBR based on a mapping of PBR to weight (k).

[0285] The WTRU may determine the weight based on the broadcast type associated with the destination (unicast, multicast, broadcast, etc.). For example, the WTRU may apply different weights (e.g., configured weights) for one or more broadcast types (or each broadcast type).

[0286] The WRU may minimize the amount of data transmitted in a grant that exceeds Bj (eg, minimize the use of grants for non-prioritized data).

[0287] The WTRU may select a destination so as to minimize the total amount of data in a grant (e.g., the total amount of data transmitted using the grant) that exceeds the respective Bj of one or more logical channels associated with the destination. For example, in selecting a destination, the WTRU may select logical channels to be multiplexed into the grant based on one or more Uu LCP rules (e.g., currently determined or preconfigured LCP rules). Such rules may include, for example, first satisfying Bj>0 and then filling the grant with pending data from one or more logical channels that exceeds the Bj of these logical channels (e.g., if the grant allows these actions). The WTRU may select a destination so as to minimize the total amount of data (e.g., data that exceeds the non-zero Bj of one or more logical channels) that is multiplexed onto the grant (e.g., when the grant is greater than zero). The WTRU may select a destination such that the grant is primarily used to satisfy the pending data of one or more logical channels associated with a current bucket size (e.g., such a current bucket size may be preconfigured).

[0288] The WTRU may select a destination that satisfies all or a certain percentage (e.g., a majority) of the configured bucket sizes. For example, the WTRU may select a destination so that the received grant can accommodate all data or the maximum amount of data for logical channels with Bj>0. The WTRU may select a destination so that after performing the LCP, the respective Bj of all or a certain percentage of logical channels with pending data is equal to or less than zero (e.g., Bj<=0). The WTRU may select a destination for which the grant can accommodate the largest portion of the data associated with the bucket size of the logical channels with pending data. In the example, the WTRU may select a destination so that the total Bj of logical channels with pending data after the LCP and for which Bj is still>0 is minimized. In the example, the WTRU may select a destination so that the total Bj of logical channels with pending data after the LCP and for which Bj is still>0 can minimize the ratio of the total Bj to the grant size.

[0289] The WTRU may select a destination that satisfies a certain percentage (e.g., a majority) of logical channels with pending data. For example, the WTRU may select a destination for which a grant may accommodate a majority (e.g., a majority) of the pending data for logical channels associated with the destination. The WTRU may select a destination for which all or a majority of logical channels may have no remaining data after execution of the LCP. For example, the WTRU may select a destination for which the remaining data on any logical channel associated with the destination is minimized.

[0290] The WTRU may select a destination such that the bucket size of one or more logical channels associated with the destination or the total bucket size of all logical channels associated with the destination (e.g., logical channels with pending data) is above a certain threshold. For example, if the total Bj among all logical channels associated with a destination and / or with pending data is above a preconfigured threshold, the WTRU may be allowed to select the destination.

[0291] The WTRU may select a destination based on a bucket size (or equivalent metric) associated with the destination address. For example, the WTRU may maintain a variable Bd corresponding to a bucket size (e.g., a total bucket size for all logical channels) associated with (e.g., each) destination address. The WTRU may initialize Bd (e.g., with a value of zero) when a logical channel associated with destination d is initiated. The WTRU may increase Bd by a PBR*T based on the destination, where T may represent the time since the last LCP procedure. The WTRU may select a destination address with a maximum Bd>0. The WTRU may select a destination address with the highest priority logical channel with pending data and Bd>0. The WTRU may determine the value of the PBR for a particular destination based on the configured PBR of one or more (e.g., each) logical channels associated with the destination. The WTRU may be configured with a value of the PBR for (e.g., each) destination address.

[0292] The WTRU may be restricted from selecting the same destination address continuously. The WTRU may select a destination address using one or more criteria discussed herein. The WTRU may be configured with restrictions on how often or how frequently the WTRU may select the same destination address in subsequent (e.g., consecutive) LCP procedures. Such restrictions may be conditioned on or applied to the following scenarios: the WTRU selects a destination address from multiple destination addresses with Bj>0, or when there are multiple destination addresses that meet at least one of the criteria described herein. For example, after selecting a destination address for an LCP, if there is another destination address that meets one or more criteria described herein, the WTRU may exclude selecting the same destination address for the next N LCP procedures and / or authorizations. The value of N may be configurable and may further depend on one or more of the following: the number of destination addresses configured for transmission by the WTRU, the number of destination addresses associated with a logical channel with Bj>0 at a given time, or the number of destination addresses for logical channels with one or more PDBs greater than a threshold.

[0293] In an example, after selecting a destination address for LCP, the WTRU may exclude selection of the same destination for LCP for a specific time period. The duration of the time period may depend on similar conditions or factors as described above. For example, if there are one or more other destination addresses that also meet the criteria discussed herein (e.g., Bj>0, etc.), the exclusion may be applied. The WTRU may use a timer for the destination address (e.g., associate a timer with the destination address). For example, the timer may be a destination starvation avoidance timer. The timer may reflect the amount of time that has passed since the destination was last selected by the LCP procedure. For example, the WTRU may start a timer for the destination address when data is received on a logical channel associated with the destination address (e.g., a logical channel with Bj>0). When the timer associated with the destination address expires, the WTRU may select the destination address (e.g., select the destination address again).

[0294] The WTRU may determine which decision criteria to use for destination address selection or the order in which these criteria should be used based on channel conditions. For example, one measure of such channel conditions may be the channel busy ratio of the side link (SL). When the channel busy ratio of the SL is above a threshold, the WTRU may select the destination address based on priority (e.g., based on the destination with the highest priority logical channel). When the channel busy ratio is below a threshold, the WTRU may select the destination based on the logical channel with the maximum Bj>0. The WTRU may use one or more of the other criteria discussed herein for destination selection based on channel conditions.

[0295] The WTRU may determine which decision criteria to use for destination address selection or the order in which these criteria should be used based on which decision criteria are more critical at the time of LCP. Such criticality may be determined based on the associated values ​​of the parameters used for the selection. For example, when the measured value of the total Bj for the destination is greater than a certain threshold, the WTRU may use one or more criteria associated with the total Bj (e.g., having a value greater than zero) for destination selection. When the measured value of the total Bj for the destination is equal to or less than the threshold, the WTRU may use one or more criteria associated with the maximum Bj of a single logical channel (e.g., having a value greater than zero). For example, if at least one logical channel has pending data with a priority higher than a certain threshold, the WTRU may use the priority of the logical channel as a criterion for determining the destination address, and if no logical channel has pending data with a priority higher than the threshold, the WTRU may use another criterion to determine the destination address. The WTRU may use one or more other criteria discussed herein for destination selection based on the criticality of the criteria.

[0296] The WTRU may be configured to have one or more destination addresses that should be given a higher priority or weight when considering destination selection under any of the decision criteria discussed herein. For example, the WTRU may be configured to apply an offset to one or more decision criteria values ​​(e.g., Bj, priority, etc.) when comparing different destination addresses using the decision criteria. To illustrate, the WTRU may be configured to select one destination over another when both destinations meet a particular criterion or have the same value for a particular metric (e.g., Bj, priority, etc.). In an example, the destinations given a higher priority may be those associated with a particular broadcast. For example, the WTRU may prioritize destination addresses associated with unicast over destination addresses associated with multicast or broadcast.

[0297] The WTRU may use a combination of criteria for destination selection.

[0298] In an example, the WTRU may select a destination address with the highest priority logical channel that has data available in the WTRU's buffer and the current value of Bj>0. In an example (e.g., if there is no LCH with Bj>0), the WTRU may select a destination address with the highest priority LCH. In an example (e.g., if there are multiple destination addresses with Bj>0, and where the highest priority LCH is the same for the multiple destination addresses), the WTRU may select a destination that minimizes the amount of data (e.g., data transmitted using the grant) that exceeds Bj, or the WTRU may select a destination with the largest total Bj (e.g., for the highest priority), as described herein.

[0299] In an example, the WTRU may select the destination with the highest priority LCH. If multiple destinations have the same highest priority LCH, the WTRU may select the destination with the maximum value of Bj associated with that destination address. These selection techniques may be used in conjunction with other techniques described herein (e.g., for the case where there is no LCH with Bj>0).

[0300] The WTRU may perform one or more of the following operations after destination selection. The WTRU may perform an NR Uu-based LCP procedure on logical channels associated with the selected destination. For example, the WTRU may attempt logical channels that satisfy Bj>0 in descending order of priority. As described herein, a WTRU that selects a destination group may perform such an LCP procedure on one or more (e.g., all) logical channels of the destinations associated with the destination group. For example, the WTRU may (e.g., on all logical channels in the selected destination group) attempt to satisfy Bj>0 in one or more (e.g., all) destinations associated with the selected logical channel group in descending order of priority.

[0301] The WTRU may be configured to adjust one or more parameters or behaviors, such as those associated with starvation avoidance, based on congestion conditions. For example, the WTRU may adjust parameters and / or behaviors related to LCP based on measured congestion conditions of the sidelink (e.g., using a channel busy ratio or CBR). Starvation avoidance may refer to rules, operating parameters, behaviors, efforts, etc., applied by the network and / or the WTRU so that the WTRU may avoid or mitigate a shortage of resources for sending or receiving transmissions.

[0302] The WTRU may be configured to change and / or alternate the values ​​of one or more of the following parameters configured based on the presence and / or level of congestion associated with the sidelink resources. These parameters may include, for example, a prioritized bit rate (PBR) of one or more logical channels, a bucket size duration (BSD) of one or more logical channels, and / or bucket size parameters (e.g., Bj and / or similar bucket size parameters).

[0303] The WTRU may be configured to have different PBR values ​​for a given logical channel (e.g., depending on the measured congestion level). For example, the WTRU may be configured to apply a first PBR for a logical channel when the measured CBR meets a first criterion (e.g., when the measured CBR is within a first configured range of CBRs), and to apply a second PBR for the logical channel when the measured CBR meets a second criterion (e.g., when the measured CBR is within a second configured range of CBRs).

[0304] The WTRU may be configured to operate in one or more of the following ways (e.g., modify one or more LCP-related behaviors) based on congestion conditions. The WTRU may decide whether to select the amount of data based on Bj based on the CBR. The WTRU may decide to perform or skip starvation avoidance during the LCP based on the measured congestion conditions. For example, if the measured congestion conditions meet a first criterion (e.g., the measured congestion level is within a first configured range of CBR), the WTRU may perform LCP by selecting the amount of data up to the value of Bj from the selected logical channel. If the measured congestion conditions meet a second criterion (e.g., the measured congestion level is within a second configured range of CBR), the WTRU may perform LCP by selecting available data for the selected logical channel (e.g., selecting all available data if there is enough space in the corresponding grant). The WTRU may determine whether to select the amount of data based on Bj based on the specific logical channel involved. For example, the WTRU may be configured to have a separate CBR range within which the WTRU may perform starvation avoidance (e.g., select data based on Bj) or not perform starvation avoidance (e.g., select data up to the full amount of data available for the logical channel). Based on this configuration, the WTRU may decide (eg, for a specific instance of the LCP and / or a specific measured CBR) to select data based on Bj for a first logical channel and not to select data based on Bj for a second logical channel.

[0305] The WTRU may decide whether to consider Bj in destination address selection based on the CBR. The WTRU may start / stop considering Bj during destination address selection, for example for a subset of logical channels, based on the measured congestion level. For example, in case of high congestion (e.g., above a certain threshold), the WTRU may perform LCP by selecting the destination with the highest priority. In case of low congestion, the WTRU may perform LCP by selecting the destination with the highest priority and Bj>0. This is in similar conditions as discussed herein for starvation avoidance, where the WTRU may perform LCP by selecting the destination with the highest priority and Bj>0. For some logical channels, the WTRU may consider whether Bj is greater than 0, and for other logical channels, may not consider whether Bj is greater than 0. The WTRU may determine whether to consider Bj>0 based on the congestion level. For example, the WTRU may be configured with a per-logical channel congestion threshold to determine whether and / or when to start / stop consideration of Bj>0 during destination address selection.

[0306] The WTRU may decide whether to increase Bj based on measured congestion conditions. The WTRU may start, stop, or pause bucket size (e.g., Bj) calculation and / or accumulation based on measured congestion conditions. For example, the WTRU may freeze the value of Bj (e.g., not calculate and / or accumulate the value of Bj) when congestion increases (e.g., when the congestion level moves from below a configured threshold to above the configured threshold, or from one configured range to another configured range). The WTRU may continue Bj calculation when congestion decreases.

[0307] The WTRU may calculate Bj differently depending on the congestion conditions. The WTRU may calculate its bucket size (e.g., Bj) differently depending on the measured congestion conditions. For example, the WTRU may be configured with an offset and / or multiplication factor that the WTRU may apply in the calculation of Bj, for example, when the measured congestion level meets certain rules and / or conditions (e.g., when the congestion level is within the configured range of the CBR).

[0308] The WTRU may select the amount of data as a function of Bj. Such a function may depend on the measured congestion conditions. The WTRU may continue to apply starvation avoidance and / or calculation of Bj based on the PBR. The WTRU may consider a modified value of Bj, which may depend on the congestion conditions. For example, the WTRU may consider (e.g., only consider) data up to a certain percentage of Bj, where the percentage may depend on (e.g., may be based on) the congestion level and / or a specific logical channel. For example, the WTRU may be configured (e.g., for each logical channel) with a percentage of Bj for selecting the amount of data, where the percentage may depend on the measured CBR.

[0309] The WTRU may be configured to determine and / or change the SLRB configuration (eg, such as RLC mode) based on the CBR.

[0310] The WTRU may be configured with a CBR-based configuration corresponding to a QoS flow or QoS profile. The WTRU may change the SLRB configuration based on the measured CBR. For example, the WTRU may be provided with a different configuration for some or all parameters associated with the SLRB for (e.g., each) range of the measured CBR. The WTRU may change the SLRB configuration when the measured CBR changes from one range to another.

[0311] The WTRU may be configured to have different values ​​for one or more of the following parameters, for example, based on the measured CBR. For example, the WTRU may be configured to operate in different RLC modes based on the measured CBR (e.g., high CBR corresponds to RLC unacknowledged mode (UM), low CBR corresponds to RLC acknowledged mode (AM), etc.). The WTRU may be configured to determine and / or use a polling retransmission timer value (e.g., T-pollRetransmit timer value) based on the measured CBR. The WTRU may be configured to determine and / or use a maximum retransmission threshold (e.g., MaxRetxThreshold) based on the measured CBR. The WTRU may be configured to determine and / or use a prohibit timer value (e.g., T-statusProhibit timer value) based on the measured CBR. The WTRU may be configured to determine and / or apply an LCH priority based on the measured CBR. The WTRU may be configured to determine and / or apply a ConfiguredGrantType1Allowed value based on the measured CBR. The WTRU may be configured to determine and / or apply a PDCP discard timer value based on a measured CBR. The WTRU may be configured to determine and / or apply a PDCP T-Reordering timer value based on a measured CBR.

[0312] The WTRU may select a resource pool during a mobility event (e.g., during a handover). The WTRU may determine condition(s) for an exception resource pool. As used herein, the term exception resource pool may refer to certain resource pools that are utilized when certain conditions (e.g., atypical or exceptional conditions) are met. For example, the WTRU may determine whether to move a mode 1 transmission (e.g., a transmission associated with an LCH in mode 1) to an exception resource pool (e.g., use mode 2 transmissions on the exception resource pool) during an exceptional situation (e.g., during an RLF, beam failure, mobility event, etc.) based on one or more of the following conditions.

[0313] The WTRU may determine whether to use an exception resource pool based on the QoS of data associated with Mode 1 transmissions in the WTRU's buffer. For example, the WTRU may use an exception resource pool for transmissions associated with a subset of logical channels. The subset of logical channels may be determined based on the configuration of parameters associated with those logical channels (e.g., whether use of the exception pool is allowed for those logical channels). The subset of logical channels may be determined based on the QoS associated with those logical channels (e.g., PQI / PFI, MCR, GBR, etc.).

[0314] The WTRU may determine whether to use an exception resource pool based on the presence or configuration of resources for Mode 2 transmissions. For example, if the WTRU is not configured with a resource pool for Mode 2 transmissions and / or if the WTRU is not allowed to perform Mode 2 transmissions, the WTRU may use the exception resource pool for transmissions associated with Mode 1. If one or more Mode 2 resource pools are configured for transmissions that meet the QoS of one or more corresponding LCHs (e.g., if the LCH is not restricted to use Mode 2 resource pools), the WTRU may use the exception resource pool for transmissions associated with Mode 1.

[0315] The WTRU may determine whether to use an exception resource pool based on the type of beam failure recovery (BFR) initiated (e.g., based on whether the BFR is contention-based or contention-free). For example, the WTRU may be configured to use an exception resource pool for transmissions associated with Mode 1 when a beam failure occurs and beam failure recovery is contention-based.

[0316] The WTRU may determine whether to use the exception resource pool based on the amount of time that has expired since the beam failure recovery was triggered. For example, the WTRU may be configured to use the exception resource pool for transmissions associated with Mode 1 when the beam failure recovery timer reaches a certain time after multiple beam failure recovery attempts.

[0317] The WTRU may determine whether to use an exception resource pool based on the congestion level of the exception resource pool (e.g., as indicated by the CBR). For example, the WTRU may be configured to use the exception resource pool for transmissions associated with Mode 1 when the CBR of the exception resource pool is below a certain threshold.

[0318] The above-mentioned conditions for selecting and / or using an exception resource pool may be combined (e.g., an exception resource pool may be selected / used based on a combination of conditions). For example, a condition for using an exception resource pool in one option may depend on a parameter associated with another option. For example, when contention-based BFR is triggered (e.g., a first condition) and the LCH associated with mode 1 transmission is part of a subset of logical channels that are allowed to use an exception resource pool (e.g., a second condition), the WTRU may use such a resource pool. The LCH associated with mode 1 transmission that is part of a subset of channels that use such a pool may be determined based on the QoS of the LCH. The WTRU may use an exception resource pool after a certain amount of time has passed since the BFR was triggered, where the certain amount of time may depend on the configured LCH or the LCH having data available in the WTRU's buffer.

[0319] Resource / carrier selection / reselection may be performed by the WTRU despite the WTRU having limited TX capabilities.

[0320] The WTRU may support a minimum communication range. The WTRU may be allowed to transmit data based on a minimum communication range specific to the data (e.g., a minimum required communication range). Examples are described herein in the context of a sidelink, but these examples may generally be applied to any other scenario where a minimum communication range (MCR) requirement exists.

[0321] The WTRU may select at least one parameter for transmitting data on a sidelink channel (e.g., PSSCH). The at least one parameter may include frequency allocation, time allocation, modulation and coding scheme, rank, number of repetitions (or its maximum value), and / or HARQ information, etc. The at least one parameter may include transmission power level, transmit antenna gain and / or effective isotropic radiated power (EIRP). At least one of the above parameters may be configured or directly indicated by downlink control information (e.g., in a network scheduling mode, such as mode 1). For at least one of the above parameters, the WTRU may be configured to select from multiple candidate values ​​or (e.g., in the case of more than one parameter) candidate combinations of values. A subset of possible values ​​may be configured as a range or an explicit list.

[0322] The minimum communication range class may be mapped to a minimum communication range (e.g., a minimum required communication range). The WTRU may have data available for transmission. From the perspective of the MAC sublayer, such data may include a set of MAC SDUs from at least one logical channel. A higher layer may configure or provide a minimum communication range (e.g., a minimum required communication range) for one or more logical channels (e.g., for each logical channel) and / or for one or more MAC SDUs (e.g., for each individual MAC SDU). For example, according to a predefined or configured rule or formula, a minimum communication range (e.g., a minimum required communication range) value (e.g., which may be expressed in meters) may be mapped to one of a finite set of minimum communication range classes. Each such minimum communication range class may be represented by an index and may be associated with a path loss value (e.g., in dB) predefined or configured by a higher layer. Such a path loss value may represent a path loss to a device that is not expected to be exceeded (e.g., with a high probability of not being exceeded, such as 99% probability), for example, based on an applicable propagation model when the device is at a distance corresponding to the minimum communication range.

[0323] As referred to herein, unless otherwise specified, the acronym MCR may refer to a minimum communication range level or directly to a minimum communication range (e.g., a minimum required communication range). As referred to herein, a minimum communication range may correspond to a specific minimum communication range associated with a transmission. A minimum communication range may be attached to a logical channel. A minimum communication range may refer to a range of values ​​for a minimum communication range. For example, a network may configure a logical channel in a WTRU with a set of minimum communication range values. This set of values ​​may be a continuous set of minimum communication range values ​​from a lower minimum communication range to an upper minimum communication range. When referred to herein, a minimum communication range may correspond to a specific value of a minimum communication range associated with a transmission, a logical channel, and / or an SLRB, etc., or a configured set of minimum communication range values.

[0324] Different transmissions may be suitable for different minimum communication ranges. Logical channel prioritization (LCP) may be performed according to one or more LCH restrictions based on the suitability of the transmission to the minimum communication range.

[0325] The WTRU may determine for a given transmission (e.g., a PSSCH transmission) the suitability of the transmission for one or more minimum communication ranges (e.g., for each minimum communication range). When performing logical channel prioritization, the WTRU may multiplex data or select a logical channel associated with the minimum communication range for which the transmission is determined to be suitable.

[0326] Suitability for transmission to a minimum communication range may be determined based on one or more of the following. Suitability may be obtained from downlink control information (e.g., in a network scheduling mode, e.g., mode 1), e.g., along with other grant parameters. For example, the WTRU may receive via downlink control information the highest minimum communication range for which the grant applies. This information may be provided explicitly in a field of the DCI or implicitly (e.g., from a search space of a decoded PDCCH or from an RNTI value).

[0327] Suitability may be calculated based on one or more authorization parameters and / or associated power parameters. For example, the WTRU may calculate the maximum achievable path loss based on transmit power level, antenna gain, and / or other parameters used in existing power control formulas, such as bandwidth (e.g., number of resource blocks), number of code blocks, and the like. Additional parameters may be configured for this purpose. In an example, the maximum achievable path loss may be obtained, and if the maximum achievable path loss is higher than the path loss value associated with the minimum communication range, the WTRU may determine that the authorization is suitable for the minimum communication range. In an example, the WTRU may calculate (e.g., directly calculate) the expected maximum distance according to a formula. If the expected maximum distance is greater than the minimum communication range (e.g., the minimum required communication range), the WTRU may determine that the transmission is suitable.

[0328] The WTRU may be configured to select a combination of authorization parameters from a table. One or more elements (e.g., each element) of the table may be configured to have a minimum value of an effective isotropic transmit power or a transmit power for (e.g., each) MCR. The WTRU may determine that a transmission using a combination of authorization parameters according to an entry of the table is applicable to a minimum communication range if the transmission uses a transmit power (e.g., effective isotropic transmit power) that is higher than the corresponding configured minimum value.

[0329] A maximum communication range may be defined / utilized. Such a maximum communication range may be defined instead of or in addition to the minimum communication range described herein. The examples described herein in the context of the minimum communication range may be similarly applied to the maximum communication range. For example, in the case of determining suitability by calculation, if the maximum achievable path loss is lower than the path loss corresponding to the maximum communication range level, then the authorization may be considered suitable.

[0330] The WTRU may restrict or prioritize transmissions associated with a minimum communication range (e.g., MCR) that falls within the communication range of a selected LCH (e.g., the first selected LCH). For example, when performing LCP, the WTRU may restrict or prioritize the multiplexing of SDUs associated with similar minimum communication ranges. The set of minimum communication ranges to be multiplexed may be related to the minimum communication range of the first logical channel selected for transmission. The WTRU may select the first logical channel based on one or more criteria discussed herein (e.g., priority, Bj>0, etc.). After selecting the first logical channel, the WTRU may be restricted from selecting or may prioritize the selection of logical channels with a similar minimum communication range as the first logical channel. For example, the WTRU may be configured with a set of minimum communication ranges (e.g., for each LCH) and may select (e.g., only select) logical channels whose one or more minimum communication ranges fall within the configured set of minimum communication ranges, while using other criteria (e.g., such as priority) for destination selection. The following example illustrates how the WTRU determines whether an LCH is within the range of another LCH.

[0331] The WTRU may be configured with a set of minimum communication range values ​​(e.g., for each logical channel), where the set of minimum communication range values ​​may include a lower minimum communication range and an upper minimum communication range. The minimum communication range may correspond to a distance range that includes a minimum communication range requirement (e.g., a specific minimum communication range) for one or more (e.g., all) QoS flows mapped to the corresponding SLRB. For example, the WTRU may be configured to have a minimum communication range [AB], where [AB] = [50m500m]. The WTRU may multiplex QoS flows with a minimum communication range requirement that falls within the configured range of the SLRB (e.g., a minimum communication range requirement of 100m will fall within the configured range of [50m 500]). The LCH may include QoS flows with a minimum communication range requirement that falls within the range configured for the LCH. Once a first logical channel is selected, the WTRU may determine that a second logical channel is within one or more minimum communication ranges of the first logical channel based on one or more of the following.

[0332] The WTRU may determine whether the minimum communication range of the second logical channel overlaps with the minimum communication range of the first logical channel. For example, if LCH1 is configured with a minimum communication range of [A, B] and LCH2 is configured with a minimum communication range of [C, D], then if A<=C<=B or A<=D<=B, then LCH2 may be allowed to be multiplexed or prioritized.

[0333] The WTRU may determine that the second logical channel is within the minimum communication range of the first logical channel if the amount of overlap between the two minimum communication ranges associated with the first and second logical channels (eg, as described above) is greater than a threshold.

[0334] If the distance between the respective minimum communication ranges of the second logical channel and the first logical channel is below a threshold (e.g., a preconfigured threshold), the WTRU may determine that the second logical channel is within the minimum communication range of the first logical channel. The distances between these minimum communication ranges may be measured as a distance between lower limits (e.g., the distance between A and C in the above example), a distance between upper limits (e.g., the distance between B and D in the above example), a distance between two edges (e.g., the distance between B and C if B < C, or the distance between D and A if D < A), or a distance between midpoints of the ranges (e.g., the distance between the midpoints of A and B and the midpoints of C and D in the above example).

[0335] The WTRU may determine that the second logical channel is within the minimum communication range of the first logical channel if the respective minimum communication ranges of the two LCHs share at least one common endpoint (eg, A=C or B=D in the above example).

[0336] If the minimum communication range of the second LCH falls completely within the minimum communication range of the first LCH (eg, using the above example, A<=C and D<=B, etc.), the WTRU may determine that the second logical channel is within the minimum communication range of the first logical channel.

[0337] The LCH may be configured with a list of allowable minimum communication range values ​​(e.g., in addition to or instead of a range). For example, the LCH may be configured with a list of minimum communication range values. Such a list of minimum communication range values ​​may correspond to a set of minimum communication range requirements (e.g., specific minimum communication range values) for one or more (e.g., all) QoS flows mapped to the corresponding SLRB. The WTRU may be configured with a list of minimum communication range values, such as (10m, 100m, 200m). The WTRU may multiplex QoS flows with minimum communication range requirements that match one or more (e.g., any) of the listed values. The WTRU may select a first logical channel and may determine that a second logical channel is within the minimum communication range of the first logical channel based on one or more of the following.

[0338] If a value (eg, any value) in the minimum communication range value list for the first logical channel matches a value in the minimum communication range value list for the second logical channel, the WTRU may determine that the second logical channel is within the minimum communication range of the first logical channel.

[0339] The WTRU may determine that the second logical channel is within the minimum communication range of the first logical channel if at least x minimum communication range values ​​(eg, x may be preconfigured or predetermined) for the first logical channel correspond to the x minimum communication range values ​​configured for the second logical channel.

[0340] The WTRU may determine that the second logical channel is within the minimum communication range of the first logical channel if at least one value in the list of minimum communication range values ​​for the second logical channel is numerically between the two minimum communication range values ​​configured for the first logical channel.

[0341] The WTRU may determine that the second logical channel is within the minimum communication range of the first logical channel if at least one value in the list of minimum communication range values ​​for the second logical channel is at a distance y from at least one value in the list of minimum communication range values ​​for the second logical channel, where y is lower than a threshold (e.g., a preconfigured threshold).

[0342] If multiple (e.g., all) minimum communication range values ​​in the list of minimum communication range values ​​of the first logical channel match the corresponding minimum communication range values ​​(e.g., all minimum communication range values) of the second logical channel, the WTRU can determine that the second logical channel is within the minimum communication range of the first logical channel.

[0343] If the minimum communication range value configured for the second logical channel is a subset of the minimum communication range value configured for the first logical channel, the WTRU may determine that the second logical channel is within the range of the minimum communication range of the first logical channel.

[0344] The WTRU may, for example, assign an associated minimum communication range for the grant when selecting a first LCH. The associated minimum communication range may be a lower minimum communication range value in a set of minimum communication range values ​​configured for the LCH. The associated minimum communication range may be an upper minimum communication range value in a set of minimum communication range values ​​configured for the LCH. The associated minimum communication range may be a midpoint minimum communication range value in a set of minimum communication range values ​​configured for the LCH. The associated minimum communication range may be any minimum communication range value within a set of minimum communication range values ​​configured for the LCH.

[0345] The WTRU may determine that a second LCH may be multiplexed into a PDU (e.g., a PDU including data from a first LCH) if one or more of the following items are within a distance x of the minimum communication range assigned for the grant (e.g., x may be preconfigured or predetermined). For example, if the upper limit of the minimum communication range value of the second LCH is within the distance x of the minimum communication range assigned for the grant, the WTRU may determine that the second LCH may be multiplexed into the PDU. If the lower limit of the minimum communication range value of the second LCH is within the distance x of the minimum communication range assigned for the grant, the WTRU may determine that the second LCH may be multiplexed into the PDU. If the midpoint of the minimum communication range value of the second LCH is within the distance x of the minimum communication range assigned for the grant, the WTRU may determine that the second LCH may be multiplexed into the PDU. If any value within the minimum communication range value configured for the second LCH is within the distance x of the minimum communication range assigned for the grant, the WTRU may determine that the second LCH may be multiplexed into the PDU.

[0346] The WTRU may be configured to have a set of allowable or possible minimum communication range values. Once the WTRU selects a first LCH, the WTRU may identify one of the allowed or possible values ​​based on the minimum communication range (one or more) of the LCH. The WTRU may then be restricted to or may prioritize LCHs associated with the identified allowable or possible range (e.g., identified based on the first selected LCH). The WTRU may identify or associate an allowable or possible range for a LCH based on one or more of the following.

[0347] The WTRU may identify or associate an allowable or possible range of an LCH with an LCH based on whether the minimum communication range, minimum communication range value set, or minimum communication range value list associated with the LCH falls within the allowable configured range. For example, the configured allowable range may be [50m 100m], and an LCH associated with a minimum communication range of [60m 80m] would be associated with such a range.

[0348] The WTRU may identify an allowed or possible range of the LCH or associate an allowable or possible range with the LCH based on whether one or more elements in the configured minimum communication range list of the LCH falls within the configured allowable range.

[0349] As described herein, the WTRU may identify or associate an allowable or possible range of the LCH with the LCH based on whether there is an overlap between the configured allowable minimum communication range and the minimum communication range configured for the LCH.

[0350] The WTRU may continue the LCP by selecting an LCH that is within the range of the first LCH (e.g., selecting only those LCHs). A comparison may be made between the LCH under consideration and the selected first LCH. In an example (e.g., when selecting each LCH), the WTRU may take into account one or more (e.g., all) LCHs selected so far to decide whether the LCH under consideration may be included in the PDU. For example, if, based on the rules shown in the above examples, an LCH is within the range of one or more (e.g., any) already selected LCHs, the WTRU may include the LCH. If, based on the rules shown in the above examples, an LCH is within the range of one or more (e.g., at least x, where x may be preconfigured) already selected LCHs, the WTRU may include the LCH.

[0351] The WTRU may first select logical channels that fall within a certain minimum communication range set, and may satisfy each of these logical channels until their respective bucket sizes are reached. If all logical channels within the minimum communication range satisfy their bucket sizes, and there is still room left in the grant, the WTRU may select logical channels outside the minimum communication range. This selection may also be based on one or more other criteria discussed herein (e.g., priority, Bj>0, etc.).

[0352] The WTRU may select a logical channel for the LCP based on a combination of one or more QoS parameters including minimum communication range. The WTRU may determine the logical channels to be multiplexed in a grant based on a combination of bucket size, priority, and / or minimum communication range, as described below.

[0353] The WTRU may select one or more highest priority logical channels with Bj>0 and the WTRU may satisfy logical channels of that priority until their respective Bj is reached as long as the minimum communication range of those logical channels falls within a certain range. In an example, logical channels that are outside the minimum communication range and have Bj>0 may be satisfied after satisfying the logical channels with the highest priority and within the minimum communication range. In an example, logical channels within the minimum communication range (e.g., of any priority) may be satisfied after satisfying the Bj of one or more (e.g., all) logical channels (e.g., of any priority).

[0354] The WTRU may select one or more highest priority logical channels with Bj>0, and may further select those logical channels that fall within a certain minimum communication range so that the total value of Bj>0 for such logical channels (e.g., logical channels with the same priority) may be maximized.

[0355] The WTRU may select a set of logical channels with Bj>0 (e.g., of any priority), and may further select those logical channels that fall within a certain minimum communication range in order to maximize the total value of Bj>0 or the weighted value of Bj>0 for the selected list of logical channels. The weights used to calculate the weighted value of Bj may be associated with (e.g., based on) the priority of each corresponding logical channel.

[0356] The WTRU may restrict or prioritize multiplexing of SDUs associated with the MCR range separately from multiplexing of SDUs not associated with the minimum communication range. For example, the WTRU may multiplex SDUs associated with the minimum communication range together and multiplex SDUs not associated with the minimum communication range together (e.g., separately from multiplexing SDUs associated with the minimum communication range). The WTRU may multiplex logical channels associated with the minimum communication range until another QoS parameter (e.g., such as bucket size) is met, and then if there is additional space in the grant, consider multiplexing logical channels not associated with the minimum communication range. The WTRU may multiplex logical channels not associated with the minimum communication range until another QoS parameter (e.g., such as bucket size) is met, and then if there is additional space in the grant, consider multiplexing logical channels associated with the minimum communication range.

[0357] The LCP restriction associated with the MCR range may be applied when (e.g., only when) the selected first transmission has a minimum communication range that is below or above a threshold. For example, if the WTRU selects data for a first LCH associated with a first minimum communication range, and the first minimum communication range is below a threshold, the WTRU may restrict the selection of other LCHs so that they fall within one or more minimum communication ranges associated with the first LCH. If the WTRU selects a transmission with a minimum communication range that is above a threshold, the WTRU may select an LCH that has no minimum communication range restriction (e.g., any LCH, regardless of the associated minimum communication range).

[0358] The LCP restriction associated with the minimum communication range may include the WTRU selecting one or more LCHs having a minimum communication range value that is equal to or less than the minimum communication range value associated with the selected first LCH. For example, the WTRU may select the first LCH based on other criteria (e.g., criteria unrelated to the minimum communication range). The WTRU may (e.g., after such selection) select (e.g., only select) LCHs having a minimum communication range value that is equal to or less than the minimum communication range value associated with the first selected LCH.

[0359] The WTRU may decide whether to multiplex the LCH with and without range limitation.

[0360] A WTRU may be configured with an LCH with a minimum communication range and / or an LCH without a minimum communication range. For some LCHs (e.g., LCHs associated with multicast), QoS flows with minimum communication range requirements may be grouped together, while for other LCHs (e.g., which may also be associated with multicast), QoS flows without minimum communication range requirements may be grouped together. When performing LCP in the presence of an LCH with or without a configured minimum communication range or set of minimum communication ranges, the WTRU may have one or more of the following behaviors.

[0361] The WTRU may be configured to not multiplex an LCH with a configured minimum communication range with an LCH that does not have a configured minimum communication range. In an example (e.g., as described herein, where the allowable range is determined by a first selected LCH), if the WTRU selects an LCH that does not have a configured minimum communication range or a minimum communication range set, the WTRU may select (e.g., only select) other LCHs that also do not have a configured minimum communication range or a minimum communication range set (e.g., for multiplexing). If the WTRU selects an LCH with a configured minimum communication range or a minimum communication range set, the WTRU may select (e.g., only select) other LCHs that also have a configured minimum communication range or a minimum communication range set (e.g., for multiplexing).

[0362] The WTRU may be configured to multiplex an LCH with a configured minimum communication range with an LCH without a configured minimum communication range, for example, based on a specific minimum communication range or minimum communication range set associated with the LCH with the configured minimum communication range or minimum communication range set. For example, if the WTRU selects an LCH with a configured minimum communication range or minimum communication range set, the WTRU may select one or more other LCHs that do not have the configured minimum communication range or minimum communication range set (e.g., for multiplexing), as long as the minimum communication range or minimum communication range set of the first selected LCH is large enough (e.g., based on the absolute minimum communication range value of one or more minimum communication ranges in the configured set), small enough (e.g., based on the absolute minimum communication range value of one or more minimum communication ranges in the configured set), wide enough (e.g., based on the size of the range), or narrow enough (e.g., based on the size of the range). If the WTRU selects an LCH that does not have a configured minimum communication range or minimum communication range set, the WTRU may select one or more other LCHs that have a configured minimum communication range or minimum communication range set (e.g., for multiplexing), as long as the LCH meets similar conditions as described above.

[0363] The WTRU may be configured to multiplex an LCH with a configured minimum communication range with an LCH without a configured minimum communication range, which may be based on the distance between the minimum communication ranges configured for one or more (e.g., each) QoS flows currently multiplexed with the LCH without a configured minimum communication range. If the WTRU selects an LCH without a configured minimum communication range, the WTRU may determine whether the distance between the lowest minimum communication range QoS flow and the largest minimum communication range QoS flow is greater than a threshold. If the distance is greater than the threshold, the WTRU may decide not to multiplex the LCH with the configured minimum communication range into the same PDU. Otherwise, the WTRU may decide to multiplex the LCH with the configured minimum communication range into the same PDU. The WTRU may determine (one or more) allowable minimum communication ranges, as illustrated in the examples provided herein.

[0364] The WTRU may determine whether to multiplex an LCH with a configured minimum communication range with an LCH that does not have a configured minimum communication range based on the actual QoS flows that have been mapped to the LCH (e.g., and / or their associated minimum communication ranges). For example, the WTRU may select an LCH (e.g., a first LCH) that does not have a configured minimum communication range or set of minimum communication ranges. The WTRU may determine the QoS flows that have been mapped to the LCH and their corresponding MCR ranges. The WTRU may determine whether an LCH with a configured MCR range (e.g., a second LCH) may be multiplexed into a PDU by considering one or more MCR ranges associated with the flows multiplexed into the first LCH, and applying the rules described herein to determine whether the second LCH is within the range of the first LCH (e.g., based on whether the minimum communication range of the second LCH includes the minimum communication range configured for one or more QoS flows mapped to the first LCH).

[0365] The WTRU may select an LCH configured with a minimum communication range or a minimum communication range set. The WTRU may then determine whether to multiplex an LCH that does not have the configured minimum communication range based on the actual minimum communication range value associated with the stream multiplexed into the LCH without the minimum communication range requirement.

[0366] Figure 3 A destination selection procedure 300 that may be performed in a WTRU is shown. The procedure 300 may be performed by the WTRU at 302 (e.g., periodically). At 304, the WTRU may determine that a set of sidelink resources are available for the WTRU to perform a sidelink transmission. As described herein, the set of sidelink resources may be configured or scheduled by the network (e.g., in Mode 1), or the set of sidelink resources may be autonomously selected by the WTRU (e.g., from one or more pre-configured resource pools). The set of resources may include time and / or frequency resources, and / or may be specifically configured for sidelink transmission. In response to determining that the set of resources has become available, the WTRU may identify one or more logical channels (LCHs) having a bucket size parameter that meets a specific criterion at 306. For example, the WTRU may identify one or more logical channels with Bj>0. Once one or more logical channels with Bj>0 are identified, the WTRU may further select (one or more) logical channels with the highest transmission priority from the identified logical channels.

[0367] At 308, the WTRU may determine the respective destinations associated with the selected logical channels (e.g., the selected one or more highest logical channels with Bj>0). If the WTRU determines at 310 that there are multiple destinations associated with logical channels that meet the above criteria, the WTRU may select at 312 a destination to which transmission may minimize the amount of resources used for data exceeding Bj of the logical channel associated with the destination (e.g., transmission to the selected destination may result in the least amount of resources being used for data exceeding the Bj or may result in the maximum amount of resources being used to meet the Bj). If the WTRU determines at 310 that there are only destinations with logical channels that meet the above criteria, the WTRU may select at 314 the first LCH (L1) associated with the destination with the highest priority and Bj>0 and allocate at least a portion of the available resources to transmission of L1 (e.g., to meet the Bj of L1) at 316.

[0368] At 318, the WTRU may check whether there are additional resources remaining for transmission. If there are remaining resources, the WTRU may select the additional LCH (Lx) for transmission (e.g., multiplexed with the transmission of L1) based on one or more of the priority, bucket size related parameters (e.g., Bj), or minimum communication range (MCR) associated with the additional LCH (Lx) at 320. For example, the WTRU may select an additional LCH with the second highest priority (e.g., the second highest priority among the remaining logical channels associated with the destination), Bj>0 and / or with a minimum communication range within the distance of the minimum communication range of the first logical channel L1 (e.g., distance (MCR(L1), MCR(Lx))<threshold, where the threshold may be configured / signaled by the network or determined by the WTRU). After selecting such an additional LCH (Lx), the WTRU may allocate at least a portion of the available resources to the transmission of Lx (e.g., to meet the Bj of Lx). The transmissions of L1 and Lx may be multiplexed together (e.g., multiplexed in the same PDU). The WTRU may repeat the operations at 318 and 322 until no more resources remain, and the WTRU may end the destination selection procedure 300 at 324 .

[0369] The WTRU may determine a minimum communication range to be transmitted in the SCI or sent to the L1. In an example (e.g., after the LCP), the WTRU may determine a minimum communication range value to be transmitted in the SCI. Such a minimum communication range may be sent explicitly or may be combined with other QoS parameters into an L1 QoS parameter (e.g., such as L1 priority). The value of the L1 QoS parameter may be associated with a specific minimum communication range and / or other QoS parameters (e.g., one or more of reliability, latency, or priority related parameters).

[0370] The WTRU may determine the minimum communication range to be sent to L1 based on one or more of the following. The WTRU may use one or more of the minimum communication range or minimum communication range set associated with the LCH, where the LCH is configured to have the largest minimum communication range or the largest list of minimum communication range values. The WTRU may use the maximum upper limit minimum communication range value associated with the set of LCHs multiplexed into the PDU. The WTRU may use the maximum lower limit minimum communication range value associated with the set of LCHs multiplexed into the PDU. The WTRU may use the maximum midpoint minimum communication range value associated with the set of LCHs multiplexed into the PDU. The WTRU may use the maximum minimum communication range (e.g., a single minimum communication range value) configured for any LCH multiplexed into the PDU. The WTRU may use the maximum minimum communication range in the minimum communication range list configured for one or more (each) LCHs in the LCH multiplexed into the PDU. The WTRU may use the maximum minimum communication range associated with one or more (e.g., any) QoS flows mapped to (e.g., any) LCHs multiplexed into the PDU.

[0371] The WTRU may be configured to select an appropriate value for a transmission parameter from a plurality of candidate values ​​(or a combination thereof). Minimum communication range, data rate, and / or fairness requirements may be satisfied based on the corresponding values ​​selected by the WTRU for one or more transmission parameters.

[0372] The transmission parameter value may be selected based on the data available for transmission, based on attributes of the data, requirements associated with the data, and / or variables associated with the data. For example, the transmission parameter value may be selected based on the minimum communication range of a logical channel (or MAC SDU) for which there is data available for transmission. The transmission parameter value may be selected based on one or more parameters or variables used in the LCP, such as a bucket variable (Bj) for logical channel j representing a bucket size associated with the logical channel, a prioritized bit rate (PBR), and / or a logical channel priority. The transmission parameter value may be selected based on an identity of a WTRU or group of WTRUs that intends to receive the data available for transmission.

[0373] The data or LCH for parameter selection may be determined as follows. The WTRU may determine the data or logical channel based on which parameter selection is performed. The WTRU may consider a set of logical channels that meet one or more of the following conditions. The WTRU may consider logical channels that have data available for transmission. The WTRU may consider a logical channel for which a variable Bj used in the LCP (e.g., representing the bucket size associated with the logical channel) is above a certain threshold (e.g., zero).

[0374] One or more of the above conditions (e.g., the second condition above) may serve to ensure fairness of transmission, for example, because these conditions may prevent the use of resources beyond what is needed to meet the quality requirements (e.g., data rate requirements) of the logical channel. The WTRU may limit the selection of logical channels to the logical channel with the highest priority among all logical channels that meet the given condition.

[0375] The WTRU may determine a target minimum communication range, which may be used to determine transmission parameters and / or generate reports for the network. The target minimum communication range may be, for example, a highest minimum communication range level (or value) among a plurality of minimum communication range values ​​associated with (one or more) logical channels (e.g., as determined above) or with a MAC SDU available for transmission.

[0376] In an example (e.g., when network controlled operation is supported, such as in a network scheduled mode, such as Mode 1), the WTRU may send a target minimum communication range to the network, such as via physical layer and / or MAC layer signaling. The WTRU may include the target minimum communication range in an enhanced buffer status report. When the target minimum communication range changes, the WTRU may trigger the transmission of a MAC control element (or enhanced BSR). In an example (e.g., when no PUSCH resources are available), the WTRU may transmit the target minimum communication range in a physical layer signal such as a scheduling request. The WTRU may report a target maximum communication range.

[0377] For example, if there are no intended receivers outside a certain communication range below a minimum communication range level, then the WTRU may reduce the target minimum communication range to a level below the minimum communication range level associated with the data available for transmission. The WTRU may obtain the location of (e.g., each) intended receiver (e.g., via higher layer signaling) and may determine a maximum distance between the intended receivers. The WTRU may obtain path loss estimates for (e.g., each) intended receiver and may determine a maximum path loss among the intended receivers. Such estimates may be performed and reported by the intended receivers, or performed directly by the WTRU (e.g., based on signaling regarding known transmit powers).

[0378] The transmission parameters (e.g., MCS) may be selected to maximize a metric (e.g., spectral efficiency). The WTRU may select a combination of transmission parameters within the candidate set that satisfies at least one of the following conditions. The WTRU may select a combination of transmission parameters such that the transmission is suitable for a target minimum communication range. The WTRU may select a combination of transmission parameters such that a metric (as described herein) is maximized or minimized.

[0379] The attempted maximization (or minimization) of the metric may be used to attempt to maximize spectral efficiency and / or minimize transmit power. The attempted maximization (or minimization) may be achieved in various ways, for example, depending on how the WTRU selects transmission parameters.

[0380] The WTRU may be configured to select a modulation and coding scheme (MCS) from a configured set or range of MCS values. The WTRU may select the highest MCS value for which the transmission is appropriate. If a parameter table (e.g., an MCS table) is sorted by MCS value, the WTRU may select the minimum or maximum table index entry from the parameter table. The WTRU may select an MCS such that the required transmit power appropriate for a target minimum communication range is maximized while still being lower than the WTRU's actual transmit power (e.g., which may be independently set).

[0381] The WTRU may be configured to select a combination of MCS and transmission power level from a configured (e.g., predefined) set of candidate combinations. For example, such combinations may be sorted in descending order based on the highest MCS level so that the transmission may be suitable. The WTRU may select the highest value such that the transmission is suitable for the target MCS and / or such that the transmission power level is below the maximum power level configured for the WTRU (e.g., the maximum power level configured by the independent power control mechanism).

[0382] The WTRU may determine candidate resources based on a target transport block size. The WTRU may be configured to select resources for a grant (e.g., in the frequency domain and / or time domain) from a plurality of candidate resources. The set of candidate resources may be such that different candidate resources may occupy different numbers of resource blocks, time slots, and / or symbols. As described herein, the set of candidate resources may be limited by factors such as channel occupancy.

[0383] The WTRU may determine the transport block size for each candidate resource based on the frequency allocation, time allocation, and / or other parameters such as the MCS. The MCS may in turn be determined based on, for example, a target minimum communication range as described herein.

[0384] The WTRU may select candidate resources such that the amount of resources used may be minimized and / or QoS requirements (e.g., data rate) may be met. The WTRU may determine the target transport block size to be the minimum transport block size such that (e.g., after performing LCP for a MAC PDU or transport block) at least one of the following conditions may be met for at least one logical channel: no data is available for transmission for the at least one logical channel, or a variable Bj associated with the at least one logical channel and used in the LCP (e.g., which may represent a bucket size associated with logical channel j) is below a threshold (e.g., zero). Other conditions may also be selected, and the selection of the condition may depend on the logical channel(s) of interest.

[0385] Once the target transport block size is determined, the WTRU may restrict the set of candidate resources to those resources whose corresponding transport block size is the smallest and still higher than the target transport block size. This approach may ensure that the WTRU does not use more resources than are needed to meet a given QoS requirement.

[0386] The WTRU may use best effort when transmitting outside a certain minimum communication range (e.g., a minimum communication range configured for a particular flow, bearer, and / or transmission). For example, if a receiving device (e.g., a receiving WTRU) is outside the minimum communication range, the WTRU may use best effort transmission parameters (e.g., the best or optimal transmission parameters available to the WTRU).

[0387] To illustrate, a WTRU participating in a V2X transmission may modify one or more aspects of a sidelink transmission parameter of the WTRU based on whether a receiving device (e.g., an RX WTRU) is within or outside a certain minimum communication range (e.g., a minimum communication range configured for a particular flow, bearer, and / or transmission). When a transmission is associated with a minimum communication range and the WTRU receiving the transmission is within the minimum communication range, the WTRU (e.g., a transmitting or TX WTRU) may operate with optimal transmission parameters that are targeted to meet the QoS requirements of the transmission. On the other hand, if the transmission is associated with a minimum communication range and the WTRU receiving the transmission is outside the minimum communication range, the transmitting WTRU may switch to parameters that are not intended to meet the aforementioned QoS requirements. Such QoS requirements may be related to at least latency, priority, data rate, and / or reliability.

[0388] A receiving WTRU (eg, RX WTRU) may provide an indication of its location and / or whether the WTRU is within or outside of a minimum communication range, for example, via an SCI or a sidelink control message.

[0389] The receiving WTRU may transmit its location, or indicate a change in its location, via a control message. The transmitting WTRU may determine whether the receiving WTRU is within the minimum communication range of a particular transmission based on the reception of the control message. Such a control message may include a dedicated SCI, a SL MAC CE, feedback information, or a SL RRC message. The control message may include geographic location information, an area or sub-area index, an indication of a location change, or similar information for the receiving WTRU. For example, the control message may include location information of the receiving WTRU, such as geographic location coordinates, an area ID, a sub-area ID, and / or similar information. The control message may include an indication of whether the receiving WTRU is within or outside a specific minimum communication range (e.g., a minimum communication range associated with a specific SLRB). The control message may include one or more SLRB IDs, for which the receiving WTRU is within or outside a specific minimum communication range. The control message may include link feedback related information, such as HARQ feedback, CQI report, etc. The control message may include a WTRU ID, a unicast link ID, and / or the like.

[0390] The WTRU may determine whether to transmit its location information based on a configuration (e.g., based on a SL bearer configuration). For example, a receiving WTRU may receive a SL bearer configuration for a unicast link from a transmitting WTRU. The configuration may explicitly configure periodic location transmissions at the receiving WTRU. The receiving WTRU may determine whether and / or when to transmit location information based on a bearer configuration associated with the transmitting WTRU, based on the location of the receiving WTRU, and / or based on transmission characteristics of the transmitting WTRU.

[0391] The receiving WTRU may respond to a feedback request (e.g., a feedback request sent by a transmitting WTRU) when the receiving WTRU is within a certain minimum communication range. The receiving WTRU may transmit feedback information when the receiving WTRU is within a certain minimum communication range (e.g., only when the WTRU is within a certain minimum communication range). The transmitting WTRU's feedback request may be implicitly sent based on the transmission of a reference signal (e.g., when the transmitting WTRU includes a CSI-RS in its transmission). For example, the transmitting WTRU may transmit an RRC request message (e.g., such as a maintain message), and the receiving WTRU may respond (e.g., only respond to) the maintain message when the receiving WTRU is within a certain minimum communication range. The receiving WTRU may determine that it is within the configured minimum communication range based on the bearer configuration, the location of the transmitting WTRU (e.g., which may be indicated in the transmission of the transmitting WTRU (e.g., a CQI request)), and / or the receiving WTRU's own location information. For example, the receiving WTRU may calculate the distance between itself and the transmitting WTRU based on the location information of the transmitting WTRU (e.g., as indicated in the CQI request) and the receiving WTRU's own location. If the distance is less than the minimum communication range associated with the SLRB configured by the transmitting WTRU, the receiving WTRU may respond to the transmitting WTRU's feedback request. Otherwise, the receiving WTRU may ignore the feedback request.

[0392] The transmitting WTRU may signal the applicable minimum communication range, for example, in a feedback request. Such a feedback request may be specific to a specific minimum communication range. The receiving WTRU may send feedback when (e.g., only in this case) the receiving WTRU determines that it is within the minimum communication range associated with the feedback request. The transmitting WTRU may explicitly transmit the minimum communication range associated with the feedback request in a feedback request message. A CQI request, a data transmission including a CSI-RS, or another feedback request sent by the transmitting WTRU may include an explicit indication of the minimum communication range expected for feedback. Sidelink control information associated with the CQI request or data transmission may also include such an explicit indication.

[0393] The receiving WTRU may determine the applicable minimum communication range, for example, based on data multiplexed with a transmission by the transmitting WTRU. The receiving WTRU may determine the LCH(s) or SLRB(s) included in such a transmission. The receiving WTRU may treat the minimum communication range of the feedback request provided via such a transmission as the worst case (e.g., maximum) minimum communication range configured for one or more (e.g., each) transmitted SLRBs.

[0394] A WTRU (e.g., a transmitting WTRU) may transmit (e.g., signal) an offset (e.g., distance) to a minimum communication range associated with a data transmission, and a receiving WTRU may apply the offset when determining a minimum communication range associated with a feedback request. A WTRU (e.g., a transmitting WTRU) may transmit an indication to signal whether a minimum communication range associated with a feedback request should be associated with the data minimum communication range or with another minimum communication range. Such another minimum communication range may be determined based on a SLRB configuration of the transmitting WTRU (e.g., a SLRB with a maximum minimum communication range). A WTRU (e.g., a transmitting WTRU) may transmit a SLRB or LCH index in a feedback request, and a receiving WTRU may determine an applicable minimum communication range for the feedback request based on the minimum communication range configured for that SLRB or LCH.

[0395] The receiving WTRU may transmit an indication of its location when the WTRU moves into or out of a minimum communication range. The receiving WTRU may transmit an event-triggered control message when it transitions from being within (or outside) a minimum communication range of at least one or more SLRBs to being outside (or within) a minimum communication range of the one or more SLRBs. The receiving WTRU may determine its distance from the transmitting WTRU based on location information included in a data or control transmission of the transmitting WTRU and the receiving WTRU's own location. The receiving WTRU may determine the minimum communication range information associated with the SLRB based on SLRB configuration information (e.g., which may be sent via SL RRC signaling).

[0396] The receiving WTRU may transmit location information (e.g., periodically) based on the SLRB configuration. For example, when the SL bearer configuration of the transmitting WTRU includes at least one SLRB configured with a range requirement, the receiving WTRU may determine to transmit location information periodically. The receiving WTRU may receive the SL bearer configuration of the transmitting WTRU via an SL RRC message transmission associated with unicast and / or multicast link establishment or modification. As described herein, the receiving WTRU may transmit such periodic location information when the receiving WTRU determines that it is within the minimum communication range of at least one SLRB.

[0397] The receiving WTRU may transmit HARQ feedback as well as a transmission range indication.

[0398] In an example (e.g., for unicast SL multicast transmissions), when the TX-RX distance associated with a PSSCH transmission is greater than the distance specified by a communication range requirement such as a minimum communication range requirement (e.g., the PSSCH transmission is outside the minimum communication range), the WTRU may not send HARQ feedback for the PSSCH transmission. In these cases, the transmitting WTRU may observe HARQ discontinuous transmission (DTX) in the associated physical side link feedback channel (PSFCH) (e.g., the transmitting WTRU may not receive HARQ ACK / NACK).

[0399] The transmitting WTRU may perform HARQ retransmissions upon receiving a HARQ DTX (e.g., because the HARQ DTX may indicate that the receiving WTRU may have failed to decode the PSCCH). In these cases, the transport block (TB) may be received correctly and HARQ retransmissions may not actually be required. HARQ DTX outside the minimum communication range may be distinguished from other HARQ DTX transmissions to avoid or reduce unnecessary HARQ retransmissions.

[0400] In an example (e.g., for a HARQ-enabled group transmission), the WTRU may transmit HARQ feedback including HARQ ACK / NACK information and / or an out of minimum communication range indicator. For example, the WTRU may transmit one or more additional bits in the HARQ feedback payload to indicate whether the HARQ feedback information is related to a TB received within a minimum communication range (MCR). The transmitting WTRU may receive the HARQ feedback with the minimum communication range indicator and may perform HARQ retransmissions, for example, according to the example rules shown in the table below. When HARQ retransmissions are not performed, the transmitting WTRU may flush its HARQ buffer. The transmitting WTRU may then apply a "best effort" transmission, for example, based on transmission parameters configured (e.g., preconfigured) for WTRUs outside the minimum communication range.

[0401] HARQ Feedback Payload WTRU HARQ Retransmission Within HARQ ACK+MCR no HARQ NACK+MCR yes Beyond HARQ ACK+MCR no HARQ NACK+MCR no

[0402] A HARQ feedback payload including a transmission range indicator as described herein may use a reserved cyclic shift. For example, four cyclic shift values ​​of a sequence may be configured, reserved, and / or used. One or more of these cyclic values ​​may be selected or determined based on the HARQ feedback payload.

[0403] Example sets (eg, three sets) of cyclic shift values ​​may include, for example: set 1: {0, 3, 6, 9}; set 2: {1, 4, 7, 10}; and set 3: {2, 5, 8, 11}.

[0404] The set of cyclic shift values ​​may be determined based on one or more of the following. The cyclic shift value may be determined based on a subchannel index (e.g., a first subchannel index) of an associated PSSCH / PSCCH transmission. The set of cyclic shift values ​​may be determined based on the number of subchannels. The set of cyclic shift values ​​may be determined based on the number of PSFCH resources within a slot.

[0405] An example cyclic shift value assignment for each HARQ feedback payload within a set may be as shown in the following table.

[0406] HARQ Feedback Payload PSFCH cyclic shift value Within HARQ ACK+MCR First cyclic shift value HARQ NACK+MCR The third circular shift value Beyond HARQ ACK+MCR Second cyclic shift value HARQ NACK+MCR Fourth circular shift value

[0407] In an example (e.g., when multiple HARQ-ACK bits are multiplexed), the inside-MCR and / or outside-MCR status of the transmission may be indicated in the HARQ-ACK transmission. In an example, if the number of HARQ-ACK bits exceeds a threshold, the receiving WTRU may not include the inside-MCR or outside-MCR indicator in the HAR-ACK transmission.

[0408] Separate PSFCH resource pools may be used for transmissions within the MCR and transmissions outside the MCR. For example, when the receiving WTRU is within the MCR, a first PSFCH resource pool may be used, and when the receiving WTRU is outside the MCR, a second PSFCH resource pool may be used. The one or more PSFCH resource pools may be multiplexed in the frequency domain, for example, so that the receiving WTRU may report HARQ feedback in the same timeslot regardless of the within-MCR or outside-MCR status of the WTRU. One or more of the following may apply.

[0409] If a transmitting WTRU receives HARQ feedback in a PSFCH resource pool outside the MCR, the WTRU may not retransmit the sidelink transmission.

[0410] The within-MCR PSFCH resource pool may be configured to have no associated outside-MCR PSFCH resource pool. When the outside-MCR PSFCH resource pool is not configured, the receiving WTRU may not send HARQ-ACK when the WTRU is outside the MCR.

[0411] If both the in-MCR PSFCH resource pool and the out-MCR PSFCH resource pool are configured, the receiving WTRU may send HARQ feedback regardless of the in-MCR or out-MCR status of the WTRU.

[0412] A transmitting WTRU may determine whether one or more receiving WTRUs are within a minimum communication range. The transmitting WTRU may make the determination based on a location indication provided by one or more receiving WTRUs, as discussed herein. For example, the transmitting WTRU may transmit a request message (e.g., an RRC maintain message, a CQI request, etc.) to one or more receiving WTRUs. Based on the presence of a response message and / or location information contained in the response message, the transmitting WTRU may determine whether one or more receiving WTRUs are within a minimum communication range associated with a bearer.

[0413] The transmitting WTRU may use the transmission of the receiving WTRU (e.g., which may include the location information of the receiving WTRU) to determine whether the receiving WTRU is within the minimum communication range. For example, the transmitting WTRU may receive one or more transmissions made by the receiving WTRU, which include the location information of the receiving WTRU. The transmitting WTRU may determine the distance between itself and the receiving WTRU based on the location information and the location of the transmitting WTRU itself. If the distance is less than the minimum communication range associated with the packet, flow, or SLRB, the transmitting WTRU may determine that the receiving WTRU is within the minimum communication range associated with the packet, flow, or SLRB. The transmitting WTRU may determine whether the receiving WTRU is within the minimum communication range based on the reception of HARQ feedback from the receiving WTRU. The receiving WTRU may be configured with (one or more) HARQ feedback resources on which to transmit ACK / NACK. If the transmitting WTRU observes one or more (e.g., consecutive) DTXs on (one or more) such resources, the transmitting WTRU may assume that the receiving WTRU is outside the minimum communication range associated with the transmission of the transmitting WTRU.

[0414] A transmitting WTRU may determine a receiving WTRU associated with a unicast or multicast session based on one or more of the following.

[0415] The transmitting WTRU may determine the receiving WTRUs associated with the unicast or multicast session based on the link establishment signaling. For example, the transmitting WTRU may obtain the WTRU ID of the peer receiving WTRU during the unicast link establishment signaling and / or exchange. The transmitting WTRU may initiate unicast link establishment signaling with one or more (e.g., each) WTRU in the group and may determine the list of WTRUs in the multicast session based on the response(s) associated with the unicast link establishment. The unicast link establishment may be initiated by an upper layer (e.g., NAS layer).

[0416] The transmitting WTRU may determine the receiving WTRU associated with the unicast or multicast session based on one or more upper layers. For example, the transmitting WTRU may obtain a list of WTRU IDs (e.g., source WTRU IDs) associated with the multicast session or multicast destination ID based on information provided by upper layers (e.g., NAS layer, V2X layer, and / or application layer).

[0417] The WTRU may associate a minimum communication range with an LCH or SLRB. The WTRU may determine the minimum communication range associated with the SLRB based on a network configuration (e.g., explicit signaling of the minimum communication range in the SLRB configuration). The WTRU may determine the minimum communication range associated with the SLRB based on the minimum communication range configured for (e.g., each) flow mapped to the SLRB. For example, the WTRU may be configured with a mapping (e.g., a mapping rule) between flows and SLRBs, and the WTRU may determine the minimum communication range of the SLRB as the worst case (e.g., maximum) minimum communication range associated with all flows mapped to the bearer.

[0418] If a flow is not associated with a minimum communication range configured by upper layers, the WTRU may assign a default value (eg, 0 m) to the minimum communication range associated with the flow.

[0419] The transmitting WTRU may modify transmission-related parameters for a bearer or for a transmission associated with a minimum communication range. For example, when the WTRU determines that one or more receiving WTRUs are outside the minimum communication range (e.g., the minimum communication range associated with the bearer), the transmitting WTRU may modify the transmission-related parameters (e.g., parameters associated with the bearer). The transmitting WTRU may make such a determination based on signaling and / or transmissions from the receiving WTRU, as described herein. For example, the transmitting WTRU may use one or more configured parameters for a best effort scenario, as described herein. These best effort parameters may be fixed or predetermined and / or may correspond to default values. The transmitting WTRU may use such configured or predetermined parameters to replace the configured parameters associated with the SLRB. For example, when one or more (e.g., all) transmitting WTRUs are outside the minimum communication range of the SLRB, the transmitting WTRU may replace the SLRB configuration with one or more of the following configurations or predetermined values.

[0420] The transmitting WTRU may use default or preconfigured variables or parameters in the LCP procedure. For example, the transmitting WTRU may use different values ​​or default values ​​for PBR, BSR, or Bj during the LCP procedure. The transmitting WTRU may set Bj to 0 (or a similar default value) for SLRB or LCH. The transmitting WTRU may set the allowable BW, the number of allowable resources, the number of allowable carriers, etc. associated with resource selection to a default value, a configured value, or a predetermined value. The transmitting WTRU may use a default or different priority value (e.g., as used in LCP) for LCH. The transmitting WTRU may modify one or more LCP restrictions to allow or not allow LCH to be multiplexed with other LCHs. In an example, the transmitting WTRU is allowed to multiplex the multiple LCHs together if (e.g., only if) the intended WTRU is within the minimum communication range of at least one of the multiple LCHs. In an example, the transmitting WTRU is allowed to multiplex the multiple LCHs together if (e.g., only if) the intended WTRU is outside the minimum communication range of at least one of the multiple LCHs.

[0421] The transmitting WTRU may use default or preconfigured variables or parameters for resource selection. For example, the transmitting WTRU may set the resource selection window to different values ​​(e.g., for resource selection associated with multiple LCHs, where the WTRU is expected to be outside the minimum communication range of at least one of the multiple LCHs). The transmitting WTRU may set parameters associated with several resources to a default value or predetermined value for one or more side link processes. The several resources may include those resources that the WTRU may reserve in advance or maintain after reselection. The one or more side link processes may be used for multiple LCHs, where the predetermined WTRU is outside the minimum communication range of at least one of the multiple LCHs. The transmitting WTRU may be allowed to perform periodic transmissions in the following circumstances (e.g., only in the following circumstances): those transmissions include data that the WTRU is expected to be within a certain minimum communication range. The transmitting WTRU may be configured with different resource availability thresholds.

[0422] The transmitting WTRU may use default or preconfigured values ​​for one or more PHY parameters. For example, the transmitting WTRU may set transmission parameters such as MCS, TX power, and / or number of retransmissions to default, predefined, or configured values ​​for transmissions associated with an LCH for which the WTRU is expected to be outside a certain minimum communication range. The transmitting WTRU may be allowed duplication of a transmission based on whether the transmission is associated with an LCH for which the WTRU is expected to be within a certain minimum communication range.

[0423] The transmitting WTRU may use default or preconfigured values ​​for unicast or multicast feedback configuration. For example, the transmitting WTRU may disable HARQ feedback associated with transmissions where the intended receiver (e.g., WTRU) is outside a certain minimum communication range. The transmitting WTRU may disable transmission of CSI-RS when one or more receiving WTRUs are outside the minimum communication range associated with one or more (e.g., any or all) LCHs or SLRBs.

[0424] The transmitting WTRU may modify the flow-bearer mapping for a flow associated with a minimum communication range. For example, the transmitting WTRU may change the flow-bearer mapping associated with the flow based on whether the expected receiving WTRU of the flow is within or outside a certain minimum communication range. The transmitting WTRU may map a flow for which at least one of the expected WTRUs is within the minimum communication range to a SLRB having one or more QoS requirements configured to meet the flow. The transmitting WTRU may map a flow for which at least one of the expected WTRUs is outside the minimum communication range to a default or best effort SLRB. The default or best effort SLRB may be associated with default, predefined or configured parameters similar to those discussed herein, which may be modified for QoS specific SLRBs.

[0425] A transmitting WTRU may consider one or more of the following factors when deciding whether to use best effort SLRBs and / or parameters to perform a transmission (eg, in addition to determining whether the receiving WTRU is within a certain minimum communication range).

[0426] The transmitting WTRU may take into account the measured congestion of one or more SL resources when deciding whether to perform a transmission using best effort SLRBs and / or parameters. For example, the transmitting WTRU may be configured with a threshold channel busy ratio and may decide to perform a transmission using best effort parameters if the measured channel busy ratio is above the threshold. The transmitting WTRU may be configured to use different SLRB configurations or parameters (e.g., different default configurations or parameters) based on the measured channel busy ratio.

[0427] The transmitting WTRU may consider the speed of the transmitting WTRU and / or the relative motion between the transmitting WTRU and the receiving WTRU when deciding whether to use best effort SLRBs and / or parameters to perform a transmission. For example, the transmitting WTRU may be configured to perform a transmission using a default SLRB configuration and / or parameters when (e.g., only when) the speed of the WTRU is below a threshold or the relative speed of the WTRU compared to one or more other WTRUs (e.g., a peer WTRU) is below a threshold.

[0428] The transmitting WTRU may take into account the network configuration when deciding whether to perform a transmission using best effort SLRBs and / or parameters. For example, the transmitting WTRU may be configured (e.g., via SIB or RRC signaling) with an indication of whether to perform a transmission using default SLRB parameters. Such an indication may be implicit (e.g., it is included or indicated by the network in the configuration regarding such parameters).

[0429] The WTRU may be configured to perform best effort transmission when the WTRU is beyond the minimum communication range.

[0430] The WTRU may be configured to favor (eg, give higher priority to) transmissions with a lower minimum communication range during congestion control (eg, in order to alleviate congestion).

[0431] The WTRU may operate using different sets of congestion control TX parameters based on range requirements (e.g., minimum communication range) for transmissions (e.g., data transmissions). For example, a lower / smaller minimum communication range transmission may take precedence (e.g., be given higher priority) over a larger minimum communication range transmission when congestion occurs (e.g., when the minimum communication range may not be met for a larger minimum communication range transmission due to congestion control). The WTRU may perform one or more of the following during congestion control.

[0432] The WTRU may set default values ​​for TX related parameters (e.g., set TX power to 0). The WTRU may drop a transmission. The WTRU may stop performing resource selection for a transmission. The WTRU may disable HARQ for a transmission. The WTRU may disable carrier aggregation for a transmission. The WTRU may suspend SLRBs and / or LCHs associated with a transmission.

[0433] The WTRU may be configured with a set of congestion control TX parameters (e.g., maximum TX power, retransmission limit, maximum number of selected subchannels, etc.). These parameters may be configured based on congestion, priority, and / or transmission range. For example, the WTRU may be configured with a corresponding set of congestion control parameters for different combinations of one or more of the following values, and the WTRU may apply a set of congestion controlled TX parameters that corresponds to a combination of values ​​associated with the measured CBR and the set of transmission parameters being used. The one or more values ​​may include, for example, a range of measured CBRs, a priority value (e.g., PPPP or LCH priority), a latency value, a reliability value, and / or a minimum communication range value or a set of minimum communication range values.

[0434] The WTRU may determine or may be configured with a threshold minimum communication range. The WTRU may perform congestion control for a transmission differently based on whether the transmission has an associated minimum communication range that is above or below the configured threshold minimum communication range. The WTRU may perform congestion control differently for a transmission based on whether the measured CBR meets a specific criterion (e.g., whether the CBR is above a threshold, for example, for a transmission of a specific priority). For example, when the measured CBR meets a specific criterion (e.g., a set of preconfigured criteria), the WTRU may apply default values ​​for one or more TX parameters (e.g., setting the maximum TX power to 0) for transmissions with a minimum communication range above a threshold. The WTRU may determine a single threshold, or the WTRU may determine corresponding thresholds for multiple destination L2 IDs (e.g., for each destination L2 ID). The WTRU may determine the threshold(s) based on one or more of the following.

[0435] The WTRU may determine the threshold(s) based on a network configuration. For example, the WTRU may be configured to have one or more threshold minimum communication ranges. Different threshold minimum communication ranges may be configured for different measured CBR levels, for different LCH or PPPP priority levels, for different PQI values, and / or for different latency requirements associated with the same data transmission.

[0436] The WTRU may determine the threshold(s) based on distance information (e.g., the distance between the WTRU and one or more other WTRUs or one or more gNBs). For example, the WTRU may determine the threshold MCR based on explicit information about the distance between the WTRU and a peer WTRU. The WTRU may calculate the threshold based on the peer WTRU that is at the shortest distance from the current WTRU. For example, the threshold may be calculated as a percentage of the shortest distance, where the percentage may be configurable (e.g., by the network).

[0437] The WTRU may determine the threshold(s) based on, for example, HARQ, CQI, and / or other feedback from a peer WTRU. For example, the WTRU may determine the threshold minimum communication range based on one or more feedback received from a peer WTRU or multiple WTRUs. Such feedback may include, for example, measured power (e.g., RSRP) from HARQ feedback from one or more peer WTRUs, CQI reports from one or more peer WTRUs, ACK / NACK status from one or more peer WTRUs.

[0438] In an example, the WTRU may derive the threshold minimum communication range using (e.g., based on) a preconfigured formula or function of RSRP associated with a PSFCH transmission. The PSFCH transmission may be received from a group of one or more WTRUs associated with the same L2 destination ID (e.g., received via a multicast link or a unicast link), where congestion control is considered for the PSFCH transmission. The RSRP may be a minimum RSRP, a maximum RSRP, or an average RSRP (e.g., in the case of multicast). The RSRP may correspond to the last PSFCH transmission from a group of one or more WTRUs associated with a multicast link or a unicast link. The WTRU may calculate the average RSRP of such PSFCH transmissions over a period of time (e.g., within a time window). The WTRU may use the average RSRP to calculate the threshold minimum communication range.

[0439] The WTRU may treat transmissions that do not have a configured minimum communication range requirement (e.g., for unicast or multicast transmissions) as having a maximum minimum communication range or an infinite minimum communication range. Such transmissions may be subject to conventional congestion control (e.g., without regard to the minimum communication range). For example, these transmissions may not be dropped or deprioritized when the range cannot be met.

[0440] SLRBs can be specifically configured to meet certain QoS requirements.

[0441] Due to SIB overhead and / or non-standardized PQIs that require broadcast of QoS information (eg, all QoS information), the SLRB configurations mapped to QoS profiles may be limited (eg, for a WTRU in idle mode).

[0442] The WTRU may be configured (eg, among multiple configurations) to select the SLRB configuration that best represents the QoS profile of the flow.

[0443] The WTRU may determine the SLRB configuration for a particular QoS profile and / or flow that is not configured by the network (e.g., via SIB, pre-configuration, or dedicated signaling) by selecting the SLRB configuration that best represents the configuration of that QoS profile or flow. The WTRU may make this determination based on the similarity of QoS parameter values ​​in the QoS profiles (e.g., the QoS profile associated with the configured flow).

[0444] A WTRU may be configured with one or more QoS profiles (e.g., equivalent QoS profiles) for a QoS flow (e.g., in addition to an actual QoS profile). Such configuration may be provided, for example, from an upper layer. A WTRU configured with a flow associated with a non-standardized PQI may be configured with one or more standardized PQIs (e.g., equivalent standardized PQIs) and may select a configuration associated with the standardized PQI when establishing an SLRB for a non-standardized PQI flow.

[0445] The WTRU may determine which of the configured SLRB configurations to use for a QoS flow or profile that does not have a network configuration, for example, by selecting an SLRB configuration associated with a QoS profile having the same or similar one or more similar QoS parameters. For example, the WTRU may select an SLRB configuration associated with a QoS profile having the same latency requirement (e.g., in a PQI), the WTRU may select an SLRB configuration associated with a QoS profile having the same reliability requirement (e.g., in a PQI), etc.

[0446] Although the examples described herein may consider LTE, LTE-A, New Radio (NR), or 5G specific protocols, it should be understood that the examples described herein are not limited to these scenarios and may also be applied to other wireless systems.

[0447] Although the features and elements are described above in specific combinations, it will be understood by those skilled in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embedded in a computer-readable medium and executed by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM discs and digital versatile discs (DVDs). A processor associated with the software may be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: A processor configured to: determining a set of resources available to the WTRU for performing a sidelink transmission, wherein the set of resources is associated with a configured type 1 grant; determining a set of one or more logical channels, wherein each of the one or more logical channels in the set is determined based on the logical channel having data available for transmission and having a corresponding bucket size parameter having a value greater than zero, wherein each of the one or more logical channels in the set is further determined based on whether the configured type 1 grant is allowed for the logical channel, and wherein, in the case where hybrid automatic repeat request (HARQ) feedback is not configured for the set of resources, each of the one or more logical channels in the set is further determined based on the logical channel having disabled HARQ feedback; selecting a destination associated with a logical channel having a highest priority in the set of one or more logical channels; and The sidelink transmission to the selected destination is performed using at least a portion of the set of resources available for the sidelink transmission, wherein the sidelink transmission includes data associated with the logical channel having the highest priority in the set of one or more logical channels.

2. The WTRU of claim 1 , wherein the respective bucket size parameter associated with each logical channel in the set of the one or more logical channels is determined based on a prioritized bit rate associated with the logical channel.

3. The WTRU of claim 1 , wherein, in a case where HARQ feedback is configured for the resource set, each logical channel in the set of one or more logical channels is further determined based on the logical channel having enabled HARQ feedback.

4. The WTRU of claim 1 , wherein the processor is further configured to receive configuration information regarding the configured type 1 authorization from a network device.

5. The WTRU of claim 4, wherein the processor is configured to determine that the set of resources are available to the WTRU based on a periodicity associated with the configured type 1 grant.

6. A WTRU according to claim 1, wherein the processor is configured to perform the sidelink transmission to the selected destination includes the processor being configured to determine the amount of data to be transmitted to the selected destination based on the bucket size parameter associated with the logical channel having the highest priority in the set of one or more logical channels.

7. The WTRU of claim 1, wherein the sidelink transmission is a unicast transmission, a multicast transmission, or a broadcast transmission.

8. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: determining a set of resources available to the WTRU for performing a sidelink transmission, wherein the set of resources is associated with a configured type 1 grant; determining a set of one or more logical channels, wherein each of the one or more logical channels in the set is determined based on the logical channels having data available for transmission and having a corresponding bucket size parameter having a value greater than zero, wherein each of the one or more logical channels in the set is further determined based on whether the configured type 1 grant is allowed for the logical channel, and wherein, in a case where hybrid automatic repeat request (HARQ) feedback is not configured for the set of resources, each of the one or more logical channels in the set is further determined based on the logical channel having disabled HARQ feedback; selecting a destination associated with a logical channel having a highest priority in the set of one or more logical channels; and The sidelink transmission to the selected destination is performed using at least a portion of the set of resources available for the sidelink transmission, wherein the sidelink transmission includes data associated with the logical channel having the highest priority in the set of one or more logical channels.

9. The method of claim 8, wherein the respective bucket size parameter associated with each logical channel in the determined set of one or more logical channels is determined based on a prioritized bit rate associated with the logical channel.

10. The method of claim 9, wherein in a case where HARQ feedback is configured for the resource set, each logical channel in the determined set of one or more logical channels is further determined based on the logical channel having enabled HARQ feedback.

11. The method of claim 8, further comprising receiving configuration information regarding the configured Type 1 authorization from a network device.

12. The method of claim 11, wherein the set of resources is determined to be available to the WTRU based on a periodicity associated with the configured type 1 grant.

13. A method according to claim 8, wherein performing the sidelink transmission to the selected destination includes determining an amount of data to be transmitted to the selected destination based on the bucket size parameter associated with the logical channel having the highest priority in the set of one or more logical channels.

14. A wireless transmit / receive unit (WTRU), the WTRU comprising: A processor configured to: determining a first logical channel associated with a sidelink destination; determining a second logical channel associated with the sidelink destination, the determination based on a distance between a first minimum communication range (MCR) of the first logical channel and a second MCR of the second logical channel; as well as In response to determining that the distance between the first MCR and the second MCR is less than a threshold, the first logical channel and the second logical channel are multiplexed.

15. The WTRU of claim 14, wherein the processor is further configured to receive configuration information about the first MCR and the second MCR from a base station.

Images