WO2024216864A1

WO2024216864A1 - A method for multi-stage downlink control information transmission in wireless access network

Info

Publication number: WO2024216864A1
Application number: PCT/CN2023/122222
Authority: WO
Inventors: Chunli Liang; Xingguang WEI; Jian Li; Zhaohua Lu; Jing Shi; Xianghui HAN
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2023-09-27
Filing date: 2023-09-27
Publication date: 2024-10-24
Anticipated expiration: 2026-03-27

Abstract

This disclosure is directed generally to wireless communications and more specifically to flexible construction and transmission of downlink control information (DCI). Specifically, a multi-stage (e.g., two-stage) DCI construction and transmission scheme is designed, where multiple DCIs are constructed as separate stages by a wireless network node and transmitted to a UE to jointly provide UE downlink and uplink assignment and/or grant. While a first-stage DCI among the multiple DCI stages may be constructed and transmitted in one of a set of predefined DCI formats in order to facilitate efficient blind detection by the UE, the second-stage DCI may be flexibly constructed and transmitted with its formatting information (such as bit length), content information (such as DCI fields it contains), and/or reception information (such as its frequency/time resource identification) being indicated in the first-stage DCI.

Description

A METHOD FOR MULTI-STAGE DOWNLINK CONTROL INFORMATION TRANSMISSION IN WIRELESS ACCESS NETWORK

TECHNICAL FIELD

This disclosure is directed generally to wireless communications and more specifically to flexible construction and transmission of downlink control information (DCI) .

BACKGROUND

Wireless communication technologies are moving the world toward an increased network connectivity. Wireless communications rely on efficient network resource management and allocation between user stations and wireless access network nodes (including but not limited to wireless base stations) in a highly mobile environment. A new generation network is expected to provide high speed, low latency and ultra-reliable communication capabilities and to fulfil the requirements from different industries and users. User mobile stations or user equipment (UE) are becoming more complex in order to handle increasing amount of data communications. Flexibility in formatting and transmitting control information involving UE downlink and uplink resource assignment and/or grant may be improved upon in order to enhance network efficiency.

SUMMARY

This disclosure is directed generally to wireless communications and more specifically to flexible construction and transmission of downlink control information (DCI) . Specifically, a multi-stage (e.g., two-stage) DCI construction and transmission scheme is designed, where multiple DCIs are constructed as separate stages by a wireless network node and transmitted to a UE to jointly provide UE downlink and uplink assignment and/or grant. While a first-stage DCI among the multiple DCI stages may be constructed and transmitted in one of a set of predefined DCI formats in order to facilitate efficient blind detection by the UE, the second-stage DCI may be flexibly constructed and transmitted with its formatting information (such as bit length) , content information (such as DCI fields it contains) , and/or reception information (such as its frequency/time resource identification) being indicated in the first-stage DCI.

In some implementations, a method performed by a wireless network node is disclosed. The method may include transmitting a set of downlink control information (DCI) to a user equipment (UE) in two separate stages as a stage-I DCI and a stage-II DCI. The stage-I DCI and the stage-II DCI jointly control an assignment or grant for the UE. A bit length of the stage-II DCI is derived from information carried in the stage-I DCI.

In some other implementations, another method performed by a UE is disclosed. The method may include monitor and receive a stage-I downlink control information (DCI) from a wireless network node; determine a DCI size of a stage-II DCI based on information carried in the stage-I DCI, the stage-II DCI being transmitted by the wireless network node separately from the stage-I DCI; and receiving the stage-II DCI from the wireless network node based the DCI size as determined from the stage-I DCI; and determine a grant or assignment for the UE based on the stage-II DCI.

In any one of the implementations above, the stage-I DCI is of one of a set of predefined or configurable bit lengths and is identified as one of a predefined set of DCI formats.

In any one of the implementations above, the stage-I DCI comprises a bitmap for a plurality of DCI field combinations, each bit of the bitmap corresponding to a DCI field combination among the plurality of DCI field combinations, and each bit indicating a presence or absence of the corresponding DCI field combination in the stage-II DCI or indicating a configuration state of the corresponding DCI field combination in the stage-II DCI.

In any one of the implementations above, a size of the bitmap is predefined to represent a number of all allowed DCI field combinations.

In any one of the implementations above, the plurality of DCI field combinations corresponds to a DCI field configuration among a set of possible DCI field configurations; and the stage-I DCI further comprise a configuration index for identifying the DCI field configuration among the set of possible DCI field configurations.

In any one of the implementations above, the set of possible DCI field configurations and indexes thereof are informed to the UE by the wireless network node using one or more radio resource control (RRC) messages.

In any one of the implementations above, each DCI field combination of the plurality of DCI field combinations comprises one or more related DCI fields.

In any one of the implementations above, each DCI field combination of the plurality of DCI field combinations comprises a single DCI field.

In any one of the implementations above, bit widths of the one or more DCI fields associated with each of the plurality of DCI field combinations are further indicated in the one or more RRC messages.

In any one of the implementations above, the one or more RRC messages further define DCI filed components of each DCI field combination of the plurality of DCI field combinations.

In any one of the implementations above, the stage-I DCI further comprises information pertaining to the stage-II DCI.

In any one of the implementations above, wherein a bit width for the information pertaining to the stage-II DCI as contained in the stage-I DCI is predefined or configured via RRC.

In any one of the implementations above, the information pertaining to the stage-II DCI comprises at least one of: a frequency and/or time resource allocation of the stage-II DCI; a start control channel element (CCE) of the stage-II DCI; a physical layer processing procedure indicator for the stage-II DCI; a first duration for validly applying the stage-II DCI; a second duration for monitoring the stage-II DCI; or beam information with respect to the stage-II DCI.

In any one of the implementations above, the stage-I DCI further comprises information pertaining to a next stage-I DCI.

In any one of the implementations above, wherein a bit width for the information pertaining to the next stage-I DCI as contained in the stage-I DCI is predefined or configured via RRC.

In any one of the implementations above, the information pertaining to the next stage-I DCI comprises at least one of: a frequency and/or time resource allocation of the next stage-I DCI; a start control channel element (CCE) of the next stage-I DCI; a period of the stage-I DCI.

In any one of the implementations above, wherein the stage-II DCI comprises DCI fields within the plurality of DCI field combinations that are indicated by the bitmap of the Stage-I DCI as being present and as having a configuration state.

In any one of the implementations above, the stage-II DCI comprises a predefined number of reserved bits.

In any one of the implementations above, at least a portion of the reserved bits of the stage-II DCI comprise indicate whether the stage-II DCI is used for uplink scheduling or downlink assignment.

In any one of the implementations above, at least a portion of the reserved bits of the stage-II DCI indicate beam information for a next stage-I DCI.

In some other implementations, a wireless communications apparatus is disclosed. The wireless communication apparatus may include a processor and a memory, wherein the processor is configured to read code from the memory and implement any one of the methods above.

In yet some other implementations, a non-transitory computer readable medium is disclosed. The non-transitory computer readable medium may include computer instructions, when executed by a processor of a wireless communication device, may cause the wireless communication device to implement any one of the methods above.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example wireless communication network including a wireless access network, a core network, and data networks.

FIG. 2 illustrates an example wireless access network including a plurality of mobile stations/terminals or User Equipments (UEs) and a wireless access network node in communication with one another via an over-the-air radio communication interface.

FIG. 3 shows an example radio access network (RAN) architecture.

FIG. 4 shows an example communication protocol stack in a wireless access network node or wireless terminal device including various network layers.

FIG. 5 illustrates various control and data channels between a wireless network node and a wireless terminal.

FIG. 6 illustrates validity time duration for applying a second-stage DCI in a two-stage DCI implementation.

FIG. 7 illustrates monitoring duration for a second-stage DCI in a two-stage DCI implementation.

FIG. 8 illustrates an example first-stage DCI and second-stage DCI in a two-stage DCI implementation.

FIG. 9 illustrates another example first-stage DCI and second-stage DCI in a two-stage DCI implementation.

FIG. 10 illustrates another example first-stage DCI and second-stage DCI in a two-stage DCI implementation.

FIG. 11 illustrates yet another example first-stage DCI and second-stage DCI in a two-stage DCI implementation.

DETAILED DESCRIPTION

The present disclosure will now be described in detail hereinafter with reference to the accompanied drawings, which form a part of the present disclosure, and which show, by way of illustration, specific examples of embodiments. Please note that the present disclosure may, however, be embodied in a variety of different forms and, therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the embodiments to be set forth below.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment” or “in some embodiments” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment” or “in other embodiments” as used herein does not necessarily refer to a different embodiment. The phrase “in one implementation” or “in some implementations” as used herein does not necessarily refer to the same implementation and the phrase “in another implementation” or “in other implementations” as used herein does not necessarily refer to a different implementation. It is intended, for example, that claimed subject matter includes combinations of exemplary embodiments or implementations in whole or in part.

In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and/or, ” as used herein may include a variety of meanings that may depend at least in part upon the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” or “at least one” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a” , “an” , or “the” , again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” or “determined by” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

Wireless Network Overview

An example wireless communication network, shown as 100 in FIG. 1, may include wireless terminal devices or user equipment (UE) 110, 111, and 112, a carrier network 102, various service applications 140, and other data networks 150. The wireless terminal devices or UEs, may be alternatively referred to as wireless terminals. The carrier network 102, for example, may include access network nodes 120 and 121, and a core network 130. The carrier network 110 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) among UEs 110, 111, and 112, between the UEs and the service applications 140, or between the UEs and the other data networks 150. The access network nodes 120 and 121 may be configured as various wireless access network nodes (WANNs, alternatively referred to as wireless base stations) to interact with the UEs on one side of a communication session and the core network 130 on the other. The term “access network” may be used more broadly to refer a combination of the wireless terminal devices 110, 111, and 112 and the access network nodes 120 and 121. A wireless access network may be alternatively referred to as Radio Access Network (RAN) . The core network 130 may include various network nodes configured to control communication sessions and perform network access management and traffic routing. The service applications 140 may be hosted by various application servers deployed outside of but connected to the core network 130. Likewise, the other data networks 150 may also be connected to the core network 130.

In the example wireless communication network of 100 of FIG. 1, the UEs may communicate with one another via the wireless access network. For example, UE 110 and 112 may be connected to and communicate via the same access network node 120. The UEs may communicate with one another via both the access networks and the core network. For example, UE 110 may be connected to the access network node 120 whereas UE 111 may be connected to the access network node 121, and as such, the UE 110 and UE 111 may communicate to one another via the access network nodes 120 and 121, and the core network 130. The UEs may further communicate with the service applications 140 and the data networks 150 via the core network 130. Further, the UEs may communicate to one another directly via side link communications, as shown by 113.

FIG. 2 further shows an example system diagram of the wireless access network 120 including a WANN 202 serving UEs 110 and 112 via the over-the-air interface 204. The wireless transmission resources for the over-the-air interface 204 include a combination of frequency, time, and/or spatial resource. Each of the UEs 110 and 112 may be a mobile or fixed terminal device installed with mobile access units such as SIM/USIM modules for accessing the wireless communication network 100. The UEs 110 and 112 may each be implemented as a terminal device including but not limited to a mobile phone, a smartphone, a tablet, a laptop computer, a vehicle on-board communication equipment, a roadside communication equipment, a sensor device, a smart appliance (such as a television, a refrigerator, and an oven) , or other devices that are capable of communicating wirelessly over a network. As shown in FIG. 2, each of the UEs such as UE 112 may include transceiver circuitry 206 coupled to one or more antennas 208 to effectuate wireless communication with the WANN 120 or with another UE such as UE 110. The transceiver circuitry 206 may also be coupled to a processor 210, which may also be coupled to a memory 212 or other storage devices. The memory 212 may be transitory or non-transitory and may store therein computer instructions or code which, when read and executed by the processor 210, cause the processor 210 to implement various ones of the methods described herein.

Similarly, the WANN 120 may include a wireless base station or other wireless network access point capable of communicating wirelessly via the over-the-air interface 204 with one or more UEs and communicating with the core network 130. For example, the WANN 120 may be implemented, without being limited, in the form of a 2G base station, a 3G nodeB, an LTE eNB, a 4G LTE base station, a 5G NR base station of a 5G gNB, a 5G central-unit base station, or a 5G distributed-unit base station. Each type of these WANNs may be configured to perform a corresponding set of wireless network functions. The WANN 202 may include transceiver circuitry 214 coupled to one or more antennas 216, which may include an antenna tower 218 in various forms, to effectuate wireless communications with the UEs 110 and 112. The transceiver circuitry 214 may be coupled to one or more processors 220, which may further be coupled to a memory 222 or other storage devices. The memory 222 may be transitory or non-transitory and may store therein instructions or code that, when read and executed by the one or more processors 220, cause the one or more processors 220 to implement various functions of the WANN 120 described herein.

Data packets in a wireless access network such as the example described in FIG. 2 may be transmitted as protocol data units (PDUs) . The data included therein may be packaged as PDUs at various network layers wrapped with nested and/or hierarchical protocol headers. The PDUs may be communicated between a transmitting device or transmitting end (these two terms are used interchangeably) and a receiving device or receiving end (these two terms are also used interchangeably) once a connection (e.g., a radio link control (RRC) connection) is established between the transmitting and receiving ends. Any of the transmitting device or receiving device may be either a wireless terminal device such as device 110 and 120 of FIG. 2 or a wireless access network node such as node 202 of FIG. 2. Each device may both be a transmitting device and receiving device for bi-directional communications.

The core network 130 of FIG. 1 may include various network nodes geographically distributed and interconnected to provide network coverage of a service region of the carrier network 102. These network nodes may be implemented as dedicated hardware network nodes. Alternatively, these network nodes may be virtualized and implemented as virtual machines or as software entities. These network nodes may each be configured with one or more types of network functions which collectively provide the provisioning and routing functionalities of the core network 130.

Returning to wireless radio access network (RAN) , FIG. 3 illustrates an example RAN 340 in communication with a core network 310 and wireless terminals UE1 to UE7. The RAN 340 may include one or more various types of wireless base station or WANNs 320 and 321 which may include but are not limited to gNB, eNodeB, NodeB, or other type of base stations. The RAN 340 may be backhauled to the core network 310. The WANNs 320, for example, may further include multiple separate access network nodes in the form of a Central Unit (CU) 322 and one or more Distributed Unit (DU) 324 and 326. The CU 322 is connected with DU1 324 and DU2 326 via various interfaces, for example, an F1 interface. The F1 interface, for example, may further include an F1-C interface and an F1-U interface, which may be used to carry control plane information and user plane data, respectively. In some embodiments, the CU may be a gNB Central Unit (gNB-CU) , and the DU may be a gNB Distributed Unit (gNB-DU) . While the various implementations described below are provided in the context of a 5G cellular wireless network, the underlying principles described herein are applicable to other types of radio access networks including but not limited to other generations of cellular network, as well as Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

The UEs may be connected to the network via the WANNs 320 over an air interface. The UEs may be served by at least one cell. Each cell is associated with a coverage area. These cells may be alternatively referred to as serving cells. The coverage areas between cells may partially overlap. Each UE may be actively communicating with at least one cell while may be potentially connected or connectable to more than one cell. In the example of FIG. 1, UE1, UE2, and UE3 may be served by cell1 330 of the DU1, whereas UE4 and UE5 may be served by cell2 332 of the DU1, and UE6 and UE7 may be served by cell3 associated with DU2. In some implementations, a UE may be served simultaneously by two or more cells. Each of the UE may be mobile and the signal strength and quality from the various cells at the UE may depend on the UE location and mobility.

FIG. 4 further illustrates a simplified view of the various network layers involved in transmitting user-plane PDUs from a transmitting device 402 to a receiving device 404 in the example wireless access network of FIGs. 1-3. FIG. 4 is not intended to be inclusive of all essential device components or network layers for handling the transmission of the PDUs. FIG. 4 illustrates that the data packaged by upper network layers 420 at the transmitting device 402 may be transmitted to corresponding upper layer 430 (such as radio resource control or RRC layer) at the receiving device 304 via Packet Data Convergence Protocol layer (PDCP layer, not shown in FIG. 4) and radio link control (RLC) layer 422 and of the transmitting device, the physical (PHY) layers of the transmitting and receiving devices and the radio interface, as shown as 406, and the media access control (MAC) layer 434 and RLC layer 432 of the receiving device. Various network entities in each of these layers may be configured to handle the transmission and retransmission of the PDUs.

In FIG. 4, the upper layers 420 may be referred as layer-3 or L3, whereas the intermediate layers such as the RLC layer and/or the MAC layer and/or the PDCP layer (not shown in FIG. 4) may be collectively referred to as layer-2, or L2, and the term layer-1 is used to refer to layers such as the physical layer and the radio interface-associated layers. In some instances, the term “low layer” may be used to refer to a collection of L1 and L2, whereas the term “high layer” may be used to refer to layer-3. In some situations, the term “lower layer” may be used to refer to a layer among L1, L2, and L3 that are lower than a current reference layer. Control signaling may be initiated and triggered at each of L1 through L3 and within the various network layers therein. These signaling messages may be encapsulated and cascaded into lower layer packages and transmitted via allocated control or data over-the-air radio resources and interfaces. The term “layer” generally includes various corresponding entities thereof. For example, a MAC layer encompasses corresponding MAC entities that may be created. The layer-1, for example, encompasses PHY entities. The layer-2, for another example encompasses MAC layers/entities, RLC layers/entities, service data adaptation protocol (SDAP) layers and/or PDCP layers/entities.

FIG. 5 further shows a simplified illustration of uplink and downlink messaging in a wireless access network 500 between a base station 502 and a UE 504 via over-the-air (OTA) radio communication resources 506. The radio communication resources 506 may include portions of licensed radio frequency bands, portions of unlicensed ration frequency bands, or portions of a mix of both licensed and unlicensed radio frequency bands. The radio communication resources 506 available for carrying the wireless communication signals between the base station 502 and user equipment 504 may be further divided into physical downlink channels 510 for transmitting wireless signals from the base station 502 to the user equipment 504 and physical uplink channels 520 for transmitting wireless signals from the user equipment 504 to the base station 502. The physical downlink channels 510 may further include physical downlink control channels (PDCCHs) 512 and physical downlink shared channels (PDSCHs) 514. Likewise, the physical uplink channels 520 may further include physical uplink control channels (PUCCHs) 522 and physical uplink shared channels (PUSCHs) 524. For simplification, other types of downlink and uplink channels are not shown in FIG. 5 but are within the scope of the current disclosure. The control channels PDCCHs 512 and PUCCHs 522 may be used to carry control information in forms of control messages such as downlink control information (DCI) message 516 and uplink control information (UCI) message 526. The DCI message 516, for example, may be used for allocating PDSCH communication resources to the user equipment 504 besides carrying other control information (such as power control commands) . The DCI message 516 may also be used to schedule uplink transmission resource grant for the UE to transmit uplink information. The UCI message 526, for example, may be used to carry acknowledgment feedback information transmitted by the user equipment 504 with respect to communication resource allocation from the base station 502 via the DCI message 516. The shared channels PDSCHs 514 and PUSCHs 524 may be allocated/scheduled and used for communicating downlink data messages 118 and uplink data messages 128 between the base station 102 and the user equipment 104.

The communication resources 506 may include both radio frequency resources and time slots. In some implementations, the entire accessible bandwidth of the radio frequency resource may be divided into multiple radio frequency bandwidth parts (BWPs) . Each BWP may include a plurality of radio frequency physical resource block (PRB) . In the context of orthogonal frequency division multiplexing (OFDM) technology, each frequency PRB may further include a predetermined number of OFDM subcarriers with a predetermined subcarrier frequency spacing. For example, each frequency PRB may include 12 OFDM subcarriers. The subcarrier frequency spacing may be provides with a plurality of configurable values which the UE may choose based on its signal processing capability. For example, the subcarrier frequency spacing may be configurable at 15 KHz, 30 KHz, 60 KHz, 120 KHz, or 240 KHz. The OFDM signals may be modulated onto one or more radio frequency carriers.

The time-slot dimension of the communication resources 506 may be organized as frames and sub-frames of predetermined time durations. In one particularly implementation, the duration of a frame may be predefined at 10 ms. A frame may be divided into a predetermined number of sub-frames. For example, a 10 ms frame may be divided into 10 sub-frames with each sub-frame lasting 1 ms. Each sub-frame may be further divided into multiple time slots. In the context of OFDM, each time slot may be used for transmitting a predetermined number of OFDM symbols (e.g., 14 OFDM symbols) in a sequence. The number of time slots in a sub-frame may be configurable, in correlation with the configurable OFDM subcarrier spacing described above. For example, a sub-frame may include 1, 2, 4, 8, or 16 time slots corresponding to subcarrier spacing configuration of 15, KHz, 30 KHz, 60 KHz, 120 KHz, and 240 KHz, respectively.

In some implementations, the communication resources 506 including the radio frequency resources and time slots form a two-dimensional communication resource grid (with a frequency dimension and a time dimension) . Such a resource grid may be divided into the various uplink and downlink channels discussed above with respect to FIG. 5. Allocation within each channel may be further made. For example, the PDSCH resource may be allocated for transmitting data from the base station to the UE and each allocation may include one or more PRB in frequency and one or more time slots in time.

The DCI message 516 may be used by the base station 502 to inform the UE 504 about allocation of PRBs in PDSCHs 512, among other information that may be included in the DCI massage (such as power control commands) . The DCI message 516, while including PDSCH allocation information, for example, may further include information for controlling the HARQ procedure. Examples of various DCI files are provided in further detail below.

For a detection of DCI, a UE monitors a set of PDCCH candidates in the configured monitoring occasions in one or more configured COntrol REsource SETs (CORESETs) according to a corresponding search space configuration to decode the PDCCH under certain assumptions of DCI format sizes and aggregation levels. Such procedure is referred to as “PDCCH blind detection” . To facilitate such blind detection of DCI by the UEs, fully flexible DCI formats or construction may not be feasible. As such, a number of allowed sizes and formats for DCI may be predefined such that a UE may monitor and receive control resource sets and then extract any DCI from the received signal by performing the blind detection without undue burden. As such, to simplify the blind detection of DCI by the UE, the number of the various predefined DCI sizes and formats may be limited. For example, in the current 4G/5G systems, up to 4 DCI format sizes can be supported for a specific search space, and a few DCI formats are defined, e.g., DCI format 1_0, DCI format 1_1, DCI format 1_2, DCI format 1_3, DCI format 0_0, DCI format 0_1, DCI format 0_2, DCI format 0_3, etc. Different DCI formats having a same size may be differentiated by CRC (Cyclic Redundancy Check) being scrambled using different RNTI (radio network temporary identifier) .

The various DCI fields and the order thereof for each predefined DCI format may be pre-specified. More specifically, which DCI fields among the available DCI fields are included in a particular DCI format and the order among these included DCI fields may be predefined. Each of these DCI fields contains one or multiple bits. For example, the following DCI fields and the order thereof may be specified or predefined for DCI format 1_0 scrambled with corresponding C-RNTI:

● Frequency domain resource assignment (FDRA) ;

● Time domain resource assignment (TDRA) ;

● VRB-to-PRB mapping;

● Modulation and coding scheme (MCS) ;

● New data indicator (NDI) ;

● Redundancy version (RV) ;

● HARQ process number (HPN) ;

● Downlink assignment index (DAI) ;

● TPC command for scheduled PUCCH;

● PUCCH resource indicator (PRI) ;

● PDSCH-to-HARQ_feedback timing indicator;

● ChannelAccess-CPext;

● Reserved bits.

Such pre-defined DCI field composition and order is not flexible. In other words, it is not possible for the base station to replace some of the DCI fields or re-order these DCI fields for a particular DCI format according to the network requirements, for the purpose keeping the burden of blind DCI detection on the UEs sufficiently low.

A flexibility in constructing and transmitting DCI, however, may be highly desired in some situations. For example, in some newer generation of wireless networks, such as the 6th generation networks, AI/ML (Artificial Intelligence/Machine Learning) may begin to be applied to PDCCH to augment air-interface to improve the network performance. To take advantage of AI/MI assisted resource assignment and scheduling, the DCI construction and transmission may need to be made flexible (e.g., allows for flexible DCI size, and DCI field combination and order) rather than being constrained to a limited number of predefined formats. At the same time, a new transmission scheme for such flexible DCI may also need to be designed to maintain a low burden for blind detection on UEs.

In the various embodiments described below, a multi-stage (e.g., two-stage) DCI construction and transmission scheme is designed, where multiple DCIs are constructed as separate stages by a wireless network node and transmitted to a UE to jointly provide UE downlink and uplink assignment and/or grant. While a first-stage DCI among the multiple DCI stages may be constructed and transmitted in one of a set of predefined DCI formats in order to facilitate efficient blind detection by the UE, the second-stage DCI may be flexibly constructed and transmitted with its formatting information (such as bit length) , content information (such as DCI fields it contains) , and/or reception information (such as its frequency/time resource identification) being indicated in the first-stage DCI.

For example, a two-stage DCI may include a first DCI for indicating DCI fields that are to be included in a second DCI and the second DCI may include these DCI fields. The second DCI may thus be constructed or decoded according to the first DCI. In the disclosure herein, the first DCI may be alternatively referred to as a first-stage DCI or stage-I DCI whereas the second DCI may be alternatively referred to as a second-stage DCI or stage-II DCI. These two DCIs jointly provide, e.g., resource allocation/scheduling with flexibility in selection of DCI fields and their order but without increase blind detection burden for the UEs.

In some example implementations, the first DCI may include plurality of ON/OFF bits corresponding to a plurality of groups or combinations of DCI fields. Each of the ON/OFF bit corresponds to one group or combination of the plurality of groups or combinations of DCI fields. Each group or combination of DCI fields may be referred to as a DCI module, and may include one or more DCI fields that are related (e.g., with similar functionality) and are thus likely be configured together as a group. The various groups or combinations of DCI fields among the plurality of groups or combinations of DCI fields may contain same or different number of DCI fields. In one specific example, each of the ON/OFF bit correspond to one DCI field as its own group of DCI fields.

Each ON/OFF bit field above in the first DCI may indicate a presence/absence of a corresponding group or combination of DCI fields in the second DCI or indicate a configuration state of the corresponding DCI field combination in the second DCI. The plurality of ON/Off bits in the first DCI thus may be included as a bitmap for indicating the presence or absence of the corresponding groups or combinations of DCI fields in the second DCI or indicating the configuration state of the corresponding DCI field combination in the second DCI.

In some example implementations, the plurality of groups of combinations of DCI fields may be referred to as a DCI field configuration. Different DCI field configurations may correspond to different sets of groups or combinations of DCI fields (e.g., different number of groups or combinations of DCI fields and/or different group/combination compositions) . Each of such configurations may be identified by a DCI field configuration index. Each configuration may specify the groups or combinations of DCI fields being included, the order of the groups/combinations, the composition and order of DCI fields in each group/combination, and the bit widths of the DCI fields or DCI field groups/combinations included in the DCI field configuration. In the situation where each DCI field represents one group/combination, a DCI field configuration would specify the DCI fields being included, their order, and the bit width of the DCI field included.

Such various DCI field configurations may be predefined and indexed. Alternatively, each of the various DCI field configurations and their index may be configurable via, for example, RRC. For example, one or more RRC messages may be transmitted from the network node to the UE for providing, for each DCI field configuration, the groups or combinations of DCI fields being included, the order of the groups/combinations, the composition and order of DCI fields in each of the groups/combinations, and the bit width of the DCI fields or DCI field groups/combinations included in the DCI field configuration. With respect to the bit width for a DCI field, if not included in the DCI field configuration, then a default bit width for that DCI field may be assumed. The configuration index for a particularly chosen plurality of groups or combinations of DCI fields may be included in the first DCI. Such configuration index may preferably be included in the first DCI at a fixed location. The DCI field configuration index, for example, may precede the bitmap above in the first DCI.

The number of DCI field configurations may be represented by N. Correspondingly, the number of bits to be included in the first DCI for the DCI configuration index may be ceiling (log₂N) . The ceiling () function here is performed as a round-up to next integer. The DCI field configuration index, for example, may be included as the ceiling (log₂N) most significant bits (MSB) of the first DCI.

Different DCI field configurations among all of the predefined DCI field configurations may include same or different numbers of groups or combinations of DCI fields. In some implementations, the size of the bitmap above for the first DCI may be determined by a maximum number of groups or combinations of DCI fields in all possible DCI filed configurations, represented as M. For example, the plurality of groups or combinations of DCI fields included in different DCI field configurations may differ but the maximum number of groups or combinations may be M. The size of the bitmap above thus may be M. In the situation where an indicated DCI field configuration includes a number of groups or combinations of DCI fields K that is smaller than M, then only a portion of the bitmap (e.g., the K most significant bits) is used for indicating ON/OFF for these groups or combinations, and the additional M-K bits may be zero padded or disregarded. In some other example implementations, the size of the bitmap above may be reserved to be larger than M, but only at most M bits are effective in the bitmap for the ON/OFF indication, and the rest of extra bits in the bitmap may be zero padded or disregarded. In some example implementations, the bitmap may be included at a fixed position of the first DCI. For example, the bitmap may immediately follow the DCI field configuration index above in the first DCI.

In some example implementations, all possible DCI fields may be divided into various groups or combinations of DCI fields with the order of DCI fields in each group/combination defined (an example is given below) . Each DCI field configuration above may be defined by inclusion of one or more of these groups or combinations in a specified order (as shown in the example below in relation to Table 2) . In some implementations, these groups/combinations may be indexed. The division and indexing of these groups/combinations of all DCI fields may be communicated to the UE via one or more RRC messages.

The first DCI may be defined in one or more fixed DCI formats for purposes of blind detection by UE. As such, the number of available formats for such first DCIs may be limited, similar to the legacy DCIs. For example, all such first DCIs may follow a single fixed DCI format. Such format may coexist with other legacy DCI formats. As such, the stage-I DCI described above may be subject to blind detection in similar manner as the latency DCI formats. Such a DCI format may be added to the existing legacy DCI formats. The size of the stage-I DCI may be different or the same as a legacy DCI format. If the size of the first DCI is the same as a legacy DCI, then a new RNTI for the first DCI should be introduced. In some example implementations, if the size of a first DCI is same as a legacy DCI format, it may be aligned to DCI format 0-0/1-0.

As described above, the stage-I DCI design above still facilitates a blind detection by the UE. The detection of a stage-I DCI then allows for identification of a corresponding stage-II DCI to be detected from, e.g., PDCCH, and the stage-II DCI may then contain actual DCI fields which are flexibly constructed and can be detected and decoded based on information included in the stage-I DCI.

In some example implementations, the first DCI, in addition to including the DCI field configuration and the bitmap described above (which indicate DCI fields that are present in the corresponding stage-II DCI and the order of the inclusion, either at DCI field level or as groups or combinations of DCI fields) , may include other information pertaining to the stage-II DCI. Such additional information carried in a stage-I or first DCI pertaining to the corresponding stage-II or second DCI may include one or more of but is not limited to the following:

● A frequency and time resource allocation of the second DCI.

● A start Control Channel Element (CCE) of the second DCI if legacy PDCCH is used to carry the second DCI.

● A physical layer processing procedure indicator about the second DCI. The physical layer processing procedure indicator for indicating, for example, at least two processing procedures: one for a legacy processing procedure, and another for a new processing procedure for the second DCI.

● A valid duration of the second DCI. For example, the valid duration for the second DCI may specify a time duration to be applied to all or a specific set of the DCI fields in the second DCI (the specific set of DCI field may include one or more DCI fields) . Such a valid duration included in the first DCI indicates a time length that the second DCI can be applied after it is received. An example is shown in FIG. 6, where a valid time duration for the second DCI may be included in the corresponding first DCI. Specifically, such information included in the first DCI 602 may indicate that the corresponding second DCI 612 can be validly applied for 3 slots flowing reception of the second DCI 612. Likewise, such information included in the first DCI 604 may indicate that the corresponding second DCI 614 can be validly applied for 3 slots flowing reception of the second DCI 614. Likewise, such information included in the first DCI 606 may indicate that the corresponding second DCI 616 can be validly applied for 4 slots flowing reception of the second DCI 616.

● A monitoring duration of the second DCI. For example, such monitoring duration included in the first DCI may indicate a time duration that the UE should monitor for the second DCI. An example of monitoring duration is shown in FIG. 7. In FIG. 7, monitoring time duration for the second DCI may be included in the corresponding first DCI. As shown in FIG. 7, such information included in the first DCI 702 may indicate that the corresponding second DCI 712 may be transmitted over a duration of 3 slots and thus may be monitored during these three time slots after the first DCI 702 is received. Likewise, such information included in the first DCI 704 may indicate that the corresponding second DCI 714 may be transmitted over a duration of 3 slots and thus may be monitored during these three time slots after the first DCI 704 is received. Likewise, such information included in the first DCI 706 may indicate that the corresponding second DCI 716 may be transmitted over a duration of 4 slots and thus may be monitored during these three time slots after the first DCI 706 is received.

● A beam related information of the second DCI. Such information may be included in the first DCI to facilitate detection of the second DCI at the specified beam.

In some example implementations, the first DCI, in addition to including the DCI field configuration and the bitmap described above (which indicate DCI fields that are present in the corresponding stage-II DCI and the order of inclusion, either at DCI field level or as groups or combinations of DCI fields) , may include other information pertaining to a next stage-I DCI. Such additional information carried in a stage-I or first DCI pertaining to the next stage-I DCI may include one or more of but is not limited to the following:

● A frequency and time resource allocation of the next stage-I DCI.

● A start Control Channel Element (CCE) of the next stage-I DCI if legacy PDCCH is used to carry the next stage-I DCI.

● A period of the next stage-I DCI.

As described above, in some example implementations, the size of the first DCI, including the DCI field configuration index bits, the ON/OFF bitmap, and the additional bits above for carrying the additional information for the corresponding second DCI and/or the additional information for the next first DCI, may be fixed or configurable. The number of fixed or configurable first DCI sizes may be limited to a small number, e.g., up to 2 or 3 sizes for the first DCI, in order to support and facilitate the blind detection of the first DCI. As such, in some example implementations, a bit width for carrying the additional information above in the stage-I DCI may be fixed or configurable in a limited number of options. If configurable, such a bit width may be specified, for example, in one or more RRC messages.

Turning to example second or stage-II DCI, the stage-II DCI may have a bit length that can be determined or derived from the first DCI. The stage-II DCI may at least include the DCI fields or groups/combination of fields indicated as being present according to the bitmap of the corresponding stage-I DCI as described above.

In some example implementations, a stage-II DCI may further include a fixed number of reserved bits. For example, one of the reserved bits may be used to indicate whether the second DCI is used for uplink scheduling for PUSCH or downlink resource assignment for PDSCH. For another example, one or more of the reserved bits may be used to indicate beam information for a next stage-I DCI. Such implementation takes advantage of the two stages of these DCI to provide information that further facilitate more efficient blind detection of a next stage-I DCI following a stage-II DCI.

In some example implementations, the size of a second-stage DCI may be derived from the first DCI. For example, information such as the various DCI fields (or groups or combinations of DCI fields) that are indicated as present in the second-stage DCI may be identified from the first DCI and/or information already configured from RRC. Further, bit widths of these DCI fields (or groups or combinations of DCI fields) may be obtained from information carried in the first DCI or from prior RRC messages. As such, the total bit width of all DCI fields included in the second-stage DCI may be derived. The fixed or configurable reserve bit width for the second-stage DCI may be further added to generate an overall bit width of the second-stage DCI. As such, the UE would be able to decode the second stage DCI without having to try different sizes and perform blind detection.

An example first-stage DCI and corresponding second-stage DCI following the implementations above is shown in FIG. 8 in the context that the DCI fields are not grouped (or each DCI field is considered as its own group) . In the example of FIG. 8, four DCI field configurations are allowed. As such, a two-bit ceiling (log₂4) =2 configuration index 804 may be included as the two MSB in the example first-stage DCI 802.

Merely as an example, Table 1 below further shows all four allowed DCI field configurations referred to as Config_0, Confi_1, Config_2, and Config_3, corresponding to DCI field configuration indexes of 00, 01, 10, and 11, respectively. According to such example allowed DCI field configurations, the maximum number of DCI fields in any DCI field configuration is 10. As such, the size of the ON/OFF bitmap 806 in the example stage-I DCI of 802 may be 10 bits. Each “ON/OFF” bit in the 10-bit bitmap 806 may indicate a presence or absence of the corresponding DCI field in the corresponding second-stage DCI.

Table 1

In the example of FIG. 8, the configuration index 804 is “00” as indicated in the first DCI 802, which means that Config_0 in Table 1 applies. As such, the “ON/OFF” bitmap 806 in the first DCI 802 is used to indicate the DCI fields of Config_0. The value of “ON/OFF” bitmap 806 in the example of FIG. 8 is “1 1 1 0 1 1 1 1 0 0” , which indicates to the UE that the DCI fields with indexes of 0/1/2/4/5/6/7 in Config_0 would be present in the second DCI 810. Correspondence between the “ON/OFF” bitmap 806 and the DCI fields present in the stage-II DCI 810 is indicated by the arrows 812 in FIG. 8. In some implementations, default value for the DCI fields included in the indicated configuration but not present in the second DCI 810 may resort to preconfigured default values.

In the example of FIG. 8, the additional bits in the first DCI for carrying additional information for the second DCI are shown as 808, whereas the reserve bits described above for the second DCI is not shown in FIG. 8 for simplicity.

In some example implementations, in a case that the “ON/OFF” fields are all set to “0” in the first DCI, the second DCI may not need to be sent. In this case, for example, default DCI field values for the DCI fields in configuration corresponding to the indicated configuration index may be use. In some example implementation of such cases, values of the fields indicated by the configuration index in the first DCI may be taken from the last received stage-II DCI, if available.

Another example first-stage DCI and corresponding second-stage DCI following the implementations above is shown in FIG. 9 in the context that the DCI fields are not grouped (or each DCI field is considered as its own group) . In the example of FIG. 9, similar to FIG. 8, four DCI field configurations are allowed. As such, a two-bit ceiling (log₂4) =2 configuration index 904 may be included as the two MSB in the example first-stage DCI 902. Merely as an example, Table 2 below further shows all four allowed DCI field configurations referred to as Config_0, Confi_1, Config_2, and Config_3, corresponding to DCI field configuration indexes of 00, 01, 10, and 11, respectively. According to such example allowed DCI field configurations, the maximum number of DCI fields in any DCI field configuration is 10. As such, the size of the ON/OFF bitmap 906 in the example stage-I DCI of 902 may be 10 bits. Each of some of “ON/OFF” bits in the 10-bit bitmap 906 may indicate a presence or absence of the corresponding DCI field in the corresponding second-stage DCI. For some of the DCI fields in some DCI field configurations, there may be two different configurations. For example, the DCI field of “TDRA” in DCI Field Config_0 (index 00) of Table 2 may have two configurations, referred to TDRA config0, and TDRA config1 (configuration states of TDRA) . For these DCI fields under the corresponding DCI field configuration index, they are always present in the second DCI, and the corresponding bits in the bitmap 906 may be used to indicate which configuration is applied rather than being used as “ON/OFF” bits. For example, the index 902 being “00” , bit 920 in the bit map 906 may correspond to the “TDRA” field according to Table 2 and may be used to indicate whether TDRA Config1 or TDRA Config2 is used in the second stage DCI (rather than for indicating presence of TDRA) , e.g., “0” for TDRA config0 and “1” for TDRA config1. Similar, the DCI field of “PDSCH-to-HARQ-timing” of configuration index 00 (Config_0 of Table 2) may also be in either its Config0 and Config1 (configuration states of "PDSCH-to-HARQ-timing” ) . As shown in FIG. 9, when the configuration index indicates “00” for Config_0, the DCI fields corresponding to “TDRA” and “PDSCH-to-HARQ-timing” , according to Table 2, will always be presented in the stage-II DCI. But the actual value of these DCI fields indicated will depend on which configuration is indicated in stage-I DCI by bit 920 and bit 922 of the bitmap 906. As also shown in Table 2, whether presence/absence or configuration is indicated for each field of each DCI field configurations is predefined or configured. In Table 2, for configuration index 00, while the TDRA field and the PDSCH-to-HARQ-timing field will always be present in stage-II DCI with their configuration indicated in the corresponding bits in bitmap of the stage-I DCI, other DCI fields would be either ON or OFF in the stage-II DCI. For configuration index 10 (Config_2 in Table 2) , only the MCS field is always present with its configuration state indicated in the bitmap of stage-I DCI and other fields would be either ON or OFF in the stage-II DCI.

Table 2

For further detail in the example of FIG. 9, the configuration index 904 is “00” as indicated in the first DCI 902, which means that Config_0 in Table 2 applies. As such, the “ON/OFF” bitmap 906 in the first DCI 902 is used to indicate the DCI fields of Config_0. The value of “ON/OFF” bitmap 906 in the example of FIG. 9 is “X 1 1 0 1 X 1 1 0 0” , which indicates to the UE that the DCI fields with indexes of 0/1/2/4/5/6/7 in Config_0 would be present in the second DCI 910. Correspondence between the “ON/OFF” bitmap 906 and the DCI fields present in the stage-II DCI 910 is indicated by the arrows 912 in FIG. 9. Furthermore, the first bit of “X” corresponding to “TDRA” field, if X=0, it means TDRA Config0 in “TDRA” field would be used in stage-II DCI for indication, otherwise, TDRA Config1 in “TDRA” field would be used instead. Similar for the sixth bit “X” corresponding to the “PDSCH-to-HARQ-timing” field, if X=0, it means Config0 in “PDSCH-to-HARQ-timing” field would be used in stage-II DCI for indication, otherwise, Config1 in “PDSCH-to-HARQ-timing” field would be used instead. As another example in FIG. 10, the configuration index 1004 is “10” as indicated in the first DCI 1002, which means that Config_2 in Table 2 applies. As such, the “ON/OFF” bitmap 1006 in the first DCI 1002 is used to indicate the DCI fields of Config_2. The value of “ON/OFF” bitmap 1006 in the example of FIG. 10 is “0 1 1 X 1 1 1 1 0 0” , which indicates to the UE that the DCI fields with indexes of 1/2/3/4/5/6/7 in Config_2 of Table 2 would be present in the second DCI 1010. Correspondence between the “ON/OFF” bitmap 1006 and the DCI fields present in the stage-II DCI 1010 is indicated by the arrows 1012 in FIG. 10. Furthermore, the bit 1020 of “X” corresponding to “MCS” field, if X=0, it means Config0 in “MCS” field would be used in stage-II DCI for indication, otherwise, Config1 in “MCS” field would be used instead.

Another example first-stage DCI and corresponding second-stage DCI following the implementations above is shown in FIG. 11 in the context that the DCI fields are grouped into DCI field combinations or DCI field modules. For this example, it is assumed that the RRC configurable DCI field grouping or modules are the following:

● Resource allocation (RA) DCI module: FDRA, TDRA, hopping flag, VRB-to-PRB mapping, BWP indicator, carrier indicator;

● TB related DCI module: MCS, RV, NDI;

● HARQ related DCI module: PRI, PDSCH-to-HARQ timing, DAI, CBGTI, CBGFI;

● MIMO related DCI module: antenna port, TCI;

● Energy saving (ES) related DCI module: scell dormancy indicator, PDCCH monitoring adaptation indicator;

● Power control (PC) related DCI module: TPC for PUCCH/PUSCH, second TPC for PUCCH.

In the example of FIG. 11, it is again assumed that there are 4 RRC configured DCI module configurations and thus a selected configuration of DCI modules is indicated in the configuration index 1104 in the first DCI 1102. Again, the DCI module configuration index contains two bits as needed by the four possible configurations. The DCI module configuration index 1104 may occupy the two MSB of the first DCI 1102. An example of the 4 DCI module configurations configurable by RRC are shown in Table 3.

Table 3

According to the four available configurations in Table 3, the maximum number of DCI modules in the all 4 configurations is 4. As such, the “ON/OFF” bitmap 1106 of FIG. 11 may include as few as 4 bits for indicating the presence/absence in the second DCI of the DCI modules corresponding to the DCI module configuration indicated by the index 1104.

In the example of FIG. 11, the configuration index is indicated as “01” , which means that the “ON/OFF” bitmap 1106 in the first DCI is used to indicate the presence/absence in the second DCI 1110 of DCI modules corresponding to configuration “01” in Table 3. In the example of FIG. 11, the value of “ON/OFF” bitmap is “1 1 1 1” , which means the DCI modules of 0/1/2/3 in configuration “01” of Table 1 would be indicated in the second DCI 1110, as represented by the arrows 1112 of FIG. 11.

Compared to the example of FIG. 8, the bit width for “ON/OFF” bitmap in the example of FIG. 11 may be smaller, as a result of grouping/combination of DCI fields with similar functionality. As such, by using DCI filed groups/combinations or modules as unit for indication in the bitmap of the first DCI, signaling overhead for the first DCI may be reduced. Such an approach may be suitable for scenarios where the DCI fields in a DCI module with similar functionality update at the same time or together. In addition, if the size of first DCI is same as legacy DCI format size, because the bitmap size is reduced by DCI field grouping/combination, the bit fields available for carrying additional information would be larger, and as a result, more additional information pertaining to the second DCI may be carried in the first DCI.

The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment/implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment/implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Claims

A method performed by a wireless network node, comprising:

transmitting a set of downlink control information (DCI) to a user equipment (UE) in two separate stages as a stage-I DCI and a stage-II DCI,

wherein:

the stage-I DCI and the stage-II DCI jointly control an assignment or grant for the UE; and

a bit length of the stage-II DCI is derived from information carried in the stage-I DCI.
The method of claim 1, wherein the stage-I DCI is of one of a set of predefined or configurable bit lengths and is identified as one of a predefined set of DCI formats.
The method of claim 1, wherein the stage-I DCI comprises a bitmap for a plurality of DCI field combinations, each bit of the bitmap corresponding to a DCI field combination among the plurality of DCI field combinations, and each bit indicating a presence or absence of the corresponding DCI field combination in the stage-II DCI or indicating a configuration state of the corresponding DCI field combination in the stage-II DCI.
The method of claim 3, wherein a size of the bitmap is predefined to represent a number of all allowed DCI field combinations.
The method of claim 3, wherein:

the plurality of DCI field combinations corresponds to a DCI field configuration among a set of possible DCI field configurations; and

the stage-I DCI further comprise a configuration index for identifying the DCI field configuration among the set of possible DCI field configurations.
The method of claim 5, wherein the set of possible DCI field configurations and indexes thereof are informed to the UE by the wireless network node using one or more radio resource control (RRC) messages.
The method of claim 3, wherein each DCI field combination of the plurality of DCI field combinations comprises one or more related DCI fields.
The method of claim 7, wherein each DCI field combination of the plurality of DCI field combinations comprises a single DCI field.
The method of claim 7, wherein bit widths of the one or more DCI fields associated with each of the plurality of DCI field combinations are further indicated in the one or more RRC messages.
The method of claim 6, wherein the one or more RRC messages further define DCI filed components of each DCI field combination of the plurality of DCI field combinations.
The method of claim 3, wherein the stage-I DCI further comprises information pertaining to the stage-II DCI.
The method of claim 11, wherein a bit width for the information pertaining to the stage-II DCI as contained in the stage-I DCI is predefined or configured via RRC.
The method of claim 11, wherein the information pertaining to the stage-II DCI comprises at least one of:

a frequency and/or time resource allocation of the stage-II DCI;

a start control channel element (CCE) of the stage-II DCI;

a physical layer processing procedure indicator for the stage-II DCI;

a first duration for validly applying the stage-II DCI;

a second duration for monitoring the stage-II DCI; or

beam information with respect to the stage-II DCI.
The method of claim 3, wherein the stage-I DCI further comprises information pertaining to a next stage-II DCI.
The method of claim 14, wherein a bit width for the information pertaining to the next stage-I DCI as contained in the stage-I DCI is predefined or configured via RRC.
The method of claim 14, wherein the information pertaining to the next stage-I DCI comprises at least one of: a frequency and/or time resource allocation of the next stage-I DCI; a start CCE of the next stage-I DCI; a period of the stage-I DCI.
The method of claim 3, wherein the stage-II DCI comprises DCI fields within the plurality of DCI field combinations that are indicated by the bitmap of the Stage-I DCI as being present and as having a configuration state.
The method of claim 3, wherein the stage-II DCI comprises a predefined number of reserved bits.
The method of claim 18, wherein at least a portion of the reserved bits of the stage-II DCI comprise indicate whether the stage-II DCI is used for uplink scheduling or downlink assignment.
The method of claim 18, wherein at least a portion of the reserved bits of the stage-II DCI indicate beam information for a next stage-I DCI.
A method performed by a user equipment (UE) , comprising:

monitor and receive a first downlink control information (DCI) from a wireless network node;

determine a DCI size of a second DCI based on information carried in the first DCI, the second DCI being transmitted by the wireless network node separately from the first DCI; and

receiving the second DCI from the wireless network node based the DCI size as determined from the first DCI; and

determine a grant or assignment for the UE based on the second DCI.
The method of claim 21, wherein the first DCI is of one of a set of predefined or configurable bit lengths and is identified as one of a predefined set of DCI formats.
The method of claim 21, wherein the first DCI comprises a bitmap for a plurality of DCI field combinations, each bit of the bitmap corresponding to a DCI field combination among the plurality of DCI field combinations, and each bit indicating a presence or absence of the corresponding DCI field combination in the second DCI or indicating a configuration state of the corresponding DCI field combination in the stage-II DCI.
The method of claim 23, wherein a size of the bitmap is predefined to represent a number of all allowed DCI field combinations.
The method of claim 23, wherein:

the plurality of DCI field combinations corresponds to a DCI field configuration among a set of possible DCI field configurations; and

the first DCI further comprise a configuration index for identifying the DCI field configuration among the set of possible DCI field configurations.
The method of claim 25, wherein the set of possible DCI field configurations and indexes thereof are informed to the UE by the wireless network node using one or more radio resource control (RRC) messages.
The method of claim 23, wherein each DCI field combination of the plurality of DCI field combinations comprises one or more related DCI fields.
The method of claim 27, wherein each DCI field combination of the plurality of DCI field combinations comprises a single DCI field.
The method of claim 27, wherein bit widths of the one or more DCI fields associated with each of the plurality of DCI field combinations are further indicated in the one or more RRC messages.
The method of claim 26, wherein the one or more RRC messages further define DCI filed components of each DCI field combination of the plurality of DCI field combinations.
The method of claim 23, wherein the first DCI further comprises information pertaining to the second DCI.
The method of claim 31, wherein a bit width for the information pertaining to the second DCI as contained in the first DCI is predefined or configured via RRC.
The method of claim 31, wherein the information pertaining to the stage-II DCI comprises at least one of:

a frequency and/or time resource allocation of the second DCI;

a start control channel element (CCE) of the second DCI;

a physical layer processing procedure indicator for the second DCI;

a first duration for validly applying the second DCI;

a second duration for monitoring the second DCI; or

beam information with respect to the second DCI.
The method of claim 23, wherein the stage-I DCI further comprises information pertaining to a next stage-II DCI.
The method of claim 34, wherein a bit width for the information pertaining to the next stage-I DCI as contained in the stage-I DCI is predefined or configured via RRC.
The method of claim 34, wherein the information pertaining to the next stage-I DCI comprises at least one of: a frequency and/or time resource allocation of the next stage-I DCI; a start CCE of the next stage-I DCI; a period of the stage-I DCI.
The method of claim 23, wherein the second DCI comprises DCI fields within the plurality of DCI field combinations that are indicated by the bitmap of the First DCI as being present and as having a configuration state.
The method of claim 23, wherein the second DCI comprises a predefined number of reserved bits.
The method of claim 38, wherein at least a portion of the reserved bits of the second DCI comprise indicate whether the second DCI is used for uplink scheduling or downlink assignment.
The method of claim 38, wherein at least a portion of the reserved bits of the second DCI indicate beam information for a next first DCI.
A wireless communications apparatus comprising a processor and a memory, wherein the processor is configured to read code from the memory and implement the method recited in any of claims 1 to 40.
A computer program product comprising a computer-readable program medium code stored thereupon, the code, when executed by a processor, causing the processor to implement the method recited in any of claims 1 to 40.