Procedures for enabling simultaneous transmission of various types

Abstract

To provide a method and a wireless transmit receive unit (WTRU) for enabling simultaneous transmission of different types of transmission protocols.SOLUTION: In a communication system, a WTRU receives configuration information arriving from a network via a base station, receives a data packet from an upper layer of a protocol stack operating on the WTRU, determines a transmission type for the data packet at a first time based on the configuration information and a condition, and transmits the data packet using the determined transmission type. The configuration information includes decision criteria associated with determining the transmission type and a set of logical channels that are associated with data properties. The transmission type is one of a network scheduled mode, WTRU autonomously scheduled mode, LTE, NR, unicast, groupcast, or broadcast.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 784,040, filed December 21, 2018, and U.S. Provisional Patent Application No. 62 / 840,797, filed April 30, 3019, the contents of which are incorporated herein by reference. [Background technology]

[0002] background

[0002] As wireless capabilities evolve, interconnected systems are possible that combine multiple use cases to further improve communication and information sharing. For example, vehicle-to-everything (V2X) can be used to wirelessly connect traffic-related devices with the environment surrounding the traffic infrastructure. As these systems evolve, the protocols and procedures for wireless device interaction must also evolve. Summary of the Invention

[0003] overview

[0003] A system, method, and apparatus for enabling simultaneous transmission of various types of transmission protocols. A device, such as a wireless transmit / receive unit (WTRU), can receive configuration information and receive data packets from upper layers of a protocol stack running on the WTRU. The WTRU can then determine a transmission type of the data packet at a first time based on the configuration information and conditions. The WTRU can then transmit the data packet using the determined transmission type. The configuration information can include criteria related to determining the transmission type and a set of logical channels related to data characteristics. The transmission type can be one of network-scheduled mode, WTRU autonomous-scheduled mode, LTE, NR, unicast, groupcast, or broadcast.

[0004] BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Furthermore, like reference numbers in the figures indicate like elements. [Brief explanation of the drawings]

[0005] [Figure 1A] FIG. 5 is a system diagram illustrating an example of a communication system in which one or more disclosed embodiments may be implemented. [Figure 1B]

[0006] 1B is a system diagram illustrating an example of a wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1C]

[0007] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D]

[0008] 1B is a system diagram illustrating a further example of a RAN and a further example of a CN that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 2]

[0009] 1 is a flow diagram illustrating an example of a process for processing data packets for transmission. [Figure 3]

[0010] FIG. 10 illustrates an example of a data packet processing process when conditions change. [Figure 4]

[0011] 10 is a flow diagram illustrating an example of a process for communicating buffer status reports and scheduling requests. DETAILED DESCRIPTION OF THE INVENTION

[0006] Detailed Description

[0012] 1A illustrates an example of a communication system 100 in which one or more disclosed embodiments can be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, 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-tailed unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0007]

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

[0008]

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

[0009]

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

[0010]

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

[0011]

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

[0012]

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

[0013]

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

[0014]

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

[0015]

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

[0016]

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

[0017]

[0023] The RAN 104 may communicate with the CN 106, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 and / or CN 106 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 or a different RAT. In addition to being connected to the RAN 104, which may utilize, for example, NR radio technology, the CN 106 may also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0018]

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

[0019]

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

[0020]

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

[0021]

[0027] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, output control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated within an electronic package or chip.

[0022]

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

[0023]

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

[0024]

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

[0025]

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

[0026]

[0032] The processor 118 may obtain power from the power source 134 and may be configured to distribute and / or control power to other components within 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 batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0027]

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

[0028]

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

[0029]

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

[0030]

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

[0031]

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

[0032]

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

[0033]

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

[0034]

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

[0035]

[0041] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 by an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during handovers between eNode Bs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0036]

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

[0037]

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

[0038]

[0044] Although FIGS. 1A-1D depict the WTRU as a wireless terminal, certain representative embodiments contemplate that such a terminal may employ a wired communication interface (eg, temporarily or permanently) with a communication network.

[0039]

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

[0040]

[0046] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic into and out of the BSS. Traffic to a STA originating from outside the BSS may arrive and be delivered to the STA through the AP. Traffic originating from a STA to a destination outside the BSS may be sent to the AP to be delivered to its respective destination. Traffic between STAs within the BSS may be sent through the AP; for example, a source STA may send traffic to the AP, which can deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent (e.g., directly) between a source STA and a destination STA using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using an IBSS (e.g., all of the STAs) can communicate directly with each other. IBSS mode communication may also be referred to herein as an "ad hoc" mode of communication.

[0041]

[0047] When using 802.11ac infrastructure mode of operation or a similar mode of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a 20 MHz wide band) or a dynamically configured width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, for example, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented within an 802.11 system. In CSMA / CA, STAs (e.g., all STAs), including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is in use, the particular STA can back off. Within a given BSS, one STA (e.g., only one station) can transmit at any given time.

[0042]

[0048] For example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel, a high throughput (HT) STA can use the 40 MHz wide channel for communication.

[0043]

[0049] A Very High Throughput (VHT) STA may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. A 40 MHz and / or 80 MHz channel can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, which may be called an 80+80 configuration. In the 80+80 configuration, the channel-encoded data can be passed through a segment parser, which can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above 80+80 configuration operation can be reversed, and the combined data can be sent to the Medium Access Control (MAC).

[0044]

[0050] Sub-1 GHz modes of operation are supported by 802.11af and 802.11ah. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidths and carriers. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to exemplary embodiments, 802.11ah can support meter-type control / machine-type communication (MTC), such as MTC devices, within macro coverage areas. MTC devices may have limited functionality, including support for (e.g., only) specific and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0045]

[0051] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, can include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by a STA among all STAs operating in the BSS that can support the minimum bandwidth operating mode. In the 802.11ah example, the primary channel can be 1 MHz wide for a STA (e.g., an MTC-type device) that supports (e.g., only supports) 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) configuration can depend on the state of the primary channel. For example, if the primary channel is in use by a STA (that only supports 1 MHz operating mode) transmitting to the AP, all available frequency bands can be considered in use, even if most of the available frequency bands remain unused.

[0046]

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

[0047]

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

[0048]

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

[0049]

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

[0050]

[0056] 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 can communicate with the gNBs 180a, 180b, 180c without accessing any other RANs (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c can communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with / connect to a gNB 180a, 180b, 180c while also communicating with / connecting to another RAN, such as an eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0051]

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

[0052]

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

[0053]

[0059] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 by an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling various protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service being utilized. For example, different network slices may be established for different use cases, such as services relying on Ultra-Reliable Low-Latency (URLLC) access, services relying on enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, etc. The AMFs 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that use other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0054]

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

[0055]

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

[0056]

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

[0057]

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

[0058]

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

[0059]

[0065] The one or more emulation devices may perform one or more functions, inclusive, without being implemented / introduced as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a test laboratory and / or in a test scenario within an unintroduced (e.g., test) wired and / or wireless communication network to perform testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0060] [Begin disclosure of 14596]

[0066] Vehicle communications, also known as Vehicle to Everything (V2X), is a communication mode in which vehicles (e.g., trucks, cars, etc.) can communicate directly with each other and / or with surrounding infrastructure (e.g., roadside units (RSUs)). As disclosed herein, vehicles are associated with, integrated with, and may be referred to interchangeably as WTRUs. There may be two scenarios for V2X operation: an in-coverage scenario in which the WTRU receives network assistance to initiate transmission and reception of V2X messages, and / or an out-of-coverage scenario in which the WTRU uses some pre-configured parameters to initiate transmission and reception of V2X messages.

[0061]

[0067] V2X communication may involve activities performed in device-to-device (D2D) communication. V2X communication services may include at least four different types of interactions: vehicle-to-vehicle (V2V), in which WTRUs in vehicles may communicate directly with each other; vehicle-to-infrastructure (V2I), in which WTRUs in vehicles may communicate with an RSU / eNB; vehicle-to-network (V2N), in which WTRUs in vehicles may communicate with a core network; and vehicle-to-pedestrian (V2P), in which WTRUs in vehicles may communicate with pedestrian (e.g., non-vehicle) WTRUs that have special conditions (e.g., low battery capacity).

[0062]

[0068] There are several operating modes related to V2X resource allocation. In LTE, there can be at least two operating modes for V2X communication. Mode 3 is a mode in which the network provides scheduling instructions to the WTRU for V2X sidelink transmissions. Mode 4 is a mode in which the WTRU autonomously selects resources from a configured / pre-configured resource pool. In addition to these modes, V2X LTE can include at least two categories of resource pools: a receive pool that is monitored to receive V2X transmissions, and a V2X transmit pool that is used by the WTRU to select transmission resources in Mode 4. The transmit pool cannot be used by a WTRU configured in Mode 3.

[0063]

[0069] In LTE, the resource pool may be semi-statically signaled to the WTRU by RRC signaling. In Mode 4, the WTRU may use sensing before selecting resources from the RRC-configured transmission pool. In some cases, LTE V2X may not support dynamic resource pool reconfiguration, and pool reconfiguration may only be carried by SIBs and / or dedicated RRC signaling.

[0064]

[0070] New Radio (NR) can be thought of as the "next generation" radio system. NR systems can support several use cases, such as enhanced mobile broadband (eMBB) and ultra-reliable and / or low latency communications (URLLC).

[0065]

[0071] Enhanced V2X (eV2X) communications can be part of the NR system. eV2X in NR can support new services for both safety and non-safety scenarios (e.g., sensor sharing, autonomous driving, vehicle platooning, remote driving). Different eV2X services may have different performance requirements (e.g., a 3 ms latency may be required).

[0066]

[0072] NR V2X can support new use cases such as vehicle platooning, advanced driving, expanded sensors, and remote driving.

[0067]

[0073] Vehicle platooning may enable vehicles to dynamically form a group that travels together. To perform platooning maneuvers, all vehicles in the platoon may receive periodic data from the leading vehicle. This information may enable extremely tight inter-vehicle distances (e.g., gap distances translated into time may be very small, such as less than one second). Platooning applications may enable autonomous driving of the following vehicles.

[0068]

[0074] Advanced driving may enable semi-autonomous or fully autonomous driving. In this use case, longer vehicle distances may be expected. Each vehicle and / or roadside unit (RSU) can share data from its local sensors with nearby vehicles, allowing the vehicles to adjust their trajectory or maneuver. Additionally, each vehicle can share its driving intentions with nearby vehicles. Some benefits of this use case are safer driving, collision avoidance, and / or improved traffic efficiency.

[0069]

[0075] The extended sensors may enable the exchange of raw or processed data or live video data collected by local sensors between vehicles, RSUs, pedestrian devices, and V2X application servers, potentially enhancing the vehicle's awareness of the environment beyond what its own sensors can detect and providing a more comprehensive understanding of the local situation.

[0070]

[0076] Tele-driving may enable a remote driver or V2X application to operate a remote vehicle for passengers who are unable to drive themselves or in hazardous environments. For use cases with limited variability and predictable routes, such as public transportation, cloud computing or tele-driving based driving can be implemented. Additionally, access to a cloud-based backend service platform can be considered for this use case.

[0071]

[0077] Both LTE and NR may be radio access technologies (RATs) that support eV2X. NR V2X can complement LTE V2X for advanced V2X services and may support interoperation with LTE V2X. Therefore, a WTRU may need to support both NR and LTE sidelink operation simultaneously.

[0072]

[0078] LTE V2X can support both NW-scheduled mode (Mode 3) and WTRU-autonomous mode (Mode 4). NR V2X can also support NW-scheduled mode (Mode 1) and WTRU-autonomous mode (Mode 2). Furthermore, there may be submodes of Mode 2 for V2X, such as Mode 2a, where the WTRU autonomously selects sidelink resources for transmission, Mode 2c, where the WTRU is configured with an NR configuration grant (such as type-1) for sidelink transmission, and / or Mode 2d, where the WTRU schedules sidelink transmissions of other WTRUs. Mode 2b-like behavior may also be an option for features that can be incorporated into any of the other modes. In Mode 2b, the WTRU can assist other WTRUs in sidelink resource selection.

[0073]

[0079] In some situations, LTE V2X may act as a broadcast mechanism at the access stratum (AS) layer. A V2X WTRU may be provided with an L2 destination ID from a higher layer corresponding to the V2X service. The WTRU may include the L2 destination ID in the MAC header, and reception may be based on the WTRU filtering MAC PDUs with an L2 destination ID that matches the service in which the WTRU is interested.

[0074]

[0080] With NR V2X, there may be more stringent requirements combined with use cases (e.g., platooning) that also motivate the use of unicast and groupcast transmissions. With unicast and groupcast transmissions, the WTRU can leverage feedback from the receiver (e.g., HARQ, CQI) to optimize transmit power, retransmissions, etc., to enable more efficient use of resources and better control of QoS.

[0075]

[0081] There is a possible QoS model for NR V2X. QoS over PC5 can be supported by ProSe Per-Packet Priority (PPPP). The application layer can mark packets with PPPP, which indicates the desired QoS level. Certain extensions can be added, such as deriving a Packet Delay Budget (PDB) from PPPP.

[0076]

[0082] NR QoS may have additional features. These additional features may include key performance indicators with one or more of the following parameters (and their units): payload (bytes), transmission rate (messages / second), maximum end-to-end delay (ms), reliability (%), data rate (Mbps), and / or minimum required communication range (meters).

[0077]

[0083] The same set of service requirements may be applied to both PC5-based V2X communications and Uu-based V2X communications, so that there may be a unified QoS model for PC5 and Uu (e.g., also using 5QI for V2X communications over PC5), so that the application layer may have a consistent way of indicating QoS requirements regardless of the link being used.

[0078]

[0084] Considering a 5GS V2X-enabled WTRU, there can be at least three different types of traffic: broadcast, multicast, and unicast.

[0079]

[0085] For unicast-type traffic, the same QoS model as for Uu can be used (e.g., each unicast link can be treated as a bearer and a QoS flow can be associated with it). All QoS characteristics and additional parameters of data rate defined in 5QI can also be applied. In addition, minimum required communication range can be treated as an additional parameter, especially for PC5 applications. Similar considerations can be applied to multicast traffic, since multicast traffic can be treated as a special case of unicast (e.g., with multiple defined receivers of the traffic). For broadcast traffic, there may be no concept of a bearer, and therefore each message may have different characteristics according to the application requirements. 5QI can then be used in a similar manner to Prose Per Packet Priority / Prose Per Packet Reliability (PPPP / PPPR) (e.g., tagged with each packet). 5QI can represent all characteristics required for PC5 broadcast operation (e.g., delay, priority, reliability, etc.). A set of 5QIs specific to V2X broadcast (e.g., Voice Quality Index (VQI)) can be defined for use with PC5.

[0080]

[0086] One or more use cases as discussed herein may require the WTRU to perform simultaneous operations, which may refer to one or more operations performed by the WTRU, such as transmitting, receiving, processing, making decisions, or executing an operational mode. These operations may include handling one or more transmission types, such as the WTRU handling simultaneous transmission types, as appropriate. As discussed herein, transmission type may refer to a transmission mode, such as, but not limited to, a WTRU autonomous mode or a network-scheduled mode (e.g., Mode 3 or Mode 4 in LTE, or Mode 1 or Mode 2 in NR), a submode of NR Mode 2 (e.g., Mode 2a, Mode 2c, Mode 2d), a sidelink radio access technology (SL RAT) such as the WTRU may transmit over an NR SL RAT or an LTE SL RAT, or a type of broadcast using which an NR V2X WTRU may transmit. Combinations of these transmission types (e.g., Mode 2 over an NR SL RAT versus Mode 3 over an LTE SL RAT) may also be considered separate modes in their own right.

[0081]

[0087] In one or more embodiments, there may be simultaneous operation in Mode 1 and Mode 2. In LTE V2X, the WTRU may be configured only in Mode 3 or Mode 4 based on the decision of the NW. Specifically, if the system information includes the required V2X resource pool, the WTRU may perform Mode 4 resource selection in RRC_IDLE. Otherwise, the WTRU may be forced to start an RRC connection, and the NW may provide the pool, allowing the WTRU to operate in Mode 4, or the WTRU may become scheduled in Mode 3. If the WTRU operates simultaneously in Mode 1 and Mode 2, the WTRU may use the NW grant or the grant from resource selection to transmit buffered data. A procedure may be required in the WTRU to determine which data to transmit on Mode 1 or Mode 2. The Mode 2 resource selection rules may need to consider NW resource availability, while Mode 1 interaction with the network (e.g., BSR reporting) may also need to consider the availability of Mode 2 resources at the WTRU. Approaches to address simultaneous operation in Mode 1 and Mode 2 may be discussed herein.

[0082]

[0088] In one or more embodiments, there may be simultaneous operation on the LTE and NR sidelink (SL). The WTRU may need to operate simultaneously on both the LTE SL and the NR SL. Some packets may be tagged by higher layers as required for transmission on LTE or NR (e.g., due to backward compatibility or strict QoS requirements), while other packets may be allowed on either RAT. For such packets, a procedure may be required in the WTRU to manage the load on each RAT and select the appropriate RAT to ensure that the packet is transmitted while respecting its QoS. Techniques for addressing simultaneous operation on LTE SL and NR SL may be discussed herein.

[0083]

[0089] In one or more embodiments, there may be simultaneous operation in unicast, groupcast, and broadcast. A WTRU may receive packets from higher layers associated with a unicast or groupcast link (e.g., packets targeted to a unique WTRU) as well as packets associated with a broadcast transmission (e.g., packets associated with an L2 destination ID monitored by multiple WTRUs). Given that any of the cast types can operate using Mode 1 or Mode 2, resource allocation may need to be done when considering the two modes. In particular, the NW may need to know the amount of data buffered for each cast type to operate in Mode 1. Additionally, resource and carrier selection may allow for a set of common resources for each cast type to avoid resource isolation. Approaches to address simultaneous operation in unicast, groupcast, and broadcast may be discussed herein.

[0084]

[0090] When dealing with embodiments that address simultaneous WTRU operation, one issue that may arise is how to select a transmission type for data in different situations. To address this issue, there may be multiple models of Layer 2 architecture for simultaneous use of transmission types, as well as criteria and WTRU actions for selecting a transmission type.

[0085]

[0091] When discussing various models related to the simultaneous use of transmission types, it is intended that each model described herein is presented as an example, and that features of one model or example may be applicable to another model or other described situation. Numbers associated with the models are merely intended to provide reference to particular examples and are not intended to confer any significance regarding a preferred approach.

[0086]

[0092] FIG. 2 is a flow diagram illustrating an example procedure for selecting a transmission type for data. Each model described herein may perform all or part of the procedure shown in the figure. Generally, for any model, the WTRU may first receive 201 a configuration, which includes configuration information or settings that the WTRU can use to determine or decide an appropriate transmission type for a given situation. The configuration may arrive from the network via an appropriate device (e.g., a base station, such as a gNB or eNB). Data may be received 202 from a higher layer as part of normal operation of the WTRU (e.g., received at a lower level in a stack of protocol layers operating on the WTRU), and the data may be one or more data packets for transmission. The WTRU may determine or decide 203 an appropriate transmission type for the received data packet based on the received configuration information and other criteria. This determination / decision process may be further described herein. The WTRU may then transmit 204 the data packet using the appropriate transmission type. At some point, the WTRU may change the type of transmission based on conditions (e.g., a change in conditions measured by the WTRU, a condition such as a new configuration received from the network, or a condition such as an event) and / or criteria (205). During the example process of Figure 2, the WTRU may communicate with another WTRU (e.g., on the sidelink) and / or the network (e.g., a base station) and may convey a scheduling request (SR) and / or a buffer status report (BSR) to further facilitate the process. Additionally, the WTRU may perform a carrier / resource selection process based on the conditions and / or the types of concurrent transmissions.

[0087]

[0093] In a first model, there may be a fixed mapping of logical channels to transmission types. Logical channels may be created by the WTRU, or the network may be associated with only a single transmission type. Within each transmission type, the WTRU may create several logical channels, each of which may be associated with different QoS requirements and / or different destination IDs. This mapping may be part of the configuration information the WTRU receives in 201. For example, the WTRU may create a logical channel for transmitting data over the LTE RAT, or may create a logical channel for transmitting data over the NR RAT. In another example, the WTRU may create a logical channel for transmitting data using Mode 1, or may create a logical channel for transmitting data using Mode 2. In another example, the WTRU may create a logical channel for transmitting unicast data. The WTRU may create separate logical channels for unicast transmissions to different destination WTRUs.

[0088]

[0094] In the first model, the WTRU may receive a data packet for transmission from higher layers, just like 202. Based on the criteria described herein, the WTRU may decide to send the data packet on a logical channel associated with one transmission type or another, just like 203. In that case, the decision may be made by the WTRU upon arrival of the packet from higher layers.

[0089]

[0095] The WTRU may receive a packet that it decides to use transmission type x, but may not have an appropriate logical channel active for transmission type x. In that case, the WTRU may create a new logical channel associated with mode x. Alternatively or in conjunction, the WTRU may indicate the need to create a new logical channel from the network, for example, by transmitting a MAC CE, an RRC message, or a Uu PHY channel transmission (e.g., SR, PUCCH, etc.). This determination and creation of the new logical channel may occur at 203.

[0090]

[0096] The WTRU may decide to create / remove a logical channel associated with a transmission type based on one of the following: one of the criteria discussed herein is met and there is no logical channel for the transmission type (e.g., create logical channel), or the criteria is that all data is transmitted using only a single transmission type (remove logical channel), the logical channel associated with a transmission type no longer allows some types of data (e.g., a particular QoS or VQI) to be mapped to that transmission type (e.g., remove logical channel), the WTRU does not receive packets that map to a certain transmission type discussed herein for a (pre-)configured period of time, and / or is informed / reconfigured by the network. This creation / removal of a logical channel may occur at 203 or 205 depending on the circumstances prompting the change.

[0091]

[0097] In a second model, the WTRU can move a logical channel from one transmission type to another. This model can be used in combination with the first model of fixed logical channels to transmission types. Here, a logical channel can be configured to be of a certain transmission type only for a given period of time, such as at 205, where the transmission type can change, or at 203, where the transmission type can change based on parameters related to received data packets. The WTRU can decide to move a logical channel from one transmission type to another, for example, based on criteria discussed herein. In this model, the decision on which transmission mode to use to transmit a particular data packet can be made upon arrival of data from higher layers (e.g., when the arrival of new data causes the logical channel to change from one transmission type to another), periodically based on current and future packets, or based on some event triggered in the WTRU and defined by the criteria discussed herein (e.g., measurements meeting some criteria, etc.).

[0092]

[0098] For example, in the case of Mode 1 / Mode 2, the WTRU may create or be configured with one set of logical channels that use only Mode 1 and one that uses only Mode 2. Additionally, the WTRU may create or be configured with logical channels that may use a single resource selection mode (Mode 1 or Mode 2) at a given time but that can change from one mode to another. The WTRU may be configured with a mapping of data to logical channels (e.g., based on QoS). Additionally, the WTRU may decide to move one or more logical channels from transmitting using one transmission type to transmitting using another transmission type, either periodically or based on a trigger received from a lower layer.

[0093]

[0099] The WTRU may be configured with the maximum number of such logical channels that can change from one transmission type to another. The WTRU may further be configured with the intervals or time periods during which the logical channels can change their transmission type. In particular, the WTRU may perform an evaluation of the criteria for each such "changing" logical channel (e.g., based on criteria discussed herein) only during the defined time period. The WTRU may further use information available over the previous change interval to determine the transmission type of the logical channel.

[0094]

[0100] In this model, the WTRU can apply the decision criteria defined herein for switching the transmission type of a logical channel only to the QoS / VQI that is mapped to this logical channel, and not simply to the QoS / VQI of a particular data packet. In particular, the WTRU can be configured to create a logical channel for each VQI or set of VQIs. By considering only the QoS / VQI that is mapped to this logical channel, the WTRU can apply the decisions defined herein that depend on the data type or QoS.

[0095]

[0101] In a third model, a logical channel may be associated with multiple transmission modes. This model may be used in combination with the first modeling of fixed logical channels for transmission type, where a logical channel may be configured with multiple transmission modes. In such modeling, the WTRU may determine the particular transmission mode to use when transmitting data, such as at 204, and possibly not when receiving data from higher layers, as opposed to when transmitting data.

[0096]

[0102] For example, in the case of an LTE RAT and an NR RAT, the WTRU may create or be configured with a set of logical channels transmitted on the LTE RAT and a set of logical channels configured on the NR RAT, just as in 201. The WTRU may be further configured with or create one or more logical channels associated with both RATs. In such an example, the WTRU may receive a packet from higher layers just as in 202 and transmit the packet on an LTE RAT or NR RAT logical channel based on the criteria described herein. Additionally, the WTRU may decide to transmit a particular packet on a logical channel that is mapped to both the LTE RAT and the NR RAT. The actual mapping of data to logical channels can occur at the time of transmission, such as in 204.

[0097]

[0103] FIG. 3 illustrates an example of data processing as conditions change. In this example, a WTRU may be handling various transmission types, such as Mode 1 and Mode 2. Time progresses horizontally, with time T1 in 301 and time T2 in 302 illustrated to distinguish two different points in time. In a typical WTRU transmission situation, the WTRU may be configured with a set of logical channels (e.g., LCH1-4). The WTRU may be instructed or may decide to assign a logical channel to a transmission type. In the middle section 312, this example shows that logical channels LCH1 and LCH2 are associated with Mode 1 at T1, and logical channels LCH3 and LCH4 are associated with Mode 2 at T1. Data packets are received from higher layers and assigned to logical channels based on criteria related to the transmission type. Some condition (e.g., change in radio conditions) may prompt the WTRU to change the transmission type assigned to a logical channel at or some time between T1 and T2, as shown by 312 where logical channel LCH1 is changed to Mode 2 at T2. This drawing may be further described herein.

[0098]

[0104] To determine the type of transmission of data during simultaneous WTRU operation, there may be conditions and / or criteria for selecting the type of transmission and WTRU actions. The WTRU may select the type of transmission for sidelink data based on one or more (e.g., a combination) of the factors listed in Table 1. The listed criteria may also be considered conditions, and the conditions may have parameters associated with them.

[0099] [Table 1]

[0100] [Table 2]

[0101]

[0105] These criteria are not intended to be an exhaustive list, but may broadly represent the types and nature of criteria that may be useful in certain circumstances to determine the selection of transmission types.

[0102]

[0106] In a reference situation where the WTRU determines the transmission type of data to be transmitted based on characteristics of the data available for transmission, the WTRU may select the transmission type of the data based on the QoS requirements of the data to be transmitted. For example, the WTRU may select the transmission mode of a packet (e.g., Mode 1 vs. Mode 2) based on a (pre-)configured mapping of QoS parameters associated with the data (e.g., VQI, PPPP, PPPR, delay, reliability, range, etc.) to the transmission mode.

[0103]

[0107] In one example of this situation, the WTRU may be (pre-)configured with a set of VQIs at which the WTRU should transmit packets using Mode 1 / Mode 2, or with a VQI threshold above / below which the WTRU should transmit packets using Mode 1 / Mode 2. If a packet is received and tagged with a VQI that satisfies the condition, the WTRU may transmit the packet using Mode 1 / Mode 2. Otherwise, the WTRU may transmit the packet using Mode 2 / Mode 1.

[0104]

[0108] In another example of this situation, the WTRU may select a RAT for transmission based on a VQI associated with that RAT in addition to a measurement of the CBR associated with each RAT. In particular, the WTRU may select a RAT for transmission based on a (pre-)configured table of VQI and CBR (e.g., LTE CBR or NR CBR) or the difference in CBR between the RATs. The WTRU may prioritize an NR RAT to be used for certain transmissions for which the NR RAT can be accommodated, as long as the CBR is not high or significantly higher than the LTE CBR. Such prioritization may be incorporated into the RAT selection based on a (pre-)configured VQI / CBR table in the WTRU.

[0105]

[0109] In a reference situation, the WTRU determines the transmission type of data to be transmitted based on the frequency and / or size of the transmission. In particular, the WTRU may determine the transmission type based on the frequency of the transmission (i.e., periodic or aperiodic and the periodicity of the transmission) and / or the size of the message (e.g., maximum message size, minimum message size, average message size, etc.). For example, the WTRU may be configured to use Mode 2 for periodic transmissions, possibly in combination with other conditions (e.g., periodic transmissions with a CBR above / below a threshold). Similarly, the WTRU may be configured to use Mode 1 if the average / minimum / maximum message size (e.g., for SLRB) is above a threshold.

[0106]

[0110] In a reference situation, the WTRU determines the transmission type of data to be transmitted based on the characteristics of the sidelink session. In one example, the WTRU can determine the transmission type based on the group size of the sidelink groupcast. For example, in a group with a large number of members, the WTRU can be configured to use Mode 1, whereby feedback resources from all receiver WTRUs can be allocated by the network. Similarly, if the group size is small, the WTRU can be configured to use Mode 2 for sidelink groupcast. Here, the transmitter WTRU can allocate feedback resources for each of the receiver WTRUs. A HARQ feedback mechanism can also be used to determine the transmission type. In a HARQ NACK-only mechanism, receiver WTRUs can share feedback resources only for NACK messages. Thus, the WTRU can be configured to use Mode 2 for sidelink groupcast. If a HARQ ACK / NACK mechanism is used, the WTRU can be configured to use Mode 1 for sidelink groupcast.

[0107]

[0111] In a reference situation where the WTRU decides the type of data transmission based on the availability of sufficient resources for that type of transmission, such decision may be based on any of the following determined by the transmitting WTRU or determined by a peer WTRU (e.g., a WTRU in a unicast link with the transmitting WTRU) and indicated to the transmitting WTRU: availability of SR resources, possibly associated with a particular RAT and / or particular cast type and with acceptable timing / delay for the arrival of data; available uplink resources, possibly associated with a particular RAT and / or particular cast type and with acceptable timing / delay for the transmission of a BSR (e.g., to indicate the arrival of data); available uplink resources, possibly associated with a particular requirement or a particular logical channel, with acceptable timing / delay for the transmission of data. available periodic resources, the WTRU detecting a change in the periodicity, offset, or packet size of some data (e.g., the WTRU may change to Mode 2 transmission over a period of time when it detects a change in the periodicity, offset, or packet size of some data), the particular type of available SL grant, possibly in combination with the QoS requirements associated with the data, the amount of resources configured by the network for either type of transmission (e.g., the WTRU determines the type of transmission based on the amount of resources configured by the network for either type of transmission, and such a decision may be made to use an equal resource share for both types), and / or an inability to select sufficient resources using Mode 2 resource selection or a failure of Mode 2 resource selection.

[0108]

[0112] For a particular type of available SL grant, depending on which grant is available first in time and which grant has characteristics (e.g., grant size, MCS for transmission, number of configured retransmissions) that meet the data requirements, the WTRU can choose to use either an LTE grant or an NR grant (assuming both grants are available) for data transmissions with low latency requirements. Such a grant may be a Mode 2 / 4 grant or a Mode 1 / 3 grant.

[0109]

[0113] With regard to the inability to select sufficient resources, the WTRU may decide to use Mode 1 for some data transmission after a resource selection procedure that may fail for any of the following reasons: inability to obtain Mode 2 resources by LBT after a period of time or after several attempts, e.g., because one / more / all of the available resources selected for transmission fail the LBT (e.g., are occupied during clear channel assessment), or because the number of failures or the number / amount of backoff time possibly exceeds a threshold related to the required delay of the packet; inability to obtain Mode 2 resources by LBT after a period of time or after several attempts, determined at the time of resource selection or periodically determined for transmission; The number of Mode 2 resources considered available falls below a (pre-)configured or defined threshold, where determining the availability of Mode 2 resources may include excluding resources pre-reserved by transmissions such as SCI and / or measuring RSRP / RSSI on PSSCH / PSCCH; scheduling the WTRU for Mode 2d is not possible or reachable for a period of time; and / or possibly one / more / all of the resource patterns configured for the WTRU for use with the transmitted data are not available or do not meet the delay requirements of the transmitted data.

[0110]

[0114] Further regarding the inability to select sufficient resources, the WTRU can decide whether to use the NR RAT or the LTE RAT based on the number of possibly recent resource allocations that were deemed successful on either RAT. In particular, the WTRU can measure the number or proportion of resource selection procedures on each RAT that determined x% of the resources were available during resource selection, and can select the RAT with the smallest number or proportion.

[0111]

[0115] Further regarding the inability to select sufficient resources, the resource selection may be based on sensing results and / or measurements determined at the transmitting WTRU or sensing results and / or measurements provided by a peer WTRU.

[0112]

[0116] Further regarding the inability to select sufficient resources, the WTRU may perform carrier selection and determine insufficient resources for resource selection if the number of allowed / selected carriers is below a certain number (this number may be related to the bearers / flows / VQIs of the data being transmitted).

[0113]

[0117] In one scenario involving determining the type of transmission based on resource availability, the WTRU can use Mode 2 if SR / BSR resources are unavailable or do not meet the timing requirements. The WTRU can use Mode 1 transmission if it is configured with available SR resources to meet the timing requirements of the transmitted data or if it can obtain a grant for BSR transmission in sufficient time to transmit the data. If the WTRU is not configured with sufficient SR resources or if the delay determined by the WTRU for transmitting BSR and subsequent sidelink data is greater than the delay requirement of the data transmission itself, the WTRU can use Mode 2 resources (e.g., forward-booked or one-off resources). Upon determining that Mode 1 cannot be used for the above reasons, the WTRU can perform Mode 2 resource selection or prioritize the transmission of such data over existing Mode 2 grants (e.g., periodically occurring resources).

[0114]

[0118] In one scenario involving determining the type of transmission based on resource availability, the WTRU can use the NR RAT if the SR / BSR resources for the LTE RAT are unavailable or do not meet timing requirements. In the example of a WTRU configured to use Mode 1 NR simultaneously with Mode 3 LTE, the WTRU can be configured with SR resources specific to each RAT. The WTRU can determine the sidelink RAT on which to transmit a packet based on the timing of the NR RAT SR relative to the LTE RAT SR, possibly in combination with configured rules. In particular, the WTRU can be configured to transmit data over the LTE / NR RAT, possibly related to a particular service, cast, etc., as long as the SR configuration over the LTE / NR RAT allows the WTRU to transmit the packet within the required delay. If a packet arrives and the LTE / NR RAT SR is configured such that the packet delay is not respected, the WTRU can transmit the packet over the NR / LTE RAT instead. The WTRU transmits an NR / LTE SR to the network for the associated data and can include the data within the data multiplexed over a future NR / LTE grant.

[0115]

[0119] In certain scenarios involving determining the type of transmission based on resource availability, the WTRU may use Mode 1 if resource selection using Mode 2 does not meet timing requirements. In one example, a WTRU may be configured to use Mode 2 resource selection for data associated with a particular bearer / flow or associated with a particular VQI. If one or more (pre-)configured or defined resource selection attempts performed on data for such bearer / flow / VQI fail to select resources that meet the QoS requirements of the data (e.g., delay, reliability), the WTRU may be further configured to use Mode 1 for the aforementioned bearer / flow / VQI. For example, resource selection may require a sensing procedure similar to that of LTE. For a particular VQI, the WTRU may require that a (pre-)configured percentage X of available resources be available. A WTRU performing the resource selection process that does not determine that X percent of resources are available may transmit the aforementioned data packet on Mode 1. Alternatively, the WTRU may maintain a count of the number of such failed resource selection attempts, possibly associated with a particular bearer / flow / VQI, and may decide to transmit the bearer / flow / VQI over Mode 1 if the number of failed resource selection attempts in succession or within a configured time period exceeds a certain amount.

[0116]

[0120] The WTRU in the above scenario may continue to transmit bearers / flows / VQIs using Mode 1 even though said bearers / flows / VQIs are configured in Mode 2, for a period that may be determined by either a (pre-)configured timer, one or more successful resource selection indications for other bearers / flows / VQIs using Mode 2, and / or the congestion measure on the Mode 2 pool changing below a configured threshold.

[0117]

[0121] In certain scenarios involving determining the type of transmission based on resource availability, the WTRU may select a transmission mode based on the size / configuration of a Mode 2 resource pool. In one example, the WTRU may choose to use Mode 1 or Mode 2 for transmission of a particular type of data based on the configuration of the Mode 2 resource pool. In particular, the WTRU may use Mode 2 for transmissions associated with a particular VQI if the time between slots configured for SL transmission in the Mode 2 resource pool is less than a threshold, which may further be related to the VQI or delay requirements of the transmitted data. In another example, the WTRU may use Mode 1 or Mode 2 transmission of data in a manner such that the amount or proportion of data using Mode 2 is proportional to the size of the pool configured by the network for Mode 2 transmission.

[0118]

[0122] In one scenario involving determining the type of transmission based on resource availability, the WTRU may change transmission modes when it detects a change in the periodicity / offset / size or periodic data. In one example, the WTRU may transmit some data using Mode 2 when it detects a change in the periodicity / timing / offset of its transmission. The WTRU may further decide to perform such a mode switch when it is unable to transmit WTRU assistance information in time to adjust the SPS resources to meet the data delay requirements associated with the SPS configuration. The WTRU may transmit only a portion of the data that is mapped to the SPS configuration (e.g., in the case of a change in size) using Mode 2. Upon detecting a change in periodicity / timing / offset, the WTRU may decide to transmit all or a portion of the data utilizing the SPS resources. The WTRU may continue to transmit WTRU assistance information associated with the SPS configuration. After the network reconfigures the SPS configuration to meet the new periodicity / offset / size requirements, the WTRU may resume using Mode 1 SPS resources.

[0119]

[0123] In a reference situation where the WTRU may decide the type of transmission based on a network decision, the network may explicitly or implicitly indicate the type of transmission to the WTRU based on either the RRC configuration, DCI, and / or MAC CE.

[0120]

[0124] With respect to RRC configuration, in one example, the WTRU may be explicitly configured to use a particular transmission type, possibly associated with certain types of data, and in another example, the WTRU may receive an SPS reconfiguration for the SPS process (e.g., a Type 1 or Type 2 configuration grant). If the grant size associated with the reconfiguration is smaller than the requested grant size in the WTRU assistance information, the WTRU may use Mode 2 to transmit the remaining data (e.g., the difference between the requested grant size in the WTRU assistance information and the actual SPS grant size provided by the network).

[0121]

[0125] With respect to the DCI, in one example, the WTRU may receive an indication in the DCI that only a certain portion of the volume reports in the BSR will be processed by the network using Mode 1. The WTRU may then use Mode 2 to transmit the remaining data in its buffer, having first transmitted the buffer status in the BSR.

[0122]

[0126] With respect to the MAC CE, in one example, the WTRU may receive a MAC CE indicating that it should change logical channels from using one transmission type to using another transmission type.

[0123]

[0127] In a reference situation where a WTRU may determine the type of transmission based on Uu coverage or Uu restricted area, the determination may possibly be based on the WTRU's Uu coverage relative to the Uu coverage of other WTRUs. A WTRU's determination of Uu coverage may include one or more factors.

[0124]

[0128] One element may be the decision whether to perform V2X communication while the WTRU is in-coverage or out-of-coverage. In particular, the WTRU may select the type of transmission, possibly of some type of data, depending on whether the WTRU itself or other related WTRUs (e.g., destinations of unicast / groupcast links) are in-coverage or out-of-coverage.

[0125]

[0129] Another factor may be consideration of the quality of the Uu for the WTRU, such as Uu RSRP, among other things, the WTRU may select the type of transmission of possibly some types of data based on the measured Uu RSRP being above or below a threshold.

[0126]

[0130] Another factor may be the consideration of the system information validity area for the WTRU, and in particular the WTRU may select the type of transmission of some data based on whether the WTRU and a peer WTRU have the same / different system information validity area.

[0127]

[0131] In certain scenarios involving Uu coverage or limited areas, the WTRU may use Mode 1 for unicast as long as the WTRU is served by the same gNB / SysInfoArea / PLMN. In one example, the WTRU may be configured to use Mode 1 for unicast / groupcast transmissions when all WTRUs involved in unicast / groupcast transmissions are in or under the coverage of the same gNB, same PLMN, same System Information Area, etc. When any of the WTRUs moves out of coverage, the WTRU may move an ongoing unicast transmission using Mode 1 to Mode 2.

[0128]

[0132] In some cases, the WTRU may transmit an indication of a change between in-coverage and out-of-coverage, or may transmit an indication of a change in the serving gNB / PLMN / SysInfoArea and / or the serving gNB / PLMN / SysInfoArea. Such a change indication transmission may be broadcast by the WTRU, or may be transmitted using unicast / groupcast transmission only to WTRUs with which the WTRU is currently communicating. Such a change indication transmission may be transmitted on the PSCCH, SL-MIB, or PSSCH. The PSSCH transmission may take the form of a MAC CE or SL-RRC message. The WTRU may include the new serving gNB, PLMN, or SysInfoArea with the indication, or may include in the indication whether the WTRU is in-coverage or out-of-coverage, and / or may include any Uu measurements of the gNB to which the WTRU is camped / attached. The WTRU may further include measurements of nearby gNBs in such an indication.

[0129]

[0133] The WTRU may transmit an indication of the change to the scheduler WTRU or head WTRU according to a similar method as described above.

[0130]

[0134] A WTRU that receives the instruction can decide to change between Mode 1 and Mode 2 transmission based on its Uu connection state and the information in the instruction. In particular, a first WTRU in the coverage of a gNB can decide to transmit to a second WTRU using Mode 1 in unicast when it receives an instruction from the second WTRU indicating that the second WTRU is also in the coverage of the same gNB. Alternatively, the first WTRU can change from transmission Mode 1 unicast to Mode 2 unicast for a second WTRU if it receives an instruction from the second WTRU indicating that the second WTRU is in the coverage of a different gNB or a gNB that is not part of the default list of gNBs.

[0131]

[0135] In certain scenarios involving Uu coverage or limited areas, the WTRU may use Mode 1 as long as the Uu RSRP is above a threshold. In one example, the WTRU may be configured to use Mode 1, possibly for certain types of data, as long as the Uu RSRP measured by the WTRU is above a (pre-)configured threshold; otherwise, the WTRU may use Mode 2. Additionally, the WTRU may be configured with different RSRP thresholds associated with different bearers / flows / VQIs, and may choose to use Mode 1 for a particular flow / bearer / VQI if the Uu RSRP is above the threshold associated with that flow / bearer / VQI. Additionally, such thresholds may further depend on the speed.

[0132]

[0136] In a reference situation where the WTRU may determine the transmission type based on the service type, the WTRU may determine the transmission type used for sidelink data based on the service type of the transmitted data. The WTRU may be (pre-)configured with a mapping of service types to transmission types, such as an RRC mapping or a mapping provided by a higher layer of destination ID to transmission mode (e.g., Mode 1 or Mode 2), an RRC mapping or a mapping provided by a higher layer of destination ID to RAT (LTE RAT or NR RAT), and based on the mapping, the WTRU may select a transmission mode and / or RAT for transmitting packets on the sidelink. In addition, the mapping may further depend on other factors discussed herein. For example, the WTRU may be configured with a mapping of destination ID to transmission mode for each range of measurement CBRs and / or may have mappings configured for various regions or geographical locations, and may observe such mappings under each CBR and / or geographical region.

[0133]

[0137] In a reference situation where the WTRU may decide the transmission type to use for sidelink data based on sidelink load or quality measurements and / or resource availability, the decision may further depend on a comparison of such measurements of sidelink load or quality relative to other transmission types. The WTRU may select a transmission type based on lowest load / best quality, or may select one transmission type as long as the load associated with that transmission type is below a certain threshold or the quality of that transmission type is above a certain threshold.

[0134]

[0138] The WTRU may base its transmission type decision on any or a combination of the following measures: a channel busy ratio (CBR) measurement for a pool, resource pattern, or BWP; possibly the WTRU's own channel occupancy (CR) associated with one or more pools, resource patterns, or BWPs; an RSSI measurement of sidelink resources associated with one or more pools, resource patterns, or BWPs, or a subset thereof, which may correspond to the resources selected by the WTRU for its transmission; an RSCP measurement of sidelink channels, such as PSSCH, feedback channels, synchronization signals, or reference signals, transmitted by one or more involved WTRUs, such as WTRUs to which the WTRU is currently on a unicast / groupcast link; an estimated number of WTRUs in the area; the number of configured carriers / BWPs / resource pools; and / or detection of a received preemption signal.

[0135]

[0139] In one example, a WTRU may be configured to measure the CBR of a Mode 2 pool in the NR RAT and a Mode 4 pool in the LTE RAT. The WTRU may determine the RAT for transmitting some or all of its data based on its CBR measurement, and may decide to transmit in the RAT with a lower CBR, or may change RAT if the RAT of transmission has a CBR below a threshold CBR measured on the other RAT. The WTRU may further be configured with rules for converting LTE CBR to NR CBR or vice versa so that the LTE CBR and NR CBR can be compared on an equal basis.

[0136]

[0140] In another example, the WTRU may be configured to measure the CBR and / or CR of the Mode 2 pool, and may transmit some or all of its data using Mode 1 if the CBR and / or CR of the Mode 2 pool are above a (pre-)configured threshold.

[0137]

[0141] In another example, a first WTRU may be configured to measure the RSRP of a sidelink reference signal received from a second WTRU with which it is configured in unicast. For certain types of data, the first WTRU may be configured to transmit that data using a unicast transmission type only if the RS-RSRP exceeds a certain threshold. The first WTRU may further maintain separate logical channels related to the transmission of data or services to the second WTRU, one using a unicast link (e.g., configured by a feedback channel, HARQ, etc.) and another using an SL broadcast mechanism. If the RS-RSRP exceeds a certain threshold, the first WTRU may transmit packets destined for other specific WTRUs and / or services using the unicast link. One advantage of such an approach is that it limits the number of HARQ retransmissions for eMBB-type data, but continues to apply HARQ-type transmissions for URLLC-type data.

[0138]

[0142] In another example, the WTRU may be configured to select a RAT for transmission for a particular service or type of transmission (e.g., associated with a particular QoS) based on the number of carriers on each RAT available for transmission. In particular, the WTRU may select a RAT for a service or type of data based on a greater number of carriers available on one RAT compared to another RAT. The WTRU may determine the number of carriers available on a RAT for a service or type of data based on the carriers configured for transmission on that RAT for that service and / or the WTRU's carrier capabilities on each RAT.

[0139]

[0143] In another example, a WTRU may use Mode 1 for transmission of some or all of its data after receiving a preemption signal from another WTRU. Such a preemption signal may further indicate which data should utilize Mode 1 transmission. The WTRU may continue to use Mode 1 transmission for a (pre)configured period or for a period indicated in the preemption signal. The same example and WTRU behavior related to preemption may also be used for changing from an NR RAT to an LTE RAT or from unicast to broadcast.

[0140]

[0144] Without loss of generality, the above approaches relating to these situations can be combined with other approaches described herein. For example, the WTRU can select between Mode 1 and Mode 2 transmission for particular data based on a comparison of the Uu RSRP and a measurement of the CBR on the Mode 2 sidelink pool. In particular, the WTRU can select a type of transmission using Mode 2 if the Uu RSRP is below a particular threshold and the CBR of the Mode 2 transmission pool is below another particular threshold. Alternatively, the WTRU can select a type of transmission using Mode 1.

[0141]

[0145] In reference situations where the WTRU may determine the type of transmission based on the Uu RRC state, possibly in combination with the state of the RRC timers, the WTRU may select or change the type of transmission based on either the WTRU transitioning from one RRC state (e.g., RRC_CONNECTED, RRC_IDLE, RRC_INACTIVE) to another RRC state (e.g., the WTRU may change to unicast transmission of certain types of data when transitioning to RRC_CONNECTED, but may use broadcast transmission in RRC_IDLE and RRC_INACTIVE), or the WTRU starting an RRC-related timer such as, but not limited to, timers related to RLF, BFR, access barring, etc. With respect to the RRC-related timers, in one example, the WTRU may change to Mode 2 transmission at the start of T310 (e.g., upon detection of a PHY layer problem with the PCell) and may resume Mode 1 transmission when T310 stops (e.g., by receiving an N311 continuous synchronization indication from lower layers). In another example of RRC related timers, the WTRU may change to broadcast transmission at the start of T310 (e.g., upon detection of a PHY layer problem on the PCell) and may resume Mode 1 transmission when T310 stops (e.g., upon receiving an N311 continuous synchronization indication from lower layers). In another example of RRC related timers, the WTRU may use Mode 2 transmission for some or all SL transmissions while T309 is running (e.g., access attempts are barred). In another example of RRC related timers, if a beam failure occurs during unicast transmission, the WTRU may use broadcast transmission to transmit unicast.

[0142]

[0146] In a reference situation where the WTRU may determine the type of transmission based on the dynamic characteristics of the WTRU, the WTRU may select the type of transmission for some data based on any or a combination of the WTRU's measured speed, the WTRU's absolute position, the WTRU's position relative to another WTRU, the WTRU's speed relative to another WTRU, the WTRU's direction relative to another WTRU, and / or the WTRU's detection of a change in any of the speed / position / direction (e.g., if there is a detected change in any of the speed / position / direction, the WTRU temporarily uses a transmission type (e.g., based on a timer)).

[0143]

[0147] In one example, a WTRU may be configured to transmit certain data, possibly destined for a particular WTRU, using a unicast link as long as the WTRU's speed is below a threshold, otherwise the data may be transmitted using a broadcast.

[0144]

[0148] In another example, the WTRU may be configured to use Mode 1 for some / all data if the WTRU's speed is below a (pre-)configured threshold, and may use Mode 2 otherwise.

[0145]

[0149] In another example, the first WTRU may be configured to use unicast transmission when the distance between the first WTRU and a second WTRU (e.g., the second WTRU is communicating with the first WTRU) is below a (pre-)configured threshold or some threshold that depends on the characteristics (e.g., QoS) of the data being transmitted.

[0146]

[0150] In this situation, the WTRU may make periodic sidelink transmissions about its position, velocity, or direction. Such transmissions may occur on the PSCCH, SL-MIB, or PSSCH. Transmission of such information on the PSSCH may occur within MAC CE or SL-RRC messages. A WTRU receiving this position / velocity / direction transmission may use that information in addition to its own dynamics (e.g., vehicle dynamics) to determine the type of transmission based on (pre-)configured rules.

[0147]

[0151] In the reference situation where the WTRU may decide the type of transmission based on users of other transmission types, such decision may be based on (pre-)configured restrictions, which may be applied in combination with or under any additional techniques / conditions for type selection described herein. For example, the WTRU may be configured to use Mode 1 only when making unicast transmissions associated with a particular QoS.

[0148]

[0152] In criteria situations where the WTRU may determine the transmission type based on carrier / BWP / resource pool limitations, the WTRU may be (pre-)configured with a particular transmission type based on those criteria. For example, the WTRU may be configured to use Mode 1 on a first carrier and Mode 2 on a second carrier. Alternatively, the WTRU may use one transmission type on a carrier and another transmission mode on a different carrier based on other factors described herein. For example, the WTRU may be configured to use Mode 1 on the carrier with the highest measured CBR and Mode 2 on another carrier. The number of carriers using Mode 1 (e.g., with the highest CBR) may be further (pre-)configured, or may depend on the capabilities of the WTRU, or may be the number of carriers available for a particular service (e.g., destination address). For example, the number of carriers using Mode 1 (e.g., corresponding to the highest CBR) may be defined as a percentage of the carriers configured for a particular destination address and / or as the number of carriers supported by the WTRU.

[0149]

[0153] In a reference situation where the WTRU may decide the type of transmission based on the amount of traffic configured for each type, the traffic used for such decision may consist of the WTRU's own transmissions or other WTRU's transmissions (e.g., detected based on SCI transmissions). For example, the WTRU may select a RAT for transmission to obtain equal amounts or a (pre-)configured ratio of LTE SL and NR SL transmissions.

[0150]

[0154] In a reference situation where the WTRU may indicate a transmission type opportunity to the network, the WTRU may indicate to the network a change in transmission type for some or all of the data in the WTRU's buffer or possibly some or all of the future data that the WTRU will receive. The WTRU may be further configured with a threshold value that, when exceeded, may indicate a change in transmission type. This threshold may be based on one or more of the amount of data in the WTRU's buffer that is moved from one transmission type to another, the number of VQI or QoS levels that change from one transmission type to another, the amount of change in a metric (e.g., amount of available resources, RSSI, SCI RSCP) that may cause a change in transmission type for some data, and / or other values ​​or metrics that determine a change in transmission type for certain data.

[0151]

[0155] The WTRU may indicate the change in transmission type using one or more of a dedicated SR or PUCCH, a RACH (e.g., a two-step RACH with information of the change in transmission type in the RACH procedure), a MAC CE such as a BSR or a new MAC CE, an RRC message, connection establishment and / or resumption with a new cause value or indication provided in MSG3 or MSG5 (e.g., the WTRU may initiate an RRC connection and provide information related to the change in transmission type during connection establishment).

[0152]

[0156] In a reference situation where a WTRU may change transmission type based on receiving a mode change from another WTRU, the second WTRU may transmit an indication of the transmission type change to the first WTRU or the first set of WTRUs. For example, the second WTRU may transmit an indication of the transmission mode (e.g., a change to Mode 1 vs. Mode 2 or Mode 1 / Mode 2). If the second WTRU decides to change modes, the second WTRU may transmit the indication of the mode change on the PSCCH, PSSCH, or SL-MIB. Such an indication of the mode change may take the form of a MAC CE or SL-RRC message transmitted on the PSSCH to a set of WTRUs that are in a unicast / groupcast state with the second WTRU. Upon receiving the indication of the mode change from the second WTRU, the first WTRU may decide to change its transmission mode to match that of the other WTRU. If a first WTRU receives a mode change from a second WTRU with a unicast link that indicates, among other things, that the second WTRU is to use mode 2, the first WTRU may change its transmission mode for that unicast link from mode 1 to mode 2 (e.g., it may transmit all packets specific to that unicast link using mode 2).

[0153]

[0157] In some circumstances, the WTRU may be configured with respect to mode selection. In one example, the WTRU may be configured with an allowable, required, or preferred mode or transmission type (e.g., Mode 1 or Mode 2) for the SLRB. In particular, the SLRB or LCH may be configured to use only Mode 1, or may be configured to use only Mode 2. Additionally, the WTRU may be configured with the conditions under which the SLRB should use Mode 1 or Mode 2. Such conditions may be based on one or more of the quality of the Uu, the quality of the SL signal, the amount of data in the WTRU's buffer for the SLRB, the resource / carrier / BWP, the frequency / periodicity, and / or the size of the transmission.

[0154]

[0158] With regard to the quality of Uu, the WTRU may be configured with conditions related to the quality of Uu for which the SLRB should use Mode 1 or Mode 2. The signal quality of Uu may be determined either by cell-level measurements (i.e., RRM measurements) of the current cell or other cells, and / or by the allowable UL power (e.g., power headroom). For example, the WTRU may be configured to use Mode 1 as long as the measured cell quality of its serving cell is above a threshold, and to use Mode 2 otherwise.

[0155]

[0159] With regard to SL signal quality, the WTRU may be configured with SL quality-related conditions under which the SLRB should use Mode 1 or Mode 2. The quality of the SL signal may be determined based on a congestion measure (e.g., CBR) of the transmission resource pool used by the WTRU, a measure of the HARQ success rate on the sidelink (e.g., number of NACKs over a period of time, number of consecutive NACKs, number of missed ACKs / NACKs), a channel quality measure for reference signals such as CSI-RS, DMRS, etc., measurements reported from peer WTRUs such as SL CQI reports, allowable SL power (e.g., power headroom), the state of the SL RLM / RLF associated with the unicast link containing the SLRB (e.g., whether the RLF timer is running, number of IS / OOS from lower layers, triggering of RLF), and / or the size of the configured resource pool, possibly within a certain time budget, successful resource selection related metrics (i.e., resource selection can be made to meet delay requirements), etc. For example, the WTRU may be configured to use / select Mode 2 for the SLRB as long as the CBR is below a threshold, and to use Mode 1 otherwise. In another example, it can be configured to use / prefer Mode 2 for SLRBs associated with unicast links unless the unicast link has triggered an RLF or has an active RLF counter.

[0156]

[0160] With respect to the combination of Uu quality and SL quality, the WTRU may be configured with conditions for selecting or using Mode 1 or Mode 2 based on including both the Uu quality metric and the SL quality metric. For example, such conditions may be based on a comparison of a CBR measurement with a Uu cell measurement and the difference between such measures.

[0157]

[0161] Regarding the amount of data in the WTRU's buffer for the SLRB, the WTRU may be configured with a condition for using one mode (mode 1 or mode 2) in preference to another mode as long as the amount of pending data for the SLRB is below a threshold. Such a limit or threshold may further be related to the size of the resources on the sidelink (e.g., amount of resources for transmission, HARQ feedback, or measured congestion on those resources).

[0158]

[0162] There may be conditions regarding resources / carriers / BWP etc. based on the values ​​selected for transmission by the WTRU and determined by limitations of the transmission modes available for each of these.

[0159]

[0163] Without loss of generality, conditions combining any of the above conditions may be provided.

[0160]

[0164] As mentioned above, when a WTRU has simultaneous operation, there may be one or more logical channels associated with a transmission type, and in some cases one logical channel may be prioritized over another. The WTRU may be configured with at least one separate logical channel prioritization (LCP) procedure for each transmission type. Such configurations may be applicable to different transmission types, such as a WTRU operating with simultaneous Mode 1 and Mode 2 transmissions may perform a Mode 1-specific LCP procedure when receiving a grant from the network and a Mode 2-specific LCP procedure when a grant from resource selection becomes active; a WTRU operating with simultaneous LTE and NR transmissions may perform and LTE-specific LCP when processing grants on an LTE carrier and an NR-specific LCP when processing grants on an NR carrier; a WTRU operating with unicast and groupcast transmissions may perform a unicast-specific LCP if it decides to use or is instructed to use a unicast grant, and a broadcast-specific LCP if it decides to use or is instructed to use a groupcast grant.

[0161]

[0165] The WTRU may use or be configured with various parameters or rules to use for the LCP associated with each transmission type, including, but not limited to, handling of logical channel prioritization (e.g., LTE-related grants may utilize PPPP as a logical channel selection criterion, while NR-related grants may utilize VQI or both VQI-derived priority and delay parameters), determining the amount of data to consider in each logical channel (e.g., LTE-related grants may process each logical channel until data for that logical channel is exhausted, while NR-related grants may process each logical channel up to the PDB associated with that logical channel, if the logical channel is associated with a PDB), and / or rules related to RLC SDU segmentation (e.g., grants associated with LTE processes may allow RLC segmentation, while grants for NR may not allow RLC segmentation).

[0162]

[0166] Alternatively, the WTRU may be configured to use completely separate procedures for the LCP, each procedure relating to a different type of transmission and / or each procedure defining different rules and parameters (e.g., as in the example above).

[0163]

[0167] A WTRU that receives a grant associated with a certain transmission type may execute the LCP using the procedures / parameters / rules associated with that transmission type. The WTRU may also determine the transmission type for a particular grant. Based on this determination, the WTRU may execute the LCP using the procedures / parameters / rules associated with the selected transmission type.

[0164]

[0168] In some situations, the WTRU may decide whether the grant is for unicast / groupcast / broadcast based on implicit / explicit network instructions (e.g., for Mode 1) and / or based on the QoS (e.g., priority, delay, etc.) associated with the pending data.

[0165]

[0169] With respect to implicit / explicit network indication, the WTRU may receive an explicit indication indicating unicast, groupcast, or broadcast in the DCI specifying the grant. Additionally, the WTRU may receive a DCI indicating the RAT of the grant, whereby the RAT does not allow unicast / groupcast transmission (e.g., LTE RAT), and the WTRU may implicitly interpret the grant as a grant for broadcast transmission. Additionally, the WTRU may receive modulation / coding parameters or resource-related parameters (e.g., time / frequency / beam / carrier / BWP / pool) in the DCI that implicitly indicate one type of broadcast based on the WTRU's configuration, WTRU's functional limitations, and / or WTRU's state. For example, the WTRU may be configured with unicast and broadcast transmissions in separate carriers, and the DCI may implicitly indicate the broadcast for transmission from the carrier. In another example, the WTRU may be configured with unicast transmissions on a subset of beams and broadcast transmissions on all beams, and if the DCI includes information for determining the subset of beams, the WTRU may use the grant to fill the unicast logical channel.

[0166]

[0170] With regard to the QoS associated with the pending data, the WTRU can decide to use a grant for unicast, groupcast, or broadcast by first considering the logical channel with the highest priority and / or lowest latency, and / or the logical channel with the highest reliability, etc. For example, the WTRU can select the logical channel with pending data with the highest priority and / or lowest latency from its logical channels. Based on whether the selected logical channel is unicast / groupcast / broadcast, the WTRU can determine whether the grant being processed is unicast / groupcast / broadcast, which can possibly be considered upon receipt of the grant. The WTRU can then process the LCP of this grant using the procedure appropriate for that cast type. In this manner, if the network indicates that the grant is usable for any transmission type, the WTRU can further perform QoS-based association. For example, the DCI can explicitly or implicitly indicate that the grant is usable for unicast or broadcast transmission.

[0167]

[0171] In some situations, a WTRU may be configured to handle simultaneous grants of different types differently depending on the nature of the transmission type (e.g., mode vs. RAT vs. cast) and / or the capabilities of the WTRU. For example, a WTRU capable of simultaneous transmissions of different transmission types may transmit both, while a WTRU that cannot may select one of the transmissions based on certain rules discussed herein.

[0168]

[0172] The WTRU's capability for simultaneous transmissions using different types simultaneously may depend on the nature of the transmission types. For example, a WTRU may not be allowed to transmit Mode 1 and Mode 2 or unicast and broadcast simultaneously on the same RAT, but may be allowed to perform Mode 1 transmissions on the NR RAT and Mode 4 transmissions on the LTE RAT simultaneously, or unicast transmissions on the NR RAT and groupcast transmissions on the LTE RAT simultaneously.

[0169]

[0173] In one approach, if the WTRU receives a Mode 1 grant that overlaps in time with a Mode 2 grant (e.g., a resource selected by the WTRU), the WTRU may prioritize the Mode 1 grant and ignore / cancel the Mode 2 grant. If the Mode 2 grant is ignored / cancelled due to a conflict between the Mode 1 grant and the Mode 2 grant, the WTRU may further reselect resources.

[0170]

[0174] In another approach, if the WTRU receives a Mode 1 grant that overlaps in time with a Mode 2 grant (e.g., resources selected by the WTRU), the WTRU may prioritize the grant (e.g., Mode 1 or Mode 2) with the highest priority / lowest latency data available for transmission on the associated logical channel (e.g., Mode 1 logical channel vs. Mode 2 logical channel). If the WTRU ignores / cancels the Mode 1 grant, the WTRU may trigger an immediate transmission of a BSR. Alternatively, if the WTRU ignores / cancels the Mode 1 grant, the WTRU may transmit an SR on the PUCCH to indicate that the Mode 1 grant has been ignored / canceled.

[0171]

[0175] In some circumstances, the WTRU can perform LCP procedures associated with a particular transmission mode by considering only the logical channels associated with that transmission mode when executing the LCP. This may be applicable to a first modeling of a fixed mapping of logical channels to transmission types, and / or a second modeling in which the WTRU moves logical channels from one transmission type to another. The WTRU may maintain a set of logical channels associated with each transmission mode. Assuming modeling in which the WTRU moves logical channels from one transmission type to another, the WTRU may change the transmission mode associated with the logical channels. The WTRU may evaluate the logical channels associated with each transmission mode at the time of the grant.

[0172]

[0176] In one example, the WTRU may be configured with a second modeling where the WTRU moves logical channels from one transmission type to another for Model 1 and Model 2 transmission cases. When the WTRU receives a Mode 1 grant, the WTRU may perform LCP by considering only the logical channels that are associated with Mode 1 at the time of receipt of the Mode 1 grant.

[0173]

[0177] The WTRU may change the transmission mode associated with a logical channel while the LCP is running (e.g., due to an event received from a lower layer or expiration of a timer), in which case the WTRU may delay changing the transmission mode until after the LCP procedure is completed and / or after retransmission of a MAC PDU is configured to occur by the LCP procedure.

[0174]

[0178] In some situations, a WTRU may be configured with logical channels that are associated with a particular transmission type (e.g., fixed) and logical channels that are not associated with any transmission type (e.g., flexible). This may apply to a third modeling where a logical channel may be associated with multiple transmission modes. When performing LCP for a grant that has an associated transmission type, the WTRU may consider only the logical channels that are associated with that transmission type and the logical channels that are not associated with any transmission type. The WTRU may perform LCP by first selecting the logical channels with the highest priority, regardless of transmission type, and allocating resources to those logical channels until the grant is exhausted or the logical channels are filled (e.g., possibly up to the prioritized bit rate).

[0175]

[0179] In some situations, the WTRU may be configured with or may determine a prioritization of logical channels for a transmission type. This may apply to a third model where a logical channel may be associated with multiple transmission modes. The WTRU may perform the LCP of a grant associated with a transmission type by selecting data on a logical channel that is prioritized for that transmission type as long as there is data in the buffer of such logical channel. If there is no data remaining in the buffer of any prioritized logical channel, or if each logical channel is served up to its prioritized bit rate, the WTRU may select data associated with a non-prioritized logical channel (e.g., prioritized for a transmission type).

[0176]

[0180] In one example, the WTRU may determine the logical channels for the data packets based on QoS. The WTRU may further determine the prioritization of the logical channels for the modes (e.g., Mode 1 and Mode 2) based on criteria as described herein. When a grant for Mode 1 is received, the WTRU may select all prioritized logical channels for Mode 1 to fill the grant. If all such logical channels are filled (e.g., a logical channel is empty or filled to its prioritized bit rate), the WTRU may select non-prioritized logical channels to fill the remainder of the grant.

[0177]

[0181] In some circumstances, an LCP procedure associated with a transmission type may fill a logical channel capable of transmission on any transmission type up to a percentage of its PBR. If a logical channel is not associated with a PBR, the WTRU may fill a percentage of the available data in the WTRU's buffer. The WTRU may determine a PBR percentage for each transmission type based on either: the PBR percentage may be configured by the network; the PBR percentage may be based on the percentage of the BSR reported for each transmission type in the last BSR to the network; the PBR percentage may be based on the measured quality of each transmission type (e.g., LTE RAT vs. NR RAT); or the PBR percentage may be determined or derived from any other condition / criteria described herein (Note: the PBR may be finite for a particular logical channel).

[0178]

[0182] In some situations, the WTRU may decide to prioritize between NR and LTE QoS transmission types. This may occur when LTE prioritization is based on PPPP while NR prioritization is based on VQI. Inter-RAT prioritization may be required for LCP, BSR transmission, resource selection, etc.

[0179]

[0183] In one approach, the WTRU may be provided with QoS parameters associated with both RATs on a packet-by-packet or radio bearer basis and can base its prioritization rules on the QoS parameters of a single RAT. For example, the WTRU may be provided with NR packets containing both PPPP and VQI by higher layers. The WTRU can make prioritization decisions between LTE and NR packets by considering the PPPP associated with each packet.

[0180]

[0184] In another approach, a table may be provided by a higher layer or by the network that the WTRU can use to derive QoS parameters in one RAT (e.g., PPPP) from QoS parameters in another RAT (e.g., VQI). The WTRU can prioritize based on the QoS parameters in one RAT. For example, the WTRU may be provided with a table that maps VQI to PPPP. The WTRU can then prioritize both LTE and NR packets based on PPPP.

[0181]

[0185] In another approach, the WTRU may be provided with a mapping table for one or both RATs, which table can derive one or more QoS parameters from the QoS parameters provided by the upper layer and derive the priority of that RAT based on predefined or (pre-)configured rules. For example, in the case of an LTE packet, the priority of the packet may be PPPP. In the case of an NR packet, the WTRU can be configured by a table that derives reliability, range, delay, priority, and data transfer speed from the VQI. The WTRU can be (pre-)configured by one or more rules for deriving the priority from those individual QoS parameters derived from the VQI. For example, one such rule can be to specify the priority of a packet to be equal to the priority derived from a compensation factor related to VQI and delay (e.g., raise the priority by 1 if the delay < x and lower the priority by 1 if the delay > y). The WTRU can be further configured by various rules for various prioritization operations in the WTRU, such as LCP (e.g., selection of the logical channel having the highest priority among all data pending in the WTRU), BSR (e.g., prioritization of LTE BSR vs. NR BSR, or determination of LCGs to include in the short BSR), etc. In another example, one such rule can be to specify the priority for delay based on a (pre-)configured mapping of delay in ms to priority (e.g., mapped to the same scale as PPPP in absolute terms).

[0182]

[0186] As previously described, the WTRU may report its buffer status, but in some cases there may be SR / BSR procedures to handle QoS requirements and types of simultaneous transmissions.

[0183]

[0187] In some situations, the WTRU may have an SR / BSR procedure to address NR QoS requirements, and the WTRU selects / changes the format of the BSR and / or mapping QoS to LCG based on the data currently in its buffer. Given a limited number of LCGs in the BSR, such selection / change may occur when determining how to report buffer status related to various QoS. The WTRU may assume different mappings of QoS to LCG when determining the BSR, or may transmit BSRs with different formats depending on the QoS of the data in its buffer.

[0184]

[0188] Different mappings of QoS to LCGs may include either a different number of QoS levels or QoS parameters being mapped to a given LCG (e.g., mapping VQI values ​​1, 2 to LCG 1, VQI values ​​2, 3 to LCG 2, etc., or modifying such mappings), a different number of QoS levels being represented by a particular LCG (e.g., some QoS levels may not have an LCG to represent them), a different association of distinct QoS parameters (e.g., delay vs. priority vs. reliability) with LCGs (e.g., mapping PPPP to LCG 1, 2, and PPPR to LCG 3, 4, or modifying such mappings), and / or certain LCGs being used to represent buffer states for different QoS parameters in certain cases but not in other cases.

[0185]

[0189] Different formats of the BSR may include either a different number of bits in the BSR related to an LCG (e.g., a different number of allowed LCGs) (e.g., one format of the BSR may assume 4 bits for LCG and 4 bits for buffer status, while another format may assume 5 bits for LCG and 3 bits for buffer status, or one format of the BSR may assume 12 bits to report buffer status related to a single destination ID and LCG, while another format of the BSR may assume 24 bits to report buffer status related to a destination ID and logical channel group, further allowing for different mappings of QoS levels to LCGs), and / or replacing / reusing certain fields in the BSR to report buffer status related to certain QoS parameters (e.g., the WTRU may replace the destination address related to a buffer status report with additional QoS parameters such as reliability or delay, if such data is available in the WTRU's buffer and if the destination address in the report is the same as in the previous report).

[0186]

[0190] The WTRU may indicate the changed or different mapping / format to the network by one or more of: transmitting an RRC message or MAC CE with an index to the (pre-)configured mapping / format to be used in future BSR reports or with the actual mapping to be used in future BSR reports; transmitting the mapping / format to be used for a particular BSR within the BSR itself by a field in the BSR or by selection of the BSR format or MAC CE type; indicating that a change in mapping / format has occurred by transmitting a dedicated SR or PUCCH indication possibly followed by the actual mapping to be used; and / or providing using the RRC, MAC CE, or BSR itself a bitmap of the QoS levels represented by the LCGs in the BSR and / or the number of QoS levels represented by each available LCG in the LCG space.

[0187]

[0191] The WTRU may change the BSR format / mapping from one format / mapping to another based on any of the following triggers: new data arrives for a QoS level for which there is no LCG representing that format in the current / previous BSR format / mapping; the amount of data in the buffer for one or more mode QoS levels exceeds / falls below a threshold; and / or the relative amount of data in the WTRU's buffer for two or more QoS levels exceeds / falls below a threshold.

[0188]

[0192] In one example, a WTRU may be configured with multiple mappings of VQIs to LCGs. Using one mapping as an illustrative example, where a WTRU can report three LCGs, the WTRU may use LCG1 to report buffer status for data associated with VQIs 1-2, LCG2 to report buffer status for data associated with VQIs 3-4, LCG3 to report buffer status for data associated with VQIs 5-6, and so on, so that all VQIs are equally represented. Additionally, a WTRU may be configured with a mapping where VQI1 is mapped to LCG1, VQI2 is mapped to LCG2, and all remaining VQIs are mapped to LCG3. The WTRU may use the second mapping if the data in its buffer is primarily from VQIs 1 and 2. Alternatively, the WTRU may use the first mapping if the WTRU has data in its buffer that is evenly distributed between the VQIs. The WTRU may indicate a change in mapping (e.g., via an RRC message or MAC CE) or may indicate the mapping to be used in the respective BSR message.

[0189]

[0193] In another example that can be used in combination with the previous example, the WTRU can report the BSR using 4 bits for LCGs in one scenario where the data in the buffer is limited to a subset of QoS levels (e.g., 16 LCGs in total), and 5 bits for LCGs in another scenario where the data in the buffer includes all or nearly all QoS levels (32 LCGs in total).

[0190]

[0194] As mentioned above, the WTRU may signal SR / BSR when determining how to handle data packets for transmission, but there may also be SR / BSR approaches to address types of simultaneous transmissions.

[0191]

[0195] In some situations, the BSR calculation may be based on available Mode 2 resources. In this approach, which may be the case for types of Mode 1 vs. Mode 2 transmissions, the WTRU may calculate the buffer status by considering the amount of resources reserved or available for Mode 2 transmissions. In particular, the WTRU may consider any of the following "reserved" resources in Mode 2 when calculating the buffer status for transmission to the network: the total amount of resources reserved by reservation signals, forward booking signals, etc.; the total amount of resources associated with a selected resource pattern; the amount of "reserved" resources occurring within the next N reservation periods, where N may be pre-defined or configured (pre-configured); and / or the amount of "reserved" resources available to satisfy transmissions over logical channels enabled for Mode 1 or Mode 2 transmissions.

[0192]

[0196] The WTRU may subtract from the buffer status of each logical channel or LCG the estimated amount of data that the WTRU may transmit on the "reserved" resources.

[0193]

[0197] 4 is a flow diagram of an example process by which a WTRU determines buffer status to report to the network in a BSR for a given LCG. At 401, the WTRU may calculate the overall buffer status of all logical channels that can be mapped to that LCG and that are allowed to transmit using Mode 1. Next, at 402, the WTRU may calculate the portion of the buffer status in the previous stage that relates to logical channels of the LCG that are also allowed to transmit using Mode 2. Next, at 403, the WTRU may calculate the amount of buffer status in the second stage that the WTRU can transmit on Mode 2 based on the amount of data in the WTRU's buffer that can only be transmitted using Mode 2 (e.g., logical channels that are mapped to Mode 2 only) 403a, the amount of data from data in step 2 that can still be transmitted using Mode 2 based on the amount of reserved Mode 2 resources and MCS estimates (e.g., average MCS over time) 403b, and / or the current state of criteria discussed herein for determining the portion of data in the second stage that the WTRU is allowed to transmit on Mode 2 given the criteria 403c. At 404, the WTRU may finally report the first stage buffer status minus the estimated mode 2 data in the third stage.

[0194]

[0198] In some circumstances, the WTRU may send a BSR to indicate a change in transmission type. In particular, the WTRU may trigger a BSR to the network during a decision to transmit some or all of the data possibly pending at the WTRU over a different transmission type, or when any of the conditions for determining the transmission type change.

[0195]

[0199] The WTRU may trigger a BSR when any of the following events occur: the WTRU decides to transfer a logical channel associated with one transmission type (e.g., Mode 1) to be associated with a different transmission type (e.g., Mode 2); any condition that defines the mapping of data to transmission types discussed herein changes; a change, possibly from one period to another, in any of the conditions discussed herein, a change in the estimated MCS, or a change in the amount of reserved Mode 2 resources causes a possibly certain amount of change in the buffer state calculation that takes into account available Mode 2 resources; the WTRU removes all logical channels associated with a particular transmission type; and / or the WTRU creates a new logical channel, possibly the first logical channel, associated with the transmission type.

[0196]

[0200] The following are examples of conditions that define the mapping to transmission types: some failures of Mode 2 resource selection possibly occurring within a predefined time window; the value of a measurement quantity related to the Mode 2 resource pool, such as the CBR, CR, RSSI, average RSCP of SCI transmissions, or the number of SCIs within a predefined period, changing by a predefined or (pre)configured amount; the estimated number of WTRUs in the area changing by a predefined or (pre)configured amount; receiving a preemption signal; and / or other examples discussed herein.

[0197]

[0201] In one example, a WTRU may receive a preemption signal possibly associated with Mode 2 transmission for a given QoS. The WTRU may decide to move all Mode 2 traffic possibly associated with the given QoS to Mode 1 and may transmit a BSR to the network upon receiving the preemption signal. The transmitted BSR may indicate the presence of new data for Mode 1 transmission by including a new LCG along with the buffer status, or by a new buffer status that accounts for the new data to be transmitted using Mode 1. Alternatively, the WTRU may send a BSR in which the buffer status represents the delta of new data compared to the previous BSR report, which may now be transmitted via Mode 1. Such an example may also be applicable to other transmission type cases (e.g., LTE-to-NR where preemption is received over NR and Mode 3 is configured for LTE).

[0198]

[0202] In another example, upon detecting a reduction in the CBR of a Mode 2 pool, a WTRU may decide to move all of its transmissions, possibly associated with a particular logical channel or LCG, to Mode 2 transmissions. The WTRU may transmit a BSR indicating a buffer status of 0 associated with said LCG upon such decision. Such an example may also be applicable to other transmission types (e.g., LTE vs. NR). The WTRU may transmit such a BSR after completing a resource selection procedure for the data in its buffers.

[0199]

[0203] In some circumstances, the WTRU may indicate a change in the preferred transmission mode configured by the network. In one example, the WTRU may transmit a BSR or related message after a change in the available / preferred transmission mode (e.g., mode 1 vs. mode 2) of the SLRB configured by the network (e.g., as described herein with respect to configuring the WTRU for mode selection).

[0200]

[0204] In one example, the WTRU may send a BSR to the network after changing the transmission mode (Mode 1 or Mode 2) of an SLRB (e.g., an SLRB is moved from Mode 1 to Mode 2). The WTRU may calculate new buffer states for all LCHs associated with Mode 1 after changing the mode of the SLRB and send a new BSR to the network. For example, the WTRU may detect a condition (e.g., Uu quality falling below a threshold) that triggers a change of an SLRB currently configured to use Mode 1 to use Mode 2. The WTRU may remove the SLRB from the logical channel associated with Mode 1 and move the SLRB to an SLRB for Mode 2. The WTRU may further inform the network of the change in buffer state resulting from the change. In another example, the WTRU may detect a condition (e.g., SL RLM).

[0201]

[0205] In one example, the WTRU may include BSRs for all LCGs in such a BSR, or in another example, the WTRU may include only LCGs whose buffer state has changed due to a change in mode for a given SLRB.

[0202]

[0206] In one example, the WTRU may start a timer after triggering a condition that requires a change of mode for a particular SLRB, and if the condition persists for the duration of the timer, the WTRU may send a mode change message to the network as in other scenarios described herein.

[0203]

[0207] In another example, the WTRU may send a BSR and / or associated messages (e.g., RRC messages such as MAC CE, SidelinkUEInformation, etc.) to the network to inform the network of a change in preferred mode for a particular SLRB. Such messages may include the SLRB or LCH for which a mode change trigger was determined in the WTRU, the specific condition that triggered the condition (e.g., in the form of an index into a list of configured conditions), QoS characteristics (e.g., PQI, QFI, etc.) of the SLRB and / or flows mapped to the SLRB, and / or measurements related to the condition, such as Uu quality, SL quality, etc., as described herein with respect to the WTRU's configuration for mode selection.

[0204]

[0208] In such an example, after sending a message to the network, the WTRU may do one or a combination of the following: the WTRU may initiate a mode change for the particular SLRB immediately after successful transmission of the instruction to the network; the WTRU may stop transmissions related to the SLRB until reconfiguration by the network; and / or the WTRU may start a timer. If the conditions for the mode change persist and the timer expires, the WTRU may initiate the mode change. Upon initiating the mode change, the WTRU may transmit a BSR with updated buffer status for all Mode 1 LCGs as described herein. If the conditions for the mode change do not persist for the duration of the timer, the WTRU may cancel the timer and inform the network.

[0205]

[0209] 3 illustrates an example of data processing when conditions change, where the situations described above with respect to the SR / BSR procedure may be applicable. Referring to section 311, here the WTRU decides to change LCH1 from mode 1 to mode 2, which may result in the need to send a BSR to the network, since the network no longer needs to consider the buffer state of LCH1, as LCH1 is moving to mode 2 where the WTRU is responsible for scheduling autonomously. Note that due to the remapping of LCH1 to mode 2, the buffer state shown in section 311 is fuller for T1 than for T2.

[0206]

[0210] In some circumstances, the WTRU may remap the LCG after a traffic switch, which may be applicable to any of the modeling discussed herein. After switching data from one transmission type to another, or after any of the conditions described herein change, the WTRU may change the mapping of QoS to LCG used to report the BSR. In particular, the WTRU may be configured with one mapping of QoS parameters (e.g., VQI, PPPP, priority, delay, etc.) to LCG and may indicate a preferred or alternative mapping to the network after a change in conditions as described herein. Alternatively, the WTRU may be configured with multiple mappings of QoS to LCG and may indicate a new mapping to the network (e.g., by an index to the new mapping) when conditions change. If conditions result in a change in transmission type for one or more QoS types (e.g., VQI range or set) and / or a change in transmission type for one or more logical channels or LCGs, the WTRU may further indicate such an alternative mapping or change in mapping.

[0207]

[0211] The WTRU may indicate the change in LCG remapping using an RRC message (e.g., UEAssistanceInformation or SidelinkUEInformation), a MAC CE, or a physical channel (e.g., SR or PUCCH). For example, the WTRU may include the QoS to LCG mapping with each report of the BSR.

[0208]

[0212] The WTRU may perform such LCG remapping after initiating a new transmission type, for example, the WTRU may initiate a unicast link and may perform LCG remapping for broadcast traffic so that it can reserve one of the LCGs for reporting buffer status related to the unicast traffic.

[0209]

[0213] In some situations, the WTRU may report buffer status for unicast separately from broadcast traffic. Specifically, the WTRU may report BSRs for different cast types using one of the following: pre-defining or (pre-)configuring one or more LCGs for different cast types; using different BSR formats (e.g., different MAC CEs) to report buffer status with different cast types; using separate buffer status fields in BSRs associated with logical channel groups to report the separate cast types; and / or using different destination indices to report the different cast types.

[0210]

[0214] In some cases, the WTRU may report a BSR for unicast / broadcast using a destination index from a list of dedicated destination indexes reserved for unicast. The WTRU may use a different dedicated destination index for each unicast / groupcast link (e.g., each distinct destination address) that is active at the WTRU. The WTRU can determine the list of dedicated destination indices for unicast / groupcast from: (pre-)configuration (e.g., system information, dedicated RRC signaling, pre-configuration), predetermined for all WTRUs, from another WTRU (e.g., head or scheduling WTRU), MAC CE or dynamic scheduling (e.g., DCI), in an HO command, while moving, implicitly based on the difference in address space between some bits configured for destination index and the number for broadcast destination addresses that the WTRU must actually reference (e.g., the WTRU can be configured with a list of destination addresses for broadcast services in a UE Sidelink Information message of length 32, which requires 5 bits, and a 6-bit wide destination index, and can use indexes 0-31 or 32-63 for unicast / groupcast destination indices).

[0211]

[0215] The WTRU may increment the destination index in the list of dedicated destination indices for each unicast / groupcast link that is established, or the WTRU may send a selected destination index to the network (e.g., upon link establishment) for each unicast / groupcast link that is established.

[0212]

[0216] If additional destination indices are needed for the unicast link, the WTRU may send an indication to the network, which may be sent by the RRC (e.g., UEAssistanceInformation) or the MAC CE.

[0213]

[0217] In some situations, the WTRU may report buffer status for the LTE RAT and the NR RAT separately. In particular, the WTRU may report buffer status for data transmitted on different sidelink RATs (e.g., LTE vs. NR) separately. The WTRU may report BSRs for different cast types using either different BSR formats, different LCGs in the same BSR message, and / or different destination indices in the same BSR message.

[0214]

[0218] Regarding different BSR types, in one example, the WTRU may transmit MAC CEs for different LTE and NR BSRs. This case, in particular, may assume a model in which the same LCG can be specified for both LTE and NR. The WTRU may be configured with separate mappings of QoS to LCGs by RRC; for example, in LTE, the WTRU may be configured with a mapping between PPPP and LCG, and in NR, the WTRU may be configured with a mapping between VQI and LCG.

[0215]

[0219] Regarding different LCGs in the same BSR message, this case may assume a model where an LCG can be assigned to either LTE or NR, but not both. If the WTRU has / does not have data available for a certain RAT, it can follow the LCG remapping procedure described herein.

[0216]

[0220] With respect to different destination indices in the same BSR message, this case may assume a model where the same LCG can be specified for both LTE and NR. The WTRU may be configured with separate mappings of QoS to LCG by RRC, e.g., in LTE, the WTRU may be configured with a mapping between PPPP and LCG, and in NR, the WTRU may be configured with a mapping between VQI and LCG.

[0217]

[0221] In some cases, the WTRU may determine a buffer status per RAT for flexible data. This may be applicable to a second modeling in which the WTRU can move a logical channel from one transmission type to another, and to a third modeling in which a logical channel may be associated with multiple transmission modes. In particular, the WTRU may calculate the buffer status per RAT based on an estimated amount of data routed on each RAT determined from one or more conditions defined herein. Such buffer status calculation may be based on the state of the conditions at the time of calculating the BSR. If one of the conditions changes and / or the amount of data that can be moved from one RAT to another exceeds a threshold, the WTRU may trigger a new BSR.

[0218]

[0222] For example, the WTRU may be configured with the percentage of traffic to be transmitted over each LTE and NR for traffic from higher layer indication that can be transmitted over both RATs. This percentage may be determined based on the CBR of the Mode 2 / Mode 4 pool in each of the RATs. At the moment when a BSR should be transmitted (e.g., based on any BSR trigger), the WTRU may calculate the CBR over LTE and NR and the corresponding percentage of data to transmit over each RAT, determine the data in the WTRU's buffer that is configured (e.g., by higher layers) to transmit only over a single RAT, the data that can be transmitted over both RATs, and the total amount of data to transmit over each RAT based on the calculated percentages above, and / or calculate the buffer status for each RAT based on the above.

[0219]

[0223] In some cases, there may be prioritization rules between LTE SL BSRs and NR SL BSRs. In particular, with respect to transmissions of different BSR types for different RATs, the WTRU may prioritize between LTE BSR and NR BSR transmissions in an UL grant based on either the QoS of the data sent in the BSR (e.g., the WTRU may prioritize BSR, LTE, or NR transmissions that require reporting of high priority data, or the WTRU may prioritize BSRs associated with the RAT for which the WTRU has the highest priority logical channel, or QoS-based prioritization may use the inter-RAT prioritization rules discussed herein), the size of the BSR (e.g., the WTRU may prioritize BSR, LTE, or NR transmissions that have the smallest overall size, or may avoid transmission of a shortened BSR due to the current uplink grant), and / or the RAT associated with the BSR (e.g., the WTRU may prioritize LTE RAT or NR RAT transmissions).

[0220]

[0224] The WTRU may further be configured by the network to follow certain rules regarding the above, for example, the WTRU may be configured by the network with an RAT that prioritizes transmission of BSRs (e.g., prioritizes LTE BSRs over NR BSRs).

[0221]

[0225] If a particular rule does not produce results, the WTRU may use a combination of the above rules or may use multiple rules, for example, the WTRU may use the QoS of the data being sent, and if both RATs have pending data of equal priority, the WTRU may use the size of the BSR.

[0222]

[0226] In some cases, the WTRU can determine the destination index for the LTE SL and the NR SL. This case may arise when the destination address may be common between the two RATs (e.g., multi-RAT support for the same service), and therefore a method for distinguishing the buffer status of the service on LTE and NR may be required.

[0223]

[0227] In one example, the WTRU may associate an explicit bit (e.g., a RAT indicator bit) in the destination index in the BSR with the RAT. In particular, the complete destination index may consist of a 1-bit RAT indicator and an x-bit destination index, which may be derived from the index of the destination address in the list of destination addresses in the UE Sidelink Information message (e.g., as in LTE).

[0224]

[0228] In another example, the WTRU may associate a destination index for a particular broadcast service on a RAT with one of the indices (e.g., the first index) for that service in a carrier / service list in the UE Sidelink Information associated with a carrier for that RAT. Among other things, the WTRU may be configured with a list of carriers and a RAT association for each carrier. In addition, the WTRU may be configured with a list of services / destination addresses of interest and the carrier that supports each service / destination address. The WTRU may associate a destination index for a service on LTE to be the first LTE carrier in that service list, and a destination for a service on NR to be the first NR carrier on that service list.

[0225]

[0229] In another example, when a WTRU determines that a service can be supported by LTE or NR, the WTRU can associate two related destination indices with the respective RATs, LTE and NR. The relationship between the destination indices can be either using consecutive destination indices and / or using destination indices separated by several destination indices in the address space of the destination indices, and the separation can be based on several total supported destination indices for the WTRU or a (pre-)configured value. For example, the WTRU can determine the services / destination addresses supported by the WTRU on different RATs. Such a determination can also be made by associating the carrier frequency associated with the service / destination address with the RAT associated with that carrier frequency. The WTRU can assign a single destination index to each service on a given RAT, regardless of the number of carriers supported for that RAT, by incrementing based on the order of the service / destination addresses reported to the network in the UE Sidelink Information. For services that the WTRU supports over multiple RATs, the WTRU may specify two consecutive destination indices, where the first index is associated with one RAT (e.g., LTE) and the second index is associated with the other RAT (e.g., NR).

[0226]

[0230] In some cases, when performing LTE SL and NR SL, the WTRU may determine the shortened BSR. This case may involve, among other things, reporting LTE and NR buffer status within the same BSR, and the WTRU may determine the contents of the shortened BSR using one or more of the following: the WTRU may prioritize transmission of buffer status of one RAT, possibly predetermined or (pre-)configured, over another RAT; the WTRU may prioritize transmission of buffer status associated with the highest priority LCG (e.g., assuming separate LCGs are specified for different RATs); the WTRU may prioritize transmission of buffer status associated with the highest priority LCG, and possibly predetermined or (pre-)configured, over another RAT for the same LCG of a different RAT; or the WTRU may prioritize the RAT that has data in its buffer with the highest priority between the two RATs (e.g., the WTRU may use any of the rules defined herein for such prioritization).

[0227]

[0231] As previously mentioned, the WTRU may perform resource selection / reselection based on conditions and / or as part of the data packet handling process (eg, type of transmission).

[0228]

[0232] In some situations, retransmission resource selection for unicast transmissions may occur only after the WTRU receives a NACK from a peer WTRU. In general, a WTRU may be configured with different resource selection processes for unicast / groupcast transmissions and broadcast transmissions. The WTRU may further be configured with different resource selection procedures for unicast / groupcast resource selection and broadcast resource selection. The WTRU may select retransmission resources using modified parameters for resource selection, including, but not limited to, a shorter T value defining the resource selection window, a different threshold for determining whether a resource is available / unavailable based on the detection procedure, a different value for the LBT back-off timer or a channel occupancy threshold associated with LBT detection, different conditions (e.g., number of available resources) under which the WTRU may transmit a preemption indication, a different priority compared to the actual PPPP / VQI of the packet compared to the initial transmission, a different number of channels / RBs, where the retransmission resources may use some channels / RBs that are a (pre-)configured function of the amount of resources for the initial transmission, a different number of channels / RBs (e.g., the WTRU may provide additional redundancy in the retransmission resources by further coding or by transmitting a different RV).

[0229]

[0233] Such modified parameters for resource selection for retransmission resources may reduce delays associated with the retransmission resources and / or increase the reliability of the retransmission resources.

[0230]

[0234] In some situations, the WTRU may use unnecessary retransmission resources for a transmission of another sidelink process. In particular, the WTRU may simultaneously select both transmission and retransmission resources for unicast transmissions. If the WTRU does not need one of the retransmission resources due to the lack of an ACK or NACK associated with the initial transmission, the WTRU may use that retransmission resource for an initial transmission by another sidelink process (e.g., unicast or broadcast). The WTRU may select a sidelink process that utilizes unused retransmission resources based on one or a combination of the following criteria: sidelink processes that perform resource (re)selection for a possibly one-off transmission when unused retransmission resources are available; sidelink processes whose retransmission resources meet the timing requirements of the process's initial transmission; and / or sidelink processes that require the same number of retransmission resources as are available due to the number of unused or retransmission resources.

[0231]

[0235] In some situations, the WTRU may use a one-shot resource selection procedure to select retransmission resources. In particular, the WTRU may use the one-shot resource selection procedure to select retransmission resources for a forward booking (e.g., periodic) unicast process. The WTRU may trigger such a one-shot resource selection procedure after receiving a NACK received from lower layers for the unicast process. Alternatively, the WTRU may select retransmission resources from unused retransmission resources as in the previous solution upon receiving a NACK from lower layers. Alternatively, the WTRU may decide not to trigger resource selection for retransmission resources if there is another unicast process (e.g., associated with the same destination ID) that meets the timing requirements of the retransmission.

[0232]

[0236] In some circumstances, the WTRU may use band-specific CQI during resource selection for unicast. In particular, the WTRU may utilize sidelink CQI results associated with the unicast link in the resource selection procedure.

[0233]

[0237] In one example, the WTRU may exclude resources with sidelink CQI below a threshold from the resource selection algorithm. In particular, the WTRU may exclude resources based on the detection results and then further exclude resources with CQI below a threshold. The WTRU may then perform random resource selection for the remaining non-excluded resources.

[0234]

[0238] In another example, the WTRU may select the resource with the best CQI from the available resources. In particular, the WTRU may exclude resources based on the detection results. If the number of available resources is above a threshold, the WTRU may select the resource with the best / highest SL CQI from the available resources that meets the data requirements.

[0235]

[0239] In another example, the WTRU may select a resource pool or resource pattern for transmission that has the best average CQI over the resource pool or resource pattern.

[0236]

[0240] In some situations, the WTRU may determine successful resource allocation based on the reliability of the transmitted data. This may be applicable to both unicast and broadcast resource selection, and the WTRU may determine the criteria necessary for successful resource selection based on the reliability requirements associated with the transmitted data. For example, the WTRU may consider resource selection successful if detection determines that a certain percentage (x%) of resources are available that meet the timing requirements of the transmission. The WTRU may be configured to use different values ​​of x% depending on the reliability requirements of the WTRU.

[0237]

[0241] The WTRU may further determine failure cases of the resource selection algorithm based on reliability requirements. For example, the WTRU may perform multiple attempts of resource selection by increasing a threshold associated with determining resource occupancy based on sensing results (e.g., as in LTE). Depending on reliability, the WTRU may indicate a failed resource selection algorithm after several such attempts, which may depend on the reliability requirements of the transmitted data.

[0238]

[0242] As discussed herein, unsuccessful resource allocation may trigger a change in the type of transmission. Unsuccessful resource allocation may also trigger preemption or an increase in the number of retransmissions by the WTRU.

[0239]

[0243] In some situations, a WTRU may use different carrier selection rules for unicast transmissions. In particular, a WTRU may be configured with different rules for carrier selection related to unicast transmissions as compared to broadcast transmissions. The motivation behind such rules may be due to a limited number of carriers that can be supported between two WTRUs in unicast (e.g., due to capabilities).

[0240]

[0244] The WTRU may be configured to make carrier selection for unicast differently from broadcast by either configuring the WTRU with a different CBR threshold for carrier selection related to unicast compared to broadcast, configuring the WTRU with a different carrier keep threshold for carrier selection related to unicast compared to broadcast, possibly configuring the WTRU to ignore the CBR threshold for carrier selection for unicast (e.g., always use any carrier) even if the number of supported carriers for unicast transmission between the two WTRUs is below a threshold, and / or configuring the WTRU with a different number of allowable sidelink processes depending on the carrier, where the WTRU may be granted a larger number of sidelink processes on carriers that are candidate carriers for transmitting unicast data. Alternatively, perhaps under certain criteria (e.g., the number of carriers for unicast is below a threshold, or the CBR on a particular carrier is above / below a threshold), the WTRU may be allowed to have only unicast processes on a carrier where the WTRU is configured with both unicast and broadcast services.

[0241]

[0245] In some situations, the WTRU may trigger carrier / resource reselection when there is a change in conditions for determining the type of data packet transmission. For example, the WTRU may trigger resource reselection after a decision to move certain logical channels or certain QoS types from Mode 2 to Mode 1. Additionally / alternatively, the WTRU may trigger resource reselection after a decision to move certain logical channels or certain QoS types from Mode 1 to Mode 2 due to network coverage limitations / conditions. Such resource reselection may be performed by the WTRU to replace NW configuration resources (e.g., SPS resources) with Mode 2 resources.

[0242]

[0246] The situations described herein with respect to the carrier / resource (re)selection procedure may be applicable to Figure 3, which shows an example of data processing when conditions change. See section 313, where a carrier / resource reselection may have to occur as a result of the WTRU deciding to change LCH1 from Mode 1 to Mode 2, and since the WTRU is no longer receiving scheduling information for LCH1, the WTRU must address the resources required for LCH1 within its own Mode 2 resources. Note the blocks representing the added Mode 2 resources now required for LCH1, which have been added at T2 compared to T1.

[0243]

[0247] In some circumstances, the WTRU may use the amount of Mode 1 resources in a Mode 2 resource selection procedure. In particular, the WTRU may determine the amount of resources (e.g., periodicity, size, number of single processes, etc.) to select during resource selection / reselection based on either a NW indication of available NW resources and / or the QoS of the data to be transmitted. With respect to the NW indication of NW available resources, in one example, the NW may enable / disable and the WTRU may perform resource reselection by adding / removing SPS resources and the amount of resources determined by the SPS. In another example, the NW may indicate a change in the amount / percentage of Mode 1 resources it provides, and the WTRU may determine the amount of additional Mode 2 resources to select based on such indication.

[0244]

[0248] In some situations, the WTRU may decide whether to use Mode 1 or Mode 2 on a carrier based on the CBR. In particular, the WTRU may perform carrier selection for the sidelink process. If the number of carriers selected by the process is below a threshold (e.g., due to a CBR threshold on that carrier), the WTRU may decide to use Mode 1 on other carriers that do not meet the CBR threshold.

[0245]

[0249] In another approach, the WTRU may make resource selection based on QoS and / or CBR up to a maximum number of resources on a carrier. If the WTRU needs additional resources to meet its current buffer requirements, it may request Mode 1 resources to meet the remaining resource requirements on that carrier.

[0246]

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

Claims

1. 1. A method implemented by a first wireless transmit / receive unit (WTRU), comprising: Detecting a condition related to a first transmission mode of a side link radio bearer (SLRB), the first transmission mode being configured by a mobile network (MN) and associated with a first logical channel (LCH); triggering a change of the SLRB from the first transmission mode to a second transmission mode in response to detecting the condition; notifying the MN of the change of the SLRB to the second transmission mode; transmitting data associated with the SLRB according to the second transmission mode; A method comprising:

2. The method of claim 1 , wherein the condition relates to at least one of a quality of service (QoS) of the data, a size of the data, or a periodicity of the data.

3. The method of claim 1 , wherein the condition relates to a coverage condition of the first WTRU while transmitting data associated with the SLRB.

4. 2. The method of claim 1, wherein the conditions relate to a first coverage condition of the first WTRU associated with the SLRB and a second coverage condition of the second WTRU associated with the SLRB indicated in a message received by the first WTRU from a second WTRU.

5. The method of claim 1 , wherein the condition relates to a load or an estimated transmission quality associated with one or more of the first transmission mode or the second transmission mode.

6. 2. The method of claim 1 , wherein triggering the change in response to detecting the condition comprises triggering the change in response to detecting a value associated with the condition rising above or falling below a threshold.

7. 2. The method of claim 1, wherein triggering the change of the SLRB from the first transmission mode to the second transmission mode includes triggering a change in association of the first LCH from the first transmission mode to the second transmission mode.

8. 2. The method of claim 1, wherein triggering the change of the SLRB from the first transmission mode to the second transmission mode includes triggering a change of the SLRB to a second LCH associated with the second transmission mode.

9. 2. The method of claim 1, wherein notifying the MN of the change of the SLRB to the second transmission mode comprises sending a Buffer Status Report (BSR) to the MN.

10. The method of claim 1 , wherein notifying the MN of the change of the SLRB to the second transmission mode comprises sending a message to the MN.

11. The method of claim 1 , wherein transmitting data associated with the SLRB includes transmitting the data to a second WTRU according to the second transmission mode.

12. a first wireless transmit / receive unit (WTRU), Detecting a condition related to a first transmission mode of a side link radio bearer (SLRB), the first transmission mode being configured by a mobile network (MN) and associated with a first logical channel (LCH); triggering a change of the SLRB from the first transmission mode to a second transmission mode in response to detecting the condition; notifying the MN of the change of the SLRB to the second transmission mode; transmitting data associated with the SLRB according to the second transmission mode; a first WTRU configured to:

13. The first WTRU of claim 12 , wherein the condition relates to one or more of a quality of service (QoS) of the data, a size of the data, or a periodicity of the data.

14. The first WTRU of claim 12, wherein the conditions relate to a first coverage condition of the first WTRU associated with the SLRB and a second coverage condition of the second WTRU associated with the SLRB indicated in a message configured to be received by the first WTRU from the second WTRU.

15. The first WTRU of claim 12 , wherein the condition relates to one or more of a load or an estimated transmission quality associated with one or more of the first transmission mode or the second transmission mode.

16. The first WTRU of claim 12 , configured to trigger the change by triggering the change in response to detecting a value associated with the condition being above or below a threshold.

17. The first WTRU of claim 12 , configured to trigger a change of association of the first LCH to the second transmission mode in response to detecting the condition.

18. The first WTRU of claim 12 , configured to trigger the change of the SLRB to a second LCH associated with the second transmission mode in response to detecting the condition.

19. The first WTRU of claim 12 , configured to notify the MN of the change of the SLRB to the second transmission mode by sending a buffer status report (BSR) to the MN.

20. The first WTRU of claim 12 , configured to transmit data associated with the SLRB by transmitting the data to a second WTRU according to the second transmission mode.

Images