[go: up one dir, main page]

WO2021155929A1 - Mécanisme de détection et d'évitement pour réseaux sans fil - Google Patents

Mécanisme de détection et d'évitement pour réseaux sans fil Download PDF

Info

Publication number
WO2021155929A1
WO2021155929A1 PCT/EP2020/052960 EP2020052960W WO2021155929A1 WO 2021155929 A1 WO2021155929 A1 WO 2021155929A1 EP 2020052960 W EP2020052960 W EP 2020052960W WO 2021155929 A1 WO2021155929 A1 WO 2021155929A1
Authority
WO
WIPO (PCT)
Prior art keywords
timer
channel
idle
transmission
transmit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2020/052960
Other languages
English (en)
Inventor
Timo Erkki Lunttila
Karol Schober
Esa Tapani Tiirola
Kari Juhani Hooli
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Technologies Oy
Original Assignee
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Priority to PCT/EP2020/052960 priority Critical patent/WO2021155929A1/fr
Publication of WO2021155929A1 publication Critical patent/WO2021155929A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0808—Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/52—Allocation or scheduling criteria for wireless resources based on load

Definitions

  • This description relates to wireless communications.
  • a communication system may be a facility that enables communication between two or more nodes or devices, such as fixed or mobile communication devices. Signals can be carried on wired or wireless carriers.
  • LTE Long Term Evolution
  • APs base stations or access points
  • eNBs enhanced Node AP
  • UE user equipments
  • LTE has included a number of improvements or developments. Aspects of LTE are also continuing to improve.
  • 5G New Radio (NR) development is part of a continued mobile broadband evolution process to meet the requirements of 5G, similar to earlier evolution of 3G & 4G wireless networks.
  • 5G is also targeted at the new emerging use cases in addition to mobile broadband.
  • a goal of 5 G is to provide significant improvement in wireless performance, which may include new levels of data rate, latency, reliability, and security.
  • 5G NR may also scale to efficiently connect the massive Internet of Things (IoT) and may offer new types of mission-critical services. For example, ultra-reliable and low- latency communications (URLLC) devices may require high reliability and very low latency.
  • URLLC ultra-reliable and low- latency communications
  • a method may include determining a first initial value for a transmit timer and a second initial value for an idle timer; setting the transmit timer to the first initial value and the idle timer to the second initial value; and performing the following until at least one of the transmit timer or the idle timer expires: scheduling a channel of a wireless network for data transmission and decrementing the transmit timer when there is data to be transmitted via the channel; and otherwise, decrementing the idle timer when there is no data to be transmitted via the channel.
  • FIG. 1 is a block diagram of a wireless network according to an example embodiment.
  • FIG. 2 is a diagram illustrating a hidden node issue for a beam-based transmission according to an example embodiment.
  • FIG. 3 is a block diagram illustrating use and adjustment of timers according to an example embodiment.
  • FIG. 4 is a diagram illustrating example beam pair links according to an example embodiment.
  • FIG. 5 is a flow chart illustrating operation of a node according to an example embodiment.
  • FIG. 6 is a flow chart illustrating operation of a node according to an example embodiment.
  • FIG. 7 is a block diagram of a wireless station or wireless node (e.g., AP, BS, gNB, RAN node, relay node, UE or user device, or other node) according to an example embodiment.
  • a wireless station or wireless node e.g., AP, BS, gNB, RAN node, relay node, UE or user device, or other node.
  • FIG. 1 is a block diagram of a wireless network 130 according to an example embodiment.
  • user devices 131, 132, 133 and 135, which may also be referred to as mobile stations (MSs) or user equipment (UEs) may be connected (and in communication) with a base station (BS) 134, which may also be referred to as an access point (AP), an enhanced Node B (eNB), a BS, next generation Node B (gNB), a next generation enhanced Node B (ng-eNB), or a network node.
  • AP access point
  • eNB enhanced Node B
  • gNB next generation Node B
  • ng-eNB next generation enhanced Node B
  • ng-eNB next generation enhanced Node B
  • a BS may also include or may be referred to as a RAN (radio access network) node, and may include a portion of a BS or a portion of a RAN node, such as (e.g., such as a centralized unit (CU) and/or a distributed unit (DU) in the case of a split BS).
  • a BS e.g., access point (AP), base station (BS) or (e)Node B (eNB), BS, RAN node
  • AP access point
  • BS base station
  • eNB Node B
  • BS RAN node
  • RAN node may also be carried out by any node, server or host which may be operably coupled to a transceiver, such as a remote radio head.
  • BS (or AP) 134 provides wireless coverage within a cell 136, including to user devices (or UEs) 131, 132, 133 and 135. Although only four user devices (or UEs) are shown as being connected or attached to BS 134, any number of user devices may be provided.
  • BS 134 is also connected to a core network 150 via a SI interface or NG interface 151. This is merely one simple example of a wireless network, and others may be used.
  • a base station e.g., such as BS 134) is an example of a radio access network (RAN) node within a wireless network.
  • RAN radio access network
  • a BS may be or may include (or may alternatively be referred to as), e.g., an access point (AP), a gNB, an eNB, or portion thereof (such as a centralized unit (CU) and/or a distributed unit (DU) in the case of a split BS or split gNB), or other network node.
  • AP access point
  • gNB gNode B
  • eNB e.g., a centralized unit (CU) and/or a distributed unit (DU) in the case of a split BS or split gNB
  • DU distributed unit
  • a BS node e.g., BS, eNB, gNB, CU/DU, ...
  • a radio access network may be part of a mobile telecommunication system.
  • a RAN radio access network
  • the RAN (RAN nodes, such as BSs or gNBs) may reside between one or more user devices or UEs and a core network.
  • each RAN node e.g., BS, eNB, gNB, CU/DU, ...
  • BS may provide one or more wireless communication services for one or more UEs or user devices, e.g., to allow the UEs to have wireless access to a network, via the RAN node.
  • Each RAN node or BS may perform or provide wireless communication services, e.g., such as allowing UEs or user devices to establish a wireless connection to the RAN node, and sending data to and/or receiving data from one or more of the UEs.
  • a RAN node e.g., BS, eNB, gNB, CU/DU, ...
  • a RAN node may forward data to the UE that is received from a network or the core network, and/or forward data received from the UE to the network or core network.
  • RAN nodes may perform a wide variety of other wireless functions or services, e.g., such as broadcasting control information (e.g., such as system information) to UEs, paging UEs when there is data to be delivered to the UE, assisting in handover of a UE between cells, scheduling of resources for uplink data transmission from the UE(s) and downlink data transmission to UE(s), sending control information to configure one or more UEs, and the like.
  • broadcasting control information e.g., such as system information
  • paging UEs when there is data to be delivered to the UE, assisting in handover of a UE between cells, scheduling of resources for uplink data transmission from the UE(s) and downlink data transmission to UE(s), sending control information to configure one or more UEs, and the like.
  • control information e.g., such as system information
  • paging UEs when there is data to be delivered to the UE, assisting in handover of a UE between
  • a base station may also be DU (Distributed Unit) part of IAB (Integrated Access and Backhaul) node (a.k.a. a relay node). DU facilitates the access link connection(s) for an IAB node.
  • a user device user terminal, user equipment (UE), mobile terminal, handheld wireless device, etc.
  • UE user equipment
  • UE mobile terminal
  • handheld wireless device may refer to a portable computing device that includes wireless mobile communication devices operating either with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: a mobile station (MS), a mobile phone, a cell phone, a smartphone, a personal digital assistant (PDA), a handset, a device using a wireless modem (alarm or measurement device, etc.), a laptop and/or touch screen computer, a tablet, a phablet, a game console, a notebook, a vehicle, a sensor, and a multimedia device, as examples, or any other wireless device.
  • SIM subscriber identification module
  • a user device may also be (or may include) a nearly exclusive uplink only device, of which an example is a camera or video camera loading images or video clips to a network.
  • a user device may be also MT (Mobile Termination) part of LAB (Integrated Access and Backhaul) node (a.k.a. a relay node). MT facilitates the backhaul connection for an IAB node.
  • LAB Integrated Access and Backhaul
  • core network 150 may be referred to as Evolved Packet Core (EPC), which may include a mobility management entity (MME) which may handle or assist with mobility/handover of user devices between BSs, one or more gateways that may forward data and control signals between the BSs and packet data networks or the Internet, and other control functions or blocks.
  • EPC Evolved Packet Core
  • MME mobility management entity
  • gateways may forward data and control signals between the BSs and packet data networks or the Internet, and other control functions or blocks.
  • 5G which may be referred to as New Radio (NR)
  • NR New Radio
  • New Radio (5G) development may support a number of different applications or a number of different data service types, such as for example: machine type communications (MTC), enhanced machine type communication (eMTC), Internet of Things (IoT), and/or narrowband IoT user devices, enhanced mobile broadband (eMBB), and ultra-reliable and low-latency communications (URLLC).
  • MTC machine type communications
  • eMTC enhanced machine type communication
  • IoT Internet of Things
  • URLLC ultra-reliable and low-latency communications
  • Many of these new 5G (NR) - related applications may require generally higher performance than previous wireless networks.
  • IoT may refer to an ever-growing group of objects that may have Internet or network connectivity, so that these objects may send information to and receive information from other network devices.
  • many sensor type applications or devices may monitor a physical condition or a status, and may send a report to a server or other network device, e.g., when an event occurs.
  • Machine Type Communications MTC, or Machine to Machine communications
  • MTC Machine Type Communications
  • eMBB Enhanced mobile broadband
  • Ultra-reliable and low-latency communications is a new data service type, or new usage scenario, which may be supported for New Radio (5G) systems.
  • 5G New Radio
  • 3 GPP targets in providing connectivity with reliability corresponding to block error rate (BLER) of lO 5 and up to 1 ms U-Plane (user/data plane) latency, by way of illustrative example.
  • BLER block error rate
  • U-Plane user/data plane
  • URLLC user devices/UEs may require a significantly lower block error rate than other types of user devices/UEs as well as low latency (with or without requirement for simultaneous high reliability).
  • a URLLC UE or URLLC application on a UE
  • eMBB UE or an eMBB application running on a UE.
  • the various example embodiments may be applied to a wide variety of wireless technologies or wireless networks, such as LTE, LTE-A, 5G (New Radio (NR)), cmWave, and/or mmWave band networks, IoT, MTC, eMTC, eMBB, URLLC, etc., or any other wireless network or wireless technology.
  • LTE Long Term Evolution
  • LTE-A Long Term Evolution
  • 5G New Radio
  • cmWave and/or mmWave band networks
  • IoT IoT
  • MTC Mobility Management Entity
  • eMTC enhanced mobile communications
  • eMBB enhanced Mobile Broadband
  • the millimeter-wave (mmWave) spectrum offers the possibility of using large portions of contiguous bandwidth to address high-throughput applications.
  • mmWave millimeter-wave
  • the 5th Generation (5G) New Radio (NR) frequency spectrum may extend well-above the previous 4th Generation (4G) frequency spectrum, which ranges from 400 MHz to 6 GHz - otherwise known in NR as Frequency Range 1 (FR1).
  • Frequency Range 2 may include the frequencies between 24 GHz and 52 GHz; and extending the NR operation into the 52-114 GHz range is currently being discussed, as illustrative examples of possible frequency ranges that may be used.
  • unlicensed wireless/radio bands there are a number of global unlicensed wireless/radio bands available, such as one or more unlicensed bands in the range of 57-71 GHz (as an example), making the unlicensed operation at mmWaves an interesting option for wireless devices, such as for 5G/NR operation, and other wireless devices.
  • a portion of the band such as 66-71 GHz, may be allocated at least partially (also) for licensed band operation.
  • operation in an unlicensed spectrum may be regulated by certain channel access or spectrum sharing rules that target fair spectrum use among different radio access technologies (RATs) on the same shared unlicensed spectrum.
  • RATs radio access technologies
  • the access or sharing rules for an unlicensed band access may require wireless devices to employ a detect-and-avoid (DAA) mechanism, e.g., which may be used to detect when a channel or wireless spectrum is occupied (e.g., another node is already transmitting on the channel or spectrum) and avoid causing a collision on the occupied channel or spectrum.
  • DAA detect-and-avoid
  • a DAA mechanism may include listen-before-talk (LBT), in which wireless nodes perform channel sensing in order to confirm that the channel is unoccupied, before transmitting on the channel.
  • LBT listen-before-talk
  • Channel sensing may include, for example, sensing whether a channel is occupied (or not) by another wireless device or wireless node.
  • Channel sensing may include, for example, detecting an energy level of a channel, and comparing the detected energy level to a threshold, where an energy level less than or equal to the threshold indicates that the channel is unoccupied (and may be used or transmitted on), while an energy level greater than the threshold may indicate that the channel is occupied (e.g., indicating that another device is transmitting on the channel).
  • channel sensing or LBT listen-before-talk
  • the transmitter transmitting device or node
  • channel sensing or LBT may be performed per beam or in a directional manner, for example.
  • a device or wireless node may apply a receive beam for channel sensing and then apply the same beam as a transmit beam to transmit a signal if the channel is unoccupied, as an illustrative example.
  • the transmitting device may typically prepare a block of data for transmission prior to performing channel sensing or LBT, because the device may typically need to transmit such block of data relatively quickly if the channel sensing indicates that the channel is idle or unoccupied.
  • a failed channel sensing e.g., if the channel sensing indicated that the channel is occupied or busy
  • other DAA mechanisms may include, e.g., adjusting a transmission duty cycle, such as a low duty cycle per carrier (which may be performed in combination e.g., with frequency hopping), and channel access mechanisms that use channel sensing for adjusting collision avoidance.
  • Some other example DAA mechanisms may include channel selection, e.g. after detecting transmission on a channel, avoiding that channel and selecting another channel instead; after detecting a channel to be busy, suspending the transmissions for, e.g., a predefined amount of time; or adaptive power reduction (avoidance) when a collision is detected on the channel.
  • FIG. 2 is a diagram illustrating a hidden node issue for a beam-based transmission according to an example embodiment.
  • a BS 210 may be intending to transmit to UE 212, and thus may first generate or provide a measurement (or receive) beam 213 to perform channel sensing in the direction of proposed transmission (e.g., using the same beam that will be used to transmit to UE 212).
  • a BS 214 may already be transmitting or occupying the channel, by BS 214 transmitting a signal via transmit beam 215 to UE 216, for example.
  • the BS 210 may detect (by generating the measurement or receive beam 213) an energy level (e.g., based on a signal transmitted by BS 214 via transmit beam 215 that overlaps with receive beam 213) above a threshold via its measurement or receive beam 213.
  • the BS 210 intending to transmit, may detect that the channel is busy or occupied, and thus, may be unable to transmit on the channel.
  • BS 220 may be transmitting a signal to UE 222 via transmit beam 221.
  • UE 224 may perform channel sensing via measurement/receive beam 225 and may detect the occupation or busy channel (e.g., based on an overlap between receive beam 225 and transmit beam 221).
  • BS 230 also intends to transmit to UE 224 on the (same) channel or spectrum, and may also first apply or generate a measurement or receive beam in the direction 231 towards UE 224.
  • the BS 230 may, or may not, be able to detect the transmission energy on the channel resulting from the transmission from BS 220 that is already occupying the channel.
  • the BS 220 may be considered a hidden node (with respect to BS 230, for example) that may not necessarily be detected by the BS 230 when performing directional (beam based) channel sensing.
  • the detection of the channel occupation may be assisted if the UE 224 (e.g., the intended destination for a proposed transmission by BS 230) also performs channel sensing via measurement beam 225, and reports to BS 230 that the channel is currently busy or occupied.
  • LBT may not necessarily work well for beam-based transmissions, since signals are typically transmitted via relatively narrow beams, and may not be detected by channel sensing.
  • LBT or DAA operation may typically be performed in the intended transmit direction, e.g., the transmitter may typically perform channel sensing using the beam it intends to use for the scheduled/planned transmission, instead of e.g., listening to (sensing energy from) all directions at the same time.
  • a device with analog beamforming may not be capable of performing an omnidirectional LBT at a single time instance.
  • analog or hybrid beamforming may be used, with fast switching between different transmit beams. It is thus useful for a gNB/BS that is serving a UE with a certain beam, to be able to quickly change to another beam and, e.g., transmit a periodic signal or receive a transmission scheduled earlier, and then switch beams again to return to serving the first UE.
  • Such flexible beam operation would be possible if the channel access availability does not need to be verified (e.g., immediately) before transmission (or immediately before each transmission), or if a transmission towards certain beam direction (assuming that channel access is acquired per beam) does not need to be strictly continuous in time.
  • contiguous transmission on a certain beam within a channel occupancy time may not be suitable to 60GHz scenarios where frequent analog beam switching may be required.
  • another device may perform LBT and access the channel during a transmission gap within a channel occupancy time. After the transmission gap, both devices are (or may be) transmitting on the same channel causing interference between the transmissions.
  • LBT may not be a suitable coexistence mechanism.
  • some form of coexistence mechanism may be required.
  • some of the wireless or communication links or channels targeted (or which may be used) for 60 GHz unlicensed spectrum operation e.g., such as UL (uplink) part of access link, mobile relays links and/or the DL (downlink) part of access link, may be subject to adequate spectrum sharing requirements fulfilled by DAA channel access mechanism.
  • channel sensing may be performed directionally (beam specific) but not necessarily (e.g., immediately) before each transmission.
  • At least some of the existing DAA mechanisms may have one or more shortcomings or disadvantages, such as using a low transmission power, too small transmission duty cycle, too long of backoff times, and/or sensing at only the transmitter, and/or requiring sensing before each transmission (e.g., which may result in inefficient use of memory and processing resources).
  • DAA detect-and-avoid
  • a duty cycle (or transmission duty cycle) for a channel or spectrum may be flexibly determined or provided by the use of one or two timers.
  • a transmission duty cycle may indicate a period or portion of time a channel is provided (or available) for transmission, as compared to a period of time the channel is provided for both idle and transmission.
  • an UL transmission duty cycle of a channel may include a percentage (or portion) of time periods (e.g., a portion or number of symbols, slots, or, other time periods, where a slot may include 14 symbols or other number of symbols) that are available to a UE for UL transmission (e.g., a percentage of time periods or slots for which UL resources have been allocated to the UE for UL transmission to the BS).
  • a transmission duty cycle for a channel may include a portion or percentage of time periods (e.g., slots), within a longer period of time, for which a node(s) may be permitted to transmit on the channel.
  • a duty cycle (or transmission duty cycle) for a channel or spectrum may be flexibly determined or provided by the use of one or two timers.
  • the timers may be set to values or initial values based on a congestion metric determined for the channel, or other value or metric.
  • a congestion metric may be associated with or may indicate an amount of traffic congestion on a channel.
  • an increased amount of congestion for a channel may be associated with or may be a result of a higher amount of data transmissions, data collisions (e.g., multiple transmitters transmitting at the same time or on the same resources, resulting in a data collision), a higher block error rate, and/or increased errors at the receiver.
  • data collisions e.g., multiple transmitters transmitting at the same time or on the same resources, resulting in a data collision
  • block error rate e.g., multiple transmitters transmitting at the same time or on the same resources, resulting in a data collision
  • a transmission duty cycle for a channel for a UE when the congestion metric indicates low congestion (or a low amount of traffic or a low amount of channel usage) so as to increase the channel usage, and it may be likewise desirable to decrease a transmission duty cycle for the UE (or for communications between UE and the BS) if the congestion metric for the channel is high (e.g., indicating a higher amount of collisions, or a higher block error rate, or a higher amount of traffic/data transmissions already on the channel) so as to reduce channel usage.
  • the transmission duty cycle for the channel may be adjusted based on the measured congestion metric for the channel.
  • FIG. 3 is a block diagram illustrating use and adjustment of timers according to an example embodiment.
  • the apparatus or functions shown in FIG. 3 may be provided as hardware, logic, and/or as functions provided or performed by a processor, for example, within or as part of a BS, gNB, transmit receive point (TRP), or other network node or wireless node.
  • a node may include other blocks, functions or apparatus that are not shown in FIG. 3.
  • one or more blocks or functions shown in FIG. 3 may be included, or may be omitted, within a system or within a node.
  • the system may include one or more timers, and other circuits, blocks or functions, for example.
  • a transmit timer 314 and an idle timer 316 may be provided.
  • one or more congestion-related parameters 308 may be input via line 309 to a congestion metric determination block 310.
  • a congestion-related parameter for the channel may include, e.g., one or more of: parameters, measured by a user equipment, associated with a congestion metric, and reported to the base station; a block error rate or a bit error rate determined for one or more transport blocks; a radio energy measurement or a listen before talk measurement, performed more than a clear channel assessment slot before transmission; radio energy measurement or error rate measured over one or more symbols or one or more slots; a discrete or quantized congestion level based on a quantization of a measured congestion level; an average of a plurality of different congestion metrics; or a most congested or most pessimistic congestion metric of a plurality of different congestion metrics; and/or other congestion-related parameters.
  • Congestion-metric determination block 310 may determine a congestion metric (or a value providing a congestion indication) for the channel, e.g., based on the one or more congestion-related parameters 308.
  • an update timer initial values block 312 may determine (e.g., determine updated) initial timer values for the transmit timer 314 and/or the idle timer 316, e.g., based on the congestion metric received via line 311 from congestion metric determination block 310.
  • the transmit timer 314 may be set to a first initial value provided via line 318
  • the idle timer 316 may be set to a second initial value provided via line 320.
  • the transmit timer 314 may be set to a first initial value (e.g., provided via line 318) that may indicate or may be related to a portion of time that the channel may be usable (or may be scheduled) for transmission.
  • the transmit timer 314 may be set to the first initial value, where the first initial may indicate a maximum number of time periods (e.g., maximum number of slots or other time periods) that the channel may be scheduled for transmission.
  • the idle timer 316 may be set to the second initial value, where the second initial value may indicate a (e.g., minimum) number of time periods (e.g., minimum or required number of slots or other time periods) that the channel should remain idle (e.g., no transmission scheduled on the channel (e.g., for the beam pair)).
  • the transmit timer 314 is decremented by 1 if there is data for transmission on the channel and the transmit timer 314 is not expired.
  • expiration of a timer may occur when the timer reaches zero (or less), or reaches other predetermined value.
  • the transmit timer 314 may be related to a period (or remaining period, as the transmit timer 314 may decrement over time) of time that the channel may be usable for transmission.
  • the idle timer 316 may be set to the second initial value (e.g., provided via line 320) that may indicate or may be related to a portion of time (e.g., a number of time periods) that the channel should be (or should remain) idle (not be scheduled for transmission).
  • a portion of time e.g., a number of time periods
  • the idle timer 316 is decremented if the channel will not be scheduled for transmission that time period.
  • the idle timer 316 is decremented if there is no data to be transmitted that time period (e.g., if there is no data transmitted at that time period or if the gNB decides not to schedule a data transmission during that time period for that channel (e.g., for that beam pair), and for example the gNB may instead prioritize a gNB transmission on another beam or beam pair), and/or if the transmit timer 316 is expired (e.g., in an example embodiment, if either, or both, of these conditions is true, then the channel is not scheduled for transmission that time period, and idle timer 316 is decremented by 1).
  • the idle timer 316 may be related to a period (or remaining period, as the idle timer 316 may decrement over time) of time that the channel should remain idle.
  • Timer expiration detector 322 may detect, via lines 315 and 317, a state of (e.g., a value included within) of transmit timer 314 and idle timer 316, respectively. Timer expiration detector 322 may also detect when each of the transmit timer 314 and/or the idle timer 316 expires (e.g., reaches a predetermined value, such as a value of zero). Timer expiration detector 322 may indicate, via line 324, an expired status (expired, or not expired) for transmit timer 314 or for both transmit timer 314 and idle timer 316, to channel scheduler 330.
  • a state of e.g., a value included within
  • Timer expiration detector 322 may also detect when each of the transmit timer 314 and/or the idle timer 316 expires (e.g., reaches a predetermined value, such as a value of zero). Timer expiration detector 322 may indicate, via line 324, an expired status (expired,
  • Detector block 326 may detect or determine if there is uplink (UL) or downlink (DL) data to be transmitted over the channel (e.g., by checking status of memory buffers at the gNB or BS or UE, and/or receiving a buffer status report from the UE or receiving an uplink scheduling request from the UE).
  • UL uplink
  • DL downlink
  • channel scheduler 330 may schedule, or may output a control signal via line 332 to cause the scheduling, of an UL and/or DL transmission via the channel, e.g., if there is data for transmission over the channel and the transmit timer 314 has not expired (e.g., transmit timer is greater than zero).
  • the BS/gNB may send a scheduling grant to the UE, to schedule (or identify to the UE) the resources for the UL or DL transmission for the UE that has been scheduled.
  • the transmit timer 314 is decremented by 1. Otherwise, according to an example embodiment, if either there is no data for transmission over the channel and/or the transmit timer 314 is expired (e.g., less than or equal to zero), then the channel is not scheduled for that time period (e.g., for slot i), so that the channel will remain idle for that time period, and the idle timer 316 is decremented by 1, according to an illustrative example embodiment.
  • a new (or updated) congestion metric may be determined or calculated, and then updated first and second initial values may be determined based on the updated congestion metric to reset the transmit timer 314 and the idle timer 316, respectively.
  • updated first initial value and an updated second initial value may be determined (e.g., based on an updated congestion metric) to be used to reset (or re-initialize) the transmit timer 314 and the idle timer 316, respectively.
  • update block 312 may then reset or reinitialize the timer initial values of transmit timer 314 and idle timer 316 via lines 318 and 320, respectively.
  • the process or procedure may repeat (e.g., returning to block 310 to determine an updated congestion metric, and then resetting or reinitializing the timers 314, 316 based on the updated congestion metric), allowing the channel to again be scheduled for transmission for a number of time periods (e.g., for a number of slots) based on the reset or reinitialized value of the transmit timer 314.
  • the transmission duty cycle for a channel may be adjusted, e.g., by flexibly setting or determining initial values for the transmit timer 314 and the idle timer 316 for the channel based on a congestion metric for the channel.
  • the congestion metric (e.g., determined or calculated by congestion metric determination block 310) may be channel- specific (e.g., determined separately for each channel, and/or based on one or more congestion-related parameters that are specific to the channel), and as a result, the initial values for the transmit timer 314 and idle timer 316 may also be channel-specific.
  • a channel may include a set of time-frequency resources (e.g., a set of symbols and/or a set of subcarriers or frequencies) that may be used by a UE and/or BS/gNB for transmission.
  • a channel may be (or may include) an uplink (UL) channel for uplink communications, and/or may include a downlink (DL) channel for downlink communications.
  • a channel may include, or may be, or may be associated with, a beam pair (which may be referred to as a beam pair link).
  • a beam pair (or beam pair link) may include a UE beam that points toward a gNB/BS (e.g., a UE beam that may be used by the UE for transmitting and/or receiving from the gNB), and a gNB/BS beam that points toward the UE (e.g., a gNB/BS beam that may be used by the gNB/BS for transmitting and/or receiving from the UE).
  • a congestion metric, and/or initial values determined for a transmit timer 314 and/or for idle timer 316 may be beam pair-specific (e.g., a separate or different congestion metric, and/or a separate or different first initial value and a second initial value for the transmit timer 314 and the idle timer 316, respectively, may be determined or provided for each of multiple beam pairs or beam pair links).
  • FIG. 4 is a diagram illustrating example beam pair links according to an example embodiment.
  • gNB/BS 134 may be in communication with UE 132.
  • gNB/BS 134 may use a gNB DL transmit beam 414 to transmit a signal to UE 132, and may use gNB UL receive beam 416 to receive a signal from UE 132.
  • UE 132 may use a UE DL receive beam 410 to receive a signal from the gNB/BS 134, and may use a UE UL transmit beam 412 to transmit a signal to the gNB/BS 134.
  • a first beam pair in the downlink (DL) direction, may include gNB DL transmit beam 414 and UE DL RX beam 410.
  • a second beam pair in the uplink direction, may include a gNB UL receive beam 416 and a UE UL transmit beam 412.
  • a congestion metric, a first initial value (for resetting or initializing the transmit timer 314), and a second initial value (for resetting or initializing the idle timer 316) may (for example) be determined specifically for (or separately for) each of the first beam pair, and for the second beam pair.
  • separate transmit timers and idle timers may be provided and decremented (and/or reset) separately for each channel, e.g., such as for each beam pair (or for each beam pair link) of a plurality of beam pairs.
  • an adjusted (or updated) transmission duty cycle may be obtained or determined, e.g., based on network or channel congestion (e.g., based on a congestion metric), rather than using a fixed or static transmission duty cycle.
  • example embodiments may include or may provide a detect-and-avoid (DAA) mechanism that may rely on avoiding collisions (or at least reducing the risk of collision on the channel) by dynamically adjusting the duty cycle (or transmission duty cycle) or rate/periodicity of transmissions on a channel based on the channel congestion metric (e.g., based on observed collisions or collision rate, error rate, or other congestion-related parameters), rather than relying on a strict listen before talk (LBT) mechanism or a fixed or statically set transmission duty cycle.
  • LBT and a static transmission duty cycle may, at least in some cases, provide inefficient techniques for channel access.
  • a static or fixed transmission duty cycle for a channel or spectrum may be inflexible, and thus, may typically be unable to adapt or adjust based on channel congestion or channel conditions that are typically of dynamic nature.
  • LBT at least in some cases, may miss a transmission by an interfering node (e.g., such that may occur for a hidden node problem), and may also result in inefficient use of processor and memory resources in the event the node is unable to transmit due to an occupied channel after preparing a data block for transmission.
  • LBT at least in some cases, may result also in inefficient use of a channel when LBT is performed each time when a transmission beam is switched.
  • a more efficient transmission duty cycle may be realized in a flexible manner, e.g., based on setting of initial values for a transmit timer 314 and an idle timer 316 (e.g., based on a congestion metric or channel conditions), and decrementing such timers under certain conditions, and then updating the congestion metric based on (or in response to) timer expiration of one or both timers.
  • a congestion metric may be determined, e.g., based on one or more congestion-related parameters.
  • Various techniques may be used, and various measurements and/or parameters may be considered, to determine a congestion metric.
  • LBT energy detection / measurement
  • a metric for detecting channel congestion and/or channel access collisions (which may be referred to as a congestion metric) may be determined based on a variety of parameters or criteria.
  • a congestion metric may be based on one or more techniques or parameters, such as, for example:
  • a LBT Energy detection/measurement may be performed (up-to) x ms prior to each transmission (or gNB acquired COT/channel occupancy time), where in x may be larger or even considerably larger than the duration of CCA (clear channel access/LBT) slot.
  • the duration of a CCA slot may be e.g. 5ps or 9ps.
  • the LBT may be performed more than a CCA slot before transmission, and thus, is not a standard LBT technique, since LBT is not necessarily required just before transmission.
  • a congestion metric may be based on a success and/or failure for one or more past transmissions, which may be measured or detected based on a block error rate (BLER) or bit error rate (BER) for one or more transport blocks (TBs) or code block groups (CBGs) that were transmitted.
  • BLER block error rate
  • BER bit error rate
  • TBs transport blocks
  • CBGs code block groups
  • the determination of the congestion metric may include, or may be based on, radio channel energy measurements by the gNB/BS and/or the UE.
  • LBT is measuring at transmitter side.
  • the radio energy measurements may be performed by the receiver or receiving node, and/or the transmitter/transmitting node.
  • the UE may perform radio energy measurements during DL portion of gNB/BS acquired COT, e.g., using ZP-CSI-RS (zero power channel state information-reference signal) resources. Measurements and the related reporting of the measurements can be periodic or aperiodic.
  • Receiving UE can measure radio channel energy (e.g., detect changes in energy during COT/channel occupancy time period).
  • the gNB/BS may, for example, perform measurements during measurements gaps, or unused resource elements of UL portion of gNB acquired channel occupancy. Also, in the UL direction, the gNB/BS may sense or measure energy during UL reception, when a UE(s) in the cell is/are not transmitting, e.g., to detect new interference during COT, from another cell or another network or UEs of other cells
  • a congestion metric may be determined, by a transmitter (or transmitting node), and/or by a receiver (or receiving node), and/or based on statistics, e.g., success/failure of transmissions, which may be indicated by a BLER or other statistics, or other parameters.
  • a congestion metric may be determined by observing data transmission or the radio channel over a certain time / frequency window, e.g., such as: [0057] n most recent slots (where n is e.g., 5, 10, etc.), or
  • n slots (where n is e.g., 5) at the start of the most recent transmission burst
  • n most recent channel occupancies e.g. one or a few channel occupancies
  • the congestion metric may consider, gNB/BS metric only, or both gNB & UE congestion metrics (or may be based on congestion related parameters from one or both of gNB/BS and/or UE).
  • a congestion metric may be determined based on parameters or measurements from either or both of UE and gNB/BS.
  • the gNB/BS may be responsible for scheduling and determined congestion metric, and UE may just report one or more congestion parameters to gNB/BS (to be used in the gNB/BS ’s congestion metric calculation, for example).
  • the congestion metric may be determined separately for each beam pair link.
  • determining the congestion metric may include measuring a congestion level (or congestion parameter), and then quantizing the measured congestion level to a discrete or quantized congestion level, of a plurality of quantized congestion levels.
  • a congestion metric may include (or may be based on) a quantized congestion level (or quantized congestion parameter(s)), of a plurality of possible quantized congestion levels, e.g., in order to simplify processing of congestion related parameters to determine a congestion metric.
  • the congestion metric may be determined by selecting the most appropriate quantized or discrete congestion metric, of a plurality of possible quantized congestion metrics.
  • quantized congestion metrics may include, e.g., the following quantized congestion levels: 1) full congestion; 2) one (or more) intermediate congestion levels for an intermediate congestion between full congestion and no congestion; and 3) no congestion.
  • multiple different measured congestion metrics may be obtained or measured, e.g., such as a LBT or channel energy measurement as a first congestion metric, and a BLER measurement as a second congestion metric; and/or a first congestion metric measured by a UE and a second congestion metric measured by gNB, etc.
  • There may be different techniques or approaches that may be used to determine one congestion metric e.g., to be used to adjust initial values for the timers), based on multiple measured congestion metrics.
  • Two example techniques may include: 1) According to an example embodiment, in the case where there may be multiple different congestion metrics, an average of the measured congestion metrics may be used as a congestion metric, e.g., by first mapping each congestion metric to a numerical value, and then taking an average of those. As an illustrative example, each measured congestion metric may be quantized to a numerical or quantized congestion level (e.g. by mapping full congestion to value 1, an intermediate congestion to value 0.5, and no congestion to value 0, and then take the average of these congestion values (congestion metrics). 2) Alternatively, a congestion metric may be determined based on a most congested or most pessimistic congestion metric of the plurality of congestion metrics. For example, if gNB/BS determines a congestion metric of full congestion, and the UE measures a congestion metric of (or measures a congestion parameter that indicates) an intermediate congestion level, then the full congestion level would be selected as the congestion metric.
  • the congestion metric e.g., indicating full congestion, one or more intermediate congestion levels, or no congestion may be used by the block 312 (FIG. 3) to adjust a transmission duty cycle for a channel or for a UE, e.g., by updating timer initial values for a transmit timer 314 and/or an idle timer 316.
  • a congestion metric that indicates a lower congestion level may result in a higher first initial value for the transmit timer (e.g., to provide more time periods when the UE or network node may be able to transmit) and/or a lower second initial value for the idle timer (e.g., to provide a shorter wait period until transmissions may resume), e.g., to cause a higher (or greater) transmit duty cycle, e.g., to allow more of the channel resources to be used (since the channel seems to be uncongested).
  • a congestion metric that indicates a higher (even full congestion, or fully congested) congestion level may result in a lower first initial value for the transmit timer (e.g., so as to reduce the number of time periods when the UE or network node may transmit) and/or a lower second initial value for the idle timer, e.g., to cause a lower transmit duty cycle, in order to reduce transmissions and avoid further collisions (e.g., since the channel is already congested).
  • a duty cycle (or transmission duty cycle) may be determined flexibly by two timers: a transmit (Tx) timer 314 (FIG. 3) and an idle timer 316 (FIG. 3).
  • the transmit timer 314 may be set/reset to an initial value corresponding to a predefined/configured COT (channel occupancy time) duration.
  • the COT duration corresponds to the maximum channel occupancy time or the duration of the most recent COT or it may be just a predefined value.
  • the transmit timer values may be defined, e.g., in terms of slots or symbols.
  • the idle timer 316 may be set/reset to a predefined/configured value, or may be determined based on a predefined/configured Idle Ratio.
  • a predefined value/ configured for idle timer may be defined, e.g., in terms of slots or symbol.
  • An example of the predefined/configured Idle Ratio may be, e.g., 0.25 or 25%.
  • the UE or other node may calculate the value for Idle timer as:
  • Idle Timer COT_duration*Idle_ratio) / (1 -Idle ratio)
  • Tx Timer Reset value 2 ms (16 slots)
  • Idle timer reset value may be 6 slots, in this example.
  • values for timers may be determined based on a congestion metric.
  • gNB/UE may determine if it will transmit during a COT or not, based on if the node has data for transmission, or based on a scheduling decision. For example, each time period (e.g., each slot, or group of symbols, or group of slots), a data transmission (e.g., UL and/or DL transmission) may be scheduled for the channel if the transmit timer has not expired and if there is data for transmission on the channel. Also, in an example embodiment, the idle timer 316 may be decremented by 1 (or count down) for a time period if there is no data scheduled for transmission for that time period.
  • the transmit timer 314 may be decremented or counted down for that time period. For example, a transmission may be scheduled for the channel for a time period (e.g., for a slot) if there is data for transmission, and the transmit timer 314 has not expired (e.g., has not reached a value of 0, or other predetermined value).
  • the idle timer 316 is decremented for a time period in which a data transmission is not scheduled (e.g., idle timer is decremented for each time period when the channel is not used for transmission by the gNB or UE of the beam pair, or no data transmission scheduled for the gNB or UE of the beam pair).
  • the transmit timer 314 may begin counting down when transmission begins, or when transmission is scheduled for transmission.
  • the transmit timer 314 and idle timer 316 may be set to initial values. Then, each time period (e.g., each slot), it is determined whether there is data for transmission, and whether the transmit timer 314 has expired.
  • the channel may be scheduled for transmission if, for example, the transmit timer 314 has not expired (e.g., has not reached a value of zero) and there is data for transmission on the channel.
  • the transmit timer 314 may be decremented for a (or each) time period (e.g., each slot) when the channel is scheduled for transmission. Otherwise, if the channel is not scheduled for transmission for a time period, then the idle timer 316 is decremented.
  • the gNB/BS may maintain and/or control resetting and/or updating or decrementing of the transmit timer 314 and/or idle timer 316.
  • the gNB/BS may determine for the time period (e.g., slot) if a transmission will be scheduled or not. Also, for example, when the transmit timer 314 expires (reaches zero), transmissions for the channel are suspended (temporarily stopped or ceased) until the idle timer 316 also expires. In an example embodiment, when the idle timer 314 expires, both transmit timer 314 and idle timer 316 may be reset back to an (e.g., updated) initial values, and transmission (or transmit scheduling for the channel) may resume based on the value of the transmit timer (e.g., if the transmit timer has not expired and there is data for transmission).
  • the transmit timer 314 may be reset back to an (e.g., updated) initial values, and transmission (or transmit scheduling for the channel) may resume based on the value of the transmit timer (e.g., if the transmit timer has not expired and there is data for transmission).
  • congestion metric determination block 310 may determine an updated congestion metric (e.g., based on one or more updated congestion-related parameters).
  • the updated initial values for the transmit timer 314 and/or the idle timer may be based on the updated congestion metric.
  • timers e.g., transmit timer 314 and/or idle timer 316
  • predefined transmit/idle periods or a fixed or static transmission duty cycle
  • use of timers may allow for, e.g.: improved flexibility to adapt transmissions based on traffic or congestion or scheduler needs; a more flexible switching between beams even during or within a transmission period (e.g., to transmit/receive periodic signals on another beam); avoiding coexistence problems of regular patterns; to allow the gNB/BS to flexibly reserve some transmit time, e.g., for DRS occurring later on during the time span of transmit timer + Idle timer.
  • the idle Timer or Idle Ratio when a collision is detected based on a congestion metric, e.g. by BLER that is above a first threshold, the idle Timer or Idle Ratio can be increased. When collisions are not detected (e.g., BLER is below a second threshold), Idle Ratio can be reduced (perhaps at slower rate).
  • the (value of) idle timer may be constrained to a value range corresponding to 95%...10% of (COT duration + Idle Timer). The corresponding range for the Idle Ratio is ⁇ 0.05...9. An additional random time offset value may be introduced before next transmission (especially when no LBT is followed).
  • Idle Ratio(s) may be reduced further to an example Min Idle Ratio (e.g., 0.05). Some Idle Ratio may be necessary to ensure that coexisting systems possibly using LBT have channel access opportunities.
  • a transmission duty cycle of the upcoming transmissions may be adjusted in a predetermined manner according to the congestion metric: e.g., the higher the congestion metric (e.g., for a higher BLER), the lower the transmission duty cycle; the duty cycle may not be strictly periodic, but pseudo random over a period in time, e.g., such that for a transmission duty cycle (e.g., a maximum duty cycle) of X%, the transmissions will occur pseudo randomly within a time window, without exceeding X% of the duration of the time window.
  • the scheduling of transmission for the channel may be performed such that the transmission duty cycle, over a period of time, will be less than or equal to a maximum transmission duty cycle.
  • FIG. 5 is a flow chart illustrating operation of a node according to an example embodiment.
  • a node may determine a congestion metric for a channel, e.g., such as for a beam pair link A.
  • congestion metric determination block 310 may determine a congestion metric, e.g., based on one or more congestion-related parameters.
  • initial values e.g., a first initial value for the transmit timer 314 and a second initial value for the idle timer 316
  • initial values are determined based on the congestion metric (and possibly other parameters, such as a COT (channel occupancy time) or maximum COT).
  • block 312 (FIG. 3) may determine timer initial values for the transmit timer 314 and idle timer 316. The higher the initial values for the timers, the higher is the maximum duration of the COT.
  • the timers are set to the initial values. For example, transmit timer 314 is set to the first initial value, and the idle timer 316 is set to the second initial value.
  • a decision may be made to schedule a transmission on (or occupy) the channel for a time period (e.g., for a slot), e.g., if the transmit timer 314 has not expired and there is data for transmission (e.g., either for UF and/or DL transmission). If a decision is made to schedule a transmission on the channel, the flow proceeds to blocks 508, 509, 511 and 513. If the decision is made not to schedule a transmission on the channel (a determination not to occupy the channel) for the time period, then the flow proceeds to blocks 515, 518, and 513.
  • the UL and/or DL transmission is scheduled for the channel (e.g., for the beam pair) (e.g., where scheduling the transmission on the channel may include transmitting a scheduling grant from the BS/gNB to the UE for the UL and/or DL transmission).
  • the transmit timer 314 is decremented.
  • flow proceeds to block 517, where it is determined whether the idle timer 316 has expired. If, at 517, the idle timer 316 has not expired, then flow proceeds to block 513, when the time period index is incremented by 1. If, at 517, the idle timer 316 has expired, then flow proceeds back to block 501 where an updated congestion metric is determined.
  • blocks 511 and 517 provide an implementation where expiration of both transmit timer and idle timer causes the flow to return to blocks 501, 503, and 505, e.g., where an updated congestion metric is determined (block 501), new or updated initial values are determined for the timers (at block 503), and then the transmit timer and idle timer are reset or reinitialized based on these new initial timer values.
  • Other blocks, features, arrangements or example embodiments may allow flow to return to block 501 (and then blocks 503 and 505) in response to expiration of just one of the two timers (e.g., see block 518, where flow returns to block 501 if the idle timer has expired at block 518).
  • the flow proceeds to block 515.
  • the idle timer 316 is decremented, and flow may proceed (in an example embodiment) to block 518.
  • idle timer if idle timer has expired (at block 518), then flow will proceed again back to block 501, where a new or updated congestion metric may be determined, and then new initial timer values may be determined at 503, and then used to reset or reinitialize the timers at block 505.
  • this e.g., block 518, may provide an illustrative example of resetting or reinitializing the transmit timer and idle timer upon expiration of the idle timer (e.g., as detected at block 518), but does not necessarily require expiration of both timers to cause a reset or reinitializing of the timers.
  • block 517 (as well as lines output from block 517) may be omitted, and a Yes line/arrow may be provided from block 511 directly to block 518.
  • flow may proceed to block 518 to determine if the idle timer is also expired. For example, in this arrangement, if both the transmit timer (checked at block 511) and idle timer (checked at block 518) are expired, then flow would proceed back to block 501 where an updated congestion metric may be determined.
  • this may provide an example where the transmit timer and the idle timer values are reset or reinitialized in response (or based upon) both the transmit timer and the idle timer expiring.
  • both timer values may be checked, to determine if both the transmit timer and idle timer have expired, and then, if both timers have expired as detected at block 518, flow would then return to block 501 (to allow updated congestion metrics and initial timer values to be determined).
  • This may provide an alternative arrangement where, after making a decision not to transmit on the channel for the i th time period (block flow via blocks 507, 515 and then to block 518), a return to block 501 would occur if both timers are expired.
  • An additional random time offset value may be introduced before next transmission (especially when no LBT is followed). This could be added e.g. after block 503.
  • a time period may, e.g., be a slot of 14 symbols or a half-slot of 7 symbols, or even a symbol.
  • a time period may also be multiple slots such as 4 or 8 slots. If there is a transmission during the time period, the channel is considered to be occupied.
  • the gNB scheduler may select to occupy the channel for time instant i based on scheduling needs, if transmit timer is greater than zero (not expired).
  • the block 507 may occur in blocks of time periods so that the channel usage determination is aligned with the normal scheduling units (e.g., slots) of gNB/BS. There could be additional rules to distribute “idle slots” in a predetermined way. E.g., each 10 consecutive time periods should have at least 2 “idle slots.” (or idle time periods). Block 518 may or may not be present. If present, the device with empty buffer (no data for transmission) periodically updates congestion metric and such follows the situation in the channel.
  • the gNB/BS may determine the state over 10 slots. During the 10 slots:
  • a gNB measured the channel energy to be below the “no congestion” threshold. Hence the channel measurement metric is quantized to “no congestion”.
  • UE measured the channel energy to be above the “full congestion” threshold. Hence the UE reported the channel measurement metric as “full congestion”.
  • the congestion state is determined based on the most pessimistic metric, the congestion state is set to “full congestion”.
  • One or more example embodiments may operate in a beam-specific manner. However, the beams are largely overlapping which questions whether they may operate fully independently. Thus, in some example embodiments, the transmit timer / idle timer values (to which the counters are reset) of the spatially overlapping beams are also considered when determining the transmit timer / idle timer values for the current beam. For example, the average (or weighted average) over the current beam’s transmit timer / idle timer values (based on the determined congestion metrics) and the transmit timer / idle timer values of the spatially overlapping beams could be used in block 503.
  • FIG. 6 is a flow chart illustrating operation of a node (e.g., network node, such as a gNB, BS, relay node, or other wireless node) according to an example embodiment.
  • a network node e.g., gNB, BS
  • the operations of FIG. 6 may be performed by a network node (e.g., gNB, BS, relay node, ... ).
  • FIG. 6 includes the operations at 610, 620 and 630. The various blocks, operations and/or functions illustrated in the examples of FIGs.
  • FIG. 6 (and subsequent examples) are not limited to such example embodiments described with reference to FIGs. 3 and 5.
  • Operation 610 includes determining a first initial value for a transmit timer and a second initial value for an idle timer.
  • a transmit timer 314 and an idle timer 316 may be provided.
  • An update block 312 (FIG. 3) may be provided to update initial values for the timers, e.g., to update or determine a first initial value for the transmit timer 314 and a second initial value for the idle timer 316 (to reset or reinitialize these timers). See FIG. 3.
  • a node may determine a congestion metric for a channel, e.g., such as for a beam pair link A (see FIG. 5).
  • a congestion metric for a channel, e.g., such as for a beam pair link A (see FIG. 5).
  • congestion metric determination block 310 may determine a congestion metric, e.g., based on one or more congestion-related parameters.
  • initial values e.g., a first initial value for the transmit timer 314 and a second initial value for the idle timer 316
  • the congestion metric are determined based on the congestion metric (and/or possibly based on other parameters, such as, e.g., a COT (channel occupancy time) or maximum COT).
  • block 312 (FIG. 3) may determine timer initial values for the transmit timer 314 and idle timer 316. The higher the initial values for the timers, the higher is the maximum duration of the COT.
  • Operation 620 includes setting the transmit timer to the first initial value and the idle timer to the second initial value.
  • the timers are set to the initial values.
  • transmit timer 314 (FIG. 3) is set to the first initial value
  • the idle timer 316 (FIG. 3) is set to the second initial value.
  • update block 312 may set or reset (initialize or reinitialize) the initial values of the timers, e.g., by update block 312 setting the transmit timer 314 to a first initial value via line 318 and setting the idle timer 316 to a second initial value via line 320 (FIG. 3).
  • operation 630 includes performing the following until at least one of the transmit timer (e.g., transmit timer 314, FIG. 3) or the idle timer (e.g., idle timer 316, FIG. 3) expires: scheduling a channel of a wireless network for data transmission (e.g., schedule transmission/occupy channel block 508 may determine to occupy the channel, FIG. 5; see also channel scheduler 330, FIG. 3, e.g., which receives timer(s) expired indication input via line 324 from timer expiration detector 322, and may receive an indication of data to be scheduled for transmission via the channel via line 328) and decrementing the transmit timer (e.g., decrement transmit timer 314, FIG.
  • the transmit timer e.g., transmit timer 314, FIG. 3
  • the idle timer e.g., idle timer 316, FIG. 3
  • operations may continue until one or both of the timers have expired (e.g., a value of the timer is zero, or less than or equal to zero).
  • blocks 511 and 517 may allow flow to return to block 501, e.g., if both the transmit timer 314 and the idle timer 316 have expired.
  • Block 518 allows flow to return to block 501 if the idle timer has expired.
  • Different example embodiments may require or allow different combinations of expiration of the two timers (e. g.
  • j ust transmit timer 314 expired, j ust idle timer 316 expired, or both the transmit timer 314 and idle timer 316 are expired to cause or trigger the flow to return to block 501 and/or to blocks 503 and 505 (to reset reinitialize the values of the timers).
  • a decision may be made to schedule a transmission on (or occupy) the channel for a time period (e.g., for a slot), e.g., if the transmit timer 314 has not expired and there is data for transmission (e.g., either for UL and/or DL transmission).
  • timer expiration detector 322 (FIG. 3) may detect when the transmit timer and/or idle timer have expired.
  • a decision is made (e.g., at block 507, FIG. 5) to schedule a transmission on the channel for the current time period
  • the flow may proceed to blocks 508, 509, 511 and 513. If a decision is made not to schedule a transmission on the channel for the current time period (a determination not to occupy the channel), then the flow proceeds to blocks 515, 518, and 513, according to an example embodiment.
  • the UL and/or DL transmission is scheduled for the channel (e.g., for the beam pair) (e.g., where scheduling the transmission on the channel may include transmitting a scheduling grant from the BS/gNB to the UE for the UL and/or DL transmission).
  • the transmit timer 314 is decremented.
  • blocks 511 and 517 provide an implementation where expiration of both transmit timer 314 and idle timer 316 may cause the flow to return to blocks 501, 503, and 505, e.g., where an updated congestion metric is determined (block 501), new or updated initial values are determined for the timers (at block 503), and then the transmit timer and idle timer are reset or reinitialized based on these new initial timer values.
  • Example 2 The method of example 1, wherein the scheduling the channel for data transmission and decrementing the transmit timer, or decrementing the idle timer is performed per time period.
  • the decrementing the transmit timer 314 at 509 and/or decrementing the idle timer 316 at 515 is performed for each time period (e.g., for the i th time period.
  • a time period may be, e.g., a half slot (e.g., symbols) a slot, a plurality of slots, or one or more symbols.
  • a slot may include a plurality of symbols (e.g., 14 symbols, or other number of symbols).
  • Example 3 The method of example 2, wherein each time period comprises at least one symbol or at least one slot, wherein a slot comprises a plurality of symbols.
  • each time period may include one or more symbols, a half slot (e.g., 7 symbols), a slot (e.g., 14 symbols or other number of symbols), or multiple slots.
  • Example 4 The method of any of examples 1-3, wherein the transmit timer is related to a portion of time that a radio channel is usable for transmission, and the idle timer is related to a portion of time that the radio channel is idle or should remain idle.
  • the transmit timer may314 be set to a first initial value, and the idle timer 316 may be set to a second initial value.
  • the value of the transmit timer may be related to a portion of time that the radio channel is usable for transmission because, in the illustrative example, the channel may be scheduled for transmission or occupied (at blocks 507, 508, FIG. 5) only if the transmit timer has not expired.
  • the initial value of the transmit timer 314 indicates a maximum number of time periods that the channel may be scheduled for transmission or occupied, before requiring some idle period.
  • the transmit timer is decremented (e.g., at 509, FIG. 5)
  • the remaining or current value of the transmit timer 314 may indicate a remaining number of time periods for which the channel may be scheduled for transmission or occupied, before requiring a minimum idle period.
  • the transmit timer 314 may be decremented at 509.
  • the channel may be scheduled for transmission or occupied (e.g., for this beam pair), e.g., only if the transmit timer 314 has not yet expired (e.g., not yet reached zero).
  • a goal may be to use the channel or spectrum, but decrease the amount of collisions.
  • the idle timer 316 is related to a portion of time that the radio channel is idle or should remain idle, e.g., because the idle timer 316 is reset (or initialized) to a second initial value that indicates a minimum number of time periods that the channel should not be scheduled (e.g., for this beam pair) or should remain unoccupied for this beam pair or UE/gNB pair.
  • the idle timer 316 may be decremented at 515 when a decision is made (at 507) not to schedule a transmission (e.g., for this beam pair, or for this UE/gNB pair) or occupy the channel for that time period.
  • the initial values used to set or initialize the transmit timer 314 and idle timer 316 may establish or provide a transmission duty cycle, e.g., for the beam pair or for the UE/gNB communications (although the channel or spectrum may be occupied by other beam pairs or other UEs or other gNBs).
  • setting the transmit timer 314 and idle timer 316 to initial values may set or establish an appropriate transmission duty cycle for this beam pair or for the communications between this UE and gNB, e.g., based on the amount of congestion that may have been detected.
  • the transmit timer may be set to a larger initial value and/or the idle timer may be set to a smaller initial value, to increase the transmission duty cycle (e.g., and thus, increase usage of a channel or spectrum that is currently not fully used, as indicated by a low amount of congestion).
  • the transmit timer may be set to a smaller initial value and/or the idle timer may be set to a larger initial value, to decrease the transmission duty cycle (and thus decrease the likelihood of collisions).
  • Example 5 The method of any of examples 1-4, wherein the determining of at least one of the first initial value and the second initial value comprises: determining a congestion metric for the channel; and determining at least one of the first initial value and the second initial value based at least in part on the congestion metric.
  • congestion metric determination block 310 (FIG. 3) may determine a congestion metric, e.g., based on one or more congestion-related parameters 308.
  • Update block 312 may determine a first initial value for the transmit timer 314 and a second initial value for the idle timer 316, e.g., based on the congestion metric received via line 311. See the example related to FIG. 3.
  • Example 6 The method of any of examples 1-5, comprising: resetting values for at least one of the transmit timer and the idle timer if the idle timer has expired. As shown in the illustrative example embodiments of FIGs. 3 and/or 5, some operations may continue until one or both of the timers have expired (e.g., a value of the timer is zero, or less than or equal to zero may be an example of timer expiration).
  • timer expiration detector 322 may detect expiration of one or both of transmit timer 314 and idle timer 316, and may provide an indication of expiration (or not) of each timer via line 324 to channel scheduler 330, for example. For example, with reference to FIG.
  • blocks 511 and 517 may determine if the transmit timer has expired (511) and the idle timer has expired (517). In this illustrative example, if both timers have expired, then flow or operation may return to block 501 and then to blocks 503 and 505 (to reset reinitialize the values of the timers 314, 316, e.g., based on an updated congestion metric). Similarly, block 518 may determine whether the idle timer 316 (FIG. 3) has expired. If the idle timer 316 has expired, then flow or operation may similarly return to block 501 and then to blocks 503 and 505 (to reset or reinitialize the values of the timers 314, 316, e.g., based on an updated congestion metric).
  • Example 7 The method of any of examples 5-6, comprising: performing the following if the idle timer has expired: determining an updated congestion metric for the channel; determining, based at least in part on the updated congestion metric, at least one of an updated first initial value for the transmit timer, and an updated second initial value for the idle timer; and resetting a value of the transmit timer to the updated first initial value, and/or resetting a value of the idle timer to the updated second initial value.
  • timer expiration detector 322 may detect expiration of one or both of transmit timer 314 and idle timer 316, and may provide an indication of expiration (or not) of each timer via line 324 to channel scheduler 330, for example.
  • blocks 511 and 517 may determine if the transmit timer has expired (511) and the idle timer has expired (517). In this illustrative example, if both timers have expired, then flow or operation may return to block 501 (e.g., where an updated congestion metric may be determined) and then to blocks 503 and 505 (to determine updated initial values (at 503) for the timers based on updated congestion metric, and then reset or reinitialize (at 505) the values of the timers 314, 316, e.g., based on the updated congestion metric). Similarly, block 518 may determine whether the idle timer 316 (FIG. 3) has expired.
  • block 501 e.g., where an updated congestion metric may be determined
  • blocks 503 and 505 to determine updated initial values (at 503) for the timers based on updated congestion metric, and then reset or reinitialize (at 505) the values of the timers 314, 316, e.g., based on the updated congestion
  • flow or operation may similarly return to block 501 and then to blocks 503 and 505 (to reset reinitialize the values ofthe timers 314, 316, e.g., based on an updated congestion metric).
  • Different example embodiments are described and/or may be used, that may require or allow different combinations of expiration of one or both of the two timers (e.g., just transmit timer 314 expired, just idle timer 316 expired, or both the transmit timer 314 and idle timer 316 are expired, for either or both of the transmit branch (blocks 508, 509, 511) and/or the idle channel branch of FIG. 5 (e.g., blocks 515, 518) to cause or trigger the flow to return to block 501 and/or to blocks 503 and 505 (to reset reinitialize the values of the timers).
  • Example 8 The method of any of examples 1-7, further comprising: resetting values for the transmit timer and the idle timer if both the transmit timer and the idle timer have expired.
  • timer expiration detector 322 (FIG. 3) may detect expiration of one or both of transmit timer 314 and idle timer 316, and may output timer expiration indicator(s) via line324 to channel scheduler.
  • expiration of both the transmit timer 314 and idle timer 316 may cause or trigger flow or operation to return to block 501 (e.g., where an updated congestion metric may be determined) and then to blocks 503 and 505 (to determine updated initial values (at 503) for the timers based on updated congestion metric, and then reset or reinitialize (at 505) the values ofthe timers 314, 316, e.g., based on the updated congestion metric).
  • block 501 e.g., where an updated congestion metric may be determined
  • blocks 503 and 505 to determine updated initial values (at 503) for the timers based on updated congestion metric, and then reset or reinitialize (at 505) the values ofthe timers 314, 316, e.g., based on the updated congestion metric.
  • blocks 511 and 517 may determine if the transmit timer 314 and idle timer 316 have expired, and if both timers have expired, flow would return to blocks 501, 503 and 505 to reset or reinitialize the timers.
  • blocks 515 and 518 although not shown in FIG.
  • block 518 (as modified to check both timers) may check to detect expiration of both transmit timer 314 and idle timer 316, and if both timers have expired, the operation or flow may return to block 501 (where an updated congestion metric may be determined) and then to blocks 503 and 505 (to determine updated initial values (at 503) for the timers based on updated congestion metric, and then reset or reinitialize (at 505)) the values of the timers 314, 316, e.g., based on the updated congestion metric).
  • Example 9 The method of any of examples 5-8, comprising: performing the following if both the transmit timer and the idle timer have expired: determining an updated congestion metric for the channel; determining, based at least in part on the updated congestion metric, at least one of an updated first initial value for the transmit timer, and an updated second initial value for the idle timer; and resetting a value of the transmit timer to the updated first initial value, and/or resetting a value of the idle timer to the updated second initial value.
  • expiration of both the transmit timer 314 and idle timer 316 may cause or trigger flow or operation to return to block 501 (e.g., where an updated congestion metric may be determined) and then to blocks 503 and 505 (e.g., to determine updated initial values (at 503) for the timers based on updated congestion metric, and then reset or reinitialize (at 505) the values of the timers 314, 316, e.g., based on the updated congestion metric).
  • block 501 e.g., where an updated congestion metric may be determined
  • blocks 503 and 505 e.g., to determine updated initial values (at 503) for the timers based on updated congestion metric, and then reset or reinitialize (at 505) the values of the timers 314, 316, e.g., based on the updated congestion metric.
  • blocks 511 and 517 may determine if the transmit timer 314 and idle timer 316 have expired, and if both timers have expired, flow may return to blocks 501, 503 and 505 to reset or reinitialize the timers.
  • blocks 515 and 518 although not shown in FIG.
  • block 518 (which may be modified to check both timers) may check to detect expiration of both transmit timer 314 and idle timer 316, and if both timers have expired, the operation or flow may return to block 501 (where an updated congestion metric may be determined), and then to blocks 503 and 505 (to determine updated initial values (at 503) for the timers based on updated congestion metric, and then reset or reinitialize (at 505)) the values of the timers 314, 316 (FIG. 3), e.g., based on the updated congestion metric).
  • block 501 (FIG.
  • a new or updated congestion metric may be determined, e.g., based on one or more (e.g., updated) congestion-related parameters.
  • the congestion-related parameters may be measured by the network node (e.g., gNB, BS), or may be measured by the UE and then reported to the network node.
  • An update block 312 may determine, at 503 (FIG. 5) updated initial values for the timers based on the updated congestion metric (e.g., an updated first initial value may be determined for the transmit timer 314, and an updated second initial value may be determined for the idle timer 316). Then, at 505 (FIG. 5) the timer values for the transmit timer 314 and the idle timer 316 may be reset or reinitialized to the updated initial timer values.
  • Example 10 The method of any of examples 1-9, wherein the scheduling the channel of the wireless network for data transmission when there is data to be transmitted via the channel comprises: scheduling the channel for at least one of uplink transmission or downlink transmission and transmitting a scheduling grant for at least one of uplink transmission or downlink transmission, if there is data for transmission and the transmit timer has not expired.
  • the network node may send the UE a scheduling grant to indicate time-frequency resources for the UL and/or DL grant (for the UL transmission and/or the DL transmission for the UE).
  • Example 11 The method of any of examples 5-10, wherein the congestion metric comprises a congestion metric determined based on at least one of the following: parameters, measured by a user equipment, associated with a congestion metric, and reported to the base station; a block error rate (or bit error rate) determined for one or more transport blocks; a radio energy measurement or a listen before talk measurement, performed more than a clear channel assessment slot before transmission; radio energy measurement or error rate measured over one or more symbols or one or more slots; a discrete or quantized congestion level based on a quantization of a measured congestion level; an average of a plurality of different congestion metrics; or a most congested or most pessimistic congestion metric of a plurality of different congestion metrics.
  • the congestion metric comprises a congestion metric determined based on at least one of the following: parameters, measured by a user equipment, associated with a congestion metric, and reported to the base station; a block error rate (or bit error rate) determined for one or more transport blocks; a radio energy measurement or
  • congestion-related parameters may be used to determine a congestion metric.
  • different and/or additional congestion-related parameters may be used to determine a congestion metric.
  • the network node e.g., BS or gNB
  • the UE may measure one or more congestion-related parameters for the channel, and may send such UE-measured congestion-related parameters to the network node, e.g., to be used to determine a congestion metric.
  • a LBT measurement (or energy measurement) may be performed well in advance (or more than a CCA or COT before such time period or channel occupancy) of a UL/DL transmission (or well in advance of a scheduling a channel for transmission), rather than performing such LBT just prior to transmission.
  • Example 12 The method of any of examples 1-11, wherein the channel comprises a beam pair link, including a beam for a base station and a beam for a user equipment, wherein the scheduled transmission is performed via the beam pair link.
  • the channel may include a set of resources (e.g., a frequency spectrum, such as a set of subcarriers, or generally a set of time, frequency and/or spatial resources) via which a transmission may be scheduled or performed.
  • selection of a beam pair may be considered as part of the scheduling.
  • a channel may include a beam pair.
  • gNB/BS 134 may be in communication with UE 132.
  • gNB/BS 134 may use a gNB DL transmit beam 414 to transmit a signal to UE 132, and may use gNB UL receive beam 416 to receive a signal from UE 132.
  • UE 132 may use a UE DL receive beam 410 to receive a signal from the gNB/BS 134, and may use a UE UL transmit beam 412 to transmit a signal to the gNB/BS 134.
  • a first beam pair (or first beam pair link) may include gNB DL transmit beam 414 and LIE DL RX beam 410.
  • a second beam pair (or a second beam pair link) may include a gNB UL receive beam 416 and a UE UL transmit beam 412.
  • a congestion metric, a first initial value (for resetting or initializing the transmit timer 314), and a second initial value (for resetting or initializing the idle timer 316) may (for example) be determined specifically for (or separately for) each of the first beam pair, and for the second beam pair.
  • separate transmit timers and idle timers may be provided and decremented (and/or reset) separately for each channel, e.g., such as for each beam pair (or for each beam pair link) of a plurality of beam pairs.
  • Example 13 The method of any of examples 5-12, comprising: determining, based on the congestion metric, a maximum transmission duty cycle for the channel, wherein a transmission duty cycle indicates a first portion of time for transmission via the channel as compared to a second portion of time for both transmission and idle for the channel; wherein the scheduling the channel for data transmission is performed such that the transmission duty cycle for the channel, over a period of time, is performed so as to maintain the transmission duty cycle for the channel to be less than or equal to the maximum transmission duty cycle for the channel.
  • a first initial value may be determined for the transmit timer (314, FIG. 3), and a second initial value may be determined for an idle timer 316 (FIG.
  • a transmission duty cycle may indicate a period or portion of time a channel is provided (or available) for transmission, as compared to a period of time the channel is provided for both idle and transmission.
  • Example 14 The method of any of examples 1-13, comprising: decrementing the idle timer (e.g., 316, FIG. 3) if the transmit timer (e.g., 314) has expired.
  • a timer expiration detector 322 (FIG. 3) may detect an expiration of the transmit timer 314 and/or the idle timer 316.
  • the node may determine whether to transmit on the channel or schedule a transmission on the channel (to occupy the channel) for a time period.
  • network node will not schedule a UL and/or DL data transmission, either because there is no data for transmission, or the gNB/network node may be scheduling transmission via a different beam pair
  • the transmit timer 314 (FIG. 3) has expired
  • the network node will not occupy or schedule the channel for transmission for the time period for this beam pair, and flow proceeds along the idle branch of FIG. 5 (e.g., including blocks 515 and 518).
  • the transmit timer 314 is detected as expired, then the channel will not be scheduled by the gNB for that beam pair for that time period, and at block 515, the idle timer will be decremented. This provides an illustrative example of decrementing the idle timer 316 if the transmit timer 314 is expired.
  • Example 15 The method of any of examples 1 -14, comprising performing the following for each time period of a plurality of time periods: determining that the transmit timer has expired; performing the following in response to determining that the transmit timer has expired: not scheduling the channel for transmission, so that the channel will be idle for a time period; and, decrementing the idle timer.
  • the network node will not schedule or occupy the channel for this beam pair for the time period, and flow proceeds along the idle branch of FIG.
  • the transmit timer 314 is detected as expired, then the channel will not be scheduled by the gNB for that beam pair for that time period, and at block 515, the idle timer will be decremented.
  • Example 16 The method of any of examples 14-15, wherein decrementing the idle timer comprises: decrementing the idle timer until the idle timer expires; and the method comprising resetting values for at least one of the transmit timer and/or the idle timer if both the transmit timer and the idle timer have expired.
  • the decrementing of idle timer 316 at 515 may be performed until the idle timer is expired (e.g., equal to zero, or less than or equal to zero). Each time period, data will not be scheduled for transmission (at 507), then flow proceeds to blocks 515 and 518, where the idle timer 316 will be decremented at 515.
  • flow may return to blocks 501, 503 and 505, where an updated congestion metric may be determined (block 501), and new or updated initial values may be determined (e.g., at block 503 based on the updated congestion metric) for the timers 314, 316, and then values of the transmit timer 314 and/ or idle timer 316 are reset or reinitialized (at block 505) to the updated initial values.
  • an updated congestion metric may be determined (block 501)
  • new or updated initial values may be determined (e.g., at block 503 based on the updated congestion metric) for the timers 314, 316, and then values of the transmit timer 314 and/ or idle timer 316 are reset or reinitialized (at block 505) to the updated initial values.
  • Example 17 An apparatus comprising means (e.g., processor 1104 and/or controller 1108, and/or memory 1106, and/or apparatus or node 1100, FIG. 7), for performing the method of any of examples 1-16.
  • means e.g., processor 1104 and/or controller 1108, and/or memory 1106, and/or apparatus or node 1100, FIG. 7
  • Example 18 A non-transitory computer-readable storage medium (e.g., memory 1106, FIG. 7) comprising instructions stored thereon that, when executed by at least one processor (e.g., processor 1104 and/or controller 1108, FIG. 7), are configured to cause a computing system (e.g., apparatus or node 1100, FIG. 7) to perform the method of any of examples 1-16.
  • processor e.g., processor 1104 and/or controller 1108, FIG. 7
  • a computing system e.g., apparatus or node 1100, FIG.
  • Example 19 An apparatus (e.g., apparatus or node 1100, FIG. 7) comprising: at least one processor (e.g., processor 1104 and/or controller 1108, FIG. 7); and at least one memory (e.g., memory 1106, FIG. 7) including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method of any of examples 1 - 16.
  • processor e.g., processor 1104 and/or controller 1108, FIG. 7
  • memory e.g., memory 1106, FIG. 7
  • the apparatus e.g., apparatus or node 1100, FIG. 7
  • at least one processor e.g., processor 1104 and/or controller 1108, FIG. 7
  • at least one memory e.g., memory 1106, FIG. 7 including computer program code
  • the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the method of any of examples 1 - 16.
  • FIG. 7 is a block diagram of a wireless station or node (e.g., AP, BS, gNB, eNB, a relay node or other network node, or a user device/UE, or other node) 1100 according to an example embodiment.
  • the wireless station 1100 may include, for example, one or more (e.g., two as shown in FIG. 7) RF (radio frequency) or wireless transceivers 1102 A, 1102B, where each wireless transceiver includes a transmitter to transmit signals and a receiver to receive signals.
  • the wireless station also includes a processor or control unit/entity (controller) 1104 to execute instructions or software and control transmission and receptions of signals, and a memory 1106 to store data and/or instructions.
  • a processor or control unit/entity (controller) 1104 to execute instructions or software and control transmission and receptions of signals
  • a memory 1106 to store data and/or instructions.
  • Processor 1104 may also make decisions or determinations, generate frames, packets or messages for transmission, decode received frames or messages for further processing, and other tasks or functions described herein.
  • Processor 1104 which may be a baseband processor, for example, may generate messages, packets, frames or other signals for transmission via wireless transceiver 1102 (1102A or 1102B).
  • Processor 1104 may control transmission of signals or messages over a wireless network, and may control the reception of signals or messages, etc., via a wireless network (e.g., after being down-converted by wireless transceiver 1102, for example).
  • Processor 1104 may be programmable and capable of executing software or other instructions stored in memory or on other computer media to perform the various tasks and functions described above, such as one or more of the tasks or methods described above.
  • Processor 1104 may be (or may include), for example, hardware, programmable logic, a programmable processor that executes software or firmware, and/or any combination of these.
  • processor 1104 and transceiver 1102 together may be considered as a wireless transmitter/receiver system, for example.
  • a controller (or processor) 1108 may execute software and instructions, and may provide overall control for the station 1100, and may provide control for other systems not shown in FIG. 7, such as controlling input/output devices (e.g., display, keypad), and/or may execute software for one or more applications that may be provided on wireless station 1100, such as, for example, an email program, audio/video applications, a word processor, a Voice over IP application, or other application or software.
  • a storage medium may be provided that includes stored instructions, which when executed by a controller or processor may result in the processor 1104, or other controller or processor, performing one or more of the functions or tasks described above.
  • Processor 1104 may control the RF or wireless transceiver 1102A or 1102B to receive, send, broadcast or transmit signals or data.
  • the example embodiments are not, however, restricted to the system that is given as an example, but a person skilled in the art may apply the solution to other communication systems.
  • Another example of a suitable communications system is the 5G system. It is assumed that network architecture in 5G will be quite similar to that of the LTE -advanced. 5G is likely to use multiple input - multiple output (MIMO) antennas, many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and perhaps also employing a variety of radio technologies for better coverage and enhanced data rates.
  • MIMO multiple input - multiple output
  • NFV network functions virtualization
  • a virtualized network function may comprise one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized.
  • radio communications this may mean node operations may be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head. It is also possible that node operations will be distributed among a plurality of servers, nodes or hosts. It should also be understood that the distribution of labour between core network operations and base station operations may differ from that of the LTE or even be non-existent.
  • Example embodiments of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them.
  • Example embodiments may be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, a data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
  • Embodiments may also be provided on a computer readable medium or computer readable storage medium, which may be a non-transitory medium.
  • Embodiments of the various techniques may also include embodiments provided via transitory signals or media, and/or programs and/or software embodiments that are downloadable via the Internet or other network(s), either wired networks and/or wireless networks.
  • embodiments may be provided via machine type communications (MTC), and also via an Internet of Things (IOT).
  • MTC machine type communications
  • IOT Internet of Things
  • the computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program.
  • carrier include a record medium, computer memory, read only memory, photoelectrical and/or electrical carrier signal, telecommunications signal, and software distribution package, for example.
  • the computer program may be executed in a single electronic digital computer or it may be distributed amongst a number of computers.
  • example embodiments of the various techniques described herein may use a cyber-physical system (CPS) (a system of collaborating computational elements controlling physical entities).
  • CPS may enable the embodiment and exploitation of massive amounts of interconnected ICT devices (sensors, actuators, processors microcontrollers, ...) embedded in physical objects at different locations.
  • ICT devices sensors, actuators, processors microcontrollers, ...) embedded in physical objects at different locations.
  • Mobile cyber physical systems in which the physical system in question has inherent mobility, are a subcategory of cyber-physical systems. Examples of mobile physical systems include mobile robotics and electronics transported by humans or animals. The rise in popularity of smartphones has increased interest in the area of mobile cyber-physical systems. Therefore, various embodiments of techniques described herein may be provided via one or more of these technologies.
  • a computer program such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit or part of it suitable for use in a computing environment.
  • a computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
  • Method steps may be performed by one or more programmable processors executing a computer program or computer program portions to perform functions by operating on input data and generating output. Method steps also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
  • FPGA field programmable gate array
  • ASIC application-specific integrated circuit
  • processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer, chip or chipset.
  • a processor will receive instructions and data from a read-only memory or a random access memory or both.
  • Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data.
  • a computer also may include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks.
  • Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
  • the processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.
  • embodiments may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a user interface, such as a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.
  • a display device e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor
  • a user interface such as a keyboard and a pointing device, e.g., a mouse or a trackball
  • Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
  • Example embodiments may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an embodiment, or any combination of such back-end, middleware, or front-end components.
  • Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
  • LAN local area network
  • WAN wide area network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne, selon un mode de réalisation donné à titre d'exemple, un procédé pouvant consister à déterminer une première valeur initiale pour un temporisateur d'émission et une seconde valeur initiale pour un temporisateur d'inactivité ; régler le temporisateur de transmission à la première valeur initiale et le temporisateur d'inactivité à la seconde valeur initiale ; et réaliser les étapes suivantes jusqu'à ce qu'au moins l'un du temporisateur d'émission ou du temporisateur d'inactivité expire : planifier un canal d'un réseau sans fil pour une transmission de données et décrémenter le temporisateur d'émission lorsqu'il y a des données à transmettre par l'intermédiaire du canal ; et sinon, décrémenter le temporisateur d'inactivité lorsqu'il n'y a pas de données à transmettre par l'intermédiaire du canal.
PCT/EP2020/052960 2020-02-06 2020-02-06 Mécanisme de détection et d'évitement pour réseaux sans fil Ceased WO2021155929A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2020/052960 WO2021155929A1 (fr) 2020-02-06 2020-02-06 Mécanisme de détection et d'évitement pour réseaux sans fil

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2020/052960 WO2021155929A1 (fr) 2020-02-06 2020-02-06 Mécanisme de détection et d'évitement pour réseaux sans fil

Publications (1)

Publication Number Publication Date
WO2021155929A1 true WO2021155929A1 (fr) 2021-08-12

Family

ID=69570639

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/052960 Ceased WO2021155929A1 (fr) 2020-02-06 2020-02-06 Mécanisme de détection et d'évitement pour réseaux sans fil

Country Status (1)

Country Link
WO (1) WO2021155929A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220046702A1 (en) * 2020-08-06 2022-02-10 Samsung Electronics Co., Ltd. Multi-beam lbt for nr-u at 60 ghz
US12389274B2 (en) 2022-06-07 2025-08-12 Microsoft Technology Licensing, Llc Alleviating cell congestion in wireless networks

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3331312A1 (fr) * 2015-07-31 2018-06-06 Samsung Electronics Co., Ltd. Procédé pour transmettre un signal sur la base d'une estimation de canal libre dans un canal à bande sans licence, et système de communication mobile
US20190313454A1 (en) * 2018-04-05 2019-10-10 Apple Inc. Listen-Before-Talk Procedure with Priority and Interference Addition Awareness

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3331312A1 (fr) * 2015-07-31 2018-06-06 Samsung Electronics Co., Ltd. Procédé pour transmettre un signal sur la base d'une estimation de canal libre dans un canal à bande sans licence, et système de communication mobile
US20190313454A1 (en) * 2018-04-05 2019-10-10 Apple Inc. Listen-Before-Talk Procedure with Priority and Interference Addition Awareness

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220046702A1 (en) * 2020-08-06 2022-02-10 Samsung Electronics Co., Ltd. Multi-beam lbt for nr-u at 60 ghz
US11956818B2 (en) * 2020-08-06 2024-04-09 Samsung Electronics Co., Ltd. Multi-beam LBT for NR-U at 60 GHz
US20240196435A1 (en) * 2020-08-06 2024-06-13 Samsung Electronics Co., Ltd. Multi-beam lbt for nr-u at 60 ghz
US12245275B2 (en) * 2020-08-06 2025-03-04 Samsung Electronics Co., Ltd. Multi-beam LBT for NR-U at 60 GHz
US12389274B2 (en) 2022-06-07 2025-08-12 Microsoft Technology Licensing, Llc Alleviating cell congestion in wireless networks

Similar Documents

Publication Publication Date Title
US11991555B2 (en) Dynamic reliability target for wireless networks
US10959225B2 (en) Techniques for handling semi-persistent scheduling collisions for wireless networks
US10764901B2 (en) Resource allocation and scheduling for wireless networks with self-backhauled links
EP3520481B1 (fr) Gestion de tampon pour réseaux sans fil durant un transfert
US12408062B2 (en) Group based beam reporting
EP3751900A1 (fr) Sélection d'une cellule cible pour un transfert sur la base d'une mesure de réponse d'impulsion de canal
US12267260B2 (en) Synchronization signaling block compatible interference coordination patterns to reduce interference in wireless networks
WO2021155929A1 (fr) Mécanisme de détection et d'évitement pour réseaux sans fil
EP3777431B1 (fr) Indication de rétroaction pour une transmission continue dans des réseaux sans fil
US10966243B2 (en) Flexible resource usage between scheduling-based and contention-based resource access for wireless networks
US12363586B2 (en) Data transmission via frequency interlace for wireless networks
US20240259157A1 (en) Sensing reference signal configuration
US20250158691A1 (en) Ue operation for multi-trp system for wireless networks
WO2025156503A1 (fr) Procédé de rapport de mesure l1 déclenché par un événement
US20250286602A1 (en) Maximum permissible exposure reporting
WO2019096386A1 (fr) Réduction d'interférence de liaison montante pour réseaux sans fil
EP4385158A1 (fr) Traitement d'une erreur de rétroaction harq pour autorisation configurée
HK40046701A (en) Feedback indication for continued transmission for wireless networks
HK40046701B (en) Feedback indication for continued transmission for wireless networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20704810

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20704810

Country of ref document: EP

Kind code of ref document: A1