Methods for managing channel access

Abstract

To provide a method for channel access management.SOLUTION: A method performed by a WTRU may include a step of receiving a plurality of LBT configurations associated with one or more of a beam, a BWP, an LCH, a set of LBT parameters, a transmission type, or an LBT sub band. The method may further include a step of receiving an indication to transmit using a first LBT configuration of the plurality of LBT configurations. An attempt to acquire a channel may then be made using the first LBT configuration. The indication to transmit may additionally indicate a second LBT configuration of the plurality of LBT configurations. Data may be transmitted on the channel when the attempt to acquire the channel is successful. When the attempt to acquire the channel using the first LBT configuration fails, an attempt to acquire the channel using the second LBT configuration of the plurality of LBT configurations may be made.SELECTED DRAWING: Figure 7

Description

Background Art

[0001] Cross - reference to related applications This application claims the benefit of U.S. Provisional Application No. 62 / 652,116, filed Apr. 3, 2018, U.S. Provisional Application No. 62 / 687,008, filed Jun. 19, 2018, and U.S. Provisional Application No. 62 / 715,646, filed Aug. 7, 2018, the contents of which are incorporated herein by reference.

Summary of the Invention

[0002] A method performed by a wireless transmit - receive unit (WTRU) may comprise receiving a plurality of listen - before - talk (LBT) configurations associated with one or more of a beam, a bandwidth part (BWP), a logical channel (LCH), a set of LBT parameters, a transmission type, or an LBT sub - band. The method may further comprise receiving an indication for transmitting using a first LBT configuration of the plurality of LBT configurations. Then, an attempt to acquire a channel may be made using the first LBT configuration. The indication for transmitting may additionally indicate a second LBT configuration within the plurality of LBT configurations. Data may be transmitted on the channel if an attempt to acquire the channel using the first LBT configuration is successful. If an attempt to acquire the channel using the first LBT configuration fails, an attempt to acquire the channel using a second LBT configuration of the plurality of LBT configurations may be made.

Brief Description of the Drawings

[0003] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate like elements. [Figure 1A] FIG. is a system diagram illustrating an exemplary communication system in which one or more of the disclosed embodiments may be implemented. [Figure 1B]This is a system diagram illustrating an exemplary wireless transceiver unit (WTRU) that may be used in the communication system shown in Figure 1A, according to an embodiment. [Figure 1C] This is a system diagram illustrating exemplary radio access network (RAN) and exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to an embodiment. [Figure 1D] This is a system diagram illustrating further exemplary RANs and further exemplary CNs that may be used in the communication system shown in Figure 1A according to an embodiment. [Figure 2] This diagram illustrates an example of a listen-before-talk (LBT) failure caused by beamforming. [Figure 3] This is a state diagram illustrating multiple LBT processes, each incrementing a single counter. [Figure 4] This is a state diagram illustrating multiple LBT processes, each incrementing a separate counter. [Figure 5A] This is a slot-based timing diagram showing simultaneous LBT processes using multiple counting groups. [Figure 5B] This is a slot-based timing diagram showing simultaneous LBT processes using a single counting group. [Figure 6] This is a diagram illustrating an example pattern for indicating availability. [Figure 7] This graph illustrates an exemplary implementation of a beam fault detection procedure for a New Radio Unlicensed (NR-U) cell. [Figure 8] This flowchart illustrates an example of how to switch LBT configurations. [Modes for carrying out the invention]

[0004] Figure 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcast to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may utilize 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, and filtered-bank multi-carrier (FBMC).

[0005] As shown in Figure 1A, the communication system 100 may include radio transceiver 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 will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be called a station (STA), may be configured to transmit and / or receive radio signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, contract-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in industrial and / or automated processing chain settings), consumer electronic devices, and devices operating on commercial and / or industrial radio networks. Any of WTRU102a, 102b, 102c, and 102d may be interchangeably called a UE.

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

[0007] Base station 114a may be part of 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), and relay nodes. Base stations 114a and / or base stations 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be called cells (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell may provide coverage for radio services to a specific geographic area, which may be relatively constant or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In embodiments, base station 114a may utilize multiple input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0008] Base stations 114a, 114b may communicate with one or more WTRUs 102a, 102b, 102c, 102d via an air interface 116, which may be any suitable radio 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).

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

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

[0011] In this embodiment, the base station 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as NR radio access, which can use NR to establish an air interface 116.

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

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

[0014] The base station 114b in Figure 1A may be a wireless router, Home Node B, Home eNode B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in localized areas such as businesses, residences, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), and roads. In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and WTRU 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via CN 106.

[0015] RAN104 may communicate with CN106, which may be any type of network configured to provide voice, data, applications, and / or VoIP (Voice over Internet Protocol) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 may provide call control, billing services, mobile location services, prepaid calls, internet connectivity, video distribution, and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 and / or CN106 may communicate directly or indirectly with other RANs that utilize the same RAT as RAN104 or different RATs. For example, in addition to being connected to RAN104, which may utilize NR radio technology, CN106 may also communicate with another RAN (not shown) utilizing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0016] CN106 may also function as a gateway for WTRU102a, 102b, 102c, and 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing basic telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as TCP, UDP, and / or IP in the TCP / IP Internet Protocol Suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may utilize the same RAT as RAN104 or a different RAT.

[0017] 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). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may utilize cellular-based wireless technology and may also be configured to communicate with a base station 114b that may utilize IEEE 802 wireless technology.

[0018] FIG. 1B is a system diagram illustrating an exemplary WTRU 102. As shown in FIG. 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a GPS chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0019] Processor 118 can be a general-purpose processor, a dedicated 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. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmit / receive element 122. Although FIG. 1B illustrates processor 118 and transceiver 120 as separate components, it will be understood that processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

[0021] Transmit / receive element 122 is illustrated in FIG. 1B as a single element, but the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can utilize MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0022] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmitting / receiving element 122 and to demodulate the signal to be received by the transmitting / receiving element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0023] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data from them. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. The processor 118 may access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data therein. Non-removable memory 130 may include RAM, ROM, a hard disk, or any other type of memory storage device. Removable memory 132 may include a SIM card, a memory stick, an SD memory card, etc. In other embodiments, the processor 118 may access information from memory not physically located on the WTRU102, such as a server or home computer (not shown), and store data therein.

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

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

[0026] The processor 118 may be further 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 connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a 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, and the like. Peripherals 138 may include one or more sensors. The sensors may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a compass sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a barometer, a gesture sensor, a byte metric sensor, a humidity sensor, and the like.

[0027] WTRU102 may include a full-duplex radio in which some or all of the transmission and reception of a signal (e.g., associated with specific subframes for both UL (e.g., for transmission) and DL (e.g., for reception) may coincide and / or be simultaneous). The full-duplex radio may include an interference management unit for reducing or substantially eliminating self-interference, either through hardware (e.g., chokes) or through signal processing via a processor (e.g., a separate processor (not shown) or processor 118). In embodiments, WTRU102 may include a full-duplex radio for any of the transmission and reception of some or all of the signal (e.g., associated with specific subframes for either UL (e.g., for transmission) or DL ​​(e.g., for reception)).

[0028] Figure 1C is a system diagram illustrating RAN104 and CN106 according to an embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using E-UTRA wireless technology. RAN104 may also communicate with CN106.

[0029] RAN104 may include eNodeB160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNodeB without inconsistency with the embodiment. Each of eNodeB160a, 160b, and 160c may include one or more transceivers that communicate with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNodeB160a, 160b, and 160c may implement MIMO technology. Thus, eNodeB160a may use multiple antennas, for example, to transmit radio signals to and / or receive radio signals from WTRU102a.

[0030] Each of the eNodeB160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle decisions regarding radio resource management, handover decisions, user scheduling in UL and / or DL, etc. As shown in Figure 1C, the eNodeB160a, 160b, and 160c can communicate with each other via the X2 interface.

[0031] The CN106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the aforementioned elements are illustrated as part of CN106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0032] MME162 may be connected to each of the eNodeB162a, 162b, and 162c within RAN104 via the S1 interface and may function as a control node. For example, MME162 may be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) utilizing other radio technologies such as GSM and / or WCDMA.

[0033] The SGW164 can be connected to each of the eNodeB160a, 160b, and 160c within the RAN104 via the S1 interface. The SGW164 can generally perform other functions such as anchoring to the user plane during handovers between eNodeBs, triggering paging when DL data is available for WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0034] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0035] CN106 can facilitate communication with other networks. For example, CN106 may provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional fixed-line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. CN106 may provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0036] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in some typical embodiments, such a terminal may use a wired communication interface with a communication network (for example, temporarily or permanently).

[0037] In a typical embodiment, the other network 112 may be a WLAN.

[0038] In Infrastructure Basic Service Set (BSS) mode, a WLAN may have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with a distribution system (DS), or another type of wired / wireless network carrying traffic entering and / or leaving the BSS. Traffic originating outside the BSS and destined for an STA may reach the STA via an AP or be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS may be sent to the AP to which it is to be delivered to its respective destination. Traffic between STAs within the BSS may be transmitted via APs; for example, a source STA may send traffic to an AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source and a destination STA (e.g., directly between them) using a Direct Link Setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode does not need to have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with one another. The IBSS communication mode is sometimes referred to herein as the “ad hoc” communication mode.

[0039] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may have a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width. The primary channel may also be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In some typical embodiments, for example in an 802.11 system, CSMA / CA (Carrier Sense Multiple Access with Collision Avoidance) may be implemented. In CSMA / CA, an STA, including the AP (e.g., each individual STA), may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA may retreat. A single STA (e.g., just one base station) may transmit on a given BSS at any given time.

[0040] A high-throughput (HT) STA may use a 40MHz wide channel for communication, for example, through a combination of a primary 20MHz channel and adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0041] Ultra-high throughput (VHT) STAs may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels may be formed by combining consecutive 20 MHz channels. 160 MHz channels may be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which may be called an 80+80 configuration. In an 80+80 configuration, the data after channel coding may be passed through a segment parser that can split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed separately on each stream. The streams may be mapped onto two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration may be reversed, and the combined data may be transmitted to a media access control (MAC).

[0042] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those 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 the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support Meter Type Control / Machine-Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have some capabilities, including limited capabilities such as support for some and / or limited bandwidths (e.g., support for only those). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0043] A WLAN system that can support multiple channels, as well as channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, includes a channel that may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest general operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs when operating in the BSS. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier discovery and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if a primary channel is busy due to an STA (which only supports 1MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy, even if the majority of the available frequency band remains idle.

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

[0045] Figure 1D is a system diagram illustrating RAN104 and CN106 according to an embodiment. As described above, RAN104 may utilize NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.

[0046] RAN104 may include gNB180a, 180b, and 180c, but it will be understood that RAN104 may include any number of gNBs without inconsistency with the embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a, for example. In an embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In embodiments, gNB180a, 180b, and 180c may implement multipoint coordination (CoMP) techniques. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0047] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the spacing of OFDM symbols and / or OFDM subcarriers may differ for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing a variable number of OFDM symbols and / or lasting for a variable absolute time).

[0048] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., eNodeB160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using unlicensed band signals. In a non-standalone configuration, WTRU102a, 102b, and 102c may communicate with / connect to gNB180a, 180b, and 180c while also communicating with / connecting to other RANs such as eNodeB160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c may implement the DC principle to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c and one or more eNodeB160a, 160b, and 160c. In a non-standalone configuration, eNodeB160a, 160b, and 160c may act as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c may provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

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

[0050] The CN106 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185b. Although the aforementioned elements are illustrated as part of the CN106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0051] AMF182a and 182b may be connected to one or more of gNB180a, 180b, and 180c in RAN104 via the N2 interface and may function as control nodes. For example, AMF182a and 182b may be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating non-accessible tier (NAS) signaling, and mobility management. Network slicing may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilized by WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-high reliability low latency (URLLC) access, services that rely on high-speed high-capacity mobile broadband (eMBB) access, and services for MTC access. The AMF182a and 182b may provide control plane functionality for switching between RAN104 and other RANs (not shown) that utilize other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

[0053] UPF184a, 184b may be connected to one or more of gNB180a, 180b, 180c in RAN104 via an N3 interface, and the N3 interface may provide WTRU102a, 102b, 102c with access to a circuit-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, 102c and IP-enabled devices. UPF184a, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

[0054] CN106 may facilitate communication with other networks. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. CN106 may provide WTRU102a, 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, WTRU102a, 102b, 102c may be connected to local DN185a, 185b through UPF184a, 184b via an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0055] With regard to Figures 1A to 1D and their corresponding descriptions, one or more, or all, of the functions described herein may be performed by one or more emulation devices (not shown) with respect to one or more of the WTRU102a to d, base stations 114a to d, eNodeB160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein. An emulation device may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

[0056] Emulation devices may be designed to perform one or more tests of other devices in a laboratory environment and / or a carrier network environment. For example, one or more emulation devices may perform one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to other devices for the purpose of testing using and / or performing tests using over-the-air wireless communication.

[0057] One or more emulation 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, an emulation device may be used in a test scenario, in a test chamber and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing), to perform testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0058] Operation in unlicensed frequency bands may be subject to certain limitations regarding Transmit Power Control (TPC), and RF output power and power density are determined by the average EIRP and average EIRP density at the highest power level. It may also be subject to requirements regarding out-of-band emissions from the transmitter. Such requirements may be specific to the band and / or geographical location.

[0059] The operation may also be subject to requirements for the nominal channel bandwidth (NCB), and the occupied channel bandwidth (OCB) is defined for the unlicensed spectrum in the 5 GHz region. The nominal channel bandwidth, i.e., the widest frequency bandwidth including the guard band allocated to a single channel, should always be at least 5 MHz. The occupied channel bandwidth, i.e., the bandwidth containing 99% of the signal power, should be between 80% and 100% of the declared nominal channel bandwidth. During established communication, devices are permitted to operate temporarily in a mode in which their occupied channel bandwidth can be reduced to 40% of their nominal channel bandwidth, with a minimum of 4 MHz.

[0060] Channel access in unlicensed frequency bands may use a listen-before-talk (LBT) mechanism. LBT is typically enforced regardless of whether the channel is occupied or not.

[0061] In frame-based systems, LBT may be characterized by a clear channel evaluation (CCA) time (e.g., ~20 μs), channel occupancy time (e.g., minimum 1 ms, maximum 10 ms), idle period (e.g., minimum 5% of channel occupancy time), fixed frame period (e.g., equal to channel occupancy time + idle period), short control signaling transmission time (e.g., a duty cycle of up to 5% within a 50 ms observation period), and a CAA energy detection threshold.

[0062] In load-based systems (e.g., where the transmit / receive structure may not be time-fixed), LBT can be characterized by a number N corresponding to the number of clear idle slots in the extended CCA rather than a fixed frame duration. N can be randomly selected within a range.

[0063] Deployment scenarios may include various standalone NR-based operations, various variations of dual connectivity operations, such as EN-DC with at least one carrier operating according to LTE Radio Access Technology (RAT) or NR DC with at least two sets of one or more carriers operating according to NR RAT, and / or various variations of carrier aggregation (CA), for example, possibly including various combinations of zero or more carriers each of LTE and NR RAT.

[0064] LAA (licensed assisted access) systems may utilize parameters and / or procedures for a WTRU to access a channel. Where used herein, a listen-before-talk (LBT) procedure may be a mechanism by which an instrument, e.g., a UE or WTRU, applies a clear channel assessment (CCA) before using a channel. CCA may determine the presence or absence of other signals on the channel, each utilizing at least energy detection, to determine whether the channel is occupied or free. European and Japanese regulations mandate the use of LBT in unlicensed bands. Apart from regulatory requirements, carrier detection via LBT is one method for the equitable sharing of the unlicensed spectrum and, therefore, within the framework of a single global solution, is considered an essential feature for equitable and friendly operation in the unlicensed spectrum.

[0065] Discontinuous transmission on a carrier with a limited maximum transmission duration. In the unlicensed spectrum, channel availability cannot always be guaranteed. Several regions, such as Europe and Japan, prohibit continuous transmission and impose restrictions on the maximum duration of transmission bursts in the unlicensed spectrum. Therefore, discontinuous transmission with a limited maximum transmission duration is a required function of LAA (Language Access Arrangement).

[0066] Given the large available bandwidth of the unlicensed spectrum, carrier selection is disclosed that allows LAA nodes to select less interfering carriers and achieve good coexistence with other unlicensed spectral deployments.

[0067] Transmit Power Control (TPC) is a regulatory requirement in several areas that a transmitting device should be able to reduce its transmit power by a ratio of 3 dB or 6 dB compared to its maximum nominal transmit power. This requirement does not require a new specification.

[0068] Radio Resource Management (RRM) measurements, including cell identification, enable robust operation in inter-SCell mobility and unlicensed bands.

[0069] Channel State Information (CSI) measurements, including channel and interference measurements. WTRUs operating on unlicensed carriers should also support necessary frequency / time estimation and synchronization to enable successful RRM measurements and information reception on the unlicensed band.

[0070] In NR, a WTRU can operate using a bandwidth portion (BWP) of the carrier. First, a WTRU can access a cell using an initial BWP. It can then be configured with a set of BWPs to continue operating. At any given moment, a WTRU can have one active BWP. Each BWP is configured with a set of control resource sets (CORESETs), in which the WTRU can blind-decode PDCCH candidates for scheduling.

[0071] Furthermore, NR supports variable transmit time and feedback timing. Variable transmit time allows physical downlink shared channel (PDSCH) or physical uplink shared channel (PUSCH) transmits to occupy a contiguous subset of slot symbols. Variable feedback timing allows the downlink control indicator (DCI) for DL ​​allocation to include indication of feedback timing for WTRU, for example, by pointing to a specific physical uplink control channel (PUCCH) resource.

[0072] NR supports two types of PUCCH resources: short PUCCH and long PUCCH. The former can be transmitted using one or two OFDM symbols, while the latter can use up to 14 OFDM symbols. Each PUCCH has multiple formats, which may depend on the type and / or size of the corresponding payload.

[0073] Beam faults can be detected and then recovered. In a beamforming NR system, the WTRU may be configured to maintain one or more beam pairs. The WTRU monitors one or more periodic channel status information reference signals (CSI-RS) on the serving DL beam to assess its quality and calculate a corresponding quality measure. If the beam quality during a given RS period is below a configured threshold, the physical (PHY) layer entity of the WTRU reports a beam fault incident (BFI) to the MAC sublayer.

[0074] To re-establish lost beam pairs in a faster manner compared to the Radio Link Monitoring (RLM) / Radio Link Fault (RLM) (RLM / RLF) procedure, the WTRU's MAC layer may utilize a Beam Fault Recovery (BFR) procedure, in which a beam fault recovery request is reported to the network when a beam fault is detected. BFR can be configured for beam maintenance on configured PCells and / or SCells.

[0075] A MAC entity may maintain a beam fault incident counter (BFI_counter) for the purpose of detecting beam faults. The MAC entity counts the number of beam fault incident indications received from the PHY entity. If the BFI counter exceeds a certain maximum number of BFIs, a BFR request is triggered to notify the serving gNB that a beam fault has been detected.

[0076] A MAC entity may reset the BFI counter only after the Beam Fault Detection (BFD) timer (BFD_timer) has expired. This may help introduce some hysteresis into the detection function. In such cases, the WTRU resets the BFD_timer whenever a BFI is indicated by the PHY layer. For example, if the BFD timer is configured for three CSI-RS periods, the MAC entity may reset the BFI_counter only after it has not observed a BFI indication from the PHY for three consecutive CSI-RS periods. In another example, the BFI counter may be reset after it has not observed a BFI indication for two, four, or five consecutive CSI-RS periods.

[0077] To report a BFR request, the WTRU may initiate a random access procedure using several parameter values, such as PreambleTransMax, power ramping step, and target received preamble power. The random access procedure may also be used for beam re-establishment, as this allows the WTRU to select an appropriate physical random access channel (PRACH) preamble and / or PRACH resource depending on the best-measured downlink beam or DL ​​synchronous signal block (SSB). The WTRU may utilize a method for re-establishing beam pairs when it determines the association between the DL beam and the UL preamble and / or PRACH opportunity, thereby testing the downlink beam selected by the WTRU by receiving a random access response (RAR) to it. If the gNB constitutes several sets of contention-free PRACH preamble / resources, such an RA re-establishment procedure may be faster, which may be preferred for initiating the RA procedure and for selection by the WTRU.

[0078] Logical Channel Prioritization (LCP) is a mechanism used to associate data available for transmission with resources available for uplink transmission. Data multiplexing with different QoS requirements within the same transport block may be supported, provided, for example, that such multiplexing does not negatively impact services with the most stringent QoS requirements or result in unnecessary waste of system resources.

[0079] When assembling a MAC PDU and filling the TB for UL transmission, the WTRU typically works on data from one or more logical channels (LCHs) using the following principle: The WTRU typically performs up to two rounds of LCP. Firstly, in round 1 (or equivalently, steps 1 and 2), data from the logical channels is taken in descending order of priority up to the preferred bit rate (PBR). The data may exceed the amount of data available for transmission for the LCH in a given TTI, i.e., the "bucket," typically to avoid unnecessary RLC segmentation.

[0080] Secondly, in round 2 (or equivalently, step 3), data from logical channels may be taken in strict descending order to fill the remaining resources. The RRC may further control the LCP procedure by configuring mapping constraints for each logical channel by controlling the following parameters: allowedSCS-List may set the allowed subcarrier interval for transmission or retransmission; maxPUSCH-Duration may set the maximum PUSCH time length allowed for transmission; configuredGrantType1Allowed may set whether configured grant type 1 can be used for transmission; allowedServingCells may set the allowed cells for transmission. In one embodiment, additional constraints may include one or more applicable MCS tables, MCS values, and an RNTI or search space for the PDCCH for the DCI that schedules the transmission.

[0081] The embodiments disclosed herein may apply to NR-based operations in the unlicensed spectrum, including initial access, scheduling, HARQ, and mobility, along with coexistence methods including LTE-LAA and other existing RATs. For example, an NR-based LAA cell may be connected to an LTE or NR anchor cell, as well as an NR-based cell which may be operating in standalone mode in the unlicensed spectrum.

[0082] Unlicensed spectrum used for New Radio Unlicensed (NR-U) may have several regulatory requirements to ensure fair use of the spectrum among multiple RATs. Such requirements may lead to discontinuous use of channels in time or frequency to allow transmission by other STAs or devices. Furthermore, such requirements may impose constraints on how it is determined that channels may be used without causing excessive interference.

[0083] WTRUs in unlicensed spectra can operate flexibly using multiple BWPs and beams. Therefore, unlicensed channels in NRs are determined by parameters such as BWPs and beams. Consequently, WTRUs may use different channel access mechanisms based on channel parameters. Therefore, it may be useful to support methods that provide efficient ways for WTRUs to access channels with different parameters while maintaining a degree of fairness. It may also be useful to support methods that achieve benefits in terms of increased reliability, minimized latency, or both, such as supporting URLLC data or traffic offloaded to unlicensed spectra. Minimizing latency and increasing reliability can also be achieved in standalone NR-U deployments.

[0084] Furthermore, several functions in NR, such as beam maintenance, are based on periodic transmission. Fair channel use may not allow for periodic transmission. Therefore, methods to enable beam maintenance on unlicensed channels may be used while still ensuring fairness in channel access. The impact of LBT and similar fairness principles on accessing channels for beam maintenance may also affect the ability to meet certain transmission requirements, such as the high reliability and latency requirements of URLLC traffic.

[0085] Figure 2 is an exemplary Figure 200 illustrating an LBT failure caused by narrow beamforming using an existing mechanism. When a WTRU is operating with a narrow beam, the basic LBT mechanism may become less effective or fail to fulfill its intended purpose. As shown in Figure 2, two WTRUs, WTRU1 202 and WTRU2 204, may be attempting to communicate with the same transmit / receive point (TRP) 206. WTRU2 202 may be transmitting to TRP206 using a given TX beam 202A. TRP206 may have an RX beam 206A directed toward the TX beam 202A. Assuming WTRU1 204 is using an existing LBT mechanism, WTRU1 204 may not detect the TX beam 202A if it is using a beamforming-based LBT mechanism. This is because the existing mechanism does not require the WTRU to receive transmissions on all beams before transmitting. Instead, the existing mechanism operates under the assumption that, for example, WTRU1 204 may transmit if it simply does not detect a threshold-exceeding transmission from another WTRU, such as WTRU2 202A. Thus, in this example, TX beam 202A is missed by WTRU1 204 because WTRU1 204 did not perform LBT in the correct direction, or because it performed LBT using the required beam. Since WTRU1 204 performs reception using a narrow beam that is not directed towards WTRU2 202, WTRU1 204 does not detect an ongoing transmission from WTRU2 202 that exceeds the threshold. As a result, WTRU1 204 may initiate a transmission that will result in a collision occurring at TRP206.

[0086] In NR, multiple LBT configurations may be provided and maintained. In one embodiment, different sets of LBT parameters or types of LBT configurations may be used to avoid the problems addressed in Figure 2. A WTRU may be configured by a gNB or other TRP using different types of LBT configurations or mechanisms. Each type of LBT mechanism may be defined by a set of parameters. From the perspective of a WTRU, an LBT type may be considered a “strict” LBT if it imposes stringent requirements on the WTRU before the WTRU is allowed to use the channel. An example of a strict LBT is an LBT type with a large number of required idle CCAs and / or a low energy detection threshold. An LBT type is called “loose” if it imposes loose requirements on the WTRU before the WTRU is allowed to use the channel. An example of a loose LBT is an LBT type configured with a high energy detection threshold and a small number of required idle CCAs.

[0087] Different types of LBT mechanisms can be configured. In some embodiments, a WTRU may be configured using a set of different types of LBT mechanisms. Each element in the set may be called an LBT type or LBT configuration. A WTRU may be configured with different parameters for each possible LBT configuration, or with parameters for one or more of a plurality of LBT configurations. In one embodiment, a WTRU may receive an LBT configuration via RRC signaling. Alternatively, a WTRU may receive such a configuration using a MAC control element (CE). In an example, a WTRU may receive a MAC CE in a Random Access Response (RAR).

[0088] Configurable LBT parameters or sets thereof may be associated with an LBT configuration. These parameters include, for example, priority level, LBT type, maximum channel occupancy time (MCOT), occupied channel bandwidth (OCB), number of idle CCAs, contention window size, contention window size adjustment, CCA slot size, duration, or number, e.g., T sl, postponement time, for example t d This may include at least one or more of the following: an energy detection threshold, e.g., xthreshold, or a contention window size. In an example, the expiration time value may represent the maximum time until the WTRU can perform a transmission for a given LBT process. Such time may include the time from which the LBT process is initiated. Such a value may be configured with respect to absolute time in units such as slots, short TTI, etc. An LBT process may be associated with one or more sets of parameters that may correspond to an LBT configuration. An LBT configuration may be identified, for example, using LBT configuration identifier information (LBT_ID or LBT configuration ID). In some embodiments, one or more of the LBT_ID or LBT configuration ID may be explicitly communicated. In some embodiments, one or more of the LBT_ID or LBT configuration ID may be implicitly communicated. In some embodiments, the WTRU may be pre-configured with one or more of the LBT_ID or LBT configuration ID.

[0089] For example, a WTRU may be configured using priority levels associated with each type of LBT or LBT configuration. For example, a WTRU may use priority levels or priority types to determine which LBT procedure and / or LBT configuration should be applied to a specific type of data and / or data associated with a specific LCH or logical channel group (LCG), for example, the data itself may be associated with a corresponding priority level. For example, a WTRU may use a high priority type of LBT for ultra-high reliability type traffic. For high-capacity mobile broadband (eMBB) traffic, a WTRU may use a lower priority type. MTC traffic may be configured to use an even lower priority type than eMBB.

[0090] The LBT type may indicate, for example, whether the LBT is considered strict or lenient. For example, the LBT type may be configured with a shorter MCOT for transmissions at shorter time lengths to allow more WTRUs to access the channel. For example, the LBT type may be configured with an OCB equal to 99% of the BW, while another type of LBT may be configured with an OCB equal to the channel BW of the transmitted signal. For example, the OCB may be equal to the RB allocated for uplink transmissions in a given frequency range, but in one or more other frequency ranges, the OCB may be equal to 99% of the BW. The number of Idle Clear Channel Evaluation (CCA) slots may be counted to declare acquired channels. The number of CCA slots may be denoted as the number N. In the example, the Contention Window Size (CWS) may be denoted as CW, for example, and adjustments may be available. For example, a method or criterion may adapt the CWS based on the number of previous failed LBT procedures using the LBT configuration.

[0091] In another example, an LBT configuration may be associated with a cell, a BWP, e.g., a center frequency position and / or offset therefrom, a bandwidth, a TX or RX beam, a bandwidth, or a combination of these parameters. In such a case, a WTRU may be configured with an LBT configuration for at least one of the following: a component carrier (CC), a BWP, one or more PRBs at frequency and / or time relative to a given cell or carrier of the WTRU configuration, a transmit or receive beam or a group / set thereof, for example, a transmit or receive beam or a group / set thereof, a bandwidth used to access a channel, for example, a bandwidth, an access class of the WTRU configuration, a WTRU category and / or WTRU capability, a LCH (or LCG) and / or mapping constraints thereto, for example, a WTRU configuration may be configured to associate a “strict” LBT type with a broad beam.

[0092] A WTRU may receive at least one configuration or configuration association for at least one LBT configuration via system information (SI), for example, via the smallest SI in a physical broadcast channel (PBCH). At least one LBT configuration may be used by the WTRU to access the channel for at least initial access. Such an LBT configuration may also be used by the WTRU for fallback operation.

[0093] An LBT configuration can be associated with a specific transmit, transmit type, physical channel, or signal. Physical channels may include, among other things, control or data channels, shared channels, or dedicated channels. Physical channels may be licensed or unlicensed channels. For example, any of the following transmit types—namely, PUSCH transmit, PUCCH transmit, SRS transmit, or PRACH transmit—can be associated with one or more specific sets of LBT configurations. Similarly, an LBT configuration can be associated with data transmits, message and / or procedure types, or data and / or L1 / L2 / L3 procedure types, such as SR transmit, uplink control information (UCI) transmit, or random access transmit.

[0094] The content of a UCI transmission may also be associated with one or more different LBT configuration sets. For example, a UCI for HARQ may have a first set of LBT configurations, and a UCI for CSI reporting may have a second set of LBT configurations. Other UCIs, such as scheduling requests (SRs), may have different configurations than sounding reference signal (SRS) transmissions. In embodiments, different configuration sets may be used for different PUCCH formats, such as formats 1, 1a, 1b, 2, 2a, 3, 4, 5, etc.

[0095] A random access procedure and / or the transmission of a specific message may include the transmission of a PRACH and message 3 (msg3). Furthermore, one or more RA triggers may be associated with a set of LBT configurations. For example, an RA for beam recovery may have a first set of LBT configurations, an RA for paging response may have a second set of LBT configurations, and so on. For example, this may include a random access procedure configured with different priorities based on the association between LBT configurations and one (or more) values ​​or configuration parameters for power ramping steps and / or scaling factors for backoff. For example, an LBT configuration may be associated with a set of PRACH resources, in particular when the set of resources itself is associated with the priority. For example, this may include a set of PRACH resources associated with a set of LCH for SR purposes.

[0096] Data types such as data, wireless bearers, and logical channels can correspond to data with different QoS requirements, such as URLLC data, eMBB data, and control plane signaling. L1 / L2 / L3 procedures can correspond to L1, e.g., PRACH resource selection procedures; L2, e.g., random access or scheduling request procedures; or L3, e.g., RRC connection re-establishment procedures.

[0097] A WTRU may report LBT results to a gNB, TRP, another WTRU, etc. In some embodiments, a WTRU may be configured to perform an LBT and report any results of the procedure to a gNB. This may help the gNB address the hidden / exposed terminal problem. The reported results may be transmitted using a channel accessed after the configured LBT has been performed. The reported results may include, namely, the average energy detected within a pre-configured time, the number of slots / symbols the WTRU waited for to access the channel, and the type of radio access technology detected for exemplary WiFi / LAA. The gNB may schedule transmission resources for reporting, for example, via DCI.

[0098] The LBT procedure may be selected in whole or in part by the WTRU. A WTRU configured with multiple LBT configurations, each of which is associated with a set of parameters, may indicate or determine the appropriate LBT configuration to be used for UL transmission by the WTRU. The LBT configuration may be indicated by the network, and the indication may be quasi-static or dynamic. The indication may be achieved by at least one of the following: explicit indication from the gNB, timing, frequency, BWP switching commands received from the network, transmit and / or receive beam configuration from the network, beam bandwidth configuration provided by the network, RS ID, logical channel (LCH) of transmit, or waveform used for UL transmission. Other parameters may also be used.

[0099] In an example of explicit representation provided by a gNB, the network may use higher-order layer signaling to indicate to the WTRU one or more applicable LBT types to be used at one or more pre-configured times. For example, the WTRU may determine the LBT type to be used between RMSI and initial access. Alternatively, the network may use L1 / L2 signaling or a combination of higher-order layers and L1 / L2 signaling to indicate applicable LBT types. For example, the WTRU may receive a DCI along with a UL grant containing fields indicating the appropriate LBT configuration.

[0100] Using timing indicators, slots, subframes, and / or symbols during which transmissions take place may be associated with one or more specific LBT configurations. Frequency indicators that may have RB and / or BWP during which UL transmissions are guaranteed may be associated with one or more specific configurations.

[0101] BWP switching or switching commands may be received from the network, for example, from a gNB or TRP. For example, a WTRU may be configured to determine the LBT type based on the BWP frequency allocation size and / or the location of the BWP center frequency.

[0102] One or more transmit and / or receive beam configurations may be received from the network. For example, an LBT type may be associated with a set of transmit and / or receive beam indices. For example, a transmit beam identified as potentially interfering with other nodes may have a stricter LBT type. Beam configurations may be contradictory or of other types.

[0103] The beamwidth configuration can be received from the network. For example, if the probability of collisions occurring between WTRUs is low, such as multiple WTRUs using the same narrow beam, then a loose LBT type may be used for narrow beams.

[0104] In the embodiment, the UL grant may be associated with a CSI-RS ID or SRS-ID. The WTRU may determine the LBT configuration based on such ID. In the method, the WTRU may have a configured mapping between the CSI-RS configuration and the SRS configuration. This may allow the WTRU to determine the appropriate Rx beam on which the LBT should be performed, which may be associated with the Tx beam on which the transmission should be performed.

[0105] In the example, an LCH may be configured with one or more mapping constraints, each corresponding to a transmission requirement, and / or with an LBT configuration. One or more of the Broadcast Control Channel (BCCH), Paging Control Channel (PCCH), Common Control Channel (CCCH), Dedicated Control Channel (DCCH), or Dedicated Traffic Channel (DTCH) may each be configured with the same or different mapping constraints. For example, transmission may be configured with requirements (e.g., latency, reliability, coding rate). The set of requirements may determine the required LBT configuration. The waveform used for UL transmission may also be considered.

[0106] In some cases, a WTRU may have multiple LBT configurations applicable to one or more transmissions. For example, a WTRU may have an LBT configuration applicable to a specific slot, and another LBT configuration may be further indicated in the DCI that pre-authorizes UL resources within that slot. In such cases, there may be a priority order for the LBT indications. For example, dynamically, any LBT configuration indicated in the DCI may override a quasi-static LBT configuration. This can be useful when new data becomes available for higher-priority transmissions that may require looser and / or stricter versions of the LBT process to ensure that latency and / or reliability requirements are met, and / or transmissions with stricter transmission requirements with respect to latency supported by the quasi-statically configured LBT parameters (e.g., URLLC traffic).

[0107] In another embodiment, a WTRU may provide one or more sets of resources on which UL transmissions should be performed. Each resource in the set may be associated with a different LBT configuration. For example, a WTRU may have two sets of semi-persistent scheduling (SRS) resources on which it can perform transmissions. Each SRS resource may be associated with a different beam pair. Thus, a WTRU may have different LBT configurations associated with each SPS resource. In another example, a grant may provide two sets of resources on which UL transmissions should be performed, with each set associated with a different LBT configuration. This can be useful when eMBB data is given a lower-priority access class and a URLLC is configured with higher-priority access, each requiring different channel resources. The same may be true for lower-priority traffic, such as MTC traffic.

[0108] The LBT configuration may be selected by the WTRU, the gNB, or the TRP. The WTRU may select an LBT configuration when it has multiple LBT configurations applicable to transmissions on one or more sets of resources. The selection of an LBT configuration may be determined by at least one of the following: the transmission resource, the transmission priority, the LBT type used by the gNB, the LBT used in a previous transmission within the same channel occupancy time (COT), the LBT used in a previous transmission, the LBT required for the upcoming transmission, a previously failed LBT attempt, the UL carrier type, the WTRU's switch to the default BWP, timer expiration, or the use of multiple LBT configurations. A transmission resource may be a resource, for example, a symbol or subcarrier or BWP on which transmission is pre-authorized, which may be associated with an LBT configuration.

[0109] The transmission priority may refer to, for example, LCH or LCH priority, or the logical channel group (LCG) priority of a transmission may be used by the WTRU to determine the appropriate LBT configuration. Priority may be determined by ProSe Per-Packet.Priority (PPPP) or V2X type priority indicator. In another example, the procedure priority of a UL transmission, such as initial access, random access, UCI transmission, data transmission, SR, autonomous UL, or paging response, may be used by the WTRU to determine the appropriate LBT configuration.

[0110] The LBT type may be used by the gNB to transmit control and / or data channels. For example, the gNB may transmit a preamble before transmitting information over the control and / or data channels. In such a case, the WTRU may be configured with a table that maps a set of preambles to one or more LBT configurations. In other embodiments, the WTRU may be configured to determine the DL LBT to be used based on the CORESET and / or search space used to schedule the data. Alternatively, the gNB may use or include a field above or within the DCI to indicate the LBT type used by the gNB. In other embodiments, the WTRU may be configured to determine the DL LBT type based on the type of data received. Other implicit and explicit methods may also be applicable.

[0111] A LBT used for a previous transmission within the same Channel Occupancy Time (COT) may be considered for a subsequent transmission. For example, a WTRU may use an LBT configuration based on the LBT configuration used by the gNB for a previously performed DL transmission within the same Channel Occupancy Time. For instance, if the gNB acquires a channel using an LBT configuration with beam pairs, the WTRU may therefore simply reacquire the channel within the COT using an LBT configuration with the same beam pairs. In another example, the WTRU may have acquired a channel for a first transmission using a first LBT configuration. However, a second transmission, which may or may not be within the MCOT, may have different requirements and therefore not be covered by the first LBT configuration. In such a case, the WTRU may perform a second LBT using a second LBT configuration.

[0112] The LBT configuration used for a previous transmission of an LCH may provide indication of how to determine the LBT configuration that should be used for a future transmission of the same or a different LCH.

[0113] The LBT required for the next transmission can also be considered an indicator. For example, a WTRU may have data available for transmission, or another type of transmission, such as PUCCH, PRACH, SRS, or other UCIs, which may lead to two consecutive UL transmissions with different transmission requirements, such as reliability, latency, QoS, etc. To ensure that both transmissions can fit within the same channel occupancy time, the WTRU may select an LBT configuration that satisfies the requirements of both next transmissions.

[0114] Information regarding previously failed LBT attempts may be taken into consideration in future attempts. For example, the WTRU may attempt to acquire a channel using a first LBT configuration, and if this fails, it may then attempt to acquire a channel again using a second LBT configuration. The WTRU may determine the order of LBT configuration selection based on the parameters of the LBT configurations. For example, the WTRU may use the first LBT configuration based on the beam to which it is applicable, e.g., the best beam, and then the WTRU may proceed to the next LBT procedure based on a second best beam, and so on.

[0115] In the example, a standard UL carrier may be associated with a first LBT configuration, and an auxiliary UL carrier may be associated with a second LBT configuration. In such an example, the WTRU may determine the associated LBT configuration, for example, by determining the UL carrier type based on measurements.

[0116] A WTRU may consider switching to a default BWP. For example, after a failed transmission on the first BWP, the WTRU may switch to another BWP, such as the default BWP. The parameters of the LBT configuration used on the first BWP may or may not be applicable to the BWP.

[0117] Timer expiration may indicate an LBT type. For example, a WTRU may be configured to use a “loose” LBT type after a pre-configured timer expires. A WTRU may use a dedicated timer for changing the LBT type, or may be configured to use an existing timer, such as an RFL timer or a BFR timer.

[0118] In another embodiment, the WTRU may attempt to acquire channels using multiple LBT configurations. This may allow the WTRU to transmit the same TB over multiple channels to achieve diversity, in an embodiment. For example, the WTRU may receive a DCI that enables transmission over a set of UL resources. Each UL resource in the set may be associated with a different LBT configuration. The WTRU may initiate a first LBT using a first LBT configuration to transmit data over a first set of UL resources. In one embodiment, depending on whether the first transmission was successful or not, the WTRU may initiate a second LBT using a second LBT configuration to transmit data over a second set of UL resources.

[0119] A WTRU may be configured with multiple future switching points, where a DL (or UL) slot or symbol is followed by a UL (or DL) slot or symbol. In one embodiment, a WTRU may be given or indicated a pattern of UL / DL / undefined future slots. Furthermore, the pattern configuration may indicate LBT configurations that the WTRU can use in one, several, or any DL-to-UL switching. For example, an LBT configuration may be explicitly indicated for at least one DL-to-UL switching. In another example, the LBT configuration for a DL-to-UL switching may be implicitly determined by the WTRU. The WTRU may determine the LBT configuration based on at least one of the following: the duration of the gap provided for the DL-to-UL switching, the time since a previous DL-to-UL switching, the time since a specific LBT configuration was used, a beampair link switch, an LBT configuration used for a previous UL-to-DL switching, the content of a previous DL transmission, or a bandwidth portion switch.

[0120] For example, if the previous DL-to-UL switch occurred less than x symbols before the current DL-to-UL switch, the WTRU may use the first LBT configuration. If the previous switch occurred more than x symbols before the current DL-to-UL switch, the WTRU may use the second LBT configuration. The first and second LBT configurations may include one different parameter, several different parameters, or a complete set of different parameters.

[0121] The WTRU may determine when a specific LBT configuration was used. For example, the WTRU may perform a more stringent LBT, such as a full LBT requiring multiple idle CCAs for a UL transmission. A full LBT may be performed either before the first UL transmission or before a UL transmission after a DL-to-UL switchover. If a certain amount of time has elapsed since the last stringent LBT, the WTRU may need to perform such an LBT configuration for the DL-to-UL switchover.

[0122] A WTRU may receive beam pair link (BPL) switching indications or commands. For example, a first BPL may be used in a first UL transmission. The WTRU may be configured with UL-to-DL switching and subsequent DL-to-UL switching. If the WTRU reuses the first BPL for a second UL transmission, the WTRU may use the first LBT configuration. If the WTRU uses a second BPL for a second UL transmission, the WTRU may use the second LBT configuration. In another example, if the BPL used in the preceding DL transmission is the same as the one used for the subsequent UL transmission, the first LBT configuration may be used for the DL-to-UL switching. On the other hand, if the BPL used in the preceding DL transmission is different from the BPL used in the subsequent UL transmission, the second LBT configuration may be used. The first and second LBT configurations may include one different parameter, several different parameters, or a complete set of different parameters.

[0123] The WTRU may refer to the LBT configuration used for the previous UL-to-DL transition. The WTRU may be indicated by the network as the LBT configuration used for the previous DL transmission, for example, the DL transmission immediately preceding the DL-to-UL transition. Based on the network's LBT configuration, the WTRU may determine the appropriate LBT configuration for the DL-to-UL transition.

[0124] The WTRU may refer to the contents of previous DL transmissions to determine configuration information. The WTRU may determine the LBT configuration for the DL-to-UL switch based on the contents of the DL transmission immediately preceding the DL-to-UL switch.

[0125] A WTRU may be configured with BWP switching, or may be instructed to perform BWP switching. For example, a first BWP may be used in a first UL transmission. A WTRU may be configured to perform UL-to-DL switching and subsequent DL-to-UL switching. If the WTRU reuses the first BWP for a second UL transmission, it may use the first LBT configuration. If the WTRU uses a second BWP for a second UL transmission, it may use the second LBT configuration. In another example, if the BWP used in the preceding DL transmission is the same as the one used for the subsequent UL transmission, the first LBT configuration may be used for the DL-to-UL switching. On the other hand, if the BWP used in the preceding DL transmission is different from the BWP used in the subsequent UL transmission, the second LBT configuration may be used. The type of BWP switching may also affect the LBT configuration used. For example, the type of LBT performed by WTRU may depend on at least one of the following: whether the new BWP reuses the same center frequency, whether the new BWP reuses the same bandwidth, whether the new BWP overlaps with some or all of the previous BWP, or the number of PRBs separating the old and new BWPs.

[0126] In some embodiments, the WTRU may be configured using multiple switching points within the COT. In such cases, the WTRU may anticipate indicating, for example, the start, end, or duration of the COT if the COT is acquired by the network. The WTRU may be configured using specific LBT configurations to be used at some or all DL-to-UL switching points within the COT. The indication of the LBT configuration for each switching point may be explicit or implicit. Furthermore, the LBT configuration for DL-to-UL switching may depend on the total number of switching events in the COT, or on the index of the UL-to-DL switching. For example, for a first switching event, the WTRU may use a first LBT configuration. For a second switching event, the WTRU may use a second LBT configuration, and so on. The LBT configuration for DL-to-UL switching may also depend on the location of one or more DL-to-UL switching events within the COT.

[0127] The WTRU may determine the duration of the COT, the location of transmission within the COT, or the remaining duration of the COT based on the LBT configuration. In such cases, a new COT may be initiated based on the LBT configuration used at the switching point. For example, the WTRU may receive an indication that a new COT has started at time x and expect the COT to continue for at least time x + MCOT, where MCOT is the maximum COT. In embodiments, the indication may be received in the timer information element of the RRC signaling. However, at some point within that time period, the WTRU may be configured using the LBT configuration via the RRC or other signaling. If successful channel acquisition is determined based on the new configuration, the WTRU may assume that since the COT has resumed, the COT may continue for the duration of another MCOT.

[0128] LBT parameters within an LBT configuration may be adjusted by the network or by the WTRU. The WTRU may attempt to acquire a channel using a first LBT configuration. If the WTRU fails to acquire a channel, it may modify or update some parameters of the LBT configuration. Such updated parameters may be used by the WTRU for future attempts in channel access using the first LBT configuration. For example, the WTRU may be a pre-authorized UL resource associated with a first LBT configuration. The WTRU may attempt to acquire a channel and may fail. The WTRU may attempt to acquire a channel for the same pre-authorized resource again by first modifying some parameters of the LBT configuration and then retrying the LBT. The updated or modified parameters may be applicable to a second or further attempt to acquire a channel for the same transmission, or to future attempts to acquire a channel for a different transmission. If future attempts fail, the WTRU may revert to the original configuration. If another failure occurs, the WTRU may modify the parameters of the original configuration or the configuration that was modified once (or later). WTRU may report modified parameters to gNB or other TRPs.

[0129] In another example, the WTRU may receive an indication to update the parameters of the LBT configuration. The indication may be received via DCI, MAC CE, or RRC(re)configuration. For example, the WTRU may receive a DCI indicating that the number of CCA slots for the LBT configuration may be increased or decreased. The indication may be specific; for example, if the DCI indicates one or more parameters, the WTRU may implicitly determine that another parameter of the LBT configuration should be adjusted, modified, or changed together.

[0130] A channel may be monitored by a WTRU for multiple simultaneous LBT processes. In one embodiment, the WTRU may distinguish between a CCA process or trigger and an LBT process or trigger to initiate transmission. In one embodiment, without imposing any constraints on other embodiments herein, such as any LBT procedure described above, an LBT procedure may include two components that can be considered distinct from each other.

[0131] CCA can be performed by monitoring the channel to collect the status of the channel assessment. The first component may include monitoring whether the channel is accessible, including but not limited to the CCA, associated configuration, and the status of the CCA. Monitoring and measurement may take into account the recent state of the channel independently of the LBT procedure.

[0132] For example, the WTRU may monitor the presence of energy, and for example, it may perform measurements on the channel regardless of whether the LBT procedure has been initiated and / or is in progress. For example, the WTRU may continuously perform a CCA during a given period when it is not accessing the channel. The WTRU may store energy values ​​and / or measurement results observed to date. The periodicity of these observed / stored values ​​may, but is not limited to, all observed values, and / or the largest, average, and / or arithmetic mean values ​​associated with a configurable time interval, e.g., 1 μs. Some, but not all, observed values, but still more than one, may also be stored. In an embodiment, the WTRU may use a window-based mechanism to retain stored measurement results. These values ​​may be stored continuously or governed by a configurable time-limited timer. Using a window mechanism, the WTRU may maintain a timer for determining how long to retain stored measurement results. In another embodiment, the WTRU may maintain counters, e.g., a COT counter, a subframe counter, etc. WTRU can store information about recent channel states, as the measured amount may be required to perform CCA.

[0133] In one embodiment, the WTRU may monitor changes in at least one associated parameter, for example, a parameter of the WTRU's LBT configuration. For example, such a parameter may include one used to determine a threshold when performing a CCA evaluation. More generally, such a parameter may include at least one of the following: maximum energy per MHz as a function of a single carrier bandwidth (e.g., Tmax), maximum energy detection threshold in dBm units defined by regulatory requirements (e.g., XR), transmit type-dependent scaling parameters, such as timing advance (TA) and power headroom (PH), and one or more sets of maximum WTRU output powers measured in dBm units relative to the carrier, such as transmit power (PTX). Other parameters to be measured may include conducted power or power spectral density.

[0134] The WTRU may compare the received power to at least one threshold over a configurable time interval, e.g., 1 μs, and give the state of the channel over that time interval, for example, the state may be determined as either below or above the configured threshold. The WTRU may consider equal values ​​as either below or above. The comparison of the received power to the threshold may be determined in several ways, for example, using the maximum value, the average value over the interval, or the arithmetic mean.

[0135] The stored values ​​may be considered in relation to threshold states or observed values ​​and may be stored for a long time, for example, for channel statistics and channel selection purposes. The stored values ​​may be associated with, but are not limited to, the number and duration of possible LBT configurations, e.g., slot-based, loose, and / or strict durations. These values / states may also be monitored in a sliding window type manner to indicate CCA against the most recent historical duration, in embodiments. These values / states may be stored and governed by a configurable time-limited timer.

[0136] A WTRU may monitor the channel and perform CCA monitoring regardless of whether the WTRU should access the channel to perform a transmit. Given the CCA status, the WTRU may decide when to transmit, depending on the applicable LBT configuration for the transmit.

[0137] The second component may define or indicate how the resources of the medium are accessed, depending on the applicable LBT configuration within the LBT process. When LBT is triggered, the WTRU may determine the LBT configuration, derive a threshold / CCA amount, and then compare the threshold or amount to the channel's recent state.

[0138] When a WTRU initiates access to a channel, it may compare one or more configured LBT parameters applicable to transmissions, such as a threshold or CCA time length, with the current state of the CCA monitoring process. If the WTRU determines that the conditions for channel access are met using the LBT parameters applicable to transmissions and / or channel access, the WTRU may consider the LBT process to be successful. For example, in a CCA, the evaluation may be determined based on parameters relating to, or applicable to, stored measurements of the channel for a period of time immediately preceding the initiation of the LBT procedure.

[0139] Instead, if the WTRU determines that the LBT was not successful, the WTRU may continue the CCA process using the stored state until all access requirements for the LBT configuration are met. The WTRU may consider any point within the stored window of CCA measurement as the starting point for the CCA assessment associated with the LBT procedure, even if that temporal point occurred before the start of the LBT procedure. In this way, the window may be a sliding window determined based on a timer, the number of symbols, slots, etc.

[0140] If a WTRU has a first ongoing LBT procedure and has data associated with a different LBT configuration, or if a WTRU initiates a second LBT procedure using a different LBT configuration, the WTRU may use a configuration that allows for the earliest determination that the WTRU can access the channel, using stored channel state measurement results. The WTRU may also occupy the channel for a period determined by the LBT procedure that gives the longest COT.

[0141] If a transmission is configured under a given LBT configuration, and the CCA monitoring process indicates that the channel is available under different LBT configurations, such as different priority levels or different maximum occupancy times, the WTRU may choose to modify the transmission to satisfy the revised LBT requirements, either by transmitting without performing LBT or by transmitting with a revised LBT time length. The revised time length may be longer and preferably should not be shorter than the first determined COT.

[0142] A successful LBT indication may be transmitted without prior request. In one embodiment, the WTRU may have prior knowledge of possible LBT configurations and may determine whether the current state of the CCA monitoring process satisfies such a configuration without a channel access request. If the CCA process matches the configuration of the LBT process, the WTRU may be made aware of channel availability, where it can access additional channels without having to run the LBT process. The LAA process or procedure may be one implementation of such a mechanism. Additional availability of unlicensed spectrum may be used in offload scenarios.

[0143] A single CCA state may be shared by multiple LBT processes, each with a different configuration. For example, a WTRU may reset the state of the CCA monitoring process when at least one of the following events occurs: the WTRU determines that it can perform a transmission on the channel, or the WTRU uses the channel's resources to perform a transmission. For example, the state may be reset if the result of at least one (and any of) LBT processes is successful, or if multiple LBT processes can operate simultaneously. For example, whether a WTRU may (or is required to) perform channel monitoring for CCA outside of the time when it has at least one ongoing LBT procedure / process may be determined by a configurable aspect of the WTRU, for example, by L3 / RRC.

[0144] Methods for handling LBT procedures may or may not be applicable without the specific modeling constraints of the LBT procedure being described.

[0145] One or more methods may be used by a WTRU or network to handle LBT procedure failures. In one embodiment, a WTRU may attempt to acquire a channel using a first LBT configuration and may fail to do so. Such a failure may be determined after a certain length of time has elapsed since the start of the LBT procedure. In another method, a WTRU may determine that an LBT has failed if it is not able to acquire a channel within the time required to enable transmission in an allocated slot or symbol. For example, if a WTRU has multiple LBT configurations applicable to a transmission, and a first LBT configuration does not lead to channel acquisition, but a second LBT configuration is successful, the WTRU may or may not consider an LBT failure event for the first LBT configuration. Determining a failure may be based on time associated with the transmission priority or the priority of data being buffered for transmission.

[0146] For example, the LBT configuration may include a value corresponding to the maximum time before a transmission can be performed. A WTRU may start a timer when it initiates the LBT procedure, regardless of whether the WTRU initiates a new CCA process, for example. If the timer expires after the start of the LBT procedure but before the WTRU performs a transmission, the WTRU may determine that the LBT was unsuccessful.

[0147] A WTRU may report to the gNB an indication of a failed LBT procedure. The indication may or may not be reported along with the failed LBT configuration. The report may be made for the resources allocated to the WTRU for such reporting. The WTRU may use resources associated with the failed LBT configuration. A WTRU may only report an LBT failure if multiple failure events occur. For example, a WTRU may only report an LBT configuration failure if N failures occur within a time window.

[0148] A set of multiple LBT failures for one or more LBT configurations, for example, one or more LBT failures, may cause a WTRU to declare an RFL or BFR. A set of multiple LBT failures for one or more LBT configurations on an SCG cell may trigger an SCG notification by a WTRU. A failed LBT procedure leading to a missing transmission may also lead to a HARQ transmission failure. Thus, a WTRU may arrive at a HARQ failure decision based on a series of LBT configuration failures.

[0149] In embodiments, a WTRU may use multiple LBT configurations to perform multiple, for example, simultaneous LBT procedures. This may allow for a reduction in channel acquisition latency. For example, a WTRU may have a UL transmit and initiate a first LBT procedure using a first LBT configuration. The WTRU may then initiate a second LBT procedure simultaneously using a second LBT configuration, for example, before declaring the success or failure of the first LBT procedure. This may be effective if the WTRU may use either of two beampair links for the transmit and therefore may select the first LBT procedure on which the LBT procedure is successful. In another example, when a WTRU may be allocated two sets of resources in different BWPs, the WTRU may perform two LBT procedures (one per BWP) and select the one BWP on which the LBT result is successful for the transmit.

[0150] Initiating a second LBT procedure while a first LBT procedure is in progress may lead to drop-or-interruption-based considerations. In the example, a WTRU may initiate a first LBT procedure using the first LBT configuration for the first transmit. Before the first LBT procedure is completed, the WTRU may be indicated or determined that a second transmit requiring a second LBT configuration is needed. In some cases, the first LBT procedure may be valid for both transmits, and the WTRU may continue with the first LBT procedure and drop the second. In other cases, the first LBT procedure may not be valid for both transmits, but the second LBT procedure may be valid for both, and the WTRU may drop the first LBT procedure and continue with the second LBT procedure. In other cases, the WTRU may need to continue with both LBT procedures. The WTRU may be configured to allow the network to decide which procedures to drop one by one. The WTRU may be configured with a priority indicator or table that leads to a decision on which procedures remain valid.

[0151] The initiation of a second LBT procedure while the first LBT procedure is in progress may affect the progress status. In one way, a WTRU may determine that it should use an LBT configuration depending on one or more transmission requirements, such as the configuration that best satisfies the data latency, reliability, or signal-to-interference-to-noise ratio (SINR) requirements available for and / or for the transmission that triggered the LBT process. For example, a WTRU may determine whether it can be transmitted on a channel based on the CCA status, which depends on at least the channel access priority class of the data or signal that the WTRU is attempting to access the channel. For example, a WTRU may use an LBT configuration associated with the highest priority class of data available for transmission.

[0152] The WTRU may use the current CCA status, either accumulated from previously ongoing LBT processes and / or from CCA monitoring unrelated to ongoing LBT procedures, to perform an evaluation of whether the WTRU can transmit on the channel using the selected LBT configuration. If the WTRU determines that it cannot yet transmit on the channel, it may continue with the LBT procedures thereafter.

[0153] A WTRU may perform multiple simultaneous LBT procedures using multiple LBT configurations by employing a two-step method. In the first step, the WTRU may attempt a simplified version of each LBT procedure. If there is a successful simplified LBT procedure for at least one LBT configuration, the WTRU may attempt a full LBT procedure for that at least one LBT configuration. For example, a WTRU may be configured with two LBT configurations, one per beam pair. In the first step, the WTRU may attempt a simplified version of the LBT procedure for each beam pair. The WTRU may determine which beam pairs and associated LBT configurations should have a full LBT procedure performed on them. The WTRU may then perform a full LBT procedure on the associated LBT configurations.

[0154] A WTRU may execute multiple simultaneous LBT procedures using multiple LBT configurations. The WTRU may be able to adjust different parameters for each LBT configuration, and therefore multiple LBT processes may be fully overlapped. If an LBT process leads to a successful channel acquisition, the WTRU may terminate all ongoing LBT procedures and proceed with transmission. In other embodiments, the WTRU may continue executing any LBT procedures that remain unaffected by the transmission.

[0155] In some cases, the WTRU may not be able to fully superimpose the LBT process. For example, if two or more LBT configurations utilize different beams, the WTRU may only be able to perform directional LBT on a single beam within the CCA slot.

[0156] The WTRU may maintain multiple LBT processes and switch between them. In the first example, the WTRU may iterate through all LBT processes in each CCA slot. In such an example, the WTRU may run a CCA on the first slot for a first LBT process using a first LBT configuration, and then on the next slot, the WTRU may run a CCA for a second LBT process using a second LBT configuration, and so on, repeating for all LBT processes. The WTRU may drop all LBT processes when one of the processes is deemed successful in acquiring a channel.

[0157] In the example, the WTRU may run a CCA on the CCA slot for the first process until it is determined that the channel is busy by the slot. At that point, the WTRU may move on to the second LBT process and start a CCA using the second LBT configuration. Such iterations may allow for a variable deferral period for the LBT processes. If necessary, when returning to a previously started LBT process, the WTRU may maintain the updated free CCA slot in its counters. In such cases, the WTRU may maintain multiple CCA counters, one per LBT process. Alternatively, one or more counters corresponding to multiple LBT processes may be used.

[0158] Figure 3 is a state diagram 300 illustrating multiple LBT processes 302-306, each incrementing a single counter. In the example shown in Figure 3, the WTRU may start by utilizing process A302 and increment a single counter 308 until it is determined that a slot in process A302 is busy. Upon detecting a busy slot, the WTRU may run LBT on process B304 and continue incrementing the single counter 308 until another busy slot is detected. The WTRU may run LBT on process C306 and, accordingly, increment the single counter 308 again for each slot determined to be available. If a busy slot is detected during LBT process C306, the WTRU may run LBT again on another process, for example, process A302. At any point, if it is determined that the single counter 308 has reached a threshold, the WTRU may assume that the LBT process has been successful and may transmit accordingly.

[0159] Figure 4 is a state diagram 400 illustrating multiple LBT processes 402-406, each utilizing counters 408-412. In the example shown in Figure 4, the WTRU may start an LBT using process A302 and increment counter A408 until it determines that a slot in process A402 is busy. Upon detecting a busy slot, the WTRU may run an LBT on process B404 and increment counter B410 until it detects another busy slot. The WTRU may run an LBT using process C406 and increment counter C accordingly. If a busy slot is detected during LBT process C, the WTRU may run an LBT again on another process, such as process A402. At any point, if it is determined that the counter has reached a threshold, the WTRU may assume that the LBT process is successful and may transmit accordingly.

[0160] In embodiments, the WTRU may perform LBT for multiple LBT configurations using a common set or subset of parameters. For example, the WTRU may maintain a single CCA counter for all LBT configurations. The WTRU may perform CCA on a set of slots in a first LBT configuration. If the channel is busy after M CCA slots, the WTRU may switch to a second LBT configuration. The WTRU may start a CCA on a slot, and the counter will start from M. The WTRU may continue switching LBT configurations when it encounters the event of a busy CCA. The WTRU may declare channel acquisition when the overall counter reaches N.

[0161] In such embodiments, some LBT configurations may be substantially advantageous, assuming they may have fewer required idle CCA slots due to the prior slots being determined for other LBT configurations. Thus, the WTRU may change the order of LBT configurations for each of one or more subsequent LBT events. The WTRU may determine the order of LBT configurations randomly or by other means. In the example, the WTRU may determine the order based on repeating the LBT configurations for each LBT event. That is, in the first LBT event or procedure, LBT configuration A may come first, followed by LBT configuration B. In the second LBT event or procedure, LBT configuration B may come first, followed by LBT configuration B. The order of these procedures may vary from procedure to procedure. In the example, the WTRU may decide on an order based on the LBT configuration that acquired a channel in the last LBT event, for example, starting from the last LBT configuration and repeating all configurations.

[0162] Figures 5A and 5B illustrate an example of a channel acquisition method performed by a WTRU, where multiple simultaneous LBT procedures occur on two different BWPs of the carrier. In each figure, the BWPs are shown separately by frequency.

[0163] Figure 5A shows an example 500 in which each LBT process may maintain an independent CCA idle slot counter, each with its own unique configuration showing different BWPs 502, 504. The WTRU may attempt to determine whether the channel is busy in the first slot 506, or it may detect that the channel is idle. Since the channel is idle, the WTRU may set N=1. In the next slot 508, the WTRU may retry the CCA and reach the same conclusion. Thus, the WTRU may increment N to 2. Again, in the next slot 510, the WTRU may determine that the channel is idle and increment N again to N=3. In the next slot 512, the WTRU may determine that the slot is busy and may not increment N.

[0164] Next, when the WTRU encounters a busy CCA slot for the first LBT process on the first BWP 502, it may switch to a second LBT process on a different BWP 504. In such a case, the WTRU may, in one embodiment, maintain a counter for the first LBT process for a configurable length of time. The WTRU may start the second counter and increment the second counter to N=1 in the first idle slot 514 in the different BWP 504. The WTRU may also determine that the next slot 516 is idle and further increment the second counter to N=2. In the next slot 518, the WTRU may determine that the slot is busy and not increment either counter.

[0165] If the WTRU detects another busy slot 518 on a different BWP504, it may return to the first BWP502 and determine whether the next slot 520 is busy or idle. In this example, the WTRU detects the next slot 520 as idle and subsequently increments N to 4. The WTRU repeats the CCA for the next slot 522 and again increments N to 5. When N reaches 5, the WTRU decides to occupy the channel for COT524.

[0166] Figure 5B shows an example 530 in which two LBT processes, each with configurations showing different BWPs 532 and 534, can maintain a single CCA idle slot counter. In such a case, the WTRU may switch to the second LBT process when it encounters a busy slot on the first LBT process. The WTRU may update the counter used for the first LBT process during the second LBT process. In Figure 5B, the WTRU may attempt to determine whether the first slot 536 is idle, and if it determines that the first slot 536 is idle, the WTRU may increment the single idle slot counter to N=1. The WTRU may determine that the next two slots 538 and 540 are both idle, and on both occasions may it increment N by 1, resulting in N=2, then N=3. In the next slot 542, the WTRU may determine that the slot is busy and subsequently switch from BWP 532 to BWP 534. The WTRU may perform a CCA on the next slot 544 of a different BWP534 and determine that slot 544 is idle. The WTRU may again perform a CCA on the next slot 546 and again determine that slot 546 is idle. After detecting N=5 idle slots, the WTRU may determine the COT548 for transmission.

[0167] In some embodiments, the WTRU may be required to detect, before performing a transmission, at least one instance of a signal or transmission having specific characteristics and receiving power or quality exceeding a threshold. Such signals are referred to as “availability indicators” in the following embodiments.

[0168] Such embodiments may address the problem of LBTs failing to prevent collisions when beamforming is used. Availability signals may provide an indication of beam availability and may be transmitted from a TRP intended to be a receiving point for transmissions of a first WTRU. The TRP may be expected to transmit availability indications only during periods of time when it is not receiving ongoing transmissions from a second WTRU that would result in a collision. Even if the WTRU does not detect ongoing transmissions from the second WTRU, the first WTRU should not initiate a transmission without receiving one or more availability indications from the TRP.

[0169] In some embodiments, the availability indicator may include a signal similar to a synchronization signal or reference signal. Such a signal may be generated from a scrambled sequence with at least one specific parameter. The at least one parameter may consist of a higher-order layer and may be associated with a beam indicator or transmit configuration indicator (TCI) state. The WTRU may determine that the availability indicator has been received if the detected signal is received at a level above a threshold. Exemplary synchronization sequences may include gold sequences, pseudo-noise sequences, and the like.

[0170] In some embodiments, the availability indicator may include, consist of, or comprise a transmission carrying information bits encoded and modulated over a physical channel. A cyclic redundancy check (CRC) may be included. The WTRU may determine that the availability indicator has been received if decoding was successful. The information bits may include scheduling information, such as information identifying the resources for the WTRU or transmission.

[0171] An example of an availability indicator may preferably consist of one or a few OFDM symbols. For example, the time duration and frequency allocation with respect to the number of OFDM symbols may be fixed or may be composed of higher-order layers.

[0172] In some embodiments, the WTRU may attempt to receive instances of availability indications at one or more specific time opportunities. For example, such time opportunities may recur according to a period, such as one slot at a time, as shown in Figures 5A and 5B. A set of opportunities, such as a first symbol for one slot at a time, may be predetermined, or it may be composed of higher-order layers, for example, using parameters for duration and offset with respect to symbols and / or slots. Such a configuration may be specific to a beam or TCI state. In this case, the WTRU may attempt to receive availability indications for each configured beam using its specific configuration of availability indications.

[0173] Figure 6 illustrates a first slot 602 having seven OFDM symbols 608-620, a second slot 604 having seven OFDM symbols 622-634, and a third slot 606 having seven OFDM symbols 636-648. In the first symbol 608 of the first slot 602, the WTRU may monitor the availability indicator. The WTRU may also monitor the first symbol 622 of the second slot 604, and for subsequent availability indicators, it may monitor the first symbol 636 of the third slot 606. For other symbols, e.g., symbols 610-620, symbols 622-634, and symbols 638-648, the WTRU does not need to monitor the availability signal, which may save power. In some embodiments, there may be more or fewer symbols in a slot. In some embodiments, the availability indicator may be provided in an alternative symbol. In some embodiments, the availability indicator may not be provided together. In this embodiment, the availability indicator may be present on any one of the seven symbols in the slot.

[0174] A WTRU may determine that the channel is available for transmission after receiving a certain number of availability indicators. This number may be determined from a contention window in a manner similar to existing LBT embodiments or other embodiments, and may depend on the priority level, traffic type, etc., associated with one or more transmissions. The WTRU may then initiate transmission after a certain delay following the reception of the last received availability indicator. Such a delay may be fixed or constitute a higher layer. Such a delay may depend on the priority level associated with the transmission.

[0175] In some embodiments, the WTRU may perform a transmission using only beams for which a beam mapping has been established, using the TCI state used for receiving that beam or availability indication. In other embodiments, the transmission may include beams for which a mapping has been established, or other selected beams.

[0176] In some embodiments, a WTRU may determine that a channel is available for transmission only if it determines that the channel was “not busy” for a certain number of time opportunities. In such embodiments, a channel may be determined to be “not busy” for a time opportunity if at least one of the following conditions is met: an availability indication is received during the time opportunity or part thereof; and at least one other criterion used to determine that a channel is “not busy,” as used in existing LBT embodiments, is met over the time opportunity or part thereof.

[0177] When assessing at least one other criterion, the WTRU may subtract energy from the availability indication before making a decision. For example, if at least one other criterion consists of, or comprises, determining whether energy exceeding a threshold is detected, the WTRU may consider only energy not received from the availability indication. Alternatively, the WTRU may assess at least one other criterion over time symbols of time opportunities in which it is not possible to map the availability indication.

[0178] An NR-gNB may perform a LBT procedure for the transmission of periodic CSI-RS associated with one or more serving beams for a resource associated with an unlicensed NR cell. In such cases, the NR-gNB may not transmit such CSI-RS if it determines that the channel is occupied for the beam in question. This can impair the WTRU's ability to perform beam fault detection. The WTRU cannot determine whether the failure to receive the CSI-RS associated with one of its beams may be caused by the interruption of the beam in question, or by a discontinuity, such as a discontinuous transmission (DTX) in the transmission from the NR-gNB following the LBT for the beam in question.

[0179] If the WTRU determines that a CSI-RS associated with a sustained beam was not transmitted because the channel is occupied, the MAC entity may not increment the BFI counter, but may further reset or increment the BFD timer by a single unit within the range of its configured values.

[0180] The WTRU may determine that no CSI-RS was transmitted for a given beam based on measuring interference and noise on the channel associated with the beam, measuring interference and noise on the channel associated with the beam, and CSI-RS, as well as indications received from the gNB or non-serving gNB.

[0181] Interference and noise on the channel associated with the beam can be measured. If the noise level exceeds a certain threshold, the WTRU may determine that the associated CSI-RS was not transmitted.

[0182] Interference and noise on the channel associated with the beam, as well as CSI-RS, can be measured. If the noise level exceeds a configured threshold and the CSI-RS quality measure is below another configured threshold, the WTRU may determine that the associated CSI-RS was not transmitted. An example of this is shown in Figure 7.

[0183] Figure 7 illustrates a method for incrementing the BFI counter 706. The illustration 700 includes a y-axis representing the measured power 702 and an x-axis representing time (t) 704 in a series of RS periods 710–736. The WTRU may be measured by receiving the CSI-RS power 740 in the first RS period 710. Since the CSI-RS 740 exceeds the CSI-RS threshold 752, the BFI counter 706 is not incremented at the end of RS period 710. The same may be true in the second RS period 712. In the third period 714, the power of the CSI-RS 740 may have decreased, but the noise + interference 742 has increased. In this case, the WTRU may still not increment the BFI counter 706 at the end of RS period 714, because the WTRU can attribute the loss of CSI-RS 740 power associated with the noise + interference 742 occurring in RS period 714 to the network not acquiring a channel for transmitting CSI-RS 740. The WTRU may reach the same conclusion in RS period 716 and therefore may not increment the BFI counter 706. In the next RS period 718, the CSI-RS power 740 may be higher, but the noise + interference 742 may be lower. Again, the WTRU may not increment the BFI counter 706 at the end of RS period 718, assuming that the CSI-RS power 740 exceeds the threshold 752. In RS period 720, the CSI-RS 740 power may be high, but the noise + interference 742 is low. Incrementing the BFI counter 706 may not be performed. During RS period 722, both CSI-RS740 and noise + interference 742 may be detected at a low level or not detected at all. In this case, the WTRU may increment the BFI counter 706 to 1 at the end of RS period 722. The BFD timer 708 may be activated. During the next RS period 724, CSI-RS740 and noise + interference 742 may again be detected at a low level, and the BFI counter may be incremented again at the end of RS period 724.The BFD timer 708 may be restarted by the incrementing of the BFI counter. In the next RS period 726, the WTRU may detect a CSI-RS 740 that exceeds the threshold and therefore may not increment the BFI counter 706. The WTRU may decrement the BFD timer 708, assuming it is active and the BFI counter was not incremented. The same may be true in RS periods 728 and 730. In RS period 732, the CSI-RS 740 may rise but may not rise above the threshold 752. Therefore, the UE may assume that the CSI-RS was not transmitted by the gNB and may not decrement the BFD timer 708, even if it is active. Similar to RS period 724, the WTRU may increment the BFI counter 706 and restart the BFI timer 708 in RS periods 732, 734, and 736. The purpose of the BFI counter 708 in this operation is to restart the BFI counter 706 when a sufficient amount of time has elapsed since the last beam fault event. Therefore, it is preferable not to restart the BFI counter 706 if the CSI-RS740 was not transmitted because the gNB did not acquire a channel. Instead, the BFD timer 708 may be suspended when the WTRU assumes that the CSI-RS740 was not transmitted. Otherwise, low channel availability would lead the WTRU to restart the BFI counter 706, even if the WTRU does not have an indication that the beam is no longer faulty.

[0184] An indication of whether a channel has been acquired from the TRP may be provided to the WTRU by the serving gNB or a non-serving gNB. The WTRU may determine that the serving gNB was not able to occupy the channel if a certain reservation signal or resource was not transmitted by the serving gNB and / or was transmitted by another neighboring gNB. Such a signal may, in embodiments, be in the form of a preamble encoded with the cell's physical ID, or it may be part of control signaling.

[0185] A CSI-RS associated with a given beam may include an index. This index can be used by the WTRU to determine whether it truly failed to detect a previous SSB / dedicated reference signal (DRS) transmission, or whether it was never transmitted at all. Thus, the WTRU may retrospectively adjust its counter based on the reception of CSI-RS over future periods.

[0186] In high-load scenarios on NR-U cells, persistent interference can lead to prolonged periods where the BFI counter remains unchanged, for example, not incremented. Depending on this duration, the WTRU may lose synchronization and even lose established beam pairs. To mitigate such scenarios, the WTRU may additionally maintain a "beam probability timer," which is reset each time the WTRU detects a CSI-RS transmission from the serving cell. Expiration of such a timer can trigger a BFR request in the WTRU. The same handling can be achieved using a "beam establishment counter" instead of a timer.

[0187] In addition to illustrating how the BFI counter may be incremented, Figure 7 shows an example where the beam fault detection procedure is modified for cases where RS is not transmitted due to the channel being busy. For example, during RS period 714, the WTRU may determine that it may detect a large amount of interference 742, even though it may not detect CSI-RS740, and therefore assume that CSI-RS740 was not transmitted during this RS period 714. Consequently, the WTRU may not increment its BFI counter 706 and may not trigger the BFD timer 708. On the other hand, if the timer has already been triggered, but the WTRU determines that CSI-RS740 may not have been transmitted due to a large amount of interference, as in RS period 730, which is the 11th RS period in Figure 7, the WTRU does not need to decrement the BFD timer 708 or increment the BFI counter 706.

[0188] A beam may be managed and detected for one or more aperiodic DRS transmissions. A WTRU does not have to be configured to anticipate periodic DRS / CSI-RS transmissions. For example, a WTRU may be configured to receive aperiodic DRS if an unlicensed channel is experiencing high occupancy. Providing periodic CSI-RS under high channel occupancy conditions can be difficult, especially if the gNB needs to transmit CSI-RS for multiple beams for different WTRUs, as such RS may receive LBT. Assuming nominal bandwidth occupancy requirements, a DRS transmission may occupy the nominal bandwidth regardless of the number of RS resources required.

[0189] A WTRU may be configured to measure DRS or CSI-RS irregularly. The WTRU may be notified by the gNB to measure and report the DRS or CSI-RS being measured. Upon receiving a DRS indication from the gNB, the WTRU may measure the corresponding RS, possibly within the same MCOT. The WTRU may further report CSI-RS measurements within the same MCOT or at a later time using periodic reporting on PUSCH.

[0190] When the WTRU is not configured to periodically monitor and measure CSI-RS, the WTRU may perform coordinated beam fault detection procedures. The WTRU may reset the BFI counter upon the expiration of the BFD timer. The WTRU considers the BFD timer units to be measured in absolute time and / or the number of non-periodic CSI-RS occurrences. Alternatively, the WTRU may rely solely on reporting the measured CSI-RS to the gNB without sending any BFR requests.

[0191] A WTRU may be configured with the ability to request the transmission of a DRS transmission by a gNB. Such a request may be conditional, for example, on the HARQ operating point or the number of determined NACKs. The WTRU may transmit such a request using an autonomous uplink transmission (AUL) transmission, using a scheduled transmission on a PCell or SCell PUSCH, or using a PUCCH transmission. The WTRU may provide additional information, such as beam identification information or multiple beam selections. After providing the indication, the WTRU may further anticipate the corresponding DRS or CSI-RS transmission. For example, if the uplink transmission used for such an indication allows uplink-to-downlink transmission within the MCOT using an intermediate short LBT, the WTRU may anticipate the corresponding CSI-RS transmission after providing the indication. Alternatively, a delay may be configured.

[0192] For unlicensed NR cells, beam fault recovery may be reported. Depending on the NR-U deployment, the WTRU may or may not be permitted to perform RA procedures on unlicensed NR cells. In NR-U deployments where the NR gNB is a SCell in the unlicensed spectrum and the PCell is in the licensed spectrum, the WTRU may not be permitted to initiate RACH or PUCCH on the NR-U SCell. In NR-U deployments where the NR-gNB is operating in the unlicensed spectrum in a standalone deployment, the WTRU may be able to initiate RA procedures on the NR-gNB to report BFR requests. The nature of RA procedures on a standalone NR-U may differ from normal RA procedures in the licensed spectrum.

[0193] WTRU may use PUSCH to report a BFR request when the deployment configuration does not allow the RA procedure to be initiated on, for example, an NR-U SCell.

[0194] A WTRU may report a BFR request using an AUL. A WTRU may implicitly or explicitly provide an indication of a suggested downlink beam or one or more SSBs within a portion of the AUL PUSCH transmission. The suggested downlink beam may be based on the nature of the PUSCH transmission or the selected PUSCH resource / channel. For example, a network may construct a WTRU using a set of timing offsets associated with several downlink beams. The suggested downlink beam may also be inferred from the AUL transmission itself. Alternatively, MAC CE may provide a best downlink beam or beam selection, possibly accompanied by associated measurements.

[0195] After sending a BFR request over PUSCH, the WTRU may monitor the PDCCH on the control resource set configured for BFR using the BFR core set. Since the BFR response from the gNB may also depend on the performance of the LBT procedure, the WTRU may attempt to decode the PDCCH on the suggested downlink beam after a short LBT time length within the MCOT.

[0196] A WTRU may determine that a BFR request was not successfully received if it fails to decode the PDCCH due to the expiration of the Beam-failure-recovery-request-window. If a WTRU consists of one or more Beam-failure-recovery-request-windows, for example, across multiple non-contiguous slots, the WTRU may determine that a BFR request was not successfully received due to the expiration of the last BFR request window.

[0197] As long as the RA is configured on an NR-U cell, the WTRU may report a BFR request by initiating the RA procedure on the NR-U cell where the BFR was detected. Such a procedure may be a four-step or two-step RA procedure. If a two-step RA procedure is initiated for a BFR, the WTRU may include the best downlink beam ID portion of the msg1 transmission. The WTRU may also include the number of selected downlink beams, along with the associated measurement results, as long as the allocated size of data on msg1 in the two-step RA procedure is sufficient.

[0198] Figure 8 is a flowchart illustrating an exemplary method for switching LBT configurations (800). A WTRU may receive an LBT configuration associated with one or more of the following: beam, BWP, LCH, set of LBT parameters, transmit type, or LBT subband (802). The WTRU may receive an indication, for example via DCI, to transmit using a first LBT configuration (804), and may attempt to acquire a channel using the first LBT configuration (806). If the attempt to acquire a channel is successful (808), the WTRU may transmit data on the channel (810). If unsuccessful, the WTRU may attempt to acquire a channel using a second LBT configuration (812). If the second attempt is successful (814), the WTRU may transmit data on the channel (816). If unsuccessful, the WTRU may revert to the first LBT configuration (818). Alternatively, or in combination, the WTRU may attempt to acquire a channel using two LBT configurations simultaneously.

[0199] While features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. The methods described herein may be implemented in computer programs, software, or firmware incorporated into computer-readable media for execution by a computer or processor. Examples of computer-readable media include electrical signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media, but not limited to, include ROM, 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 discs and DVDs. A processor associated with the software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a wireless transceiver unit (WTRU) comprising an initial bandwidth portion (BWP) and a second BWP, It operates in the second BWP described above, The WTRU determines that it cannot acquire a channel in the second BWP in time to enable transmission in multiple symbols, and that the attempt to acquire the channel in the second BWP is based on the WTRU performing a listen-before-talk (LBT) procedure in the second BWP. Based on the failure of one or more LBT procedures performed in the second BWP, the system switches to operating in the initial BWP. The WTRU determines that it cannot acquire the channel in the initial BWP, and that the attempt to acquire the channel in the initial BWP is based on the LBT procedure in the initial BWP. Triggering a radio link failure (RLF) based on the failure of one or more LBT procedures in the initial BWP, A method for providing this.

2. The method of claim 1, further comprising sending a notification that the initial BWP is unavailable.

3. The method of claim 2, wherein the notification is transmitted to at least one of a base station, a transmitting / receiving point (TRP), or another WTRU.

4. The method of claim 1, wherein the initial BWP is associated with a first logical channel (LCH).

5. The method of claim 1, wherein the second BWP is associated with the second LCH.

6. The method of claim 1, wherein the plurality of symbols are based on the contention window (CW) size.

7. The method of claim 1, further comprising triggering the RLF by exceeding a threshold associated with the total elapsed time since the failure of one or more LBT procedures.

8. A wireless transceiver unit (WTRU) comprising an initial bandwidth portion (BWP) and a second BWP, wherein the WTRU is Transceiver and, Processor and Equipped with, The transceiver and the processor are It operates in the second BWP described above, The WTRU determines that it cannot acquire a channel in the second BWP in time to enable transmission in multiple symbols, and that the attempt to acquire the channel in the second BWP is based on the WTRU performing a listen-before-talk (LBT) procedure in the second BWP. Based on the failure of one or more LBT procedures performed in the second BWP, the system switches to operating in the initial BWP. The WTRU determines that it cannot acquire the channel in the initial BWP, and that the attempt to acquire the channel in the initial BWP is based on the LBT procedure in the initial BWP. Triggering a radio link failure (RLF) based on the failure of one or more LBT procedures in the initial BWP, A WTRU configured to perform the following actions.

9. The WTRU of claim 8, further configured to transmit a notification that the initial BWP is unavailable, wherein the transceiver and the processor are configured to transmit a notification that the initial BWP is unavailable.

10. The WTRU of claim 9, wherein the notification is transmitted to at least one of a base station, a transmitting / receiving point (TRP), or another WTRU.

11. The WTRU of claim 8, wherein the initial BWP is associated with a first logical channel (LCH).

12. The WTRU of claim 8, wherein the second BWP is associated with the second LCH.

13. The plurality of symbols are based on the contention window (CW) size, according to claim 8.

14. The WTRU of claim 8, further comprising triggering the RLF by exceeding a threshold associated with the total elapsed time since the failure of one or more LBT procedures.

Images