WO2022268967A1 - Channel access technique - Google Patents

Abstract

A technique for switching between channel access modes for a transmission from a wireless device (100) on a wireless channel (502; 522) is described. The channel access modes comprise a listen-before-talk, LBT, mode and a non-LBT mode. As to a method aspect of the technique, the wireless device (100) determines to switch the channel access mode for the transmission from the wireless device (100) on the wireless channel (502; 522) between the LBT mode and the non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode.

Description

Channel Access Technique

Technical Field

The present disclosure relates to a technique for accessing a wireless channel. More specifically, and without limitation, methods and devices are provided for switching between a listen-before-talk (LBT) mode and a non-LBT mode for a transmission from a wireless device on a wireless channel.

Background

Mobile broadband will continue to drive demands for higher overall traffic capacity and higher achievable end-user data rates in wireless access networks, such as Fifth Generation (5G) radio access networks (RANs) defined by the Third Generation Partnership Project (3GPP). Several scenarios in the future will require data rates, e.g., on the order of 10 Gbps in local areas. These demands for very high system capacity and very high end-user date rates can be met by networks with distances between access nodes ranging from a few meters in indoor deployments up to roughly 50 m in outdoor deployments, i.e. with an infra-structure density considerably higher than the densest networks of today. The wide transmission bandwidths needed to provide data rates up to 10 Gbps and above can likely only be obtained from spectrum allocations in the millimeter-wave band. High-gain beamforming, typically realized with array antennas, can be used to mitigate the increased pathloss at higher frequencies. We refer to such networks as NR systems in the following.

At least in some spatial areas and frequency ranges, the resources for wireless channels are shared among different RANs and/or different radio access technologies (RATs). In such shared scenarios, a wireless device may mandatorily perform an LBT process as a mechanism for accessing the shared resources.

However, decisions of a network node serving the wireless device as to whether or not the wireless device has to perform the LBT process may be detrimental due to lacking knowledge of the state of the wireless channel at the end of the wireless device. Summary

Accordingly, there is a need for a channel access technique that enables more accurate decisions as to whether or not an LBT process is performed at a wireless device.

As to a first method aspect, a method of switching between channel access modes for a transmission from a wireless device on a wireless channel is provided. The channel access modes comprise a listen-before-talk (LBT) mode and a non-LBT mode. The method comprises or initiates the step of determining, at the wireless device, to switch the channel access mode for the transmission from the wireless device on the wireless channel between the LBT mode and the non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode.

The LBT mode or the non-LBT mode resulting from the determining (e.g., resulting from the determining to switch or from the switching as determined) may also be referred to as the determined channel access mode. The LBT mode or the non-LBT mode applied prior to the determining (e.g., prior to the determining to switch or prior to the switching) may also be referred to as the current channel access mode.

The determining, at the wireless device, to switch the channel access mode may comprise determining, autonomously at the wireless device, to switch the channel access mode.

The method may be implemented as a method of selectively performing an LBT process on a wireless channel by a wireless device. The determining step may comprise or may be implemented by determining, at the wireless device, whether or not to perform the LBT process on the wireless channel (e.g., prior to the transmission). Alternatively or in addition, the step of determining to switch the channel access mode may comprise or may be implemented by switching from a current channel access mode to the determined channel access mode or applying the determined channel access mode. Applying the determined channel access mode or switching to the determined channel access mode may comprise applying the determined channel access mode for the transmission or any further transmission until the channel access mode is changed. The LBT process may comprise at least one of a clear channel assessment (CCA) and back-off mechanism. The CCA may comprise measuring energy within a predefined time or power on the wireless channel. The wireless channel may be clear, if the measured energy or power is less than a predefined first threshold value. The wireless channel may be occupied, if the measured energy or power is greater than the predefined first threshold value or a predefined second threshold value greater than the predefined first threshold value. Alternatively or in addition, the back-off mechanism may comprise a back-off counter or back-off timer (e.g., initialized by a value selected randomly within a contention window). The back-off counter or back-off timer may be decremented when the wireless channel is clear.

The LBT process may be a channel access mechanism defined by 3GPP and/or specified for a radio access technology (RAT) used by the wireless device and/or for the transmission on the wireless channel. In the LBT mode, the transmission from the wireless device on the wireless channel may comprise performing the LBT process and transmitting on the wireless channel depending on a result of the LBT process, e.g., not until or upon the LBT process indicating that the wireless channel is idle, e.g., clearance of CCA and/or expiry of a back-off timer or back-off counter (e.g., when the back-off counter or back-off timer is zero).

In a first variant of any embodiment, in the non-LBT mode, the transmission from the wireless device on the wireless channel does not comprise performing the LBT process and/or does not depend on the LBT process. For example, the transmission from the wireless device on the wireless channel may be performed unconditionally and/or as scheduled (i.e., using a scheduled resource) on the wireless channel. Alternatively or in addition, the wireless device may skip the LBT process in the non-LBT mode. In a second variant of any embodiment, which may be combined with the first variant, another channel access mechanism other than the LBT process may be performed in the non-LBT mode prior to the transmission from the wireless device on the wireless channel. The other channel access mechanism may have less restrictive requirements (e.g., a CCA without a back-off mechanism) for the transmission on the wireless channel.

The wireless device may be wirelessly connected or connectable to a network node or a radio access network comprising at least one network node. The wireless device may be configured for the transmission and/or reception on the wireless channel according to the channel access mode. Alternatively or in addition, the wireless device may be configured for an optical or radio transmission and/or an optical or radio reception on the wireless channel. The wireless channel may be a free-space optical (FSO) channel or a radio channel.

The transmission and/or the reception on the wireless channel may be directed. That is, the transmission may be a beamformed transmission and/or the reception may be a beamformed reception. The wireless channel may also be referred to as a beam.

The non-LBT mode may also be referred to as non-LBT operation or no-LBT mode or no-LBT operation.

The method (e.g., according to the first method aspect) may further comprise or initiate the step of receiving a configuration message from a network node serving the wireless device. The configuration message may be indicative of the LBT mode or the non-LBT mode as an initial channel access mode.

The initial channel access mode may be a baseline for the transmission or the operation of the wireless device. Alternatively or in addition, the wireless device may be configured to perform the transmission or operate in the initial channel access mode.

The determined channel access mode (e.g., according to the first method aspect) may be different from the initial channel access mode.

The wireless device may be configured (e.g., by the configuration message) with the non-LBT mode as an initial channel access mode. After some time of operating in the non-LBT mode, the wireless device may determine that the non-LBT mode is not suitable (e.g., for the wireless channel and/or the wireless device) in the determining step. Accordingly, the wireless device may switch to and/or apply the LBT mode.

Alternatively or in addition, the wireless device may be configured (e.g., by the configuration message) with the LBT mode as an initial channel access mode. After some time of operating in the LBT mode, the wireless device may determine that the LBT mode is not suitable (e.g., for the wireless channel and/or the wireless device) in the determining step. Accordingly, the wireless device may switch to and/or apply the non-LBT mode.

The method (e.g., according to the first method aspect) may further comprise or initiate at least one of the steps of transmitting a report from the wireless device to a network node serving the wireless device, the report being indicative of the determined channel access mode; and receiving a feedback message from a network node serving the wireless device, the feedback message being indicative of an acknowledgment or a rejection of the determined channel access mode.

The method may further comprise receiving an acknowledgment of the determined channel access mode from the serving network node. The wireless device may switch to or apply the determined channel access mode responsive to the acknowledgment.

The feedback message may be received responsive to at least one of the report indicative of the determined channel access mode and a transmission according the determined channel access mode.

The wireless device (e.g., according to the first method aspect) may switch to the determined channel access mode without a report of the determined channel access mode to and/or without an acknowledgment of the determined channel access mode from a network node serving the wireless device.

The wireless device may apply the determined channel access mode immediately and/or without communication with and/or without confirmation from a network node serving the wireless device.

The method (e.g., according to the first method aspect) may further comprise or initiate the step of transmitting a request from the wireless device to a network node serving the wireless device. The request may be indicative of the determined channel access mode. The wireless device may switch to the determined channel access mode responsive to a feedback message received from the network node in response to the transmitted request and indicative of an acknowledgment of the determined channel access mode. Alternatively or in addition, the wireless device may refrain from switching to the determined channel access mode responsive to a feedback message received from the network node in response to the transmitted request and indicative of a rejection of the determined channel access mode.

The reported or requested channel access mode (i.e., the determined channel access mode indicated in the report or the request) may be indicative of a preference of the wireless device. The reported or requested channel access mode may be part of assistance information provided by the wireless device to the network node.

Alternatively or in addition, the method may further comprise or initiate the step of transmitting a request from the wireless device to a network node serving the wireless device. The request may be indicative of the determined channel access mode as preferred channel access mode. The method may further comprise or initiate the step of receiving a further configuration message from the serving network node in response to the request, the further configuration message being indicative of the determined channel access mode or another channel access mode.

At least one of the report and the request (e.g., according to the first method aspect) may use or may be comprised in, or may be indicated by, at least one of a message on a physical uplink shared channel (PUSCH) optionally without user plane data; a medium access control (MAC) control element (CE); a radio resource control (RRC) signaling; a message on a random access channel (RACH) optionally a random access preamble (RAP) or Message 1 or Message A of a random access procedure or a Message 3 of a random access procedure; a message on a physical uplink control channel (PUCCH) or an uplink control information (UCI); and a sounding reference signal (SRS).

At least one of the report and the request (e.g., according to the first method aspect) may be further indicative of a reason for the switching of the channel access mode.

The channel access mode (e.g., according to the first method aspect) may be determined based on one or more conditions measured at the wireless device and/or one or more events at the wireless device. The reason indicated in the report and the request may comprise the one or more conditions measured at the wireless device and/or the one or more events at the wireless device.

The wireless device may determine to switch the channel access mode (e.g., after a while and/or after receiving the configuration indicative of the initial channel access mode) when a current channel access mode (i.e., the LBT mode or the non- LBT mode, e.g., the initial channel access mode) is not suitable any more, e.g., based on a condition of the wireless device and/or the wireless channel. The conditions may also be referred to as criteria.

The one or more events at the wireless device may comprise the availability of data (e.g., received from higher layers or an application layer) at the wireless device for the transmission. The data for the transmission may associated with a type of data or a type of application.

At least one of the configuration message and the feedback message (e.g., according to the first method aspect) may use or may be comprised in or may be indicated by at least one of a message on a physical downlink shared channel (PDSCH) optionally without user plane data; a MAC CE; an RRC signaling; and a message on a physical downlink control channel (PDCCH) or a downlink control information (DCI) optionally addressed to a cell radio network temporary identifier (C-RNTI) of the wireless device.

The method (e.g., according to the first method aspect) may further comprise or initiate the step of selectively performing the LBT process at the wireless device on the wireless channel according to the determined channel access mode.

The LBT process may be performed selectively at the wireless device on the wireless channel according to either the LBT mode or the non-LBT mode resulting from the determining step.

The LBT process may be selectively performed responsive to data available for the transmission at the wireless device and/or prior to the transmission (e.g., prior to the occurrence of a resource scheduled on the wireless channel for the transmission. The method (e.g., according to the first method aspect) may further comprise or initiate the step of transmitting from the wireless device on the wireless channel. The transmission may be selectively subject to the LBT process according to the determined channel access mode.

The transmission may be selectively based on the LBT process according to the determination.

The wireless channel (e.g., according to the first method aspect) may be on an uplink (UL) between the wireless device and a network node, or wherein a message may be transmitted from the wireless device on the wireless channel to a network node using an UL.

The wireless channel (e.g., according to the first method aspect) may be on a sidelink (SL) between the wireless device and another wireless device.

Alternatively or in addition, a message may be transmitted from the wireless device on the wireless channel to another wireless device using a SL.

The method (e.g., according to the first method aspect) wherein at least one of the transmission may comprise transmitting data; the wireless channel may comprise a physical uplink shared channel (PUSCH); the wireless channel may comprise a physical sidelink shared channel (PSSCH); the transmission may comprise transmitting control signaling; the wireless channel may comprise a physical uplink control channel (PUCCH); and the wireless channel may comprise a physical sidelink control channel (PSCCH).

The wireless channel (e.g., according to the first method aspect) may be within a region that does not require performing the LBT process for the transmission on the wireless channel.

The region that does not require performing the LBT process may encompass a region where the LBT process is not mandated.

The wireless device may receive, from the serving network node, a control message. The control message may be indicative of the wireless device or the wireless channel being in a region that does not require performing the LBT process. Alternatively or in addition, the control message may be indicative of the wireless device being allowed to (e.g., autonomously) determine to switch the channel access mode. The control message may be received in response to channel state information (CSI) reported to the serving network node. The reported CSI may be indicative of a channel quality indicator (CQI) less than a predefined CQI threshold value.

The region (e.g., according to the first method aspect) may comprise a spatial area.

The wireless device may be in a region that does not require performing the LBT process for the transmission on the wireless channel. The region may correspond to an area covered by the network node serving the wireless device.

The region (e.g., according to the first method aspect) may comprise a frequency range.

The region may correspond to a radio spectrum or an optical spectrum that is shared between different RATs, e.g., unlicensed spectrum. Alternatively or in addition, the region may correspond to a frequency range 2 (FR2) from 24.250 GHz to 52.6 GHz or from 52.6 GHz to 71 GHz.

The wireless device (e.g., according to the first method aspect) may determine to switch to the LBT mode when measuring interference on the wireless channel at the wireless device.

The interference may be measured (e.g., observed) or measurable (e.g., observable) only at the wireless channel. The interference may be not measured (e.g., not observed) or not measurable (e.g., not observable) at the serving network node. For example, the interference may be caused by hidden nodes, e.g., nodes hidden from the perspective of the serving network node. The hidden nodes may be part of another RAN other than the RAN of the serving network node. Alternatively or in addition, the hidden nodes may use another RAT other than the RAT of the serving network node.

The wireless device (e.g., according to the first method aspect) may determine to switch the channel access mode depending on at least one of a type of the transmission; a type of a service or application underlying the transmission; and a type of the data or traffic to be transmitted; a Quality of Service (QoS) or a 5G QoS Identifier (5QI) associated with the transmission; and a flow, a flow identifier, a QoS flow, a QoS flow identifier, a protocol data unit, PDU, session, a PDU session identifier, a bearer, a bearer identifier, a logical channel (LCH) a LCH identifier, a logical channel group (LCG) a LCG identifier, a LCH priority, or a LCG priority associated with the transmission.

The wireless device (e.g., according to the first method aspect) may determine to switch to the LBT mode if the transmission is associated with a transmission reliability greater than a predefined reliability threshold value.

The wireless device (e.g., according to the first method aspect) may determine to switch to the non-LBT mode if the transmission is associated with a required data rate greater than a predefined data rate threshold value and/or a required latency less than a predefined latency threshold value.

The wireless device (e.g., according to the first method aspect) may determine to switch to the non-LBT mode if a priority associated with the transmission is greater than a predefined first priority threshold value. Alternatively or in addition, the wireless device may determine to switch to the LBT mode if a priority associated with the transmission is less than the predefined first priority threshold value or a predefined second priority threshold value less than the predefined first priority threshold value.

The priority associated with the transmission may be a priority associated with the type of service, application, data or traffic underlying (e.g., triggering) the transmission.

The wireless device (e.g., according to the first method aspect) may determine to switch to the non-LBT mode if a quality of service (QoS) associated with the transmission is greater than a predefined first QoS threshold value. Alternatively or in addition, the wireless device may determine to switch to the LBT mode if a QoS associated with the transmission is less than the predefined first QoS threshold value or a predefined second QoS threshold value less than the predefined first QoS threshold value. The QoS associated with the transmission may be a QoS requirement of a service, an application, data or traffic underlying (e.g., triggering) the transmission.

The wireless device (e.g., according to the first method aspect) may determine to switch to the non-LBT mode if a volume of data pending for the transmission is greater than a predefined first data volume threshold value. Alternatively or in addition, the wireless device may determine to switch to the LBT mode if a volume of data pending for the transmission is less than the predefined first data volume threshold value or a predefined second data volume threshold value less than the predefined first data volume threshold value.

The volume of data pending for the transmission may be a data volume of a service, an application or traffic using the wireless channel.

The wireless device (e.g., according to the first method aspect) may determine to switch to the non-LBT mode if a measured congestion of a system using the wireless channel or a measured occupancy of the wireless channel is greater than a predefined first congestion threshold value. Alternatively or in addition, the wireless device may determine to switch to the LBT mode if a measured congestion of a system using the wireless channel or a measured occupancy of the wireless channel is less than the predefined first congestion threshold value or a predefined second congestion threshold value less than the predefined first congestion threshold value.

The congestion of the system using the wireless channel or the occupancy of the wireless channel may be measured at the wireless device. The system may comprise at least one of the network node serving the wireless device, one or more neighboring network nodes of the wireless device, and one or more neighboring wireless devices of the wireless device.

The wireless device (e.g., according to the first method aspect) may determine to switch to the LBT mode if a measured interference on the wireless channel is greater than a predefined first interference threshold value. Alternatively or in addition, the wireless device may determine to switch to the non-LBT mode if a measured interference on the wireless channel is less than the predefined first interference threshold value or a predefined second interference threshold value less than the predefined first interference threshold value. The interference may be measured at the wireless device.

The wireless device (e.g., according to the first method aspect) may determine to switch to the non-LBT mode if a measured signal strength on the wireless channel is greater than a predefined first signal strength threshold value. Alternatively or in addition, the wireless device may determine to switch to the LBT mode if a measured signal strength on the wireless channel is less than the predefined first signal strength threshold value or a predefined second signal strength threshold value less than the predefined first signal strength threshold value.

The signal strength may be measured at the wireless device. The signal strength may be a radio strength of the wireless channel as a radio channel measured at the wireless device or an optical intensity of the wireless channel as an optical channel measured at the wireless device.

Alternatively or in addition, the signal strength may be measured in terms of at least one of a reference signal received power (RSRP), a reference signal received quality (RSRQ), a received signal strength indicator (RSSI), a signal-to-noise ratio (SNR), a signal-to-interference and noise ratio (SNIR), and a signal-to-interference ratio (SIR).

The wireless device (e.g., according to the first method aspect) may determine to switch to the non-LBT mode if a performance metric in terms of packets on the wireless channel is greater than a predefined first performance metric threshold value. Alternatively or in addition, the wireless device may determine to switch to the LBT mode if a performance metric in terms of packets on the wireless channel is less than the predefined first performance metric threshold value or a predefined second performance metric threshold value less than the predefined first performance metric threshold value.

The performance metric may be measured in terms of packets on the wireless channel and/or transmitted from the wireless device and/or received at the wireless device. Alternatively or in addition, the performance metric may be or may comprise at least one of a (e.g., negative or inverse) packet delay, a (e.g., negative or inverse) packet loss (e.g., packet loss rate), a (e.g., negative or inverse) packet collision rate, a (e.g., negative or inverse) packet error rate, a (e.g., negative or inverse) jitter, and a data rate.

The wireless device (e.g., according to the first method aspect) may determine to switch to the non-LBT mode if a requirement for short control signal (SCS) exemption on the wireless channel is fulfilled. Alternatively or in addition, the wireless device may determine to switch to the LBT mode if a requirement for SCS exemption on the wireless channel is not fulfilled.

The short control signal (SCS) may also be referred to as short control signaling.

The requirement for the SCS exemption may be a requirement for the transmission (e.g., transmitting control signaling and/or not transmitting payload or user plain data).

The SCS exemption (e.g., according to the first method aspect) may require the transmission of at least one of a message on a RACH or a RAP; an SRS; a message on a PUCCH or a UCI; a message on a physical sidelink control channel (PSCCH) or a sidelink control information (SCI); and a message on a PUSCH without user plane data or a MAC CE or an RRC signaling.

The requirement for the SCS exemption may be a requirement for the occupancy of resources (e.g., radio resources) on the wireless channel (e.g., a radio channel).

The SCS exemption (e.g., according to the first method aspect) may require an amount or a share of resources occupied by the wireless device on the wireless channel to be less than an occupancy threshold value.

For example, the requirement for the SCS exemption may depend on the amount or the share (e.g., proportion) of resources occupied by the wireless device on the wireless channel. The amount or the share (e.g., proportion) of the resources may be measured in the frequency domain and/or in the time domain resources

The SCS exemption (e.g., according to the first method aspect) may require the share of resources occupied by the wireless device on the wireless channel to be less than 10% over intervals of 100 ms. The SCS exemption (e.g., according to the first method aspect) may require that the wireless device has occupied on the wireless channel no more than a predefined share of the resources in the frequency domain over sequences of a predefined number of consecutive physical resource blocks (PRBs).

The predefined share of the resources in the frequency domain may be configured (e.g., by the serving network node) or hardcoded (e.g., according to a technical as specification). Alternatively or in addition, the predefined number of consecutive PRBs may be configured (e.g., by the serving network node) or hardcoded (e.g., according to a technical as specification).

The wireless device (e.g., according to the first method aspect) may determine that the requirement for the SCS exemption is fulfilled at the wireless device and/or at a network node serving the wireless device.

The wireless device may transmit a query message to the serving network node. The query message may be indicative of a query whether or not the requirement for the SCS exemption is fulfilled at the network node.

The wireless device (e.g., according to the first method aspect) may determine to switch to the non-LBT mode if the wireless device is located in, or moves to, a region that does not require performing the LBT process for the transmission on the wireless channel. Alternatively or in addition, the wireless device may determine to switch to the LBT mode if the wireless device is located in, or moves to, a region that requires performing the LBT process for the transmission on the wireless channel.

The wireless device (e.g., according to the first method aspect) may determine to switch to the LBT mode if a state of charge of a battery of the wireless device is greater than a predefined first charge threshold value. Alternatively or in addition, the wireless device may determine to switch to the non-LBT mode if a state of charge of a battery of the wireless device is less than the predefined first charge threshold value or a predefined second charge threshold value less than the predefined first charge threshold value.

The wireless device (e.g., according to the first method aspect) may determine to switch to the LBT mode if a transmission power class of the wireless device for the transmission or recent transmissions on the wireless channel is greater than a predefined first power class threshold value. Alternatively or in addition, the wireless device may determine to switch to the non-LBT mode if a transmission power class of the wireless device for the transmission or recent transmissions on the wireless channel is less than the predefined first power class threshold value or a predefined second power class threshold value less than the predefined first power class threshold value.

The method may be performed for each of a plurality of wireless channels. The wireless channel or each of the wireless channels may be (e.g., uniquely) associated with a beam or a synchronization signal block (SSB) or a bandwidth part (BWP) or a cell or a cell group or a carrier.

The channel access mode (e.g., according to the first method aspect) may be at least one of determined, switched, applied, reported and requested per beam or per synchronization signal block (SSB) or per bandwidth part (BWP) or per cell or per cell group or per carrier.

The method (e.g., according to the first method aspect) may be performed by the wireless device.

As to a second method aspect a method of serving a wireless device switching between channel access modes for a transmission from the wireless device on a wireless channel is provided. The channel access modes comprise a listen-before- talk (LBT) mode and a non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode. The method comprises or initiates the step of receiving a report from the wireless device at a network node serving the wireless device, the report being indicative of a channel access mode determined at the wireless device for the switching between the LBT mode and the non-LBT mode.

The second method aspect may further comprise any feature and/or any step disclosed in the context of the first method aspect, or a feature and/or step corresponding thereto, e.g., a receiver counterpart to a transmitter feature or step. The method (e.g., according to the second method aspect) may further comprise or initiate the step of transmitting a configuration message from the network node to the wireless device, the configuration message being indicative of the LBT mode or the non-LBT mode as an initial channel access mode.

The configuration message may be transmitted prior to the wireless device determining to switch the (e.g., initial) channel access mode and/or prior to the network node receiving the report indicative of the determined channel access mode.

The determined channel access mode (e.g., according to the second method aspect) may be different from the initial channel access mode.

The method (e.g., according to the second method aspect) may further comprise or initiate the step of transmitting a feedback message from the network node to the wireless device, the feedback message being indicative of an acknowledgment or a rejection of the determined channel access mode.

The method (e.g., according to the second method aspect) may further comprise or initiate the step of determining that the wireless device switched the channel access mode based on a pattern of transmissions from the wireless device on the wireless channel.

The network node may determine that the wireless device has switched to the LBT mode based on a (e.g., positive) temporal correlation between an idle state of the wireless channel (e.g., as measured at the network node) and the transmission from the wireless device. Alternatively or in addition, the network node may determine that the wireless device has switched to the LBT mode based on a (e.g., negative) temporal correlation between an occupied state of the wireless channel (e.g., as measured at the network node) and the transmission from the wireless device.

The method (e.g., according to the second method aspect) may further comprise or initiate the step of receiving a request from the wireless device at the network node. The request may be indicative of the determined channel access mode. The method (e.g., according to the second method aspect) may further comprise the step of transmitting a feedback message from the network node to the wireless device in response to the received request.

The feedback message may be indicative of an acknowledgment of the determined channel access mode which triggers the wireless device to switch to the determined channel access mode. Alternatively or in addition, the feedback message is indicative of a rejection of the determined channel access mode which triggers the wireless device to refrain from switching to the determined channel access mode.

The method (e.g., according to the second method aspect) may be performed by the network node serving the wireless device.

The method (e.g., according to the second method aspect) may further comprise any one of the features or the steps of the first method aspect or any feature or step corresponding thereto.

As to another aspect, a computer program product is provided. The computer program product comprises program code portions for performing any one of the steps of the first method aspect and/or the second method aspect disclosed herein when the computer program product is executed by one or more computing devices. The computer program product may be stored on a computer-readable recording medium. The computer program product may also be provided for download, e.g., via the radio network, the RAN, the Internet and/or the host computer. Alternatively, or in addition, the method may be encoded in a Field- Programmable Gate Array (FPGA) and/or an Application-Specific Integrated Circuit (ASIC), or the functionality may be provided for download by means of a hardware description language.

As to a first device aspect, a wireless device for switching between channel access modes for a transmission from the wireless device on a wireless channel is provided. The channel access modes comprise a listen-before-talk (LBT) mode and a non-LBT mode. The wireless device comprises memory operable to store instructions and processing circuitry operable to execute the instructions, such that the wireless device is operable to determine, at the wireless device, to switch the channel access mode for the transmission from the wireless device on the wireless channel between the LBT mode and the non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode.

The wireless device (e.g., according to the first device aspect) may further comprise the features, or may be operable to perform any of the steps, of the first method aspect.

As to another first device aspect, a wireless device for switching between channel access modes for a transmission from the wireless device on a wireless channel is provided. The channel access modes comprise a listen-before-talk (LBT) mode and a non-LBT mode. The wireless device is configured to determine, at the wireless device, to switch the channel access mode for the transmission from the wireless device on the wireless channel between the LBT mode and the non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode.

The wireless device (e.g., according to the other first device aspect) may further comprising the features, or may be configured to perform any of the steps, of the first method aspect.

As to a yet another first device aspect, a user equipment (UE) for switching between channel access modes for a transmission from the UE on a wireless channel is provided. The channel access modes comprise a listen-before-talk (LBT) mode and a non-LBT mode. The UE is configured to communicate with a network node and/or with another UE. The UE comprises a radio interface and processing circuitry configured to determine, at the UE, to switch the channel access mode for the transmission from the UE on the wireless channel between the LBT mode and the non-LBT mode. The transmission is subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode.

For the UE (e.g., according to the yet other first device aspect), the processing circuitry may be further configured to execute any one of the steps of the first method aspect.

As to a second device aspect, a network node for serving a wireless device switching between channel access modes for a transmission from the wireless device on a wireless channel is provided. The channel access modes comprise a listen-before-talk (LBT) mode and a non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non- LBT mode. The network node comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the network node is operable to receive a report from the wireless device at the network node serving the wireless device, the report being indicative of a channel access mode determined at the wireless device for the switching between the LBT mode and the non-LBT mode.

The network node (e.g., according to the second device aspect) may further comprising the features, or operable to perform any one of the steps, of the second method aspect.

As to another second device aspect, a network node for serving a wireless device switching between channel access modes for a transmission from the wireless device on a wireless channel is provided. The channel access modes comprise a listen-before-talk (LBT) mode and a non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non- LBT mode. The network node being configured to receive a report from the wireless device at the network node serving the wireless device, the report being indicative of a channel access mode determined at the wireless device for the switching between the LBT mode and the non-LBT mode.

The network node (e.g., according to the other second device aspect) may further comprising the features, or may be configured to perform any one of the steps, of the second method aspect.

As to yet another second device aspect, a base station for serving a user equipment (UE) switching between channel access modes for a transmission from the UE on a wireless channel is provided. The channel access modes comprise a listen-before-talk (LBT) mode and a non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non- LBT mode, the base station being configured to communicate with the UE. The base station comprises a radio interface and processing circuitry configured to receive a report from the UE at the base station serving the UE, the report being indicative of a channel access mode determined at the UE for the switching between the LBT mode and the non-LBT mode. For the base station (e.g., according to the yet another second device aspect), the processing circuitry may be further configured to execute any one of the steps of the second method aspect.

As to a still further aspect, a communication system including a host computer is provided. The host computer comprises a processing circuitry configured to provide user data, e.g., for the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode. The host computer further comprises a communication interface configured to forward the data to a cellular network (e.g., the RAN and/or the base station) for transmission to a UE.

A processing circuitry of the cellular network is configured to execute any one of the steps of the first and/or second method aspects. Alternatively or in addition, the UE comprises a radio interface and processing circuitry, which is configured to execute any one of the steps of the first and/or second method aspects.

The communication system may further include the UE. Alternatively, or in addition, the cellular network may further include one or more base stations configured for radio communication with the UE and/or to provide a data link between the UE and the host computer using the first and/or second method aspects.

The processing circuitry of the host computer may be configured to execute a host application, thereby providing the data and/or any host computer functionality described herein. Alternatively, or in addition, the processing circuitry of the UE may be configured to execute a client application associated with the host application.

The communication system (e.g., according to the system aspect) may further including the UE.

The radio network (e.g., according to the system aspect) may further comprise a base station. The base station may be configured to communicate with the UE. The base station (e.g., according to the system aspect) may comprise processing circuitry, which is configured to execute any one of the steps of the second method aspect.

The communication system (e.g., according to the system aspect), wherein the processing circuitry of the host computer may be configured to execute a host application, thereby providing the user data; and the processing circuitry of the UE may be configured to execute a client application associated with the host application.

In any aspect, by determining, at the wireless device, to switch the channel access mode between an LBT mode and a non-LBT mode, a more accurate decision as to whether or not an LBT process is performed at a wireless device can be enabled by at least some embodiments. Same or further embodiments can reduce a signaling overhead by reporting or requesting the determined channel access mode to a network node serving the wireless device, optionally without providing detailed measurement value underlying the determination at the wireless device.

At least some method embodiments of any method aspect can determine whether or not to perform the LBT process based on a Quality of Service (QoS) of the traffic on the wireless channel.

Without limitation, for example in a 3GPP implementation, any wireless device may be a radio device or a user equipment (UE). Any one of the method aspects may be embodied by a method of UE-triggered mode switching of an LBT operation, e.g., in unlicensed band.

The technique may be applied in the context of 3GPP New Radio (NR). Unlike an uplink (UL) and/or a sidelink (SL) according to 3GPP LTE, 3GPP NR can provide a wider range of QoS levels. Therefore, at least some embodiments of the technique can ensure that the wireless device appropriately determines the channel access mode.

The technique may be implemented in accordance with or by extending a 3GPP specification, e.g., at least one of the 3GPP document TS 38.331, version 16.4.1; the 3GPP document 38.213, version 16.5.0; the 3GPP document TS 36.331, version 16.4.0; the 3GPP document TS 36.331, version 16.4.0; the 3GPP document TS 38.300, version 16.5.0; the 3GPP document TS 36.300, version 16.5.0; the 3GPP document TS 38.314, version 16.3.0; and the 3GPP document TS 36.314, version 16.0.0.

Any wireless device (e.g., a radio device) may be a user equipment (UE), e.g., according to a 3GPP specification or a mobile station according to the standard family IEEE 802.il (Wi-Fi).

The wireless device and/or the other wireless device and/or the network node and/or the RAN may form, or may be part of, a wireless network (e.g., a radio network). The first method aspect and the second method aspect may be performed by one or more embodiments of the wireless device and the RAN (e.g., a network node such as a base station), respectively.

The RAN may comprise one or more network node (e.g., base stations) performing the second method aspect. Alternatively or in addition, the wireless network may be a vehicular, ad hoc and/or mesh network comprising two or more wireless devices, e.g., acting as a remote wireless device and the relay wireless device connected over a SL.

Any of the radio devices may be a 3GPP user equipment (UE) or a Wi-Fi station (STA). The radio device may be a mobile or portable station, a device for machine- type communication (MTC), a device for narrowband Internet of Things (NB-loT) or a combination thereof. Examples for the UE and the mobile station include a mobile phone, a tablet computer and a self-driving vehicle. Examples for the portable station include a laptop computer and a television set. Examples for the MTC device or the NB-loT device include robots, sensors and/or actuators, e.g., in manufacturing, automotive communication and home automation. The MTC device or the NB-loT device may be implemented in a manufacturing plant, household appliances and consumer electronics.

Whenever referring to the RAN, the RAN may be implemented by one or more network node (e.g., base stations).

The network node (e.g., a base station) may encompass any station that is configured to provide radio access to any of the wireless devices. The network node may also be referred to as a base station, a cell, a transmission and reception point (TRP), a radio access node or access point (AP). The base station and/or wireless device may provide a data link to a host computer providing the user data to the remote radio device or gathering user data from the remote radio device.

Examples for the network node (e.g., the base stations) may include a 3G base station or Node B, 4G base station or eNodeB, a 5G base station or gNodeB, a Wi-Fi AP and a network controller (e.g., according to Bluetooth, ZigBee or Z-Wave).

The RAN may be implemented according to the Global System for Mobile Communications (GSM), the Universal Mobile Telecommunications System (UMTS), 3GPP Long Term Evolution (LTE) and/or 3GPP New Radio (NR).

Any aspect of the technique may be implemented on a Physical Layer (PHY), a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, a packet data convergence protocol (PDCP) layer, and/or a Radio Resource Control (RRC) layer of a protocol stack for the radio communication.

Herein, referring to a protocol of a layer may also refer to the corresponding layer in the protocol stack. Vice versa, referring to a layer of the protocol stack may also refer to the corresponding protocol of the layer. Any protocol may be implemented by a corresponding method.

Any one of the devices, the UE, the network node (e.g., base station), the communication system or any node or station for embodying the technique may further include any feature disclosed in the context of the method aspect, and vice versa. Particularly, any one of the units and modules disclosed herein may be configured to perform or initiate one or more of the steps of the method aspect.

Brief Description of the Drawings

Further details of embodiments of the technique are described with reference to the enclosed drawings, wherein:

Fig. 1 shows a schematic block diagram of an embodiment of a device for switching between channel access modes for a transmission from a wireless device on a wireless channel; Fig. 2 shows a schematic block diagram of an embodiment of a device for serving a wireless device switching between channel access modes for a transmission from the wireless device on a wireless channel;

Fig. 3 shows a flowchart for a method of switching between channel access modes for a transmission from a wireless device on a wireless channel, which method may be implementable by the device of Fig. 1;

Fig. 4 shows a flowchart for a method for serving a wireless device switching between channel access modes for a transmission from the wireless device on a wireless channel, which method may be implementable by the device of Fig. 2;

Fig. 5 shows an example deployment scenario in a wireless network comprising embodiments for devices of Figs. 1 and 2 in wireless communication;

Fig. 6 schematically illustrates a physical resource grid of a 3GPP NR implementation;

Fig. 7 shows a schematic block diagram of a wireless device embodying the device of Fig. 1;

Fig. 8 shows a schematic block diagram of a network node embodying the device of Fig. 2;

Fig. 9 schematically illustrates an example telecommunication network connected via an intermediate network to a host computer;

Fig. 10 shows a generalized block diagram of a host computer communicating via a base station or radio device functioning as a gateway with a user equipment over a partially wireless connection; and

Figs. 11 and 12 show flowcharts for methods implemented in a communication system including a host computer, a base station or radio device functioning as a gateway and a user equipment. Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as a specific network environment in order to provide a thorough understanding of the technique disclosed herein. It will be apparent to one skilled in the art that the technique may be practiced in other embodiments that depart from these specific details. Moreover, while the following embodiments are primarily described for a New Radio (NR) or 5G implementation, it is readily apparent that the technique described herein may also be implemented for any other radio communication technique, including a Wireless Local Area Network (WLAN) implementation according to the standard family IEEE 802.11, 3GPP LTE (e.g., LTE-Advanced or a related radio access technique such as MulteFire), for Bluetooth according to the Bluetooth Special Interest Group (SIG), particularly Bluetooth Low Energy, Bluetooth Mesh Networking and Bluetooth broadcasting, for Z-Wave according to the Z-Wave Alliance or for ZigBee based on IEEE 802.15.4.

Moreover, those skilled in the art will appreciate that the functions, steps, units and modules explained herein may be implemented using software functioning in conjunction with a programmed microprocessor, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP) or a general purpose computer, e.g., including an Advanced RISC Machine (ARM). It will also be appreciated that, while the following embodiments are primarily described in context with methods and devices, the invention may also be embodied in a computer program product as well as in a system comprising at least one computer processor and memory coupled to the at least one processor, wherein the memory is encoded with one or more programs that may perform the functions and steps or implement the units and modules disclosed herein.

Fig. 1 schematically illustrates a block diagram of an embodiment of a device for switching between channel access modes for a transmission from a wireless device on a wireless channel. The device is generically referred to by reference sign 100.

The device 100 comprises a module 102 that determines, at the wireless device, to switch the channel access mode for the transmission from the wireless device on the wireless channel between the LBT mode and the non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode.

Optionally, the device 100 comprises a module 104 and/or 106 that performs the corresponding steps 304 and/or 306 of the first method aspect.

Any of the modules of the device 100 may be implemented by units configured to provide the corresponding functionality.

The device 100 may also be referred to as, or may be embodied by, the wireless device (or briefly: UE). The UE 100 and a network node serving the UE 100 may be in direct or indirect wireless (e.g., radio) communication, e.g., on the wireless channel. The network node may be embodied by the device 200.

Fig. 2 schematically illustrates a block diagram of an embodiment of a device for serving a wireless device switching between channel access modes for a transmission from the wireless device on a wireless channel. The device is generically referred to by reference sign 200.

The device 200 comprises a module 204 that receives a report from the wireless device at the network node serving the wireless device, the report being indicative of a channel access mode determined at the wireless device for the switching between the LBT mode and the non-LBT mode.

Optionally, the device 200 comprises a module 202 and/or 206 that performs the corresponding steps 402 and/or 406 of the second method aspect.

Any of the modules of the device 200 may be implemented by units configured to provide the corresponding functionality.

The device 200 may also be referred to as, or may be embodied by, the network node (or briefly: gNB). The gNB 200 and a wireless device served by gNB 200 may be in direct or indirect wireless (e.g., radio) communication, e.g., on the wireless channel. The wireless device may be embodied by the device 100.

Fig. 3 shows an example flowchart for a method 300 of switching between channel access modes for a transmission from a wireless device on a wireless channel. The channel access modes comprise a listen-before-talk (LBT) mode and a non-LBT mode. The method 300 comprises a step 302, and optionally steps 304 and 306, according to the first method aspect and/or as indicated in Fig. 3.

The method 300 may be performed by the device 100. For example, the modules 102, 104 and 106 may perform the steps 302, 304 and 306, respectively.

Fig. 4 shows an example flowchart for a method 400 of serving a wireless device switching between channel access modes for a transmission from the wireless device on a wireless channel. The channel access modes comprise a listen-before- talk (LBT) mode and a non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode.

The method comprises a step 404, and optionally steps 402 and 406, according to the second method aspect.

The method 400 may be performed by the device 200. For example, the modules 202, 204 and 206 may perform the steps 402, 404 and 406, respectively.

In any aspect, the technique may be applied to uplink (UL) or direct communications between radio devices, e.g., device-to-device (D2D) communications, i.e., a sidelink (SL) communications.

Each of the wireless device 100 and network node 200 may be a radio device and a base station, respectively. Herein, any wireless device (e.g., radio device) may be a mobile or portable station and/or any wireless device wirelessly connectable to a base station or RAN, or to another radio device. For example, the radio device may be a user equipment (UE), a device for machine-type communication (MTC) or a device for (e.g., narrowband) Internet of Things (loT). Two or more radio devices may be configured to wirelessly connect to each other, e.g., in an ad hoc radio network or via a 3GPP SL connection. Furthermore, any base station may be a station providing radio access, may be part of a radio access network (RAN) and/or may be a node connected to the RAN for controlling the radio access. For example, the base station may be an access point, for example a Wi-Fi access point. Herein, whenever referring to noise or a signal-to-noise ratio (SNR), a corresponding step, feature or effect is also disclosed for noise and/or interference or a signal-to-interference-and-noise ratio (SINR).

Fig. 5 shows an example deployment scenario 500 for a wireless communication, i.e., a wireless network 500. The deployment scenario comprises an embodiment of a network node 200 of a RAN with a coverage area 504, i.e., a cell 504. A wireless device 100 is in the coverage area 504 of the network node 200.

Optionally, another wireless device 520 is wireless connected with the wireless device 100 via a SL 522. The other wireless device 520 may function as a remote wireless device, and the wireless device 100 may function as a relay wireless device, since the remote wireless device is outside of the coverage area 504 of the network node 200, but in proximity to the wireless device 100.

In a first scenario, the wireless channel is an uplink 502 between the wireless device 100 and the network node 200. In a second scenario, which may be combinable with the first scenario, the wireless channel is a sidelink 522 between the wireless device 100 and the network node 200.

The wireless communication may be a radio communication, i.e., the wireless channel 502 or 522 and the wireless device 100 may be a radio channel and a radio device, respectively.

A hidden node 510, i.e., a node hidden from the perspective of the serving network node 200, may cause interference on the wireless channel 502 or 522, which may be measurable only at the wireless device 100.

Any embodiment may be implemented using a frame structure for the radio communication, e.g., according to 3GPP NR.

Similar to LTE, NR uses OFDM (Orthogonal Frequency Division Multiplexing) in the DL (e.g., from a network node, gNB, eNB, or base station, to a user equipment or UE).

Fig. 6 schematically illustrates an example of a physical resource grid 600 for a 3GPP NR implementation of the technique. The basic NR physical resource over an antenna port can be seen as a time- frequency grid as illustrated in Fig. 6, wherein a resource block (RB) 602 in a 14- symbol slot 608 is shown. A RB 602 corresponds to 12 contiguous subcarriers 604 in the frequency domain. RBs 602 are numbered in the frequency domain, starting with 0 from one end of the system bandwidth. Each resource element (RE) 606 corresponds to one OFDM subcarrier during one OFDM symbol 610 interval. A slot 608 comprises 14 OFDM symbols 610.

Different subcarrier spacing values are supported in NR. The supported subcarrier spacing values (also referred to as different numerologies) are given by Dί=(15^c2^m) kHz where m £ (0,1, 2, 3, 4). Dί=15 kHz is the basic (or reference) subcarrier spacing that is also used in LTE. Herein, the abbreviation SCS may not be confused with the subcarrier spacing.

In the time domain, DL and UL transmissions in NR are organized into equally- sized subframes of 1ms each similar to LTE. A subframe is further divided into multiple slots 608 of equal duration. The slot length for subcarrier spacing Dί=(15^c2^m) kHz is (1/2)^m ms. There is only one slot 608 per subframe for Af=15kHz, and a slot 608 consists of 14 OFDM symbols 610.

DL transmissions are dynamically scheduled, e.g., in each slot the gNB transmits DL control information (DCI) about which radio device (e.g., UE) data is to be transmitted to and which RBs in the current DL slot the data is transmitted on. This control information is conventionally transmitted in the first one or two OFDM symbols in each slot in NR. The control information is carried on the Physical Control Channel (PDCCH), and data is carried on the Physical Downlink Shared Channel (PDSCH). A radio device (e.g., a UE) first detects and decodes PDCCH and, if a PDCCH is decoded successfully, it (e.g., the UE) then decodes the corresponding PDSCH based on the DL assignment provided by decoded control information in the PDCCH.

In addition to PDCCH and PDSCH, there are also other channels and reference signals transmitted in the downlink, including synchronization signal blocks (SSBs), channel state information reference signals (CSI-RS), etc. UL data transmissions, carried on Physical Uplink Shared Channel (PUSCH), can also be dynamically scheduled by the gNB by transmitting a DCI. The DCI (which is transmitted in the DL region) indicates a scheduling time offset so that the PUSCH is transmitted in a slot in the UL region.

The wireless channel may be in mm-wave bands. Alternatively or in addition, the transmission 306 may use New Radio (NR) operation.

NR supports a diverse set of use cases and a diverse set of deployment scenarios. The later includes deployment at both low frequencies (100s of MHz), and very high frequencies (mm waves in the tens of GHz). Two operation frequency ranges are defined in NR Release 15: Frequency Range 1 (FR1) from 410 MHz to 7125 MHz, and FR2 from 24.250 GHz to 52.6 GHz. As captured in RP-210862, 3GPP RAN is currently working on a work item on Supporting NR above 52.6 GHz and leveraging FR2 design to the extent possible, e.g., including a work item that extends NR operation up to 71 GHz.

The wireless channel 502, 522 and the transmission 306 may relate to licensed and/or unlicensed operation, e.g. with the following objectives:

A first objective includes physical layer aspects, including at least one of:

- In addition to 120 kHz SCS, specify new SCS, 480 kHz and 960 kHz, and define maximum bandwidth(s), for operation in this frequency range for data and control channels and reference signals, only NCP supported.

Note: Except for timing line related aspects, a common design framework shall be adopted for 480 kHz to 960 kHz.

- Time line related aspects adapted to 480 kHz and 960 kHz, e.g., BWP and beam switching timing, HARQ timing, UE processing, preparation and computation timelines for PDSCH, PUSCH/SRS and CSI, respectively.

- Support of up to 64 SSB beams for licensed and unlicensed operation in this frequency range.

- Supports 120 kHz SCS for SSB and 120 kHz SCS for initial access related signals/channels in an initial bandwidth part (BWP).

Study and specify, if needed, additional SCS (240 kHz, 480 kHz, 960 kHz) for SSB, and additional SCS (480 kHz, 960 kHz) for initial access related signals and/or channels in an initial bandwidth part (BWP). Study and specify, if needed, additional SCS (480 kHz, 960 kHz) for SSB for cases other than initial access.

Note: coverage enhancement for SSB is not pursued.

- Specify timing associated with beam-based operation to new SCS (i.e.,

480 kHz and/or 960 kHz), study, and specify if needed, potential enhancement for shared spectrum operation.

Release 15 and/or 16 and any Release 17 beam management enhancements can be considered for 52.6-71 GHz. Whether particular features should be excluded for 52.6-71 GHz can be further discussed Note: As per usual procedure, duplication of work between work items in Release 17 should be avoided.

- Support enhancement for PUCCH format 0/1/4 to increase the number of RBs under PSD limitation in shared spectrum operation.

- Support enhancements for multi-PDSCH/PUSCH scheduling and HARQ support with a single DCI.

Note: coverage enhancement for multi-PDSCH/PUSCH scheduling is not pursued.

- Support enhancement to PDCCH monitoring, including blind detection/CCE budget, and multi-slot span monitoring, potential limitation to UE PDCCH configuration and capability related to PDCCH monitoring.

- Specify support for PRACH sequence lengths (i.e. L=139, L=571 and L=1151) and study, if needed, specify support for RO configuration for non-consecutive RACH occasions (RO) in time domain for operation in shared spectrum.

- Evaluate, and if needed, specify the PTRS enhancement for 120 kHz SCS, 480 kHz SCS and/or 960 kHz SCS, as well as DMRS enhancement for 480 kHz SCS and/or 960 kHz SCS.

A second objective includes one or more physical layer procedures, including at least one of:

- Channel access mechanism assuming beam-based operation in order to comply with the regulatory requirements applicable to unlicensed spectrum for frequencies between 52.6 GHz and 71 GHz.

- Specify both LBT and non-LBT (also referred to as no-LBT) related procedures, and for the non-LBT case no additional sensing mechanism is specified. - Study, and if needed specify, omni-directional LBT, directional LBT and receiver assistance in channel access.

- Study, and if needed specify, energy detection threshold enhancement.

A third objective includes Radio interface protocol architecture and procedures:

- For operation in this frequency range: Introduce higher layer support of enhancements listed above that are agreed to be specified.

A fourth objective includes one Core specifications for UE, gNB and RRM requirements:

- Specify new band(s) for the frequency range from 52.6GHz-71GHz. The band(s) definition should include UL/DL operation and excludes ITS spectrum in this frequency range.

- Specify gNB and UE RF core requirements for the band(s) in the above frequency range, including a limited set of example band combinations (see Note 1).

- Specify RRM/RLM/BM core requirements.

Note 1: The Wl can be completed provided requirements for at least one band combination involving a new NR-U band is specified as long as it is in line with country-specific regulatory directives.

Note 2: UEs supporting a band in the range of 52.6GHz-71GHz are not required to support 480kHz SCS and 960kHz SCS.

Note 3: The maximum FFT size required to operate the system in 52.6GHz- 71 GHz frequency is 4096, and the maximum of RBs per carrier is 275 RBs.

Note 4: the system is designed to support both single-carrier and multi carrier operation.

Note 5: RAN plenary will decide whether new FR (e.g. FR3) shall be defined for the frequency range from 52.6 GHz - 71GHz or the existing FR2 shall be extended to cover frequency range from 52.6 GHz - 71 GHz. - Similar to regular NR and NR-U operations below 52.6 GHz, NR and/or NR- U operation in the 52.6 GHz to 71 GHz can be in stand-alone or aggregated via CA or DC with an anchor carrier

The transmission 306 may use resources on the wireless channel 502 or 522 according to periodic and/or semi-persistent configurations.

In NR the gNB 200 can configure the UE 100 with a number of periodic configurations. A periodic configuration can cover either an UL transmission occasion or a DL reception occasion. Periodic UL transmissions may be triggered due to at least one of the below purposes:

1) scheduling request (SR),

2) periodic CSI reporting,

3) Sounding Reference Signal (SRS),

4) Configured Grant based transmission (e.g., based on either Type 1 CG configuration or Type 2 CG configuration), and

5) Random access (RACH).

An example of a periodic downlink configuration is the DRX configuration, which determines during which time occasions the UE should monitor PDCCH.

In common for these periodic configurations, there is an agreement between the gNB and UE on when a transmission is expected. The offset (to some common time reference, e.g. system frame number 0) is either RRC configured or a relation to a DCI activating the semi-persistent configuration. The periodicity is always RRC configured.

The transmission 306 may use resources on the wireless channel 502 or 522 resulting from a Scheduling Request.

In NR, the Scheduling Request (SR) is used for requesting UL-SCH resources for new transmission. A UE in connected mode may be configured with zero, one, or more SR configurations, with each SR configuration corresponding to one or multiple logical channels. An SR configuration consists of a set of PUCCH resources for SR across different BWPs and cells, also referred as SR resources in the standard. There is at most one SR resource assigned to a SR configuration in a BWP in a serving cell. An SR resource configuration includes a SR periodicity and time offset parameter ( periodicityAndOffset ) and a PUCCH resource ID. The SR periodicity and time offset parameter specifies the SR transmission occasions in time domain, and the PUCCH resource ID indicates which one of the PUCCH resources in the PUCCH configuration should be used for SR transmission.

The transmission 306 may comprise periodic or semi-persistent channel state information (CSI) reporting on PUCCH.

The UE 100 can be configured with up to 48 CSI report configurations. The CSI report configuration contains a CSI-ReportPeriodicityAndOffset field and a PUCCH resource ID. With the CSI-ReportPeriodicityAndOffset field, the UE tis allowed to be jointly configured with the periodicity and corresponding slot offset for a specific PUCCH resource.

The transmission 306 may be a beam-forming centric transmission, e.g., for NR operation in mm-wave frequency.

As the operating frequency of wireless networks 500 increases and moves to milli-meter wave territory, data transmission between nodes suffers from high propagation loss, which is proportional to the square of the carrier frequency. Moreover, milli-meter wave signal also suffers from high oxygen absorption, high penetration loss and a variety of blockage problems. On the other hand, with the wavelength as small as less than a centi-meter, it becomes possible to pack a large amount (tens, hundreds or even thousands) of antenna elements into a single antenna array with a compact formfactor, which can be widely adopted in a network equipment and a user device. Such antenna arrays/panels can generate narrow beams with high beam forming gai n to compensate for the high path loss in mm-wave communications, as well as providing highly directional transmission and reception pattern. As a consequence, directional transmission and reception are the distinguishing characteristics for wireless networks in mm- wave bands. In addition, a transmitter/receiver can typically only transmit/receive in one or perhaps a few directions at any given time.

The transmission 306 may rely on spatial relations for PUCCH.

3GPP NR has introduced in Release 15 the concept of PUCCH-SpatialRelationlnfo for PUCCH transmissions, which is used to inform the UE how to tune its transmitter antenna array. For PUCCH, the UE is configured with PUCCH- SpatialRelationlnfo relations to another signals. The other signals can either be an SS/PBCH block (SSB), a CSI-RS or an SRS as defined in the 3GPP document TS 38.213, version 16.5.0:

- If PUCCH-SpatialRelationlnfo provides ssb-lndex, the UE transmits the PUCCH using a same spatial domain filter as for a reception of a SS/PBCH block with index provided by ssb-lndex for a same serving cell or, if servingCellld is provided, for a serving cell indicated by servingCellld

- else if PUCCH-SpatialRelationlnfo provides csi-RS-lndex, the UE transmits the PUCCH using a same spatial domain filter as for a reception of a CSI-RS with resource index provided by csi-RS-lndex for a same serving cell or, if servingCellld is provided, for a serving cell indicated by servingCellld

- else PUCCH-SpatialRelationlnfo provides srs, the UE transmits the PUCCH using a same spatial domain filter as for a transmission of a SRS with resource index provided by resource for a same serving cell and/or active UL BWP or, if servingCellld and/or uplinkBWP are provided, for a serving cell indicated by servingCellld and/or for an UL BWP indicated by uplinkBWP

After configuring the UE with a list of spatial relations, the gNB activates one of them using a MAC control element (MAC CE). The update will typically come as a response to that the UE has reported a stronger received power for another reference signal than the one the current spatial relation is associated with. Thus, as the UE moves around in the cell, UE provides CSI report to the gNB, based on which the gNB will update the currently active spatial relation.

In Release 16, an Enhanced PUCCH Spatial Relation Activation/Deactivation MAC CE is introduced, which allows the gNB to update spatial relations for multiple PUCCH resources. Correspondingly, the space of Spatial Relation Info ID is extended from 8 to 64.

The enhanced PUCCH spatial relation Activation/Deactivation MAC CE may be structured as illustrated in below table or in Figure 6.1.3.25-1 of the 3GPP document TS 38.213, version 16.5.0. Oct 1

Oct 2

Oct 3

Oct 2N-2

Oct 2N-1

The transmission 306 may rely on spatial relations for PUSCH using Configured Grants (CGs).

Two types of Configured Grant (CG) UL transmission schemes have been supported in NR since Release 15, referred as CG Typel and CG Type2 in the standard. The major difference between these two types of CG transmission is that for CG Typel, an uplink grant is provided by RRC configuration and activated automatically, while in the case of CG Type2, the uplink grant is provided and activated via LI signaling, i.e., by an UL DCI with CRC scrambled by CS-RNTI. In both cases, the spatial relation used for PUSCH transmission with Configured Grant is indicated by the uplink grant, either provided by the RRC configuration or by an UL DCI. The uplink grant contains an srs-Resourcelndicator field, pointing to one of the SRS resources in the SRS resource configuration, which can be configured in-turn with a spatial relation to a DL RS (SSB or CSI-RS) or another SRS resource.

With the SRS resource indicator in the uplink grant and the RRC SRS resource configuration, PUSCH with Configured Grant is supposed to be transmitted with the same precoder or beamforming weights as the one used for the transmission of the reference SRS.

Alternatively or in addition, the transmission 306 may rely on spatial relations for PUSCH using dynamic grants.

For PUSCH transmission in NR, there are several possible configurations or modes, and when transmitting PUSCH in a beam management context, two PUSCH configuration options are include codebook-based transmission and non- codebook-based transmission.

It is also possible to use single-port transmission for PUSCH. In this case, DCI format 0_0 could be used, and the UE would use the same spatial relation for PUSCH as the PUCCH resource with the lowest ID. Ericsson is targeting to develop 2-port UL MIMO already in first products.

For codebook-based and non-codebook-based, the UE 100 would always transmit PUSCH using the same spatial properties, i.e. beam, as the transmission of an associated SRS resource. The spatial properties of the associated SRS are configured using the RRC parameter SpatialRelationlnfo.

For codebook-based transmission, the UE determines its PUSCH transmission precoder based on the SRI, precoder and layer indication (TPMI and rank, TRI) fields from the DCI. SRI is only needed when more than one SRS resource is in the SRS resource set used for codebook based transmission. In this case, SRI selects an SRS resource from one of two SRS resources in the set, and this resource is used to determine the precoder. Otherwise, the single SRS resource in the set is used to determine the precoder. If the SRS resource has a valid spatial relation (indicated or configured), the UE applies that spatial relation to determine the Tx beam for PUSCH. If the SRS resource does not have a valid (configured or indicated) spatial relation, the UE may transmit the SRS in any direction, and subsequent transmissions of PUSCH should use the SRS beam in the latest transmission.

If the PUSCH transmission precoder is based on an SRI pointing to an SRS resource that has not been transmitted and has no a valid spatial relation, the UE may choose the PUSCH transmission precoder freely.

For non-codebook based transmissions, the UE determines its PUSCH precoder and transmission rank based on selecting one or more SRS resources by the SRI field from the DCI. Each SRS resource has a single antenna port in this case, so the number of selected resources equals the transmission rank. Like for codebook- based transmissions, the SRI points to the latest transmission of the SRS resource with index SRI. Still, if the SRS resources are configured with spatial relations, the SRS resource can be indicated without a preceding transmission, since the UL Tx beam is determined by the spatial relation anyway. For non-codebook based transmission, the UE may be configured with a single SRS resource set, but with up to 4 SRS resources.

The spatial properties of the PUSCH transmission is controlled via the associated SRS resource; PUSCH beam management is thus equivalent to SRS beam management. There is one exception to this rule: for UL data scheduled using DCI format 0_0. Since there is no SRI field in DCI format 0_0, it has been decided that in this case, the PUSCH is transmitted using the same spatial relation as the PUCCH.

The configuration message for the initial channel access mode and/or the feedback message may be implemented according to a TCI state switch.

The UE 100 may be configured by the network node 200 with one active TCI (Transmission Configuration Indication) state for PDCCH (physical downlink control channel) and PDSCH (physical downlink shared channel), respectively. The active TCI indicates for each of the channels which timing reference the UE shall assume for the downlink reception. The timing reference may be with respect to an SSB index associated with a particular Tx beam, or with respect to a particular DL-RS (downlink reference signals, e.g. channel state information reference signals - CSI- RS) resource configured by the network node and provided (i.e. transmitted) to the UE.

Implicitly, the active TCI state additionally indicates to the UE which UE Rx beam to use when receiving PDCCH and/or PDSCH, since it shall use the Rx beam that allows best conditions for receiving the SSB index or DL-RS resource associated with the TCI state. Note that the best UE RX beam for a given TCI state may change over time, e.g. if the UE orientation changes, but also has to be relatively static at least over short time intervals.

Up to 8 TCI states can be configured for PDSCH via higher layer signaling (RRC signaling), but only one TCI state can be active at any time. In case several TCI states are configured by the network node, the network node indicates to the UE via DCI (downlink control signaling over PDCCH) which one of the pre-configured TCI states to activate for upcoming PDSCH reception(s). The TCI state can be switched by the UE based on received command via MAC, DCI or RRC messages etc. Upon receiving a TCI state command, the UE first sends HARQ feedback to the serving cell and switches active TCI state within certain delay.

The wireless channel may be PDCCH and/or PDSCH, e.g., using TCI states.

For PDCCH, the overall process of applying TCI for this case may comprise at least one of the following steps.

Step 1: A TCI State table called 'tci-StatesToAdd Mod List' is defined in PDSCH- Config. The max size of the table is 128.

Step 2: Select a subset of the tables from tci-StatesToAddModList and put them into ControlResourceSet.tci-StatesPDCCH-ToAddList. The max size of this table is 64.

Step 3: Apply a specific tci-States defined in Step 2 via TCI State Indication for UE- specific PDCCH MAC CE\

There are roughly two cases for configuring TCI-State on UE side.

In a case 1, the tci-PresentlnDCI is omitted or PDSCH is scheduled by DCI 1_0. In this case, UE uses the TCI state for CORESET/PDCCH as the TCI state for PDSCH. This may mean that the TCI state for PDSCH is the same as the TCI state for CORESET/PDCCH.

In a case 2, the tci-PresentlnDCI is enabled. In this case, UE uses the TCI indicated in DCI 1_1 following the below steps.

Step 1: A TCI State table called 'tci-StatesToAddModList' is defined in PDSCH- Config. The max size of the table is 128.

Step 2: Select a subset of the tables from tci-StatesToAddModList and put them into a smaller table 'codepoint'. This is done by the 'TCI States Activation/Deactivation for UE-specific PDSCH MAC CE'. The max size of this table is 8. Step 3: For each PDSCH scheduling, the TCI field (Transmission Configuration Indication) field in DCI 1_1 indicates a specific index of the table defined in Step 2.

Any embodiment may use the channel access mode (i.e., non-LBT versus LBT) in unlicensed bands from 52.6 GHz to 71GHz and/or according to at least one of the following agreements:

According to a first agreement, for regions where LBT is not mandated, the gNB 200 should indicate to the UE 100 this gNB-UE connection is operating in LBT mode or non-LBT mode. Alternatively or in addition, both cell specific (common for all UEs in a cell as part of system information or dedicated RRC signaling or both) and UE specific (can be different for different UEs in a cell as part of UE-specific RRC configuration) gNB indication may be supported.

According to a second agreement, contention exempt for Short Control Signaling (SCS) rules apply to the transmission of msgl for the 4-step RACH and MsgA for the 2-step RACH for all supported SCS. Optionally, note restriction for short control signaling transmissions apply (e.g., 10% over any 100ms intervals). Alternatively or in addition, the 10% over any 100ms interval restriction is applicable to all available msgl and/or MsgA resources configured (not limited to the resources actually used) in a cell. Alternatively or in addition, the 10% over any 100ms interval restriction is applicable to the msgl and/or MsgA transmission from one UE perspective.

Optionally, other UL signals and/or channels can be transmitted with Contention Exempt Short Control Signaling rule, such as msg3, SRS, PUCCH, PUSCH without user plain data, etc.

Based on the above agreements, it is observed that for regions where LBT is not mandated, the gNB 200 may signal to the UE as to the channel access mode, i.e., LBT mode or non-LBT mode, e.g., as the initial channel access mode. The signaling can be UE-specific. In other words, a UE 100 may apply non-LBT mode, while another UE may apply LBT mode. In addition, a UE may apply non-LBT mode for transmissions if they fulfil the SCS rules, i.e., the 10% over any 100ms interval restriction is met. Conventionally, there may occur at least one of the following potential issues.

According to a first potential issue, the gNB may not have up to date status information of a UE so that the gNB does not know the latest status of the UE. Therefore, the LBT mode that is signaled to the UE may be not suitable any more. In an example, the UE has been signaled to apply non-LBT mode, which was suitable for the UE at the beginning. However, the UE is now experiencing high interference from hidden nodes. This means that it would be better for the UE to switch to LBT mode operation. The gNB is not aware of the situation so that the gNB is not able to update the UE's LBT mode in time.

According to a second potential issue, the UE has applied non-LBT mode for UL transmissions which meet the SCS rules in regions where LBT is not mandated. After a while, the UE may experience high interface created by neighbor nodes, resulting that certain UL transmissions (e.g., Msgl for the 4-step RA, or MsgA for the 2-step RA) are not fulfilling the SCS rules any more. In this case, it would be better for the UE to switch to LBT mode operation for UL transmissions which may be categorized as SCS transmissions.

According to a third potential issue, in a region where LBT is not mandated, a UE may apply non-LBT operation while another UE may apply LBT operation. This may create unfairness issue especially in case both UEs are employing similar services/applications/traffic types. This may adversely affect UEs' QoS satisfaction. This means that fully relying configuration provided by the gNB may be not always feasible in terms of fairness between UEs and QoS satisfaction from the perspective of the UEs.

Embodiments can solve at least one of the potential issues.

According to one embedment, in regions where LBT is not mandated, a UE 100 is allowed to switch between LBT mode and non-LBT mode using the gNB 200 signaling and/or configuration as a baseline.

In one case, the UE 100 has been configured with non-LBT operation for UL transmissions 306 by the gNB. After a while, it is realized by the UE that non-LBT mode is not suitable any more so that the UE is allowed to apply the LBT mode. In one case, the UE 100 has been configured with LBT operation for UL transmissions 306 by the gNB 200. After a while, it is realized by the UE that LBT mode is not suitable any more so that the UE is allowed to apply the non-LBT mode.

In case the UE 100 has determined to change to a mode of LBT operation which is different from the one configured by the gNB 200, the gNB 200 replies with an acknowledgement upon reception of the request and/or report message indicating a mode switch from a UE 100.

The technique may be implemented as a mechanism applicable to unlicensed operations, e.g., licensed-assisted access (LAA) or eLAA or feLAA or MuLteFire,

NR unlicensed operation (NR-U), and/or in any unlicensed band (e.g., 5 GHz band, 6 GHz band or unlicensed band from 52.6 GHz to 71 GHz).

The term LBT process (or briefly LBT) may also interchangeably be called clear channel assessment (CCA), shared spectrum access procedure, etc. The wireless channel (e.g., a carrier) on which the LBT process is applied may belong to a shared spectrum or an unlicensed band or band with contention based access etc. The term "channel" or "subband" is used to stand for a bandwidth segment or a group of physical resource blocks (PRBs) of a carrier. The UE 100 may perform separate LBT operations in multiple wireless channels, e.g., in different channels or subbands. Both terms are applied interchangeably.

The terms LBT mode and LBT operation may be used interchangeably. Similarly, the terms non-LBT mode and non-LBT operation may be used interchangeably.

Below detailed embodiments are not restricted by any term. Any similar term is equally applicable here. The detailed embodiments may be implemented as disclosed or in combination with any embodiment in the list of embodiments.

In a first detailed embodiment, in regions where LBT is not mandated, a UE 100 is allowed to switch between LBT mode and non-LBT mode in the step 302 using the signaling of the gNB 200 (e.g., an activation message or a configuration) as a baseline (e.g., the initial channel access mode). In one case, the UE 100 has been configured with non-LBT operation as the initial channel access mode for UL transmissions 306 by the gNB 200. After a while, it is realized by the UE 100 according to the step 302 that non-LBT mode is not suitable any more so that the UE 100 is allowed to change to LBT mode, i.e., the UE 100 may apply LBT operation (i.e., perform the LBT process) prior to a UL transmission 306. The UE 100 only performs the UL transmission if the LBT operation indicates that the channel is idle.

In one case, the UE 100 has been configured with LBT operation for UL transmissions 306 by the gNB 200 as the initial channel access mode. After a while, it is realized by the UE 100 that LBT mode is not suitable any more so that the UE 100 is allowed to change to the non-LBT mode, i.e., the UE may skip LBT operation prior to the UL transmission 306.

In another case, the UE may only apply LBT operation prior to certain types of UL transmissions 306. The UE 100 may skip LBT operation prior to other types of UL transmissions. The UE 100 may perform actions according to configuration or signaling from the gNB 200, or pre-configuration captured in on or more technical specifications. Alternatively, how the UE 100 shall behave (e.g., apply LBT operation or skip LBT operation) may be captured (e.g., according to technical specifications) in a hard-coded fashion.

In the second detailed embodiment, the UE 100 considers at least one of the following conditions or events to determine whether the configured mode of the LBT operation (i.e., the current channel access mode) is suitable, i.e., whether the UE 100 shall change its LBT operation mode (i.e., change between non-LBT mode and LBT mode).

The determination 302 may depend on the services and/or applications and/or traffic types which are being employed by the UE 100.

E.g., for high priority services and/or applications and/or traffic types, it may be beneficial to skip LBT operation to reduce potential latency and signaling overhead due to LBT operations. Alternatively or in addition, for low priority services and/or applications and/or traffic types, it may be more suitable to apply LBT operation so that the UE may release resources to other services/applications/traffic types with high priority. The determination 302 may depend on QoS requirements of the services and/or applications and/or traffic types which are being employed by the UE 100.

E.g., for services and/or applications and/or traffic types with critical QoS requirements such as low latency, it may be beneficial to skip LBT operation to reduce potential latency and signaling overhead due to LBT operations. Alternatively or in addition, for services and/or applications and/or traffic types without critical QoS requirement, it may be more suitable to apply LBT operation so that the UE may release resources to other services/applications/traffic types with critical QoS requirements.

The determination 302 may depend on a data volume of or at the UE.

E.g., it may be more appropriate for the UE to skip LBT operation if the data volume is above a configured threshold so that the data transmission can be speeded up. Otherwise, if there is low data volume, it may be fine for the UE to apply LBT operation.

The determination 302 may depend on a measured system congestion or channel occupancy.

E.g., in low system congestion or channel occupancy, it may be better to skip LBT operation since the resources are sufficient for transmissions, therefore, collision between transmissions may unlikely occur. Alternatively or in addition, in high system congestion or channel occupancy, it may be better to apply LBT operation since resource utilization and spectrum efficiency can be improved with LBT operation.

The determination 302 may depend on the measured signal strength in terms of RSRP, RSRQ, RSSI, SINR, SIR etc. E.g., non-LBT operation is beneficial for the UE especially when there is low interference, low load or strong radio strength detected. In this case, there may be sufficient resources available for UEs to access the channel. Otherwise, when there is high interference, high load or weak radio strength detected, it is likely that the UE may experience collision when accessing the channel. In this case, it may be useful for the UE to apply LBT, based on which the UE performances transmissions only when the LBT indicates that the channel is idle.

The determination 302 may depend on a measured performance of DL receptions and/or UL transmissions, e.g., in terms of metrics such as packet delay, packet loss, packet error rate, jitter, or data rate, etc.

E.g., when the performance metrics indicate that the UE 100 has been experiencing good performance, meaning that the UE 100 is unlikely and/or seldom experiencing collision during transmissions 306 or receptions. In this case, the UE 100 is recommended to skip LBT operation according to the step 302. Otherwise, if the performance metrics indicate that the UE 100 has been experiencing bad performance, meaning that the UE is likely and/or often experiencing collision during transmissions 306 or receptions, the UE 100 is recommended to apply LBT operation to avoid potential collision during transmissions 306 (or receptions) according to the step 302.

The determination 302 may depend on occupied resources by transmissions 306 in frequency domain and/or time domain.

In an example, when the restriction for short control signaling transmissions (e.g., RACH messages , SRS , PUCCH PUSCH without user plain data) is not met (i.e., the control signaling, or transmissions have occupied more than 10% over any 100 ms intervals). In this case, the UE 100 shall apply LBT operation prior to any subsequent transmission 306 of those control signaling. When the restriction for short control signaling transmissions (e.g., RACH messages , SRS , PUCCH, PUSCH without user plain data) is met (i.e., the control signaling, or transmissions have occupied no higher than 10% over any 100 ms intervals), the UE 100 can skip LBT operation prior to any subsequent transmission 306 of those control signaling. It is notated that the UE 100 may check whether the restriction for short control signaling transmissions is met, from either one cell perspective or one UE perspective.

In an example, when the UE 100 has been occupying frequency resources more than X% of any Y PRBs for the transmissions. The UE shall apply LBT operation prior to any subsequent transmission. Otherwise, when the UE has been occupying frequency resources no more than X% of any Y PRBs for the transmissions, the UE can skip LBT operation prior to any subsequent transmission. X and Y can be configured or preconfigured to the UE. Alternatively, X and Y are captured in specs in hard coded fashion.

The determination 302 may depend on a location of the UE 100.

E.g., in case the UE is in a region where LBT is mandated, the UE 100 shall apply LBT operation prior to any transmission 306. In case the UE 100 has moved to a region where LBT is not mandated, the UE 100 may skip LBT operation prior to a transmission according to the step 302.

The determination 302 may depend on a battery life of the UE 100.

E.g., the remaining battery life of the UE 100 may affect whether the UE 100 shall apply or skip LBT operation. If the UE 100 has sufficient remaining battery life, the UE 100 may perform LBT operation prior to a transmission 306. If the U E 100 has low remaining battery life, the UE 100 may skip LBT operation prior to a transmission 306.

The determination 302 may depend on a power class or recently used transmission power of the UE 100

E.g., in case the power class of the UE 100 is high or the recent used transmission power is high, the UE 100 is more likely to create interference to surrounding nodes, it is safer for the UE to apply LBT operation prior to a transmission. In case the UE's power class is low or the recent used transmission power is low, the UE 100 is less likely to create interference to surrounding nodes, the UE 100 may skip LBT operation prior to a transmission. In a third detailed embodiment, in case the UE 100 has determined in the step 302 to change (e.g., switch) to a mode of LBT operation which is different from the one configured by the gNB 200 (i.e., the initial channel access mode), the UE 100 may apply at least one of the following options to handle the mode of the LBT operation (e.g., the channel access mode)

According to a first option, the UE 100 changes to the new mode (i.e., the determined channel access mode) immediately.

According to a second option, the UE 100 keeps using the old mode (i.e., the current channel access mode).

Meanwhile, the UE 100 also informs the gNB 200 of the mode switch, i.e., the determined channel access mode. The UE 100 performs further actions according to a feedback message from the gNB 200, e.g., gNB's acknowledgement or reply.

In a fourth detailed embodiment, in case the UE 100 has determined to change to a mode of LBT operation which is different from the one configured by the gNB 200, the UE 100 may signal the gNB 200 of the mode switch via at least one of the following signaling alternatives.

A first alternative uses RRC signaling, which may be an existing RRC signaling or a new RRC signaling.

A second alternative uses a MAC CE, i.e., signaling based on a MAC CE, which may be an existing MAC CE or a new MAC CE for indicating that the UE 100 prefers to apply a different mode, i.e., the determined channel access mode.

A third alternative uses a UE-initiates a RACH procedure.

A 4-step RA can be triggered to indicate the mode switch.

In an example, Msgl is used to identify the mode switch. A dedicated preamble or dedicated RACH occasions may be allocated to the UE for indicating the mode switch. The allocation may be pre-defined, determined based on a pre-defined rule, or configured by another node. In an example, Msg3 is extended to identify the mode switch. In Msg3, the UE MAC entity adds an indicator indicating the mode switch. The indicator may be a field in the MAC subheader or carried in a MAC CE.

A 2-step RA can be triggered to indicate the mode switch. A dedicated preamble or dedicated RACH occasions or dedicated PUSCH occasions/resources may be allocated to the UE for indicating the mode switch. Alternatively, indicators indicating the mode switch can be included in MsgA payload. The indicator may be a field in the MAC subheader or carried in a MAC CE.

Alternatively, an RRC message (partly or fully) may be included in a RACH message, which includes indicators of the mode switch.

According to a fourth alternative, the UE 100 initiates a PUCCH transmission for indicating (i.e., reporting or requesting) the mode switch. For indicating the mode switch, separate dedicated PUCCH resources may be configured accordingly.

According to a fifth alternative, the UE 100 initiates a configured grant-based transmission for indicating the mode switch. For indicating the mode switch, separate dedicated configured grant resources may be configured accordingly. Alternatively, indicators for indicating the mode switch request may be included in the CG-UCI.

According to a sixth alternative, the UE 100 initiates an SRS transmission for indicating the mode switch. For indicating the mode switch, separate dedicated SRS resources may be configured accordingly.

Specifically, e.g., as an additional example of the fourth alternative and the fifth alternative, the UE 100 can indicate a mode switch 302 (i.e., the determined channel access mode) in the PUCCH-UCI which can be carried in the PUCCH or multiplexed with PUSCH.

In any embodiment or example, the UCI containing mode switch (i.e., the report or the request) may have a priority defined in the form of, e.g., a. PHY priority, or b. Implicit priority which can be a. Higher or lower than SR, b. Higher or lower than HARQ-ACK. c. Higher or lower than CSI.

In one example, for the resources used for the mode switch, the resources are configured via RRC. In another example, the resources are signaled using a MAC CE or a DCI.

In a fifth detailed embodiment, which may be combined with any other detailed embodiment, the mode switch message (i.e., the report or the request) indicates at least one of example information.

A first example information comprises one or more mode switch reasons (e.g., the conditions or events as listed in the second detailed embodiment).

A second example information is indicative of the new mode (i.e., the determined channel access mode) which is preferred by the UE 100, such as non-LBT or LBT.

A third example information is indicative of old mode (e.g., the current channel access mode).

The above information may be transmitted using a single or multiple messages.

In addition, at least one of below listed additional information may be also included in one or multiple requests and/or reports (e.g., reported for a measurement object, a carrier, for a group of carriers, for a certain PLMN, for a cell, per PCI, per BWP, per beam/SSB, per BWP, etc.):

- Channel occupancy, e.g., based on RSSI.

- LBT statistics e.g. number of LBT failures and/or successes, LBT failure/success ratio (e.g. calculated over a certain time period or using exponential averaging of successive time periods), LBT failure rate (e.g. calculated over a certain time period or using exponential averaging of successive time periods). Either of these could be reported per UL/DL, or per service/LCH/LCG.

- Radio quality indicators, such as RSRP, RSRQ, RSSI, SNR, SINR...

- Service QoS indicators such as latency, packet loss, priority, jitter, etc.

- Buffer status report. - Power headroom report.

- The indices for cells/BWPs/carriers/channels/sub-bands/PLMNs that the UE has applied the old mode.

- The index for the beams/SSBs that the UE has applied the old mode.

- The indices for cells/BWPs/carriers/channels/sub-bands/PLMNs that the UE prefers to apply the new mode.

- The index for the beams/SSBs that the UE prefers to apply the new mode.

For any above report message, it may be transmitted in the same Public Land Mobile Network (PLMN) and/or carrier and/or cell and/or BWP and/or channel and/or subband in which the old mode (e.g., the current channel access mode) is being triggered or in a different PLMN/carrier/cell/BWP/channel/subband. The report message may be also transmitted on a different beam and/or SSB.

In a sixth detailed embodiment, the gNB 100 replies with a feedback message (e.g., an acknowledgement) upon reception of the request and/or report indicating a mode switch (i.e., the determined channel access mode) from a UE 100. The feedback message (e.g., the acknowledgement) may be indicated via at least one of the below signaling means:

1) a DCI addressed to the C-RNTI associated with the UE,

2) an RRC signaling message, and

3) a MAC CE.

The gNB 200 may also provide further signaling to the UE 100, e.g., including at least one of the following:

1) Agree (i.e., acknowledgment) with the new mode (i.e., the determined channel access mode) that the UE 100 has chosen in the step 302.

2) Sisagree with (i.e., rejection of) the new mode that the UE has chosen, so that the UE has to continue using the old mode.

3) Switch/change to other PLMNs/carriers/cells/BWPs/channels/subbands.

4) Switch/change to other beams/SSBs.

In a seventh detailed embodiment, which may be combined with any other embodiment , the mode of LBT operation (i.e., non-LBT or LBT) may be applied and/or configured and/or preconfigured per service and/or application and/or traffic type and/or type of transmissions (e.g., control signaling or data, or which type of control signaling/data). For data transmissions, different mode may be configured/applied to different services/traffic types represented by different IDs/indices (e.g., 5Qls, flow ID, bearer ID, LCH ID, LCG ID, LCH priority or other indicators). The mode of LBT operation (i.e., non-LBT or LBT) may be applied/configured/preconfigured per beam and/or SSB and/or beam group and/or SSB group and/or BWP and/or cell and/or carrier and/or cell group.

In an eighth detailed embodiment, which may be combined with any one of the above embodiments, the UE 100 may perform actions according to configuration or signaling from the gNB 200, or pre-configuration captured in technical specifications. Alternatively, how the UE 100 determines 302 (e.g., apply LBT operation or skip LBT operation) may be implemented in a hard-coded fashion.

Fig. 7 shows a schematic block diagram for an embodiment of the device 100. The device 100 comprises processing circuitry, e.g., one or more processors 704 for performing the method 300 and memory 706 coupled to the processors 704. For example, the memory 706 may be encoded with instructions that implement at least one of the modules 102, 104 and 106.

The one or more processors 704 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and/or encoded logic operable to provide, either alone or in conjunction with other components of the device 100, such as the memory 706,

UE functionality. For example, the one or more processors 704 may execute instructions stored in the memory 706. Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein. The expression "the device being operative to perform an action" may denote the device 100 being configured to perform the action.

As schematically illustrated in Fig. 7, the device 100 may be embodied by a wireless device 700, e.g., functioning as a UE. The wireless device 700 comprises a radio interface 702 coupled to the device 100 for radio communication with one or more network node 200 or other wireless devices. Fig. 8 shows a schematic block diagram for an embodiment of the device 200. The device 200 comprises processing circuitry, e.g., one or more processors 804 for performing the method 400 and memory 806 coupled to the processors 804. For example, the memory 806 may be encoded with instructions that implement at least one of the modules 202, 204 and 206.

The one or more processors 804 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and/or encoded logic operable to provide, either alone or in conjunction with other components of the device 200, such as the memory 806, network node functionality. For example, the one or more processors 804 may execute instructions stored in the memory 806. Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein. The expression "the device being operative to perform an action" may denote the device 200 being configured to perform the action.

As schematically illustrated in Fig. 8, the device 200 may be embodied by a network node 800, e.g., functioning as a gNB. The network node 800 comprises a radio interface 802 coupled to the device 200 for radio communication with one or more wireless devices, e.g., functioning as a UEs.

With reference to Fig. 9, in accordance with an embodiment, a communication system 900 includes a telecommunication network 910, such as a 3GPP-type cellular network, which comprises an access network 911, such as a radio access network, and a core network 914. The access network 911 comprises a plurality of base stations 912a, 912b, 912c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 913a, 913b, 913c. Each base station 912a, 912b, 912c is connectable to the core network 914 over a wired or wireless connection 915. A first user equipment (UE) 991 located in coverage area 913c is configured to wirelessly connect to, or be paged by, the corresponding base station 912c. A second UE 992 in coverage area 913a is wirelessly connectable to the corresponding base station 912a. While a plurality of UEs 991, 992 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 912. Any of the base stations 912 and the UEs 991, 992 may embody the device 200 and/or 100.

The telecommunication network 910 is itself connected to a host computer 930, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 930 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 921, 922 between the telecommunication network 910 and the host computer 930 may extend directly from the core network 914 to the host computer 930 or may go via an optional intermediate network 920. The intermediate network 920 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 920, if any, may be a backbone network or the Internet; in particular, the intermediate network 920 may comprise two or more sub-networks (not shown).

The communication system 900 of Fig. 9 as a whole enables connectivity between one of the connected UEs 991, 992 and the host computer 930. The connectivity may be described as an over-the-top (OTT) connection 950. The host computer 930 and the connected UEs 991, 992 are configured to communicate data and/or signaling via the OTT connection 950, using the access network 911, the core network 914, any intermediate network 920 and possible further infrastructure (not shown) as intermediaries. The OTT connection 950 may be transparent in the sense that the participating communication devices through which the OTT connection 950 passes are unaware of routing of uplink and downlink communications. For example, a base station 912 need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 930 to be forwarded (e.g., handed over) to a connected UE 991. Similarly, the base station 912 need not be aware of the future routing of an outgoing uplink communication originating from the UE 991 towards the host computer 930.

By virtue of the method 300 being performed by any one of the UEs 991 or 992 and/or the method 400 by any one of the base stations 912 (i.e., network nodes), the performance or range of the OTT connection 950 can be improved, e.g., in terms of increased throughput and/or reduced latency. More specifically, the host computer 930 may indicate to the RAN 500 or the network node 200 or the wireless device 100 (e.g., UE), e.g., on an application layer, a criterion that triggers or influences the determination 302, e.g., the QoS of the traffic.

Example implementations, in accordance with an embodiment of the UE, base station and host computer discussed in the preceding paragraphs, will now be described with reference to Fig. 10. In a communication system 1000, a host computer 1010 comprises hardware 1015 including a communication interface 1016 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 1000. The host computer 1010 further comprises processing circuitry 1018, which may have storage and/or processing capabilities. In particular, the processing circuitry 1018 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 1010 further comprises software 1011, which is stored in or accessible by the host computer 1010 and executable by the processing circuitry 1018. The software 1011 includes a host application 1012. The host application 1012 may be operable to provide a service to a remote user, such as a UE 1030 connecting via an OTT connection 1050 terminating at the UE 1030 and the host computer 1010. In providing the service to the remote user, the host application 1012 may provide user data, which is transmitted using the OTT connection 1050. The user data may depend on the location of the UE 1030. The user data may comprise auxiliary information or precision advertisements (also: ads) delivered to the UE 1030. The location may be reported by the UE 1030 to the host computer, e.g., using the OTT connection 1050, and/or by the base station 1020, e.g., using a connection 1060.

The communication system 1000 further includes a base station 1020 provided in a telecommunication system and comprising hardware 1025 enabling it to communicate with the host computer 1010 and with the UE 1030. The hardware 1025 may include a communication interface 1026 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 1000, as well as a radio interface 1027 for setting up and maintaining at least a wireless connection 1070 with a UE 1030 located in a coverage area (not shown in Fig. 10) served by the base station 1020. The communication interface 1026 may be configured to facilitate a connection 1060 to the host computer 1010. The connection 1060 may be direct, or it may pass through a core network (not shown in Fig. 10) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 1025 of the base station 1020 further includes processing circuitry 1028, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 1020 further has software 1021 stored internally or accessible via an external connection.

The communication system 1000 further includes the UE 1030 already referred to. Its hardware 1035 may include a radio interface 1037 configured to set up and maintain a wireless connection 1070 with a base station serving a coverage area in which the UE 1030 is currently located. The hardware 1035 of the UE 1030 further includes processing circuitry 1038, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 1030 further comprises software 1031, which is stored in or accessible by the UE 1030 and executable by the processing circuitry 1038. The software 1031 includes a client application 1032. The client application 1032 may be operable to provide a service to a human or non-human user via the UE 1030, with the support of the host computer 1010. In the host computer 1010, an executing host application 1012 may communicate with the executing client application 1032 via the OTT connection 1050 terminating at the UE 1030 and the host computer 1010. In providing the service to the user, the client application 1032 may receive request data from the host application 1012 and provide user data in response to the request data. The OTT connection 1050 may transfer both the request data and the user data. The client application 1032 may interact with the user to generate the user data that it provides.

It is noted that the host computer 1010, base station 1020 and UE 1030 illustrated in Fig. 10 may be identical to the host computer 930, one of the base stations 912a, 912b, 912c and one of the UEs 991, 992 of Fig. 9, respectively. This is to say, the inner workings of these entities may be as shown in Fig. 10, and, independently, the surrounding network topology may be that of Fig. 9.

In Fig. 10, the OTT connection 1050 has been drawn abstractly to illustrate the communication between the host computer 1010 and the UE 1030 via the base station 1020, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 1030 or from the service provider operating the host computer 1010, or both. While the OTT connection 1050 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

The wireless connection 1070 between the UE 1030 and the base station 1020 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 1030 using the OTT connection 1050, in which the wireless connection 1070 forms the last segment. More precisely, the teachings of these embodiments may reduce the latency and improve the data rate and thereby provide benefits such as better responsiveness and improved QoS.

A measurement procedure may be provided for the purpose of monitoring data rate, latency, QoS and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1050 between the host computer 1010 and UE 1030, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 1050 may be implemented in the software 1011 of the host computer 1010 or in the software 1031 of the UE 1030, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 1050 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 1011, 1031 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1050 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 1020, and it may be unknown or imperceptible to the base station 1020. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer's 1010 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 1011, 1031 causes messages to be transmitted, in particular empty or "dummy" messages, using the OTT connection 1050 while it monitors propagation times, errors etc.

Fig. 11 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 9 and 10. For simplicity of the present disclosure, only drawing references to Fig. 11 will be included in this paragraph. In a first step 1110 of the method, the host computer provides user data. In an optional substep 1111 of the first step 1110, the host computer provides the user data by executing a host application. In a second step 1120, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 1130, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 1140, the UE executes a client application associated with the host application executed by the host computer.

Fig. 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 9 and 10. For simplicity of the present disclosure, only drawing references to Fig. 12 will be included in this paragraph. In a first step 1210 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In a second step 1220, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 1230, the UE receives the user data carried in the transmission.

As has become apparent from above description, at least some embodiments of the technique enable a UE to express or assist the gNB with its preference on mode of LBT operation. Same or further embodiment enable the UE to provide assistance information to the gNB so that the gNB makes proper configuration on LBT operation mode. Same or further embodiment can achieve a more efficient combination of control by the gNB and the assistance from the UE. Many advantages of the present invention will be fully understood from the foregoing description, and it will be apparent that various changes may be made in the form, construction and arrangement of the units and devices without departing from the scope of the invention and/or without sacrificing all of its advantages. Since the invention can be varied in many ways, it will be recognized that the invention should be limited only by the scope of the following claims.

Claims

Claims

1. A method (300) of switching between channel access modes for a transmission (306) from a wireless device (100; 700; 991; 992; 1030) on a wireless channel (502; 522), wherein the channel access modes comprise a listen-before- talk, LBT, mode and a non-LBT mode, the method (300) comprising or initiating the step of: determining (302), at the wireless device (100; 700; 991; 992; 1030), to switch the channel access mode for the transmission (306) from the wireless device (100; 700; 991; 992; 1030) on the wireless channel (502; 522) between the LBT mode and the non-LBT mode, the transmission (306) being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode.

2. The method (300) of claim 1, further comprising or initiating the step of: receiving a configuration message from a network node (200; 800; 912;

1020) serving the wireless device (100; 700; 991; 992; 1030), the configuration message being indicative of the LBT mode or the non-LBT mode as an initial channel access mode.

3. The method (300) of claim 2, wherein the determined channel access mode is different from the initial channel access mode.

4. The method (300) of any one of claims 1 to 3, further comprising or initiating at least one of the steps of: transmitting a report from the wireless device (100; 700; 991; 992; 1030) to a network node (200; 800; 912; 1020) serving the wireless device (100; 700; 991; 992; 1030), the report being indicative of the determined channel access mode; and receiving a feedback message from a network node (200; 800; 912; 1020) serving the wireless device (100; 700; 991; 992; 1030), the feedback message being indicative of an acknowledgment or a rejection of the determined channel access mode.

5. The method (300) of any one of claims 1 to 4, wherein the wireless device switches to the determined (302) channel access mode without a report of the determined channel access mode to and/or without an acknowledgment of the determined channel access mode from a network node (200; 800; 912; 1020) serving the wireless device (100; 700; 991; 992; 1030).

6. The method (300) of any one of claims 1 to 4, further comprising or initiating the step of: transmitting a request from the wireless device (100; 700; 991; 992; 1030) to a network node (200; 800; 912; 1020) serving the wireless device (100; 700;

991; 992; 1030), the request being indicative of the determined channel access mode, wherein the wireless device (100; 700; 991; 992; 1030) switches to the determined (302) channel access mode responsive to a feedback message received from the network node (200; 800; 912; 1020) in response to the transmitted request and indicative of an acknowledgment of the determined channel access mode, and/or wherein the wireless device (100; 700; 991; 992; 1030) refrains from switching to the determined (302) channel access mode responsive to a feedback message received from the network node (200; 800; 912; 1020) in response to the transmitted request and indicative of a rejection of the determined channel access mode.

7. The method (300) of any one of claims 4 to 6, wherein at least one of the report and the request uses or is comprised in or is indicated by at least one of: a message on a physical uplink shared channel, PUSCH, optionally without user plane data; a medium access control, MAC, control element, CE; a radio resource control, RRC, signaling; a message on a random access channel, RACH, optionally a random access preamble, RAP, or Message 1 or Message A of a random access procedure or a Message 3 of a random access procedure; a message on a physical uplink control channel, PUCCH, or an uplink control information, UCI; and a sounding reference signal, SRS.

8. The method (300) of any one of claims 4 to 7, wherein at least one of the report and the request is further indicative of a reason for the switching of the channel access mode.

9. The method (300) of any one of claims 1 to 8, wherein the channel access mode is determined (302) based on one or more conditions measured at the wireless device (100; 700; 991; 992; 1030) and/or one or more events at the wireless device (100; 700; 991; 992; 1030).

10. The method (300) of any one of claims 2 to 9, wherein at least one of the configuration message and the feedback message uses or is comprised in or is indicated by at least one of: a message on a physical downlink shared channel, PDSCH, optionally without user plane data; a MAC CE; an RRC signaling; and a message on a physical downlink control channel, PDCCH, or a downlink control information, DCI, optionally addressed to a cell radio network temporary identifier, C-RNTI of the wireless device (100; 700; 991; 992; 1030).

11. The method (300) of any one of claims 1 to 10, further comprising or initiating the step of: selectively (304) performing the LBT process at the wireless device (100;

700; 991; 992; 1030) on the wireless channel (502; 522) according to the determined (302) channel access mode.

12. The method (300) of any one of claims 1 to 11, further comprising or initiating the step of: transmitting (306) from the wireless device (100; 700; 991; 992; 1030) on the wireless channel (502; 522), wherein the transmission (306) is selectively subject to the LBT process according to the determined (302) channel access mode.

13. The method (300) of any one of claims 1 to 12, wherein the wireless channel (502; 522) is on an uplink, UL, between the wireless device (100; 700; 991; 992; 1030) and a network node (200; 800; 912; 1020), or wherein a message is transmitted (306) from the wireless device (100; 700; 991; 992; 1030) on the wireless channel (502; 522) to a network node (200; 800; 912; 1020) using an UL.

14. The method (300) of any one of claims 1 to 13, wherein the wireless channel (502; 522) is on a sidelink, SL, between the wireless device (100; 700; 991; 992; 1030) and another wireless device (520), or wherein a message is transmitted (306) from the wireless device (100; 700; 991; 992; 1030) on the wireless channel (502; 522) to another wireless device (520) using a SL.

15. The method (300) of any one of claims 1 to 14, wherein at least one of: the transmission (306) comprises transmitting data; the wireless channel (502; 522) comprises a physical uplink shared channel, PUSCH; the wireless channel (502; 522) comprises a physical sidelink shared channel, PSSCH; the transmission (306) comprises transmitting control signaling; the wireless channel (502; 522) comprises a physical uplink control channel, PUCCH; and the wireless channel (502; 522) comprises a physical sidelink control channel, PSCCH.

16. The method (300) of any one of claims 1 to 15, wherein the wireless channel (502; 522) is within a region that does not require performing the LBT process for the transmission (306) on the wireless channel (502; 522).

17. The method (300) of claim 16, wherein the region comprises a spatial area.

18. The method (300) of claim 16 or 17, wherein the region comprises a frequency range.

19. The method (300) of any one of claims 1 to 18, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode when measuring interference on the wireless channel (502; 522) at the wireless device (100; 700; 991; 992; 1030).

20. The method (300) of any one of claims 1 to 19, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch the channel access mode depending on at least one of: a type of the transmission (306); a type of a service or application underlying the transmission (306); and a type of the data or traffic to be transmitted (306); a Quality of Service, QoS, or a 5G QoS Identifier, 5QI, associated with the transmission (306); and a flow, a flow identifier, a QoS flow, a QoS flow identifier, a protocol data unit, PDU, session, a PDU session identifier, a bearer, a bearer identifier, a logical channel, LCH, a LCH identifier, a logical channel group, LCG, a LCG identifier, a LCH priority, or a LCG priority associated with the transmission (306).

21. The method (300) of any one of claims 1 to 20, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode if the transmission (306) is associated with a transmission reliability greater than a predefined reliability threshold value.

22. The method (300) of any one of claims 1 to 21, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the non-LBT mode if the transmission (306) is associated with a required data rate greater than a predefined data rate threshold value or a required latency less than a predefined latency threshold value.

23. The method (300) of any one of claims 1 to 22, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the non-LBT mode if a priority associated with the transmission (306) is greater than a predefined first priority threshold value, and/or wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode if a priority associated with the transmission (306) is less than the predefined first priority threshold value or a predefined second priority threshold value less than the predefined first priority threshold value.

24. The method (300) of any one of claims 1 to 23, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the non-LBT mode if a quality of service, QoS, associated with the transmission (306) is greater than a predefined first QoS threshold value, and/or wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode if a QoS associated with the transmission (306) is less than the predefined first QoS threshold value or a predefined second QoS threshold value less than the predefined first QoS threshold value.

25. The method (300) of any one of claims 1 to 24, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the non-LBT mode if a volume of data pending for the transmission (306) is greater than a predefined first data volume threshold value, and/or wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode if a volume of data pending for the transmission (306) is less than the predefined first data volume threshold value or a predefined second data volume threshold value less than the predefined first data volume threshold value.

26. The method (300) of any one of claims 1 to 25, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the non-LBT mode if a measured congestion of a system using the wireless channel (502; 522) or a measured occupancy of the wireless channel (502; 522) is greater than a predefined first congestion threshold value, and/or wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode if a measured congestion of a system using the wireless channel (502; 522) or a measured occupancy of the wireless channel (502; 522) is less than the predefined first congestion threshold value or a predefined second congestion threshold value less than the predefined first congestion threshold value.

27. The method (300) of any one of claims 1 to 26, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode if a measured interference (512) on the wireless channel (502; 522) is greater than a predefined first interference threshold value, and/or wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the non-LBT mode if a measured interference (512) on the wireless channel (502; 522) is less than the predefined first interference threshold value or a predefined second interference threshold value less than the predefined first interference threshold value.

28. The method (300) of any one of claims 1 to 27, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the non-LBT mode if a measured signal strength on the wireless channel (502; 522) is greater than a predefined first signal strength threshold value, and/or wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode if a measured signal strength on the wireless channel (502; 522) is less than the predefined first signal strength threshold value or a predefined second signal strength threshold value less than the predefined first signal strength threshold value.

29. The method (300) of any one of claims 1 to 28, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the non-LBT mode if a performance metric in terms of packets on the wireless channel (502; 522) is greater than a predefined first performance metric threshold value, and/or wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode if a performance metric in terms of packets on the wireless channel (502; 522) is less than the predefined first performance metric threshold value or a predefined second performance metric threshold value less than the predefined first performance metric threshold value.

30. The method (300) of any one of claims 1 to 29, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the non-LBT mode if a requirement for short control signal, SCS, exemption on the wireless channel (502; 522) is fulfilled, and/or wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode if a requirement for SCS exemption on the wireless channel (502; 522) is not fulfilled.

31. The method (300) of claim 30, wherein the SCS exemption requires the transmission (306) of at least one of: a message on a RACH or a RAP; an SRS; a message on a PUCCH or a UCI; a message on a physical sidelink control channel, PSCCH, or a sidelink control information, SCI; and a message on a PUSCH without user plane data or a MAC CE or an RRC signaling.

32. The method (300) of claim 30 or 31, wherein the SCS exemption requires an amount or a share of resources occupied by the wireless device (100; 700; 991;

992; 1030) on the wireless channel (502; 522) to be less than an occupancy threshold value.

33. The method (300) of any one of claims 30 to 32, wherein the SCS exemption requires the share of resources occupied by the wireless device (100; 700; 991;

992; 1030) on the wireless channel (502; 522) to be less than 10% over intervals of 100 ms.

34. The method (300) of any one of claims 30 to 33, wherein the SCS exemption requires that the wireless device (100; 700; 991; 992; 1030) has occupied on the wireless channel (502; 522) no more than a predefined share of the resources in the frequency domain over sequences of a predefined number of consecutive physical resource blocks, PRBs.

35. The method (300) of any one of claims 30 to 34, wherein wireless device (100; 700; 991; 992; 1030) determines that the requirement for the SCS exemption is fulfilled at the wireless device (100; 700; 991; 992; 1030) and/or at a network node (200; 800; 912; 1020) serving the wireless device (100; 700; 991; 992; 1030).

36. The method (300) of any one of claims 1 to 35, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the non-LBT mode if the wireless device (100; 700; 991; 992; 1030) is located in or moves to a region that does not require performing the LBT process for the transmission (306) on the wireless channel (502; 522), and/or wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode if the wireless device (100; 700; 991; 992; 1030) is located in or moves to a region that requires performing the LBT process for the transmission (306) on the wireless channel (502; 522).

37. The method (300) of any one of claims 1 to 36, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode if a state of charge of a battery of the wireless device (100; 700; 991; 992; 1030) is greater than a predefined first charge threshold value, and/or wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the non-LBT mode if a state of charge of a battery of the wireless device (100; 700; 991; 992; 1030) is less than the predefined first charge threshold value or a predefined second charge threshold value less than the predefined first charge threshold value.

38. The method (300) of any one of claims 1 to 37, wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the LBT mode if a transmission power class of the wireless device (100; 700; 991; 992; 1030) for the transmission (306) or recent transmissions on the wireless channel (502; 522) is greater than a predefined first power class threshold value, and/or wherein the wireless device (100; 700; 991; 992; 1030) determines to switch to the non-LBT mode if a transmission power class of the wireless device (100; 700; 991; 992; 1030) for the transmission (306) or recent transmissions on the wireless channel (502; 522) is less than the predefined first power class threshold value or a predefined second power class threshold value less than the predefined first power class threshold value.

39. The method (300) of any one of claims 1 to 38, wherein the channel access mode is at least one of determined (302), switched, applied, reported and requested per beam or per synchronization signal block, SSB, or per bandwidth part, BWP, or per cell (504) or per cell group or per carrier.

40. The method (300) of any one of claims 1 to 39, wherein the method (300) is performed by the wireless device (100; 700; 991; 992; 1030).

41. A method (400) of serving a wireless device (100; 700; 991; 992; 1030) switching between channel access modes for a transmission from the wireless device (100; 700; 991; 992; 1030) on a wireless channel (502; 522), wherein the channel access modes comprise a listen-before-talk, LBT, mode and a non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode, the method (400) comprising or initiating the step of: receiving (404) a report from the wireless device (100; 700; 991; 992; 1030) at a network node (200; 800; 912; 1020) serving the wireless device (100; 700;

991; 992; 1030), the report being indicative of a channel access mode determined at the wireless device (100; 700; 991; 992; 1030) for the switching between the LBT mode and the non-LBT mode.

42. The method (400) of claim 41, further comprising or initiating the step of: transmitting (402) a configuration message from the network node (200;

800; 912; 1020) to the wireless device (100; 700; 991; 992; 1030), the configuration message being indicative of the LBT mode or the non-LBT mode as an initial channel access mode.

43. The method (400) of claim 42, wherein the determined channel access mode is different from the initial channel access mode.

44. The method (400) of any one of claims 41 to 43, further comprising or initiating the step of: transmitting (406) a feedback message from the network node (200; 800; 912; 1020) to the wireless device (100; 700; 991; 992; 1030), the feedback message being indicative of an acknowledgment or a rejection of the determined channel access mode.

45. The method (400) of any one of claims 41 to 44, further comprising or initiating the step of: determining that the wireless device (100; 700; 991; 992; 1030) switched the channel access mode based on a pattern of transmissions from the wireless device (100; 700; 991; 992; 1030) on the wireless channel (502; 522).

46. The method (400) of any one of claims 41 to 45, further comprising or initiating the step of: receiving (404) a request from the wireless device (100; 700; 991; 992;

1030) at the network node (200; 800; 912; 1020), the request being indicative of the determined channel access mode, transmitting (406) a feedback message from the network node (200; 800; 912; 1020) to the wireless device (100; 700; 991; 992; 1030) in response to the received (404) request, wherein the feedback message is indicative of an acknowledgment of the determined channel access mode which triggers the wireless device (100; 700;

991; 992; 1030) to switch to the determined channel access mode and/or wherein the feedback message is indicative of a rejection of the determined channel access mode which triggers the wireless device (100; 700; 991; 992; 1030) to refrain from switching to the determined channel access mode.

47. The method (400) of any one of claims 41 to 46, wherein the method (400) is performed by the network node (200; 800; 912; 1020) serving the wireless device (100; 700; 991; 992; 1030).

48. The method (400) of any one of claims 41 to 47, further comprising the features or the steps of any one of claims 2 to 40 or any feature or step corresponding thereto.

49. A computer program product comprising program code portions for performing the steps of any one of the claims 1 to 40 or 41 to 48 when the computer program product is executed on one or more computing devices (704; 804), optionally stored on a computer-readable recording medium (706; 806).

50. A wireless device (100; 700; 991; 992; 1030) for switching between channel access modes for a transmission from the wireless device (100; 700; 991; 992; 1030) on a wireless channel (502; 522), wherein the channel access modes comprise a listen-before-talk, LBT, mode and a non-LBT mode, the wireless device (100; 700; 991; 992; 1030) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the wireless device (100; 700; 991; 992; 1030) is operable to: determine, at the wireless device (100; 700; 991; 992; 1030), to switch the channel access mode for the transmission from the wireless device (100; 700; 991; 992; 1030) on the wireless channel (502; 522) between the LBT mode and the non- LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode.

51. The wireless device (100; 700; 991; 992; 1030) of claim 50, further comprising the features or operable to perform the steps of any one of claims 2 to 40.

52. A wireless device (100; 700; 991; 992; 1030) for switching between channel access modes for a transmission from the wireless device (100; 700; 991; 992; 1030) on a wireless channel (502; 522), wherein the channel access modes comprise a listen-before-talk, LBT, mode and a non-LBT mode, the wireless device (100; 700; 991; 992; 1030) being configured to: determine, at the wireless device (100; 700; 991; 992; 1030), to switch the channel access mode for the transmission from the wireless device (100; 700; 991; 992; 1030) on the wireless channel (502; 522) between the LBT mode and the non- LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode.

53. The wireless device (100; 700; 991; 992; 1030) of claim 52, further comprising the features or configured to perform the steps of any one of claims 2 to 40.

54. A user equipment, UE (100; 700; 991; 992; 1030), for switching between channel access modes for a transmission from the UE (100; 700; 991; 992; 1030) on a wireless channel (502; 522), wherein the channel access modes comprise a listen-before-talk, LBT, mode and a non-LBT mode, the UE (100; 700; 991; 992; 1030) being configured to communicate with a network node (200; 800; 912;

1020) and/or with another UE (520), the UE (100; 700; 991; 992; 1030) comprising a radio interface (702; 1037) and processing circuitry (704; 1038) configured to: determine, at the UE (100; 700; 991; 992; 1030), to switch the channel access mode for the transmission from the UE (100; 700; 991; 992; 1030) on the wireless channel (502; 522) between the LBT mode and the non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode.

55. The UE (100; 700; 991; 992; 1030) of claim 54, wherein the processing circuitry (704; 1038) is further configured to execute the steps of any one of claims 2 to 40.

56. A network node (200; 800; 912; 1020) for serving a wireless device (100; 700; 991; 992; 1030) switching between channel access modes for a transmission from the wireless device (100; 700; 991; 992; 1030) on a wireless channel (502; 522), wherein the channel access modes comprise a listen-before-talk, LBT, mode and a non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode, the network node (200; 800; 912; 1020) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the network node (200; 800; 912; 1020) is operable to: receive a report from the wireless device (100; 700; 991; 992; 1030) at the network node (200; 800; 912; 1020) serving the wireless device (100; 700; 991; 992; 1030), the report being indicative of a channel access mode determined at the wireless device (100; 700; 991; 992; 1030) for the switching between the LBT mode and the non-LBT mode.

57. The network node (200; 800; 912; 1020) of claim 56, further comprising the features or operable to perform the steps of any one of claims 41 to 48.

58. A network node (200; 800; 912; 1020) for serving a wireless device (100; 700; 991; 992; 1030) switching between channel access modes for a transmission from the wireless device (100; 700; 991; 992; 1030) on a wireless channel (502; 522), wherein the channel access modes comprise a listen-before-talk, LBT, mode and a non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode, the network node (200; 800; 912; 1020) being configured to receive a report from the wireless device (100; 700; 991; 992; 1030) at the network node (200; 800; 912; 1020) serving the wireless device (100; 700; 991; 992; 1030), the report being indicative of a channel access mode determined at the wireless device (100; 700; 991; 992; 1030) for the switching between the LBT mode and the non-LBT mode.

59. The network node (200; 800; 912; 1020) of claim 31, further comprising the features or configured to perform the steps of any one of claim 41 to 48.

60. A base station (200; 800; 912; 1020) for serving a user equipment, UE (100; 700; 991; 992; 1030) switching between channel access modes for a transmission from the UE (100; 700; 991; 992; 1030) on a wireless channel (502; 522), wherein the channel access modes comprise a listen-before-talk, LBT, mode and a non-LBT mode, the transmission being subject to an LBT process in the LBT mode and not subject to the LBT process in the non-LBT mode, the base station (200; 800; 912; 1020) being configured to communicate with the UE (100; 700; 991; 992; 1030), the base station (200; 800; 912; 1020) comprising a radio interface (1202; 1427) and processing circuitry (804; 1028) configured to: receive a report from the UE (100; 700; 991; 992; 1030) at the base station (200; 800; 912; 1020) serving the UE (100; 700; 991; 992; 1030), the report being indicative of a channel access mode determined at the UE (100; 700; 991; 992; 1030) for the switching between the LBT mode and the non-LBT mode.

61. The base station (200; 800; 912; 1020) of claim 60, wherein the processing circuitry (804; 1028) is further configured to execute the steps of any one of claims 41 to 48.

62. A communication system (900; 1000) including a host computer (930; 1010) comprising: processing circuitry (1018) configured to provide user data; and a communication interface (1016) configured to forward user data to a cellular or ad hoc radio network (500; 910) for transmission to a user equipment, UE, (100; 700; 991; 992; 1030) wherein the UE (100; 700; 991; 992; 1030) comprises a radio interface (702; 1037) and processing circuitry (704; 1038), the processing circuitry (704; 1038) of the UE (100; 700; 991; 992; 1030) being configured to execute the steps of any one of claims 1 to 40.

63. The communication system (900; 1000) of claim 62, further including the UE (100; 700; 991; 992; 1030).

64. The communication system (900; 1000) of claim 62 or 63, wherein the radio network (500; 910) further comprises a base station (200; 800; 912; 1020), which is configured to communicate with the UE (100; 700; 991; 992; 1030).

65. The communication system (900; 1000) of claim 64, wherein the base station (200; 800; 912; 1020) comprises processing circuitry (804; 1028), which is configured to execute the steps of claim 41 to 48.

66. The communication system (900; 1000) of any one of claims 62 to 65, wherein: the processing circuitry (1018) of the host computer (930; 1010) is configured to execute a host application (1012), thereby providing the user data; and the processing circuitry (704; 1038) of the UE (100; 700; 991; 992; 1030) is configured to execute a client application (1032) associated with the host application (1012).