CN117999813A

CN117999813A - Proactive COT request

Info

Publication number: CN117999813A
Application number: CN202180102166.2A
Authority: CN
Inventors: 吴春丽; 陶涛; T·E·伦蒂拉; C·罗萨; N·哈蒂拉玛尼; 郑迺铮; P-H·阔
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2021-09-08
Filing date: 2021-09-08
Publication date: 2024-05-07
Also published as: WO2023035140A1

Abstract

Example embodiments of the present disclosure relate to active Channel Occupancy Time (COT) requests. The first device determining a buffer status of the first device; and based at least in part on the buffer status of the first device, sending, during the first COT, indication information to the second device, the indication information indicating whether the first device requests acquisition and sharing of the at least one second COT by the second device.

Description

Proactive COT request

Technical Field

Embodiments of the present disclosure relate generally to the field of telecommunications and, in particular, relate to methods, apparatuses, devices, and computer-readable storage media for active Channel Occupancy Time (COT) requests.

Background

With the rapid development of communication technology, a communication system can support various types of service applications of terminal devices, such as transmission between terminal devices. The concept of cellular-based access over a shared radio frequency band (e.g., unlicensed spectrum) has been introduced in communication systems, which can be used as a complementary tool for operator enhanced service provision, e.g., by offloading a large amount of traffic from the licensed band to the unlicensed spectrum as needed.

Generally, in a communication environment, if a device wants to perform a transmission over a shared radio frequency band (e.g., unlicensed spectrum), the device may need to acquire permission to access the channel for a particular period of time. The process of acquiring grants is called a channel access procedure. The time to occupy a channel is referred to as the Channel Occupation Time (COT). If a device plays the role of a responding device, the device may share the COT acquired by the initiating device.

Disclosure of Invention

The scope of protection sought for the various embodiments of the present disclosure is set forth in the independent claims. The embodiments/examples and features (if any) described in this specification that do not fall within the scope of the independent claims should be construed as examples that aid in the understanding of the various embodiments of the disclosure. Note that the term "embodiment" or "example" shall correspondingly adapt the term used in the present application, i.e. if the term "example" is used, the statement shall correspondingly refer to "example"; or if the term "embodiment" is used, then the statement should be read as referring to "embodiment" accordingly.

In general, example embodiments of the present disclosure provide solutions for active Channel Occupancy Time (COT) requests. Embodiments (if any) that do not fall within the scope of the claims should be construed as examples that are useful for understanding the various embodiments of the present disclosure.

In a first aspect, a first device is provided. The first device includes: at least one processor; and at least one memory including computer program code; wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to: determining a buffer status of the first device; and based at least in part on the buffer status of the first device, transmitting, during the first channel occupancy time, indication information to the second device, the indication information indicating: whether the first device requests acquisition and sharing of at least one second channel occupation time by the second device.

In a second aspect, a method is provided. The method comprises the following steps: determining, at the first device, a buffer status of the first device; and based at least in part on the buffer status of the first device, transmitting, during the first channel occupancy time, indication information to the second device, the indication information indicating: whether the first device requests acquisition and sharing of at least one second channel occupation time by the second device.

In a third aspect, a first apparatus is provided. The first device comprises: means for determining a buffer status of the first device; and means for transmitting, to the second apparatus, indication information during the first channel occupancy time based at least in part on the buffer status of the first apparatus, the indication information indicating: whether the first device requests acquisition and sharing of at least one second channel occupation time by the second device.

In a fourth aspect, a computer-readable medium is provided. The computer readable medium comprises program instructions for causing an apparatus to perform at least the method according to the first aspect.

It should be understood that the summary is not intended to identify key or essential features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the description that follows.

Drawings

Some example embodiments will now be described with reference to the accompanying drawings, in which:

FIG. 1 illustrates an example communication environment in which example embodiments of the present disclosure may be implemented;

Fig. 2 illustrates an example of a COT sharing mechanism for Downlink (DL) and Uplink (UL);

Fig. 3 illustrates signaling flows for communication according to some example embodiments of the present disclosure;

Fig. 4 illustrates a flowchart of a method implemented at a first device, according to some example embodiments of the present disclosure;

FIG. 5 illustrates a simplified block diagram of an apparatus suitable for practicing the example embodiments of the present disclosure; and

Fig. 6 illustrates a block diagram of an example computer-readable medium, according to some example embodiments of the present disclosure.

The same or similar reference numbers will be used throughout the drawings to refer to the same or like elements. The same or similar reference numbers will be used throughout the drawings to refer to the same or like elements.

Detailed Description

Principles of the present disclosure will now be described with reference to some example embodiments. It should be understood that these embodiments are described merely for purposes of illustration and to aid those skilled in the art in understanding and achieving the disclosure without implying any limitation on the scope of the disclosure. The embodiments described herein may be implemented in various ways other than those described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

References in the present disclosure to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It will be understood that, although the terms "first" and "second," etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term "and/or" includes any and all combinations of one or more of the listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "includes," "including," "has," "having," "includes" and/or "including" when used herein, specify the presence of stated features, elements, and/or components, but do not preclude the presence or addition of other elements, components, and/or groups thereof, but does not preclude the presence or addition of one or more other features, elements, components and/or groups thereof.

As used herein, the term "circuitry" may refer to one or more or all of the following:

(a) Pure hardware circuit implementations (such as implementations in analog and/or digital circuitry only), and

(B) A combination of hardware circuitry and software, such as (if applicable):

(i) Combination of analog and/or digital hardware circuit(s) and software/firmware, and

(Ii) Any portion of the hardware processor(s) with software, including the digital signal processor(s), software, and memory(s), which work together to cause a device, such as a mobile phone or server, to perform various functions, and

(C) Hardware circuit(s) and/or processor(s) such as microprocessor(s), or a portion of microprocessor(s), that require software (e.g., firmware) to operate, but may not exist when operation is not required.

This definition of circuitry applies to all uses of this term in this disclosure (including in any claims). As another example, as used in this disclosure, the term "circuitry" also encompasses an implementation of only a hardware circuit or processor (or processors), or a portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. For example, and where applicable to the elements of the particular claim, the term "circuitry" also encompasses a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other computing or network device.

As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as New Radio (NR), long Term Evolution (LTE), LTE-advanced (LTE-a), wideband Code Division Multiple Access (WCDMA), high Speed Packet Access (HSPA), narrowband internet of things (NB-IoT), etc. Furthermore, the communication between the terminal device and the network device in the communication network may be performed according to any generation of suitable communication protocols, including, but not limited to, first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, fifth generation (5G) communication protocols, and/or any other protocols currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. In view of the rapid development of communications, there will of course also be future types of communication technologies and systems that may embody the present disclosure. The scope of the present disclosure should not be considered limited to the foregoing system.

As used herein, the term "network device" refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. Network devices may refer to Base Stations (BS) or Access Points (APs), e.g., node BS (NodeB or NB), evolved NodeB (eNodeB or eNB), NR NB (also known as gNB), remote Radio Units (RRU), radio Heads (RH), remote Radio Heads (RRH), relay stations, integrated Access and Backhaul (IAB) nodes, low power nodes (such as femto nodes, pico nodes, etc.), non-terrestrial networks (NTN) or non-terrestrial network devices such as satellite network devices, low Earth Orbit (LEO) satellites and Geosynchronous Earth Orbit (GEO) satellites, aircraft network devices, etc., depending on the terminology and technology applied. In some example embodiments, a Radio Access Network (RAN) split architecture includes a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node. The IAB node includes a mobile terminal (IAB-MT) part, which is a UE for a parent node, and a DU part of the IAB node, which is a base station for a next hop IAB node.

The term "terminal device" refers to any terminal device capable of wireless communication. By way of example, and not limitation, a terminal device may also be referred to as a communication device, user Equipment (UE), subscriber Station (SS), portable subscriber station, mobile Station (MS), or Access Terminal (AT). The terminal devices may include, but are not limited to, mobile phones, cellular phones, smart phones, voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal Digital Assistants (PDAs), portable computers, desktop computers, image capture terminal devices (such as digital cameras), gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEEs), laptop mounted devices (LMEs), USB dongles, smart devices, wireless client devices (CPE), internet of things (loT) devices, watches or other wearable devices, head Mounted Displays (HMDs), vehicles, drones, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in an industrial and/or automated processing chain environment), consumer electronic devices, devices operating in a commercial and/or industrial wireless network, and the like. The terminal device may also correspond to a Mobile Terminal (MT) part of an IAB node (e.g., a relay node). In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" may be used interchangeably.

As used herein, the terms "resource," "transmission resource," "resource block," "physical resource block" (PRB), "uplink resource," or "downlink resource" may refer to any resource used to perform communications (such as communications between a terminal device and a network device), such as time domain resources, frequency domain resources, spatial domain resources, code domain resources, or other communications-enabling resources, and the like. In the following, some example embodiments of the present disclosure will be described with resources in both the frequency and time domains as examples of transmission resources unless explicitly stated. It should be noted that example embodiments of the present disclosure are equally applicable to other resources in other domains.

FIG. 1 illustrates an example communication environment 100 in which example embodiments of the present disclosure may be implemented. In the communication environment 100, a plurality of communication devices (including the first device 110 and the second device 120) may communicate with each other.

In the example of fig. 1, the first device 110 is illustrated as a terminal device and the second device 120 is illustrated as a network device serving the terminal device. The service area of the second device 120 may be referred to as the cell 102.

It should be understood that the number of devices shown in fig. 1 and their connections are for illustration purposes only and do not imply any limitation. Communication environment 100 may include any suitable number of devices suitable for implementing embodiments of the present disclosure. Although not shown, it is to be appreciated that one or more additional devices can reside within the cell 102 and that one or more additional cells can be deployed within the communication environment 100. It should be noted that although illustrated as a network device, the second device 120 may be other devices in addition to the network device. Although illustrated as a terminal device, the first device 110 may be other devices besides a terminal device.

In some example embodiments, if the first device 110 is a terminal device and the second device 120 is a network device, the link from the second device 120 to the first device 110 is referred to as a Downlink (DL) and the link from the first device 110 to the second device 120 is referred to as an Uplink (UL). In DL, the second device 120 is a Transmitting (TX) device (or transmitter) and the first device 110 is a Receiving (RX) device (or receiver). In the UL, the first device 110 is a TX device (or transmitter) and the second device 120 is an RX device (or receiver).

Communication in communication environment 100 may be implemented in accordance with any suitable communication protocol(s), including, but not limited to, first generation (1G), second generation (2G), third generation (3G), fourth generation (4G), fifth generation (5G) and the like cellular communication protocols, wireless local area network communication protocols (such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 and the like), and/or any other protocols currently known or to be developed in the future. Further, the communication may utilize any suitable wireless communication technology including, but not limited to: code Division Multiple Access (CDMA), frequency Division Multiple Access (FDMA), time Division Multiple Access (TDMA), frequency Division Duplex (FDD), time Division Duplex (TDD), multiple Input Multiple Output (MIMO), orthogonal Frequency Division Multiplexing (OFDM), discrete fourier transform spread OFDM (DFT-s-OFDM), and/or any other technique currently known or to be developed in the future.

In some cases, the first device 110 and the second device 120 may operate on a shared frequency band (e.g., unlicensed spectrum) to offload heavy traffic from the licensed frequency band to the unlicensed spectrum as needed. Unlicensed spectrum also provides additional opportunities to deploy private networks for various use cases (such as shipping ports, mine airports, etc.). MulteFire attempt to create technology-based connectivity options for internet of things deployments, operating exclusively in unlicensed spectrum, to help hug the fourth industrial revolution. New Radios (NRs) have also introduced operation in unlicensed spectrum and can also support highly reliable low-delay use cases in the vertical domain.

Generally, in a communication environment, if a device wants to perform a transmission over a shared radio frequency band (e.g., unlicensed spectrum), the device may need to acquire permission to access the channel for a period of time. The process of acquiring grants is called a channel access procedure. The period of time for occupying a channel is referred to as a Channel Occupation Time (COT). The channel access procedure may include a Listen Before Talk (LBT) procedure. There may be two types of channel access procedures, including channel access type 1 with random backoff, and channel access type 2 with a one-time Clear Channel Assessment (CCA).

In some example embodiments, if a device initiates communication (i.e., the device plays the role of initiating device), the device may apply an "extended" LBT procedure in which the channel may need to be considered idle for the entire duration of the Contention Window (CW). This "extended" LBT procedure is commonly referred to as LBT class 4 (LBT cat.4) or channel access type 1.

In some example embodiments, if a device plays the role of a responding device, the device may share the COT acquired by another device. As used herein, the term "initiating device" may refer to a device that initiates a transmission(s) to one or more other devices and obtains a COT for the transmission(s). As used herein, the term "responding device" may refer to a device to which an initiating device performs a transmission. The initiating device that has acquired the COT may share the COT with one or more other devices (e.g., responding devices) with which it communicates. To share the COT with the responding device, the initiating device may notify the responding device (e.g., via control signaling) about the COT sharing information. With the COT sharing mechanism, the responding device can perform transmission within the COT through a "simplified" LBT procedure.

The "reduced" LBT procedure is commonly referred to as LBT class 2 (LBT cat.2) or LBT class 1 (LBT cat.1), although it is also identified as channel access type 2. There are several types of channel access type 2 procedures that can be selected based on the time gap between two transmissions (e.g., DL and UL) to be performed within the COT. As an example, LBT type 2 procedures may include type 2A procedures, type 2B procedures, and type 2C procedures. These variants are summarized as follows:

type 2A (25 μs LBT Cat.2) -if the gap between two transmissions is more than or equal to 25 μs;

Type 2B (16 μs LBT cat.2) -if the gap between two transmissions is exactly equal to 16 μs; and

Type 2C (no LBT, LBT Cat.1) -if the gap between two transmissions

≤16μs。

In some cases, there may be a large number of low complexity, high reliability requiring terminal devices in the communication environment. These devices may operate in unlicensed spectrum. For example, large-scale Industrial Wireless Sensor Networks (IWSN) support not only ultra-reliable low-latency (URLLC) services with ultra-high reliability requirements, but also relatively low-end services with small device form factor requirements, and/or with complete wireless for battery life up to several years. These use cases will push the work of low complexity new radio-unlicensed (NR-U) to support low complexity and low cost devices in the network when operating in unlicensed spectrum.

Although two types of channel access are supported in a communication environment, the implementation complexity and power consumption of channel access type 1 is much greater than that of channel access type 2. Low complexity terminal devices (e.g., sensors and asset tracking beacons) may only have the ability to perform channel access type 2 and thus may need to share the COTs acquired by other devices, such as network devices. In some cases, some of the low complexity devices may only support channel access type 2C (i.e., not support LBT), and thus may always rely on the COT shared by other devices.

If a device relies on or prefers to transmit using a COT sharing mechanism, there may be situations when the device has no opportunity to perform a transmission when there is no shared COT available. For example, if a first device has a transmission to perform, but a second device does not acquire a COT (e.g., due to no data for transmission, or due to LBT failure), the first device may need to wait until a subsequent transmission opportunity for the second device to acquire the COT. In some cases, the first device may be configured with a transmission to be performed at some time, e.g., a transmission via a Configured Grant (CG), a transmission of a Scheduling Request (SR), a transmission of a Physical Random Access Channel (PRACH), and/or a transmission of other data or signaling. If no shared COT is available, the latency requirements of the transmission may be difficult to meet and some transmissions may need to be relinquished.

Fig. 2 illustrates an example of a COT sharing mechanism of DL and UL between a terminal device and a network device. In this embodiment, it is assumed that the network device acquires and shares the COT with the terminal device. As illustrated, the network device acquires the COT 205 and performs DL transmissions 211 and 212 to the terminal device during the COT 205. The network device also shares the COT 205 with the terminal device. The terminal device is configured to perform UL transmissions 221, 222, 223, and 224 in UL periodicity. During the COT 205, the terminal device performs UL transmissions 221 and 222 to the network device during the corresponding transmission occasions of the terminal device. However, after DL transmission 212, the network device does not acquire the COT in the next period as DL data is exhausted. The intended UL transmissions 223 and 224 may then wait until the network device acquires the subsequent transmission opportunity(s) of the COT.

According to some example embodiments of the present disclosure, an active COT request mechanism is provided. In this solution, the first device determines its buffer status. Depending on the buffer status, the first device actively informs the second device whether one or more COTs are requested. The second device may perform a channel access procedure according to the indication information. Through the active COT request, the second device may be aware of the first device's need for shared COT. Thus, the second device may determine whether to acquire one or more COTs to facilitate subsequent transmissions from the first device. As such, low latency requirements, and/or high priority requirements of the transmission to be performed by the first device may be met.

Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

Referring now to fig. 3, a signaling flow 300 for communication is shown in accordance with some example embodiments of the present disclosure. As shown in fig. 3, the signaling flow 300 involves the first device 110 and the second device 120. For discussion purposes, the signaling flow 300 is described with reference to fig. 1.

In operation, the first device 110 currently has a COT 301 (sometimes referred to herein as a "first COT" for discussion purposes) available for communication with the second device 120.

In some example embodiments, the first device 110 and the second device 120 may operate on a shared frequency band (unlicensed spectrum). In some example embodiments, the COT 301 may be acquired by the first device 110, e.g., by success of a channel access procedure performed on the shared frequency band. In some example embodiments, the first device 110 may be intended to initiate a transmission to the second device 120 or other device(s) over the shared radio frequency band, and thus acquire the COT 301. In some examples, the channel access procedure for acquiring the COT may include an LBT type 1 procedure. In other examples, the first device 110 may perform any other channel access procedure suitable for acquiring a COT.

In some example embodiments, the COT 301 may be acquired by the second device 120 and shared by the second device 120 with the first device 110. In some examples, the first device 110 may relay the COTs shared by other devices if the first device cannot initiate a channel access procedure to actively acquire the COTs for communication. For example, the first device 110 may be a low complexity device and thus be configured to utilize the COT shared by other devices for power saving and low processing complexity purposes.

An embodiment related to sharing a COT 301 from the second device 120 to the first device 110 is illustrated in fig. 3. As illustrated, the second device 120 may acquire 302COT 301 and determine to share the acquired COT 301 with at least the first device 110. The second device 120 may indicate 304COT 301 to the first device 110, for example, by sending a COT share indication to the first device 110. By receiving 306 the COT sharing indication, the first device 110 may be able to determine the COT 301 available for communication with the second device 120.

In some example embodiments, the second device 120 may aim to initiate transmissions to the first device 110 or other device(s) over the shared radio frequency spectrum band, and thus acquire the COT 301. In some example embodiments, the second device 120 may initiate a channel access procedure, and the success of the channel access procedure may allow the second device 120 to acquire the COT 301. In some examples, the channel access procedure for obtaining the COT may include an LBT type 1 procedure. In other examples, the second device 120 may perform any other channel access procedure suitable for obtaining a COT.

After acquiring the COT 301, the second device 120 may determine to share the COT 301 with the first device 110. Note that the second device 120 may also share the COT 301 with one or more other devices in addition to the first device 110, which is not limited to this scope of the present disclosure. In some example embodiments, the second device 120 may provide the COT sharing indication to the first device 110 in a transmission along with data and/or other control information. The COT sharing indication may indicate at least a starting point and a duration of the COT 301 shared with the first device 110. The second device 120 may send other information that allows the first device 110 to perform transmission(s) during the COT 301.

During the COT 301, although not shown, the second device 120 may perform one or more transmissions of data and/or control information to the first device 110, and/or one or more other devices. During the COT 301, although not shown, the first device 110 may perform one or more transmissions of data and/or control information to the second device 120. In the case where the first device 110 is a terminal device and the second device 120 is a network device, the second device 120 may perform DL transmission to the first device 110 and the first device 110 may perform UL transmission to the second device 120.

In the signaling flow 300, during the COT 301, the first device 110 determines 310 a buffer status of the first device 110. According to example embodiments of the present disclosure, the first device 110 is allowed to actively inform the second device 120 whether one or more COTs are acquired and shared by the second device 120. During the COT 301, the first device 110 determines whether to request one or more additional COTs from the second device 120 based on its buffer status.

In some example embodiments, the first device 110 may determine whether there is pending data to be transmitted at the end of the COT 301 based on the buffer status, and determine the indication information to be transmitted based on the determination of the pending data. That is, the availability of pending data following the currently available COT 301 is a trigger condition for the first device 110 to trigger a request. In some other example embodiments, some other trigger conditions may also be considered, as will be discussed below.

Based at least in part on the result of the determination regarding the pending data, the first device 110 sends 315 indication information to the second device 120, the indication information indicating: whether the first device 110 requests acquisition and sharing of one or more COTs (sometimes referred to herein as "second COTs" for discussion purposes) by the second device 120. That is, the COT sharing request or the COT sharing stop indicator may be piggybacked in the transmission performed to the second device 120. The COT sharing request may indicate that the first device 110 requests acquisition and sharing of one or more COTs by the second device 120, and the COT sharing stop indicator may indicate that the first device 110 does not request additional COTs from the second device 120. Example trigger conditions for the COT sharing request and the COT sharing stop indicator are described below.

In some example embodiments, the transmission performed during the COT 301 may indicate data and/or control information to be transmitted to the second device 120 in addition to the COT sharing request or the COT stop indicator. In some examples, the first device 110 may prepare a Transport Block (TB) that includes data to be transmitted to the second device 120. In some examples, the control information (also referred to as control signaling, or control channel) may include an SR, a Physical Random Access Channel (PRACH), and/or any other information.

One or more transmissions from the first device 110 to the second device 120 may be performed using one or more resources allocated for the first device 110. Thus, the first device 110 may perform transmission in the corresponding transmission occasion of the resource during the COT shared by the second device 120. In some examples, where the first device 110 is a terminal device and the second device 120 is a network device, the transmission including the indication information may be performed via a Physical Uplink Shared Channel (PUSCH).

In some example embodiments, the transmission from the first device 110 to the second device 120 may be performed using one or more grants (e.g., configured grants or dynamic grants) within the COT 301. In an example embodiment, the grant (such as a configured grant) for the first device 110 may have a periodicity, and thus the transmission opportunity for the first device 110 may occur with the periodicity. In some example embodiments, the first device 110 may be allocated resources periodically, or aperiodically, to perform one or more transmissions during the COT. The first device 110 may have one or more transmission occasions during the COT 301, depending on the grants or resources available for transmission.

In some example embodiments, if the first device 110 determines to request one or more COTs from the second device 120 in order to send more data and/or control information to the second device 120, the first device 110 may include an indication of the requested COT in a transmission performed during the COT 301. In some example embodiments, the second device 120 may default to acquiring the COTs to share with the first device 110 unless the first device 110 determines that no more COTs are needed in a subsequent time period. In this case, the first device 110 may include indication information indicating that additional COTs are not requested.

In some example embodiments, the indication information may indicate various aspects regarding the COT(s) to be requested in different forms, examples of which are described below.

In some example embodiments, the indication information may include an indication (referred to as a "first indication" for discussion purposes) of whether the first device 110 requests acquisition and sharing of the COT by the second device 120. The first indication is a general indication that is used to indicate a COT sharing request, or a COT sharing stop indicator, to the second device 120. In some examples, the first indication may be one bit of information, where the first value indicates a COT sharing request and the second value indicates a COT sharing stop indicator.

In some example embodiments, the first device 110 may indicate to the second device 120 a desired length of the COT sharing. In this case, the indication information may additionally or alternatively include an indication of the number of transmissions to be performed from the first device 110 to the second device 120 (referred to as "second indication" for discussion purposes). In some examples, the second indication may be multi-bit information indicating the number. In some example embodiments, the second indication may be included in the indication information when the first device 110 determines that the request is acquired by the second device 120 and that one or more additional COTs are shared.

In some example embodiments, the number of transmissions may be indicated in terms of a number of Transport Blocks (TBs) (e.g., PUSCH TBs) to be transmitted to the second device 120, and/or a number of transmission occasions (e.g., CG-PUSCH occasions). In some example embodiments, the second indication may be indicated in units of time (e.g., ms) from which the second device 120 may derive the number of TBs or transmission occasions. In some examples, the second indication may be determined as a number of COTs to be acquired, which may implicitly indicate a number of transmissions to be performed. In some example embodiments, the first device 110 may determine the number of transmissions (e.g., the number of TBs, the number of transmission occasions, the length of time, and/or the explicit number of COTs) based on the amount of pending data expected to be sent to the second device 120. By indicating the number of transmissions to be performed, the second device 120 may determine the number of COTs to be shared with the first device 110 in order to allow the first device 110 to now send the data currently available in the buffer.

In some example embodiments, the indication information may additionally or alternatively include an indication of a priority (or traffic type) of pending data to be sent from the first device 110 to the second device 120 (referred to as a "third indication" for discussion purposes). In some example embodiments, when the first device 110 determines that the request is acquired by the second device 120 and that one or more additional COTs are shared, a third indication may be included in the indication information.

In some example embodiments, the priority of the pending data may include a priority of a Logical Channel (LCH) to which the pending data belongs. In some examples, if there are two or more LCHs pending data, or pending data having different traffic types, the first device 110 may indicate to the second device the highest LCH priority, or traffic type with the highest priority, or may alternatively indicate each LCH priority or traffic type.

Information regarding the priority of pending data may be used by the second device 120 to decide whether it will acquire the COT(s) to share with the first device 110. In some examples, the second device 120 may determine to acquire the COT(s) when the first device 110 notifies that pending data of a high priority (e.g., above a threshold priority) needs to be sent. In some examples, the third indication may be multi-bit information to indicate priority(s), or may be one-bit information to indicate whether pending data of a particular priority (priority above a threshold priority) is to be transmitted by the first device 110.

In some example embodiments, the indication information may additionally or alternatively include an indication of a Channel Access Priority Class (CAPC) to be used by the second device 120 to acquire one or more COTs (referred to as a "fourth indication" for discussion purposes). CAPC may have an impact on the probability of successfully acquiring the COT during channel access. CAPC may be associated with an LCH of pending data to be sent from the first device 110 to the second device 120. In some example embodiments, the first device 110 may indicate the highest CAPC of the LCHs with pending data in the buffer, so the second device 120 may know which CAPC to use when initiating the channel access procedure. In some examples, the fourth indication may be multi-bit information for indication CAPC. In some example embodiments, the fourth indication may be included in the indication information when the first device 110 determines that the request is acquired by the second device 120 and that one or more additional COTs are shared.

In some example embodiments, the indication information may additionally or alternatively include information regarding grant requests for further grants from the second device during at least one second channel occupancy time. More specifically, the indication information may include an indication (referred to as a "fifth indication" for discussion purposes) of whether more grants (or resources) within one or more subsequent COTs will be requested from the second device 120. In some examples, the fifth indication may be one bit of information indicating whether the currently configured resources are sufficient or whether the second device 120 may dynamically schedule more grants to the first device 110 to perform subsequent transmissions in subsequent COTs.

According to the periodicity of the configured grant(s), the first device 110 may be able to determine the number of transmission occasions in a subsequent period when the second device 120 shares another COT. If the first device 110 determines that pending data may not be transmitted in its entirety using the determined transmission opportunity, it may decide to request more grants from the second device 120. Upon receiving an indication of such a request, the second device 120 may configure one or more dynamic grants in a subsequent COT shared with the first device 110. In some example embodiments, when the first device 110 determines that the request is acquired by the second device 120 and that one or more additional COTs are shared, a fifth indication may be included in the indication information.

Some example indications included in the indication information have been described above. In some example embodiments, the indication information may include one or more of the above-described indications, and may include other indications related to requesting or not requesting the COT(s) from the second device 120. In some examples, without a first explicit indication of a COT sharing request, inclusion of one or more of the above-mentioned indications may be used to implicitly indicate a request for a COT.

In some example embodiments, the indication information may be transmitted to the second device 120 by various different methods, examples of which will be described below.

In some example embodiments, the indication information may be included in physical signaling (e.g., control information sent to the second device 120). In some cases where the transmission to the second device 120 is performed (e.g., using resources on the grant), the first device 110 may send control information to the second device 120 along with other information and/or data. In the case where the second device 120 is a network device and the first device 110 is a terminal device, the control information may be Uplink Control Information (UCI) transmitted from the first device 110 to the second device 120. Indication information related to the COT sharing request or the COT sharing stop indicator may be piggybacked in the control information.

In some example embodiments, the first device 110 may send the indication information to the second device 120 in the last available transmission occasion during the current COT 301. That is, if the next transmission opportunity of the first device 110 is still within the COT 301, the first device 110 may not include the indication information in the transmission. This may avoid unnecessary signal overhead. In other example embodiments, the indication information may be sent in any available transmission opportunity during the current COT 301.

In general, the control information transmitted to the second device 120 may have a predefined format. An example of a CG-UCI format defined in TS 38.212 is shown in Table 1 below:

table 1 mapping order of CG-UCI fields

The higher layer parameter CG-COT-SHARINGLIST consists of C instances of CG-COT-Sharing-r16, which is defined in TS 38.331, as shown in Table 2 below.

TABLE 2 definition of cg-COT-SHARINGLIST

In some example embodiments, the format of the control information may be updated to include additional dedicated fields to include the indication information. The dedicated field may be defined with a corresponding bit width to specify one or more of the above-mentioned indications. For example, the UCI may include an additional field to include indication information. In some example embodiments, the presence of respective bits for one or more indications in the control information may be configured by the second device 120.

In some example embodiments, the indication information may be indicated with a specific value of a higher layer parameter of the control information. In some example embodiments, higher layer parameters related to the COT shared information from the first device 110 may be used to convey the indication information. When the first device 110 acquires the COT and shares the acquired COT with the second device 120, the COT sharing information is provided.

In some examples, the higher layer parameter CG-COT-Sharing-r16 in the COT shared information may be redefined to have a particular value for a field (e.g., an offset field) to indicate whether the first device 110 requests one or more COTs from the second device 120. The higher layer parameter CG-COT-Sharing-r16 may be redefined as "CG-COT-Sharing-r17" as shown in Table 3 below.

TABLE 3 definition of CG-COT-Sharing-r17

The offset field (e.g., offset r-16) in the higher layer parameter CG-COT-Sharing-r16 previously had a range of values from 1 to 39. By redefining this higher layer parameter as CG-COT-Sharing-r17, the offset (renamed "offset-r17" from offset r-16) may have a new value of "40" for indicating that the first device 110 requested one or more COTs from the second device, or for indicating that the first device 110 did not request one or more COTs from the second device, as shown in table 3. In some example embodiments, the redefinition of higher layer parameters may be configured by the second device 120 to the first device 110. By redefining, the second device 120 may treat the value of the offset as an offset from the first device 110's COT sharing request, rather than COT sharing information related to the COT acquired by the first device 110.

In some example embodiments, other fields of higher layer parameters may also be used to convey one or more other aspects of indication information related to the COT sharing request and the COT sharing stop indicator. In some examples, field channelAccessPriority (channel access priority) may be interpreted as CAPC of the one or more COTs to be requested, and field duration may be interpreted as, for example, the number of transmissions to be performed to second device 120.

In some example embodiments, new higher layer parameters corresponding to indication information regarding the COT sharing request, and the COT sharing stop indicator may be defined for the control information (more specifically, the COT sharing information in the control information). For example, such a new higher layer parameter may be referred to as CG-COT-Sharing-r17. The new higher layer parameter CG-COT-Sharing-r17 may be part of an Information Element (IE) for COT shared information, e.g., configuredGrantConfig IE, which may be defined as follows in table 4.

Definition of Table 4ConfiguredGrantConfig IE

The new higher layer parameter CG-COT-Sharing-r17 may have a similar structure as the new higher layer parameter CG-COT-Sharing-r16, which may be defined in table 5 below. In this case, the offset field may still have a value ranging from 1 to 39.

TABLE 5 definition of CG-COT-Sharing-r17

In the case where the new higher layer parameter CG-COT-Sharing-r17 is configured, the first device 110 may transmit control information (e.g., UCI) using a combination of CG-COT-Sharing-r17 and CG-COT-SHARINGLIST-r 16. For example, the first X entries in the COT shared information are for cg-COT-SHARINGLIST-r16, and the other entries are for cg-COT-SHARINGLIST-r17.

In some example embodiments, the indication information may be indicated to the second device 120 via a particular hybrid automatic repeat request (HARQ) process selection. The HARQ process identifier (also referred to as HARQ process number) may be split (e.g., semi-statically) into two groups. A first of the two groups may be associated with information related to a COT sharing request (e.g., the first device 110 requesting one or more COTs from the second device), and a second of the two groups may be associated with information related to not requesting one or more COTs (e.g., a COT sharing stop indicator). In some example embodiments, such mapping between HARQ process identifiers and indication information may be preconfigured via Radio Resource Control (RRC) signaling from the second device 120, for example.

Based on such a configuration, if the first device 110 determines to request one or more COTs after the COT 301, it may select the HARQ process identifier from the first group. In some cases, if the first device 110 determines that one or more COTs are not requested after the COTs 301, it may select a HARQ process identifier from the second group. The first device 110 may perform transmission using the selected HARQ process identifier. In some examples, the selected HARQ process identifier may be sent to the second device 120 in a "HARQ process number" field in the control information, as seen from the example control information in table 1. In this way, the first device 110 may be able to indicate whether additional COT(s) are needed by selecting the HARQ process identifier.

In some example embodiments, the indication information of whether to request one or more COTs may be applicable to an initial transmission during a HARQ process, for example, when a New Data Indicator (NDI) field in control information indicates that new data is transmitted. This is because the retransmission in the HARQ process can inherit the HARQ process identifier used in the initial transmission.

In some example embodiments, the indication information may be indicated to the second device 120 via a particular reference signal resource selection. The first device 110 may be configured (e.g., semi-statically) by the second device 120 for a set of resources for transmitting the reference signal. The reference signal may be transmitted by the first device 110 to the second device 120. Examples of such reference signals may include Sounding Reference Signals (SRS), demodulation reference signals (DMRS), and/or any other reference signals.

The resources in the set of resources of the reference signal may be different in the time domain, frequency domain, and/or code domain (for different signal sequences of the reference signal). Thus, the different resources for the reference signal may include different frequency resources, different time resources, and/or different signal sequences. Different resources for the reference signal may be configured to be associated with different indication information. For example, a resource may be associated with information related to a COT request (e.g., the first device 110 requesting one or more COTs from the second device 120), and another resource may be associated with information related to not requesting one or more COTs.

In some example embodiments, the framework of reference signal resource selection may also be utilized to allow more information to be indicated by providing more resources for reference signals to the first device 110. For example, the different resources may be associated with an indication of the number of transmissions to be performed by the first device 110, the need for other resources to be scheduled by the second device 120, and so on. In some example embodiments, such a mapping between the resources for the reference signal and the indication information may be configured by the second device 120.

In some example embodiments, the indication information may be included in MAC signaling (e.g., MAC CE). In some example embodiments, a new MAC CE may be defined for the indication information. Since the size of the MAC CE may vary as desired, in the event that the first device 110 determines to request additional COT(s), more indications may be included in the MAC CE and transmitted to the second device 120. For example, the MAC CE may include a COT sharing request, or a COT sharing stop indicator. In the event that a COT sharing request is triggered, the MAC CE may include other information as discussed above, including the number of transmissions to be performed, CAPC for use by the second device 120, the priority of LCHs of pending data, an indication as to whether more grants are requested during the subsequent COT to be shared.

In some example embodiments, the first device 110 may send a Buffer Status Report (BSR) as the indication information. The BSR may be transmitted as a BSR MAC CE. In such embodiments, the trigger condition for the COT sharing request or the COT sharing stop indicator may be considered as the trigger condition for triggering the BSR. In some example embodiments, if the first device 110 decides to request one or more subsequent COTs from the second device 120, the first device 110 may send a BSR to act as a COT sharing request, the BSR indicating the size of the pending data in the buffer. In some example embodiments, if the first device 110 decides not to request additional COTs from the second device 120, the first device 110 may send an empty BSR to act as a COT sharing stop indicator.

In some example embodiments, a particular MAC CE or BSR may be sent to the second device 120 in any transmission occasion during the currently available COT 301. In some example embodiments, the first device 110 may determine an appropriate transmission opportunity within the COT 301 for transmitting the BSR, as the second device 120 may take some time to decode the BSR. The transmission opportunity may be determined in such a way that the second device 120 has a remaining time to decode the BSR before the COT 301 ends. This may avoid potential delays in acquiring the requested COT for the first device 110. In an example embodiment, a particular MAC CE or BSR may be transmitted by the first device 110 to the second device 120 in the last available transmission opportunity during the COT 301.

In some example embodiments, if the BSR is not transmitted in the last available transmission occasion in the COT 301, the BSR may indicate an estimated size of pending data remaining after the currently available COT 301. As such, the second device 120 may determine how much data needs to be sent from the first device 110. In some example embodiments, the BSR may indicate a size of pending data stored in the buffer when the BSR is transmitted. The second device 120 may be capable of estimating the size of the pending data remaining after the COT 301 based on the number of transmission occasions remaining in the COT 301 for the first device 110 to transmit data.

Based on the received BSR, the second device 120 may be aware of the size of pending data to be transmitted by the first device 110. The second device 120 may then determine whether to acquire one or more COTs to share with the first device 110. In this way, the BSR may be considered an implicit COT sharing request or COT sharing stop indicator (in the case of an empty BSR) for allowing the first device 110 to request or stop COT sharing.

Some example embodiments for transmitting indication information have been described above. In other embodiments, indication information related to the COT sharing request or the COT sharing stop indicator may be transmitted to the second device 120 during the COT 301 by other means, and the scope of the present disclosure is not limited in this respect.

There may be various trigger conditions for transmitting indication information about the COT sharing request or the COT sharing stop indicator, examples of which will be described below.

As mentioned above, the first device 110 determines whether to request one or more COTs based on the buffer status. More specifically, the first device 110 determines whether there is pending data or control signaling to be sent to the second device 120 at the end of the currently available COT 301 based on the buffer status. In some example embodiments, if the first device 110 determines from the buffer status that there is pending data available for transmission, but the pending data cannot be sent in its entirety within the current COT 301 (meaning that part of the pending data will still be buffered at the end of the COT 301), the first device 110 may send a COT sharing request and/or possibly other relevant information (e.g., the number of transmissions to be performed after the COT 301, the CAPC, the priority of LCH, grant requests, etc.) to the second device 120.

In some example embodiments, if the first device 110 determines that there is no pending data remaining at the end of the COT 301, the first device 110 may determine not to send the COT sharing request, or may determine to send a COT sharing stop indicator to the second device 120. In some example embodiments, the first device 110 may determine to request one or more subsequent COTs from the second device 120 if the first device 110 is configured to periodically send certain data or control signaling, or if the first device 110 estimates that more data will arrive after the COTs 301.

In some example embodiments, if there is pending data to be sent after the COT 301, the first device 110 may determine whether to request one or more COTs based on additional trigger conditions related to one or more characteristics of the pending data. Specifically, in some example embodiments, the first device 110 may determine whether to request one or more COTs based on one or more priorities of pending data to be sent to the second device 120, parameter(s) or setting(s) of LCH(s) to which the pending data belongs, latency requirements of the pending data, and/or mapping limits of the pending data relative to at least one grant configured for the first device.

In some example embodiments, it may be configured that: the first device 110 is permitted to transmit indication information regarding one or more COTs (e.g., COT sharing requests) requesting data having a particular priority (e.g., above a threshold priority). The threshold priority may be configured by the second device 120 or predefined. In some example embodiments, the first device 110 may be allowed to send a COT sharing request if pending data for some LCHs is to be sent. For example, the first device 110 may send a COT sharing request if the LCH with pending data has a high priority (e.g., above a threshold priority) and/or has a high CAPC (e.g., above a threshold class). Otherwise, if the LCH of the pending data has a low priority (e.g., below a threshold priority) and/or has a low CAPC (e.g., below a threshold class), the first device 110 may not send the COT sharing request, or may instead send the COT sharing stop indicator. The threshold class may be configured by the second device 120 or predefined.

In some example embodiments, the first device 110 may be allowed to send a COT sharing request, alternatively or additionally, if the latency requirements of the pending data meet the latency criteria. For example, it may be configured that: when the first device 110 has pending data with stringent delay requirements to be transmitted, the first device 110 may actively request additional COTs. In some examples, the delay criteria may be defined based on delay requirements of a particular traffic type (e.g., URLLC). For example, if the first device 110 determines URLLC data to be transmitted, or data with more stringent delay requirements than URLLC data, the first device 110 may transmit indication information regarding the request for one or more COTs. In some examples, the first device 110 may not send a COT sharing request, or may instead send a COT sharing stop indicator, if the latency requirements of the pending data fail to meet the latency criteria.

In some example embodiments, the indication information requesting one or more COTs may be allowed to be triggered on one or more specific grants. In some example embodiments, the first device 110 may be configured with mapping restrictions of pending data relative to at least one grant configured for the first device 110. The mapping limit indicates: whether to allow pending data of the LCH to be mapped to a particular grant (e.g., a configured grant). In some example embodiments, the first device 110 may determine whether to allow mapping of pending data sent after the COT 301 to one or more configured grants, or to one or more grants that become available in a subsequent period of time (which may be located within the requested COT to be shared from the second device 120). Depending on the periodicity of the configured grants, the first device 110 may determine whether one or more configured grants become available in a subsequent period of time. If pending data is not allowed to be mapped to the foreseeable grant, the first device 110 may not send a COT sharing request to the second device 120, or may instead send a COT sharing stop indicator. Otherwise, if the pending data can be mapped to a predictable grant, the first device 110 can send a COT sharing request.

In some example embodiments, the first device 110 may be configured with a COT request limit with respect to authorization. For example, the active COT request mechanism may be configured to be applicable to one or more specific grants. If the first device 110 is configured with one or more grants to which the active COT request mechanism is applicable, and those grants are available for a particular period of time after the COT 301, the first device 110 may determine to send a COT sharing request to the second device 120. Otherwise, if the first device 110 is not configured with such authorization, the first device 110 may not send a COT sharing request, or may instead send a COT sharing stop indicator.

In some example embodiments, the transmission of the indication requesting the one or more COTs may be performed based on instructions from the second device 120. The second device 120 may send an instruction whether to allow the first device 110 to request one or more COTs. The instructions may be included in a Control Element (CE), e.g., in a Medium Access Control (MAC) CE, in a Physical Downlink Control Channel (PDCCH), or via RRC signaling, which is transmitted from the second device 120 to the first device 110. In some example embodiments, the transmission of the instruction may be performed during the COT 301 in a last transmission occasion of the second device 120.

If the second device 120 instructions allow the first device 110 to actively request one or more COTs, the first device 110 may generate and send an indication to the second device 120 to indicate that the first device 110 requests or does not request the second device 120 to acquire and share one or more COTs. Conversely, if the second device 120 does not require the first device 110 to provide the indication information, the first device 110 may not include the indication information, whether it is needed or not.

Some example trigger conditions for the indication information of the COT sharing request and the COT stop indicator have been discussed above. It should be appreciated that any combination of these trigger conditions may be applied by the first device 110 to decide whether to request one or more subsequent COTs from the second device 120.

Still referring to fig. 3, in signaling flow 300, second device 120 receives 320 a transmission from first device 110, the transmission including at least an indication of whether first device 110 requested acquisition and sharing of one or more COTs by second device 120. The second device 120 performs 325 a channel access procedure based on the indication information. The channel access procedure may comprise, for example, an LBT type 1 procedure, but other channel access procedures are also possible.

In some example embodiments, if the indication information indicates that the first device 110 requests to acquire and share the COT, the second device 120 may initiate a channel access procedure after the COT 301 to acquire the COT, even though the second device 120120 does not need to perform other transmissions to the first device 110 or other devices. Depending on the indication information received from the first device 110, the second device 120 may also determine the number of COTs to be acquired and shared with the first device 110, and/or CAPC to be utilized when acquiring COTs, whether to assign more grants to the first device 110 to perform transmissions in subsequent COTs.

In some example embodiments, the second device 120 may be able to acquire additional COTs after the COTs 301 in response to the success of the channel access procedure. The second device 120 may also indicate the acquired COT to the first device 110 to allow the first device 110 to share the COT.

In some example embodiments, if the indication information indicates that the first device 110 does not request a COT from the second device 120, the second device 120 may not initiate a channel access procedure after the COT 301 unless the second device 120 has other transmissions to be performed to the first device 110 or other devices.

In some example embodiments, the second device 120 may make a decision as to whether to initiate a channel access procedure to acquire the COT based on one or more other factors (e.g., based on a priority or LCH of pending data to be sent from the first device 110, a workload on a shared band, etc.). Thus, if the second device 120 receives indication information indicating that the first device 110 requests one or more COTs, it may not always initiate a channel access procedure after the COTs 301 to acquire the COTs. On the other hand, as mentioned above, if the indication information indicates that the first device 110 does not request a COT, the second device 120 may perform a channel access procedure to obtain the COT, e.g., for other transmissions to be performed by the second device 120. Accordingly, the present disclosure is not limited in this respect.

In some example embodiments, after pending data that allows for the transmission of the trigger indication information has been sent, the first device 110 may send an indication information to the second device 120 that no more COTs are requested during the ongoing COT (i.e., a COT shared stop indicator). In some example embodiments, the second device 120 may assume that additional COTs are needed after receiving the COT sharing request from the first device 110 until additional indications, such as when a COT sharing stop indicator is received.

In some example embodiments, if the indication information from the first device 110 indicates the number of transmissions to be performed (e.g., the number of TBs, the number of transmission occasions, the length of time, and/or the explicit number of COTs), or if a BSR is received from the first device 110, the second device 120 may acquire the number of COTs shared with the first device 110 so that the first device 110 can perform the requested number of transmissions, or send buffered data as indicated in the BSR.

In some example embodiments, the second device 120 may not need to receive the COT sharing indicator to stop the COT acquisition. In some example embodiments, the second device 120 may determine when the first device 110 does not need a COT, e.g., based on data multiplexed in the received transmission. For example, if the first device 110 begins to transmit data with a lower priority or latency requirement, or data in the LCH that is not allowed to request additional COTs, the second device 120 may determine not to request more COTs for the first device 110 unless the second device 120 is to initiate its transmission.

Fig. 4 illustrates a flowchart of an example method 400 implemented at a first device, according to some example embodiments of the present disclosure. For discussion purposes, the method 400 will be described from the perspective of the first device 110 in fig. 1.

At block 410, the first device 110 determines a buffer status of the first device 110. At block 420, the first device 110 sends indication information to the second device 120 during a first channel occupancy time based at least in part on a buffer status of the first device 110. The first channel occupancy time is currently available to the first device 110 for communication with the second device 120. The indication information indicates: whether the first device 110 requests acquisition and sharing of at least one second channel occupation time by the second device 120.

In some example embodiments, the first device 110 may determine whether there is pending data to be transmitted at the end of the first channel occupancy time based on the buffer status. Based at least in part on determining that there is pending data to be transmitted at the end of the first channel occupancy time, the first device 110 may transmit at least a channel occupancy time sharing request to the second device requesting at least one second channel occupancy time to be acquired and shared by the second device.

In some example embodiments, based at least in part on determining that there is pending data to be transmitted at the end of the first channel occupancy time, the first device 110 may transmit a channel occupancy time sharing request, along with additional information regarding at least one of: the number of transmissions from the first device to the second device to be performed after the first channel occupation time, a channel access priority class to be used by the second device to acquire at least one second channel occupation time, a priority of a logical channel to which pending data belongs, and an authorization request for more grants from the second device during the at least one second channel occupation time.

In some example embodiments, the first device 110 may determine whether there is pending data to be transmitted at the end of the first channel occupancy time based on the buffer status. Based at least in part on determining that there is no pending data to be transmitted at the end of the first channel occupancy time, the first device 110 may send a channel occupancy time sharing stop indicator to the second device to indicate that no channel occupancy time was acquired and shared by the second device.

In some example embodiments, the first device 110 may send at least a channel occupancy time sharing request further based on at least one characteristic of the pending data in addition to the buffer status.

In some example embodiments, the at least one characteristic of the pending data includes at least one of: the priority of the logical channel to which the pending data belongs, the channel access priority class of the logical channel to which the pending data belongs, the latency requirement of the pending data, and the mapping limit of the pending data with respect to at least one grant configured for the first device.

In some example embodiments, the first device 110 may send at least a channel occupancy time sharing request to the second device 120 based further on at least one of: the priority of the logical channel is above a threshold priority, the channel access priority class of the logical channel is above a threshold class, the latency requirement of the pending data meets a latency criterion, and the mapping limit indicates that the pending data is allowed to be mapped to at least one grant configured for the first device.

In some example embodiments, the first device 110 may transmit the indication information in a medium access control element, or in physical control information.

In some example embodiments, the first device 110 may send a buffer status report as the indication information. Different types of buffer status reports may be used to indicate channel occupancy time sharing requests, or channel occupancy time stop indicators.

In some example embodiments, the first device comprises a terminal device and the second device comprises a network device.

In some example embodiments, a first apparatus (e.g., first device 110 in fig. 1) capable of performing any of methods 400 may include means for performing the respective operations of method 400. The component may be implemented in any suitable form. For example, the components may be implemented in circuitry or software modules. The first means may be implemented as the first device 110 in fig. 1 or comprised in the first device 110 in fig. 1.

In some example embodiments, a first apparatus includes: means for determining a buffer status of the first device; means for transmitting, to a second apparatus (e.g., second device 120 in fig. 1), indication information during a first channel occupancy time based at least in part on a buffer status of the first apparatus, the indication information indicating: whether the first device requests acquisition and sharing of at least one second channel occupation time by the second device.

In some example embodiments, the means for transmitting the indication information comprises: means for determining whether there is pending data to be transmitted at the end of the first channel occupancy time based on the buffer status; means for sending at least a channel occupancy time sharing request to the second device to request at least one second channel occupancy time to be acquired and shared by the second device based at least in part on determining that there is pending data to be sent at the end of the first channel occupancy time.

In some example embodiments, the means for sending at least a channel occupancy time sharing request comprises: means for transmitting a channel occupancy time sharing request, based at least in part on determining that there is pending data to be transmitted at the end of the first channel occupancy time, and information about at least one of: the number of transmissions from the first device to the second device to be performed after the first channel occupation time, a channel access priority class to be used by the second device to obtain at least one second channel occupation time, a priority of a logical channel to which pending data belongs, and an grant request for more grants from the second device during the at least one second channel occupation time.

In some exemplary embodiments, the means for transmitting the indication information further comprises: means for determining whether there is pending data to be transmitted at the end of the first channel occupancy time based on the buffer status; and means for transmitting a channel occupancy time sharing stop indicator to the second apparatus to indicate that no channel occupancy time was acquired and shared by the second apparatus based at least in part on determining that there is no pending data to be transmitted at the end of the first channel occupancy time.

In some example embodiments, the means for sending at least the channel occupancy time sharing request further comprises: means for transmitting at least a channel occupancy time sharing request based further on at least one characteristic of the pending data.

In some example embodiments, the means for transmitting at least the channel occupancy time sharing request further based on at least one characteristic of the pending data comprises: means for sending at least a channel occupancy time sharing request to a second apparatus based further on at least one of: the priority of the logical channel is above a threshold priority, the channel access priority class of the logical channel is above a threshold class, the latency requirement of the pending data meets a latency criterion, and the mapping limit indicates that the pending data is allowed to be mapped to at least one grant configured for the first device.

In some example embodiments, the means for transmitting the indication information comprises: means for sending the indication information in a medium access control element, or in physical control information.

In some example embodiments, the means for transmitting the indication information comprises: means for sending a punch status report as indication information.

In some example embodiments, the first apparatus comprises a terminal device and the second apparatus comprises a network device.

In some example embodiments, the first apparatus further comprises: means for performing the method 400 or other operations in some example embodiments of the first device 110. In some example embodiments, the component includes: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause execution of the first apparatus.

Fig. 5 is a simplified block diagram of an apparatus 500 suitable for implementing example embodiments of the present disclosure. The device 500 may be provided to implement a communication device, for example, the first device 110 or the second device 120 as shown in fig. 1. As shown, the device 500 includes one or more processors 510, one or more memories 520 coupled to the processors 510, and one or more communication modules 540 coupled to the processors 510.

The communication module 540 is used for two-way communication. The communication module 540 has one or more communication interfaces to facilitate communications with one or more other modules or devices. The communication interface may represent any interface required to communicate with other network elements. In some example embodiments, the communication module 540 may include at least one antenna.

Processor 510 may be of any type suitable to the local technology network and may include, as non-limiting examples, one or more of the following: general purpose computers, special purpose computers, microprocessors, digital Signal Processors (DSPs), and processors based on a multi-core processor architecture. The device 500 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock that is synchronized to the master processor.

Memory 520 may include one or more non-volatile memories, as well as one or more volatile memories. Examples of non-volatile memory include, but are not limited to, read-only memory (ROM) 524, electrically programmable read-only memory (EPROM), flash memory, a hard disk, a Compact Disk (CD), a Digital Video Disk (DVD), an optical disk, a laser disk, and other magnetic and/or optical storage devices. Examples of volatile memory include, but are not limited to, random Access Memory (RAM) 522, and other volatile memory that does not last for the duration of the power outage.

The computer program 530 includes computer-executable instructions that are executed by an associated processor 510. Program 530 may be stored in a memory (e.g., ROM 524). Processor 510 may perform any suitable actions and processes by loading program 530 into RAM 522.

Example embodiments of the present disclosure may be implemented by the program 530 such that the device 500 may perform any of the processes of the present disclosure as discussed with reference to fig. 3-4. Example embodiments of the present disclosure may also be implemented by hardware, or by a combination of software and hardware.

In some example embodiments, the program 530 may be tangibly embodied in a computer-readable medium, which may be included in the device 500 (such as in the memory 520), or other storage device accessible to the device 500. Device 500 may load program 530 from a computer readable medium into RAM 522 for execution. The computer readable medium may include any type of tangible, non-volatile storage device, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Fig. 6 illustrates an example of a computer-readable medium 600, which may be in the form of a CD, DVD, or other optical storage disc. The computer readable medium has a program 530 stored thereon.

In general, the various embodiments of the disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of the embodiments of the disclosure are illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product comprises computer executable instructions, such as those included in program modules, to be executed in a device on a target physical or virtual processor to perform any of the methods described above with reference to fig. 3-5. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or split between program modules as desired. Machine-executable instructions of program modules may be executed within local or distributed devices. In distributed devices, program modules may be located in both local and remote memory storage media.

Program code for carrying out the methods of the present disclosure may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable an apparatus, device or processor to perform the various processes and operations described above. Examples of carriers include signals, computer readable media, and the like.

The computer readable medium may be a computer readable signal medium, or a computer readable storage medium. The computer readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Moreover, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some scenarios, multitasking and parallel processing may be advantageous. Also, while the above discussion contains several specific implementation details, these should not be construed as limitations on the scope of the disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the disclosure has been described in language specific to structural features and/or methodological acts, it is to be understood that the disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A first device, comprising:

at least one processor; and

At least one memory including computer program code;

wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to:

determining a buffer status of the first device; and

Transmitting, to a second device, indication information during a first channel occupancy time based at least in part on the buffer status of the first device, the indication information indicating:

Whether the first device requests acquisition and sharing of at least one second channel occupancy time by the second device.

2. The first device of claim 1, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to send the indication information by:

Determining, based on the buffer status, whether there is pending data to be transmitted at the end of the first channel occupancy time; and

At least one channel occupancy time sharing request is sent to the second device to request the at least one second channel occupancy time to be acquired and shared by the second device based at least in part on determining that there is pending data to be sent at the end of the first channel occupancy time.

3. The first device of claim 2, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to at least send the channel occupancy time sharing request by:

Based at least in part on determining that there is pending data to be transmitted at the end of the first channel occupancy time, transmitting the channel occupancy time sharing request, and information regarding at least one of:

The number of transmissions from the first device to the second device to be performed after the first channel occupancy time,

A channel access priority class to be used by the second device to acquire the at least one second channel occupancy time,

Priority of the logical channel to which the pending data belongs, and

An grant request for more grants from the second device during the at least one second channel occupancy time.

4. The first device of claim 1, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to send the indication information by:

A channel occupancy time sharing stop indicator is sent to the second device to indicate that no channel occupancy time was acquired and shared by the second device based at least in part on determining that there is no pending data to be sent at the end of the first channel occupancy time.

5. The first device of claim 2, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to at least send the channel occupancy time sharing request by:

and further transmitting at least the channel occupancy time sharing request based on at least one characteristic of the pending data.

6. The first device of claim 5, wherein the at least one characteristic of the pending data comprises at least one of:

the priority of the logical channel to which the pending data belongs,

A channel access priority class of the logical channel to which the pending data belongs,

Delay requirement of the pending data, and

The pending data is relative to at least one authorized mapping limit configured for the first device.

7. The first device of claim 6, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to further transmit at least the channel occupancy time sharing request based on at least one characteristic of the pending data by:

Further based on at least one of the following, sending at least the channel occupancy time sharing request to the second device:

the priority of the logical channel is higher than a threshold priority,

The channel access priority class of the logical channel is higher than a threshold class,

The latency requirement of the pending data meets a latency criterion, and

The mapping limit indicates: allowing the pending data to be mapped to the at least one grant configured for the first device.

8. The first device of any of claims 1-7, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to send the indication information by:

The indication information is sent in a medium access control element or in physical control information.

9. The first device of any of claims 1-8, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to send the indication information by:

And sending a buffer status report as the indication information.

10. A method, comprising:

Determining, at a first device, a buffer status of the first device; and

Transmitting, to a second device, indication information during a first channel occupancy time based at least in part on the buffer status of the first device, the indication information indicating: whether the first device requests acquisition and sharing of at least one second channel occupancy time by the second device.

11. The method of claim 10, wherein transmitting the indication information comprises:

12. The method of claim 11, wherein transmitting at least the channel occupancy time sharing request comprises:

Priority of the logical channel to which the pending data belongs, and

13. The method of claim 10, wherein transmitting the indication information further comprises:

14. The method of claim 11, wherein transmitting at least the channel occupancy time sharing request comprises:

15. The method of claim 14, wherein the at least one characteristic of the pending data comprises at least one of:

the priority of the logical channel to which the pending data belongs,

Delay requirement of the pending data, and

16. The method of claim 15, wherein transmitting at least the channel occupancy time sharing request further based on at least one characteristic of the pending data comprises:

the priority of the logical channel is higher than a threshold priority,

The latency requirement of the pending data meets a latency criterion, and

The mapping limit indicates: the pending data is allowed to be mapped to at least one grant configured for the first device.

17. The method of any of claims 10 to 16, wherein transmitting the indication information comprises:

18. The method of any of claims 10 to 17, wherein transmitting the indication information comprises:

And sending a buffer status report as the indication information.

19. A first apparatus, comprising:

Means for determining a buffer status of the first device; and

Means for transmitting, to a second device, indication information during a first channel occupancy time based at least in part on a buffer status of the first device, the indication information indicating: whether the first device requests acquisition and sharing of at least one second channel occupancy time by the second device.

20. A computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any one of claims 10 to 18.