WO2023035140A1 - Demande de cot proactive - Google Patents

Demande de cot proactive Download PDF

Info

Publication number
WO2023035140A1
WO2023035140A1 PCT/CN2021/117136 CN2021117136W WO2023035140A1 WO 2023035140 A1 WO2023035140 A1 WO 2023035140A1 CN 2021117136 W CN2021117136 W CN 2021117136W WO 2023035140 A1 WO2023035140 A1 WO 2023035140A1
Authority
WO
WIPO (PCT)
Prior art keywords
occupancy time
channel occupancy
pending data
cot
channel
Prior art date
Application number
PCT/CN2021/117136
Other languages
English (en)
Inventor
Chunli Wu
Tao Tao
Timo Erkki Lunttila
Claudio Rosa
Navin Hathiramani
Naizheng ZHENG
Ping-Heng Kuo
Original Assignee
Nokia Shanghai Bell Co., Ltd.
Nokia Solutions And Networks Oy
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Shanghai Bell Co., Ltd., Nokia Solutions And Networks Oy, Nokia Technologies Oy filed Critical Nokia Shanghai Bell Co., Ltd.
Priority to PCT/CN2021/117136 priority Critical patent/WO2023035140A1/fr
Priority to CN202180102166.2A priority patent/CN117999813A/zh
Publication of WO2023035140A1 publication Critical patent/WO2023035140A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0278—Traffic management, e.g. flow control or congestion control using buffer status reports

Definitions

  • Embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to methods, devices, apparatuses and computer readable storage medium for proactive channel occupancy time (COT) request.
  • COT channel occupancy time
  • communication systems can support various types of service applications for terminal devices, such as transmissions between terminal devices. It has been introduced in the communication systems the notion of cellular-based access via a shared radio frequency band (for example, unlicensed spectrum) , which can be used as a complementary tool for operators to augment the service offering, for example, by offloading heavy traffic from licensed band to unlicensed spectrum on-demand.
  • a shared radio frequency band for example, unlicensed spectrum
  • a device may need to acquire the permission to access a channel for a certain period of time.
  • the procedure to acquire the permission is referred to as a channel access procedure.
  • the period of time for occupying the channel is referred as a channel occupancy time (COT) .
  • COT channel occupancy time
  • example embodiments of the present disclosure provide a solution for proactive channel occupancy time (COT) request.
  • COT channel occupancy time
  • a first device comprising at least one processor; and at least one memory including computer program code; where the at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to determine a buffer status of the first device; and transmit, based at least in part on the buffer status of the first device, indication information to a second device during a first channel occupancy time, the indication information indicating whether the first device requests at least one second channel occupancy time to be acquired and shared by the second device.
  • a method comprises determining, at a first device, a buffer status of the first device; and transmitting, based at least in part on the buffer status of the first device, indication information to a second device during a first channel occupancy time, the indication information indicating whether the first device requests at least one second channel occupancy time to be acquired and shared by the second device.
  • the first apparatus comprises means for determining a buffer status of the first apparatus; and means for transmitting, based at least in part on the buffer status of the first apparatus, indication information to a second apparatus during a first channel occupancy time, the indication information indicating whether the first apparatus requests at least one second channel occupancy time to be acquired and shared by the second apparatus.
  • a computer readable medium comprises program instructions for causing an apparatus to perform at least the method according to the first aspect.
  • Fig. 1 illustrates an example communication environment in which example embodiments of the present disclosure can be implemented
  • Fig. 2 illustrates an example of a COT sharing mechanism for downlink (DL) and uplink (UL) ;
  • Fig. 3 illustrates a signaling flow 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 that is suitable for implementing example embodiments of the present disclosure.
  • Fig. 6 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.
  • references in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, 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 affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
  • first, ” “second” and the like 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. 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.
  • the term “and/or” includes any and all combinations of one or more of the listed terms.
  • circuitry may refer to one or more or all of the following:
  • circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.
  • circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
  • the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on.
  • NR New Radio
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • WCDMA Wideband Code Division Multiple Access
  • HSPA High-Speed Packet Access
  • NB-IoT Narrow Band Internet of Things
  • the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) communication protocols, and/or any other protocols either currently known or to be developed in the future.
  • suitable generation communication protocols including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) communication protocols, and/or any other protocols either currently known or to be developed in the future.
  • Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system
  • the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom.
  • the network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, an Integrated Access and Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and
  • radio access network (RAN) split architecture comprises a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node.
  • An IAB node comprises a Mobile Terminal (IAB-MT) part that behaves like a UE toward the parent node, and a DU part of an IAB node behaves like a base station toward the next-hop IAB node.
  • IAB-MT Mobile Terminal
  • terminal device refers to any end device that may be capable of wireless communication.
  • a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) .
  • UE user equipment
  • SS Subscriber Station
  • MS Mobile Station
  • AT Access Terminal
  • the terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and/
  • the terminal device may also correspond to a Mobile Termination (MT) part of an IAB node (e.g., a relay node) .
  • MT Mobile Termination
  • IAB node e.g., a relay node
  • the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.
  • resource may refer to any resource for performing a communication, for example, a communication between a terminal device and a network device, such as a resource in time domain, a resource in frequency domain, a resource in space domain, a resource in code domain, or any other resource enabling a communication, and the like.
  • a resource in both frequency domain and time domain will be used as an example of a transmission resource for describing some example embodiments of the present disclosure. It is noted that example embodiments of the present disclosure are equally applicable to other resources in other domains.
  • Fig. 1 shows an example communication environment 100 in which example embodiments of the present disclosure can be implemented.
  • a plurality of communication devices including a first device 110 and a second device 120 can communicate with each other.
  • the first device 110 is illustrated as a terminal device while the second device 120 is illustrated as a network device serving the terminal device.
  • the serving area of the second device 120 may be called a cell 102.
  • the communication environment 100 may include any suitable number of devices adapted for implementing embodiments of the present disclosure. Although not shown, it would be appreciated that one or more additional devices may be located in the cell 102, and one or more additional cells may be deployed in the communication environment 100. It is noted that although illustrated as a network device, the second device 120 may be other device than a network device. Although illustrated as a terminal device, the first device 110 may be other device than a terminal device.
  • a link from the second device 120 to the first device 110 is referred to as a downlink (DL)
  • a link from the first device 110 to the second device 120 is referred to as an uplink (UL)
  • the second device 120 is a transmitting (TX) device (or a transmitter)
  • the first device 110 is a receiving (RX) device (or a receiver)
  • the first device 110 is a TX device (or a transmitter) and the second device 120 is a RX device (or a receiver) .
  • Communications in the communication environment 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) and the fifth generation (5G) and on the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future.
  • s cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) and the fifth generation (5G) and on the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future.
  • IEEE Institute for Electrical and Electronics Engineers
  • the communication may utilize any proper wireless communication technology, comprising 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 Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and/or any other technologies currently known or to be developed in the future.
  • CDMA Code Division Multiple Access
  • FDMA Frequency Division Multiple Access
  • TDMA Time Division Multiple Access
  • FDD Frequency Division Duplex
  • TDD Time Division Duplex
  • MIMO Multiple-Input Multiple-Output
  • OFDM Orthogonal Frequency Division Multiple
  • DFT-s-OFDM Discrete Fourier Transform spread OFDM
  • the first device 110 and the second device 120 may operate on a shared frequency band (e.g., unlicensed spectrum) , so as to offload heavy traffic from licensed band to unlicensed spectrum on-demand.
  • a shared frequency band e.g., unlicensed spectrum
  • the unlicensed spectrum also provides additional opportunities to deploy private networks for various use cases such as shipping ports, mines airports, and so on.
  • MulteFire was an attempt to create a technology based connectivity option for internet of things deployments, exclusively operating in unlicensed spectrum, to help embrace the fourth industrial revolution. Operation in unlicensed spectrum has also been introduced for New Radio (NR) , and can also support highly reliable low latency use cases in verticals.
  • NR New Radio
  • a device may need to acquire the permission to access a channel for a certain period of time.
  • the procedure to acquire the permission is referred to as a channel access procedure.
  • the period of time for occupying the channel is referred as a channel occupancy time (COT) .
  • the channel access procedure may include a Listen Before Talk (LBT) procedure.
  • LBT Listen Before Talk
  • a device may apply an “extended” LBT procedure where the channel may needed to be deemed as free for the entire duration of a Contention Window (CW) .
  • This “extended” LBT procedure is commonly known as LBT Category 4 (LBT Cat. 4) or channel access Type 1.
  • a device may share the COT acquired by another device.
  • 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) .
  • the term “responding device” may refer to a device to which the initiating device performs the transmission.
  • the initiating device which has acquired a COT, may share the COT with one or more other devices with which it communicates, for example, a responding device.
  • the initiating device may inform (e.g., via control signaling) the responding device about the COT sharing information.
  • the responding device may be able to perform a transmission within the COT through a “reduced” LBT procedure.
  • LBT Cat. 2 LBT Cat. 2
  • LBT Category 1 LBT Cat. 1
  • channel access Type 2 There are several types of channel access Type 2 procedures that are selectable based on a time gap between two transmissions (e.g., DL and UL) to be performed within a COT.
  • the LBT Type 2 procedure may include a Type 2A procedure, a Type 2B procedure and a Type 2C procedure. Those variants are summarized as follows:
  • the massive industrial wireless sensor network supports not only ultra_reliable low latency (URLLC) services with very high reliability requirements, but also relatively low-end services with the requirement of small device form factors, and/or being completely wireless with a battery life of several years.
  • URLLC ultra_reliable low latency
  • NR-U New Radio-Unlicensed
  • channel access Type 1 Although two types of channel access are supported in the communication environment, the implementation complexity and power consumption of channel access Type 1 is much larger than that of channel access Type 2.
  • Low-complexity terminal devices e.g., sensors and asset tracking beacons, may only have capability of performing channel access Type 2 and thus may need to share COTs acquired by other devices (such as the network devices) .
  • some of the low-complexity devices may only support channel access Type 2C, i.e. no LBT, and thus may always rely on COTs shared by other devices.
  • a device relies on or prefers to utilize the COT sharing mechanism for transmissions, there may be a situation that this device has no chance to perform a transmission when no shared COT is available for use. For example, if a first device has a transmission to be performed but a second device does not acquire a COT (e.g., due to no data for transmissions or due to LBT failure) , the first device may need to wait until the following transmission occasion where the second device acquires a COT. In some cases, the first device may have configured transmissions to be performed at certain times, for example, transmissions over configured grant (CG) , transmissions of scheduling request (SR) , transmissions of physical random access channel (PRACH) , and/or transmissions of other data or signaling. Without a shared COT available, the latency requirements of the transmissions may be hard to be satisfied, and some transmissions may need to be abandoned.
  • CG configured grant
  • SR scheduling request
  • PRACH physical random access channel
  • Fig. 2 illustrates an example of a COT sharing mechanism for DL and UL between a terminal device and a network device.
  • the network device acquires and shares COTs with the terminal device.
  • the network device acquires a 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 with a UL periodicity.
  • the terminal device performs the UL transmissions 221 and 222 to the network devices in corresponding transmission occasions for the terminal device.
  • the network device does not acquire a COT in following periods because DL data is exhausted. Then the expected UL transmissions 223 and 224 may wait until following transmission occasions where the network device acquires a COT (s) .
  • a proactive COT request mechanism In this solution, a first device determines its buffer status. Depending on the buffer status, the first device proactively informs the second device of whether or not one or more COTs are requested. The second device may perform a channel access procedure depending on the indication information. Through the proactive COT request, the second device may be aware of the demand of shared COTs by the first device. Thus, the second device may determine whether or not to acquire one or more COTs to facilitate following transmissions from the first device. As such, it is possible to satisfy the low-latency requirement and/or high priority requirement for transmissions to be performed by the first device.
  • Fig. 3 shows a signaling flow 300 for communication according to some example embodiments of the present disclosure.
  • the signaling flow 300 involves a first device 110 and a second device 120.
  • Fig. 1 For the purpose of discussion, reference is made to Fig. 1 to describe the signaling flow 300.
  • the first device 110 currently has a COT 301 (sometimes referred to as “first COT” herein for the purpose of discussion) available for communication with the second device 120.
  • a COT 301 (sometimes referred to as “first COT” herein for the purpose of discussion) available for communication with the second device 120.
  • the first device 110 and the second device 120 may operate on a shared frequency band (unlicensed spectrum) .
  • the COT 301 may be acquired by the first device 110, for example, by a success of a channel access procedure performed on the shared frequency band.
  • the first device 110 may intend to initiate a transmission to the second device 120 or other device (s) on the shared radio frequency band, and thus acquire the COT 301.
  • the channel access procedure to obtain the COT may include a LBT Type 1 procedure.
  • the first device 110 may perform any other channel access procedure applicable for acquiring a COT.
  • the COT 301 may be acquired by the second device 120 and shared by the second device 120 with the first device 110.
  • the first device 110 may relay on the COT shared by other devices if it is not able to initiate a channel access procedure to actively acquire a COT for communication.
  • the first device 110 may be a low-complexity device and thus is configured to utilize COTs shared by other devices for the purpose of power saving and low processing complexity.
  • the embodiment related to sharing the COT 301 from the second device 120 to the first device 110 is illustrated in Fig. 3.
  • the second device 120 may acquire 302 the COT 301 and determine to share the acquired COT 301 with at least the first device 110.
  • the second device 120 may indicate 304 the COT 301 to the first device 110, for example, by transmitting a COT sharing indication to the first device 110.
  • the first device 110 may be able to determine the COT 301 that is available for communication with the second device 120.
  • the second device 120 may intend to initiate a transmission to the first device 110 or other device (s) on the shared radio frequency band, and thus acquire the COT 301.
  • the second device 120 may initiate a channel access procedure and a success of the channel access procedure may allow the second device 120 to acquire the COT 301.
  • the channel access procedure to obtain the COT may include a LBT Type 1 procedure.
  • the second device 120 may perform any other channel access procedure applicable for obtaining a COT.
  • the second device 120 may determine to share the COT 301 with the first device 110. It is noted that the second device 120 may also share the COT 301 with one or more other devices than the first device 110, which is not limited in this scope of the present disclosure. In some example embodiments, the second device 120 may provide the COT sharing indication together with data and/or other control information in a transmission to the first device 110.
  • the COT sharing indication may at least indicate a start point and a duration of the COT 301 shared with the first device 110.
  • the second device 120 may transmit other information that allows the first device 110 to perform a transmission (s) during the COT 301.
  • 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.
  • the first device 110 may perform one or more transmissions of data and/or control information to the second device 120.
  • the second device 120 may perform DL transmissions to the first device 110 and the first device 110 may perform UL transmissions to the second device 120.
  • the first device 110 determines 310 whether a buffer status of the first device 110. According to example embodiments of the present disclosure, the first device 110 is allowed to proactively inform the second device 120 whether one or more COTs are to be acquired and shared by the second device 120. During the COT 301, the first device 110 determines determine whether or not to request the one or more further COTs from the second device 120 based on its buffer status.
  • the first device 110 may determine, based on the buffer status, whether there is pending data to be transmitted at an end of the COT 301, and determine the indication information to be transmitted based on the determination about the pending data. That is, availability of the pending data after the currently available COT 301 is a trigger condition for the first device 110 to trigger the request. In some other example embodiments, some other trigger conditions may also be taken into account, as will be discussed in the following.
  • the first device 110 transmits 315, to the second device 120, indication information indicating whether the first device 110 requests one or more COTs (sometimes referred to as “second COTs” herein for the purpose of discussion) to be acquired and shared by the second device 120. That is, a COT sharing request or a COT sharing stop indicator may be piggybacked in a transmission performed to the second device 120.
  • the COT sharing request may indicate that the first device 110 requests one or more COTs to be acquired and shared by the second device 120
  • the COT sharing stop indicator may indicate that the first device 110 does not request additional COTs from the second device 120.
  • the example trigger conditions for the COT sharing request and the COT sharing stop indicator will be described in the following.
  • the transmission performed during the COT 301 may further indicate data and/or control information to be communicated to the second device 120.
  • the first device 110 may prepare a transport block (TB) including data to be transmitted to the second device 120.
  • the control information also referred to as control signaling or a control channel, may include a 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.
  • the first device 110 may perform the transmissions in corresponding transmission occasions of the resources during the COT shared by the second device 120.
  • the transmission comprising the indication information may be performed via a physical uplink shared channel (PUSCH) in the case where the first device 110 is a terminal device and the second device 120 is a network device.
  • PUSCH physical uplink shared channel
  • the transmissions 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.
  • a grant (such as a configured grant) for the first device 110 may have a periodicity and thus the transmission occasions for the first device 110 may occur with the periodicity.
  • the first device 110 may be allocated with resources with or without a periodicity to perform one or more transmissions during a COT. Depending on the grants or resources available for the transmissions, the first device 110 may have one or more transmission occasions during the COT 301.
  • the first device 110 may include indication information of requesting the COTs in the transmission performed during the COT 301.
  • the second device 120 may by default acquire COTs to share with the first device 110 unless the first device 110 determines that no more COTs are needed for a following period of time. In such a case, the first device 110 may include indication information indicating that no additional COT is requested.
  • the indication information may be in different forms to indicate various aspects about the COT (s) to be requested, example of which will be described below.
  • the indication information may comprise an indication (referred to as a “first indication” for the purpose of discussion) of whether the first device 110 requests a COT to be acquired and shared by the second device 120.
  • This first indication is a general indication used to indicate either a COT sharing request or a COT sharing stop indicator to the second device 120.
  • the first indication may be one-bit information, with a first value indicating the COT sharing request and a second value indicating the COT sharing stop indicator.
  • the first device 110 may indicate the desired length of COT sharing to the second device 120.
  • the indication information may additionally or alternatively comprise an indication (referred to as a “second indication” for the purpose of discussion) of the number of transmissions to be performed from the first device 110 to the second device 120.
  • the second indication may be multi-bit information to indicate the number.
  • the second indication may be comprised in the indication information when the first device 110 determines to request one or more additional COTs to be acquired and shared by the second device 120.
  • the number of transmissions may be indicated in terms of the number of transport blocks (TBs) (e.g., PUSCH TBs) to be transmitted to the second device 120 and/or the number of transmission occasions (e.g., CG-PUSCH occasions) .
  • the second indication may be indicated in terms of time units (e.g. ms) , from which the second device 120 may derive the number of TBs or transmission occasions.
  • the second indication may be determined as the number of COTs to be acquired, which may implicitly indicate the number of transmissions to be performed.
  • the first device 110 may determine the number of transmissions (e.g., the number of TBs, the number of transmission occasions, the time length, and/or the explicit number of COTs) based on the amount of pending data expected to be transmitted to the second device 120.
  • 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 transmit the data currently available in the buffer now.
  • the indication information may additionally or alternatively comprise an indication (referred to as a “third indication” for the purpose of discussion) of a priority (or traffic type) of pending data to be transmitted from the first device 110 to the second device 120.
  • the third indication may be comprised in the indication information when the first device 110 determines to request one or more additional COTs to be acquired and shared by the second device 120.
  • the priority of pending data may include a priority of a logical channel (LCH) to which the pending data belongs.
  • LCH logical channel
  • the first device 110 may indicate the highest LCH priority or the traffic type with the highest priority to the second device, or may alternatively indicate each of the LCH priorities or traffic types.
  • the information about the priority of pending data may be used by the second device 120 to decide whether it will acquire a COT (s) to share with the first device 110.
  • the second device 120 may determine to acquire the COT (s) when the first device 110 informs that pending data of a high priority (e.g., higher than a threshold priority) needs to be transmitted.
  • the third indication may be multi-bit information to indicate the priority (priorities) , or may be one-bit information to indicate whether pending data of a certain priority (a priority higher than a threshold priority) is to be transmitted by the first device 110.
  • the indication information may additionally or alternatively comprise an indication (referred to as a “fourth indication” for the purpose of discussion) of a channel access priority class (CAPC) to be utilized by the second device 120 to acquire one or more COTs.
  • the CAPC may have an impact on the probability of successfully acquiring a COT in a channel access procedure.
  • the CAPC may be associated with the LCH (s) of the pending data to be transmitted from the first device 110 to the second device 120.
  • the first device 110 may indicate the highest CAPC of the LCHs with pending data in the buffer so the second device 120 may be aware of which CAPC to use when initiating a channel access procedure.
  • the fourth indication may be multi-bit information to indicate the CAPC.
  • the fourth indication may be comprised in the indication information when the first device 110 determines to request one or more additional COTs to be acquired and shared by the second device 120.
  • the indication information may additionally or alternatively comprise information about a grant request for more grants from the second device during the at least one second channel occupancy time. More specifically, the indication information may comprise an indication (referred to as a “fifth indication” for the purpose of discussion) of whether more grants (or resources) within one or more following COTs are to be requested from the second device 120. In some examples, this fifth indication may be one-bit information to indicate whether currently configured resources are sufficient or whether the second device 120 can schedule dynamically more grants for the first device 110 to perform following transmissions in the following COTs.
  • the first device 110 may be able to determine the number of transmission occasions in following periods when a further COT is shared by the second device 120. If the first device 110 determines that the pending data may not be all transmitted using the determined transmission occasions, it may decide to request for more grants from the second device 120. Upon reception of the indication of such a request, the second device 120 may configure one or more dynamic grants in the following COT shared with the first device 110. In some example embodiments, the fifth indication may be comprised in the indication information when the first device 110 determines to request one or more additional COTs to be acquired and shared by the second device 120.
  • the indication information may comprise one or more of the above described indications, and may include other indications that are related to requesting or not requesting a COT (s) from the second device 120.
  • the inclusion of one or more above-mentioned indications may be used to implicitly indicate the request for the COT (s) .
  • the indication information may be conveyed to the second device 120 through various different approaches, example of which will be described below.
  • the indication information may be comprised in physical signaling, for example, control information transmitted to the second device 120.
  • the first device 110 may transmit control information together with other information and/or data to the second device 120.
  • the control information may be uplink control information (UCI) transmitted from the first device 110 to the second device 120.
  • UCI uplink control information
  • the indication information related to the COT sharing request or COT sharing stop indicator may be piggybacked in the control information.
  • the first device 110 may transmit, to the second device 120, the indication information in a last available transmission occasion during the current COT 301. That is, the first device 110 may not include the indication information in a transmission if the next transmission occasion for the first device 110 is still within the COT 301. This may avoid unnecessary signal overhead.
  • the indication information may be transmitted in any available transmission occasion during the current COT 301.
  • control information transmitted to the second device 120 may have a predefined format.
  • An example format for CG-UCI as defined in TS 38.212 is as follows in Table 1:
  • the higher layer parameter cg-COT-SharingList consists of C instances of CG-COT-Sharing-r16, defined in TS 38.331 as follows in Table 2.
  • the format of the control information may be updated to include an additional dedicated field to comprise the indication information.
  • This dedicated field may be defined with a corresponding bitwidth to specify one or more of the above mentioned indications.
  • the UCI may include an additional field to comprise the indication information.
  • the presence of the bits for the one or more indications in the control information may be configurable by the second device 120.
  • the indication information may be indicated with a specific value for a higher layer parameter of the control information.
  • a higher layer parameter related to COT sharing information from the first device 110 may be utilized for conveying the indication information.
  • the COT sharing information is provided when the first device 110 acquires a COT and shares the acquired COT with the second device 120.
  • the higher layer parameter CG-COT-Sharing-r16 in the COT sharing information may be re-defined to have a specific value for a field, e.g., the offset field, to indicate whether the first device 110 requests the one or more COTs from the second device 120.
  • the higher layer parameter CG-COT-Sharing-r16 may be re-defined as “CG-COT-Sharing-r17” as follows in Table 3.
  • the offset field (e.g., offset r-16) in the higher layer parameter CG-COT-Sharing-r16 previously has a valuing range from 1 to 39.
  • the offset (renamed from offset r-16 to “offset-r17” ) may have a new value of “40” to indicate that the first device 110 requests the one or more COTs from the second device 120, or to indicate that the first device 110 requests no more COTs from the second device 120.
  • the re-definition of the higher layer parameter may be configured by the second device 120 to the first device 110. By means of the re-definition, the second device 120 may consider the value of the offset as a COT sharing request from the first device 110 instead of an offset of COT sharing information related to a COT acquired by the first device 110.
  • other fields for the higher layer parameter may also be utilized to convey one or more other aspects of the indication information related to the COT sharing request and the COT sharing stop indicator.
  • the field channelAccessPriority may be interpreted as the CAPC of the one or more COTs to be requested, and the field duration may be interpreted as e.g. the number of transmissions to be performed to the second device 120.
  • a new higher layer parameter corresponding to the indication information related to the COT sharing request and the COT sharing stop indicator may be defined for the control information, more specifically, for the COT sharing information in the control information.
  • 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 the information element (IE) for the COT sharing information, e.g., the ConfiguredGrantConfig IE, which may be defined as follows in Table 4.
  • the new higher layer parameter CG-COT-Sharing-r17 may have a similar structure as new higher layer parameter CG-COT-Sharing-r16, which may be defined as follows in Table 5. In this case, the valuing range for the offset field may still be from 1 to 39.
  • the first device 110 may transmit the control information (e.g., UCI) using a combination of the CG-COT-Sharing-r17 and cg-COT-SharingList-r16.
  • the control information e.g., UCI
  • the first X entries in the COT sharing information are for the cg-COT-SharingList-r16, and other entries are for cg-COT-SharingList-r17.
  • the indication information may be indicated to the second device 120 via specific Hybrid Automatic Repeat reQuest (HARQ) process selection.
  • the HARQ process identifiers (also referred to as HARQ process numbers) may be split (e.g., semi-statically) into two groups.
  • a first group of the two groups may be associated with information related to a COT sharing request (e.g., that the first device 110 requests for one or more COTs from the second device)
  • a second group of the two groups may be associated with information related to not requesting for one or more COTs (e.g., a COT sharing stop indicator) .
  • such a mapping between the HARQ process identifiers and the indication information may be pre-configured, for example, via radio resource control (RRC) signaling from the second device 120.
  • RRC radio resource control
  • the first device 110 may select a HARQ process identifier from the first group. In some cases, if the first device 110 determines not to request one or more COT after the COT 301, it may select a HARQ process identifier from the second group. The first device 110 may perform a transmission using the selected HARQ process identifier. In some examples, the selected HARQ process identifier may be transmitted to the second device 120 in the field of “HARQ process number” in the control information, as can be seen from the example control information in Table 1. In this way, the first device 110 may be able to indicate whether an additional COT (s) is needed by selecting the HARQ process identifier.
  • the indication information of whether or not to request one or more COTs may be applicable in an initial transmission during the HARQ process, for example, when the field of new data indicator (NDI) in the control information indicates that new data is transmitted. This is because a retransmission in the HARQ process may inherit the HARQ process identifier used in the initial transmission.
  • NDI new data indicator
  • the indication information may be indicated to the second device 120 via specific reference signal resource selection.
  • the first device 110 may be configured (e.g., semi-statically) by the second device 120 with a set of resources for transmitting a reference signal.
  • the reference signal may be transmitted by the first device 110 to the second device 120. Examples of such a reference signal may include a sounding reference signal (SRS) , a demodulation reference signal (DMRS) , and/or any other reference signals.
  • SRS sounding reference signal
  • DMRS demodulation reference signal
  • the resources in the set of resources for the reference signal may be different in the time domain, frequency domain, and/or code domain (different signal sequences for the reference signal) .
  • 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., that the first device 110 requests for one or more COTs from the second device 120) , and another resource may be associated with information related to not requesting for one or more COTs.
  • this framework of reference signal resource selection may be further exploited to allow indication of more information by providing the first device 110 with more resources for the reference signal.
  • different resources may be associated with indications of the number of transmissions to be performed by the first device 110, the need of further resources to be scheduled by the second device 120, and/or the like.
  • such a mapping between the resources for the reference signal and the indication information may be configured by the second device 120.
  • the indication information may be comprised in MAC signaling, for example, in a MAC CE.
  • a new MAC CE may be defined for the indication information.
  • the size of the MAC CE may be varied as needed, more indications may be comprised in the MAC CE and communicated to the second device 120 in the case that the first device 110 determines to requests an additional COT (s) .
  • the MAC CE may include the COT sharing request or the COT sharing stop indicator.
  • the MAC CE may comprise other information as discussed above, including the number of transmissions to be performed, the CAPC for use by the second device 120, the priority of the LCH of the pending data, the indication of whether or not to request for more grants during the following COTs to be shared.
  • the first device 110 may transmit a buffer status report (BSR) as the indication information.
  • the BSR may be transmitted as a BSR MAC CE.
  • the trigger conditions for the COT sharing request or the COT sharing stop indicator may be considered as the trigger conditions for triggering the BSR.
  • the first device 110 may transmit a BSR indicating the size of pending data in the buffer to act as the COT sharing request if it decides to request one or more following COTs from the second device 120.
  • the first device 110 may transmit an empty BSR to act as the COT sharing stop indicator if it decides not to request additional COTs from the second device 120.
  • the specific MAC CE or the BSR may be transmitted to the second device 120 in any of the transmission occasions during the currently available COT 301.
  • the first device 110 may determine an appropriate transmission occasion within the COT 301 for transmitting the BSR.
  • the transmission occasion may be determined in such a way that there is time left for the second device 120 to decode the BSR before the end of the COT 301. This may avoid potential delay for acquiring the requested COTs for the first device 110.
  • the specific MAC CE or the BSR may be transmitted by the first device 110 to the second device 120 in a last available transmission occasion during the COT 301.
  • the BSR may indicate the estimated size of pending data remained after the currently available COT 301 if the BSR is not transmitted in the last available transmission occasion in the COT 301.
  • the second device 120 may determine how many data needed to be transmitted from the first device 110.
  • the BSR may indicate the size of pending data stored in the buffer when the BSR is transmitted. The second device 120 may be able to estimate the size of pending data remained after the COT 301, based on the number of transmission occasions remained in the COT 301 for the first device 110 to transmit data.
  • 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 or not to acquire one or more COTs to share with the first device 110. In this way, the BSR may be considered as an implicit COT sharing request or a COT sharing stop indicator (in the case of empty BSR) to allow the first device 110 to request or to stop the COT sharing.
  • the 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 employing other means, and the scope of the present disclosure is not limited in this regard.
  • the first device 110 determines whether or not to request one or more COTs based on the buffer status. More specifically, the first device 110 determines, based on the buffer status, whether there is pending data or control signaling to be transmitted to the second device 120 at the end of the currently available COT 301.
  • the first device 110 may transmit, to the second device 120, the COT sharing request and/or possible other related information (e.g., the number of transmissions to be performed after the COT 301, the CAPC, the priority of the LCH, the grant request, or the like) .
  • the first device 110 may determine not to transmit the COT sharing request, or may determine to transmit the COT sharing stop indicator to the second device 120. In some example embodiments, if the first device 110 is configured to transmit certain data or control signaling with a periodicity or if the first device 110 estimates that more data will arrive after the COT 301, then the first device 110 may determine to request one or more following COTs from the second device 120.
  • the first device 110 may determine whether or not 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 or not to request one or more COTs based on a priority or priorities of the pending data which is to be transmitted to the second device 120, a parameter (s) or setting (s) of the LCH (s) to which the pending data belongs, a latency requirement of the pending data, and/or a mapping restriction of the pending data with respect to at least one grant configured for the first device.
  • the first device 110 may be configurable that the first device 110 is allowed to transmit the indication information about requesting one or more COTs (e.g., the COT sharing request) for data with a certain priority (e.g., higher than a threshold priority) .
  • the threshold priority may be configured by the second device 120 or predefined.
  • the first device 110 may be allowed to transmit the COT sharing request if pending data of certain LCHs are to be transmitted. For example, if a LCH with pending data has a high priority (e.g., higher than a threshold priority) and/or has a high CAPC (e.g., higher than a threshold class) , then the first device 110 may transmit the COT sharing request.
  • a high priority e.g., higher than a threshold priority
  • CAPC e.g., higher than a threshold class
  • the first device 110 may not transmit the COT sharing request or may transmit the COT sharing stop indicator instead.
  • the threshold class may be configured by the second device 120 or predefined.
  • the first device 110 may be allowed to transmit the COT sharing request if the latency requirement of the pending data meets a latency criterion.
  • a latency criterion may be defined based on a latency requirement of certain traffic type, e.g., URLLC.
  • URLLC a latency requirement of certain traffic type
  • the first device 110 may transmit the indication information about requesting one or more COTs.
  • the first device 110 may not transmit the COT sharing request or may transmit the COT sharing stop indicator instead.
  • the indication information of requesting one or more COTs may be allowed to be triggered on one or more specific grants.
  • the first device 110 may be configured with a mapping restriction of the pending data with respect to at least one grant configured for the first device 110.
  • the mapping restriction indicates whether pending data of a LCH is allowed to be mapped to a certain grant (e.g., a configured grant) .
  • the first device 110 may determine whether the pending data to be transmitted after the COT 301 is allowed to be mapped to one or more configured grants, or to one or more grants that become available in a following period of time (which may possibly be within a requested COT to be shared from the second device 120) .
  • the first device 110 may determine whether one or more configured grants become available in a following period of time. If the pending data is not allowed to be mapped to the foreseeable grants, the first device 110 may not transmit the COT sharing request to the second device 120, or may transmit the COT sharing stop indicator instead. Otherwise, if the pending data can be mapped to the foreseeable grants, the first device 110 may transmit the COT sharing request.
  • the first device 110 may be configured with a COT request restriction with respect to grants.
  • the proactive COT request mechanism may be configured to be applicable for one or more certain grants. If the first device 110 is configured with the one or more grants to which the proactive COT request mechanism is applicable and those grants are available in a certain period of time after the COT 301, the first device 110 may determine to transmit the COT sharing request to the second device 120. Otherwise, if the first device 110 is not configured with such grants, the first device 110 may not transmit the COT sharing request, or may transmit the COT sharing stop indicator instead.
  • the transmission of the indication of requesting one or more COTs may be performed based on an instruction from the second device 120.
  • the second device 120 may transmit an instruction whether the first device 110 is allowed to request one or more COTs.
  • This instruction may be included in a control element (CE) , e.g., in a media access control (MAC) CE, in a physical downlink control channel (PDCCH) , or via RRC signaling, that is transmitted from the second device 120 to the first device 110.
  • CE control element
  • MAC media access control
  • PDCCH physical downlink control channel
  • RRC signaling Radio Resource Control
  • the first device 110 may generate and transmit the indication information to the second device 120, to indicate that the first device 110 requests or not to request one or more COTs to be acquired and shared by the second device 120. Conversely, if the second device 120 does not ask the first device 110 to provide the indication information, the first device 110 may not include the indication information regardless of its need.
  • Some example trigger conditions for the indication information about the COT sharing request and the COT stop indicator have been discussed above. It would be appreciated that the first device 110 may apply any combination of those trigger conditions to decide whether or not to request one or more following COTs from the second device 120.
  • the second device 120 receives 320, from the first device 110, the transmission comprising at least the indication information of whether the first device 110 requests one or more COTs to be acquired and shared by the second device 120.
  • the second device 120 performs 325 a channel access procedure based on the indication information.
  • the channel access procedure may include, for example, a LBT Type 1 procedure, although other channel access procedure is also possible.
  • the second device 120 may initiate a channel access procedure to acquire a COT after the COT 301 even if the second device 120 does not need to perform further 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 further determine the number of COTs to be acquired and shared with the first device 110, and/or the CAPC to be utilized in acquiring the COTs, whether or not to allocate more grants for the first device 110 to perform transmissions in the following COT.
  • the second device 120 in response to a success of the channel access procedure, may be able to acquire an additional COT after the COT 301.
  • the second device 120 may also indicate the acquired COT to the first device 110, to allow the first device 110 to share this COT.
  • the second device 120 may not initiate a channel access procedure after the COT 301 unless the second device 120 has further transmissions to be performed to the first device 110 or other devices.
  • the second device 120 may make the decision about whether or not to initiate a channel access procedure to acquire a COT according to one or more other factors, for example, based on the priority or LCH of data to be transmitted from the first device 110, the workload on the shared frequency band, and/or the like.
  • the second device 120 may not always initiate a channel access procedure to acquire a COT following the COT 301.
  • the second device 120 may perform the channel access procedure to acquire a COT, for example, for further transmissions to be performed by the second device 120. Therefore, the scope of the present disclosure is not limited in this regard.
  • the first device 110 may transmit indication information of requesting no more COTs (i.e., the COT sharing stop indicator) to the second device 120 during an on-going COT.
  • the second device 120 may assume further COTs are needed after reception of the COT sharing request from the first device 110 until otherwise indicated, for example, when the COT sharing stop indicator is received.
  • the second device 120 may acquire a number of COTs to share with the first device 110 so that the first device 110 can perform the requested number of transmissions or transmit the buffered data as indicated in the BSR.
  • 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 no COT is needed by the first device 110, for example, based on the data multiplexed in the received transmission. For example, if the first device 110 starts to transmit data with a lower priority or latency requirement or data in a LCH that is not allowed for requesting for additional COTs, the second device 120 may determine not to request more COTs for the first device 110 unless the second device 120 has its transmission to initiate.
  • Fig. 4 shows a flowchart of an example method 400 implemented at a first device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 400 will be described from the perspective of the first device 110 in Fig. 1.
  • the first device 110 determines a buffer status of the first device 110.
  • the first device 110 transmits, based at least in part on the buffer status of the first device 110, indication information to the second device 120 during a first channel occupancy time.
  • the first channel occupancy time is currently available for the first device 110 to communicate with the second device 120.
  • the indication information indicates whether the first device 110 requests at least one second channel occupancy time to be acquired and shared by the second device 120.
  • the first device 110 may determine, based on the buffer status, whether there is pending data to be transmitted at an end of the first channel occupancy time. Based at least in part on a determination that there is pending data to be transmitted at an 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, to request for the at least one second channel occupancy time to be acquired and shared by the second device.
  • the first device 110 may transmit the channel occupancy time sharing request and additional information about at least one of the following: the number of transmissions to be performed from the first device to the second device after the first channel occupancy time, a channel access priority class to be utilized by the second device to acquire the at least one second channel occupancy time, a priority of a logical channel to which the pending data belongs, and a grant request for more grants from the second device during the at least one second channel occupancy time.
  • the first device 110 may determine, based on the buffer status, whether there is pending data to be transmitted at an end of the first channel occupancy time. Based at least in part on a determination that there is no 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 stop indicator to the second device, to indicate that no channel occupancy time is to be acquired and shared by the second device.
  • the first device 110 may transmit at least the channel occupancy time sharing request further based on at least one characteristic of the pending data.
  • the at least one characteristic of the pending data comprises at least one of the following: a priority of a logical channel to which the pending data belongs, a channel access priority class of the logical channel to which the pending data belongs, a latency requirement of the pending data, and a mapping restriction of the pending data with respect to at least one grant configured for the first device.
  • the first device 110 may transmit at least the channel occupancy time sharing request to the second device 120 further based on at least one of the following: the priority of the logical channel being above a threshold priority, the channel access priority class of the logical channel being above a threshold class, the latency requirement of the pending data meeting a latency criterion, and the mapping restriction indicating that the pending data is allowed to be mapped to the at least one grant configured for the first device.
  • the first device 110 may transmit the indication information in a medical access control control element or in physical control information.
  • the first device 110 may transmit a buffer status report as the indication information.
  • Different types of buffer status reports may be used to indicate the channel occupancy time sharing request or the channel occupancy time stop indicator.
  • the first device comprises a terminal device
  • the second device comprises a network device
  • a first apparatus capable of performing any of the method 400 may comprise means for performing the respective operations of the method 400.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the first apparatus may be implemented as or included in the first device 110 in Fig. 1.
  • the first apparatus comprises means for determining a buffer status of the first apparatus; and means for transmitting, based at least in part on the buffer status of the first apparatus, indication information to a second apparatus (for example, the second device 120 in Fig. 1) during a first channel occupancy time, the indication information indicating whether the first apparatus requests at least one second channel occupancy time to be acquired and shared by the second apparatus.
  • a second apparatus for example, the second device 120 in Fig. 1
  • the means for transmitting the indication information comprises: means for determining, based on the buffer status, whether there is pending data to be transmitted at an end of the first channel occupancy time; and means for transmitting, based at least in part on a determination that there is pending data to be transmitted at the end of the first channel occupancy time, at least a channel occupancy time sharing request to the second apparatus, to request for the at least one second channel occupancy time to be acquired and shared by the second apparatus.
  • the means for transmitting at least the channel occupancy time sharing request comprises: means for transmitting, based at least in part on a determination that there is pending data to be transmitted at the end of the first channel occupancy time, the channel occupancy time sharing request and information about at least one of the following: the number of transmissions to be performed from the first apparatus to the second apparatus after the first channel occupancy time, a channel access priority class to be utilized by the second apparatus to acquire the at least one second channel occupancy time, a priority of a logical channel to which the pending data belongs, and a grant request for more grants from the second apparatus during the at least one second channel occupancy time.
  • the means for transmitting the indication information further comprises: means for determining, based on the buffer status, whether there is pending data to be transmitted at an end of the first channel occupancy time; and means for transmitting, based at least in part on a determination that there is no pending data to be transmitted at the end of the first channel occupancy time, a channel occupancy time sharing stop indicator to the second apparatus, to indicate that no channel occupancy time is to be acquired and shared by the second apparatus.
  • the means for transmitting at least the channel occupancy time sharing request further comprises: means for transmitting at least the channel occupancy time sharing request further based on at least one characteristic of the pending data.
  • the at least one characteristic of the pending data comprises at least one of the following: a priority of a logical channel to which the pending data belongs, a channel access priority class of the logical channel to which the pending data belongs, a latency requirement of the pending data, and a mapping restriction of the pending data with respect to at least one grant configured for the first apparatus.
  • 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 transmitting at least the channel occupancy time sharing request to the second apparatus further based on at least one of the following: the priority of the logical channel being above a threshold priority, the channel access priority class of the logical channel being above a threshold class, the latency requirement of the pending data meeting a latency criterion, and the mapping restriction indicating that the pending data is allowed to be mapped to the at least one grant configured for the first appratus.
  • the means for transmitting the indication information comprises: means for transmitting the indication information in a medical access control control element or in physical control information.
  • the means for transmitting the indication information comprises: means for transmitting a buffer status report as the indication information.
  • the first apparatus comprises a terminal device
  • the second apparatus comprises a network device
  • the first apparatus further comprises means for performing other operations in some example embodiments of the method 400 or the first device 110.
  • the means comprises at least one processor; and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the first apparatus.
  • Fig. 5 is a simplified block diagram of a device 500 that is 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.
  • the device 500 includes one or more processors 510, one or more memories 520 coupled to the processor 510, and one or more communication modules 540 coupled to the processor 510.
  • the communication module 540 is for bidirectional communications.
  • the communication module 540 has one or more communication interfaces to facilitate communication with one or more other modules or devices.
  • the communication interfaces may represent any interface that is necessary for communication with other network elements.
  • the communication module 540 may include at least one antenna.
  • the processor 510 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples.
  • the device 500 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.
  • the memory 520 may include one or more non-volatile memories and one or more volatile memories.
  • the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 524, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , an optical disk, a laser disk, and other magnetic storage and/or optical storage.
  • Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 522 and other volatile memories that will not last in the power-down duration.
  • a computer program 530 includes computer executable instructions that are executed by the associated processor 510.
  • the program 530 may be stored in the memory, e.g., ROM 524.
  • the processor 510 may perform any suitable actions and processing by loading the program 530 into the RAM 522.
  • the example embodiments of the present disclosure may be implemented by means of the program 530 so that the device 500 may perform any process of the disclosure as discussed with reference to Figs. 3 to 4.
  • the example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.
  • the program 530 may be tangibly contained in a computer readable medium which may be included in the device 500 (such as in the memory 520) or other storage devices that are accessible by the device 500.
  • the device 500 may load the program 530 from the computer readable medium to the RAM 522 for execution.
  • the computer readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like.
  • Fig. 6 shows an example of the computer readable medium 600 which may be in form of CD, DVD or other optical storage disk.
  • the computer readable medium has the program 530 stored thereon.
  • various embodiments of the present 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 embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method 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 includes computer-executable instructions, such as those included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above with reference to Figs. 3 to 5.
  • program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types.
  • the functionality of the program modules may be combined or split between program modules as desired in various embodiments.
  • Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.
  • Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes 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 codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented.
  • the program code may execute entirely on a 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.
  • the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above.
  • Examples of the carrier include a signal, computer readable medium, and the like.
  • the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
  • a computer readable medium may include but 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 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.

Landscapes

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

Abstract

Des exemples de modes de réalisation de la présente divulgation concernent une demande de temps d'occupation de canal proactive (COT). Un premier dispositif détermine un état de tampon du premier dispositif et transmet, sur la base, au moins en partie, de l'état de tampon du premier dispositif, des informations d'indication au second dispositif pendant le premier COT, les informations d'indication indiquant si le premier dispositif demande au moins un second COT à acquérir et partager par le second dispositif.
PCT/CN2021/117136 2021-09-08 2021-09-08 Demande de cot proactive WO2023035140A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2021/117136 WO2023035140A1 (fr) 2021-09-08 2021-09-08 Demande de cot proactive
CN202180102166.2A CN117999813A (zh) 2021-09-08 2021-09-08 主动cot请求

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/117136 WO2023035140A1 (fr) 2021-09-08 2021-09-08 Demande de cot proactive

Publications (1)

Publication Number Publication Date
WO2023035140A1 true WO2023035140A1 (fr) 2023-03-16

Family

ID=85506142

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/117136 WO2023035140A1 (fr) 2021-09-08 2021-09-08 Demande de cot proactive

Country Status (2)

Country Link
CN (1) CN117999813A (fr)
WO (1) WO2023035140A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019192446A1 (fr) * 2018-04-04 2019-10-10 华为技术有限公司 Procédé et dispositif de programmation de demande
WO2019215670A1 (fr) * 2018-05-11 2019-11-14 Nokia Technologies Oy Agencement de canal d'accès aléatoire physique pour une nouvelle radio sans licence
US20200154471A1 (en) * 2018-11-09 2020-05-14 Qualcomm Incorporated Prach and sr transmissions for new radio in unlicensed spectrum
WO2020125180A1 (fr) * 2018-12-20 2020-06-25 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil de partage de canal de communication

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019192446A1 (fr) * 2018-04-04 2019-10-10 华为技术有限公司 Procédé et dispositif de programmation de demande
WO2019215670A1 (fr) * 2018-05-11 2019-11-14 Nokia Technologies Oy Agencement de canal d'accès aléatoire physique pour une nouvelle radio sans licence
US20200154471A1 (en) * 2018-11-09 2020-05-14 Qualcomm Incorporated Prach and sr transmissions for new radio in unlicensed spectrum
WO2020125180A1 (fr) * 2018-12-20 2020-06-25 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil de partage de canal de communication

Also Published As

Publication number Publication date
CN117999813A (zh) 2024-05-07

Similar Documents

Publication Publication Date Title
WO2021035393A1 (fr) Configuration de retransmission dynamique
AU2019460320B2 (en) Sharing HARQ processes by multiple configured grants resources
US11722998B2 (en) Methods and devices for transmission by selecting between uplink resources
WO2021072658A1 (fr) Retransmission en liaison montante sur la base d'un service
JP2023065547A (ja) 端末装置、ネットワークデバイス、及び方法
WO2022205451A1 (fr) Procédé, dispositif et support lisible par ordinateur pour la communication
WO2022036590A1 (fr) Mécanisme de priorisation de transmissions
WO2022027645A1 (fr) Support lisible par ordinateur, procédés, et dispositifs de communication
WO2023035140A1 (fr) Demande de cot proactive
WO2023035148A1 (fr) Demande de cot proactive
WO2024098229A1 (fr) Déclenchement d'informations de faisceau pour activation de cellule
US20240195535A1 (en) Harq process selection
WO2024138445A1 (fr) Configuration de sous-bande pour duplex intégral sans chevauchement de sous-bande
WO2023010270A1 (fr) Saut d'autorisation pour une procédure de transmission de petites données
WO2022213238A1 (fr) Transmission fiable sur des bandes sous licence et sans licence
WO2024031482A1 (fr) Amélioration de transmission de rétroaction de liaison latérale
WO2023225874A1 (fr) Procédé et appareil de rapport de marge de puissance
US20210306124A1 (en) Scheduling release feedback
US20240080834A1 (en) Uplink Skipping
US20240260058A1 (en) Transmisison of feedback information
WO2024093108A1 (fr) Dispositif terminal et procédé de communications de liaison latérale
WO2022252122A1 (fr) Transmission d'informations de rétroaction
WO2024092572A1 (fr) Planification multi-créneau dans un contexte de sbfd
WO2024065790A1 (fr) Mappage de fréquence de sous-canal de liaison latérale
WO2021232354A1 (fr) Gestion de demande de planification

Legal Events

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

Ref document number: 21956329

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202180102166.2

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE