Wireless transmit / receive unit and method for performing same

Abstract

Systems, methods, and devices for enabling simultaneous transmissions of different types of transport protocols, such as a wireless transmit / receive unit and a method performed by the same. A device, such as a wireless transmit receive unit (WTRU), may receive configuration information and receive data packets from an upper layer of a protocol stack operating on the WTRU. The WTRU may then determine a transmission type of the data packet at the first time based on the configuration information and the condition. The WTRU may then transmit the data packet using the determined transmission type. The configuration information may include decision criteria associated with determining the transmission type and a logical channel set associated with the data attribute. The transmission type may be one of a network scheduling mode, a WTRU autonomous scheduling mode, LTE, NR, unicast, multicast, or broadcast.

Description

[0001] This application is a divisional application of the invention patent application with the application date of December 19, 2019, application number: 201980085476.0, and invention name: "Process for realizing simultaneous transmission of different types".

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0004] As wireless capabilities advance, there can be interconnected systems that join multiple use cases to further enhance the transmission and sharing of information. For example, Vehicle-to-Everything (V2X) can be used to wirelessly connect devices involved in transportation and the environment around the transportation infrastructure. As these systems evolve, so must the protocols and processes for wireless device interactions. Summary of the invention

[0005] Systems, methods and devices for implementing simultaneous transmission of different types of transmission protocols. A device such as a wireless transmit receive unit (WTRU) may receive configuration information and receive a data packet from an upper layer of a protocol stack operating on the WTRU. The WTRU may then determine a transmission type of the data packet at a first time based on the configuration information and a condition. The WTRU may then transmit the data packet using the determined transmission type. The configuration information may include a decision criterion associated with determining the transmission type and a set of logical channels associated with data attributes. The transmission type may be one of a network scheduled mode, a WTRU autonomous scheduled mode, LTE, NR, unicast, multicast, or broadcast. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] In addition, like reference numerals in the drawings represent like elements, wherein:

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

[0008] Figure 1B is a diagram showing that according to an embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system as shown in;

[0009] Figure 1C is a diagram showing that according to an embodiment, Figure 1AA system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system as shown in;

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

[0011] Figure 2 is a flow chart illustrating an example process for data packet processing for transmission;

[0012] Figure 3 is a diagram showing an example process of data packet processing when conditions change; and

[0013] Figure 4 is a flow chart illustrating an example process associated with buffer status reporting and scheduling request communications. DETAILED DESCRIPTION

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

[0015] like Figure 1AAs shown, the communication 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, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 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), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

[0017] 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), a relay node, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, in one embodiment, the base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

[0019] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. 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).

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

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

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

[0023] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio 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), etc.

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

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

[0026] 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 that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may use the same RAT as the RAN 104 or a different RAT.

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

[0028] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 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 appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

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

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

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

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

[0033] The processor 118 of the WTRU 102 may be connected to and may receive user input data from a speaker / microphone 124, a keyboard 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 keyboard 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

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

[0036] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connections. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, 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 sensor 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.

[0037] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (eg, signals associated with particular subframes for both UL (eg, for transmission) and DL (eg, for reception)) may be concurrent and / or simultaneous.

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

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

[0040] 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, user scheduling in the UL and / or DL, etc. Figure 1CAs shown in FIG. , the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0041] Figure 1C The CN 106 shown in FIG. 1 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the foregoing elements are depicted 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.

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

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

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

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

[0046] Although the WTRU Figures 1A-1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may use (eg, temporarily or permanently) a wired communications interface with a communications network.

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

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

[0049] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP can send beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a 20MHz wide bandwidth) or a dynamically set width. The primary channel can be an operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs (e.g., each STA), including the AP, can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

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

[0051] Very high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining adjacent 20MHz channels. A 160MHz channel can be formed by combining 8 consecutive 20MHz channels or by combining two non-contiguous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing, respectively. The stream can be mapped onto two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the above 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0052] The operating mode below 1 GHz is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to the channel operating bandwidth and carrier used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, for example, including limited capabilities for support (e.g., only support) for certain and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0053] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. 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 set and / or limited by the STA among all STAs operating in the BSS, which supports the minimum bandwidth operating mode. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (which only supports the 1MHz operating mode) transmits to the AP, all available bands can be considered busy even if most of the available bands remain idle.

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

[0055] Figure 1D1 is a system diagram showing the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0056] RAN104 may include gNB180a, 180b, 180c, but it should be understood that RAN104 may include any number of gNBs while remaining consistent with the embodiment. Each of gNB180a, 180b, 180c includes one or more transceivers for communicating with WTRU102a, 102b, 102c via the air interface 116. In one embodiment, gNB180a, 180b, 180c may implement MIMO technology. For example, gNB180a, 108b may utilize beamforming to transmit signals to and / or receive signals from gNB180a, 180b, 180c. Therefore, gNB180a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from WTRU102a. In an embodiment, gNB180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0057] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter configurations (numerology). For example, 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 various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or absolute times of varying lengths).

[0058] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing other RANs (e.g., eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNBs 180a, 180b, 180c while also communicating / connecting with another RAN such as an eNodeB 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 eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may serve 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.

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

[0060] Figure 1D The CN 106 shown in FIG. 1 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may include a data network (DN) 185a, 185b. Although the aforementioned elements are depicted 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.

[0061] AMF 182a, 182b may be connected to one or more of gNBs 180a, 180b, 180c in RAN 104 via an N2 interface and may be used as a control node. For example, AMF 182a, 182b may be responsible for authenticating users of WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting specific SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, and the like. AMF 182a, 182b may use network slicing to customize CN support for WTRU 102a, 102b, 102c based on the type of service used by WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182A, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A Pro and / or non-3GPP access technologies (eg, WiFi).

[0062] SMF183a, 183b can be connected to AMF182a, 182b in CN106 via N11 interface. SMF183a, 183b can also be connected to UPF184a, 184b in CN106 via N4 interface. SMF183a, 183b can select and control UPF184a, 184b, and configure the routing of services through UPF184a, 184b. SMF183a, 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy implementation and QoS, providing DL data notification, etc. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

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

[0064] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), or may communicate with an IP gateway that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to 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 DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0065] Given that Figures 1A-1D and Figures 1A-1D , one or more or all of the functions described herein with respect to one or more of the following items may be performed by one or more simulation devices (not shown): WTRU102a-d, base station 114a-b, eNodeB160a-c, MME162, SGW164, PGW166, gNB180a-c, AMF182a-b, UPF184a-b, SMF183a-b, DN185a-b, and / or any (one or more) other devices described herein. The simulation device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0067] One or more simulation devices may perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device may be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to enable testing of one or more components. One or more simulation devices may be test equipment. The simulation device may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuits (e.g., which may include one or more antennas).

[0068] [Start 14596 public]

[0069] Vehicular communication, also known as vehicle-to-everything (V2X), is a communication mode whereby 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, a vehicle may be associated with, integrated with, and referred to interchangeably with a WTRU. There may be two scenarios for V2X operation: an in-coverage scenario, where the WTRU receives assistance from the network to start transmitting and receiving V2X messages; and / or an out-of-coverage scenario, where the WTRU uses some pre-configured parameters to start transmitting and receiving V2X messages.

[0070] V2X communications may be related to work done with device-to-device (D2D) communications. V2X communication services may involve at least four different types of interactions: vehicle-to-vehicle (V2V), where vehicle WTRUs may communicate directly with each other; vehicle-to-infrastructure (V2I), where vehicle WTRUs may communicate with RSUs / eNBs; vehicle-to-network (V2N), where vehicle WTRUs may communicate with a core network; and vehicle-to-pedestrian (V2P), where vehicle WTRUs may communicate with pedestrian (e.g., non-vehicle) WTRUs that have special conditions (e.g., low battery capacity).

[0071] There are several modes of operation related to V2X resource allocation. In LTE, there may be at least two modes of operation in V2X communications. Mode 3 is where the network gives the WTRU a scheduling allocation for V2X sidelink transmissions. Mode 4 is where the WTRU autonomously selects resources from a configured / pre-configured resource pool. In addition to the modes, V2X LTE may include at least two types of resource pools: a receive pool that is monitored for receiving V2X transmissions and a V2X transmit pool that is used by the WTRU to select transmission resources in Mode 4. The transmit pool may not be used by a WTRU configured in Mode 3.

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

[0073] New Radio (NR) can be considered the "next generation" wireless system. NR systems can support a variety of use cases such as enhanced mobile broadband (eMBB) and ultra-reliable and / or low-latency communications (URLLC).

[0074] 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 require different performance requirements (e.g., 3ms latency may be required).

[0075] NR V2X can support new use cases such as vehicle platooning, advanced driving, extended sensors, remote driving, etc.

[0076] Vehicle platooning may enable vehicles to dynamically form groups that travel together. All vehicles in a platoon may receive periodic data from the lead vehicle in order to perform platooning operations. This information may allow the distance between vehicles to become extremely small (e.g., the gap distance converted to time may be very low, such as sub second). Platooning applications may allow following vehicles to be driven autonomously.

[0077] Advanced driving can achieve semi-autonomous or fully autonomous driving. For this use case, a long inter-vehicle distance can be assumed. Each vehicle and / or roadside unit (RSU) can share data obtained from its local sensors with nearby vehicles, allowing vehicles to coordinate their trajectories or maneuvers. In addition, each vehicle can share its driving intentions with nearby vehicles. Some benefits of this use case can be safer travel, collision avoidance, and / or improved traffic efficiency.

[0078] Extended sensors can 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. Vehicles can enhance their perception of their environment beyond what their own sensors can detect and have a more comprehensive view of the local situation.

[0079] Remote driving can enable remote drivers or V2X applications to operate remote vehicles for passengers who cannot drive their own vehicles, or to operate remote vehicles located in hazardous environments. For use cases with limited changes and predictable routes, such as public transportation, cloud-based or remote-operated driving can be implemented. In addition, for this use case, access to a cloud-based backend service platform can be considered.

[0080] Both LTE and NR can be radio access technologies (RATs) supporting eV2X. NR V2X can complement LTE V2X for advanced V2X services and support interworking with LTE V2X. Therefore, the WTRU may need to support both NR and LTE sidelink operations.

[0081] LTE V2X may support both NW scheduling mode (Mode 3) and WTRU autonomous mode (Mode 4). NR V2X may also support both NW scheduling mode (Mode 1) and WTRU autonomous mode (Mode 2). In addition, for V2X, there may also be sub-modes of Mode 2, such as: Mode 2a, where the WTRU autonomously selects sidelink resources for transmission; Mode 2c, where the WTRU is configured with an NR configured grant (similar to Type 1) for sidelink transmission; and / or Mode 2d, where the WTRU schedules sidelink transmissions of other WTRUs. Behavior similar to Mode 2b may also be an option for functionality that can be built into any other mode. For Mode 2b, the WTRU may assist other WTRUs in sidelink resource selection.

[0082] In some cases, LTE V2X may be used as a broadcast mechanism at the access stratum (AS) layer. The V2X WTRU may be provided with an L2 destination ID corresponding to the V2X service from upper layers. The WTRU may include the L2 destination ID in the MAC header and reception may filter MAC PDUs based on the WTRU having an L2 destination ID that matches the service of interest to the WTRU.

[0083] For NR V2X, there may be more stringent requirements coupled with use cases (e.g., platooning), which also motivates the use of unicast and multicast transmissions. With unicast and multicast transmissions, the WTRU can utilize feedback from the receiver (e.g., HARQ, CQI) to optimize transmit power, retransmissions, etc., allowing for more efficient use of resources and better control of QoS.

[0084] There may be a QoS model for NR V2X. QoS on PC5 may be supported with ProSe per-packet priority (PPPP). The application layer may be allowed to mark packets with PPPP, which indicates the required QoS level. Certain enhancements may be added, such as deriving the packet delay budget (PDB) from PPPP.

[0085] There may be additional features for QoS of NR. These additional features may have key performance indicators having 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).

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

[0087] Considering 5GS V2X-capable WTRU, there may be at least three different types of services: broadcast, multicast, and unicast.

[0088] For unicast type services, the same QoS model as for Uu can be used (e.g., each unicast link can be considered as a bearer and a QoS flow can be associated with it). All QoS characteristics defined in 5QI and additional parameters for data rate can also be applied. In addition, the minimum required communication range can be considered as an additional parameter specifically for PC5 use. Similar considerations can also be applied to multicast services, as it can be considered as a special case of unicast (e.g., with multiple defined service receivers). For broadcast services, there may be no bearer concept; therefore, each message may have different characteristics depending on the application requirements. The 5QI can then be used in a similar way to ProSe per-packet priority / ProSe per-packet reliability (PPPP / PPPR) (e.g., marked with each packet). The 5QI is able to represent all characteristics required for PC5 broadcast operation (e.g., latency, priority, reliability, etc.). A set of V2X broadcast specific 5QIs (e.g., voice quality index (VQI)) can be defined for use by PC5.

[0089] In one or more use cases, such as those discussed herein, the WTRU may need to perform simultaneous operations; the operations discussed herein may refer to one or more operations performed by the WTRU, such as transmitting, receiving, processing, determining, executing an operation mode, etc. These operations may include processing one or more transmission types, such as the WTRU processing simultaneous transmission types, depending on the environment. As discussed herein, the transmission type may refer to, but is not limited to: a transmission mode, such as a WTRU autonomous or NW scheduled mode (e.g., Mode 3, Mode 4 for LTE, or Mode 1, Mode 2 for NR), and / or a sub-mode of Mode 2 for NR (e.g., Mode 2a, Mode 2c, Mode 2d); a sidelink radio access technology (SL RAT), such as where the WTRU may transmit via the NR SL RAT or the LTE SL RAT; a cast type, such as where the NR V2X WTRU may transmit using unicast, multicast, or broadcast transmissions. Combinations of these transmission types (e.g., Mode 2 on the NR SL RAT and Mode 3 on the LTE SL RAT) may also be considered separate modes in themselves.

[0090] In one or more embodiments, it is possible to operate in Mode 1 and Mode 2 simultaneously. In LTE V2X, the WTRU may be configured with only Mode 3 or Mode 4 based on the NW decision. Specifically, if the system information contains the required V2X resource pool, the WTRU may perform Mode 4 resource selection in RRC_IDLE. Otherwise, the WTRU may be forced to initiate an RRC connection, and the NW may provide the pool and allow the WTRU to operate in Mode 4, or the WTRU may be provided with scheduling in Mode 3. If the WTRU operates in Mode 1 and Mode 2 simultaneously, the WTRU may use the NW grant or the grant from the resource selection to transmit buffered data. At the WTRU, a process may be required to determine which data should be sent on Mode 1 or Mode 2. The Mode 2 resource selection rules may need to consider the availability of NW resources, and the interaction with the network for Mode 1 (such as BSR reporting) may also need to consider the availability of Mode 2 resources at the WTRU. This article discusses methods for addressing simultaneous operation in Mode 1 and Mode 2.

[0091] In one or more embodiments, there may be simultaneous operation in LTE and NR Sidelink (SL). The WTRU may need to operate on both LTE and NR SL simultaneously. While some packets may be marked by upper layers as required for transmission on either LTE or NR (e.g., for reasons of backward compatibility or strict QoS requirements), other packets may be allowed on either RAT. For such packets, a process may be required at the WTRU to select the appropriate RAT that manages the load of each RAT and ensures that the packets are transmitted while adhering to their QoS. Methods for addressing simultaneous operation in LTE and NR SL are discussed herein.

[0092] In one or more embodiments, there may be simultaneous operation in unicast, multicast, and broadcast. The WTRU may receive packets associated with a unicast or multicast, link (e.g., packets intended for transmission to a unique WTRU) and packets associated with a broadcast transmission (e.g., packets associated with an L2 destination ID monitored by multiple WTRUs) from upper layers. Assuming that any one propagation type can operate using mode 1 or mode 2, both modes may need to be considered to perform resource allocation. Specifically, the NW may need to know the amount of data buffered for each propagation type in order to operate in mode 1. In addition, resource and carrier selection may allow a common set of resources for each propagation type to avoid resource separation. Methods for addressing simultaneous operation in unicast, multicast, and broadcast are discussed herein.

[0093] When dealing with embodiments that address simultaneous WTRU operations, one issue that may arise is how to select a transmission type for data in different environments. To address this issue, there may be more than one layer 2 structural model for simultaneous use of transmission types, as well as decision criteria and WTRU actions for transmission type selection.

[0094] When discussing various models in conjunction with simultaneous use of transport types, each model described herein is presented as an example, and it is intended that features from one model or example may be applicable to another model or other described situations. Numbers associated with models are used only to provide reference to a specific example and are not intended to provide any implication as to a preferred method.

[0095] Figure 2is a flow chart illustrating an example process of selecting a transmission type for data. Each model described herein may perform all or some of the processes shown in the figure. In general, for any model, the WTRU may first receive a configuration 201, which contains configuration information or settings that the WTRU may use to determine or decide the transmission type that is appropriate for a given situation. The configuration may come from the network via an appropriate device (e.g., a base station such as a gNB, eNB, etc.). As part of the normal operation of the WTRU, data may be received 202 from an upper layer (e.g., received at a lower level in a protocol layer stack operating on the WTRU), where the data may be one or more data packets for transmission. The WTRU may determine or decide the transmission type that is appropriate for the received data packet based on the received configuration information and other decision criteria 203. The determination / decision process may be further described herein. The WTRU may then transmit the data packet using the appropriate transmission type 204. At some point, the WTRU may change the transmission type 205 based on conditions (such as changes in conditions measured by the WTRU, conditions received from the network such as a new configuration, or conditions such as an event, etc.) and / or decision criteria. Figure 2 During the example process of , the WTRU may communicate with another (one or more) WTRUs (e.g., sidelink) and / or a network (e.g., a base station) and may transmit (one or more) scheduling requests (SRs) and / or (one or more) buffer status reports (BSRs) to further facilitate the process. In addition, the WTRU may perform a carrier / resource selection process based on conditions and / or simultaneous transmission types.

[0096] 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 multiple logical channels, each of which may be associated with different QoS requirements and / or different destination IDs. The mapping may be part of the configuration information received by the WTRU in 201. For example, the WTRU may create a logical channel for transmitting data on an LTE RAT, or it may create a logical channel for transmitting data on an NR RAT. In another example, the WTRU may create a logical channel for data transmission using mode 1, or it may create a logical channel for data transmission using mode 2. In another example, the WTRU may create a logical channel for unicast data transmission. The WTRU may create separate logical channels for unicast transmissions to different destination WTRUs.

[0097] In a first model, the WTRU may receive data packets for transmission from upper layers, as at 202. Based on the decision criteria described herein, the WTRU may decide to send the data packets to a logical channel associated with one transmission type or another transmission type, as at 203. In this case, the WTRU may make the decision when packets from upper layers arrive.

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

[0099] The WTRU may decide to create / remove a logical channel associated with a transport type based on any of the following: one of the decision criteria discussed herein is met and there are no logical channels for a transport type (e.g., creation of a logical channel), or the criteria are such that only a single transport type will be used to transmit all data (removal of a logical channel); there is a certain type of data (e.g., a specific QoS or VQI) for the logical channels associated with the transport type that can no longer be mapped to the transport type (e.g., removal of a logical channel); the WTRU does not receive packets mapped to a certain transport type as discussed herein for a (pre-)configured time period; and / or is notified / reconfigured by the network. This creation / removal of a logical channel may occur at 203 or 205, depending on the circumstances of the prompt change.

[0100] In a second model, the WTRU may move a logical channel from one transmission type to another transmission type. This model may be used in conjunction with the first model of fixing logical channels to transmission types. Here, the logical channel may be configured to be of one transmission type only for a given period of time, for example, at 205, the transmission type may be changed, or for example, at 203, the transmission type may be changed based on parameters associated with received data packets. The WTRU may decide to move a logical channel from one transmission type to another transmission type, for example, based on criteria discussed herein. In this model, the decision of which transmission mode to use for transmission of a particular data packet may be made when data from upper layers arrives (for example, when the arrival of new data forces the logical channel to change from one transmission type to another transmission type), or the decision may be made periodically based on current and future packets, or based on some events triggered at the WTRU and defined by the criteria discussed herein (for example, a measurement satisfies some criteria, etc.).

[0101] For example, in the case of Mode 1 / Mode 2, the WTRU may create or be configured with a set of logical channels that use only Mode 1 and logical channels that use 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 may change from one mode to another. The WTRU may be configured with a mapping of data (e.g., based on QoS) to logical channels. Additionally, the WTRU may decide to move one or more logical channels from transmission using one transmission type to another transmission type periodically or based on a trigger received from lower layers.

[0102] The WTRU may be configured to have a maximum number of logical channels that may be changed from one transmission type to another. The WTRU may also be configured to have intervals or periods during which a logical channel may change its transmission type. Specifically, the WTRU may perform a decision criterion evaluation (e.g., based on the criteria discussed herein) for each such "movable" logical channel only at defined periods. The WTRU may also use the information available at the last change interval in order to decide the transmission type of the logical channel.

[0103] The WTRU in this model may apply the decision criteria for logical channel transmission type switching defined herein only for the QoS / VQI mapped to the logical channel, rather than simply for the QoS / VQI of a specific data packet. Specifically, the WTRU may be configured to create a logical channel for each VQI or set of VQIs. The WTRU may apply the decision defined herein that depends on the data type or QoS by considering only the QoS / VQI mapped to the logical channel.

[0104] In a third model, a logical channel may be associated with multiple transmission modes. This model may be used in conjunction with the first modeling of fixing logical channels to transmission types. Here, a logical channel may be configured with multiple transmission modes. In this modeling, the WTRU may determine a specific transmission mode to use when transmitting data, such as at 204, and may not use it when receiving data from upper layers, in contrast.

[0105] For example, in the case of LTE and NR RAT, the WTRU may create or be configured with a set of logical channels sent over the LTE RAT and a set of logical channels set over the NR RAT, as at 201. The WTRU may also be configured to have or create one or more logical channels associated with both RATs. In such an example, the WTRU may receive packets from upper layers, as at 202, and send such packets to either the LTE RAT or NR RAT logical channels based on the decision criteria described herein. Additionally, the WTRU may decide to send certain packets to logical channels that are mapped to both LTE and NR RAT. The actual data to logical channel mapping may then be performed at the time of transmission, for example at 204.

[0106] Figure 3 is a diagram showing an example of data processing when conditions change. In this example, the WTRU may handle different transmission types, such as mode 1 and mode 2. The time level moves forward, where 301 time T1 and 302 time T2 are shown to distinguish two different time points. In the case of a universal transmission of the WTRU, the WTRU may be configured with a set of logical channels (e.g., LCH1-4). The WTRU may be instructed or may decide on its own to allocate logical channels for transmission types. In the middle portion 312, the 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 may be received from upper layers and allocated to logical channels based on decision criteria related to the transmission type. At some point in time at or between T1 and T2, some condition (e.g., a change in radio conditions) may prompt the WTRU to change the transmission type assigned to the logical channel, as shown at 312, where logical channel LCH1 is changed to mode 2 at T2. This figure may be further explained herein.

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

[0108]

[0109] These criteria are not intended to be an exhaustive list, but rather are generally indicative of the types and nature of criteria that may be used in determining the type of transmission selected in certain circumstances.

[0110] For criteria cases where the WTRU determines the transmission type of data to be transmitted based on the attributes 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 (e.g., Mode 1 versus Mode 2) for the packet based on a (pre-)configured mapping of QoS parameters associated with the data (e.g., VQI, PPPP, PPPR, latency, reliability, range, etc.) and the transmission mode.

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

[0112] In another example of this case, in addition to the measurement of the CBR associated with each RAT, the WTRU may also select a RAT for transmission based on the VQI associated with the RAT. Specifically, 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 CBR differences between RATs. The WTRU may prioritize NR RAT for certain transmissions for which the NR RAT may be customized unless the CBR is high or significantly higher than the LTE CBR. This prioritization may be built into the RAT selection based on a (pre-)configured VQI / CBR table at the WTRU.

[0113] For criteria cases where the WTRU determines the transmission type of data to be transmitted based on the frequency and / or size of the transmission(s). Specifically, the WTRU may determine the transmission type based on the transmission frequency (i.e., periodic or aperiodic, and the periodicity of the transmission) and / or the message size (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 in combination with possible other conditions (e.g., periodic transmissions with CBR above / below a threshold). Similarly, if the average / minimum / maximum message size (e.g., for SLRBs) is above a threshold, the WTRU may be configured to use Mode 1.

[0114] For criteria cases where the WTRU determines the transmission type of the data to be transmitted based on the attributes of the side link session. In one instance, the WTRU may determine the transmission type based on the group size of the side link multicast. For example, for a group with a large number of members, the WTRU may be configured to use Mode 1 so that feedback resources from all receiver WTRUs may be allocated by the network. Similarly, the WTRU may be configured to use Mode 2 for side link multicast when the group size is small. Here, the transmitter WTRU may allocate feedback resources for each receiver WTRU. The HARQ feedback mechanism may also be used to determine the transmission type. For a HARQ NACK-only mechanism, the receiver WTRU may only share feedback resources for NACK messages. Therefore, the WTRU may be configured to use Mode 2 for side link multicast. If the HARQ ACK / NACK mechanism is used, the WTRU may be configured to use Mode 1 for side link multicast.

[0115] For criteria cases where the WTRU determines the transmission type of data based on the availability of sufficient resources for that transmission type, such determination 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, which may be associated with a particular RAT and / or a particular propagation type and have acceptable timing / latency with respect to the arrival of data; available uplink resources with acceptable timing / latency for transmitting a BSR (e.g., to indicate the arrival of data); available periodic resources with acceptable timing / latency for transmitting data; source, which may be associated with specific requirements or a specific logical channel; WTRU detection of a change in periodicity, offset, packet size of some data (for example, when the WTRU detects a change in periodicity, offset, or packet size of some data, the WTRU may change to Mode 2 transmission for a certain time); a specific type of available SL authorization, which may be combined with QoS requirements associated with the data; the amount of resources configured by the network for either transmission type (for example, the WTRU determines the transmission type based on the amount of resources configured by the network for either transmission type, where such a decision may be performed to use an equal proportion of resources in either type); and / or an inability to select sufficient resources using Mode 2 resource selection, or a failure in Mode 2 resource selection.

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

[0117] Regarding the inability to select sufficient resources, the WTRU may decide to use Mode 1 for some data transmissions after a resource selection process that may fail due to any of the following reasons: failure to acquire Mode 2 resources with LBT after a period of time or after multiple attempts, for example due to one / multiple / all available resources selected for transmission failing LBT (e.g., occupied during clear channel assessment) or due to the number of failures or the number / amount of backoff times exceeding a threshold, which may be related to the required latency of the packet; the number of Mode 2 resources considered available for transmission, determined at resource selection or periodically, is lower than a (pre-)configured or defined threshold, where the determination of the availability of Mode 2 resources may include excluding resources pre-reserved by similar SCI transmissions, and / or measurements of RSRP / RSSI on PSSCH / PSCCH; the scheduled WTRU for Mode 2d is not available or is unreachable during a certain time period; and / or, one / multiple / all resource modes configured for the WTRU that may be used for the data to be transmitted are not available or do not meet the latency requirements of the data to be transmitted.

[0118] Further with respect to not being able to select sufficient resources, the WTRU may decide to use the NR RAT or the LTE RAT based on the number of resource allocations that may have been recently deemed successful on either RAT. Specifically, the WTRU may measure the number or ratio of resource selection processes on each RAT where x% of resources were determined to be available during resource selection and may select the RAT with the smallest number or ratio.

[0119]

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

[0120] Further with respect to not being able to select sufficient resources, if the WTRU performs carrier selection and the number of allowed / selected carriers is below a certain number, the WTRU may determine that there are insufficient resources for resource selection, where the number may be related to the bearer / stream / VQI of the data to be transmitted.

[0121] In one scenario related to determining the type of transmission based on resource availability, the WTRU may use Mode 2 when SR / BSR resources are not available or do not meet the timing requirements. The WTRU may use Mode 1 transmission as long as it is configured with available SR resources to meet the timing requirements of the data to be transmitted, or a grant for BSR transmission can be obtained in sufficient time to transmit the data. If the WTRU is not configured with sufficient SR resources, or if the latency determined by the WTRU to transmit the BSR and subsequent sidelink data is greater than the latency requirement of the data transmission itself, the WTRU may use Mode 2 resources (e.g., forward reserved resources or one-time resources). Upon determining that Mode 1 cannot be used for the above reasons, the WTRU may perform Mode 2 resource selection, or may prioritize the transmission of the data on an existing Mode 2 grant (e.g., a periodically occurring resource).

[0122] In one scenario regarding determining the type of transmission, based on the availability of resources, the WTRU may use the NR RAT when the SR / BSR resources for the LTE RAT are not available or do not meet the timing requirements. In the example where the WTRU is configured to use both Mode 3 LTE and Mode 1 NR, the WTRU may be configured with SR resources specific to each RAT. The WTRU may determine the sidelink RAT on which to transmit the packet based on the timing of the NR RATSR relative to the LTE RAT SR (possibly in conjunction with the configured rules). Specifically, the WTRU may be configured to transmit data that may be associated with a specific service, propagation, etc. on the LTE / NR RAT, as long as the SR configuration on the LTE / NR RAT allows the WTRU to transmit the packet within the required latency. If a packet arrives and the LTE / NRRAT SR is configured so that the latency of the packet is not considered, the WTRU may instead transmit the packet on the NR / LTE RAT. The WTRU may transmit an NR / LTE SR to the network to obtain the associated data and include the data in the data to be multiplexed on a future NR / LTE grant.

[0123] In one scenario regarding determining the transmission type based on resource availability, the WTRU may use Mode 1 when resource selection using Mode 2 does not meet the timing requirements. In an example, the WTRU may be configured to use Mode 2 resource selection for data associated with a particular bearer / stream or data associated with a particular VQI. The WTRU may also be configured to use Mode 1 for such bearer / stream / VQI if one or more (pre-)configured or defined resource selection attempts performed for the data of the bearer / stream / VQI cannot select resources that meet the QoS requirements (e.g., latency, reliability) of the data. For example, the resource selection may require a sensing process 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 that performs resource selection for a process in which X% of resources are not determined to be available may transmit data packets via Mode 1. Alternatively, the WTRU may maintain a count of the number of such failed resource selection attempts that may be associated with a particular bearer / stream / VQI and decide to transmit the bearer / stream / VQI via Mode 1 when the number of failed resource selection attempts in succession or within a configured time exceeds a certain amount.

[0124] Despite the bearer / flow / VQI being configured with Mode 2, the WTRU in the above scenario may continue to transmit the bearer / flow / VQI using Mode 1 for a period of time, which period of time may be determined by any of: a (pre-)configured timer; an indication of one or more successful resource selections for other bearers / flows / VQIs using Mode 2; and / or a measurement of a change in congestion on the Mode 2 pool to below a configured threshold.

[0125] In one scenario regarding determining the transmission type based on resource availability, the WTRU may select a transmission mode based on the Mode 2 resource pool size / configuration. In an example, the WTRU may select to use Mode 1 or Mode 2 to transmit a certain type of data based on the configuration of the Mode 2 resource pool. Specifically, if the time between the time slots configured for SL transmission in the Mode 2 resource pool is less than a threshold, the WTRU may use Mode 2 for transmissions associated with a specific VQI, whereby such a threshold may be further associated with the VQI or the latency requirement of the data to be transmitted. In another example, the WTRU may transmit data using Mode 1 or Mode 2 in such a manner that the amount of data or the data ratio using Mode 2 is proportional to the size of the pool configured by the network for Mode 2 transmission.

[0126] In a scenario regarding determining the type of transmission based on resource availability, the WTRU may change the transmission mode when a change in periodicity / offset / size or periodic data is detected. In an example, when the WTRU detects a change in the periodicity / timing / offset of its transmission, the WTRU may use Mode 2 to send some data. The WTRU may further decide to perform this mode switch when the WTRU is unable to send WTRU assistance information in time to adjust the SPS resources to meet the latency requirements of the data associated with the SPS configuration. The WTRU may use Mode 2 to send only a portion of the data mapped to the SPS configuration (for example, in the case of a size change). The WTRU may decide to send all or part of the data utilizing the SPS resources when a change in periodicity / timing / offset is detected. The WTRU may still send WTRU assistance information associated with the SPS configuration. The WTRU may resume use of Mode 1 SPS resources after a network reconfiguration of the SPS configuration so that it meets the new periodicity / offset / size requirements.

[0127] For criteria cases where the WTRU may determine the transmission type based on network decision(s), the network may indicate the transmission type to the WTRU explicitly or implicitly based on any of: RRC configuration; DCI; and / or MAC CE.

[0128] Regarding RRC configuration, in one example, the WTRU may be explicitly configured to use certain transmission types that may be associated with certain types of data; in another example, the WTRU may receive an SPS reconfiguration for an SPS procedure (e.g., a grant of type 1 or type 2 configuration). If the grant size associated with the reconfiguration is less than the requested grant size in the WTRU assistance information, the WTRU may transmit the remainder of the data using mode 2 (e.g., the difference between the requested grant size in the WTRU assistance information and the actual SPS grant size provided by the network).

[0129] Regarding DCI, in one example, the WTRU may receive an indication in the DCI that only a certain portion of the quantity reported in the BSR is to be processed by the network using Mode 1. The WTRU may then utilize Mode 2 to transmit the remaining data in its buffer for which it originally sent the buffer status in the BSR.

[0130] Regarding MAC CE, in one example, a WTRU may receive a MAC CE to indicate that a logical channel should change from using one transmission type to using another transmission type.

[0131] For criteria cases where the WTRU may determine the transmission type based on Uu coverage or Uu defined area, the determination may be based on the WTRU's Uu coverage, which may be related to the Uu coverage of other WTRUs. The WTRU's determination of Uu coverage may include one or more factors.

[0132] In one factor, it may be determined whether the WTRU is in coverage or out of coverage to perform V2X communications. Specifically, the WTRU may select a transmission type that may be used for some types of data based on whether the WTRU in question or other related WTRUs (e.g., the destination of a unicast / multicast link) is in coverage or out of coverage.

[0133] In another factor, the Uu quality of the WTRU may be considered, such as Uu RSRP. Specifically, the WTRU may select a transmission type that may be used for some types of data based on the measured Uu RSRP being above or below a threshold.

[0134] In another factor, the WTRU's system information validity region may be considered. Specifically, the WTRU may select a possible transmission type for some data based on whether the WTRU and a peer WTRU have the same / different system information validity region.

[0135] In one scenario regarding Uu coverage or defined areas, the WTRU may use Mode 1 for unicast as long as the WTRUs are served by the same gNB / SysInfoArea / PLMN. In an example, when the WTRUs involved in the unicast / multicast transmission are all within the coverage area, or within the coverage area of ​​the same gNB, same PLMN, same system information area or similar areas, the WTRU may be configured to use Mode 1 for unicast / multicast transmission. When any WTRU moves out of coverage, the WTRU may move the ongoing unicast transmission using Mode 1 to Mode 2.

[0136] 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 served gNB / PLMN / SysInfoArea and / or the serving gNB / PLMN / SysInfoArea. The transmission of this change indication may be broadcast by the WTRU, or may be transmitted using unicast / multicast transmission only to the WTRUs with which the WTRU is currently communicating in unicast / multicast. The transmission of this change indication may be transmitted on the PSCCH, SL-MIB, or PSSCH. The PSSCH transmission may be in the form of a MAC CE or SL-RRC message. The WTRU may include the newly served 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 include any Uu measurements of the gNB to which the WTRU is stationed / connected. The WTRU may also include measurements of neighbor gNBs in this indication.

[0137] The WTRU may communicate an indication of a change to the scheduler WTRU or head WTRU following a similar method as described above.

[0138] A WTRU receiving the indication may decide to change between Mode 1 and Mode 2 transmission based on its own Uu connection state and the information in the indication. Specifically, a first WTRU within the coverage of a gNB may decide to transmit to the second WTRU using Mode 1 in unicast when an indication is received from the second WTRU indicating that the second WTRU is also within the coverage of the same gNB. Alternatively, the first WTRU may change from transmitting Mode 1 unicast to Mode 2 unicast to the second WTRU if the first WTRU receives an indication 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 predefined gNB list.

[0139] In one scenario regarding Uu coverage or defined areas, the WTRU may use Mode 1 as long as the Uu RSRP is above a threshold. In an example, the WTRU may be configured to use Mode 1, perhaps for a certain type 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. Furthermore, the WTRU may be configured with different RSRP thresholds associated with different bearers / streams / VQIs, and when the Uu RSRP is above a threshold associated with a specific stream / bearer / VQI, the WTRU may choose to use Mode 1 for that stream / bearer / VQI. Additionally, such thresholds may also be speed dependent.

[0140] For criteria cases where the WTRU may determine the transmission type based on the service type, the WTRU may determine the transmission type to be used for the sidelink data based on the service type of the transmitted data. The WTRU may be (pre-)configured with a mapping of service type to transmission type, such as: an RRC mapping, or a mapping of a destination ID provided by upper layers to a transmission mode (e.g., Mode 1 or Mode 2); an RRC mapping, or a mapping of a destination ID provided by upper layers to a RAT (LTE RAT or NR RAT); based on the above mapping, the WTRU may select a transmission mode and / or RAT for transmitting packets on the sidelink. In addition, the above mapping may further depend on other factors as discussed herein. For example, the WTRU may be configured with a mapping of destination ID to transmission mode for each measured CBR range, and / or may have a mapping configured for different regions or geographic locations, and the WTRU may comply with such mapping under each CBR and / or geographic region.

[0141] For criteria cases where the WTRU may determine a transmission type for sidelink data based on measurements of sidelink load or quality and / or resource availability, such decision may further depend on comparison of such measurements of sidelink load or quality associated with other transmission types. The WTRU may select a transmission type based on lowest load / best quality, or the WTRU may select a transmission type as long as the load associated with the transmission type is below a certain threshold, or the quality of the transmission type is above a certain threshold.

[0142] The WTRU may make a transmission type decision based on any one or a combination of the following measurements: channel busy ratio (CBR) measurements for a pool, resource pattern, or BWP; the WTRU's own channel occupancy (CR), which may be associated with one or more pools, resource patterns, or BWPs; RSSI measurements of sidelink resources, which may be associated with one or more pools, resource patterns, or BWPs, or subsets thereof, which may correspond to resources selected by the WTRU for its own transmission; RSCP measurements of sidelink channels, such as PSSCH, feedback channels, synchronization signals, or reference signals, which may be sent by one or more associated WTRUs, such as a WTRU with which the WTRU is currently in a unicast / multicast link; an estimated number of WTRUs in the area; the number of configured carriers / BWPs / resource pools; and / or detection of received preemptive signals.

[0143] In one example, the WTRU may be configured to measure the CBR of the Mode 2 pool in the NR RAT and the Mode 4 pool in the LTE RAT. The WTRU may determine the RAT to use for transmitting some or all of its data based on such CBR measurements and may decide to transmit in the RAT with the lower CBR or may change the RAT of transmission when that RAT has a CBR below a CBR threshold measured on the other RAT. The WTRU may also be configured with rules to convert the LTE CBR to the NR CBR or vice versa so that they can be compared equally.

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

[0145] In another example, a first WTRU may be configured to measure the RSRP of a sidelink reference signal received from a second WTRU, wherein the first WTRU is configured to unicast to the second WTRU. For certain types of data, the first WTRU may be configured to transmit the data using a unicast transmission type only when the RS-RSRP is above a certain threshold. The first WTRU may also maintain separate logical channels associated with the transmission of data or services to the second WTRU - one using a unicast link (e.g., configured with a feedback channel, HARQ, etc.) and the other using an SL broadcast mechanism. When the RS-RSRP is above a certain threshold, the first WTRU may use a unicast link to send packets destined for specific other WTRUs and / or services. One advantage of this approach is that it limits a large number of HARQ retransmissions for eMBB type data, but still applies HARQ type transmissions to URLLC type data.

[0146] In another example, the WTRU may be configured to select a RAT for transmission that may be used for a particular service or type of transmission (e.g., associated with a particular QoS) based on the number of carriers available for transmission on either RAT. Specifically, the WTRU may select a RAT for a service or type of data based on the ability to use a greater number of carriers on one RAT than another RAT. The WTRU may determine the number of carriers it can use for the service or type of data on the RAT based on the carriers configured for transmission on the RAT for the service and / or the carrier capabilities of the WTRU on each RAT.

[0147] In another example, the WTRU may transmit some or all of its data using Mode 1 after receiving a preemption signal from another WTRU. Such a preemption signal may also indicate which data should be transmitted using Mode 1. The WTRU may continue to use Mode 1 transmission for the period of time that is (pre)configured or indicated in the preemption signal. The same examples and WTRU behaviors related to preemption may also be used for a change from NR RAT to LTE RAT, or for a change from unicast to broadcast.

[0148] Without loss of generality, the above methods related to these cases may be combined with other methods described herein. For example, the WTRU may select between Mode 1 transmission and Mode 2 transmission for specific data based on a comparison of Uu RSRP and a measurement of CBR on the Mode 2 side link pool. Specifically, when the Uu RSRP is below a certain threshold and the CBR of the Mode 2 transmission pool is below another certain threshold, the WTRU may select to use the Mode 2 transmission type. Alternatively, the WTRU may select to use the Mode 1 transmission type.

[0149] For criteria cases where the WTRU may determine the transmission type based on the Uu RRC state, possibly in combination with the state of the RRC timers, the WTRU may select the transmission type or change the transmission type based on any of the following: the WTRU transitions 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 a certain type of data when transitioning to RRC_CONNECTED, but may use broadcast transmission in RRC_IDLE and RRC_INACTIVE); the WTRU starts RRC related timers, such as but not limited to timers related to RLF, BFR, access barring, etc. For RRC related timers, in one example, when T310 starts (e.g., upon detection of a PHY layer problem with the PCell), the WTRU may change to Mode 2 transmission, and when T310 stops (e.g., due to receiving N311 consecutive synchronization indications from lower layers), the WTRU may re-initiate Mode 1 transmission. In another example related to RRC-related timers, the WTRU may change to broadcast transmission when T310 starts (e.g., upon detection of a PHY layer problem with the PCell), and may restart Mode 1 transmission when T310 stops (e.g., due to receipt of an N311 continuous synchronization indication from lower layers). In another example related to 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 prohibited). In another example related to RRC-related timers, the WTRU may use broadcast transmission to transmit unicast when beam failure occurs during unicast transmission.

[0150] For criteria cases where the WTRU may determine the transmission type based on WTRU dynamic characteristics, the WTRU may select the transmission type for some data based on any one or a combination of the following: measured WTRU speed; absolute WTRU position; relative WTRU position to another WTRU; relative WTRU speed to another WTRU; relative WTRU direction to another WTRU; and / or, detection of any speed / position / direction change by the WTRU (e.g., when a change is detected in any speed / position / direction, the WTRU temporarily uses a transmission type (e.g., based on a timer)).

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

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

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

[0154] For this case, the WTRU may perform periodic sidelink transmissions of its position, speed or direction. Such transmissions may be performed on the PSCCH, SL-MIB or PSSCH. The transmission of such information on the PSSCH may be performed in a MAC CE or in a SL-RRC message. A WTRU receiving this position / speed / direction transmission may use such information to determine the type of transmission based on (pre-)configured rules in addition to using its own dynamic characteristics (e.g., vehicle dynamic characteristics).

[0155] For criteria cases where the WTRU may determine the transmission type based on the users of another transmission type, such decision may be based on (pre-)configured restrictions, and such restrictions may be applied in conjunction with or in the context of any additional methods / conditions for type selection described herein. For example, the WTRU may be configured to use Mode 1 only when performing unicast transmissions associated with a particular QoS.

[0156] For criteria cases where the WTRU may determine the transmission type based on carrier / BWP / resource pool restrictions, the WTRU may be (pre)configured with a specific transmission type based on these 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 maximum measured CBR and may be configured to use mode 2 on other carriers. The number of carriers on which mode 1 is used (e.g., the carrier with the maximum CBR) may be further (pre)configured or configured depending on the WTRU capabilities or the number of carriers that can be used for a particular service (e.g., destination addresses). For example, the number of carriers on which mode 1 is used (e.g., corresponding to the maximum CBR) may be defined as a percentage of carriers configured for a particular destination address, and / or the number of carriers supported by the WTRU.

[0157] For criteria cases where the WTRU may determine the type of transmission based on the amount of traffic configured for each type, the traffic used for such decision may include the WTRU's own transmissions or other WTRU transmissions (e.g. based on SCI transmission detection). For example, the WTRU may select the RAT for transmissions so as to have an equal amount or a (pre-)configured ratio of LTE SL transmissions and NR SL transmissions.

[0158] For criteria situations where the WTRU may indicate an opportunity for a transmission type to the network, the WTRU may indicate to the network a change in transmission type for some or all data, both within the WTRU buffer and future data that may be received by the WTRU. The WTRU may also be configured with a threshold above which a change in transmission type may be indicated. The threshold may be based on one or more of: the amount of data in the WTRU buffer that will be moved from one transmission type to another; the number of VQIs or QoS levels that will be changed from one transmission type to another; the amount of changes in measurements (e.g., amount of available resources, RSSI, SCI RSCP) that may result in a change in transmission type for some data); and / or other values ​​or metrics that will determine a change in transmission type for certain data.

[0159] The WTRU may indicate a change in transmission type using one or more of the following: a dedicated SR or PUCCH; a RACH (e.g., a 2-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; a 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 associated with the change in transmission type during connection establishment).

[0160] For criteria cases where a WTRU may change transmission type based on receiving a mode change from another WTRU, a second WTRU may transmit an indication of a change in transmission type to a first WTRU or set of WTRUs. For example, a second WTRU may transmit an indication of a transmission mode (e.g., mode 1 to mode 2, or change to mode 1 / mode 2). When the second WTRU decides to change mode, it may send a mode change indication on the PSCCH, PSSCH, or SL-MIB. Such a mode change indication may take the form of a MAC CE or SL-RRC message transmitted on the PSSCH to a set of WTRUs that are unicast / multicast with the second WTRU. The first WTRU, upon receiving a mode change indication from the second WTRU, may decide to change its own transmission mode to match the transmission mode of (one or more) other WTRUs. Specifically, if the first WTRU receives a mode change from a second WTRU, where the first WTRU has an indication that the second WTRU will use a unicast link of mode 2, the first WTRU may change its transmission mode from mode 1 to a unicast link of mode 2 (e.g., all packets specific to the unicast link may be transmitted using mode 2).

[0161] In some cases, the WTRU may be configured for mode selection. In one example, the WTRU may be configured with an allowed, required, or preferred mode or transmission type (e.g., Mode 1 or Mode 2) for the SLRB. Specifically, the SLRB or LCH may be configured to use only Mode 1, or may be configured to use only Mode 2. In addition, the WTRU may be configured with conditions under which the SLRB should use Mode 1 or Mode 2. Such conditions may be based on one or more of the following: Uu quality; SL signal quality; amount of data in the WTRU buffer for the SLRB; resource / carrier / BWP; frequency / periodicity; and / or size of the transmission.

[0162] Regarding Uu quality, the WTRU may be configured with conditions related to whether the SLRB should use Mode 1 or Mode 2 for Uu quality. The Uu signal quality may be determined by any of: cell level measurements (i.e., RRM measurements) of the current cell or other cells; and / or 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 Mode 2 otherwise.

[0163] Regarding SL signal quality, the WTRU may be configured with conditions related to whether the SLRB should use Mode 1 or Mode 2 for SL quality. The SL signal quality may be determined based on: a measurement of congestion (e.g., CBR) of the transmission resource pool used by the WTRU; a measurement of the HARQ success rate on the peer link (e.g., number of NACKs over a time period, number of consecutive NACKs, number of lost ACK / NACKs); a measurement of channel quality on reference signals, such as CSI-RS, DMRS, etc.; a measurement reported from a peer WTRU, such as an SL CQI report; an allowable SL power (e.g., power headroom); a SL RLM / RLF state 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 availability of resources on the sidelink, such as the size of the configured resource pool, which may be within a certain time budget, a metric related to successful resource selection (i.e., resource selection can be performed to meet latency requirements). For example, the WTRU may be configured to use / prefer Mode 2 for SLRBs as long as the CBR is below a threshold, and to use Mode 1 otherwise. In another example, the WTRU may be configured to use / prefer Mode 2 for SLRBs associated with a unicast link as long as the unicast link does not trigger RLF or the RLF counter is not running.

[0164] Regarding the combination of Uu quality and SL quality, the WTRU may be configured to have a condition to prefer or use Mode 1 or Mode 2 based on the condition involving both Uu quality metric and SL quality metric. For example, such a condition may be based on CBR comparison and Uu cell measurement, the difference of such measurements.

[0165] With respect to the amount of data in the WTRU buffer for the SLRB, the WTRU may be configured with a condition to use one mode (mode 1 or mode 2) instead of another mode as long as the amount of data pending for the SLRB is below a threshold. Such a limit or threshold may also be related to the size of resources on the sidelink (e.g., the amount of resources used for transmission, HARQ feedback, or congestion measured on these resources).

[0166] There may be conditions based on the values ​​selected by the WTRU for transmission with respect to resources / carriers / BWP / or the like, and the conditions are determined by the restrictions on the transmission modes that can be used on each of these.

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

[0168] As previously mentioned, in the case of a WTRU with simultaneous operation, there may be one or more logical channels associated with the transmission type, however, in some cases, one logical channel may take precedence over another logical channel. The WTRU may be configured to have at least one separate logical channel prioritization (LCP) procedure per transmission type. Such a configuration may be applicable to different transmission types, such as: a WTRU operating in simultaneous Mode 1 and Mode 2 may perform a Mode 1-specific LCP procedure when the WTRU receives a grant from the network, and may perform a Mode 2-specific LCP procedure when a grant from resource selection becomes active; a WTRU operating in simultaneous LTE and NR transmission may perform an LTE-specific LCP when the WTRU processes a grant on an LTE carrier, and may perform an NR-specific LCP when the WTRU processes a grant on an NR carrier. A WTRU operating in unicast and multicast may perform a unicast-specific LCP when the WTRU decides or is instructed to use a grant for unicast, and the WTRU performs a broadcast-specific LCP when the WTRU decides or is instructed to use a grant for multicast.

[0169] The WTRU may use or be configured with different parameters or rules for the LCP associated with each transmission type, including, but not limited to: prioritized handling of logical channels (e.g., a grant associated with LTE may utilize PPPP as a logical channel selection criterion, while a grant associated with NR may utilize VQI or both priority and latency parameters derived from VQI); determining the amount of data to be considered in each logical channel (e.g., if a logical channel is associated with a PDB, a grant associated with LTE may process each logical channel until the data for that logical channel is exhausted, while a grant associated with NR may process each logical channel until the PDB associated with that logical channel is exhausted); and / or rules associated with RLC SDU segmentation (e.g., a grant associated with LTE processing may allow RLC segmentation, while a grant for NR may not allow RLC segmentation).

[0170] Alternatively, the WTRU may be configured to use completely separate procedures for LCP, where each procedure is associated with each transmission type, and / or where each procedure defines the rules and parameters differently (eg, according to the examples above).

[0171] A WTRU that receives a grant associated with a transmission type may perform LCP using the procedures / parameters / rules associated with the transmission type. The WTRU may further determine the transmission type to use for a particular grant. Based on this determination, the WTRU may perform LCP using the procedures / parameters / rules associated with the selected transmission type.

[0172] In some cases, the WTRU may determine whether the grant is for unicast / multicast / broadcast based on implicit / explicit network indications (eg, for Mode 1) and / or based on the QoS associated with the data to be processed (eg, priority, latency, etc.).

[0173] Regarding implicit / explicit network indication, the WTRU may receive an explicit indication in a DCI allocating a grant indicating unicast, multicast, or broadcast. Additionally / alternatively, the WTRU may receive a DCI for a RAT indicating a grant whereby the RAT does not allow unicast / multicast transmissions (e.g., LTE RAT), and the WTRU may implicitly interpret such a grant as a grant for broadcast transmission. Additionally / alternatively, the WTRU may receive modulation / coding parameters or resource-related parameters (e.g., time / frequency / beam / carrier / BWP / pool) in a DCI that implicitly indicates a type of propagation based on the WTRU configuration, WTRU capability limitations, and / or WTRU state. For example, the WTRU may be configured to have unicast transmissions and broadcast transmissions in separate carriers, and the DCI may implicitly indicate the propagation used for the transmission from the carrier. In another example, the WTRU may be configured to have unicast transmissions on a subset of beams and broadcast transmissions on all beams, where if the DCI contains information for determining the beam subset, the WTRU may use the grant to satisfy the unicast logical channel.

[0174] Regarding the QoS associated with the data to be processed, the WTRU may decide to use the authorization for unicast, multicast, broadcast by first considering the logical channel with the highest priority and / or lowest latency, and / or highest reliability, etc. For example, the WTRU may select the logical channel with the highest priority and / or lowest latency for the data to be processed from its logical channels. The WTRU may determine whether the authorization being processed is unicast / multicast / broadcast based on whether the selected logical channel is unicast / multicast / broadcast, and this may be taken into account when the authorization is received. The WTRU may then process the LCP for the authorization using the appropriate process for that transmission type. In this method, when the network indicates that the authorization can be used for any transmission type, the WTRU may further perform a QoS-based association. For example, the DCI may explicitly or implicitly indicate that the authorization is for unicast or broadcast transmission.

[0175] In some cases, the WTRU may be configured to handle different types of simultaneous grants differently depending on the nature of the transmission type (e.g., mode vs. RAT vs. propagation) and / or WTRU capabilities. For example, a WTRU that is capable of transmitting simultaneously with different transmission types may perform both transmissions, while a WTRU that is not capable may select one of the transmissions based on specific rules discussed herein.

[0176] The ability of the WTRU to use different types of simultaneous transmissions at the same time may depend on the nature of the transmission types. For example, the WTRU may not be allowed to transmit Mode 1 and Mode 2 or unicast and broadcast on the same RAT at the same time, but may be allowed to perform Mode 1 transmissions on NR RAT and Mode 4 transmissions on LTE RAT at the same time, or to perform unicast transmissions on NR RAT and multicast transmissions on LTE RAT at the same time.

[0177] In one method, 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. When the WTRU ignores / cancels the Mode 2 grant due to a conflict between the Mode 1 grant and the Mode 2 grant, the WTRU may further perform resource reselection.

[0178] In another method, 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) in which the associated logical channel (e.g., Mode 1 logical channel versus Mode 2 logical channel) has the highest priority / lowest latency data available for transmission. 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 was ignored / cancelled.

[0179] In some cases, the WTRU may perform an LCP procedure associated with a particular transmission mode by considering only the logical channels associated with that transmission mode when performing the LCP. This may apply to a first modeling of fixed logical channel to transmission type mapping and / or a second modeling of the WTRU moving a logical channel from one transmission type to another transmission type. The WTRU may maintain a set of logical channels associated with each transmission mode. Assuming a modeling of the WTRU moving a logical channel from one transmission type to another transmission type, the WTRU may change the transmission mode associated with the logical channel. The WTRU may evaluate the logical channels associated with each transmission mode at the time of authorization.

[0180] In an example, for the case of Mode 1 and Mode 2 transmission, the WTRU may be configured using a second modeling of the WTRU moving logical channels from one transmission type to another transmission type. When the WTRU receives a Mode 1 grant, the WTRU may perform LCP by considering only the logical channels associated with Mode 1 when receiving the Mode 1 grant.

[0181] The WTRU may change the transmission mode associated with a logical channel during the execution of LCP (e.g., due to an event received from a lower layer, or the expiration of a timer). In this case, the WTRU may delay the change of the transmission mode until: after the LCP procedure is completed; and / or after a retransmission of a MAC PDU constructed by the LCP procedure is performed.

[0182] In some cases, the WTRU may be configured with logical channels that are associated with a specific transport type (e.g., a fixed transport type), and logical channels that are not associated with any transport type (e.g., a flexible transport type). This may be applied to a third modeling where logical channels may be associated with multiple transport modes. When the WTRU performs LCP for a grant with an associated transport type, only logical channels associated with that transport type may be considered, and logical channels that are not associated with any transport type. The WTRU may perform LCP by first selecting the logical channels with the highest priority, regardless of the transport type, and allocating resources to these logical channels until the grant is exhausted or the logical channels are satisfied (e.g., possibly up to the prioritized bit rate).

[0183] In some cases, the WTRU may be configured with or determine prioritization of logical channels to transport types. This may be applied to a third modeling where a logical channel may be associated with multiple transport modes. The WTRU may perform an LCP for a grant associated with a transport type by selecting data on a logical channel that is prioritized for the transport type, as long as there is data in the buffer for that logical channel. In the event that there is no data remaining in the buffer of any prioritized logical channel, or when each logical channel is served to its prioritized bit rate, the WTRU may then select data associated with a non-prioritized logical channel (e.g., prioritized for transport type).

[0184] In an example, the WTRU may determine the logical channels to use for data packets based on QoS. The WTRU may also determine the prioritization of logical channels to modes (e.g., Mode 1 and Mode 2) based on decision criteria such as described herein. When a grant for Mode 1 is received, the WTRU may select all logical channels prioritized for Mode 1 to satisfy the grant. If all such logical channels are satisfied (e.g., the logical channels are empty or until their prioritized bit rates are satisfied), the WTRU may select non-prioritized logical channels to fill the remainder of the grant.

[0185] In some cases, the LCP process associated with a transport type may satisfy a logical channel that may be transmitted on any transport type up to a percentage of its PBR. If a logical channel is not associated with a PBR, the WTRU may satisfy a certain percentage of available data in the WTRU buffer. The WTRU may determine the percentage of PBR for each transport type based on any of the following (note: for a particular logical channel, the PBR may be infinite): the percentage of PBR may be configured by the network; the percentage of PBR may be based on the percentage of BSRs reported to the network for each transport type in the last BSR; the percentage of PBR may be based on the measured quality of each transport type (e.g., LTE RAT vs. NR RAT); the percentage of PBR may be determined or derived by any other condition / criteria described herein.

[0186] In some cases, the WTRU may determine prioritization between NR and LTE QoS transmission types. This may occur in cases where LTE prioritization is based on PPPP and NR prioritization is based on VQI. Inter-RAT prioritization may be required for LCP, BSR transmission, resource selection, etc.

[0187] In one method, the WTRU may be provided with QoS parameters associated with both RATs per packet or per radio bearer and may 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 upper layers. The WTRU may perform prioritization decisions between LTE packets and NR packets by considering the PPPP associated with each packet.

[0188] In another method, the WTRU may be provided with a table by upper layers or by the network that may be used to derive QoS parameters in one RAT (e.g., PPPP) from QoS parameters in another RAT (e.g., VQI). The WTRU may then perform prioritization based on the QoS parameters in the one RAT. For example, the WTRU may be provided with a table that maps VQI to PPPP. The WTRU may then perform prioritization for both LTE packets and NR packets based on PPPP.

[0189] In another method, the WTRU may be provided with a mapping table for one RAT or for two RATs, which derives one or more QoS parameters from the QoS parameters provided by the upper layer and may derive the priority of the RAT based on predefined or (pre-)configured rules. For example, for an LTE packet, the priority of the packet may be PPPP. For an NR packet, the WTRU may be configured with a table that derives reliability, range, latency, priority, and data rate from the VQI. The WTRU may be (pre-)configured with one or more rules to derive the priority from these individual QoS parameters derived from the VQI. For example, one such rule may be to assign the priority of the packet to be equal to the priority derived from the VQI plus a compensation factor related to latency (e.g., if the latency < x, increase the priority by 1, and if the latency > y, decrease the priority by 1). The WTRU may also be configured to have different rules for different prioritization operations at the WTRU, such as: LCP (e.g., the logical channel that selects the data with the highest priority among all the data to be processed at the WTRU); BSR (e.g., prioritization of the LTE BSR over the prioritization of the NR BSR, or determination of the LCG to be included in the truncated BSR). In another example, one such rule may be to assign priority to latency based on a (pre-)configured mapping of latency in ms to priority (e.g., in absolute numerical terms, mapped to the same scale as PPPP).

[0190] As previously mentioned, the WTRU may report buffer status. However, in some cases, there may be an SR / BSR process to address QoS requirements and simultaneous transmission types.

[0191] In some cases, the WTRU may have an SR / BSR process for handling NR QoS requirements, where the WTRU selects / changes the BSR format and / or maps QoS to the LCG based on the data currently in its buffer. This may occur when determining how to report the buffer status associated with a wide range of QoS in the case of a given limited number of LCGs in the BSR. When determining the BSR, the WTRU may assume different mappings of QoS to the LCG, or it may transmit BSRs with different formats according to the QoS of the data in its buffer.

[0192] Different mappings of QoS to LCGs may include any of the following: different numbers of QoS levels or QoS parameters mapped to a given LCG (e.g., mapping VQI values ​​1, 2 to LCG1, mapping VQI 2, 3 to LCG2, etc., or varying this mapping); different numbers of QoS levels represented by a particular LCG (e.g., some QoS levels may not have an LCG representing them); different associations of different QoS parameters (e.g., latency versus priority versus reliability) with LCGs (e.g., mapping PPPP to LCG1, 2 and PPPR to LCG3, 4, or varying this mapping); and / or certain LCGs used to represent buffer states for different QoS parameters in some cases but not in other cases.

[0193] The different formats of the BSR may include any of the following: different numbers of bits in the BSR associated with LCGs (e.g., different numbers of allowable LCGs) (e.g., one format of the BSR may assume 4 bits for LCGs and 4 bits for buffer status, while another format may assume 5 bits for LCGs and 3 bits for buffer status, or one format of the BSR may assume 12 bits to report the buffer status associated with a single destination ID and LCG, while another format of the BSR may assume 24 bits to report the buffer status associated with a destination ID and a logical channel group, and different mappings of QoS levels to LCGs may also be used); and / or replacement / reuse of certain fields in the BSR to report buffer status associated with certain QoS parameters (e.g., the WTRU may replace the destination address associated with the reporting of the buffer status with additional QoS parameters (e.g., reliability or latency) when such data is available in the WTRU buffer and when the reported destination address is the same as a previous report).

[0194] The WTRU may indicate a changed or different mapping / format to the network by one or more of: transmitting an RRC message or MAC CE with an index to a (pre-)configured mapping / format for use, or with the actual mapping to be used in a future BSR report; transmitting the mapping / format for a specific BSR in the BSR itself, either through a field in the BSR or by selecting a BSR format or MAC CE type; indicating that the mapping / format has changed, possibly followed by the actual mapping to be used, by transmitting a specific SR or PUCCH indication; and / or providing 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, using the RRC, MAC CE or BSR itself.

[0195] The WTRU may change the format / mapping of the BSR from one format / mapping to another based on any of the following triggers: new data arrives for a QoS level for which no LCG representing the format exists 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 buffer for two or more QoS levels exceeds / falls below a threshold.

[0196] In one example, the WTRU may be configured with multiple mappings from (one or more) VQIs to LCGs. In one mapping, used as an illustrative example where the WTRU may report 3 LCGs, the WTRU may report the buffer status of data associated with VQI1-2 using LCG1, the buffer status of data associated with VQI3-4 using LCG2, the buffer status of data associated with VQI5-6 using LCG3, and so on, so that all (one or more) VQIs are represented equally. In addition, the WTRU may be configured to have a mapping whereby VQI1 is mapped to LCG1, VQI2 is mapped to LCG2, and the remaining VQIs are all mapped to LCG3. The WTRU may adopt the second mapping when the data in the WTRU's buffer is mainly from VQI1 and VQI2. Alternatively, if the WTRU has data in its buffer that is evenly distributed between multiple VQIs, the WTRU may use the first mapping. The WTRU may indicate a change in mapping (e.g., via an RRC message or MAC CE), or it may indicate the mapping used in each BSR message.

[0197] In another example that may be used in conjunction with the previous example, in one scenario where the data in the buffer is limited to a subset of QoS levels, the WTRU may use 4 bits for LCGs (e.g., 16 LCGs total) to report the BSR, and in another scenario where the data in the buffer contains all QoS levels or close to all QoS levels, the WTRU may use 5 bits for LCGs (32 LCGs total).

[0198] As previously described, the WTRU may transmit a SR / BSR when determining how to handle data packets for transmission, however, there may also be a SR / BSR method to handle simultaneous transmission types.

[0199] In some cases, the BSR calculation may be based on the available Mode 2 resources. In this approach, which may be the case for Mode 1 versus Mode 2 transmission types, the WTRU may calculate the buffer status by considering the amount of resources reserved or available for Mode 2 transmission. Specifically, when calculating the buffer status to send to the network, the WTRU may consider any of the following "reserved" resources in Mode 2: the total amount of resources reserved by a reservation signal, forward reservation signal, or similar signal; the total amount of resources associated with a selected resource mode; the amount of "reserved" resources that occur in N next reservation periods, where N may be predefined or (pre)configured; and / or, the amount of "reserved" resources that may be used to satisfy logical channel transmissions, where the logical channel may use Mode 1 transmissions or Mode 2 transmissions.

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

[0201] Figure 4 403a, the amount of data in the WTRU buffer that can be transmitted using only mode 2 (e.g., only logical channels mapped to mode 2); 403b, the amount of data from step 2 that can be additionally transmitted using mode 2 based on the amount of reserved mode 2 resources and an estimate of the MCS (e.g., average MCS over a period of time); and / or 403c, the current state of the decision criteria used to determine the portion of the data that the WTRU is allowed to transmit via mode 2 in the second phase, given the decision criteria, as discussed herein. At 404, the WTRU may finally report the buffer status from the first stage minus the estimated Mode 2 data in the third stage.

[0202] In some cases, the WTRU may send a BSR to indicate a change in transmission type. Specifically, the WTRU may trigger a BSR to the network during a decision to send some or all data that may be pending at the WTRU via a different transmission type, or when any condition used to determine the transmission type changes.

[0203] The WTRU may trigger a BSR when any of the following events occurs: the WTRU decides to move 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 of the conditions defining the mapping of data to transmission types as discussed herein change; a change in the calculation of the buffer status of available Mode 2 resources is taken into account, which may change by some amount, which occurs due to a change in any of the conditions as discussed herein, a change in the estimated MCS, or a change in the amount of reserved Mode 2 resources, which may change per time period; the WTRU removes all logical channels associated with a particular transmission type; and / or the WTRU creates a new logical channel associated with a transmission type, which may be the first logical channel.

[0204] The following are examples of conditions that define a mapping to transmission types: the number of failed Mode 2 resource selections that occur, possibly within a predefined time window; a change in the value of a measurement quantity associated with a Mode 2 resource pool, such as CBR, CR, RSSI, average RSCP of SCI transmissions, or the number of SCIs in a predefined period, by a predefined or (pre)configured amount; a change in the estimated number of WTRUs in an area by a predefined or (pre)configured amount; reception of a preemption signal; and / or other examples discussed herein.

[0205] In one example, the WTRU may receive a preemption signal associated with a Mode 2 transmission, possibly for a given QoS. The WTRU may decide to move all Mode 2 traffic that may be 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 as well as the buffer status, or by taking into account the new buffer status for the new data to be transmitted using Mode 1. Alternatively, the WTRU may send a BSR where the buffer status indicates a delta of new data compared to the previous BSR report, which may now be transmitted in Mode 1. Such an example may also be applicable to cases with other transmission types (e.g., LTE to NR, where preemption is received on NR and Mode 3 is configured for LTE).

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

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

[0208] In one example, the WTRU may send a BSR to the network after the transmission mode (mode 1 or mode 2) of the SLRB changes (e.g., the SLRB moves from mode 1 to mode 2). The WTRU may calculate the new buffer status of all LCHs associated with mode 1 after the mode of the SLRB changes and may send a new BSR to the network. For example, the WTRU may detect a condition (e.g., Uu quality below a threshold) that triggers a SLRB that is currently configured to use mode 1 to change to use mode 2. The WTRU may remove the SLRB from the logical channels associated with mode 1 and move the SLRB to a mode 2 SLRB. The WTRU may also notify the network of the change in buffer status caused by the change. In another example, the WTRU may detect a condition (e.g., SLRLM).

[0209] In one example, the WTRU may include the BSR for all LCGs in the BSR. In another example, the WTRU may only include the LCGs whose buffer status is changed by the mode change of the given SLRB(s).

[0210] In one example, the WTRU may start a timer after a condition is triggered that requires a mode change for a particular SLRB. If the condition persists during the timer, the WTRU may send a mode change message to the network as described in other scenarios herein.

[0211] In another example, the WTRU may send a BSR and / or related messages (e.g., MAC CE, RRC messages such as SidelinkUEInformation, etc.) to the network to inform the network about the change in the preferred mode for a particular SLRB. Such a message may include: the SLRB or LCH for which the mode change trigger was determined at the WTRU; the specific condition of the triggering condition (e.g., in the form of an index to a list of configured conditions); the QoS attributes of the SLRB and / or the flow mapped to the SLRB (e.g., PQI, QFI, etc.); and / or measurements related to the condition, such as Uu quality, SL quality, etc., as described herein with respect to the WTRU configuration for mode selection.

[0212] In such an example, the WTRU may perform any one or a combination of the following operations after it sends a message to the network: the WTRU may initiate a mode change for a specific SLRB immediately after successfully transmitting an indication to the network; the WTRU may stop transmissions associated with the SLRB until reconfigured by the network; and / or, the WTRU may start a timer. If the conditions for the mode change are maintained and the timer expires, the WTRU may initiate a mode change. As described herein, once the mode change is initiated, the WTRU may transmit a BSR with an updated buffer status for all Mode 1 LCGs. If the conditions for the mode change do not hold for the duration of the timer, the WTRU may cancel the timer and notify the network.

[0213] The above description of the SR / BSR process can be applied to Figure 3 , which shows an example of data processing when conditions change. Referring to portion 311, since the WTRU decides to change LCH1 from mode 1 to mode 2, a BSR may need to be sent to the network here, because the network no longer needs to consider the buffer status of LCH1 since it moves to mode 2 where the WTRU will perform scheduling autonomously. Note that the buffer status shown in portion 311 is fuller at T1 than at T2 due to the remapping of LCH1 to mode 2.

[0214] In some cases, the WTRU may remap the LCG after a service switch, which may apply to any modeling discussed herein. After data is switched from one transmission type to another or after any condition changes described herein, the WTRU may change the QoS to LCG mapping for BSR reporting. Specifically, the WTRU may be configured with a mapping of QoS parameters (e.g., VQI, PPPP, priority, latency, etc.) to LCGs, and may indicate a preferred or alternative mapping, such as those described herein, to the network after conditions change. Alternatively, the WTRU may be configured with more than one QoS to LCG mapping, and may indicate a new mapping to the network when conditions change (e.g., via an index to the new mapping). The WTRU may also indicate such an alternative mapping or mapping change when conditions result in a change in the transmission type of one or more QoS types (e.g., a range or set of VQIs) and / or a change in the transmission type of one or more logical channels or LCGs.

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

[0216] 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 a remapping of the LCGs for the broadcast traffic so that one of the LCGs may be reserved for reporting buffer status associated with the unicast traffic.

[0217] In some cases, the WTRU may report the buffer status for unicast separately from the broadcast traffic. Specifically, the WTRU may use any of the following to report BSRs for different propagation types: one or more LCGs are predefined or (pre)configured for different propagation types; different BSR formats (e.g., different MAC CEs) are used to report buffer status with different propagation types; separate buffer status fields are used in the BSR associated with a logical channel group to report separate broadcast types; and / or different destination indexes are used to report different propagation types.

[0218] In one case, the WTRU may report a BSR for unicast / multicast using a destination index from a list of dedicated destination indices reserved for unicast. The WTRU may use a different dedicated destination index for each unicast / multicast link active at the WTRU (e.g., for each different destination address). The WTRU may determine the list of dedicated destination indices for unicast / multicast from: (pre-) configuration (e.g., system information, dedicated RRC signaling, pre-configuration); predefined for all WTRUs; from another WTRU (e.g., head WTRU or scheduling WTRU); MAC CE or dynamic scheduling (e.g., DCI); during mobility, in the HO command; implicitly, based on the difference in address space between the number of bits configured for the destination index and the number of broadcast destination addresses the WTRU actually needs to reference (e.g., the WTRU may be configured with a list of broadcast service destination addresses in the UESidelinkInformation message of length 32, which requires 5 bits, and may be configured with 6-bit wide destination indices, where the WTRU may use indices 0-31 or 32-63 for unicast / multicast destination indices).

[0219] The WTRU may increment the destination index in a dedicated destination index list for each unicast / multicast link established. Alternatively, the WTRU may send the selected destination index to the network for each unicast / multicast link established (eg, at link establishment).

[0220] When an additional destination index is required for a unicast link, the WTRU may send an indication to the network. Such an indication may be sent by RRC (eg, UEAssistanceInformation) or MAC CE.

[0221] In some cases, the WTRU may report the buffer status of the LTE and NR RATs separately. Specifically, the WTRU may report the buffer status of data to be transmitted over different sidelink RATs (e.g., LTE to NR) separately. The WTRU may report BSRs for different propagation types using any of the following: different BRS formats; different LCGs within the same BSR message; and / or different destination indexes within the same BSR message.

[0222] Regarding different BSR formats, in one example, the WTRU may transmit different LTE BSR and NR BSR MAC CEs. Specifically, this case may assume a model where the same LCG may be assigned to both LTE and NR. The WTRU may be configured to have separate QoS to LCG mappings via RRC - for example, for LTE, the WTRU may be configured to have a mapping between PPPP and LCG, while for NR, the WTRU may be configured to have a mapping between VQI and LCG.

[0223] Regarding different LCGs within the same BSR message, this case may assume a model where an LCG may be assigned for either LTE or NR but not both. When the WTRU has / does not have data available for one RAT, the WTRU may follow the LCG remapping procedure as described herein.

[0224] Regarding different destination indices within the same BSR message, this scenario may assume a model where the same LCG may be assigned to both LTE and NR. The WTRU may be configured with separate QoS to LCG mappings via RRC - for example, for LTE, the WTRU may be configured with a mapping between PPPP and LCG, while for NR, the WTRU may be configured with a mapping between VQI and LCG.

[0225] In one case, the WTRU may determine the buffer status of each RAT for flexible data. This may apply to a second modeling where the WTRU may move a logical channel from one transmission type to another, and a third modeling where a logical channel may be associated with multiple transmission modes. Specifically, the WTRU may calculate the buffer status of each RAT based on an estimated amount of data to be routed on each RAT, as determined from one or more conditions defined herein. Such calculation of the buffer status may be performed based on the status of the conditions at the time of the BSR calculation. The WTRU may trigger a new BSR when one of the conditions has changed and / or the amount of data that may be moved from one RAT to another is greater than a threshold.

[0226] For example, the WTRU may be configured with an indication from upper layers of the percentage of traffic to be transmitted on each LTE and the NR to be used for that traffic, which may be sent on both RATs. The percentage may be defined based on the CBR of the Mode 2 / Mode 4 pool in each RAT. At the time a BSR is to be sent (e.g., based on any BSR trigger), the WTRU may: calculate the CBR on LTE and NR and the corresponding percentage of data to be sent on each RAT; determine the total amount of data to be sent on each RAT based on the data in the WTRU buffer that is configured (e.g., by upper layers) to be sent only on a single RAT, the data that may be sent on either RAT, and the percentage calculated above; and / or the buffer status of each RAT based on the above calculation.

[0227] In one case, there may be prioritization rules between LTE SL BSRs and NR SL BSRs. Specifically, with respect to the transmission of different BSR formats for different RATs, the WTRU may prioritize between the transmission of an LTE BSR and an NR BSR within an UL grant based on any of: the QoS of the data to be submitted within the BSR (e.g., the WTRU may prioritize the transmission of a BSR, LTE, or NR, that requires reporting its higher priority data, where the WTRU may prioritize the BSR associated with the RAT for which the WTRU has the highest priority logical channel, or the QoS-based prioritization may use rules for inter-RAT prioritization as discussed herein); the size of the BSR (e.g., the WTRU may prioritize the transmission of a BSR, LTE, or NR with the smallest total size, or may avoid the need to transmit a truncated BSR using the current uplink grant); and / or the RAT associated with the BSR (e.g., the WTRU may prioritize the transmission of the LTE RAT or the NR RAT).

[0228] The WTRU may also be configured by the network to follow certain rules related to the above. For example, the WTRU may be configured by the network with a RAT for which BSR transmissions are prioritized (e.g., prioritizing LTE BSRs over NR BSRs).

[0229] The WTRU may use a combination of the above rules, or may use multiple rules if a specific rule does not produce a result. For example, the WTRU may use the QoS of the data to be submitted, and if both RATs have pending data of equal priority, the WTRU may use the size of the BSR.

[0230] In one case, the WTRU may determine the destination index for both the LTE SL and the NR SL. This may occur in situations where the destination address may be common between the two RATs (e.g., multi-RAT support for the same service), so a method may be needed to differentiate the buffer status of the service on LTE and NR.

[0231] In one example, the WTRU may associate an explicit bit (e.g., RAT indicator bit) in the destination index in the BSR with the RAT. Specifically, the complete destination index may include a one-bit RAT indicator and an x-bit destination index, where the destination index may be derived from the index of the destination address in the destination address list in the UESidelinkInformation message (e.g., as in LTE).

[0232] 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) of the service in a carrier / service list in UESidelinkInformation, the list being associated with a carrier for the RAT. Specifically, the WTRU may be configured with a list of carriers and an association of the RAT for each carrier. In addition, the WTRU may be configured with a list of services / destination addresses of interest and the carriers that support each service / destination address. The WTRU may associate the destination index for a service for LTE as the first LTE carrier in the list for the service, and associate the destination for a service on NR as the first NR carrier in the list for the service.

[0233] In another example, when the WTRU determines that LTE or NR can support a service, the WTRU may associate two related destination indexes with each RAT LTE and NR. The relationship between the destination indexes may be any of the following: using consecutive destination indexes; and / or, using destination indexes separated by multiple destination indexes in the destination index address space, wherein the separation may be based on the number of total supported destination indexes of the WTRU or a (pre-)configured value. For example, the WTRU may determine a service / destination address supported by the WTRU that is supported on different RATs. This determination may also be made by associating the carrier frequency associated with the service / destination address and the RAT associated with the carrier frequency. The WTRU may allocate a single destination index for each service on a given RAT, regardless of the number of carriers supported by the RAT, by incrementing based on the order of the service / destination addresses reported to the network in UESidelinkInformation. For services supported by the WTRU on multiple RATs, the WTRU may allocate two consecutive destination indexes, wherein the first index is associated with one RAT (e.g., LTE) and the second index is associated with another RAT (e.g., NR).

[0234] In one case, when performing LTE SL and NR SL, the WTRU may determine a truncated BSR. Specifically, this may involve reporting LTE and NR buffer status in the same BSR, wherein the WTRU may determine the content of the truncated BSR using one or more of the following: the WTRU may prioritize the transmission of the buffer status of one RAT over another RAT, which may be predefined or (pre)configured; the WTRU may prioritize the transmission of the buffer status associated with the highest priority LCG (e.g., assuming that separate LCGs are allocated for different RATs); the WTRU may prioritize the transmission of the buffer status associated with the highest priority LCG, and for the same LCG for different RATs, the WTRU may prioritize one RAT over another RAT, which may be predefined or (pre)configured, or prioritize the RAT that has data in its buffer that has the highest priority between the two RATs (e.g., the WTRU may use any of the rules defined herein to perform such prioritization).

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

[0236] In some cases, the WTRU may perform the selection of retransmission resource(s) for unicast transmission only after receiving a NACK from peer(s) WTRU. In general, the WTRU may be configured to have different resource selection procedures for unicast / multicast and broadcast transmissions. The WTRU may also be configured to have different resource selection procedures for unicast / multicast resource selection and broadcast resource selection. The WTRU may select the retransmission resource(s) using modified parameters for resource selection, including but not limited to: a shorter value of T2 defining the resource selection window; a different value of the threshold for determining the availability / unavailability of resources based on the sensing process; a different value of the LBT backoff timer, or a channel occupancy threshold associated with LBT sensing; different conditions when the WTRU can transmit a preemption indication (e.g., the number of available resources); a different priority of the actual PPP / VQI of the packet compared to the initial transmission; a different number of channels / RBs, where the retransmission resources may use a number of channels / RBs that is a (pre-)configured function of the amount of resources used for the initial transmission (e.g., the WTRU may provide additional redundancy for the retransmission resources by further encoding or by transmission of different RVs).

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

[0238] In some cases, the WTRU may use unneeded retransmission resources for transmission by another sidelink process. Specifically, the WTRU may select both a transmission and (one or more) retransmission resources for a unicast transmission. In a case where the WTRU does not need one of the retransmission resources due to an ACK or lack of a NACK associated with the initial transmission, the WTRU may use the retransmission resources for the initial transmission via another sidelink process (e.g., unicast or broadcast). The WTRU may select a sidelink process that uses unused retransmission resources based on any one or a combination of the following criteria: a sidelink process that performs resource (re)selection when unused retransmission resources are available, possibly for a one-time transmission; a sidelink process for which the retransmission resources meet the timing requirements of the initial transmission process; and / or a sidelink process that requires the same number of retransmission resources as the number of available retransmission resources due to the number of unused retransmission resources.

[0239] In some cases, the WTRU may use (one or more) one-time resource selection procedures for retransmission resource selection. Specifically, the WTRU may use a one-time resource selection procedure to select retransmission resources for a forward-booked (e.g., periodic) unicast process. The WTRU may trigger such a one-time resource selection procedure for a unicast process after receiving a NACK received from a lower layer. Alternatively, the WTRU may select retransmission resources from unused retransmission resources according to the previous solution when a NACK is received from a lower layer. Alternatively, if there is another unicast process that meets the timing requirements of the retransmission (e.g., associated with the same destination ID), the WTRU may choose not to trigger resource selection for the retransmission resources.

[0240] In some cases, the WTRU may use a band-specific CQI during resource selection for unicast. Specifically, the WTRU may utilize the results of the sidelink CQI associated with the unicast link during the resource selection process.

[0241] In one example, the WTRU may exclude resources with sidelink CQI below a threshold from the resource selection algorithm. Specifically, the WTRU may exclude resources based on the sensing results, and then further exclude resources with CQI below a threshold. The WTRU may then perform random resource selection on the remaining resources that are not excluded.

[0242] In another example, the WTRU may select a resource with the best CQI from the available resources. Specifically, the WTRU may exclude resources based on the sensing results. If the number of available resources is greater than a threshold, the WTRU may select a resource with the best / highest SL CQI from the available resources that meets the data requirements.

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

[0244] In some cases, the WTRU may determine a successful resource allocation based on the reliability of the data to be transmitted. This may apply to both unicast and broadcast resource selection, where the WTRU may determine the criteria required for successful resource selection based on the reliability requirements associated with the data to be transmitted. For example, if a percentage (x%) of resources that meet the timing requirements of the transmission are determined to be available through sensing, the WTRU may consider the resource selection to be successful. The WTRU may be configured to use different x% values ​​depending on the WTRU reliability requirements.

[0245] The WTRU may also determine instances of failure of the resource selection algorithm based on reliability requirements. For example, the WTRU may perform multiple attempts at resource selection by increasing a threshold associated with determining resource occupancy based on sensing results (e.g., as in LTE). Depending on the reliability, the WTRU may indicate a failed resource selection algorithm after a number of such attempts, where the number may depend on the reliability requirements of the data to be transmitted.

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

[0247] In some cases, the WTRU may use different carrier selection rules for unicast transmissions. Specifically, the WTRU may be configured with different rules for carrier selection associated with unicast transmissions compared to broadcast transmissions. The motivation behind this rule may be due to limitations on the number of carriers that can be supported between two WTRUs in unicast (e.g., due to capabilities).

[0248] The WTRU may be configured to perform carrier selection for unicast differently than broadcast using any of the following: the WTRU may be configured to have a different CBR threshold for carrier selection associated with unicast than broadcast; the WTRU may be configured to have a different carrier retention threshold for carrier selection associated with unicast than broadcast; the WTRU may be configured to ignore the CBR threshold for carrier selection for unicast (e.g., always use any carrier), possibly when the number of carriers supported for unicast transmission between two WTRUs is below a threshold; and / or, the WTRU may be configured with a different number of allowed sidelink processes per carrier, where the WTRU may be allowed a greater number of sidelink processes on a carrier that is a candidate carrier for unicast data transmission. Alternatively, the WTRU may be allowed to have only unicast processes on a carrier where the WTRU is configured to have both unicast and broadcast services, possibly under certain criteria (e.g., the number of carriers used for unicast is below a threshold, or the CBR on a particular carrier is above / below a threshold).

[0249] In some cases, the WTRU may trigger a carrier / resource reselection when there is a change in conditions for determining the transmission type of a data packet. For example, the WTRU may trigger a resource reselection after deciding to move certain logical channels or certain QoS types from Mode 2 to Mode 1. Additionally / alternatively, the WTRU may trigger a resource reselection after deciding 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 configured resources (e.g., SPS resources) with Mode 2 resources.

[0250] The scenarios described in this article regarding the carrier / resource (re)selection process can be applied to Figure 3 , which shows an example of data processing when conditions change. Referring to section 313, here carrier / resource reselection may need to occur as a result of the WTRU deciding to change LCH1 from Mode 1 to Mode 2, since the WTRU no longer receives scheduling information for LCH1, the WTRU will need to consider the resources required by LCH1 in its Mode 2 resources. Note that the added block at T2 compared to T1 represents the added Mode 2 resources now required for LCH1.

[0251] In some cases, the WTRU may use an amount of Mode 1 resources during the resource selection process for Mode 2. Specifically, the WTRU may determine the amount of resources to be selected during resource selection / reselection (e.g., periodicity, size, number of one-time processes, etc.) based on any of the following: an NW indication of the NW available resources; and / or the QoS of the data to be transmitted. For the NW indication of the NW available resources, in one example, the NW may enable / disable SPS resources, and the WTRU may perform resource reselection by adding / removing 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 that it will provide, and the WTRU may determine the amount of additional Mode 2 resources to select based on the indication.

[0252] In some cases, the WTRU may determine whether to use Mode 1 or Mode 2 on a carrier based on the CBR. Specifically, the WTRU may perform carrier selection for the sidelink procedure. If the number of carriers selected by the procedure 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.

[0253] In another method, the WTRU may perform resource selection for up to a maximum number of resources on a carrier based on QoS and / or CBR. If the WTRU requires additional resources to meet its current buffer requirements, the WTRU may request Mode 1 resources to meet the remaining resource requirements on that carrier.

[0254] Although the features and elements are described above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware that is incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, 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 associated with the software can be used to implement a radio frequency transceiver used in a UE, WTRU, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information from the network; receiving a data packet from an upper layer of a protocol stack operating on the WTRU; At a first time, determining a transmission type associated with the data packet based on the configuration information and the condition; as well as The data packet is transmitted using the determined transmission type.

2. The method according to claim 1, wherein: The configuration information includes decision criteria associated with determining the transmission type.

3. The method of claim 2, wherein the configuration information comprises a set of logical channels associated with data attributes. 4 . The method of claim 3 , wherein determining a transmission type further comprises allocating a logical channel for processing the data packet for the transmission type based on the configuration information.

5. The method according to claim 4, wherein: The transmission type is one of a mode, a radio access technology (RAT), or a type of transmission; wherein the mode is a network scheduled mode or a WTRU autonomously scheduled mode; wherein the RAT is LTE or NR; and wherein the type of transmission is unicast, groupcast, or broadcast.

6. The method according to claim 5, further comprising: A parameter associated with the condition is measured, and it is determined that the condition has changed between the first time and a second time.

7. The method according to claim 6, further comprising: When the condition changes, a buffer status report or a scheduling request is sent to the network.

8. The method according to claim 6, further comprising: Based on the change, the carrier and resources are reselected based on one or more criteria.

9. The method according to claim 6, further comprising: Based on one or more criteria, an RRC connection is initiated if one does not exist.

10. A wireless transmit / receive unit (WTRU), the WTRU comprising: a transceiver configured to receive configuration information from a network and to receive data packets from an upper layer; a processor configured to determine a transmission type of the data based on the configuration information and the condition at a first time; and Wherein the transceiver is further configured to transmit the data packet using the determined transmission type.

Images