RU2776135C2 - Channel access procedures for directional systems in unlicensed bands - Google Patents

Abstract

FIELD: communication.

SUBSTANCE: invention relates to means for reservation of a directional channel. A directional request to send (DRTS) message is received from a transmitting node. A directional clear to send (hereinafter – DCTS) message is transmitted using one or more first beams, wherein at least one first beam is directed in the first direction to the transmitting node. The second direction is determined, while the second direction is a direction different from the first direction. At least one additional DCTS message is transmitted using one or more second beams, wherein at least one second beam is directed in the second direction to a potentially interfering node. Data is received from the transmitting node. Following one or more additional DCTS messages are periodically transmitted in at least second direction within maximum channel occupancy time (MCOT) during the reception of data from the transmitting node.

EFFECT: possibility of shared use of an unlicensed spectrum by users.

25 cl, 51 dwg, 8 tbl

Description

Cross-references to related applications

This application is an ordinary application and, pursuant to 35 U.S.C. §119(e), claims benefit in respect of U.S. Provisional Application No. 62/574,548, filed October 19, 2017, entitled "Channel Access for Directional Systems In Unlicensed Bands" and U.S. Provisional Application No. 62/689,046, filed June 22, 2018, entitled "Channel Access Procedures For Directional Systems In Unlicensed Bands", each of which is hereby incorporated by reference in its entirety.

Prerequisites for the creation of the invention

Wireless communication may be required to support application requirements. Application requirements may vary. For example, the application may need low latency and may be resistant to delays. Some applications may require high reliability. The application may include advanced mobile broadband (eMBB), machine to machine communication (MTC), mass MTC (mMTC), and/or ultra-reliable low latency communication (URLLC). Applications may be useful in industry (eg, automotive, healthcare, agriculture, utilities, and/or logistics).

Wireless communication systems may be deployed using licensed and/or unlicensed spectrum. Unlicensed spectrum may be used for non-cellular services and/or other applications (eg Wi-Fi). Cellular operators may consider unlicensed spectrum as an additional tool. For example, unlicensed spectrum can complement the service offerings of a mobile operator as it satisfies a large demand for broadband data. When using unlicensed spectrum, there may be additional restrictions on the use of the spectrum, due, for example, to the possibility of users sharing the unlicensed spectrum. Users can interfere with each other.

Statement of the Invention

The present documents describe methods and systems for directional channel reservation in the presence of potentially interfering node(s), such as, for example, in unlicensed spectrum.

According to some embodiments, a method performed by a receiving node to reserve a directional channel includes: receiving a Directed Channel Transmission Request (DRTS) message from a transmitting node; transmitting a Directed Channel Ready to Send (DCTS) message using one or more first beams, wherein at least one first beam is directed in a first direction toward the transmitting node; determining a second direction, wherein the second direction is a direction different from the first direction; and transmitting at least one additional DCTS message using one or more second beams, wherein at least one second beam is directed in a second direction towards the potentially interfering node. In such a method, the receiving node may be a wireless transmit/receive module and the transmitting node may be a base station. In addition, the method may be performed by the receiving node to reserve a directional channel in the unlicensed spectrum.

In one example, the second direction may be determined based on information from a listen-before-transmission (LBT) analysis of the directed channel. In another example, the DRTS message may contain an indication of a second direction, and the second direction may be determined based on the indication in the DRTS message. In yet another example, the second direction may be determined based on directional channel measurements.

In some embodiments, the DRTS message is an enhanced DRTS message (eDRTS) and the DCTS message is an enhanced DCTS message (eDCTS). In one example, the second direction may be determined based on the eDRTS message. In some embodiments, the at least one additional DCTS message is further an enhanced DCTS-to-self (eDCTS-to-Self) message. The DCTS message sent towards the transmitting node may indicate the number of transmissions of the eDCTS-to-Self message performed by the receiving node.

In some embodiments, at least one additional DCTS message includes a backoff duration field that specifies the amount of time to delay transmission. In some embodiments, at least one additional DCTS message indicates the remaining time for which the directed channel is reserved. In this at least one DCTS message, the remaining time from the Maximum Channel Busy Time (MCOT) may be included.

In some embodiments, the at least one additional DCTS message includes a plurality of enhanced DCTS messages (eDCTS). In one example, a given at least one additional DCTS message may be transmitted multiple times within a Maximum Channel Busy Time (MCOT). In some embodiments, the implementation of the method further includes: receiving data from the transmitting node; and periodically transmitting subsequent one or more additional DCTS messages in at least a second direction within the MCOT in the course of receiving data from the transmitting node. Further, in some embodiments, transmitting the at least one additional DCTS message using one or more second beams includes transmitting the at least one additional DCTS message on other beams.

In some other embodiments, the method further includes: receiving a second DRTS message from the transmitting node; and transmitting a directional channel transmission reject (DDTS) message to the transmitting node in response to the second DRTS message when the receiving node detects potential directional interference. The DDTS message may be an enhanced DDTS message (eDDTS), and the eDDTS message may identify the node that is transmitting the interfering signal.

In some embodiments, the number of at least one additional DCTS message transmitted is based on at least one of (i) the number of potentially interfering nodes, (ii) the power of one or more second beams, and (iii) the width of one or more second beams. The content of each of the DRTS messages, DCTS, and at least one additional DCTS message may be scrambled using a sequence that is common to the cell group. In one example, the content of each of the DRTS messages, DCTS, and at least one additional DCTS message may be scrambled using a Cell Group Sequence (CGS) that is common to a group of cells.

In still other embodiments, the method further includes: performing a first directional listen-before-transmit (LBT) analysis toward another node to which the transmission is from the receiving node, the other node being different from the transmitting node; determining whether a channel between the receiving node and another node is busy based on performing a first directional LBT analysis; performing a second backward directed LBT analysis; and determining if an interfering signal is detected from the reverse direction, such that either the transmission continues to the other node or the transmission is delayed when an interfering signal is detected.

According to some embodiments, another method performed by a receiving node to reserve a directed channel includes: receiving an improved directed send request message from a transmitting node; transmitting an improved acknowledgment message over a directed channel using one or more first beams, wherein at least one first beam is directed in a first direction towards the transmitting node; and transmitting at least one further improved acknowledgment message on a steered channel using one or more second beams, wherein at least one second beam is directed in a second direction towards the potentially interfering node, the second direction being different from the first direction. In some embodiments, the method is further performed by the receiving node to reserve a directional channel in the unlicensed spectrum.

Other embodiments include a wireless transmit/receive module, a system, and a receiving node configured (eg, having a processor and a physical computer-readable medium storing instructions for execution by the processor) capable of performing the methods described herein.

Brief description of graphic materials

In FIG. 1A is a system diagram illustrating an example of a communications system in which one or more of the described embodiments may be implemented.

In FIG. 1B is a system diagram illustrating an example of a wireless transmit/receive unit (WTRU) that may be used in the communication system shown in FIG. 1A according to an embodiment.

In FIG. 1C is a system diagram illustrating an example of a radio access network (RAN) and an example of a core network (CN) that may be used in the communication system shown in FIG. 1A according to an embodiment.

In FIG. 1D is a system diagram illustrating a further example of a RAN and a further example of a CN that may be used in the communication system shown in FIG. 1A according to an embodiment.

In FIG. 2A shows an example of interference in beam-based systems using direction-based listen-before-transmit (LBT) with New Radio (NR) and WiGig (Wireless Gigabit Alliance) co-operation.

In FIG. 2B shows an example of interference in beam-based systems using direction-based listen-before-transmit (LBT) procedures in cooperative NR-NR.

In FIG. 3A shows an example of carrier sensing in LBT with interference from an access point (AP) received at a user equipment (UE).

In FIG. 3B shows an example of carrier sensing in LBT with gNB interference at the station (STA) and/or AP at the UE.

In FIG. 4A shows an example of carrier sensing in LBT with interference from an access point (AP) received on a gNB.

In FIG. 4B shows an example of carrier sensing in LBT with interference from UEs received at STA and/or from APs at gNB.

In FIG. 5 shows an exemplary interference scenario for eDRTS, eDCTS, and multiple eDCTS-to-Self procedure for withstanding interferers, in accordance with some embodiments.

In FIG. 6 shows an example of creating a period and/or a protection area, in accordance with some embodiments.

In FIG. 7 shows an example of a downlink/uplink (DL/UL) switching configuration in accordance with some embodiments.

In FIG. 8 is a flowchart illustrating an example of a transmission procedure in accordance with some embodiments.

In FIG. 9 shows an example DL/UL switching configuration for an NR-WiGig coexistence scenario, in accordance with some embodiments.

In FIG. 10 shows an example forward and/or reverse link beam coverage for an NR-WiGig cooperative non-interfering operation scenario, in accordance with some embodiments.

In FIG. 11 shows another example of a DL/UL switching configuration for an NR-WiGig coexistence scenario, in accordance with some embodiments.

In FIG. 12 shows an example forward and/or reverse link beam coverage for a UE AP interference scenario in NR-WiGig co-operation in accordance with some embodiments.

In FIG. 13 shows an example DL/UL switching configuration for an NR-WiGig co-operation scenario using higher power and multiple mini-slot backup transmissions to endure WiGig devices, in accordance with some embodiments.

In FIG. 14 shows an example forward and/or reverse link beam coverage for an NR-WiGig co-operation interference scenario in accordance with some embodiments.

In FIG. 15A shows an example of paired listening before transmission (LBT) in one opposite direction, in accordance with some embodiments.

In FIG. 15B shows an example of a paired LBT in multiple opposite directions, in accordance with some embodiments.

In FIG. 16 shows an example of the beam optimization effect used at a transmitting node for LBT in one opposite direction, in accordance with some embodiments.

In FIG. 17A shows an example of the effect of increasing the energy detection (ED) threshold for LBT in one opposite direction with an optimized beam shape, in accordance with some embodiments.

In FIG. 17B shows an example of the effect of increasing the ED threshold for LBT in multiple opposite directions with predefined beams, in accordance with some embodiments.

In FIG. 18 is an example flowchart for correcting parameters associated with LBT in the opposite direction(s), in accordance with some embodiments.

In FIG. 19 is an exemplary block diagram for dynamic parameter correction for LBT in the opposite direction(s), in accordance with some embodiments.

In FIG. 20 is an exemplary flowchart for correcting a transmission strategy based on LBT in the opposite direction(s), in accordance with some embodiments.

In FIG. 21 is an example block diagram associated with a multiple ED threshold implementation in accordance with some embodiments.

In FIG. 22 shows an example of using an angle-of-arrival estimate and an LBT ED threshold change in the opposite direction, in accordance with some embodiments.

In FIG. 23 is an example flowchart illustrating LBT service from a receiving node, in accordance with some embodiments.

In FIG. 24 shows an example of LBT beamwidth correction in the opposite direction, in accordance with some embodiments.

In FIG. 25A shows an example of blocking of nodes with different radio access technologies (RAT) based on LBT in accordance with some embodiments.

In FIG. 25B shows an example of blocking nodes with the same RAT based on LBT, in accordance with some embodiments.

In FIG. 26 shows an example LBT coordination scenario in accordance with some embodiments.

In FIG. 27A shows an example of LBT coordination in the frequency domain, in accordance with some embodiments.

In FIG. 27B shows an example of LBT coordination in the time domain, in accordance with some embodiments.

In FIG. 28A shows an example of omnidirectional LBT behavior in accordance with some embodiments.

In FIG. 28B shows an example of steered LBT behavior for steered transmissions/receptions, in accordance with some embodiments.

In FIG. 29 shows a procedure for ultra-secure omnidirectional LBT detection, in accordance with some embodiments.

In FIG. 30A and 30B show examples of contention window size (CWS) adaptations in multi-cell scenarios, in accordance with some embodiments.

In FIG. 31 shows an example of downlink data transmission with eDCTS-to-Self transmission in accordance with some embodiments.

In FIG. 32 shows another example of downlink data transmission with both eDCTS-to-Self and uplink transmission in accordance with some embodiments.

In FIG. 33 shows an example of eDRTS, eDCTS, and eDCTS-to-Self transmission in accordance with some embodiments.

In FIG. 34 shows an example of UE behavior with a non-target UE after receiving eDRTS and eDCTS from another cell, in accordance with some embodiments.

In FIG. 35 shows an example scenario including directed RTS/CTS when NR-U co-operating with NR-U in the presence of interfering nodes.

In FIG. 36 is a flowchart illustrating a steered channel reservation method in accordance with some embodiments.

In FIG. 37 is a flowchart illustrating another steered channel reservation method in accordance with some embodiments.

In FIG. 38 shows an example of a series of transmissions, including eDRTS and eDCTS-to-Self transmissions, in accordance with some embodiments.

In FIG. 39 shows an exemplary interference scenario for eDRTS, eDCTS, and multiple eDCTS-to-Self when NR-U with NR-U is operated in accordance with some embodiments.

The objects, connections, arrangements, and the like depicted in and in connection with the various figures are by way of example and not limitation. In this regard, any and all statements or other indications regarding what is depicted in a particular figure, what constitutes or has a particular element or object in a particular figure, as well as any and all such statements that, out of context or out of context, can be understood as immutable, and therefore limiting, can only be properly construed when preceded by a phrase such as "In at least some embodiments...". For brevity and clarity, this implied introductory phrase is not repeated throughout the detailed description of the drawings.

Detailed description

The following is a detailed description of illustrative embodiments with reference to various figures. Although the present description provides detailed examples of possible implementation options, it should be noted that this detailed description is given as an example and in no way limits the scope of the application.

In FIG. 1A is a diagram illustrating an example of a communications system 100 in which one or more of the described embodiments may be implemented. Communication system 100 may be a multiple access system from which multiple wireless users receive content such as voice, data, video, messaging, broadcast, and the like. Communication system 100 may be configured to provide multiple wireless users with access to such content by sharing system resources, including wireless connection bandwidth. For example, communication systems 100 may use one or more channel access techniques such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), multiple Orthogonal Frequency Division Access (OFDMA), Single Carrier FDMA (SC-FDMA), Non-Redundant Extended Discrete Fourier Transform (DFT) Extended OFDM with Sync Burst (ZT UW DTS-s OFDM), Sync Burst OFDM (UW-OFDM) , OFDM with resource block filtering, multi-carrier filter bank (FBMC), and the like.

As shown in FIG. 1A, communication system 100 may include wireless transmit/receive (WTRU) modules 102a, 102b, 102c, 102d, RAN 104/113, CN 106/115, public switched telephone network (PSTN) 108, Internet 110, and others. network 112, although it should be understood that any number of WTRUs, base stations, networks, and/or network elements are contemplated in the described embodiments. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device capable of operating and/or interoperating in a wireless communication environment. For example, WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station and/or STA, may be configured to transmit and/or receive radio signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, subscriber unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, netbook, personal computer, wireless sensor, Mi-Fi hotspot or device, internet of physical objects (IoT) device, watch or other wearable devices, head-mounted display (HMD), vehicle, RC unmanned aerial vehicle, medical device and applications (e.g. used in remote surgery), industrial device and applications (e.g. robot and/or other wireless devices operating in industrial and/or automated process chain), device related to consumer electronics, device a device operating in a commercial and/or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

Communication systems 100 may also include base station 114a and/or base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly communicate with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as CN 106/115, Internet 110 and/or other networks 112. By way of example, base stations 114a, 114b may be base transceiver stations (BTS), Node-Bs, eNode Bs, Home Node Bs, Home eNode Bs, base stations of the next generation (gNB), NodeB based on NR, site controller, access point (AP), wireless router, etc. Although each of the base stations 114a, 114b is shown as a separate element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

Base station 114a may be part of RAN 104/113, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. P. Base station 114a and/or base station 114b may be configured to transmit and/or receive radio signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service in a particular geographic area, which may be relatively fixed or which 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, ie, one for each cell sector. In an embodiment, base station 114a may use multiple input multiple output (MIMO) technology and may employ multiple transceivers for each cell sector. For example, beamforming can be used to transmit and/or receive signals in the desired spatial directions.

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

More specifically, as noted above, communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base station 114a in RAN 104/113 and WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Terrestrial Access (UTRA) for Universal Mobile Telecommunications System (UMTS) in which an air interface 115/ 116/117 using wideband CDMA (WCDMA). Wideband Code Division Multiple Access (WCDMA) technology may include communication protocols such as High Speed Packet Access (HSPA) and/or Enhanced HSPA (HSPA+). HSPA may include High Speed Downlink (DL) Packet Access (HSDPA) and/or High Speed Uplink (UL) Packet Access (HSUPA).

In an embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as Next Generation UMTS Terrestrial Radio Access (E-UTRA) that can establish a radio interface 116 using Long Term Evolution (LTE) , and/or LTE-Advanced (LTE-A), and/or LTE-Advanced Pro (LTE-A Pro).

In an embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as New Radio Access Technology (NR Radio Access), in which a radio interface 116 using New Radio (NR) technology may be established.

In an embodiment, a variety of radio access technologies may be implemented in base station 114a and WTRUs 102a, 102b, 102c. For example, in conjunction with base station 114a and WTRUs 102a, 102b, 102c, LTE radio access and NR radio access can be implemented, for example, using two-way communication (DC) principles. Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to or from multiple types of base stations (eg, eNBs and gNBs).

In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e. Wireless Fidelity (WiFi)), IEEE 802.16 (i.e. global interoperability for microwave access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), advanced data rates for GSM Evolution (EDGE), GSM EDGE (GERAN) networks, etc.

Base station 114b shown in FIG. 1A may be, for example, a wireless router, Home Node B, Home eNode B, or access point, and any suitable RAT may be used to facilitate wireless communication in a localized area such as a business, residential, transportation facility, educational institution, industrial facility, air corridor (for example, for use by unmanned aerial vehicles), roadway, etc. In one embodiment, a radio technology such as IEEE 802.11 may be implemented in base station 114b and WTRUs 102c, 102d to create a wireless local area network (WLAN). In an embodiment, a radio technology such as IEEE 802.15 may be implemented in base station 114b and WTRUs 102c, 102d to create a wireless personal area network (WPAN). In yet another embodiment, cell-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) may be used in base station 114b and WTRUs 102c, 102d to creating a pico cell or femto cell. As shown in FIG. 1A, base station 114b may have a direct connection to Internet 110. Thus, base station 114b may not need to access Internet 110 via CN 106/115.

The RAN 104/113 may communicate with the CN 106/115, which may be any type of network capable of providing voice, data, applications, and/or Internet Voice over IP (VoIP) services to one or more of the WTRUs. 102a, 102b, 102c, 102d. Data may have different quality of service (QoS) requirements, such as different performance requirements, latency requirements, fault tolerance requirements, reliability requirements, data rate requirements, mobility requirements, and the like. On the CN 106/115, call control, billing services, location-based mobile services, prepaid calls, Internet connectivity, video distribution, etc. can be provided, and/or high-level security functions such as user authentication. Although in FIG. 1A is not shown, it should be understood that RAN 104/113 and/or CN 106/115 may directly or indirectly communicate with other RANs that use the same RAT as RAN 104/113 or a different RAT. For example, in addition to communicating with RAN 104/113 that may use NR radio technology, CN 106/115 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E -UTRA or WiFi.

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

Some or each of the WTRUs 102a, 102b, 102c, 102d in communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for interacting with different wireless networks over different wireless links connections). For example, WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may use cell-based radio technology, as well as with a base station 114b that may use IEEE 802 radio technology.

In FIG. 1B is a system diagram illustrating an example of WTRU 102. As shown in FIG. 1B, WTRU 102 may include, but is not limited to, processor 118, transceiver 120, transmitter/receiver 122, speaker/microphone 124, keyboard 126, display/touchpad 128, non-removable storage 130, removable storage 132, source 134 power supply, global positioning system (GPS) chipset 136, and/or other peripheral devices 138. It should be understood that WTRU 102 may include any subcombination of the above elements and still conform to the embodiment.

Processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, application specific integrated circuits (ASICs), user programmable circuits gate arrays (FPGA), integrated circuit (IC) of any other type, state machine, etc. Processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality by which WTRU 102 operates in a wireless communication environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitter/receiver element 122. Although FIG. 1B, processor 118 and transceiver 120 are shown as separate components, it should be understood that processor 118 and transceiver 120 may be integrated into an electronic unit or chip together.

Transmitting/receiving element 122 may be configured to transmit signals to or receive signals from a base station (eg, base station 114a) over air interface 116. For example, in one embodiment, transmitting/receiving element 122 may be an antenna configured to transmitting and/or receiving RF signals. In an embodiment, transmitter/receiver element 122 may be an emitter/detector capable of transmitting and/or receiving, for example, signals in the IR spectrum, UV spectrum, or visible light spectrum. In yet another embodiment, transmitter/receiver element 122 may be configured to transmit and/or receive signals in both the RF spectrum and the visible light spectrum. It should be understood that the transmitter/receiver element 122 may be configured to transmit and/or receive any combination of radio signals.

Although in FIG. 1B, transmitter/receiver element 122 is shown as a single element, WTRU 102 may include any number of transmitter/receiver elements 122. More specifically, MIMO technology may be used in WTRU 102. Thus, in one embodiment, WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals over air interface 116.

Transceiver 120 may be configured to modulate signals transmitted by transmitter/receiver element 122 as well as demodulate signals received by transmitter/receiver element 122. As noted above, WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include a plurality of transceivers, through which the WTRU 102 is able to communicate through a plurality of RATs, such as, for example, NR and IEEE 802.11.

The processor 118 of the WTRU 102 may be coupled to a speaker/microphone 124, a keyboard 126, and/or a display/touch panel 128 (e.g., a liquid crystal display (LCD) or an organic light emitting diode (OLED) display) and may receive user input therewith. . Processor 118 may also output user data to speaker/microphone 124, keyboard 126, and/or display/touchpad 128. In addition, processor 118 may access information from any suitable storage device, such as non-removable storage device 130 and/or removable storage device 132 and store data therein. The non-removable storage device 130 may include random access memory (RAM), read only memory (ROM), a hard drive, or any other type of storage device. The removable storage device 132 may include a Subscriber Identity Module (SIM) card, a memory card, a secure digital memory (SD) card, and the like. In other embodiments, processor 118 may access and store information from a storage device that is not physically located in WTRU 102, such as a server or home computer (not shown).

Processor 118 may receive power from power supply 134 and may be configured to manage power and/or distribute power to other components in WTRU 102. Power supply 134 may be any suitable device for supplying power to WTRU 102. For example, power supply 134 may include one or more dry cells (e.g. nickel cadmium (NiCd), nickel zinc (NiZn), nickel hybrid (NiMH), lithium ion (Li-ion) batteries, etc.), solar cells , fuel cells, etc.

The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (eg, longitude and latitude) relative to the WTRU 102's current location. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location over the air interface 116 from a base station (eg, from base stations 114a, 114b) and/or determine the location based on the timing of signals received from two or more adjacent base stations. It should be understood that the WTRU 102 can acquire location information by any suitable location method and still comply with the embodiment.

Processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless communication capabilities. For example, peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photography and video), a universal serial bus (USB) port, a vibration device, a television transceiver, a wireless headset, a Bluetooth® module, a radio module with frequency modulation (FM), digital music player, multimedia player, video game playback device module, Internet browser, virtual reality and/or augmented reality (VR/AR) device, activity tracker, etc. Peripheral devices 138 may include one or more sensors, where the sensors may be one or more of a gyroscope, an accelerometer, a Hall sensor, a magnetometer, an attitude sensor, a proximity sensor, a temperature sensor, a time sensor; geographic location sensor; altimeter, ambient light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor and/or humidity sensor.

The WTRU 102 may include a full duplex radio in which the transmission and reception of some or all of the signals (eg, associated with particular subframes) for both UL (eg, transmit) and downlink (eg, receive) may be carried out jointly and/or simultaneously. The full duplex radio may include an interference control module to reduce and/or substantially eliminate its own interference using any hardware (eg, a choke) or signal processing by a processor (eg, a separate processor (not shown) or processor 118). In an embodiment, WRTU 102 may include a full duplex radio for transmitting and receiving some or all of the signals (eg, associated with specific subframes) for both UL (eg, transmit) and downlink (eg, receive).

In FIG. 1C is a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 may use E-UTRA radio technology to communicate with WTRUs 102a, 102b, 102c over air interface 116. RAN 104 may also communicate with CN 106.

RAN 104 may include eNode-Bs 160a, 160b, 160c, although it should be understood that RAN 104 may include any number of eNode-Bs and still comply with the embodiment. Each eNode-B 160a, 160b, 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, 102c over air interface 116. In one embodiment, MIMO technology may be implemented in eNode B 160a, 160b, 160c. Thus, eNode-B 160a may, for example, use a plurality of antennas to transmit radio signals to and/or receive radio signals from WTRU 102a.

Each eNode-B 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to make radio resource management decisions, handover decisions, UL and/or DL user scheduling, and the like. As shown in FIG. 1C, eNode-Bs 160a, 160b, 160c can communicate with each other via the X2 interface.

CN 106 shown in FIG. 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the above elements is shown as part of CN 106, it should be understood that any of these elements may be owned by and/or provided to an entity other than the CN operator for use.

MME 162 may be connected to each eNode-Bs 162a, 162b, 162c in RAN 104 via an S1 interface and may act as a control node. For example, MME 162 may be responsible for user authentication of WTRUs 102a, 102b, 102c, channel activation/deactivation, selection of a particular serving gateway during initial connection of WTRUs 102a, 102b, 102c, and the like. MME 162 may provide a control plane function for switching between RAN 104 and other RANs (not shown) that use other radio technologies such as GSM and/or WCDMA.

SGW 164 may be connected to each eNode B 160a, 160b, 160c in RAN 104 via an S1 interface. SGW 164 may essentially direct and forward user data stream packets to and from WTRUs 102a, 102b, 102c. SGW 164 may perform other functions such as user plane binding during handover between eNode Bs, initiating paging when DL data is available to WTRUs 102a, 102b, 102c, managing and storing the context of WTRUs 102a, 102b, 102c, etc. .P.

SGW 164 can be connected to PGW 166, through which WTRUs 102a, 102b, 102c can access packet-switched networks, such as the Internet 110, to facilitate communication between WTRUs 102a, 102b, 102c and IP-enabled devices. .

With CN 106, exchanging data with other networks can become easier. For example, CN 106 may provide WTRUs 102a, 102b, 102c with access to circuit switched networks such as PSTN 108 to facilitate communication between WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, CN 106 may include an IP gateway (eg, an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108, or may communicate with it. In addition, CN 106 may provide WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks that are owned and/or provided for use by other service providers.

Although the WTRU is described in FIG. 20A-D as a wireless terminal, it is contemplated that, in certain exemplary embodiments, such a terminal may use (eg, temporarily or permanently) a wired interface to a communications network.

In exemplary embodiments, the other network 112 may be a WLAN.

A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STA) associated with the AP. The AP may access or interface with a Distribution System (DS) or communicate over another type of wired/wireless network that carries traffic into and/or out of the BSS. Traffic to the STA provided outside the BSS may arrive via the AP and may be delivered to the STA. Traffic originating from the STA to recipients outside the BSS may be sent to the AP for delivery to the appropriate recipients. Traffic between STAs within a BSS can be sent via an AP, for example, if a source STA can send traffic to an AP and an AP can deliver traffic to a destination STA. Traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transferred between (eg, directly between) a source STA and a sink STA in a direct connection setup (DLS). In certain exemplary embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within, or using, IBSS may communicate directly with each other. The IBSS mode may sometimes be referred to herein as the direct connection mode.

When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit the beacon over a fixed channel, such as a primary channel. The primary channel may have a fixed width (eg, 20 MHz bandwidth) or a dynamically set signaling width. The primary channel may be a working channel of the BSS and may be used by STAs to establish a connection with the AP. In certain exemplary embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, such as in 802.11 systems. STAs (eg, each STA), including the AP, can discover the primary channel for CSMA/CA. Upon recognizing/detecting and/or determining that a primary channel is busy by a particular STA, that particular STA may be turned off. One STA (eg, only one station) may be transmitting in a given BSS at any given time.

For high throughput (HT) STA communication, a 40 MHz channel can be used, for example, by combining a 20 MHz primary channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz channel.

Very high throughput (VHT) STAs may support 20 MHz, 40 MHz, 80 MHz, and/or 160 MHz channels. The 40 MHz and/or 80 MHz channels may be formed by combining continuous 20 MHz channels. A 160 MHz channel can be formed by combining 8 continuous 20 MHz channels, or by combining two non-continuous 80 MHz channels, which may be referred to as an 80+80 configuration. two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately for each stream. These streams may be mapped to two 80 MHz channels, and data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operation for the 80 + 80 configuration may be inverted, and the combined data may be sent to a media access control (MAC) device.

802.11af and 802.11ah support 1GHz sub-modes of operation. Channel bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the unused television frequency spectrum (TVWS), while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using spectrum, other than TVWS. According to the exemplary embodiment, 802.11ah can support metering/machine-to-machine communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, such as limited capabilities, including support (eg, support only) certain and/or limited bandwidths. The MTC devices may include a battery having a battery life exceeding a threshold value (eg, to provide a very long battery life).

WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the largest total operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by the STA of all STAs operating in the BSS that supports the lowest bandwidth mode of operation. In the 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz and/or modes of operation with other channel bandwidths. The carrier detection and/or network allocation vector (NAV) parameters may depend on the state of the primary link. If the primary channel is busy, for example, due to a STA (which only supports 1 MHz mode of operation) transmitting to an AP, all available bands may be considered busy even though most bands are still unoccupied and may be available.

In the United States, the available frequency bands that can be used by 802.11ah range from 902 MHz to 928 MHz. The available frequency bands in Korea are from 917.5 MHz to 923.5 MHz. The available frequency bands in Japan are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz depending on the country code.

In FIG. 1D is a system diagram of RAN 113 and CN 115 according to an embodiment. As noted above, RAN 113 may use NR radio technology to communicate with WTRUs 102a, 102b, 102c over air interface 116. RAN 113 may also communicate with CN 115.

RAN 113 may include gNBs 180a, 180b, 180c, although it should be understood that RAN 113 may include any number of gNBs and still conform to the embodiment. Each gNB 180a, 180b, 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, 102c over air interface 116. In one embodiment, gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may use beamforming to transmit signals to and/or receive signals from gNBs 180a, 180b, 180c. Thus, gNB 180a, for example, can use multiple antennas to transmit radio signals to and/or receive radio signals from WTRU 102a. In an embodiment, gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple carrier components (not shown) to WTRU 102a. A subset of these carriers may be in unlicensed spectrum, while the remaining carriers may be in licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement Point to Point Negotiation (CoMP) technology. For example, WTRU 102a can receive negotiated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using scaled-value transmissions. For example, OFDM symbol spacing and/or OFDM subcarrier spacing may be different for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable duration (e.g., containing varying numbers of OFDM symbols and/or having constant different absolute time durations) .

gNBs 180a, 180b, 180c may be configured to communicate with WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In a standalone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without concurrent access to other RANs (eg, such as eNode-Bs 160a, 160b, 160c). In a standalone configuration, WTRUs 102a, 102b, 102c may use one or more gNBs 180a, 180b, 180c as a reference point for mobility. In a standalone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using unlicensed band signals. In a non-autonomous configuration, WTRUs 102a, 102b, 102c can communicate/connect with gNBs 180a, 180b, 180c while communicating/connecting with another RAN such as eNode-B 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement dual connection (DC) principles for substantially simultaneous communication with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, 160c may act as a mobility reference point for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c may provide additional coverage and/or capacity to serve WTRUs 102a, 102b , 102s.

Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to make radio resource management decisions, handover decisions, UL and/or DL user scheduling, network segmentation support, two-way communication. , interaction between NR and E-UTRA, routing of user plane data to the user plane functional block (UPF) 184a, 184b, routing of control plane information to the access and mobility management function (AMF) 182a, 182b, and the like. As shown in FIG. 1D, gNBs 180a, 180b, 180c can communicate with each other via the Xn interface.

CN 115 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possibly a data network (DN) 185a, 185b. . While each of the above elements is shown as part of CN 115, it should be understood that any of these elements may be owned by and/or provided to an entity other than the CN operator for use.

AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in RAN 113 over the N2 interface and may act as a control node. For example, AMF 182a, 182b may be responsible for authenticating users of WTRUs 102a, 102b, 102c, supporting network segmentation (e.g., handling different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing a registration area, terminating NAS signaling, managing mobility, etc. Network segmentation may be used in AMFs 182a, 182b when configuring CN support for WTRUs 102a, 102b, 102c based on the service types used by WTRUs 102a, 102b, 102c. For example, different network slices can be set up for different use cases, such as services based on high reliability low latency communication (URLLC), services based on access to Enhanced Mobile Broadband (eMBB), services for access to machine-to-machine communication. (MTC) and/or the like. AMF 162 may provide a control plane function for switching between RAN 113 and other RANs (not shown) that use other radio technologies such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies, e.g. WiFi.

SMF 183a, 183b can be connected to AMF 182a, 182b in CN 115 via N11 interface. SMF 183a, 183b can also be connected to UPF 184a, 184b in CN 115 via N4 interface. SMF 183a, 183b can select and control UPF 184a, 184b, and configure traffic routing with UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as UE IP address management and allocation, PDU session management, policy enforcement and QoS management, provision of downlink data notifications, and the like. The session type of the PDU may be IP based, non-IP based, Ethernet based, and so on.

UPFs 184a, 184b may be connected to one or more gNBs 180a, 180b, 180c in RAN 113 via an N3 interface, through which WTRUs 102a, 102b, 102c may access packet-switched networks such as the Internet 110 for facilitating communication between WTRUs 102a, 102b, 102c and IP-enabled devices. UPFs 184, 184b may perform other functions such as packet routing and forwarding, user plane policing, support for multipath PDU sessions, user plane QoS processing, downlink packet buffering, mobility anchoring, and the like.

With the CN 115, exchanging data with other networks can become easier. For example, CN 115 may include an IP gateway (eg, an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and PSTN 108, or may communicate with it. In addition, through CN 115, WTRUs 102a, 102b, 102c can access networks 112, which may include other wired or wireless networks that are owned and/or provided for use by other service providers. In one embodiment, WTRUs 102a, 102b, 102c may be connected to a local area network (DN) 185a, 185b via UPF 184a, 184b via an N3 interface to UPF 184a, 184b and an N6 interface between UPF 184a, 184b and DN 185a, 185b.

Taking into account FIG. 1A-D and the corresponding descriptions of FIG. 1A-1D one or more or all of the functions described herein in connection with one or more of: WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166 , gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and/or any other device(s) described in this document may be implemented by one or more emulation devices (not shown). Emulation devices may be one or more devices configured to emulate one or more of the functions, or all of the functions described herein. For example, emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

The emulation devices may be configured to perform one or more tests on other devices in a lab environment and/or in an operator's network environment. For example, one or more emulation devices may perform one or more functions, or all of the functions, while being fully or partially implemented and/or deployed as part of a wired and/or wireless communications network to test other devices on the communications network. One or more emulation devices may perform one or more functions, or all functions, while they are temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly connected to another device for testing and/or performing testing using wireless communication via a wireless communication channel.

One or more emulation devices may perform one or more functions, including all functions, and yet not be implemented/deployed as part of a wired and/or wireless communication network. For example, emulation devices may be used in a test lab scenario and/or in a non-deployed (eg, test) wired and/or wireless communications network to test one or more components. One or more emulation devices may be test equipment. Emulation devices may use a direct RF connection and/or wireless communications via an RF circuit (eg, which may include one or more antennas) to transmit and/or receive data.

While the features and elements are described above in specific combinations, it will be apparent to one skilled in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embedded in a computer-readable medium and designed to be executed by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable media. Examples of computer-readable storage media include, without limitation, read-only memory (ROM), random access memory (RAM), register, cache memory, semiconductor storage devices, magnetic media such as internal hard drives and removable drives, magneto-optical media and optical media such as CD-ROMs and digital versatile discs (DVDs). The processor, in combination with software, may be used to implement an RF transceiver for use in a WTRU, user equipment, terminal, base station, RNC, and/or any host computer.

The operation and/or use of a cell, a transceiver point (TRP), and/or a carrier in an unlicensed band may be autonomous. Some assistance may be provided in the operation and/or use of a cell, transceiver point (TRP) and/or carrier in an unlicensed band. For example, assistance may be provided by a carrier in a licensed band, and this may be referred to as licensed band access (LAA). In the case of LAA, the licensed cell, TRP and/or carrier may be the primary cell, TRP and/or carrier. In the case of LAA, the licensed cell, TRP, and/or carrier may be the core cell, TRP, or carrier.

A cellular system that operates on unlicensed spectrum may be shared with other spectrum users. Other spectrum users may be using unlicensed technology (eg Wi-Fi, WiGig and/or other cellular carriers). A cellular system that operates on unlicensed spectrum may attempt to minimize interference and/or may consider the fairness of other spectrum users. For example, the cellular system may use listen before transmit (LBT) and/or channel idle analysis (CCA). With LBT and/or CCA, a system node such as an access point (AP), eNodeB (eNB), gNodeB (gNB), TRP, user equipment (UE), etc., may listen to a channel (e.g., a frequency band with a certain center frequency and bandwidth). In this way, it is possible to determine the presence of another user using the channel before transmitting on that channel and/or transmitting on a portion of the channel. Listening and/or determining usage by others may include and/or be based on measurements. The measurements may include energy detection.

In this document, the terms "LBT, CCA" and "LBT/CCA" may be used interchangeably. The channel may be defined as being busy, busy, and/or in use during a measurement (eg, energy). The determination may, for example, be based on a measurement of energy, which may be at and/or above a threshold. For example, a channel may be defined as idle, idle, idle, and/or unused when a measurement (eg, energy) is at or below a threshold.

The terms idle, idle, and/or idle may be used interchangeably. The terms "non-free", "occupied", "loaded", and/or "used" may be used interchangeably. The terms "channel" and/or "working channel" may be used interchangeably. An unsuccessful CCA may indicate that the channel is busy. A successful CCA may indicate that the channel is idle.

A potential transmitter on the channel (eg, a UE with a potential uplink (UL) transmission and/or an eNB with a potential downlink (DL) transmission) may estimate and/or monitor (eg, receive) the channel. This can be done, for example, to measure and/or determine the presence of a signal and/or interference in a channel. This may be done prior to transmission, for example, to determine if the channel is being used (eg, busy and/or busy) by others (eg, another system, user, and/or signal).

A potential transmitter, for example within LBT/CCA, compares the received signal and/or interference from the channel with the criteria. The criteria may be (eg, one or more) threshold level(s). By comparison (eg, received signal and criteria), it is possible to determine whether the channel is idle. If, for example, the potential transmitter determines that the channel may be free, the potential transmitter may transmit on the channel. If, for example, the potential transmitter determines that the channel may not be free, the potential transmitter may not transmit on the channel, may delay the potential transmission, and/or refuse the potential transmission.

Frame based equipment (FBE) may refer to equipment for which the transmit/receive timing may be fixed and/or structured. Load Based Equipment (LBE), for example, may not perform LBT/CCA according to a certain frame structure (eg, at a fixed and/or specific point in time). The LBE may perform LBT/CCA, for example, when it has data to transmit.

Equipment may refer to a node or device that can transmit and/or receive over a licensed and/or unlicensed channel. For example, the equipment may include UEs, eNBs, gNBs, TRPs, STAs, and/or APs.

Herein, an eNB, gNB, TRP, STA, cell, base station (BS), and/or AP may be used interchangeably (eg, nodes may transmit and receive). An eNB, gNB, and/or TRP may be used to represent one or more of a gNB, TRP, STA, cell, BS, AP, and/or another node, such as a network node.

The equipment can perform an LBT/CCA test that can detect channel energy. This may occur prior to the transmission and/or prior to the burst of transmissions on the working channel. The LBT/CCA time period for channel estimation may be a fixed time and/or have a minimum time. Channel Busy Time (COT) may be the total time that equipment can transmit on a given channel, for example, without reassessing the availability of the channel. The Maximum COT (MCOT) may be the total time that the equipment can use the working channel for a given transmission and/or burst of transmissions. The MCOT value may be configured and/or enabled (eg, by throttling). The MCOT value may be 4 ms and/or 10 ms, for example. The MCOT for equipment can be less than the maximum allowed value. The maximum allowable value can be set, for example, by the equipment manufacturer.

The period of inactivity may be a time (eg, a continuous period of time) during which the equipment may not transmit data on the channel. There may be a minimum requirement for a period of inactivity. The minimum requirement may be based on COT. For example, the period of inactivity may be 5% of the COT. The inactivity period may be used by the equipment, for example, during the current fixed frame period.

If the equipment determines, for example, during and/or as a result of LBT/CCA, that the working channel(s) is(are) not busy, it may transmit on the idle channels. The transfer can be immediate.

In some embodiments, if the equipment determines, for example, during and/or as a result of LBT/CCA, that the working channels are busy, it may not transmit on that channel. For example, the equipment may not transmit on the channel until subsequent LBT/CCAs are performed, for example, which detect that the channel is idle.

In some embodiments, if the equipment determines, for example, during and/or as a result of LBT/CCA, that the working channel is busy, it may not transmit on that channel. For example, it may not transmit on the channel for the next fixed frame period.

LBT/CCAs may be performed after previous LBT/CCAs. For example, previous LBT/CCAs could determine the possibility of a busy channel condition. Subsequent LBT/CCAs may include a wait time and/or a dwell time before checking for a possible idle channel.

LBT/CCAs may be performed after previous LBT/CCAs. For example, previous LBT/CCAs may determine if the channel is busy. Subsequent LBT/CCAs may include a longer period to determine a possible idle channel and/or subsequent transmission.

The UE may perform CCA to determine a possible idle channel state. If the UE determines that the channel is not free, the UE may add additional backoff and/or latency time (eg, contention window time). If, for example, the UE determines that the channel is free, the UE may recheck the channel. This check may be prior to the actual transmission, for example, if it is not possible to start the actual transmission immediately after an idle channel condition is detected.

For example, if the UE is outside the inspection window (eg, 25 μs) prior to the actual transmission, the UE may perform CCA for (eg, at least) the inspection window (eg, inspection window time period) before the actual transmission. The UE may transmit (eg, only) if, for example, an idle channel state is determined for (eg, at least) a portion of the test window.

The CCA may be the full CCA or the short CCA. A complete CCA may include adding (eg, one or more) transmission backoffs. For example, a full CCA may be performed upon determining the busy channel state. The short CCA may be a quick test (eg, an energy detection test). For example, a short CCA may be performed in a test window prior to the start of a transmission and/or an intended and/or scheduled transmission.

For example, if the UE performs a CCA for (eg, the first) subframe (SF) or symbol, the UE may perform a full CCA that may determine whether the channel is free. The UE may perform a short CCA prior to the actual transmission. A short CCA may be performed, for example, to recheck if the channel is still free. This may occur if there is a gap between the end of the full CCA and the start of the transmission.

Access, resource usage, and/or resource transfer across the channel, per cell, per cell, per TRP, and/or other node may be grant-based, resource allocation-based, and/or scheduler-based.

For example, the UE may transmit (eg, only) on a set of resources. This may be done in response to and/or in accordance with the accepted provision and/or allocation of resources. The resources may be time and/or frequency resources.

The provision and/or allocation may be provided (eg explicitly). For example, allocation may be provided in downlink control information (DCI). The grant and/or allocation may be configured, for example, by higher layer signaling. The grant and/or allocation may be used by the UE if the UE has data to transmit.

Access, use of resources, and/or transfer to resources across a channel, per cell, per cell, per TRP, and/or another node may be performed, for example, without grant and/or without grant. In this document, the terms "without provision" or "in the absence of provision" may be used interchangeably. The resources may be time and/or frequency resources.

For example, the UE may transmit over (eg, a set of) resources when the UE has a transmission to be performed. The UE may determine and/or select resources for transmission from one or more resources. The resources may be, for example, a configured set of resources.

The resource(s) may be shared or used by another UE. The resource(s) may (may) be referred to as contention-based resources. It is possible for UEs (eg, multiple) transmissions to collide when UEs select and/or transmit on the same resources at the same time.

Mechanisms can be implemented by which the likelihood of conflict(s) can be reduced. For example, the choice of resources may be determined randomly (eg, partially randomly). Resource selection may be a function of the UE identity. Different UEs (eg, UE groups) may be configured with different resources (eg, resource sets).

Mechanisms may be included to provide the receiver with the ability to transmit without providing the sender to be identified. For example, the transmission may include an identifier and/or a partial identifier.

LBT procedures may be designed for omnidirectional systems. In omnidirectional systems, the transmission energy may propagate (eg, equally) in (eg, all) directions. This can be detected, for example, by devices (eg, all devices) permanently within the channel identification range of the receivers.

Directional channel transmissions can overcome propagation limitations in millimeter wave bands. LBT listening can be done along with a transmit (Tx) beam at the transmitter. This directed LBT may be referred to herein as "legacy LBT". By using legacy LBT in directed systems (eg highly directed systems) it is possible to increase the number of hidden knots (eg to the directed hidden knot problem).

In directional systems (eg, highly directional systems), signal energy may be concentrated in a spatial region (eg, a narrow spatial region) covered by the transmitted beam. Devices located in the area of the transmitted beam can determine the presence of transmissions. Devices located outside the region of the transmitted beam may be configured without the ability to determine the transmission. The device can recognize the readiness of the channel for transmission. The device may initiate a transmission that may interfere with and/or conflict with an ongoing transmission.

In accordance with some embodiments, channel idle analysis (CCA) may include Enhanced Directed Channel Request/Enhanced Directed Channel Transmission Readiness (eDRTS/eDCTS). The eDRTS messages may be sent over, for example, multiple adjacent beams or over wider beams. Transmissions may be allowed and/or configured based on quality of service (QoS) requirements. Improved signaling may be performed in eDRTS/eDCTS messages. Multiple simultaneous eDRTS/eDCTS may be sent on different beam paired (BPL) links (eg, for non-reciprocal beams). An eDCTS message such as, for example, eDCTS-to-Self can be used to provide better protection against spatial interference. In some embodiments, the eDCTS-to-Self message may be configured differently than the eDCTS message. For example, a successful eDRTS and eDCTS transmission may be followed by multiple eDCTS-to-Self transmissions. Multiple eDCTS-to-Self transmissions may be sent on multiple beams. Dynamic downlink/uplink (DL/UL) switching configurations can be used, by which conflict between transmissions of other devices and the current transmission can be prevented.

In accordance with some embodiments, cooperative implementations of directional new radio (NR) and a WiGig system can be made. The DL/UL switching patterns for the NR link may be determined based on the minimum duration of the allocated interframe interval (DIFS) in the WiGig system. Transfers can be configured to run backwards in every window (eg, in a DIFS period). In the reverse direction, multi-block transmissions may be sent. The transmission power of gears can be increased.

In accordance with some embodiments, listening before transmitting (LBT) can be performed in paired directions (eg, in the direction of the recipient and in the opposite direction). In this way, you can reduce the number of hidden nodes that can interfere with the current transmission. To reduce the number of hidden nodes that can interfere with an ongoing transmission, LBT parameters (eg, beamwidth, energy detection (ED) thresholds) can be configured. The transmit and receive strategy may be determined based on a function of the measured power/energy during the LBT.

In FIG. 2A shows an example of interference in beam-based systems using direction-based listen-before-transmit (LBT) when cooperating new radio (NR) with WiGig. For example, as shown in FIG. 2A, NR and/or WiGig nodes may be co-located. More specifically, NR UE 200 and WiGig station (STA) 202 may have packets to send to NR gNB 204 or WiGig access point (AP) 206, respectively. UE 200 may initiate a transmission to gNB 204. STA 202 may not recognize the UE's transmission to gNB 204 (eg, a hidden node issue in directional channel transmission). STA 202 may consider the channel idle and/or start transmission to AP 206. This transmission may interfere with or collide with UE 200 transmission to gNB 204. In FIG. 2B shows an example of interference in beam-based systems using direction-based listen-before-transmit (LBT) procedures in cooperative NR-NR. According to FIG. 2B, a similar situation may arise in NR-NR co-operation, where there may be no coordination between the two NR systems. In FIG. 2B, one NR system may include, for example, UE 208 (also referred to as "UE 1") and/or gNB 210 (also referred to as "gNB 1"), and another NR system may include, for example, UE 212 (also referred to as "UE 2") and/or gNB 214 (also referred to as "gNB 2").

In FIG. 3A and 3B show other examples of hidden node problems. In FIG. 3A shows an example of carrier sensing in LBT with interference from an access point (AP) received at a user equipment (UE). In FIG. 3B shows an example of LBT carrier sensing with gNB interference at a station (STA) and/or an access point (AP) at a UE.

As shown in FIG. 3A, if the receiving node is within the coverage area of the AP 300 and/or even if the legacy LBT at the sending node senses that the link is inactive towards the receiving node, the AP 300 may interfere with the receiving node. The interference may be due to a directional hidden node problem. Such a situation is possible when, for example, the AP's transmission is within the electrical axis of the receiving beam antenna of the transmitting node, but may not be detected by the LBT at the transmitting node. This is shown in FIG. 3A with dashed line 302. As shown in FIG. 3A, this is possible if, for example, gNB 304 is a transmitting node and UE 306 is a receiving node.

AP 300 may transmit (eg, in a directional manner) towards STA 308. A transmitting node (eg, gNB 304 in FIG. 3A) may perform LBT with a beam aligned with the direction of the receiver (eg, UE 306 in FIG. 3A). This may occur before gaining access to an unlicensed channel. If, for example, STA 308 is located between the AP 300 and the transmitting node (eg, as in FIG. 3A), the transmitting node may recognize that the channel is inactive and may proceed to transmit data (eg, towards the receiver). The UE may receive interference from the AP 300, which may be due to a directed hidden node problem. If, for example, STA 308 is located between gNB 304 as a transmitter node and a UE receiver, and/or the legacy LBT does not recognize STA 308 (see, for example, FIG. 3B), STA 308 may receive interference.

In FIG. 3A and 3B show examples of carrier sensing, such as legacy LBT (eg, DL access from gNB to UE). gNB 304 may perform LBT with the beam aligned towards UE 306. gNB 304 may recognize that the channel is inactive. This can happen if, for example, AP 300 is transmitting data towards STA 308 and gNB 304 starts transmitting data towards UE 306. As shown in FIG. 3A, UE 306 may receive interference from AP 300. As shown in FIG. 3B, if STA 308 is not heard on gNB 304, STA 308 may receive interference from gNB 304 and/or UE 306 from AP 300.

In other examples, directional hidden node interference problems may occur when the transmitting node is, for example, a UE and the receiving node is, for example, a gNB. In FIG. 4A shows an example of carrier sensing in LBT with interference from an access point (AP) received on a gNB. In FIG. 4B shows an example of carrier sensing in LBT with interference from UEs received at STAs and/or from APs at gNBs.

In FIG. 4A and 4B show examples of carrier sensing in, for example, legacy LBT (UL access from UE to gNB). UE 400 may perform LBT with the beam aligned towards gNB 402 and may recognize that the channel is inactive. This may occur, for example, if the AP 404 is transmitting data towards the STA 406. Thus, the UE 400 may proceed to transmit data towards the gNB 402. As shown in FIG. 4A, gNB 402 can receive interference from AP 404. As shown in FIG. 4B, STA 406 may not be heard at UE 400 and/or STA 406 may receive interference from UE 400 and/or gNB 402 from AP 404.

In some embodiments, implementations related to cooperative operation of directional NR-NR systems in the unlicensed bands may be provided.

The UE/gNB may perform CCA for the granted and/or scheduled resource with, for example, (eg, one or more) beam(s) and/or beam pair(s) (BPL). Generally, in some embodiments, the term "BPL" as used herein refers to a pair of beams (eg, reciprocal beams (pair)) that creates a communication link between a transmitting node and a receiving node. If, for example, the transmitting node (eg, UE/gNB) performs CCA, a receive (Rx) beam may be used. For example, the CCA may be determined based on the Rx beam used by the UE/gNB for beam pairing.

In some embodiments, upon successful determination of channel idle based on, for example, CCA and/or LBT analysis of the channel, the transmitting and receiving nodes may proceed to exchange data that includes improved signaling or messages. In general, improvements in signaling/messaging can facilitate or enable the various functions described herein. In some embodiments, the enhanced signaling/messages may take the form of (i) an improved channel transmission request message configured, for example, to request transmission on a (directed) channel by the transmitting node, and/or configured for channel reservation purposes, and (ii) an enhanced channel acknowledgment message, eg, to acknowledge or acknowledge receipt (eg, by the receiving node) that the channel is not busy for transmission (eg, a transmission requested by the transmitting node), and/or configured for channel reservation purposes.

As will be described in more detail, in some exemplary embodiments, the enhanced Directed Send Request message may be an enhanced Directed Channel Transfer Request (eDRTS) message, and the enhanced Directed Channel Transfer Acknowledge message may be an enhanced Directed Channel Transfer Ready message ( eDCTS) and/or enhanced Directed Link to Self (eDCTS-to-Self) message.

In addition, in general, an enhanced message of any type or kind described herein refers to a message that may, for example, have improved message content to facilitate or perform various functionality described herein. The improved message content may be in the form of, for example, one or more additional fields that provide information that makes the various functions described herein easier or more likely to perform. In some embodiments, this information may include, for example, information about potentially interfering node(s) (e.g., interfering node(s) known to interfere, or nodes that could at least interfere) when transmitting between the transmitting and receiving nodes, timing or scheduling information, interference directions, etc.

To illustrate, in some embodiments, if the UE/gNB determines that the channel is idle on the Rx beam, they may (e.g., first) send an enhanced Directed Channel Transfer Request (eDRTS) to reserve the channel and/or receive an acknowledgment from the receiving node. (e.g. gNB/UE). The Rx beam may correspond to a Tx beam on which transmission from the UE/gNB is possible. The transmitting node (eg, UE/gNB) may not transmit when it determines that the channel is busy. The eDRTS transmission may be beam based. The receiving node may send Enhanced Directed Link Ready for Transmission (eDCTS) to the transmitter. The eDCTS message may be sent after receiving the eDRTS (eg, successful reception). The eDCTS transmission may be beam(s) based. After the eDRTS and/or eDCTS transmissions, an additional transmission may be configured between the transmitting node (eg, gNB or UE) and the receiving node (eg, UE or gNB).

For example, the transmission may be configured to prevent other transmissions from other devices from starting, which may interfere with the transmission between the transmitting node and the receiving node. The configuration of such a DL/UL switchover can be done via eDRTS and/or eDCTS message(s). The transmitting node may not start transmission if, for example, it does not receive eDCTS from the receiving node (eg, for a configurable amount of time). For example, after transmitting the eDCTS, the transmitting node may start a timer. If, for example, it does not receive the eDCTS before the timer expires, the transmitting node may consider the CCA procedure unsuccessful.

It should be noted that, as used herein, the term "DL/UL switching configuration" refers in some embodiments to a configuration in which information about message timing/scheduling, signaling/messaging types, and so on, can be provided. for uplink transmission, downlink transmission, and/or changing (switching) uplink and downlink transmissions within, for example, the Maximum Channel Busy Time (MCOT) allowed for transmission.

In addition, as a rule, in a directional system, the beams are usually used to determine the resources of the spatial area. Typically, each beam has an associated identifier (eg, a beam identifier, which may be implicit, or may be tied to other reference signal identifiers), and associated spatial parameters (eg, phase shifts to achieve beam directions, beamwidth, antenna gain, and etc.). These spatial parameters are typically used to enable transmission/reception in the direction corresponding to a given beam. In addition, in transmitting/receiving nodes performing directed interchange of data, a type of identification by beam ID can be used to perform directed transmissions (eg, determine the direction used for transmission). To illustrate, in NR (new radio network), for example, a beam management procedure is used, whereby the UE can dynamically inform the gNB stations, for example, the best transmission beam (Tx) / beam identifier (for example, from the point of view of the UE) to transmit to this UE . The gNB may then use this Tx beam to transmit any data destined for the UE.

If the transmitting node (eg, UE/gNB) performs a successful CCA on the Rx beam, a Tx beam can be determined to transmit eDRTS. One or more of the following options may be applied. The UE/gNB may send eDRTS on a Tx beam corresponding to an Rx beam on which there may be a successful CCA. The UE/gNB may send eDRTS on a wider beam than the Tx beam corresponding to the Rx beam on which CCA can be successful. The wider beam can be centered along the same direction as the Rx beam on which successful CCA is performed. The UE/gNB may send eDRTS on multiple adjacent beams around a Tx beam, which may correspond to an Rx beam on which there may be a successful CCA. A plurality of adjacent beams may be chosen such that the center beam may be a Tx beam corresponding to an Rx beam on which a successful CCA can be performed.

The transmitting node may transmit eDRTS over a wider beam and/or adjacent beam(s), for example, to reserve a channel in a wider area around the UE/gNB receiver. Transmission of eDRTS over wider beam or adjacent beam(s) may be permitted and/or prohibited. For example, transmission may be allowed and/or denied based on QoS requirements and/or channel quality (eg, SNR on the Rx beam on which successful CCA is performed). For example, if the SNR on the Rx beam on which successful CCA is performed is below a certain (eg, required) SNR quality (eg, compared to the adjacent beam(s), transmission may be allowed. th) spoke(s) may be allowed if, for example, the QoS requirement(s) of transmitted data may be high (eg, above a certain threshold).

In accordance with some embodiments, the eDRTS message on the Tx beam corresponding to the Rx beam (eg, from the point of view of the transmitting node), on which the transmitting node can perform a successful CCA, may contain one or more of the example information indications shown in Table 1 With respect to the content of the eDRTS message shown in Table 1, in some embodiments, the Transmitter Identification and Receiver Identification fields may be used by other nodes to indirectly determine the direction of upcoming transmissions (eg, the identifier fields may indicate such a direction implicitly). Moreover, the "Receiver Identification" field can be used by other nodes to determine if they are intended recipients of a given transmission. If not, such a node may know that there is no support for that node to respond to an eDRTS message with an eDCTS message.

Table 1

Information Description DL/UL switching configuration This configuration may be used after a successful channel reservation process (eg, after successful reception of eDCTS at the UE/gNB transmitter). This information may be included when the UE/gNB transmitter has information (eg, complete information) about resource allocation for a given transmission. For example, if the UE sends eDRTS when it has no allocated resources, it may not include the DL/UL switching configuration.
The DL/UL switchover configuration may also specify a slot size to use for the upcoming transmission. This allows the UE/gNB receiver to determine the set of upcoming control channel monitoring events. Remaining duration of the entire transmission This information may be included when the transmitting node has information (eg, complete information) about resource allocation for a given transmission. For example, if the UE sends eDRTS when it has no allocated resources, it may not include the remaining transmission duration. Signal type For example, data or control. This may be the data type of the transmission following the receipt of the eDCTS by the transmitting node. This information may be included (eg, only) if, for example, the sending node has data to send to the receiving node. Transmitter identification Identification (eg, unique identification) of the transmitting node relative to the UE/gNB receiver (eg, C-RNTI, PCI). Receiver identification Identification (eg, unique identification) of the receiving node relative to the UE/gNB transmitter (eg, C-RNTI, PCI). eDCTS Flag May be set to "1" if, for example, the transmitting node requests the UE/gNB receiver to respond with eDCTS after successfully receiving the eDRTS. The value of this flag may be (eg, otherwise) set to "0". QoS The QoS of the data that can be transmitted after a successful link reservation process. The UE/gNB receiver may use this information to retrieve the DL/UL configuration. Buffer Status Buffer status at the UE/gNB transmitter. The UE/gNB receiver may use this information to retrieve the DL/UL configuration. eDCTS-to-Self Configuration The number (and/or timing) of eDCTS-to-Self messages that a transmitter may send after eDCTS decoding.

It should be understood that, as with other types of enhanced messages described herein, the information provided is an example of the possible content in an enhanced message in accordance with some embodiments. In accordance with some embodiments, in the case of an eDRTS message, the eDRTS message may be configured, for example, with a subset (eg, another subset) of the exemplary information shown in Table 1. For example, if a UE sends an eDRTS without resources provided, it may include eDRTS transmitter identification, receiver identification, eCTS flag, QoS and/or buffer status.

The eDRTS message may be sent on adjacent beam(s) (eg, to reserve a channel in a larger area around the receiving node). On the adjacent beam(s), eDRTS may include the duration of the entire transmission, eg if known, and/or the type of control signal transmission that may additionally be sent from the transmitting node on those beams at the time of transmission. The control signal transmission may be (eg, at least one of): a reference signal (RS), such as a cell-specific reference signal (CRS); a sequence (eg, a special sequence) of bits; a discovery reference signal (DRS), which may include synchronization signal(s) and/or reference(s) signal(s) (eg, one or more); subsequence; and/or system information.

An eDRTS may specify a control channel resource set (CORESET) or a portion of the bandwidth (BWP) of the channel. The indications may be implicit (eg, associated with the resources over which the eDRTS message may be sent) or explicit (eg, included in an information element in the eDRTS). Due to this, the UE can determine where to look for control information in which DL and/or UL resources can be assigned for transmissions performed at the upcoming channel busy time.

After decoding (eg, successful decoding) the eDRTS, the receiving node may send a beam-based eDCTS message to the transmitting node, for example, if the eDCTS flag is set. The Tx beam on which the eDCTS is sent may be selected. One or more of the following options may be used. The receiving node may send the eDCTS on the Tx beam corresponding to the Rx beam on which the eDRTS is received. The receiving node may send eDCTS on a wider beam than the Tx beam corresponding to the Rx beam on which the eDRTS message can be received. The wider beam may be centered along the same direction as the Rx beam on which eDRTS is received. The receiving node may send eDCTS on the adjacent beam(s) around the Tx beam corresponding to the Rx beam on which the eDRTS message can be received. For example, a plurality of adjacent beams may be selected, among which the center beam may be a Tx beam corresponding to an Rx beam on which eDRTS is received.

A node may transmit eDCTS over wider beam(s) and/or adjacent beam(s), (eg, to reserve a channel in a wider area around the transmitting node). eDCTS transmission over wider beam(s) and/or adjacent beam(s) may be allowed and/or prohibited based on QoS and/or channel quality requirements (e.g., SNR on Rx -beam on which eDRTS is received). For example, if the SNR on the Rx beam on which eDRTS is being received is lower than a certain (eg, required) SNR quality (eg, than that of the adjacent beam(s), the transmission may be allowed. ) to the spoke(s) may be allowed if the QoS requirements of the transmitted data may be high (eg, above a certain threshold).

The receiving node may signal to the transmitting node, for example, in an eDCTS message, about the co-channel interference that can be measured during the reception of the eDRTS. This may occur, for example, when the background directional interference may be weak. For example, when background directional interference can be overcome by adjusting the transmission parameters by the transmitting node (eg, gNB/UE). This may be indicated by (eg, one or more) alternative(s) parameter(s). For example, the parameters may include: observed interference power, measured signal-to-noise ratio plus interference power (SINR) when receiving eDRTS, requested modulation and coding scheme (MCS), and/or the like.

In accordance with some embodiments, the eDCTS message on the Tx beam corresponding to the Rx beam (e.g., from the point of view of the receiving node) on which the eDRTS is received may include one or more of the examples of information shown in Table 2.

table 2

Information Description DL/UL switching configuration This configuration may be used after a successful link reservation process (eg, after successful reception of eDCTS at the transmitting node). This information may be included by the receiving node when, for example, the eDRTS may not have any DL/UL configuration. For example, if a UE sends eDRTS to a gNB when it has no provisioned resources, it may not include the DL/UL switch configuration in the eDRTS. The gNB may (eg, in such a case) deliver and/or send the DL/UL configuration to the eDCTS.
The DL/UL switchover configuration may also specify a slot size to use for the upcoming transmission. This allows the receiving node to determine the set of upcoming control channel monitoring events. Remaining duration of the entire transmission The remaining duration of the entire transmission, excluding the eDRTS duration. Signal type For example, data and/or control. This may be the data type of the transmission following the receipt of the eDCTS by the transmitting node. This information may be included (eg, only) when the UE/gNB receiver has data to send to the transmitting node. Transmitter identification Identification (eg, unique identification) of an eDCTS transmitter relative to an eDCTS receiver (eg, C-RNTI, PCI). Receiver identification Identification (eg, unique identification) of the eDCTS receiver relative to the eDCTS transmitter (eg, C-RNTI, PCI). Interference measurement May include: observed background interference power, eDRTS receive SINR, requested MCS, and/or the like. eDCTS-to-Self Configuration The number (and/or timing) of eDCTS-to-Self messages that a sink node can send (for example) after sending the eDCTS.

It should be understood that, as with other types of enhanced messages described herein, the information provided is an example of the possible content in an enhanced message in accordance with some embodiments. According to some embodiments, in the case of an eDCTS message, the eDCTS message may be configured with, for example, a subset (e.g., another subset) of the exemplary information shown in Table 2. For example, if a UE sends eDCTS after receiving eDRTS from a gNB with a DL/switch configuration UL and/or signal type, the UE may include the remaining duration of the entire transmission, transmitter identification and/or receiver identification in the eDCTS.

The eDCTS message may be sent on adjacent beam(s) (eg, to reserve a channel in a larger area around the UE/gNB transmitter). The adjacent beam eDCTS may include the remaining duration of the entire transmission and/or the type of control signal transmission that may be sent from the UE/gNB on the respective beams later in the transmission. The transmission of the control signal may be or include (eg, may be or include at least one): a reference signal (RS), such as a cell-specific reference signal (CRS); a sequence (eg, a special sequence) of bits; a discovery reference signal (DRS), which may include synchronization signals and/or reference signals (eg, one or more); subsequence; and/or system information.

The node transmitting the eDCTS may perform (eg, perform first) LBT and/or CCA to determine if the channel is free, eg, before transmitting the eDCTS. It can be a full LBT or a short LBT. A short LBT may be obtained using, for example, a single energy detection (ED) measurement and/or a specific threshold. A node may perform (eg, may be provided to perform) LBT, CCA, and/or ED on (eg, some and/or all) beam(s) for which(s) is scheduled to transmit eDCTS from it.

Non-reciprocal beams (and/or beam-paired lines) may be used for transmission and/or reception between (eg, a pair of) UE/gNBs. The first node may perform LBT, for example, to determine if a BPL is available for transmission from the first node to the second node. For example, upon successful LBT, the first node may initiate an eDRTS procedure with respect to the second node. The second node may transmit the eDCTS, for example, after receiving the eDRTS transmission. The second node may start an LBT procedure (eg, a second LBT procedure) at the second BPL, for example, to allow the second node to transmit towards the first node. This may occur after receiving an eDRTS transmission. The second node may transmit the second eDRTS message using the beam(s) related to the second BPL, in the direction of the first node, for example, after a successful LBT. The transmission of the second eDRTS message may occur simultaneously with the first eDCTS message. The first node may send a second eDCTS message to the second node, for example, after receiving the second eDRTS. Upon completion of multiple simultaneous eDRTS-eDCTS procedures, for example, two BPLs may be considered usable. This can be done, for example, using a short LBT to switch between BPLs.

A receiving node that receives eDRTS from another node (eg, gNB/UE) may respond with enhanced directional channel transmission rejection (eDDTS), which may be based on one or more of the following. Detection by the receiving node of the presence of directional interference, such as during eDRTS reception. The signal strength of the directional interference may be insufficient, due to the UE/gNB may not be able to correctly detect eDRTS addressed to them. A gNB receiving eDRTS from a UE may respond with an eDDTS message when the transmission duration requested in the eDRTS overlaps with a previously scheduled transmission.

In accordance with some embodiments, the eDDTS message on the Tx beam, which may correspond to the Rx beam (e.g., from the point of view of the receiving node) on which the eDRTS is received, may include one or more of the examples of information shown in Table 3.

Table 3

Information Description Transmitter ID Identifies the eDDTS transmitter. UE C-RNTI, gNB cell ID, and the like may be included. Receiver ID Identifies the eDDTS receiver. UE C-RNTI, gNB cell ID, and the like may be included. Interfering transmitter ID Identifies the transmitter of the interfering signal. UE C-RNTI, gNB cell ID, and the like may be included. This information may be available to the UE/gNB if, for example, they successfully decode an eDRTS/eDCTS exchange between interfering entities. Interfering receiver ID Identifies the receiver of the interfering signal. UE C-RNTI, gNB cell ID, and the like may be included. This information may be available to the UE/gNB if they successfully decode the interfering eDRTS/eDCTS exchange. Delay duration Specifies the amount of time the transmission can be delayed. If an eDDTS message may be sent in response to an exchange of (eg, one or more) eDRTS and/or eDCTS messages between another UE and gNB pair, this field may contain a transmission duration value obtained from the receiver's eDRTS and/or eDCTS.
If, for example, an eDDTS message may be transmitted by a gNB due to potential overlap with a previously scheduled transmission, this field may contain the combined scheduled transmission duration and/or required acknowledgment/negative acknowledgment (ACK/NACK) duration.
For example, if the UE transmitting the eDDTS may not have information about the duration of the interfering transmission, it may include a Maximum Channel Busy Time (MCOT) value and/or a predetermined value that may indicate an unknown duration.

It should be understood that, as with other types of enhanced messages described herein, the information provided is an example of the possible content in an enhanced message in accordance with some embodiments. In accordance with some embodiments, in the case of an eDDTS message, the eDDTS message may be configured with a subset (eg, another subset) of the exemplary information shown in Table 3. For example, when a UE/gNB sends eDDTS in response to observed directional interference, but the interfering transmitter IDs and/or receiver are unknown, the eDDTS may include (eg, only) transmitter ID and/or receiver ID fields. For example, when sending an eDDTS in response to an observed eDRTS message, and/or when transmitting an eDCTS between an interfering pair of directed devices, the eDDTS may contain (e.g., all of) the fields listed in Table 3.

A transmitting node (eg, gNB) or a receiving node (eg, UE) may transmit enhanced Directed Link Transmission (eDCTS) to itself, or enhanced Directed Link Transmission (eDCTS-to-Self) to itself, for example, to reserve the directed channel for (e.g., scheduled) transmission(s) on the directed channel with (e.g., one or more) respective receiving node(s) (e.g., UE)) or transmitting(- and) node(s) (eg gNB). An eDCTS-to-Self transmission may and/or may not be preceded by an eDRTS transmission or reception. In some embodiments, the eDCTS-to-Self message may be an eDCTS message sent, for example, by the receiving node to itself. In some embodiments, the eDCTS-to-Self message may be configured differently from the eDCTS message, for example, with one or more different fields, formats, or information.

The transmitting node (eg, a gNB) may select a Tx beam for eDCTS-to-Self transmission, for example, after a successful CCA on the beam that is intended to transmit data from the transmitting node (eg, gNB) to the receiving node (eg, UE) . This may occur when a transmitting node (eg, gNB) sends eDCTS-to-Self on a Tx beam that it has identified to use for (eg, subsequent) downlink data transmission to a receiving node (eg, UE). This may occur when the transmitting node (eg, gNB) transmits eDCTS-to-Self to the receiving node (eg, UE) over a wider beam than the Tx beam associated with the subsequent downlink data transmission. The wider beam may be centered along the same beam direction as the Tx beam, which may be associated with downlink data transmission to the receiving node (eg, UE). This may occur when the transmitting node (eg, gNB) is able to transmit eDCTS-to-Self on the adjacent beam(s). Adjacent beam(s) may be around the intended Tx beam for subsequent downlink data transmission. The adjacent beam(s) may be selected such that the center beam may be the Tx beam associated with subsequent downlink data transmission to the receiving node (eg, UE).

A node may transmit eDCTS-to-Self over wider beam(s) and/or adjacent beam(s), (eg, to reserve a channel in a wider area around the transmitter). eDCTS-to-Self transmission over wider beam(s) and/or adjacent beam(s) may be allowed and/or prohibited, for example, based on QoS requirements, channel quality, past directional interference information and/or the like. For example, if a known potential interferer may be associated with the adjacent beam(s), transmission on the adjacent beam(s) may be allowed. Transmission on the adjacent beam(s) may be allowed when the QoS requirements of the transmitted data are high (eg, above a certain threshold). In accordance with some embodiments, the eDCTS-to-Self message may contain one or more of the examples of information shown in Table 4.

Table 4

Information Description Transmitter ID Identifies the eDCTS-to-Self transmitter. UE C-RNTI, gNB cell ID, and the like may be included. Receiver ID Identifies the eDCTS-to-Self receiver. UE C-RNTI, gNB cell ID, and the like may be included. This field may be empty. Delay duration Specifies the amount of time the transmission can be delayed. If, for example, an eDCTS-to-Self message can be transmitted in response to an eDRTS reception, this field may contain the transmission duration value obtained from the eDRTS receiver minus the eDCTS-to-Self transmission time.

In some embodiments, a transmitter node (eg, gNB) and/or a receiver node (eg, UE) may set a guard period for transmissions on a directed channel. This may be done by exchanging eDRTS and/or eDCTS. This exchange may be followed by, for example, multiple eDCTS-to-Self transmissions over, for example, multiple beams to provide, for example, greater protection against spatial interference.

In FIG. 5 shows an exemplary interference scenario for eDRTS, eDCTS, and multiple eDCTS-to-Self procedure 500 for withstanding interferers, in accordance with some embodiments. In the example shown in FIG. 5, nodes 501, 502, and 504 (also referred to as N1, N2, and N3) may, for example, be nodes that may interfere with UE 506. The interference may be due to antenna patterns (e.g., narrow beam patterns). antenna directivity). Nodes 508 and 510 (also referred to as N4 and N5) may, for example, cause interference in gNB 512, which may be due to antenna patterns (eg, narrow antenna patterns). As shown in FIG. 5, gNB 512 may send eDRTS 514 to UE 506. After receiving eDRTS 514, UE 506 may send eDCTS 516 to gNB 512. Typically, this exchange may be followed by gNB 512 sending multiple eDCTS-to-Self messages 518-522 on the respective beams on towards the interfering nodes 501-504, respectively, and the UE 506 transmitting a plurality of corresponding eDCTS-to-Self messages 524 and 526 on the respective beams towards the interfering nodes 508 and 510, respectively, with the possibility of obtaining more spatial interference.

In FIG. 6 shows an example of creating 600 a period and/or a protection area, in accordance with some embodiments. In the example shown in FIG. 6, a transmitting node (eg, gNB) may send "M" eDCTS-to-Self messages 604 after successful decoding of the eDCTS 602. This may be done, for example, to create, for example, a "protection zone" from nodes that may interfere with the receiving node (for example, UE). The transmitting node may signal to the eDRTS 601 a number of "M" eDCTS-to-Self messages 604, for example, to inform the receiving node that "M" eDCTS-to-Self messages may follow after successful decoding of the eDCTS.

The receiving node (eg, UE) may send "N" eDCTS-to-Self messages 606 following the eDCTS message 602. This can be done, for example, to create, for example, a zone of protection from nodes interfering (or possibly interfering) with gNBs. The receiving node may signal to the eDCTS 602 an "N" number of eDCTS-to-Self messages that may follow the eDCTS message 602. This may be done, for example, to inform the transmitting node (gNB) of the number "N" of eDCTS-to-Self messages that may follow eDCTS 602.

As shown in FIG. 6, transmission of control information and/or data 608 (DL and/or UL) between the transmitting node and the receiving node may begin, for example, after the last eDCTS-to-Self message is sent by the transmitting node and/or the receiving node.

The number of eDCTS-to-Self messages sent by transmitter and receiver nodes (M and N) can be optimized. For example, the optimization may be based on, for example, the number of interferers and/or the power and/or beamwidth used to transmit eDCTS-to-Self messages. This can lead to exposure of interference sources.

The timeline shown in Fig. 6 may be updated to reflect device capabilities. For example, a gNB may be capable of simultaneously processing (eg, two) beams. The gNB may use one beam to receive the eDCTS message from the UE, and may have already started sending the eDCTS-to-Self message along with (eg, simultaneously) the eDRTS. The start of the DL/UL change may be moved to the Nth eDCTS-to-Self message. As shown in FIG. 6, the DL/UL change may follow the last eDCTS-to-Self message that may be sent by the transmitting and/or receiving node.

In some embodiments, the DL and/or UL transmission may be performed, for example, upon receipt (eg, successful reception) of the eDCTS at the transmitting node. The UE/gNB may keep the channel in the DL and/or UL directions. This may occur, for example, to prevent other devices from starting transmissions of packets, the transmissions of which may interfere with the ongoing transmission. The other device(s) may (may) detect a busy channel (eg, after identifying a channel with a DL and/or UL transmission) and/or may not start its transmission.

The DL/UL switching configuration can be defined for each BPL. For example, this determination may be made at the UE/gNB transmitter and/or UE/gNB receiver. For example, when the gNB has data to send to the UE, it may output the DL/UL switch configuration and/or may send it to the eDRTS. If, for example, the UE has no (eg, none) provisioned resources and/or may have data to send to the gNB, it may send (eg, send first) eDRTS to the gNB. This can be done without any DL/UL switching configuration. The gNB may output the DL/UL switch configuration and/or may send it to the UE in the eDCTS.

The DL/UL switching configuration may be derived based on the QoS requirement and/or the minimum LBT duration. For example, for data communication (eg, highly reliable data communication), a transmission between a UE/gNB transmitter and a UE/gNB receiver in either direction may be sent within the minimum LBT duration. This may occur, for example, to prevent other devices from detecting a free channel during transmission.

In FIG. 7 shows an example downlink/uplink (DL/UL) switching configuration 700 in accordance with some embodiments. As shown in FIG. 7, a transmitting Tx node (eg, gNB) may send eDRTS 702 along the beam (eg, in the "x" direction). This may occur, for example, after performing a successful CCA on the corresponding Rx beam. Upon successful reception of eDRTS 702, for example, a receiving Rx node (eg, UE) may send eDCTS messages 704, for example, over multiple beams. The beams may include a Tx beam corresponding to the Rx beam on which the eDRTS message 702 was received. The transmitting node may include a DL/UL switching configuration in eDRTS 702. This configuration may be configured to repeat traffic 706 in the reverse direction (eg, from the receiving node to the transmitting node) within, for example, a minimum LBT duration. As shown in FIG. 7, traffic 706 in the reverse direction may be sent, for example, using multipath 708 on other adjacent beams, including, for example, the main/center beam on which the eDRTS/data/control information was received. For example, in some embodiments, traffic 706 in the reverse direction may be sent on multiple beams, which may include a main/center Tx beam corresponding to the Rx beam on which eDRTS 702 is received and/or adjacent beam(s). (s) around the main Tx beam. Thus, it is possible to prevent a transmission (eg, any transmission) from being started/received by the device(s) (eg, all devices) located near the transmitting node.

In FIG. 8 is a flowchart illustrating an example of a transmission procedure in accordance with some embodiments. The example shown in FIG. 8 may be applied when, for example, a transmitter such as a gNB has data to send to a receiver such as a UE. At step 800, a pair of Tx and Rx beams are configured and resource allocation occurs. At 802, the transmitter performs a CCA on the capabilities of the allocated resource. At 804, the transmitter determines whether the channel is busy based on the CCA. If the channel is not busy, the routine proceeds to step 806 where the transmitter transmits eDRTS and waits for a response from the receiver. If the channel is busy, at step 808, the transmitter decides to use the next resource's capabilities, including other beam directions. In step 810, the transmitter determines if an eDCTS message has been received. If an eDCTS message has been received, at step 812, the transmitter transmits (eg, data) on the allocated frequency and time resources. If no eDCTS has been received, the procedure returns to step 808. Then, at step 814, the transmitter determines whether data or a control signal was received from the receiver within the duration of the LBT. If yes, the procedure returns to block 812, and if not, the procedure returns to block 808. If there is no more data to transmit, the procedure may terminate.

In some embodiments, other UE behaviors are possible, which may be based on eDRTS transmission/reception and/or eDCTS transmission/reception. One or more of the following options may be used. A UE that sends eDRTS expects eDCTS from the receiving node. If, for example, it receives the eDCTS within a predetermined time interval, it may start transmitting data to the receiving node (eg, gNB). This may occur in accordance with the adopted DL/UL switching configuration. If, for example, it does not receive eDCTS from the receiving node in a predetermined time interval, it may consider the channel busy and/or decide to use the capabilities of other resources (eg, including other beam directions) to perform CCA. A UE that receives an eDRTS containing its own identity information and/or an eCTS flag set to "1" may send an eDCTS to an eDRTS transmitter. A UE that receives an eDRTS containing its own identity information and/or an eCTS flag set to "0" may be configured to receive downlink control data/signal over resources assigned in the eDRTS. The UE may not send (eg, none) an eDRTS message and/or may not receive eDRTS/eDCTS containing the UE's own equipment identifier. If, for example, the UE receives eDRTS and/or eDCTS without its own UE ID, it may experience backlog and/or it may not attempt channel access. This may occur over a period of time, which may be included in the eDRTS/eDCTS.

According to some embodiments, the present document further describes a dynamic DL/UL switching configuration for each BPL (paired beam link) with periodic eDCTS-to-Self transmission. In some embodiments, according to the configuration described, transmission by another device that may cause interference may be prevented by periodic eDCTS-to-Self transmissions. In addition, in accordance with some embodiments, the present document describes signaling and channel details for implementing control messages in the proposed manner (e.g., eDRTS, eDCTS, and eDCTS-to-Self), for both downlink and uplink data transmissions. connections.

In some embodiments, during data transmission, the transmitter or receiver, or both, may also send eDCTS-to-Self to reserve the directional channel and prevent (at least mitigate) directional interference from neighboring devices. Other devices, upon receiving an eDCTS-to-Self transmission, may determine that the channel is busy and may not initiate transmissions that may interfere with transmissions protected by eDCTS-to-Self transmissions.

In some embodiments, multiple eDCTS-to-Self transmissions may be performed. For multiple transmissions, antenna or beam configurations may be used, which may use, for example, one or more of the following characteristics: (i) the same antenna or beam configurations may be used for eDCTS-to-Self transmissions as for the original eDRTS transmissions. ; (ii) eDCTS-to-Self configurations are created using antenna or beam configurations that were not used for the original eDRTS transmissions; and/or (iii) some eDCTS-to-Self transmissions may use antenna or beam configurations used for the original eDRTS transmission, and other eDCTS-to-Self transmissions use different antenna or beam configurations from those used for the original eDRTS transmission .

In some embodiments, the gNB may send to the UE in an eDRTS message (in the case of downlink) or in an eDCTS message (in the case of uplink) an eDCTS-to-Self configuration containing the number of eDCTS-to-Self, for example, the number of eDCTS-to-Self transmissions. to-Self, and directions for eDCTS-to-Self transmissions.

In some embodiments, the number of eDCTS-to-Self transmissions and directions for eDCTS-to-Self transmissions may be known by the UE or gNB as a result of measurements. For example, a UE or gNB may determine the presence or absence of interfering links through measurements, and eDCTS-to-Self transmissions may only occur in directions or antenna or beam configurations that are susceptible to interference. By way of illustration, for example, based on UE measurements, if the UE determines interference in the direction of the beam on which the gNB will transmit, such as data (data beam) (or directions of beams adjacent to the data beam) that may be expected to interfere with the transmission from the gNB, the UE may decide to send control messages (eDCTS, eDCTS-to-Self) using the data beam and/or adjacent beams to stop any interference. In this case, the node (eg, UE) can be configured appropriately (eg, using suitable hardware/software) to display information about the interfering direction, with the ability to configure these beam directions appropriately to transmit such control messages.

In some alternative embodiments, the eDCTS-to-Self transmission may be included in the eDRTS/eDCTS message from the UE. If the UE sends a grant request in an eDRTS message, the UE may receive a grant for eDCTS-to-Self from the gNB (or base station (BS) in general) in the eDCTS message. If the UE sends a grant request in an eDCTS message, the UE may receive a grant for eDCTS-to-Self from the gNB (or more generally from the BS) followed by an eDCTS transmission from the UE.

In accordance with some embodiments, the grant request for eDCTS-to-Self may contain the following information, which is shown as an example in Table 5.

Table 5

Information Description Receiver IDs Identify eDCTS-to-Self receivers. UE C-RNTI, gNB cell ID, etc. may be included.
This field may optionally be left blank. Tx Beam Identifiers This field identifies the antenna configuration, such as beams, to be used during eDCTS-to-Self transmissions.

In some embodiments, multiple consecutive eDCTS-to-Self transmissions by a requesting node may have identical content. According to this embodiment, the Backoff Duration field may contain the actual duration of the DL data transmission. In another embodiment, the requesting node may modify the content of consecutive eDCTS-to-Self transmissions. For example, the transmitting node may change the contents of the Backoff Duration field in subsequent eDCTS-to-Self messages.

It should be noted that one or more eDCTS-to-Self transmissions may occur at the same time, eg, coincide with the target UE's eDCTS transmissions.

In FIG. 31 shows an example of downlink data transmission with eDCTS-to-Self message 2650, in accordance with some embodiments. In the example shown in FIG. 31, the gNB sends an eDRTS message 2652 to the UE. As shown, the UE, after successfully decoding the eDRTS message 2652, sends the eDCTS message 2654 to the gNB, and thereafter, the UE also sends the eDCTS-to-Self message 2656 using other antenna or beam configurations to reserve the steered channel. In some embodiments, the directions for eDCTS-to-Self transmission could be configured by the gNB or determined by previous measurements of the directed channel. In addition, in some embodiments, the eDCTS-to-Self transmission may be repeated once in period T (or every given time period) (e.g., based on the minimum CCA duration) during the total duration of the transmission/data exchange between the gNB and the UE. (for example, a MCOT).

In FIG. 32 shows another example of downlink data transmission with both eDCTS-to-Self and uplink transmission 2670 in accordance with some embodiments. In another example, as shown in FIG. 32, the gNB transmits multiple eDCTS-to-Self messages 2676 using other antenna or beam configurations after a successful eDRTS 2672, eDCTS 2674 exchange with the target UE, but before data transmission (eg, DL data transmission 2678) to the target UE. In one embodiment, the number of consecutive eDCTS-to-Self transmissions may be configured by the network or determined by the gNB station based on previous directional channel measurements. The number of consecutive eDCTS-to-Self transmissions may be included in the eDRTS transmission to the target UE. In another design, the UE may include a request for the gNB to perform eDCTS-to-Self transmissions one after the other. This request may be included in the eDCTS message sent in response to the eDRTS message received from the gNB. The request may indicate at least the number of requested consecutive eDRTS-to-Self messages and antenna or gNB beam configurations. In some embodiments, consecutive eDCTS-to-Self transmissions may be repeated once every T period (or every given time period) (e.g., based on minimum CCA duration) during the total transmission/data exchange duration between the gNB and UE (for example, a MCOT).

In some embodiments, eDRTS, eDCTS, and eDCTS-to-Self transmission may occur using a shared downlink channel (eg, PDSCH).

In some embodiments, the gNB may send an eDRTS message to start a downlink transmission, or an eDCTS message in response to an eDRTS message received from one of the associated UEs, or eDCTS-to-Self transmissions, which can be sent in different ways, such as described earlier in this document.

The eDRTS, eDCTS, and eDCTS-to-Self transmission from the gNB may be sent on the downlink shared channel in a variety of ways.

In some embodiments, the eDRTS/eDCTS message from the gNB may, for example, be sent only to the target UE. In the case of eDRTS transmission, the target UE may be a UE receiving downlink data. In the case of eDCTS transmission, the target UE may be the UE that transmitted the eDRTS. The gNB eDRTS/eDCTS message may be sent using a Tx beam paired with the target UE. The UE may receive a control channel transmission on a normal channel (eg, PDCCH). The control information may include downlink control information (DCI) that includes a cyclic redundant parity check (CRC) sequence scrambled using the C-RNTI of the UE. The UE may be configured to recover the DCI and verify it by descrambling the CRC with the C-RNTI.

In the case of an eDCTS-to-Self message from a gNB, the DCI may include a CRC sequence that is scrambled using a scrambling code specific to the UE ID or a gNB/eNB representing the eDCTS-to-Self destination, e.g. C-RNTI , cell ID, etc.

In some embodiments, the DCI may include new flags to indicate transmission as an eDRTS, eDCTS, or eDCTS-to-Self message. This will allow the receiving node to distinguish eDRTS/eDCTS/eDCTS-to-Self messages from other gNB transmission(s) that use the same RNTI to scramble the DCI CRC sequence.

In some other messages, the control information may include a DCI including a CRC sequence scrambled using a scrambling code common to more than one UE or more than one gNB. In the case of eDRTS transmission from a gNB, a generic RNTI, eg RTS-RNTI, can be defined to decode eDRTS messages. In the case of eDCTS transmission from a gNB, a common RNTI, such as CTS-RNTI, may be defined to decode eDCTS messages. In the case of eDCTS-to-Self transmission from a gNB, a common RNTI, such as a custom CTS-RNTI, may be determined for decoding eDCTS-to-Self messages. The receiving node may be configured to recover the DCI and verify it by descrambling the CRC with the appropriate RNTIs, such as RTS-RNTI, CTS-RNTI, and its CTS-RNTI.

In some embodiments, the UE and/or gNB may be preconfigured with RTS-RNTI, CTS-RNTI, and its CTS-RNTI, eg, through system information or UE-specific signaling. RTS-RNTI, CTS-RNTI and own CTS-RNTI may be shared throughout the network. In some alternative embodiments, the RTS-RNTI, CTS-RNTI, and own CTS-RNTI may be shared by an eNB/gNB group and used locally. In some embodiments, the UE may blindly search the UE-specific search space on the PDCCH using the UE C-RNTI and the common search space on the PDCCH using one or more of the RTS-RNTI, CTS-RNTI, and its CTS-RNTI if they are configured.

In some embodiments, in the case of eDRTS transmission, a new DCI format may be used to contain control information for eDRTS transmission in DL and/or eDCTS transmission in UL. In some embodiments, for example, the DCI may contain the following fields: eDRTS flag (when scrambling the DCI CRC sequence with C-RNTI); DL resource block assignment (for transferring eDRTS to DL); MCS (for DL); UL resource block assignment (for UE to transmit eDCTS in UL); MCS (for UL); TPC for PUSCH; and/or resource block assignment (for data transmission after eDRTS and eDCTS transmission)

However, it is understood that in other embodiments, the DCI may be configured differently (eg, the DCI may contain one or more other fields, additional fields, and/or fewer fields than described herein).

According to some embodiments, in addition to the contents of the eDRTS message shown in Table 1, the eDRTS message may also contain a subset of the following information, which is shown as an example in Table 6.

Table 6

Start time Specifies the start time for DL data transmission. This field may be present when the transmission duration field, such as "Remaining Duration of All Transmission", indicates the duration for the DL data transmission only. Number of eDCTS Indicates the number of eDCTS transmissions requested. Order of eDCTS Specifies the order in which the eDCTS is transmitted. Alternatively, the entire eDCTS transmission order may be specified, eg using a bitmap containing beam identifiers corresponding to transmission intervals. In an alternative embodiment, the requested transmitter (e.g., an eNB/gNB transmitting eDRTS) may be indicated with an eDCTS transmission schedule, e.g., via a single bit to indicate whether the eDCTS is transmitted to the requesting transmitter for the first or last time within a scheduled resource allocation involving multiple transmissions. eDCTS. Tx Beam ID This field identifies the antenna configuration, eg beam, to be used during the subsequent DL data transmission.

In some embodiments, in the case of eDCTS transmission from gNB, a new DCI format may be used with the ability to contain control information for eDCTS transmission in DL and/or data transmission in UL. In some embodiments, for example, the DCI may contain the following fields: eDCTS flag (when scrambling the CRC sequence in DCI with C-RNTI); resource block assignment (for transferring eDCTS in DL); MCS (for DL); resource block assignment (for data transmission in the UL by the UE); MCS (for UL); and/or TPC for PUSCH.

However, it is understood that in other embodiments, the DCI may be configured differently (eg, the DCI may contain one or more other fields, additional fields, and/or fewer fields than described herein).

In accordance with some embodiments, in addition to the contents of the eDCTS message shown in Table 2, the eDCTS message may also contain a subset of the following information, which is shown as an example in Table 7.

Table 7

Start time Specifies the start time for DL data transmission. This field may be present when the transmission duration field, such as "Remaining Duration of All Transmission", indicates the duration for the DL data transmission only. Remaining number of eDCTS Indicates the number of remaining eDCTS transmissions in the current sequence. This field may be present when the transmission duration field indicates the duration for DL data transmission only. Tx Beam ID This field identifies the antenna configuration, eg beam, to be used during subsequent DL data transmission by the requesting node, eg eNB/gNB.

In some embodiments, in the case of an eDCTS-to-Self message from a gNB, the DCI may contain a resource block assignment for the eDCTS-to-Self message and a flag, i. e. eDCTS-to-Self flag, when scrambling the DCI CRC sequence for an eDCTS-to-Self message using C-RNTI.

According to some embodiments, in addition to the content of the eDCTS-to-Self message shown in Table 4, the eDCTS-to-Self message may also contain a subset of the following information, which is shown as an example in Table 8.

Table 8

Start time Specifies the start time for DL data transmission. This field may be present when a transmission duration field, such as the Backoff Duration field, indicates a duration for DL data transmission only. Target receiver ID Identifies the receiver of the data transfer. Tx Beam ID This field identifies the antenna configuration, eg beam, to be used during the subsequent DL data transmission.

In some embodiments, the UE may be configured to receive more than one eDRTS/eDCTS transmission from a requesting gNB (in the case of an eDRTS transmission) or a responding gNB (in the case of an eDCTS transmission). This may occur when the requesting gNB (in the case of an eDRTS transmission) or the responding gNB (in the case of an eDCTS transmission) may repeat eDRTS/eDCTS transmissions using different antenna configurations, such as different beams. In one embodiment, the content of the message in eDRTS/eDCTS transmissions may be identical. The eDRTS/eDCTS message may include transmission start time and transmission duration fields to indicate the actual DL data transmission schedule.

In some embodiments, the content of multiple eDRTS/eDCTS transmissions may be different from each other. For example, in some embodiments, the transmission duration field in each consecutive transmission of an eDRTS/eDCTS message may be reduced by the amount required to transmit a single eDRTS/eDCTS message. In one embodiment, the receiving (or destination) UE may stop the receiving process after successfully receiving the eDRTS/eDCTS transmission in the current assignment.

In some embodiments, the content of the eDRTS/eDCTS/eDCTS-to-Self message may be scrambled using a sequence that is common to a group of cells, such as a Cell Group Sequence (CGS). In one embodiment, a common CGS may be used for the entire operator's network. In another embodiment, one CGS may be specific to a frequency channel or subband (eg, all devices operating on a specified frequency channel or subband may support the same CGS).

In yet another embodiment, the UE may be configured with multiple CGSs. To read the contents of the message, the UE may perform blind decoding on the eDRTS/eDCTS/eDCTS-to-Self transmission with each of the configured CGSs. In some alternative embodiments, the DCI may be associated with the eDRTS/eDCTS/eDCTS-to-Self message and may contain information about, for example, the configuration for the CGS used to scramble the subsequent eDRTS/eDCTS/eDCTS-to-Self message.

In some embodiments, in the case of eDRTS transmission from a gNB, a UE attached to another cell may configure a UE receive antenna pattern, such as a beam pattern, to subsequently receive the eDCTS based on the CGS obtained from successful descrambling of the eDRTS message.

In some embodiments, the UE may be configured with CGS, eg, through system information or higher layer control messaging, such as RRC messages.

In some embodiments, in the case where the eDRTS/eDCTS message can only be sent to the target UE, the eDRTS/eDCTS message can be scrambled using a sequence generated by the cell ID and a UE-specific RNTI, such as C-RNTI. The contents of the eDCTS-to-Self message may be scrambled using a sequence generated by a target receiver identifier, such as C-RNTI, cell identifier.

It should be noted that in the contents of the eDCTS message, as shown, for example, in Table 2, the "receiver identifier" field may be the same as the C-RNTI of the UE. In an alternative embodiment, the receiver identifier may be another identifier that is configured using, for example, a control channel signal, higher layer signaling, and so on.

In some embodiments, eDRTS, eDCTS, and eDCTS-to-Self transmission may occur using an uplink shared channel (eg, PUSCH).

In some embodiments, the UE may send an eDRTS message to request an uplink transmission, or an eDCTS message in response to an eDRTS message received from a BS (base station) associated with the UE, or an eDCTS-to-Self transmission, which may be sent in different methods as described above in this document.

The eDRTS, eDCTS, and eDCTS-to-Self transmission from the UE may be sent on the uplink shared channel in a variety of ways.

In some embodiments, the UE may receive a control channel transmission on a common channel (eg, PDCCH). The received control information may include a DCI containing a grant for uplink transmission, such as a physical uplink shared data channel (PUSCH).

In some embodiments, the implementation of the DCI may contain allocation for one transmission of eDRTS/eDCTS/eDCTS-to-Self by the UE to the associated BS, for example eNB/gNB. The eDRTS/eDCTS message may be sent using a Tx beam (transmission) paired with the associated UE.

In another embodiment, the DCI may comprise allocation for multiple, eg more than one, eDRTS/eDCTS/eDCTS-to-Self transmissions by the UE. However, in some embodiments, the UE may determine the number of eDRTS/eDCTS/eDCTS-to-Self transmissions. For example, the UE may transmit a single eDRTS/eDCTS/eDCTS-to-Self message in an allocation that may accommodate multiple, eg, more than one, eDRTS/eDCTS/eDCTS-to-Self transmissions.

In some embodiments, the eDRTS/eDCTS message may include a field to indicate the number of eDRTS/eDCTS transmissions. In one embodiment, the number indicated in this field may refer to the total number of eDRTS/eDCTS transmissions in the current sequence. In another embodiment, this number may refer to the remaining number of eDRTS/eDCTS transmissions in the current sequence.

In some embodiments, the UE may transmit the eDRTS/eDCTS to the associated BS first in a sequence of multiple eDRTS/eDCTS transmissions. In other embodiments, the UE may transmit the eDRTS/eDCTS to the associated BS last in a sequence of multiple eDRTS/eDCTS transmissions. In one design, the UE may not include a field to indicate the total number of eDRTS/eDCTS transmissions in the current sequence. In yet another embodiment, the UE may transmit an eDRTS/eDCTS message to an associated BS at a random location in a current sequence of multiple eDRTS/eDCTS transmissions.

In some embodiments, the UE may determine if the channel can be free to transmit a specified duration prior to the start of a scheduled eDRTS/eDCTS transmission. In some embodiments, the monitoring duration may be preconfigured on the UE or may be known to the UE. For example, the UE may perform CCA (eg, LBT) for monitoring duration. The determination (eg, CCA) may be performed prior to the start of a possible transmission.

In some embodiments, in the case of eDCTS transmission, when the UE correctly receives the eDRTS message on the DL and determines that the channel can be available for the monitoring duration, the UE may send (eg, start transmission) the eDCTS message in the assigned resources. When the UE correctly receives the eDRTS message on the DL and determines that the channel may be busy, eg, based on the CCA, the UE may not transmit the eDCTS message in the assigned resource. The UE may delay the transmission, for example, to a later time.

In some embodiments, in the case of an eDRTS transmission, when the UE determines that a channel may be available for the monitoring duration, the UE may transmit (eg, start transmission) an eDRTS message in the assigned resources. When the UE determines that the channel may be busy, eg, based on the CCA, the UE may not transmit an eDRTS message on the assigned resource. The UE may delay the transmission, for example, to a later time. In general, the transfer may depend on its compliance with the remaining time resources of the scheduled allocation.

In some embodiments, the UE may be configured to transmit multiple eDRTS/eDCTS messages at the same time. eDRTS/eDCTS serial transmissions may use different antenna configurations, such as different beams.

In one embodiment, multiple eDRTS/eDCTS transmissions from a UE may have different content. The eDRTS/eDCTS message may contain transmission start time and transmission duration fields to indicate the actual data transmission schedule.

In other embodiments, the UE may change the content of eDRTS/eDCTS messages transmitted using different antenna configurations, such as different beams. In one embodiment, the UE may decrease the transmission duration field in each consecutive eDRTS/eDCTS message transmission by the amount required to transmit one eDRTS/eDCTS message.

In some embodiments, the content of the eDRTS/eDCTS/eDCTS-to-Self message may be scrambled using a sequence that is common to a group of cells, such as CGS. In one embodiment, a common CGS may be used for the entire operator's network. In another embodiment, one CGS may be specific to a frequency channel or subband (eg, all devices operating in a subband of a frequency channel may support the same CGS).

In yet another embodiment, the UE may be configured with multiple CGSs. The UE may use any of the configured CGSs, eg, randomly. In some other alternative embodiments, the DCI may be associated with the eDRTS/eDCTS/eDCTS-to-Self message and may contain information about, for example, the configuration for the CGS to be used to scramble the subsequent eDRTS/eDCTS/eDCTS-to-Self message. In some embodiments, the UE may be configured with CGS, such as through system information or higher layer control message exchange, such as an RRC message.

In some embodiments, eDRTS, eDCTS, and eDCTS-to-Self transmission may occur using a common uplink channel.

It should be noted that in some embodiments, the UE may not receive any specific UL resource grant in advance from the BS associated with the UE, eg eNB/gNB, for the purpose of eDRTS/eDCTS/eDCTS-to-Self transmission. If the UE determines that the eDRTS/eDCTS/eDCTS-to-Self transmission was not granted the resource(s), in some embodiments, the UE may transmit the eDCTS using the UL resource(s) without grant.

In some embodiments, a channel without a UL grant may, for example, be scheduled in one or more of the following ways, which are described, for example, below.

A channel without a UL grant may reside in one or more subframes in each frame or specific frame(s), e.g. frame(s) with specific SFN number(s) or frame(s) with SFNs with specific properties. These subframes and/or frames and/or frame properties may be fixed or may be a function of the physical cell identifier (cell ID).

The UE may be preconfigured with a channel location without providing a UL, for example, through system information, downlink broadcast information, or UE-specific signaling. The sequence and/or identifier to be used for channel scrambling without granting a UL may be common to a group of cells, such as CGS. In one embodiment, a common CGS may be used for the entire operator's network. In another embodiment, one CGS may be specific to a frequency channel or subband (eg, all devices operating on a frequency channel or subband support the same CGS). In yet another embodiment, the UE may be configured with multiple CGSs.

The UE may be configured with multiple CGSs, eg, through system information or higher layer control messaging such as RRC messages.

The gNB and/or the UE may be configured to listen and decode the channel without granting a UL.

A demodulation reference signal (DM-RS) based transmission may be used. The sequence for outputting the DM-RS may be based on a common sequence such as CGS. In one embodiment, the sequence for deriving the DM-RS may be based on a UE-specific sequence. The position of the DM-RS in the allocated resources may be fixed, known, or configurable.

In some embodiments, the UE may wait some time from the start of resources without granting a UL. The waiting time can be determined, for example randomly. After waiting, the UE may first determine if the channel can be free to transmit for a specified amount of time before any transmission. The monitoring duration may be pre-configured on the UE or may be known to the UE. For example, the UE may perform CCA (eg, LBT) for monitoring duration. The determination (eg, CCA) may be performed prior to the start of a possible transmission. After a successful CCA, the UE transmits eDRTS/eDCTS/eDCTS-to-Self over the resources without granting a UL.

In some embodiments, in the case of an eDCTS-to-Self transmission, the UE may signal in the eDRTS message (in the case of uplink) or in the eDCTS message (in the case of transmission on the downlink), the number of eDCTS-to-Self messages to inform the BS . In some embodiments, this information may be sent along with beam identifiers, such as beams to be used during eDCTS-to-Self transmissions.

In some embodiments, eDRTS transmissions may occur using dedicated resources on an uplink control channel (eg, PUCCH).

In some embodiments, the UE may represent dedicated dedicated resources on the PUCCH for eDRTS transmission in various manners. Dedicated resources may reside in one or more subframes in each frame or specific frame(s), such as frame(s) with specific SFNs or frame(s) with SFNs with specific properties. These subframes and/or frames and/or frame properties may be fixed or may be a function of the physical cell identifier (cell ID). The allocated resources may be assigned in character set, short TTI, mini-slot, and/or the like. The allocated resources may be assigned in a set of one or multiple subcarriers. In addition, a demodulation reference signal (DM-RS) transmission may be provided. In this case, the position of the DM-RS in the allocated resources may be fixed, known and/or configurable.

In some embodiments, an eDRTS message on dedicated resources may be scrambled using a UE-specific scrambling sequence.

The UE may be preconfigured with a dedicated resource allocation and further configured with a UE-specific scrambling sequence, eg, through a higher layer signaling message, such as an RRC connection setup, or through system information.

In some embodiments, when the UE is to transmit eDRTS, it first performs CCA until the next available allocated resource opportunity. After a successful CCA, the UE transmits the eDRTS over the allocated resource.

In some embodiments, non-target UE behavior and neighbor gNB/eNB behavior when receiving eDRTS/eDCTS/eDCTS-to-Self is described.

Namely, in some embodiments, a non-target UE or neighbor BS that receives an eDRTS and/or eDCTS and/or eDCTS-to-Self transmission including an Other Cell Identifier or an Other UE Identifier (e.g., C-RNTI) cannot transmit over the channel for the duration of the transmission specified in the message. The transmission duration may be specified for the entire message exchange, including the remaining eDRTS, eDCTS, eDCTS-to-Self transmissions and subsequent data transmission. In an alternative embodiment, the duration of the transmission may be specified in terms of start time and duration.

In some embodiments, a UE belonging to a neighbor cell or a neighbor BS that receives eDRTS and/or eDCTS and/or eDCTS-to-Self transmissions containing another cell identity or another UE identity (e.g., C-RNTI) may transmit on a frequency channel or subband, upon determination that there is no possible interference to the subsequent transmission associated with the received eDRTS/eDCTS/eDCTS-to-Self message.

In some embodiments, the non-target UE or neighbor BS may determine that the steered channel transmission cannot interfere with the intended steered data link transmission between the eDRTS/eDCTS/eDCTS-to-Self transmitter and the corresponding receiver. In some embodiments, such a determination may be made by first determining the direction of the intended data transfer. In yet another embodiment, the direction of the intended transmission may be determined from the Target Receiver ID and Requesting Transmitter ID fields contained in the eDRTS/eDCTS/eDCTS-to-Self message. This may be possible when the receiving non-target UE or neighbor BS knows the location and orientation of the transmitter and receiver. In yet another embodiment, if possible, this determination may be based on the Requesting Transmitter Identifier and Tx Beam Identifier fields of the eDRTS/eDCTS/eDCTS-to-Self message.

Assuming that a non-target UE belonging to a neighbor cell or a neighbor BS can, after exchanging eDRTS, eDCTS, and eDCTS-to-Self messages (if any), determine whether their directional channel transmission (e.g., UL or DL transmission) can not interfere with directional channel transmission between the BS and the target UE, in which case the UE or the neighboring BS may perform parallel (eg, simultaneous) directional transmissions.

After the expiration of the transmission duration, in some embodiments, the UE or BS may first determine if the channel can be free to transmit for the specified duration prior to any subsequent transmissions. The monitoring duration may be pre-configured or may be known to the UE or BS. For example, the UE may perform CCA (eg, LBT) for monitoring duration. The determination (eg, CCA) may be performed prior to the start of a possible transmission.

In FIG. 33 shows an example of eDRTS, eDCTS, and eDCTS-to-Self transmission 2700 in accordance with some embodiments. In this example, an eDRTS transmission may be sent using a downlink shared channel such as a PDSCH, and an eDCTS transmission may be sent using dedicated resources on an uplink shared channel. In downlink transmission, an eDCTS-to-Self transmission is additionally used to protect the current transmission.

As shown in FIG. 33, at step 2701, a transmitting node, such as the gNB in FIG. 33 may first perform CCA to determine if a channel is busy/free for transmission. After the gNB determines that the channel is idle, in step 2702, it may send a new DCI on a common downlink channel, such as PDCCH, to the receiving node, which in FIG. 33 is the target UE. DCI may be scrambled using a common RNTI. The shared RNTI may be shared by more than one UE, or shared across the entire network, such as, for example, SI-RNTI. In addition, the DCI may contain DL and UL resource allocations for eDRTS transmission and eDCTS transmission, respectively. At 2704, a gNB may send a plurality of eDRTS, including at least one eDRTS message sent towards a target UE and at least one eDRTS message sent towards a non-target UE and/or neighbor gNB, as shown in FIG. 33. For example, if configured, the gNB may perform eDRTS retransmissions 2706 in multiple directions, as shown in FIG. 33. The gNB may perform multi-directional eDRTS transmissions 2706 to, for example, reserve a channel in a wider area around a receiving node, such as a target UE.

In some embodiments, each transmitted eDRTS message may include a target UE identifier, a requestor identifier (gNB), a transmission duration (Tx duration), a start time, a Tx beam (transmission) identifier, etc. The eDRTS message may further be scrambled using the CGS, which may be common to a group of cells, for example.

When the target UE receives the eDRTS from the gNB, at 2708, the target UE may decode the eDRTS and determine whether the UE ID specified in the eDRTS matches the target UE ID. Similarly, when the non-target UE and/or neighbor gNB receive eDRTS from the gNB at 2710, the non-target UE and/or neighbor gNB can decode the eDRTS and determine that the UE ID included in the eDRTS does not match the target UE ID. In addition, the non-target UE and/or neighbor gNB may receive the decoded eDRTS transmission duration (or at least an indication thereof). Accordingly, as indicated by time period 2712, the non-target UE and/or neighbor gNB may not initiate transmission(s) for the Tx duration obtained from the received eDRTS message. As a result, the non-target UE and/or neighbor gNB can be prevented from interfering with transmissions between the gNB and the target UE for at least this period of time.

At 2714, the target UE may perform a CCA to check if the channel is busy. After the UE determines that the channel is idle, at 2716, the target UE may send one or more eDCTS messages towards the gNB. For example, as shown in FIG. 33, the target UE may perform multiple eDCTS transmissions 2718 in multiple directions if configured. 2718 eDCTS messages may be transmitted over allocated resources using a shared channel such as PUSCH, and each eDCTS message may be scrambled using CGS. Upon receipt of the eDCTS transmission(s) from the target UE, in step 2720, the gNB may begin transmitting downlink (DL) data. The DL data transmission may be followed by one or more eDCTS-to-Self transmissions over a period T (denoted as 2724 in FIG. 33), which may, for example, correspond to a minimum LBT duration. For example, as shown in FIG. 33, the gNB may perform multiple eDCTS-to-Self transmissions 2722 in multiple directions, if configured, during period 2724. ) the channel between the gNB and the target UE, reserved with protection against access by potentially interfering nodes.

If the gNB has additional data to send, at step 2726 it sends additional DL data to the target UE. As shown in FIG. 33, the DL data transmission may again be followed by one or more gNB eDCTS-to-Self transmissions. For example, as shown in FIG. 33, the gNB may perform multiple eDCTS-to-Self retransmissions 2722 in multiple directions (if configured).

In FIG. 34 shows an example of non-target UE 2800 behavior after receiving eDRTS and eDCTS from another cell, in accordance with some embodiments. In this example, as shown in FIG. 34, after receiving eDRTS and eDCTS from another cell, the non-target UE determines the non-interfering transmission direction and sends the eDRTS using the uplink common channel to the BS associated with the UE to start uplink transmission.

Namely, as shown in FIG. 34, at step 2801, a transmitting node, such as gNB1 in FIG. 34 may transmit on a downlink shared channel such as a PDSCH a plurality of eDRTS, including at least one eDRTS message sent towards a receiving node, such as a target UE associated with gNB1, and at least one eDRTS message. transmitted towards a non-target UE associated with, for example, a neighbor gNB (gNB2) as shown in FIG. 34. For example, if configured, gNB1 can perform eDRTS retransmissions 2802 in multiple directions, as shown in FIG. 34. In some embodiments, each transmitted eDRTS message may be scrambled using CGS and include target UE ID, requestor ID (gNB1), transmission duration (Tx duration), start time, Tx beam (transmission) ID, etc. e. The CGS may be common to a group of cells. When the target UE receives the eDRTS from gNB1, in step 2804, the target UE may decode the eDRTS and determine whether the UE ID specified in the eDRTS matches the target UE ID. Similarly, when a non-target UE receives eDRTS from a gNB, at 2806, the non-target UE may decode the eDRTS and determine that the UE ID specified in the eDRTS does not match the non-target UE ID.

As also shown in FIG. 34, at 2808, the target UE may send one or more eDCTS messages. For example, as shown in FIG. 34, the target UE may perform multiple eDCTS transmissions 2810 in multiple directions if configured. The eDCTS messages may be transmitted over previously allocated resources (eg, resources allocated by gNB1) using a shared channel such as PUSCH, and each eDCTS message may be scrambled using CGS. As shown in FIG. 34, the multiple retransmissions of eDCTS message 2810 may include at least one eDCTS transmission towards a non-target UE. Accordingly, the non-target UE may receive one of the eDRTS and eDCTS messages, or both. If the non-target UE receives the eDCTS, at 2812 it may decode the eDCTS. At 2814, the non-target UE may determine a non-interfering transmission direction or a transmission direction that will not interfere with transmissions between gNB1 and the target UE. In some embodiments, for example, the non-target UE may determine the non-interfering direction of transmission based on information about the respective location and orientation of the transmitter and receiver (eg, gNB1 and the target UE, as in the case depicted in FIG. 34). In this regard, the appropriate location and orientation of the transmitter/receiver can be used to identify a beam that the non-target UE can use for transmission that will not, for example, interfere with reception at the target UE. In other embodiments, the non-target UE may have past measurements from which the non-target UE may extract information regarding the non-interfering transmission direction.

After determining a non-interfering transmission direction in step 2816, the non-target UE may perform one or more eDRTS transmissions directed to the gNB2 associated with that UE. For example, as shown in FIG. 34, a non-target UE may perform multiple repeated eDRTS transmissions 2818 in multiple directions if configured. Each eDRTS message transmitted by the non-target UE may be scrambled using the associated CGS and sent on a common or ungranted uplink channel. After the eDRTS transmission(s) from the non-target UE, in step 2820, the gNB2 may transmit a new DCI to the non-target UE on a common downlink channel such as PDCCH. The DCI may contain eDCTS resource allocation information. DCI may be scrambled using a common RNTI. The shared RNTI may be shared by more than one UE, or shared across the entire network, such as, for example, SI-RNTI. As indicated in the DCI transmission, at 2822, the gNB2 may transmit one or more eDCTS messages to a non-target UE on a common downlink channel (eg, PDSCH). For example, if configured, gNB2 can perform eDCTS retransmissions 2824 in multiple directions, as shown in FIG. 34. Each of the eDRTS messages may be scrambled using CGS and transmitted by gNB2 on a common downlink channel such as PDSCH.

In accordance with some embodiments, implementations related to cooperative operation of NR-WiGig directional systems in unlicensed bands may also be provided.

The WiGig device may use a detection threshold (eg, a higher detection threshold) for non-WiGig system transmission(s) that may or may not have (eg, special) preamble in CCA processing. A WiGig device may back off if, for example, it senses more interference from non-WiGig devices than interference from WiGig devices. The NR transmission may use short periodic transmissions (eg, over a mini-slot) in the reverse direction (eg, opposite to the intended direction of communication). Exposure of WiGig devices may occur due to this.

When NR and WiGig co-operate, for example, the NR device(s) (e.g., gNB and/or UE) can use (e.g., the same) channel CCA and/or (e.g., the same) a channel reservation procedure as described in relation to the NR-NR co-operation scenario, applying one or more of the following modifications. Namely, the NR device may use the transmission of (eg, one) block from the receiving node during (eg, every) minimum contention window. The NR device may use the transmission of multiple blocks from the receiving node during (eg, each) minimum contention window. The NR device may use an increase in block transmit power from the receiving node during (eg, every) minimum contention window.

In some embodiments, one of the following may be applied, for example, regarding the use of transmitting (eg, one) block from the receiving node during (eg, each) minimum contention window.

The transmission of the DL/UL switching configuration for NR transmission may be determined based on the (eg, minimum) duration of the distributed interframe interval (DIFS) of the WiGig system. In FIG. 9 shows an example DL/UL switchover configuration 850 for an NR-WiGig coexistence scenario, in accordance with some embodiments. For example, as shown in FIG. 9, the reverse transmission from the UE to the gNB on the beam corresponding to the Rx beam on which the forward transmission from the gNB was received can be repeated within the minimum contention window (minimum CW) (e.g., after successful LBT and successful decoding of eDRTS 852 followed by an eDCTS message 854 as shown in Fig. 9). The minimum CW may be set to the minimum distributed interframe interval (DIFS) duration of the WiGig system. As seen in FIG. 9, "D" may be defined as a minimum data or control block interval that can contain a meaningful data packet (eg, symbol, mini-slot, and/or the like). The reverse direction can be defined as the direction from the receiving node to the transmitting node.

In the example DL/UL switching configuration 850 shown in FIG. 9, for example, one power-controlled mini-slot steered transmission may be used, for example, to back off WiGig devices. As shown in FIG. 9, due to power controlled burst transmissions 856 (eg, burst transmissions below the maximum allowable (max) Tx power at the UE as shown in FIG. 9) in the reverse direction, device(s) latency is likely to occur. The device(s) may be within range, which may be relatively short.

The example in FIG. 9 may correspond to NR-WiGig cooperative non-interfering operation as illustrated by the example in FIG. 10. Namely, in FIG. 10 shows an example forward and/or reverse link beam coverage for an NR-WiGig cooperative non-interfering operation scenario, in accordance with some embodiments. As seen in FIG. 10, STA 900 and gNB 902 may not interfere with each other. This may be due to directed transmissions (eg, DL directed transmissions from gNB 902 to UE 906 may not interfere with STA 900, and/or UL directed transmissions from STA 900 to AP 904 may not interfere with gNB 902). The distance between AP 904 and UE 906 may be large. The co-operation scenario shown in FIG. 10 may be called a non-interfering scenario because, for example, AP over DL transmissions may interfere (eg, limited interference) to UE 906. The interference may be negligible. Interference may be due to distance and/or propagation loss. UE transmissions over UL may interfere with AP 904, which may be due to distance (and/or associated propagation loss). The distance may be large. The interference may be limited and/or negligible.

In some embodiments, one of the following may be applied, for example, regarding the use of transmitting multiple blocks from the receiving node during (eg, each) minimum contention window.

The receiving node may transmit a plurality of blocks (blocks of size "D") in the direction of the transmitting node. This may, for example, increase the range of interference (eg, to increase the likelihood of exposure to potentially interfering AP nodes of the WiGig system, as shown in FIG. 12). In FIG. 12 shows an example forward and/or reverse link beam coverage for a UE AP interference scenario in NR-WiGig co-operation in accordance with some embodiments. In the example in FIG. 12 due to a backhaul, the AP 1000 of the WiGig system cannot be backed off. In FIG. 11 shows a plurality of "D" block transmissions in the reverse direction (eg, in the direction of the transmitting node). Namely, in FIG. 11 shows another example of a DL/UL switchover configuration 950 for an NR-WiGig coexistence scenario, in accordance with some embodiments.

As shown in FIG. 11, there is a possible limit that may be defined on the reverse link to indicate the number (M) of D blocks 952 (eg, the allowable number of D blocks) used at a given power. The value of M may be determined based on the QoS and/or mapped to a finite integer. The same DL/UL switching configuration method can be applied to all types of QoS and/or mappings, for example. Sending multiple blocks 952 in the reverse direction can also be used in an NR-NR co-operation scenario.

In the configuration example shown in FIG. 11 may be used, for example, to transmit a plurality of reverse mini-slots to back-off WiGig devices. This can be used, for example, for the interference scenario depicted in FIG. 12. As seen in FIG. 12, AP 1000 may interfere with (eg, significantly interfere with) UE 1002. This may be due to the shorter distance between AP 1000 and UE 1002. As seen in FIG. 12, AP interference to a UE is highlighted as a dotted line.

In some embodiments, one of the following may be applied, for example, with respect to using transmission of increased power blocks from the receiving node during a minimum contention window, eg, each minimum contention window.

In the reverse link (eg, transmissions of the receiving node in the direction of the transmitting node), higher power can be used. This may occur, for example, followed by a more possible initiation of an interfering transmission backoff. This can be seen in FIG. 13 and/or can be used, for example, for the interference scenario depicted in FIG. 14. Namely, in FIG. 13 shows an example DL/UL switching configuration 1050 for an NR-WiGig co-operation scenario using higher power and multiple mini-slot backup transmissions to endure WiGig devices, in accordance with some embodiments. In FIG. 14 shows an example forward and/or reverse link beam coverage for an NR-WiGig co-operation interference scenario in accordance with some embodiments. In the example in FIG. 14, AP transmission(s) over DL may interfere with UE 1100 and/or AP 1102 may interfere with UE transmission(s) over UL. This may be due to the distance between the nodes.

For example, in FIG. 13 during the (eg, initial) receive process, in which the UL/DL link quality may be set, the reverse link may start (eg, only) with, for example, transmitting one power-controlled block (length D) towards the gNB. , as shown in FIG. 9. The UE may determine the presence of interference, eg, based on a measured signal-to-interference ratio (SIR), and/or it may decide to transmit (eg, one) block D at, eg, the maximum allowable power Tx. If, for example, the UE still receives the interference, it may increase the number of D blocks 1052 on the reverse link at (eg, the maximum) allowed power. This may continue until, for example, the UE uses M D blocks 1052 (M may be predetermined based on the QoS mapping for the useful forward link from the gNB to the UE and/or from the UE to the gNB). If, for example, the UE is still receiving interference, it may still use the link by choosing a (eg, lower) MCS index that may be appropriate for the (eg, measured) SIR.

In some embodiments, a transmission using higher power in the reverse direction, as described above herein, may also be used for an NR-NR co-operation scenario.

As shown in FIG. 14 due to the use of the scheme for transmission in the reverse direction (eg, for transmission by UE 1100) discussed herein in connection with FIG. 13, for example, interfering node dwell time and/or interference attenuation may occur. For example, due to UE 1100 postback, there is a possibility of AP 1102 backlog of the WiGig system.

Transmission in the reverse direction using higher power, as discussed, can be sent on a wider beam than the Rx beam on which the direct transmission is received. The wider beam may be centered along the same direction as the Rx beam on which the forward transmission is received. In an alternative embodiment, the reverse transmission may be sent on a plurality of adjacent beams around the Rx beam on which the forward transmission is received. If, for example, the direction of the interferer is known to the receiver, a return transmission can only be sent on beams that point towards the interferer. The decision regarding the transmit power level and the number of blocks D on any beam can be made by the same procedure as described above.

In some embodiments, implementations related to paired LBT may be provided.

Directed LBT can be estimated in the direction of the receiving node (as in the case of legacy LBT or in WiGig) and/or in opposite directions. For example, this avoids the interference situation shown in FIG. 3A and/or 3B or 4A and/or 4B. If the transmitting node performs LBT aligned in the direction of the receiving node ("dir"), the LBT may be performed in the (eg, opposite(s)) direction(s) dir + X°. These directions may represent: a single direction (eg dir, dir + 180°, minor direction) and/or a set of directions (eg dir + 180°, dir + 160°, dir + 200°). This may depend on the ability to configure or pre-determine the beam(s) for the LBT (eg, based on a set of previously configured beams). Such a case may be referred to as "paired LBT". Paired LBT may include LBT on "paired directions", which may mean direction towards the receiving node, opposite direction(s) and/or direction(s) towards the expected interferers. In the case of a paired LBT, it is possible to store the backlog and/or contention window status for each paired directions. This makes it possible, for example, to reduce (for example, by a factor of 2) the memory that can be used to track the soak processes for each path compared to tracking for each contention window.

In the example shown in FIG. 3A and/or 3B, the transmitting node may be a gNB and the receiving node may be a UE. If the gNB performs a paired LBT (eg, to estimate link availability), the AP handoff may be detected on the gNB and/or the handover of the gNB may be delayed. This can prevent AP interference to UE (as seen in FIG. 3A and/or 3B) and/or gNB interference to STA can be prevented (as seen in FIG. 3B).

In the example shown in FIG. 4A and/or 4B, the transmitting node may be a UE and the receiving node may be a gNB. If the UE performs a paired LBT (eg, to estimate channel availability), the UE may detect channel occupancy, which may be due to the AP's transmission, and/or the UE's transmission may be delayed. By doing this, interference from the AP to the gNB can be prevented (as seen in FIG. 4A and/or 4B) and/or interference from the UE to the STA can be prevented (as seen in FIG. 4B).

Paired LBT may be performed (eg, simultaneously) in the direction of the receiving node and/or in the opposite direction(s). This can happen (eg, whenever) when it is necessary to transmit from a transmitting node to a receiving node (eg, by using multiple radio frequency (RF) chains and/or a single RF chain with advanced sampling techniques). In order to proceed to data transmission, at (eg, all) energy detection (ED) stages during LBT, the channel may be recognized as inactive for a known period (eg, at least DIFS with dwell time).

With a paired LBT, it is possible to successfully access a medium while cooperating (eg, different) RATs with directional channel transmissions/receptions and/or it is possible to minimize the hidden node problem. Paired LBT can be used as a spectrum sharing technique within a (eg, single) RAT (eg, NR or WiGig), for example, when coordination between RAT nodes may not be possible, for example. For example, such coordination may not be possible if operators use, for example, the same unlicensed band and decide not to coordinate the respective networks.

With respect to a paired LBT, for example, as described herein, the transmit and/or receive directional antenna patterns may be described by one or more of the following parameters. The directional transmit antenna pattern may include: main lobe gain G _Tx,m with beamwidth θ _Tx and/or sidelobe gain G _Tx,s with beamwidth 2π-θ _Tx . The receive directional antenna pattern may include: main lobe gain G _Rx,m with beamwidth θ _Rx and/or sidelobe gain G _Fx,s with beamwidth 2π-θ _Fx .

In FIG. 15A shows an example of a paired LBT in one opposite direction, in accordance with some embodiments. In FIG. 15B shows an example of a paired LBT in multiple opposite directions, in accordance with some embodiments. The data exchange may be performed between the transmitting node and/or the receiving node. In FIG. 15A and 15B show DL communication (where, for example, gNB 1200 may be the transmitting node and UE 1202 may be the receiving node). However, in other embodiments in FIG. 15A and 15B, communication can be performed in the reverse direction (eg, UL communication (from UE to gNB)), for example, when changing back positions of gNB and UE.

In FIG. 15A and 15B show hypothetical beam simulation situations. The transmitting node (gNB 1200) may perform LBT in the direction of the Tx beam (e.g., the beam that can be used by the transmitting node to transmit data in the direction of the receiving beam) aligned towards the receiving node ("dir") and beamwidth θ _Tx (LBT _dir ). The transmitting node may (eg, simultaneously) perform: LBT in one opposite direction (eg, LBT _dir+180° ) with beam aligned in opposite direction dir+180°, main beam beamwidth θ _sup , and/or gain G _sup,m the main lobe (as seen in Fig. 15A); and/or a plurality of LBTs in a plurality of opposite directions (eg, LBT _dir+180° , LBT _dir+160° , LBT _dir+210° ). Each of the multiple LBTs may have a beam aligned in opposite directions dir+X° (e.g., X = 160°, 180°, 200°), a main beam beam width θ _sup , and/or a main beam gain G _sup,m (as seen in Fig. 15B).

The beam used for LBT in the opposite direction(s) may be in the form of a Tx beam 1204 of the transmitting node (e.g., θ _sup =θ _Tx as seen in FIGS. 15A and 15B) and/or a different radiation pattern (as described in more detail below).

To illustrate the hidden node(s) in FIG. 15A and 15B show the Rx beam 1206 of the receiving node. AP 1208 may be a hidden node for a legacy LBT if, for example, its transmission lies within the electrical axis of the receiving node's Rx antenna. The paired LBT procedure that is described herein can mitigate (eg, some) hidden node problems (as seen in allowed hidden node region 1210 in FIGS. 15A and 15B). APs (eg, all APs) that may be located within the allowed hidden node area 1210 can be discovered at the transmitting node (eg, on gNB 1200 for DL traffic) via paired LBT. Detection of this by an unpaired legacy LBT at the transmitting node (eg, gNB 1200 for DL traffic) may not be possible. Area 1212 may represent an unsecured area in which an insecure host problem may occur. As area 1214 in FIG. 15A and 15B may show the region of the remaining/still hidden node, which may be smaller than the region of the hidden node, such as the legacy LBT.

In FIG. 15B shows symbols that may be used with reference to, for example, FIG. 15A, 15B, 16, 17A and 17B.

In some embodiments, the paired LBT in the direction of the receiving node and the opposite direction(s) may be performed with different beam patterns and/or different ED thresholds, for example, to maximize the number of hidden node terminals to be discovered. For LBT in the opposite direction(s), multiple beams can be used, for example, if beam patterns cannot be corrected at the transmitting node, but are predetermined. At the transmitting node, correction of the beam pattern, the number of beams and/or the ED threshold for the LBT in the opposite direction(s) may be performed. This may occur when information about the Rx beam of the receiving node and/or system configuration is available. If this information and/or system configuration is not available, the corrections may be dynamic based on a feedback message from the receiving node (eg, HARQ feedback and/or messages related to interference and/or signal level reports).

At the transmitting node for LBT in the opposite direction, beam optimization (θ _sup , G _sup,m ) can be used. The beam pattern (e.g., main-beam bandwidth and/or main-beam gain) to be used at the transmitting node for LBTs in the opposite(s) (e.g., further paired) direction(s) can be set as a function of from the system parameter(s) and/or report(s) from the receiving node, for example when one opposite direction can be used.

In FIG. 16 shows an example of the beam optimization effect used at a transmitting node for LBT in one opposite direction, in accordance with some embodiments. In the example in FIG. 16, one opposite direction may be the DL access direction from gNB 1300 to UE 1302. limited number of unprotected areas (as shown in Fig. 16). This can be achieved by using a larger main beam beamwidth than for LBT towards the receiving node and for data transmission (eg, θ _sup >θ _Tx ). This can happen if the beamwidth Rx of the receiving node is larger than the beamwidth Tx of the transmitting beam (θ _Rx >θ _Tx ). If the beamwidth Rx of the receiving beam is not greater than the beamwidth Tx (θ _Rx <θ _Tx ), this can be achieved by using a smaller beamwidth of the main beam than for LBT in the direction of the receiving node and for data transmission (for example, θ _sup <θ _Tx ). The technical solution (for example, the optimal technical solution) may depend on the characteristics of the Rx beam of the receiving node (θ _Rx , G _Rx,m ), transmitter-receiver distance, propagation characteristics (for example, on the exponent of loss in the transmission path and / or carrier frequency) , noise power, and/or the product of the AP 1304 transmit power and the AP main lobe gain. To find a value (eg, the optimal value), the transmitting node may use the characteristics of the receiving node's radiation pattern (eg, θ _Rx , G _Rx,m ) and/or the transmitter-receiver distance, which can be estimated based on measurement reports from the receiving node (for example, as a result of the initial acquisition procedure or continuous adjacent beam measurements).

If θ _sup increases (eg, increases excessively), above and/or below the Rx beam of the receiving node, a new area of effect on the transmitting node may appear. The transmitting node can detect interference that is not normally detected. To optimize the width (θ _sup ) of the beam of the main lobe, a compromise solution is possible.

In some embodiments, a (eg, optimal) main lobe beamwidth may be provided, which will be described in more detail herein.

In some embodiments, the implementation can be determined, for example optimized, the number of beams used at the transmitting node for LBT in opposite directions.

The number of beams to be used at the transmitting node for LBT in opposite (eg, further paired) directions may be set as a function of system parameters and/or reports from the receiving node. This can happen when using multiple opposite (eg, additionally paired) directions (eg, when the set of beams on the transmitter is predefined and cannot be dynamically changed). An example of this is shown in FIG. 15b. As seen in FIG. 15B (where three beams are shown as an example), the number of beams for LBTs in opposite (eg, further paired) directions can be set to maximize the number of resolved hidden nodes while maintaining the limit on the number of unprotected nodes.

To find the optimal number of beams to be used for LBT in opposite directions, the parameters (eg, same parameters) of the methods discussed herein (beam parameter optimization) can be used.

In some embodiments, a determination (eg, optimization) of the ED threshold to be used at the transmitting node for LBT in the opposite direction(s) may be provided.

The ED threshold used at the transmitting node for LBT in the opposite direction(s) may be set as a function of system parameters and/or reports from the receiving node (eg, HARQ feedback and/or other messages). The ED threshold may be adjusted as a function of parameters and/or measurement reports from the receiving node. The ED threshold can be adjusted for a paired LBT with one opposite direction and for a paired LBT with multiple opposite directions.

Optimizations can minimize the number of unprotected nodes, while the area of avoided hidden nodes can be preserved. The ED threshold may be chosen to detect (eg, only) interfering APs lying in the Rx beam region of the receiving node. In FIG. 15A and 15B, by increasing the ED threshold, unprotected nodes in the new unprotected node region 1212 can be avoided.

In FIG. 17A and 17B show examples of the effect of increasing the ED threshold for LBT in the opposite direction(s). In FIG. 17A shows an example of an LBT threshold increase (ED) effect in one opposite direction with an optimized beam shape, in accordance with some embodiments. In FIG. 17B shows an example of the effect of increasing the ED threshold for LBT in multiple opposite directions with predefined beams, in accordance with some embodiments.

In FIG. 17A and 17B show the (eg, optimal) result for: (a) one LBT in the opposite (eg, additionally paired) direction (eg, 180°, see FIG. 17A), or (b) multiple LBTs in a plurality of opposite (eg, additionally paired) directions (eg, 160°, 180°, 200°, see Fig. 17B).

As shown in FIG. 17A and 17B, the ED threshold design (e.g., optimal ED threshold design) may depend on the Rx beam characteristics (e.g., θ _Rx , G _Rx,m ) of the receiving node (e.g., UE 1400), transmitter-receiver distance , propagation characteristics (e.g., from pathloss exponent and/or carrier frequency), noise power, and/or the product of AP 1402 transmit power and AP 1402 main lobe gain. Suppose, for example, that TH _leg denotes the ED threshold for LBT in the direction receiving node (which may be -72 dBm in LTE-LAA for a 20 MHz bandwidth) and that TH _sup denotes the ED threshold in the opposite(s) (e.g., further paired) direction(s) ( e.g. LBT _dir+180 ). For example, the farther the receiving node is from the transmitting node (eg, as the transmitter-receiver distance increases), the more TH _sup can be increased. A value for TH _sup (eg, an optimal value) can be obtained when the positive LBT detection area in the opposite direction(s) (eg, LBT _dir+180 ) overlaps the allowed node area 1404 (as seen in FIG. 17A and 17B). Typically, in some embodiments, a region of positive detection refers to an area in which the signal level is high enough to provide, for example, guaranteed detection. The analytical expression for TH _sup will be described in more detail below.

In one example, the ED threshold for LBT in the opposite direction(s) may be configured to be greater than the threshold used for LBT in the direction of the receiving node (eg, TH _sup >TH _leg ). This can happen when information about the receiving node is not available at the transmitting node.

In FIG. 18 shows an example flowchart 1500 for correcting parameters associated with LBT in the opposite direction(s), in accordance with some embodiments. Block diagram 1500 shown in FIG. 18 may be applied when it is possible to adjust parameters for LBT in the opposite direction(s) (eg, optimal adjustment) based on information from the receiving node and/or system configuration. In this case, the acquisition information may include, for example, characteristics of the Rx beam of the receiving node.

As shown in FIG. 18, in some embodiments, after a connection is established between the transmitting node (denoted as "TX") and the receiving node (denoted as "RX"), in step 1501, discovery information may be sent from the receiving node to the transmitting node. The discovery information may include parameters that are generated during a discovery procedure or based on continuous measurements of neighboring devices. The parameters may include, for example, the main lobe beamwidth and the main lobe gain of the Rx beam of the receiving node. Upon receipt at the transmitting node, the transmitting node may, in step 1502, adjust the parameters for the LBT in the opposite direction(s) when, for example, it receives detection-related measurements or measurements from the transmitting node based on continuous measurements of neighboring devices, estimated transmitter-receiver distance; and system configuration information (eg, noise power, propagation characteristics, and/or the like). Correcting the LBT parameters may include correcting the beam pattern and/or the number of beams and/or the ED threshold for the opposite direction(s). The correction may be performed for each receiving node and may be used for, for example, all LBTs associated with transmissions in the direction, for example, to a specific receiving node, such as the receiving RX node in FIG. 18. The transmitting node may use different parameter settings for LBT in the opposite direction for different receiving nodes.

When, at step 1504, there is data to transmit at the transmitting node, at step 1506, the transmitting node may perform LBT in paired directions, such as the direction towards the receiving node and the opposite direction(s), with LBT correction in the opposite direction(s). ) (e.g. additionally paired) direction(s). If, at step 1508, LBT in paired directions indicates an idle channel condition, the transmitting node may proceed to transmit data towards the receiving node at step 1510. At step 1512, the receiving node may receive the transmitted data and decode it. When, at step 1514, there is again data to transmit at the transmitting node, at step 1516, the transmitting node may repeat the LBT procedure performed at step 1506 until data is transmitted to determine if the channel is busy. If, at step 1518, the LBT in paired directions indicates a busy channel state, at step 1520, the transmitting node may delay the transmission of data and wait for a DIFS timed delay before the next attempt to gain access to the channel. Subsequently, the transmitting node may attempt to access the channel again, and when, at step 1522, LBT in paired directions indicates an idle channel state, the transmitting node may proceed to transmit data, at step 1524. At step 1526, the receiving node may receive the transmitted data and decode it .

In some embodiments, the paired LBT parameters (e.g., ED threshold, beam pattern, and/or number of beams to be used for LBT in the opposite(s) (e.g., further paired) direction(s)) can be dynamically adapted based on feedback from the receiver. For example, the parameters may be dynamically updated when the information about the Rx beam of the receiving node and/or the transmitter-receiver distance is not known at the transmitting node.

In an example, adaptation of the LBT parameters for the opposite (eg, additionally paired) direction may be performed based on the HARQ feedback from the receiving node. In this case, for example, the adaptation may be based on statistics for the number of received HARQ NACK messages. The transmitting node may determine that the receiver node is operating in an interference constrained scenario, and it may: increase the width (θ _sup ) of the main beam beam in the opposite (eg, further paired) direction; use more beams for LBT in the opposite direction(s); and/or reduce the threshold (TH _sup ) ED for LBT in the opposite direction(s), for example, to increase the detection area of hidden nodes.

In this way, it is possible to improve the characteristics of the transmitter-receiver link, for example, by reducing situations with restrictions due to interference and dwell time.

Signals and/or measurement reports from the receiving node may be used by the transmitter node to adapt the LBT parameters for the opposite (eg, further paired) direction. These may include, but are not limited to: Reference Signal Receive Power (RSRP), Reference Received Quality (RSRQ), Channel State Information (CSI), Interference Measurement (IM), Reference Signals (CRS, DM-RS), and/ or the like.

In FIG. 19 shows an example flowchart 1600 for dynamically adjusting parameters for LBT in the opposite direction(s), in accordance with some embodiments. In the example in FIG. 19, the parameters may be dynamically adjusted based on reports from the receiving node, which may indicate a constraint situation due to interference. For example, as shown in FIG. 19, an indication of a constrained situation due to interference (eg, a NACK message) may be used. Typically, in some embodiments, various messages may be used by the receiving node (denoted as "RX") that indicate a constrained situation due to interference, including: a NACK message, which may indicate a constrained situation due to interference. for interference, an explicit message that may indicate the situation with restrictions due to interference, and/or, for example, any other useful message by which the transmitting node (denoted as "TX") can determine that decoding may have failed due to interference (eg RSRP, RSRQ, CSI, IM and/or the like reports).

As shown in FIG. 19, when at step 1601 there is data to transmit at the transmitting node, at step 1602 the transmitting node may perform LBT in paired directions, such as the direction towards the receiving node and the opposite direction(s). If, at step 1604, LBT in paired directions indicates an idle channel condition, the transmitting node may proceed to transmit data towards the receiving node, at step 1606. If, at step 1608, the receiving node determines that decoding has failed due to received interference, at step 1610 the receiving node may send, for example, a message (denoted as "interference constraint indicator") indicating the interference (eg, a NACK message). The transmitting node, in step 1612, after receiving the message relating to the interference constraint situation or determining the interference constraint situation based on the signal quality reports from the receiving node, may adjust the parameters for the LBT in the opposite direction(s). -I). Parameter correction may include: increasing the beam pattern, increasing the number of beams, and/or decreasing the ED threshold. The correction may be updated in real time, dynamically, based on reports from the receiving node, and may be used for LBT associated with a subsequent transmission.

As also shown in FIG. 19, in the presence of interference in step 1614, the transmitting node may attempt the next LBT in paired directions (LBT with the correction performed in step 1612). At 1616, the LBT result in the paired directions may indicate a busy channel condition. In such a case, at block 1618, the transmitting node may delay the transmission of data and wait for DIFS, taking into account the delay time, before the next attempt to gain access to the channel. At 1620, the transmitting node may attempt to access the channel again (by performing LBT) and recognize the idle state of the channel. At 1622, the transmitting node may proceed to transmit data. At 1624, the receiving node may receive the transmitted data and decode it. When, at step 1626, there is again data to transmit at the transmitting node, the transmitting node may again perform LBT at step 1628 with adjusted parameters before transmitting data to determine if the channel is busy. If, at step 1630, LBT in paired directions indicates an idle channel state, the transmitting node may proceed to transmit data at step 1632. At step 1634, the receiving node may receive the transmitted data and decode it.

As noted above, the "interference constraint indicator" message may be a NACK, any other message that may be associated with an interference constraint situation occurring at the receiving node, or any other message that causes the transmitting node to can determine the existence of a constrained situation due to interference.

In some embodiments, the transmitting node may use the information (e.g., sensed power/energy) received during LBT in the opposite(s) (e.g., further paired) direction(s) to, for example, optimize the transmit/receive strategy. For example, the transmitting node may use a procedure with multiple ED thresholds for LBT in the opposite direction(s), perform adaptive MCS selection, and/or implement a power control mechanism that can be adjusted as a function of the sensed energy during LBT in the opposite(s) (eg, further paired(s)) direction(s).

The power sensed during LBT in the opposite(s) (eg, additionally paired) direction(s) can be used to correct the transmit/receive strategies. Policy corrections may include: implementing a procedure with multiple ED thresholds for LBT in the opposite direction(s) with the ability to only allow transmission towards the receiving node, but not transmission from the receiving node towards the transmitting node (reverse direction); selecting a modulation and coding scheme (MCS) at the transmitting node for each identified power during LBT in the opposite(s)/supplementary(s) direction(s); and/or correcting the power control at the transmitting node based on the sensed power during LBT in the opposite direction(s).

At the transmitting node, a procedure with two ED thresholds for LBT in the opposite direction(s) may be used, in which the two ED thresholds are TH ₁ and TH ₂ , with TH ₁ >TH ₂ . If the power detected during LBT in the opposite(s) (eg, additionally paired) direction(s) exceeds TH ₁ , the transmission of the transmitting node may be delayed. If the power detected during LBT in the opposite(s) (e.g., additionally paired) direction(s) exceeds TH ₂ but not TH ₁ , the transmission of the transmitting node may be allowed, but transmissions from receiving node (reverse direction) may not be allowed.

The procedure with two ED thresholds for LBT in the opposite direction(s) may be used to allow (eg, still allow) transmissions from the transmitting node to the receiving node, while transmissions on the reverse link may not be allowed. This may be due to the measurement of perceived interference in the opposite direction. For example, if, in a two-threshold scheme, the measured interference level is above the larger threshold for the opposite direction, the target receiving node may not be allowed uplink traffic. The receiving node may be allowed to receive data at a low bit rate (it may have a low interference signal-to-noise ratio (SINR) due to received interference from the transmitting node in the opposite direction). The transmission from the receiving node to the transmitting node (reverse direction) can be prevented except by sending an ACK/NACK message, for example. Due to this, the generation of interference on the AP and/or STA can be avoided. The ED threshold may indicate power control for transmission from the receiving node towards the transmitting node.

The transmitting node may implement adaptive MCS selection, which may be dependent on the power level sensed during LBT in the opposite direction(s). For example, if the LBT in the opposite direction(s) indicates a busy channel state, even if channel conditions on the transmitter-receiver link are favorable, the transmitting node may transmit at a lower MCS that may be adapted based on the second identified power during LBT in opposite (ie, additionally paired) directions. This can be configured to be decoded at the receiving node even if the receiving node is interfered with. Transmission from the transmitting node may be allowed because the transmitting node may not interfere with the AP/STA.

The transmitting node may use the power level learned during LBT in the opposite direction(s) to correct the transmitted power (eg, power control). If the LBT in the opposite direction(s) indicates a busy channel state, the transmitting node knows that there may be interference at the receiving node and the transmitting node's transmit power can be increased (eg, if feasible).

In FIG. 20 shows an example flowchart 1700 for correcting a transmission strategy based on LBT in the opposite direction(s), in accordance with some embodiments. In FIG. 20 shows features associated with a case in which, after detecting a busy channel by LBT in the opposite direction(s), the transmission strategy at the transmitting node is adjusted based on the power/energy that was detected during LBT in the opposite direction(s). s) direction(s). In some embodiments, the transmitting node may appropriately adjust the MCS or transmitted power so that successful decoding is possible at the receiving node.

As shown in FIG. 20, when at step 1701 there is data to transmit at the transmitting node, at step 1702 the transmitting node may perform LBT in paired directions, such as the direction towards the receiving node and the opposite direction(s). If, at step 1704, the LBT in paired directions indicates an idle channel state, the transmitting node may proceed to transmit data towards the receiving node, at step 1706. At step 1708, the receiving node may receive the transmitted data and decode it. When, at step 1710, there is again data to transmit at the transmitting node, at step 1712, the transmitting node may again perform LBT in paired directions, and as a result, at step 1714, determine that the channel is busy. At 1716, the transmitting node may adjust the transmission strategy (eg, adjust the MCS and/or transmit power) based on the sensed power in the opposite direction(s). Subsequently, at step 1718, the transmitting node may proceed to transmit data. At 1720, the receiving node may receive the transmitted data and decode it.

In some embodiments, the methods described herein may be combined. For example, the adaptive MCS may be combined with a multi-threshold ED procedure. Thresholds ED can be TH ₁ >TH ₂ >TH ₃ . If the power detected during LBT in the opposite direction(s) exceeds TH ₁ , the transmission of the transmitting node may be delayed. If the power detected during LBT in the opposite direction(s) exceeds TH ₂ but not TH ₁ , the transmission of the transmitting node may be allowed with an adapted MCS according to the determined energy. Transmissions from the receiving host may not be allowed. If the power detected during LBT in the opposite direction(s) exceeds TH ₃ but not TH ₂ , the transmission of the transmitting node may be allowed with an adapted MCS according to the determined energy. The transmission from the receiving node may be allowed with mandatory power control. If the interference in the opposite direction to the intended LBT direction becomes higher than (eg, the highest) threshold, the receiving node may be allowed to send ACK/NACK messages in the reverse direction, since the duration of these messages may be short and may have minimal impact on interfering nodes. In this case, normal reverse link transmissions may not be allowed.

The choice of MCS for DL/UL may be adapted according to the measured interference and/or the expected impact on the receiving nodes, for example, as described herein. The exchange of information between the transmitting and receiving nodes may be through the exchange of short messages or predetermined standard values that may be known to the transmitting node and the receiving node.

The ED thresholds may be determined using one or more of the following. TH ₁ may determine the lowest power level that can be measured. This level may be set as a CCA threshold level as determined in the WiGig domain or based on receiver sensitivity. The highest threshold can be set as the upper threshold in the WiGig domain when WiGig devices measure interference from non-WiGig waveforms. If the CCA is set to a busy link state, WiGig devices can keep transmitting their packets. The highest threshold level can be compared to the minimum perceived SIR at the target (receiving) node. For example, in FIG. 17A, the gNB measures the AP's power level and predicts the corresponding highest level of interference on the UE that may be caused by the AP forwarding packets. The interference may be limited at the UE and the SIR at the UE may be minimal. The highest threshold may be defined as a threshold that is associated with a choice of (eg, minimum) MCS index that may be tied to a predicted SIR at the UE that allows stable DL traffic from the gNB to the UE. It can be expected that the SIR at the UE may (eg, always) be positive due to the distance between the interferer (eg, AP) and the transmitting node (eg, gNB), as depicted in FIG. 17A. Intermediate thresholds may be set to reflect MCS selections based on (eg, estimated) SIR variation at the target receiving node.

In FIG. 21 is an example block diagram 1800 associated with an implementation with multiple ED thresholds, in accordance with some embodiments. In FIG. 21 shows a procedure with two ED thresholds in which permission/denial of transmission from transmitter to receiver and from receiver to transmitter can be determined based on the sensed power during LBT in the opposite(s) (e.g., further paired(s) in) direction. (-s) and their relationship with two predefined ED thresholds. In FIG. 21 shows features associated with an implementation with multiple ED thresholds in which transmission from the transmitter node to the receiver may be allowed, but transmission from the receiver to the transmitter node may not be allowed, which may be based on sensed power during LBT in the opposite(s). ) direction(s). In a procedure with multiple ED thresholds, signaling can be used to indicate the time of possible transmission in the reverse direction (from receiver to transmitter).

As shown in FIG. 21, when at step 1801 there is data to transmit at the transmitting node, at step 1802 the transmitting node may perform LBT in paired directions, such as the direction towards the receiving node and the opposite direction(s). If, at step 1804, based on the performed LBT, the transmitting node recognizes that the power in the opposite direction(s) is below the threshold 2 ED (hereinafter referred to as "ED TH ₂ "), the transmitting node may proceed to transmit data towards the receiving node at 1806. At 1808, the receiving node may receive the transmitted data and decode it. When at step 1810 at the transmitting node again there is data to transmit, at step 1812 the transmitting node may again perform LBT in paired directions, and at step 1814 to determine the excess power in the opposite direction(s) of the ED TH ₂ level, but not exceeding the threshold 1 ED (hereinafter referred to as "ED TH ₁ "). At block 1816, the transmitting node may proceed to transmit data, and at block 1818, the receiving node may receive the transmitted data and decode it. Thereafter, or substantially concurrently with the transmission of data, the transmitting node may transmit to the receiving node an indication of a possible lack of permission to transmit from the receiving node to the transmitting node (from RX to TX) at step 1820.

When, at step 1822, there is again data to transmit at the transmitting node, at step 1824, the transmitting node may repeat the LBT in paired directions, and at step 1826 determine if the power in the opposite direction(s) exceeds the ED TH threshold_one. As a result, at step 1828, the transmitting node may delay the transmission of data and wait for DIFS, taking into account the delay time, before the next attempt to gain access to the channel. In step 1830, the transmitting node may perform another LBT in paired directions and determine in step 1832 that the power in the opposite direction(s) is now below ED TH₂. Accordingly, at step 1834, the transmitting node may proceed to transmit data. At 1836, the receiving node may receive the transmitted data and decode it.

In accordance with some embodiments, ED threshold corrections may be based on the angle of arrival (AoA) of the interfering signal. The transmitting node may set the ED threshold for LBT in the opposite direction as a function of the AoA of the interfering signal, for example, when the transmitting node is a UE, the receiving node is a gNB, and when the LBT beamwidth in the opposite direction cannot be reduced to match the beamwidth of the gNB (eg due to hardware limitations in the UE).

In FIG. 22 shows an example of using an angle-of-arrival estimate and an LBT ED threshold change in the opposite direction, in accordance with some embodiments. For example, in FIG. 22, a signal from AP 1900 (also referred to as "AP2") arrives at UE 1902 with an AoA (AoA2), which may be different from the AoA for the signal from AP 1904 (also referred to as "AP1") (AoA1). AP 1904 may lie within the electrical axis of gNB 1906's Rx beam antenna, while AP 1900 may not lie. In this situation, the ED threshold for the signal coming from AoA2 may be greater than the ED threshold for the signal coming from AoA1. Paired LBT at UE 1902 may prevent transmission in the presence of AP 1904, but may not interfere in the presence of AP 1900.

In some embodiments, the LBT may receive assistance from the receiving node. The receiving node may assist the transmitting node in determining whether the transmission is allowed or not, for example, if the transmitting node is unable to perform simultaneous LBT towards the receiving node and one or more opposite (eg, further paired) directions. For example, if the transmitting node is a UE and the receiving node is a gNB (as in the configuration shown in FIG. 22), the UE may not be able to perform simultaneous LBT in multiple directions, and the gNB may assist the UE.

In accordance with some embodiments, a receiving node (eg, gNB) may perform LBT towards a transmitting node (eg, UE), and a transmitting node (UE) may perform LBT towards a receiving node (gNB). The gNB may cover carrier sensing in the opposite direction, and the coordination may be for both nodes (gNB and UE) to recognize the idle channel state to allow transition to data transmission from the UE to the gNB.

In FIG. 23 is an example flowchart 2000 illustrating LBT service from a receiving node, in accordance with some embodiments. In FIG. 23 shows features by which a receiving node (gNB) can provide LBT assistance to a transmitting node (UE).

In FIG. 23 The UE, upon recognizing an idle channel towards the gNB, may request assistance from the gNB. Namely, in step 2001, the UE may send discovery information to the gNB. The discovery information may include an indication whether the UE is capable of performing simultaneous LBT in multiple directions or not. If the UE is unable to perform simultaneous LBT in multiple directions, in step 2002, help from the gNB (per gNB) is activated. When there is data to transmit at the UE in step 2004, the UE may perform LBT in the direction of the receiving node (in the direction of the gNB) in step 2006. If at step 2008 the LBT in the receive direction (RX) indicates an idle channel state, the UE sends a request for help to the gNB at step 2010. The request for help may be in the form of any suitable message indicating a request for help in the LBT from the receiving node. After receiving a request for assistance from the UE, the gNB may implement LBT in the direction of the transmitting node (in the direction of the UE) in step 2012, which may cover the opposite direction(s) of the transmitting node (UE). If, in step 2014, the gNB determines an idle channel state in the transmit (TX) direction, in step 2016, the gNB may send an indication of the idle channel in that direction to the UE (eg, using a suitable message). In step 2018, the UE may repeat the LBT in the RX direction, and if the UE recognizes an idle channel state in step 2020, the UE proceeds to transmit data in step 2022. In step 2024, the gNB may receive the transmitted data and decode it.

When, at step 2026, there is again data to transmit at the UE, at step 2028, the UE may perform another LBT in the RX direction. If at step 2030 the LBT in the RX direction indicates an idle channel state, the UE sends another request for help to the gNB at step 2032. In response to this, in step 2034, the gNB performs another LBT in the direction of the TX to cover the opposite direction(s) of the UE. If, at step 2036, the LBT in the TX direction indicates a busy channel state, at step 2038, the gNB may delay any data transmission to the UE and wait for a DIFS timed out before the next attempt to gain access to the channel. After indicating, at step 2040, the LBT in the TX direction to the idle channel state, at step 2042, the gNB may proceed to send an indication of the idle channel state to the UE in that direction. In step 2044, the UE may repeat the LBT in the RX direction, and if as a result of step 2046 the UE recognizes an idle channel state, the UE proceeds to transmit data in step 2048. In step 2050, the gNB may receive the transmitted data and decode it.

In some embodiments, features may be provided related to optimizing the parameters of the transmitting node for LBT in the opposite direction(s).

Namely, in some embodiments, features may be provided to optimize the parameters of the transmission node for the intended paired LBT in the case where one beam is used in one opposite direction, for example dir+180°. The following example is described for DL communication from a gNB (transmitting node) to a UE (receiver), but can also be applied to UL communication. The gNB beam parameters for LBT in the opposite direction can be optimized while trying to maximize the number of allowed hidden nodes while avoiding an excess of unprotected nodes. The ED threshold per gNB for LBTs in the opposite (eg, further paired) direction can be optimized to overlay the region of positive detection for LBTs in the opposite direction onto the region of allowed hidden nodes. Path loss (PL) can be modeled using the expression:

where α is the path loss exponent, which can be between 2 and 6, fc can be a carrier frequency, _c can be the speed of light, and d can be the distance in meters between two nodes. Given the dispersion of the signal with distance, the average received signal power at node i from node j can be:

могут обозначать усиление передающей антенны на узле j, мощность передачи на узле j и усиление приемной антенны на узле i соответственно. Область луча Rx для UE может быть задана сектором с радиусом r и углом θ_Rx, направленным к gNB. Радиус вычисляют следующим образом:where

may denote the transmit antenna gain at node j, the transmit power at node j, and the receive antenna gain at node i, respectively. The beam area Rx for the UE may be defined by a sector with radius r and angle θ _Rx directed towards the gNB. The radius is calculated as follows:

where N _o W may denote the noise power, G _Tx,AP,m may be the AP main lobe gain, and P _Tx,AP refers to the transmit power of the AP. An AP located within the UE's beamwidth, θ _Rx , may be (eg, at least) r meters away from the UE so as not to interfere with it.

In some embodiments, beam optimization (θ _sup, G _sup,m ) may be performed for the LBT in the opposite direction. In FIG. 24 shows an example of LBT beamwidth correction in the opposite direction, in accordance with some embodiments. By doing this, the number of allowed hidden nodes can be maximized and new unprotected nodes can be prevented. This can be done by adjusting the main lobe beamwidth for the LBT in the opposite direction to cover the Rx beam area of the UE 2102 as shown in FIG. 24. The sector angle of the gNB 2100 may be selected to cover a wider area of the Rx UE beam. The antenna gain can be obtained from the beamwidth correction.

A closed-form expression for the main-beam beamwidth to be used for LBT in the opposite direction can be:

where d _gNB-UE may be the distance from the gNB to the UE, as shown in FIG. 24.

As discussed herein, beamwidth and main-beam antenna gain can be directly related. The radiation pattern of an antenna with the same beamwidth in the azimuth and elevation regions can be described as:

может иметь максимальное значение, которое зависит от количества элементов антенны на gNB. Значение

(gNB) может быть меньше значения

(UE), и коррекция может обеспечивать

(т. е. осуществимую ширину луча главного лепестка).where C can be a constant that depends on the type of 3D antenna pattern (eg elliptical, rectangular).

may have a maximum value that depends on the number of antenna elements per gNB. Meaning

(gNB) may be less than

(UE), and the correction can provide

(i.e. the feasible main lobe beamwidth).

In the case of using a plurality of predefined beams in a plurality of opposite directions (as shown in FIG. 15B), the gNB may select the number of beams that maximizes the area of allowed hidden nodes. There may not be an excess of unprotected rays.

и

(например, полученном с использованием методов, рассмотренных в настоящем документе), передающий узел (gNB) может корректировать порог ED для LBT в противоположном направлении с возможностью наложения области положительного определения для LBT в противоположном (например, дополнительно объединенном в пару) направлении на область разрешенных скрытых узлов (см. фиг. 17A). Такое может быть обеспечено за счет учета пороговой мощности для LBT в противоположном направлении:For a given fixed value

and

(e.g., obtained using the methods discussed herein), the transmitting node (gNB) may adjust the ED threshold for LBT in the opposite direction, with the possibility of superimposing the region of positive definition for LBT in the opposite (e.g., further paired) direction onto the region of allowed hidden nodes (see Fig. 17A). This can be achieved by taking into account the threshold power for LBT in the opposite direction:

This equation, which can be used to correct the ED threshold for LBT in the opposite direction, can be applied in the case of using a plurality of beams with predetermined radiation patterns in a plurality of opposite (for example, additionally paired) directions (as, for example, shown in Fig. .17B).

Various embodiments have been described above, including embodiments relating, for example, to mitigating hidden node problems that may arise when operating in unlicensed bands of highly directional systems. However, these embodiments are not exhaustive, and further changes, implementations, configurations, procedures, and so on, are possible in other embodiments. within the scope of the present description.

In accordance with some embodiments, the present document describes methods, systems, and signaling for a coordinated LBT mechanism that enables spatial reuse across multiple unlicensed bands, such as, for example, sub-6 GHz and/or mmWave unlicensed bands. waves. In some embodiments, the methods described herein provide coordination procedures for use with nodes that are, for example, associated with the same or related radio access technology (RAT) and/or with one or more operators (e.g., cell phone operators). /mobile), to prevent (e.g., avoid) (or at least reduce the likelihood of) blocking based on LBT within radio access technology (intra-RAT) and, for example, to comply with or satisfy the LBT requirement (requirements) or regulations in one or more unlicensed bands.

Due to the non-coordinated LBT mechanism applied to different nodes, eg the same RAT that normally handles handover coordination (or handover coordination between nodes), unnecessary blocking based on LBT may occur. Because of it, poor utilization of the channel is also possible. Cellular networks are typically configured to provide reuse (e.g., reuse of radio resource(s) (e.g., frequency, time)), such as complete reuse, by applying a number of interference management techniques (e.g., adaptive rate control, power control, Coordinated Multipoint (CoMP) transmission, Enhanced Inter-Cell Interference Coordination (eICIC), etc.) to mitigate inter-cell interference within nodes, such as a single RAT (eg, NR from a specific mobile/cellular carrier).

Therefore, LBT-based transmission blocking between devices of the same RAT that may be coordinated to transmit on unlicensed spectrum (e.g., nodes of the same RAT and likely the same operator) may not normally be necessary. . However, regulations for the unlicensed 5 GHz and 60 GHz bands, for example, require the implementation of LBT.

In FIG. 25A and 25B respectively show examples of LBT-based blocking for (A) nodes of different RATs and (B) nodes of the same RAT, in accordance with some embodiments.

In the example in FIG. 25A, the AP 2200 (also referred to as "AP1") has gained access to the channel and then, during the MCOT, blocks the transmission of the base station gNB 2202 (also referred to as "gNB1" because gNB 2202 recognizes the idle channel state for LBT Therefore, the gNB 2202 must wait for the end of the AP2200 transmission to complete the holdout procedure as shown in Figure 25A.Then, when the channel is idle, the gNB 2202 can finally access the channel.This is, for example, a typical procedure.

However, in FIG. 25B, the base station gNB 2204 (also referred to as "gNB2"), which may be a node of the same RAT and, for example, the same operator as gNB 2202, has gained access to the channel and is blocking the transmission of gNB 2202 due to co-transmissions. and carrier sensing LBT. In this case, gNB 2202 should delay transmission as shown in FIG. 25B, while in so-called typical cell operation, cellular networks can typically allow full reuse, achieved through efficient coordination strategies that can manage interference (e.g., at least between nodes of the same RAT and the same operator). In the example in FIG. 25B blocking based on LBT can have negative consequences because it prevents spatial reuse, for example. Typically, in some embodiments, spatial reuse is understood to mean enabling time and frequency resources to be used in different locations. In this case, for example, interfering beams can prevent (eg, due to collisions) the spatial reuse of radio resources.

In order to avoid the problem of blocking based on LBT transmission between nodes of the same RAT, a solution has been proposed to group neighboring TRPs and self-defer their channel sharing to prevent deadlock, both as a result of the use of reservation signals and the transmission itself. See, for example, Huawei, HiSilicon, "3GPP R1-1719841, "Coexistence and channel access for NR-based unlicensed band Operation"", 3GPP TSG RAN 91 Meeting, Nov. 2017.

However, the main problem that can arise in connection with the self-backoff method is the possibility of another node gaining access to the channel during the self-backoff period. In addition, it should be noted that this method resolves issues related to simultaneous accesses, but not in the case when the node has already gained access to the channel and can block transmissions of neighboring nodes within the same RAT (as shown, for example, in Fig. 25B).

Blocking based on LBT within nodes, for example, the same RAT (and/or the same operator), which usually observe coordinated transmission, remains a problem in LAA that needs to be addressed. Some communication technologies, such as Wi-Fi and WiGig, use LBT-based blocking generally admissibility contention, and the nodes also do not coordinate the transmission.

Therefore, improvements may be desirable for LAA and NR-U (or 5G NR-based access to unlicensed spectrum), which usually follow a planned approach.

In accordance with some embodiments, coordinated LBT signaling has been described. In some embodiments, LBT coordination may be implemented to coordinate the backoff procedure(s) based, for example, on the assumption that after LBT coordination, transmission coordination may be applied using, for example, some existing techniques (e.g., CoMP, eICIC, etc.). d.).

In some embodiments, when a gNB (eg, gNB1 shown in FIG. 25B) detects that the node occupying the channel is a node using, for example, the same RAT (eg, gNB2 shown in FIG. 25B), The gNB may send a message, for example, over the Xn interface, as in NR (or the X2 interface, as in LTE), to request LBT coordination (referred to herein as "LBT-C-RQ") to prevent, for example, unnecessary blocking on the basis of the LBT. In FIG. 26 shows an example LBT coordination scenario in accordance with some embodiments.

Node receiving LBT-C-RQ (e.g. gNB 2300 (also referred to as "gNB2") in FIG. 26 receiving LBT-C-RQ 2306 from gNB 2302 (also referred to as "gNB1") on interface 2304 Xn ) may either accept or reject the LBT-C-RQ. If received, in some embodiments, the agreeing node will send back an acknowledgment of consent (e.g., in the form of any appropriate acceptance message) including, for example, one or more ways in which the LBT will or can be coordinated to perform the backoff, or accompanied by them. In addition, in some embodiments, the acknowledgment may also indicate the start time of the handover coordination and the handover coordination strategy that may be applied after completion of the backoff procedure based on the LBT.

In some embodiments, detection of the presence of devices of the same RAT may be based on the assumption that nodes of the same RAT will typically be able to decode native RAT messages (eg, PDCCH or eDRTS (Enhanced Directed RTS)).

Once the nodes have access to the channel, transmission coordination can be performed in a variety of domains such as time, frequency, space, power, and/or transmission rate. However, it should be noted that in some embodiments, some level and/or form of handover coordination may be required to perform the LBT backoff procedure. In some embodiments, LBT coordination may be either in the frequency domain or in the time domain. In FIG. 27A and 27B respectively show examples of LBT coordination in (A) frequency domain and (B) time domain, in accordance with some embodiments.

In addition, in some embodiments, to improve fairness with respect to other RATs, LBT coordination may occur within the MCOT (eg, only within the MCOT).

In the case of LBT coordination in the frequency domain (see FIG. 27A), in some embodiments, an example procedure for performing backoff based on LBT and then using any suitable transmission coordination strategy may be, for example, as follows.

First, gNB2, upon receipt of the LBT-C-RQ 2400 and, for example, the dwell time indication, from gNB1, may release some resource blocks (RB) or part of the bandwidth (BWP) for a certain period of time, and may indicate this to the gNB1 stations through (message ) 2402 frequency related coordination acknowledgment (referred to in this document as "LBT-C-A-f"). gNB2 may also provide, for example, parameter indication(s) such as, but not limited to, reserved resources, handover coordination strategy, handover coordination start time, and/or time limit to MCOT. Some or all of these parameters may be specified in LBT-C-A-f 2402, or alternatively transmitted separately from LBT-C-A-f 2402. Then gNB1 upon receipt of information/message(s) from gNB2 may switch from full-band LBT to BWP LBT (or LBT sub-bands) within the specified frequency resource(s) (or BWP) released by gNB2.

In the example above, due to the procedures for coordinating LBT in the frequency domain, releasing some RBs, and allowing gNB1 to implement BWP LBT in those RBs, gNB1 can (i) perform the LBT soak procedure in accordance with the applicable unlicensed spectrum regulations and (ii) subsequently transfer by applying spatial reuse (eg, full application of spatial reuse within the allocated BWP).

In the case of LBT coordination in the time domain (see FIG. 27B), in some embodiments, an example procedure for performing LBT(b) backoff and then using any suitable transmission coordination strategy may be, for example, as follows.

First, gNB2 upon receipt of the LBT-C-RQ 2404 and indication of the soak time may release, for example, the OFDM symbol(s) that may be needed to perform the soak due to the LBT, and indicate this to gNB1 by (message) 2406 acknowledgment of temporal coordination (referred to herein as "LBT-C-A-t"). LBT-C-A-t 2406 may indicate, for example, parameters such as, without limitation, coordination start time, transmission coordination strategy, and/or time limit to MCOT. In an alternative embodiment, some or all of these parameters may be provided separately from LBT-C-A-t 2406. Then gNB1 after receiving information/message(s) from gNB2 may continue to use LBT in the entire band.

In some embodiments, in the example of the LBT coordination procedure in the time domain described above, the transmission coordination may occur by applying spatial reuse within, for example, the entire (or total) bandwidth (BW). However, compared to LBT coordination in the frequency domain, with LBT coordination in the time domain, it is possible for another access node to gain (or at least attempt to access) the channel in the released time resources (see FIG. 27B). In some embodiments, in the case of this or a similar kind of access, it can be treated as a form of "common MCOT within the RAT". In this case, the freed time may be as little as a few microseconds (eg, 25 µs, as in general MCOT), and may be sufficient to perform LBT.

In accordance with illustrative embodiments, when coordinating LBT in the time domain and/or frequency domain, the remaining dwell time (e.g., on gNB1) can be sent simultaneously or in conjunction with LBT-C-RQ 2400 and/or 2404, respectively, allowing the correct configuration resources released by gNB2 (eg BWP or some temporary symbols) for gNB1 to perform the LBT procedure. In addition, together with or simultaneously with LBT-C-A, indicate the BWP that is being released and/or the temporary symbol(s) that are(s) being released to perform the backoff, as well as information about the start time and the coordination strategy, due to which, for example, complete reuse is possible, taking into account the completion time (MCOT constraint).

Based on, for example, values related to NR-U operation, implementation of the proposed LBT coordination may be feasible for NR-U. The MCOT for the unlicensed 60 GHz band is 9 ms. See, for example, European Telecommunications Standards Institute (ETSI), "EN 302 567 Broadband Radio Access Networks (BRAN) V2.1.1", ("EN 302 567 BRAN") Jul. 2017. In terms of numerical values, μ=4 (i.e. SCS=240 kHz) resulting in 16×9=144 slots within the MCOT. Therefore, there are 144 opportunities for gNB1 to decode the PDCCH from gNB2 if it is eligible for decoding. The CCA interval (according to, for example, the EN 302 567 BRAN standard) for the 60 GHz band is 5 microseconds. In this case, in accordance with the example, gNB1, instead of waiting for 9 ms + delay (X×5 microseconds), can access the channel by decoding the PDCCH from gNB2 (for example, no more than one interval, i.e. 62.5 µs for µ= 4) + coordination + exposure (X×5 microseconds).

Advantageously, some of the embodiments described herein can not only provide spatial reuse, but can also reduce channel access delay.

In addition, 5G NR uses an Xn interface (see, for example, Xn interface 2304 in FIG. 26), which is used, for example, for communication between base stations (eg, gNB-gNB). In some embodiments described herein, signaling associated with LBT coordination is also provided that is also compatible or suitable for using the Xn interface.

In one embodiment, coordinated LBT request signaling (referred to herein as "LBTRS") is described. The LBTRS may be sent over Xn, for example, by a gNB detecting a busy channel due to a node from the RAT shared with the gNB. The LBTRS may include the following (without limitation) information: (i) intra-RAT LBT coordination request within MCOT (LBT-C-RQ), (ii) remaining dwell time, (iii) identification of the requesting gNB, and/or (iv ) identification of the requested gNB.

In one embodiment, signaling for permitted coordinated LBT (referred to herein as "LBTES") is described. The LBTES may be sent over Xn by the gNB that occupies the channel and receives the LBTRS. In addition, the LBTES may include the following (without limitation) information: (i) LBT coordination agreement in the frequency domain to perform the exposure (LBT-C-A-f), (ii) freed up frequency domain resources (e.g., BWP), (iii ) time domain LBT coordination agreement to perform backoff (LBT-C-A-t), (iv) transmission coordination start time, (iv) transmission coordination strategy (time, frequency, power, space, CoMP, etc.), (v ) time limit to MCOT, (vi) identification of the requesting gNB, and/or (vii) identification of the requesting gNB.

In the above signaling, by using the identity of the requesting gNB (e.g. gNB1 Station ID) and the identity of the requested gNB (e.g. gNB2 Station ID) in e.g. all gNBs) of this RAT.

In addition, in some embodiments, after a gNB gains access to a channel, it may inform nearby gNBs (e.g., gNBs of the same RAT) via, for example, a channel access indicator to make it easier for nearby gNBs to determine whether it has occupied/gained access to channel another gNB, for example, the same RAT.

Unlike other proposed approaches to LBT coordination (e.g., the self-deferral before gaining channel access approach as noted above), in some embodiments described herein, signaling can be provided to request LBT backlog coordination procedures. (either in time or frequency (eg, a BWP)) after, for example, detection of current TRP transmissions of the same RAT that can be coordinated for transmission. In some described embodiments, the type or type of backoff coordination based on the approved LBT (which may mean, for example, transition from full-band LBT to BWP LBT when instructed) may be further signaled to allow nodes to perform backoff at home, for example, in the entire BW or just in the BWP, to coordinate the transfer.

In some embodiments described herein, methods may be provided to provide fairness for different RATs in the unlicensed band/spectrum.

Specifically, for NR-U in 3GPP, for example, two solutions have been considered to enable acceptable co-operation of multiple RATs in unlicensed mmWave bands: (i) omnidirectional LBT (also referred to herein as "omniLBT") and (ii) directional LBT (also referred to in this document as "dirLBT"). The two solutions differ in the type of physical carrier sensing. OmniLBT controls in all directions, dirLBT controls in a directional way towards the provided RX. See, for example, Huawei, HiSilicon, "R1-1713785, "Coexistence and channel access for NR unlicensed band operation"" 3GPP TSG RAN WG1 90 Meeting, Aug. 2017.

However, there may be some drawbacks to these approaches. In FIG. 28A shows an example of omnidirectional LBT behavior in accordance with some embodiments. In FIG. 28B shows an example of steered LBT behavior for steered transmissions/receptions, in accordance with some embodiments.

In the case of directional transmissions, due to the omnidirectional LBT, the protection may become excessive, as the transmission can be prevented even if a signal is detected from a direction that may not cause harmful interference to the intended RX (for example, an unprotected node problem, as shown in Fig. 28A (top) (case of 2450 misaligned transmissions) for a TX2-RX2 transmission that could have been spectrum reused but was prevented by the omnidirectional LBT). For many implementations, broadcast LBT may, for example, only be suitable for space-aligned transmissions, as shown in FIG. 28A (bottom) (case of 2452 aligned gears).

In contrast, when using directional LBT, the protection cannot be excessive, since it is generally possible to determine only the spatial direction in which the transmission will be made (see FIG. 28B (top) (misaligned transmission case 2454)). However, with directed LBT, other ongoing adjacent transmissions may not be detected. Therefore, interference may occur due to the directional hidden node problem(s), as shown in FIG. 28B (bottom) as the TX1 transmission lies within the electrical axis of the RX2 antenna (case of 2456 aligned transmissions).

Therefore, using the approaches discussed above, (1) an omniLBT-based scheme that is overly protective and prevents spatial reuse, and (2) a dirLBT-based scheme that provides spatial reuse, but with the possibility of some hidden knot problems, can be obtained. These trade-offs are shown in Fig. 28A and 28B for misaligned (top) and aligned (bottom) gears. Accordingly, it would be desirable in certain implementations to use LBT circuits in a more optimal manner.

In addition, it can be shown through, for example, Monte Carlo simulations that the best physical carrier sense scheme of directional LBT, paired LBT (also referred to herein as "pairLBT"), and omnidirectional LBT (at least in terms of performance) varies depending on the density of the network and the beam widths used. For example, a directional LBT may suffice for a low network density, while an omnidirectional LBT may suffice for a high network density. Similarly, for narrow beamwidths, a directional LBT may suffice, while for wide beamwidths, an omnidirectional LBT may suffice. In addition, the complexity of the given LBT mode may be taken into account when selecting the LBT mode. Generally, an omnidirectional LBT, for example, can be considered the simplest.

In accordance with some embodiments, the methods and systems described herein provide an LBT switching mechanism that eliminates at least some of the disadvantages associated with, for example, using an omnidirectional LBT and/or a directional LBT in the case of directional transmissions and receptions, such as shown in FIG. 28A and 28B.

In some embodiments, switching from a directional LBT to a omnidirectional LBT may be performed when the directional LBT senses the idle state of the link, but there is a problem of hidden nodes. In some systems, switching may be performed based on feedback on the HARQ-ACK. For example, if the plurality of HARQ-ACK feedback messages are NACKs, the transmitting (TX) node may switch to broadcast LBT. Otherwise, it may continue to operate with directional LBT. It should be noted that NACK can generally be determined either when an incorrect reception occurs (for example, the control channel was decoded, but the data could not be decoded), or when feedback was not received (for example, the control channel could not be decoded, or feedback on NACK was incorrectly decoded or blocked, for example, due to LBT).

Switching from directional LBT to omnidirectional LBT may be implemented, for example, based on information such as feedback on the HARQ-ACK. Namely, in some embodiments, the transmitting node may average the collected information for the downlink (DL) case. In one exemplary embodiment, a transmitting node in the case of DL such as a gNB may collect HARQ-ACK feedback from the UE and may decide to switch from directional LBT to broadcast LBT when the number of NACK messages exceeds a specific threshold within a given time period. or for a specified number of received HARQ feedback messages.

In some embodiments, switching from omnidirectional LBT to directional LBT may be performed when omniLBT prevents some number (e.g., a predetermined number or a number exceeding a specific threshold) of channel accesses, e.g., due to unprotected nodes rather than interference situations. In some embodiments, LBT switching may be performed based on reported information from a receiving (RX) node in accordance with the following exemplary mechanism described below.

In this example mechanism, the transmitting (TX) node can keep track of channel accesses that have been determined to be busy by the omniLBT and can store specific times of those determinations. When the TX can successfully access the channel, it can send information to the RX regarding the times of the prevented channel accesses. Meanwhile, the RX can perform continuous carrier sensing by energy detection (ED) with an antenna or beam configuration that is commonly used to receive data from a TX during a radio resource control (RRC) established connection mode, and can store the results in a memory. The RX, based on the prevented channel access times received from the TX, can compare these times with the results of the carrier sense by ED and respond to TX if the RX determines the signal energy is above the threshold using the antenna configuration or beam that is used to receive data from TX.

The TX, based on the response from the RX, may continue as follows: (i) if the presence of other neighboring transmitting nodes proves to be the root cause of the prevented channel accesses, the TX may continue to use omniLBT (e.g., after making an autonomous (or at least partially autonomous) decision about such action or after receiving a command from RX to perform it); (ii) if it turns out that other neighboring transmitting nodes are not the main cause of the prevented channel accesses, the TX may switch to dirLBT (eg, after an autonomous (or at least partially autonomous) decision to take such action, or after receiving a command from the RX for its implementation).

It should be noted that in some embodiments, switching from omniLBT to, for example, dirLBT may require new information, such as information to measure the level of overprotection or the number of missed transmission opportunities in the omniLBT mode. Therefore, in some embodiments, if a switch is to be performed, a procedure can be used to measure the overprotection of the omniLBT and thus allow the recognition scheme to switch to, for example, dirLBT.

In FIG. 29 shows a procedure 2500 for detecting omnidirectional LBT overprotection, in accordance with some embodiments. Such a procedure may include, for example, the following: (i) identifying the information 2506 transmitted from the transmitting node 2502 (also referred to as "TX"), for example, indexes of the interval or OFDM symbol (OS) in which an attempt was made to access to channel (and it turned out to be busy) ({x, y, z}, as, for example, shown in Fig. 29); and/or (ii) a response 2508 to the identity information 2506 sent from the receiving node 2504 (also referred to as "RX"). A variety of response options may be available, some examples of which include one or more of the following: (1) interval/OS indices in which the recognizable node was found, (2) percentage of attempts 2508 (as shown in FIG. 29) during which the channel was busy on the RX side, and/or (3) a toggle indicator 2510 (or switch) (as shown in FIG. 29).

Based on messaging, as shown, for example, in FIG. 29, the TX may know if it recognizes anything that the RX does not recognize (in which case it may, for example, switch the LBT strategy). If both transmitting and receiving nodes recognize the transmission, the TX may continue to use the omniLBT (policy). For example, in some embodiments, TX identity information 2506 may include indexes of slots or OFDM symbols when the channel was identified and its busy state was determined by omniLBT. In such a case, the RX may determine how much of the time that the TX node determined the busy channel state when the RX node also determined the busy channel state. The RX may respond to the TX with a value that includes this information, such as a percentage or fraction (see percentage 2508 in FIG. 29, left)), or may send a switch pointer (see, for example, switch pointer 2510 in FIG. 29 (right)) to inform the TX to switch the LBT mode.

In the case of DL, reports (3) (see above) contain less overhead but provide less detail on the TX side (eg, UE side) than (1) and (2). In some embodiments, a base station (eg, an eNB) may switch the LBT mode for all UEs in a cell that have established a connection. UE reporting based on formats (1) and (2) compared to format (3) may provide the base station with additional information to make a handover decision, but to use these reporting formats, the UE may, for example, need more signaling overhead than format (3). In some embodiments, the implementation of the switch may require, for example, exceeding a certain threshold for the number of received switch indicators for a particular Tx beam. In the case of UL, since a TX (eg, UE) may communicate with different TRPs via different beams, reports (1), (2) and/or (3) may be equivalent since no averaging is required at the TX (eg, UE). .

In addition, in some embodiments, the proposed mechanisms used to switch the LBT strategy may, for example, include switching (i) from omniLBT to pairLBT (soft change), (ii) from omniLBT to dirLBT (radical change, if determined, that omniLBT results in more missed channel access opportunities than necessary) or (iii) from pairLBT to dirLBT.

Furthermore, in some embodiments, the LBT switching procedure may be extended to cases including different access schemes for NR, such as, for example, DL (scheduled) access scheme, SUL (scheduled, based on UL grant) access scheme, and /or AUL access scheme (no UL grant). Since DL and SUL will generally have a higher priority for channel access than AUL, the LBT scheme may be limited by the need to be omnidirectional for some types of channel access and network densities, such as AUL in dense networks, by, for example, not granting permission to the procedure for switching LBT from omniLBT to LBT of any other type.

In accordance with some embodiments, methods and systems are described herein for resizing the Contention Access Window (CWS) for directional transmissions in the event of collisions.

In LAA, CWS is updated based on HARQ feedback messages. If, for example, 80% of the HARQ feedback messages of one reference subframe are NACKs, CWS is increased; otherwise, do not increase. It might be worthwhile to implement some form of CWS adaptation procedure based on observed conflicts (data) within the NR-U. However, in the case of, for example, transmission over a directed channel, the CWS adaptation procedure(s) adapted for use in LAA may not be suitable, and may, for example, require other CWS adaptation procedure(s).

In FIG. 30A and 30B show examples of CWS adaptation in multi-cell scenarios. For example, as shown in the example of FIG. 30A, the LBTs (represented by respective beams 2604 and 2606) of gNB 2600 and gNB 2602 (also referred to as "gNB1" and "gNB2", respectively) are not aligned and both gNBs 2600 and 2602 can listen on the channel during DIFS. Since the transmission of one gNB cannot or cannot be heard on the other gNB, a free channel state is determined for both gNBs 2600 and 2602. Therefore, both gNBs access the channel at essentially the same time, causing a collision. If the same CWS adaptation procedure as for LAA is used in this case, both gNBs can significantly increase CWS. Both gNBs listen again during DIFS, determine the channel's idle state again, and another conflict occurs. As a result, the same procedure will continue many times. In such a case, since the LBTs are not aligned (as shown in FIG. 30A), the procedure for increasing the CWS based on the HARQ may not be suitable.

The described CWS adaptation procedure may, for example, only be suitable for the scenario shown in FIG. 30B, in which the respective LBTs (represented by respective beams 2608 and 2610) of both gNBs 2600 and 2602 are aligned. If the gNBs 2600 and 2602 see each other, the channel access will likely be backed off and randomized by adapting the appropriate CWS.

In accordance with some embodiments, in cases of, for example, simultaneous or cooperative transmission from multiple gNBs when the transmission directions are not aligned with each other (as shown, for example, in FIG. 30A), the UE may force a backoff procedure to randomize access to channel of your gNB. In some embodiments, the UE may perform channel discovery in the direction of the receive beam as well as in the opposite direction, which is intended to cover the direction of the gNB transmit beam, and when determining the busy channel state for a time exceeding a specific threshold, the UE may send a message to the gNB station with excerpt request. In some embodiments, such a message may be a new message, or may be included as an additional parameter in an eDCTS message sent in response to an eDRTS message received from a gNB.

In some other embodiments, the implementation of the CWS adaptation on gNB may be based on statistical pair recognition at the target UE in the direction of the transmit beam. It may include channel identification in the direction of the receive beam as well as in the opposite direction, which is intended to cover the direction of the gNB transmit beam. In some embodiments, the target UE may propose the most suitable CWS across all transmission beam lines based on, for example, the percentage of occupied slots learned during the learning phase.

In still other embodiments, CWS adaptation based on, for example, HARQ NACK/ACK messages can be used if, for example, the NACK includes directional information from an identity indicating whether there is an interferer aligned with a transmission beam in which such the source could cause a conflict.

In general, as set forth herein, transmission at millimeter wave frequencies may, for example, require Tx-Rx (transmit-receive) directional operation. For transmissions on unlicensed frequencies, for example, channel identification may be additionally required to determine if the channel is free. In some implementations of the standard implementation, for example, LBT and RTS/CTS in the intended transmit/receive direction may not be sufficient to correctly determine the channel usage status due to, for example, the potential existence of directed hidden nodes. In FIG. 35 shows an example scenario 2850 including directed RTS/CTS when NR-U cooperating with NR-U in the presence of interfering nodes.

As described above, the methods and systems described herein, in accordance with some embodiments, solve problems associated with an unlicensed channel reservation method using Tx-Rx directed channel transmission in the presence of hidden nodes.

In FIG. 36 is a flowchart illustrating a steered channel reservation method in accordance with some embodiments. According to some embodiments, the method may be performed by a receiving node, such as a wireless transmit/receive module (eg, a UE). As shown in FIG. 36, in step 2900, the receiving node receives a Directed Channel Transfer (DRTS) request message from the transmitting node. In step 2902, the receiving node transmits a Directed Channel Transmission Ready (DCTS) message using one or more first beams, with at least one first beam pointing in a first direction towards the transmitting node. At 2904, the receiving node determines a second direction, the second direction being different from the first direction. Then, at step 2906, the transmitting node transmits at least one additional DCTS message using one or more second beams, with at least one second beam directed in a second direction towards the potentially interfering node.

In FIG. 37 is a flowchart illustrating another steered channel reservation method in accordance with some embodiments. In accordance with some embodiments, the method may be performed by the receiving node. As shown in FIG. 37, in step 3000, the receiving node receives an improved bearer transmission request message from the transmitting node. In step 3002, the receiving node transmits an improved acknowledgment message over a directed channel using one or more first beams, wherein at least one first beam is directed in a first direction towards the transmitting node. Then, in step 3004, the receiving node transmits at least one further enhanced acknowledgment message on a steered channel using one or more second beams, wherein at least one second beam is directed in a second direction towards the potentially interfering node, the second direction being different from the first. directions.

In some of the above embodiments, the methods and systems described herein use enhanced directed channel messaging (e.g., eDCTS and/or eDCTS-to-Self messages) towards, for example, potentially interfering node(s). s) (e.g. dominant interfering nodes). In some embodiments, the eDRTS message may contain data scheduling and eDCTS-to-Self messages and/or location and orientation of interfering nodes. In some embodiments, the eDCTS-to-Self transmission may be further targeted in the direction(s), e.g., potential (e.g., known(s)) interfering node(s) (e.g., obtained from gNB or by measurement(s)).

In some embodiments, the eDCTS-to-Self transmission may be repeated once every T period (or every given time period) (eg, based on a minimum CCA duration). In some embodiments, the eDCTS-to-Self message may contain information about the remaining duration of the MCOT. As shown in FIG. 31, for example, the MCOT may, for example, start immediately after sending the eDRTS, or immediately after the (eg, successful) LBT, and may include a plurality of T periods. FIG. 38 shows an example of a series of transmissions 3100 including eDRTS and eDCTS-to-Self transmissions, in accordance with some embodiments. In FIG. 38 shows an example of MCOT duration 3102 and periodic eDCTS-to-Self transmissions within the MCOT.

In FIG. 39 shows an exemplary interference scenario for eDRTS, eDCTS, and multiple eDCTS-to-Self procedure 3200 when NR-U is operated with NR-U in accordance with some embodiments. In some embodiments, for example, the example transmission configuration shown in FIG. 38 can be applied to the scenario depicted in FIG. 39. As shown in FIG. 39, gNB 3202 and UE 3204 (also referred to as "gNB2" and "UE3", respectively) may be, for example, nodes that can potentially interfere with UE 3208 (also referred to as "UE1"). As shown in FIG. 39, gNB 3206 (also referred to as “gNB1”) may transmit an eDRTS message 3210 for reception by UE 3208. UE 3208 may then transmit an eDCTS message 3212 using a beam directed towards gNB 3206. UE 3208 may also transmit multiple messages 3214 and 3216 eDCTS-to-Self directed to potentially interfering nodes. As shown, UE 3208 may transmit an eDCTS-to-Self message 3214 using a beam directed towards gNB 3202 and may transmit an eDCTS-to-Self message 3216 using a beam directed towards UE 3204.

As noted above, potentially hidden nodes can interfere with directional channel transmission and reception on unlicensed frequencies. In accordance with some embodiments that are described herein, a UE may perform directed channel access using enhanced multi-directional messaging to reserve a channel between the UE and a transmitting node (eg, gNB).

In some embodiments, a method performed by the UE to reserve a channel may include: receiving an enhanced Directed Channel Transfer Request (eDRTS) message from a transmitting node; transmitting an enhanced Directed Channel Ready to Send (eDCTS) message in a first direction to the transmitting node; and transmitting an additional eDCTS message in the second direction to the potentially interfering node.

In some embodiments, the implementation of the second direction is opposite to the first direction.

In some embodiments, the UE may determine the second direction (towards the potentially interfering node) from the eDRTS message or listen-before-transmit (LBT) analysis.

In some embodiments, the UE may transmit the eDCTS message multiple times within the MCOT.

In addition, various other and related embodiments have been described above.

In accordance with some embodiments, a method for eliminating, at a receiving node, potential interference from one or more potentially hidden network nodes during directional channel transmission and reception between a receiving node and a transmitting node on unlicensed frequencies may include the receiving node performing a directional channel access with using enhanced multidirectional messaging to reserve a directional channel between the receiving node and the transmitting node. In some embodiments, the receiving node is a UE and the transmitting node is a base station (eg, gNB).

In accordance with some embodiments, a method performed by a device, such as, for example, a UE, for accessing a directed channel is described. Such a method includes an apparatus transmitting a plurality of channel reservation signals in one or more directions that are different from the direction towards the intended receiver for subsequent data transmission. In some embodiments, the method may also include: receiving a first type message (eg, enhanced Directed Channel Transfer Request (eDRTS)) in a first direction; and transmitting a message of the second type (eg, enhanced readiness for transmission over a directed channel (eDCTS)) in the first direction and the second direction. In some embodiments, the first and second directions are different, and at least one of the first and second directions is towards a potential interfering node. In some embodiments, the direction to the potentially interfering node may be indicated by a first type of message. In some embodiments, the second type of message is an enhanced Directed Channel to Self (eDCTS-to-Self) message. In some embodiments, the second type of message is an eDCTS, and the eDCTS message may be resent by the device a plurality of times within a given amount of time, such as maximum channel busy time (MCOT).

In accordance with some embodiments, a method performed at a transmitting node includes: performing a first listen before transmitting (LBT) in the direction of a transmitting beam towards a receiving node; determining whether the channel is busy based on the performed first LBT in the direction of the transmission beam; performing the second LBT in the opposite direction; and determining whether an interfering signal from the reverse direction is detected. In some embodiments, the implementation of the method may further include delaying the transmission in case of detection of an interfering signal. Backoff may, for example, include waiting for a backoff time and performing the first and second LBTs again. In addition, various parameters may be adaptively selected, including, for example, beamwidth configuration, number of predefined beams, energy detection threshold, and/or MCS selection for the link.

In accordance with some embodiments, methods are described for cooperative operation of NR-U and WiGig systems, in which, for example, a device (e.g., UE) can adaptively set the transmit power and/or the number of retries in the direction of the interferer until the time of the interferer persists.

In accordance with some embodiments, a method is described for use among multiple nodes to enable reuse of resources in the unlicensed band by applying listen-before-transmit (LBT) coordination. In such a method, the unlicensed band may be below 6 GHz or the millimeter wave band. The plurality of nodes may further be associated with a given radio access technology (RAT) and/or a given operator.

In accordance with several embodiments, a method for signaling a coordinated listen before transmission (LBT) between nodes may include: receiving, at a first node, an LBT coordination request from a second node; and, after agreeing to the request at the first node, providing the second node with an indication of this LBT coordination to perform backtracking based on the LBT. In some embodiments, the method may further include a second node performing backoff based on the LBT. In still other embodiments, the implementation of the method may further include using transmission coordination between the first and second nodes for transmission by the second node after the end of the backlog based on the LBT and the second node has received the channel access. The first and second nodes may be associated with a given radio access technology (RAT), eg the same RAT, or a given operator, eg the same operator. In addition, the first and second nodes may be coordinated to transmit in an unlicensed band, such as the 5 GHz or 60 GHz band, for example. In still other embodiments, the method for coordinated LBT signaling may also include providing the first node to the second node with at least one of the start time of the transmission coordination and the transmission coordination strategy to be used upon completion of the LBT backoff.

In the LBT coordinated signaling method, LBT coordination may occur within a maximum channel busy time (MCOT). In addition, the first and second nodes may be 5G nodes such as the first gNB and the second gNB.

In some embodiments, this LBT coordination to perform LBT backoff may be a frequency domain LBT coordination in which, for example: upon receiving an LBT coordination request at the first node, the first node releases the frequency resource(s) ; the first node provides an indication of the released frequency resource(s) to the second node; and upon receiving the indication from the first node, the second node transitions from using LBT in the entire band to using LBT in the sub-band within the specified freed frequency resource(s). The released frequency resource(s) may be specified in the agreement for frequency-related coordination, may include a portion of the bandwidth (BWP), and/or may be released for this period of time. In some embodiments, the remaining dwell time may be sent by the second node at the same time or in conjunction with the LBT coordination request so that the first node can configure the released frequency resource(s) according to the remaining dwell time.

In some embodiments, this LBT coordination to perform LBT backoff may be a frequency domain LBT coordination in which, for example: upon receiving an LBT coordination request at the first node, the first node releases the temporary resource(s) to perform exposure due to LBT; the first node provides an indication of the released frequency resource(s) to the second node; and after receiving the indication from the first node, the second node continues to use the LBT in the entire band. The released time resource(s) may be specified in the time-related coordination handshake and/or may include one or more OFDM symbols. In addition, in some embodiments, the remaining dwell time may be sent by the second node at the same time or in conjunction with the LBT coordination request so that the first node can configure the released frequency resource(s) according to the remaining dwell time. .

In accordance with some embodiments, the method includes providing listen-before-transmit (LBT) coordination-related signaling that is suitable for use over the 5G Xn interface. In some embodiments, signaling associated with LBT coordination may include coordinated LBT request signaling (LBTRS). The LBTRS may be sent over the Xn interface, for example by a gNB detecting a busy channel due to the presence of a node that shares a Radio Access Technology (RAT) with the gNB. In addition, the LBTRS may include (i) a request for intra-RAT LBT coordination within the Maximum Channel Occupancy Time (MCOT), (ii) remaining dwell time, (iii) identification of the gNB requesting intra-RAT LBT coordination, and/or ( iv) identification of the gNB that is being asked to coordinate the LBT within the RAT.

In some embodiments, signaling associated with LBT coordination may also include allowed coordinated LBT signaling (LBTES). The LBTES may be sent over the Xn interface by the gNB that occupies the channel and receives the LBTRS. The LBTES may further include (i) agreement to LBT coordination in the frequency domain to perform the backoff, (ii) an indication of the released frequency domain resources, (iii) agreement to the LBT coordination in the time domain to perform the backoff, (iv) the start time of the coordination transmission, (v) a transmission coordination strategy, (vi) a time limit to maximum channel busy time (MCOT), (vii) identification of the gNB requesting LBT coordination within the RAT, and/or (viii) identification of the gNB requested for intra-RAT LBT coordination RAT.

In accordance with some embodiments, the method includes switching between at least two different listen-before-transmit (LBT) modes in the unlicensed band. In some embodiments, multiple radio access technologies (RATs) operate together in the unlicensed band. In addition, in some embodiments, switching is performed for directional transmissions and/or receptions. In addition, handover may be prohibited for a given type of new radio (NR) channel access scheme.

The at least two different types of LBTs may include an omnidirectional LBT and a directional LBT. The handover may be a handover (i) from an omnidirectional LBT to a paired LBT, (ii) from an omnidirectional LBT to a directional LBT, or (iii) from a paired LBT to a directional LBT.

In some embodiments, handover includes switching from a broadcast LBT to a directional LBT when the broadcast LBT prevents a given number of channel accesses, eg, due to unprotected nodes rather than interference.

In other embodiments, the handover includes switching from a broadcast LBT to a directional LBT, wherein switching from a broadcast LBT to a directional LBT includes: the transmitting node keeping track of the channel accesses in which the busy status has been determined by the broadcast LBT, and storing points in time corresponding to these definitions; upon gaining access to the channel, the transmitting node sends to the receiving node information regarding the times of prevented channel accesses; the receiving node compares the prevented channel access times received from the transmitting node with the results of continuous carrier monitoring by energy detection (ED) performed at the receiving node; and the receiving node notifies the transmitting node of the result of the comparison. In some embodiments, the transmitting node, based on notification from the receiving node, continues to use broadcast LBT or switches to directed LBT.

In accordance with some embodiments, a method for changing the contention window size (CWS) for directional transmissions includes a user equipment, such as, for example, a user equipment (UE), requesting a backoff from a base station, such as, for example, a gNB.

In accordance with some embodiments, a method is described for changing the contention window (CWS) size for transmission over a directed channel at a base station (eg, gNB). Such a method is based on pairwise authentication at the target user device (eg, user equipment (UE)).

In accordance with some embodiments, a method for dynamically configuring downlink/uplink switching for each link of the paired beams (BPL) includes using, for example, periodic transmissions of an enhanced Directed Link Ready to Self (eDCTS-to-Self) message. ). In some embodiments, during data transmission, a transmitter or receiver, or both, may periodically transmit multiple eDCTS-to-Self messages to maintain channel reservation.

While the features and elements are described herein in specific combinations, it will be apparent to those skilled in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embedded in a computer-readable medium and designed to be executed by a computer or processor. Examples of computer-readable storage media include, without limitation, read-only memory (ROM), random access memory (RAM), register, cache memory, semiconductor storage devices, magnetic media such as internal hard drives and removable drives, magneto-optical media and optical media such as CD-ROMs and digital versatile discs (DVDs). The processor, in combination with software, may be used to implement an RF transceiver for use in a WTRU, user equipment, terminal, base station, RNC, and/or any host computer.

Claims (58)

1. A method performed by a receiving node to reserve a directional channel, the method including: receiving a Directed Channel Transfer Request (DRTS) message from the transmitting node; transmitting a Ready to Send Directed Channel (DCTS) message using one or more first beams, wherein at least one first beam is directed in a first direction toward the transmitting node; determining a second direction, wherein the second direction is a direction different from the first direction; transmitting at least one additional DCTS message using one or more second beams, wherein at least one second beam is directed in a second direction towards the potentially interfering node; and receiving data from the transmitting node; periodically transmitting a subsequent one or more additional DCTS messages in at least the second direction within the maximum channel busy time (MSOT) in the course of receiving data from the transmitting node. 2. The method according to claim 1, in which: the receiving node is a wireless transmission/reception module, and the transmitting node is a base station. 3. The method according to claim 1 or 2, wherein determining the second direction includes: determining a second direction based on information from the listening-before-transmitting (LBT) analysis of the directional channel. 4. The method of claim 1 or 2, wherein the DRTS message contains an indication of a second direction, and wherein the determination of the second direction includes: determining a second direction based on the indication in the DRTS message. 5. The method of claim 1 or 2, wherein determining the second direction includes: determining a second direction based on the directional channel measurements. 6. The method according to any one of paragraphs. 1-5, in which: the DRTS message is an enhanced DRTS message (eDRTS), and the DCTS message is an enhanced DCTS message (eDCTS). 7. The method of claim 6, wherein determining the second direction includes: determining a second direction based on the eDRTS message. 8. The method according to any one of paragraphs. 1-7, wherein the at least one additional DCTS message is an enhanced DCTS-to-Self (eDCTS-to-Self) message. 9. The method according to any one of paragraphs. 1-8, in which the DCTS message sent towards the transmitting node indicates the number of transmissions of the eDCTS-to-Self message to be performed by the receiving node. 10. The method according to any one of paragraphs. 1-9, wherein the at least one additional DCTS message includes a backoff duration field indicating the amount of time to delay transmission. 11. The method according to any one of paragraphs. 1-10, in which at least one additional DCTS message indicates the remaining time for which the directed channel is reserved. 12. The method according to any one of paragraphs. 1-11, in which at least one additional DCTS message includes the time remaining from the maximum channel busy time (MCOT). 13. The method according to any one of paragraphs. 1-12, wherein at least one additional DCTS message contains a plurality of enhanced DCTS messages (eDCTS). 14. The method according to any one of paragraphs. 1-13, wherein the transmission of at least one additional DCTS message includes: transmitting at least one additional DCTS message a plurality of times within a maximum channel busy time (MCOT). 15. The method according to any one of paragraphs. 1-14, wherein the transmission of at least one additional DCTS message using one or more second beams includes: transmitting at least one additional DCTS message on different beams. 16. The method according to any one of paragraphs. 1-15 performed by the receiving node to reserve a directional channel in the unlicensed spectrum. 17. The method according to any one of paragraphs. 1-16, further comprising: receiving a second DRTS message from the transmitting node; and transmitting a directional channel transmission rejection (DDTS) message to the transmitting node in response to the second DRTS message when the receiving node detects potential directional interference. 18. The method according to claim 17, in which: the DDTS message is an enhanced DDTS message (eDDTS) and the eDDTS message identifies the node that is transmitting the interfering signal. 19. The method according to any one of paragraphs. 1-18, wherein the number of at least one additional DCTS message transmitted is based on at least one of (i) the number of potentially interfering nodes, (ii) the power of one or more second beams, and (iii) the width of one or more second beams. . 20. The method according to any one of paragraphs. 1-19, in which the content of each of the DRTS messages, DCTS and at least one additional DCTS message is scrambled using a sequence that is common to a group of cells. 21. The method according to any one of paragraphs. 1-19, in which the content of each of the DRTS messages, DCTS and at least one additional DCTS message is scrambled using a cell group sequence (CGS) that is common to a group of cells. 22. The method according to any one of paragraphs. 1-21, further comprising: performing a first analysis of directional listening before transmission (LBT) towards another node to which the transmission from the receiving node is intended, the other node being different from the transmitting node; determining whether a channel between the receiving node and another node is busy based on performing a first directional LBT analysis; performing a second backward directed LBT analysis; and determining if an interfering signal is detected from the reverse direction, to either continue transmission to another node or delay transmission when an interfering signal is detected. 23. Wireless transmit/receive module (WTRU), comprising: CPU; and memory configured to store a plurality of instructions that, when executed by the processor, cause the processor to execute: receiving a Directed Channel Transfer Request (DRTS) message from the transmitting node; transmitting a Ready to Send Directed Channel (DCTS) message using one or more first beams, wherein at least one first beam is directed in a first direction toward the transmitting node; determining a second direction, the second direction being a direction different from the first direction; transmitting at least one additional DCTS message using one or more second beams, wherein at least one second beam is directed in a second direction towards the potentially interfering node; and receiving data from the transmitting node; periodically transmitting a subsequent one or more additional DCTS messages in at least the second direction within the maximum channel busy time (MSOT) in the course of receiving data from the transmitting node. 24. Directed channel reservation system, comprising: receiving node; CPU; and a physical computer-readable medium that stores instructions, the execution of which by the processor leads to the execution of the method according to any one of paragraphs. 1-22. 25. The system of claim 24, wherein the receiving node includes a processor and a physical computer-readable medium.

Images