Patent Description:
URLLC is one of a diversity of use cases envisaged under the next generation (e.g., <NUM>) wireless communication networks, also referred to as New Radio (NR) networks. While URLLC is aimed to provide high reliability and low latency services, a design to achieve both objectives can be challenging. As contemplated in NR networks, a URLLC reliability requirement for transmission of a packet may be considered successful if the transmission has a <NUM>-<NUM>^-<NUM>% error rate for every <NUM> bytes with a user plane latency of <NUM> millisecond. In legacy long-term-evolution (LTE) systems, LTE shortened transmission time interval (sTTI) has been used for latency reduction. While URLLC may inherit the legacy LTE sTTI design for latency reduction, achieving high-reliability URLLC transmission still presents challenges. For example, as a Hybrid Automatic Repeat reQuest (HARQ) may be not available for a URLLC control channel, URLLC must consider other mechanisms to achieve high reliability while also meeting the stringent low latency requirement.

SAMSUNG: "Multi-beam Transmission for NR-PDCCH" describes observations on multi-beam transmission for NR-PDCCH. Following are the observations:.

Thus, there is a need in the art for highly reliable transmission for URLLC data and control channels.

The present invention is defined by the features disclosed in the independent claims. Additional embodiments are defined in the dependent claims.

The present disclosure is directed to systems and methods for high-reliability URLLC control and data channel transmissions.

Aspects of the exemplary disclosure are best understood from the following detailed description when read with the accompanying figures. Various features are not drawn to scale, dimensions of various features may be arbitrarily increased or reduced for clarity of discussion.

The following description contains specific information pertaining to exemplary implementations in the present disclosure. The drawings in the present disclosure and their accompanying detailed description are directed to merely exemplary implementations. However, the present disclosure is not limited to merely these exemplary implementations. Other variations and implementations of the present disclosure will occur to those skilled in the art. Unless noted otherwise, like or corresponding elements among the figures may be indicated by like or corresponding reference numerals. Moreover, the drawings and illustrations in the present disclosure are generally not to scale, and are not intended to correspond to actual relative dimensions.

For the purpose of consistency and ease of understanding, like features are identified (although, in some examples, not shown) by numerals in the exemplary figures. However, the features in different implementations may be differed in other respects, and thus shall not be narrowly confined to what is shown in the figures.

The description uses the phrases "in one implementation," or "in some implementations," which may each refer to one or more of the same or different implementations. The term "coupled" is defined as connected, whether directly or indirectly through intervening components, and is not necessarily limited to physical connections. The term "comprising," when utilized, means "including, but not necessarily limited to"; it specifically indicates open-ended inclusion or membership in the so-described combination, group, series and the equivalent.

Additionally, for the purposes of explanation and non-limitation, specific details, such as functional entities, techniques, protocols, standard, and the like are set forth for providing an understanding of the described technology. In other examples, detailed description of well-known methods, technologies, system, architectures, and the like are omitted so as not to obscure the description with unnecessary details.

Persons skilled in the art will immediately recognize that any network function(s) or algorithm(s) described in the present disclosure may be implemented by hardware, software or a combination of software and hardware. Described functions may correspond to modules may be software, hardware, firmware, or any combination thereof. The software implementation may comprise computer executable instructions stored on computer readable medium such as memory or other type of storage devices. For example, one or more microprocessors or general purpose computers with communication processing capability may be programmed with corresponding executable instructions and carry out the described network function(s) or algorithm(s). The microprocessors or general purpose computers may be formed of applications specific integrated circuitry (ASIC), programmable logic arrays, and/or using one or more digital signal processor (DSPs). Although some of the exemplary implementations described in this specification are oriented to software installed and executing on computer hardware, nevertheless, alternative exemplary implementations implemented as firmware or as hardware or combination of hardware and software are well within the scope of the present disclosure.

The computer readable medium includes but is not limited to random access memory (RAM), read only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, compact disc read-only memory (CD ROM), magnetic cassettes, magnetic tape, magnetic disk storage, or any other equivalent medium capable of storing computer-readable instructions.

A radio communication network architecture (e.g., a long term evolution (LTE) system, a LTE-Advanced (LTE-A) system, or a LTE-Advanced Pro system) typically includes at least one base station, at least one user equipment (UE), and one or more optional network elements that provide connection towards a network. The UE communicates with the network (e.g., a core network (CN), an evolved packet core (EPC) network, an Evolved Universal Terrestrial Radio Access network (E-UTRAN), a Next-Generation Core (NGC), <NUM> Core Network (5GC), or an internet), through a radio access network (RAN) established by the base station.

It should be noted that, in the present disclosure, a UE may include, but is not limited to, a mobile station, a mobile terminal or device, a user communication radio terminal. For example, a UE may be a portable radio equipment, which includes, but is not limited to, a mobile phone, a tablet, a wearable device, a sensor, or a personal digital assistant (PDA) with wireless communication capability. The UE is configured to receive and transmit signals over an air interface to one or more cells in a radio access network.

A base station may include, but is not limited to, a node B (NB) as in the UMTS, an evolved node B (eNB) as in the LTE-A, a radio network controller (RNC) as in the UMTS, a base station controller (BSC) as in the GSM/GERAN, an NG-eNB as in an E-UTRA base station in connection with the 5GC, a next generation node B (gNB) as in the <NUM>-RAN, and any other apparatus capable of controlling radio communication and managing radio resources within a cell. The base station may connect to serve the one or more UEs through a radio interface to the network.

A base station may be configured to provide communication services according to at least one of the following radio access technologies (RATs): Worldwide Interoperability for Microwave Access (WiMAX), Global System for Mobile communications (GSM, often referred to as <NUM>), GSM EDGE radio access Network (GERAN), General Packet Radio Service (GPRS), Universal Mobile Telecommunication System (UMTS, often referred to as <NUM>) based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), LTE, LTE-A, eLTE (enhanced LTE), New Radio (NR, often referred to as <NUM>), and/or LTE-A Pro. However, the scope of the present disclosure should not be limited to the above mentioned protocols.

The base station is operable to provide radio coverage to a specific geographical area using a plurality of cells forming the radio access network. The base station supports the operations of the cells. Each cell is operable to provide services to at least one UE within radio coverage of the cell. More specifically, each cell (often referred to as a serving cell) provides services to serve one or more UEs within the cell's radio coverage, (e.g., each cell schedules the downlink and optionally uplink resources to at least one UE within the cell's radio coverage for downlink and optionally uplink packet transmissions). The base station can communicate with one or more UEs in the radio communication system through the plurality of cells. A cell may allocate sidelink (SL) resources for supporting proximity service (ProSe). Each cell may have overlapped coverage areas with other cells.

As discussed above, the frame structure for NR is to support flexible configurations for accommodating various next generation (e.g., <NUM>) communication requirements, such as eMBB, mMTC, and URLLC, while fulfilling high reliability, high data rate and low latency requirements. The orthogonal frequency-division multiplexing (OFDM) technology as agreed in 3GPP may serve as a baseline for NR waveform. The scalable OFDM numerology, such as the adaptive sub-carrier spacing, the channel bandwidth, and the Cyclic Prefix (CP) may be also used. Additionally, two coding schemes are considered for NR: (<NUM>) low-density parity-check (LDPC) code and (<NUM>) Polar Code. The coding scheme adaption may be configured based on the channel conditions and/or the service applications.

Moreover, it is also considered that in a transmission time interval TX of a single NR frame, a downlink (DL) transmission data, a guard period, and an uplink (UL) transmission data should at least be included, where the respective portions of the DL transmission data, the guard period, the UL transmission data should also be configurable, for example, based on the network dynamics of NR. In addition, sidelink resource may also be provided in a NR frame to support ProSe services.

<FIG> is a schematic diagram illustrating multiple CORESETs containing repetition DCI in a PDCCH for scheduling the same data in a PDSCH, according to an example implementation of the present disclosure. While the methods described in the present disclosure relate to URLLC service, the methods are not limited to URLLC service but can also include other types of data transmission.

To support the transmission of downlink (and uplink) transport channels, downlink (and uplink) shared channel control signaling is required. The control signaling enables a UE to successfully receive, demodulate, and decode data transmitted through the downlink shared channel. In a <NUM> NR network, the DCIs (e.g., having information about downlink shared channel resource allocation, transport format, and etc.) are transmitted from a base station through a PDCCH, and can be decoded from one or more CORESETs in a CORESET configuration transmitted to the UE from the base station, for example.

As shown in <FIG>, diagram <NUM> includes PDCCH <NUM> and PDSCH <NUM>. PDCCH <NUM> includes a plurality of control channel elements (CCEs), where CORESET <NUM> and CORESET <NUM> reside in the CCEs. CORESETs <NUM> and <NUM> contain information to decode DCIx1 and DCIx2, respectively. PDSCH <NUM> includes data <NUM> (e.g., URLLC data). PDCCH <NUM> and PDSCH <NUM> may be configured by a base station (e.g., a next generation Node B (gNB)), and transmitted to a UE.

As shown in <FIG>, in PDCCH <NUM>, several CORESETs are included so that the UE can monitor data scheduling information. For example, the UE may monitor and blind decode CORESETs <NUM> and <NUM> to obtain DCIx1 and DCIx2, respectively, for receiving data <NUM> (e.g., URLLC data) in PDSCH <NUM>. Since users (e.g., URLLC data users) may not need to monitor common search space in consideration for latency reduction, they can attempt to monitor and decode UE-specific search spaces based on, for example, Cell-Radio Network Temporary Identifier (C-RNTI) and the configuration of CORESET from higher layers (e.g., media access control (MAC) layer and radio resource control (RRC) layer).

In the present example implementation, CORESET <NUM> may include frequency resource location, time resource location, and information related to decoding DCIx1. For example, the information related to decoding DCIx1 may include, but is not limited to, maximum number of blind decoding attempt per aggregation level or per CORESET (e.g., PDCCH candidates), aggregation level and coding rate of the DCIx1, and spatial information of CORESET <NUM> (e.g., reception beam information). Similarly, CORESET <NUM> may include frequency resource location, time resource location, and information related to decoding DCIx2. For example, the information related to decoding DCIx2 may include, but is not limited to, maximum number of blind decoding attempt per aggregation level or per CORESET (e.g., PDCCH candidates), aggregation level and coding rate of DCIx2, and spatial information of CORESET <NUM> (e.g., reception beam information). Moreover, the frequency resource location may be configured in a CORESET configuration, while time resource location may be configured in a search space configuration associated with the CORESET configuration. The search space configuration may be configured separately from the time and frequency configurations, and the CORESET may include a search space index or a search space identifier (ID) indicating what search space configuration is provided when the search space configuration is not included in the CORESET. Also, the DCIs for scheduling the same data transmission in the PDSCH are repeated in one or more PDCCHs.

In various implementations of the present disclosure, to improve reliability of control channel transmissions, DCI can apply a lower coding rate. Because a lower coding rate may lead to a larger payload size of the DCI, a higher aggregation level may be applied to the DCI. In the present example implementation, the transmissions of DCIx1 and DCIx2 in PDCCH <NUM> have different coding rates and different aggregation levels to save control channel resources. For example, DCIx1 may have a higher coding rate and a lower aggregation level than DCIx2. It should be understood that different aggregation levels may result in different search space configurations. In one implementation, DCIx1 and DCIx2 are transmitted in different time resources (e.g., frame(s), subframe(s), slot(s), or symbol(s)) and/or frequency resources (e.g., frame(s), subframe(s), slot(s), or symbol(s)) of PDCCH <NUM>. As illustrated in <FIG>, DCIx1 is transmitted at a higher frequency band than DCIx2, and an earlier time slot than DCIx2. In another implementation, DCIx1 and DCIx2 may be transmitted in the same time resource, but in different frequency resources of PDCCH <NUM>. In yet another implementation, DCIx1 and DCIx2 may be transmitted in the same frequency resource, but in different time resources of PDCCH <NUM>.

In the present implementation, although DCIx1 and DCIx2 have different coding rates and/or different aggregation levels, they are repetition DCIs, having the same content for providing scheduling information for decoding the same data <NUM> (e.g., URLLC data) in PDSCH <NUM> as shown in <FIG>. Data <NUM> received in PDSCH <NUM> based on the corresponding DCIs can be in transport blocks or in code block groups. By transmitting repetition DCIs (e.g., DCIx1 and DCIx2) in one or more control channels (e.g., PDCCH <NUM>), where each DCI includes the same scheduling information for the same data in the PDSCH (e.g., PDSCH <NUM>), the reliability of URLLC control channel transmission can be improved.

In another example implementation, DCIx1 and DCIx2 may have different coding rates and the same aggregation level. In yet another example implementation, DCIx1 and DCIx2 may have the same coding rate and different aggregation levels. Higher aggregation levels may result in higher blocking probability (e.g., DCIs for different UEs transmitted in overlapped control channel resources due to limited control channel resources).

According to the claimed invention, since multiple CORESETs are included in PDCCH <NUM>, the UE may decode the CORESETs in an order that is explicitly or implicitly indicated in the CORESET configuration.

In the case of an explicit indication, each CORESET may be configured with a decoding order number. <FIG> is a diagram illustrating a CORESET configuration having an explicit indication of decoding order, according to an example implementation not covered by the claims. For example, in CORESET configuration 200A, the decoding order number of CORESET <NUM> is <NUM>, while the decoding order number of CORESET <NUM> is <NUM>. Thus, according to the claimed invention, the UE attempts to decode CORESET <NUM> first before decoding CORESET <NUM> to obtain the corresponding DCIs. If the UE successfully decodes CORESET <NUM>, the UE does not decode CORESET <NUM> for latency reduction. If the UE fails to decode CORESET <NUM>, the UE attempts to decode CORESET <NUM>. <NUM> Not covered by the claims, if the UE successfully decodes CORESET <NUM>, the UE may also decide to decode CORESET <NUM>, and perform soft combining of the decoded DCIx1 and DCIx2 to improve reliability of the URLLC control channel.

In the case of an implicit indication, a decoding order number is not explicitly indicated in each CORESET configuration. Instead, the order in which the CORESETs are arranged in the CORESET configuration may be regarded as the decoding order for the UE to blind decode to receive the respective DCIs. <FIG> is a diagram illustrating a CORESET configuration having an implicit indication of decoding order, according to an example implementation of the present invention. For example, in CORESET configuration 200B, CORESET <NUM> is listed before CORESET <NUM> in the CORESET configuration. Thus, the UE attempts to decode CORESET <NUM> first before decoding CORESET <NUM> to obtain the corresponding DCIs. If the UE successfully decodes CORESET <NUM>, the UE decides not to decode CORESET <NUM> for latency reduction. If the UE fails to decode CORESET <NUM>, the UE attempts to decode CORESET <NUM>. In the example implementations shown in <FIG> and <FIG>, a high-reliability URLLC control channel is achieved by using repetition transmissions of DCIs (e.g., DCIx1 and DCIx2) within the same time resource (e.g., region) for scheduling the same data.

In other implementations, not covered by the claims, the decoding order may be implicitly indicated to the UE based on DCI size, DCI format, or RNTI. For example, the decoding order of the CORESETs may be based on the size of the DCIs (e.g., decoding from the DCI with the largest size to the DCI with the smallest size, or vice versa).

<FIG> is a schematic diagram illustrating multiple CORESETs containing different DCIs in a PDCCH for scheduling repetition data transmissions in a PDSCH, according to an example implementation of the present disclosure. As shown in <FIG>, diagram <NUM> includes PDCCH <NUM> and PDSCH <NUM>. PDCCH <NUM> includes a plurality of control channel elements (CCEs), where CORESETs <NUM>, <NUM>, and <NUM> reside in the CCEs. CORESETs <NUM>, <NUM>, and <NUM> contain information to decode DCIx1, DCIx2, and DCIy, respectively. PDSCH <NUM> includes data 320A and data 320B (e.g., URLLC data), where data 320A and data 320B are repetition transmissions of the same data (e.g., URLLC data) located on different frequency (and/or time) resources in PDSCH <NUM>. PDCCH <NUM> and PDSCH <NUM> may be configured by a base station (e.g., a gNB), and transmitted to a UE.

As shown in <FIG>, in PDCCH <NUM>, several CORESETs are included so that the UE can monitor data scheduling information. For example, the UE may monitor and blind decode CORESETs <NUM>, <NUM>, and <NUM> to obtain DCIx1, DCIx2, and DCIy, respectively, where DCIx1 and DCIx2 may include the same content for providing scheduling information for decoding data 320A (e.g., URLLC data) in PDSCH <NUM>, while DCIy may include content for providing scheduling information for decoding data 320B (e.g., repetition URLLC data) in PDSCH <NUM>. Since users (e.g., URLLC data users) may not need to monitor common search space in consideration for latency reduction, they can attempt to monitor and decode UE-specific search spaces based on, for example, Cell-Radio Network Temporary Identifier (C-RNTI) and the configuration of CORESET from higher layers (e.g., media access control (MAC) layer and radio resource control (RRC) layer).

In the present example implementation, CORESET <NUM> may include frequency resource location, time resource location, and information related to decoding DCIx1 (e.g., maximum number of blind decoding attempt per aggregation level or per CORESET (e.g., PDCCH candidates), aggregation level and coding rate of the DCIx1, and spatial information of CORESET <NUM> (e.g., RX beam information)). Similarly, CORESET <NUM> may include frequency resource location, time resource location, and information related to decoding DCIx2, (e.g., maximum number of blind decoding attempt per aggregation level or per CORESET (i.e., PDCCH candidates), aggregation level and coding rate of DCIx2, and spatial information of CORESET <NUM> (e.g., RX beam information)). In addition, CORESET <NUM> may include frequency resource location, time resource location, and information related to decoding DCIy (e.g., maximum number of blind decoding attempt per aggregation level or per CORESET (e.g., PDCCH candidates), aggregation level and coding rate of DCIy, and spatial information of CORESET <NUM> (e.g., RX beam information)). Moreover, the frequency resource location may be configured in a CORESET configuration, while time resource location may be configured in a search space configuration associated with the CORESET configuration. The search space configuration may be configured separately from the time and frequency configurations, and the CORESET may include a search space index or a search space ID indicating what search space configuration is provided when the search space configuration is not included in the CORESET. Also, the DCIs for scheduling the same data transmission in the PDSCH are repeated in one or more PDCCHs.

In <FIG>, DCIx1 and DCIx2 both contain the scheduling information of the transmission of data 320A, while DCIy contains the scheduling information of the transmission of data 320B, where data 320A and data 320B are repetition transmissions of the same data (e.g., URLLC data) located on different frequency (and/or time) resources in PDSCH <NUM>.

In <FIG>, CORESET <NUM> and CORESET <NUM> respectively contain DCIx1 and DCIx2, which are repetition DCIs having the same content for providing scheduling information for decoding data 320A in PDSCH <NUM> as shown in <FIG>. CORESET <NUM> contains DCIy, which includes scheduling information of the transmission of data 320B. In the present implementation, data 320A and data 320B are repetition transmissions of the same data (e.g., URLLC data) located in different frequency (and/or time) resources in PDSCH <NUM>.

To improve control channel reliability, a DCI can apply lower coding rate. Because a lower coding rate induces a larger payload size of the DCI, a higher aggregation level may be applied to the DCI. In the present example implementation, the repetition transmissions of DCIx1 and DCIx2 have different coding rates and/or different aggregation levels to save more control channel resource as compared to both DCIs applying higher aggregation levels. For example, DCIx1 may have a higher coding rate and a lower aggregation level than DCIx2. It should be noted that, although DCIx1 and DCIx2 have different coding rates and different aggregation levels, they have the same content for scheduling the same data (e.g., URLLC data 320A) in PDSCH <NUM>. By transmitting repetition DCIs (e.g., DCIx1 and DCIx2) in one or more control channels (e.g., PDCCH <NUM>), where each DCI has the same content to schedule the same data (e.g., same data block) in PDSCH <NUM>, the reliability of URLLC control channel can be improved.

As further shown in <FIG>, CORESET <NUM> contains DCIy, which is different from DCIx1 and DCIx2 (collectively referred to as "DCIx"). For example, while DCIx contains the scheduling information of data 320A, DCIy contains the scheduling information of data 320B. DCIx and DCIy may contain different resource allocation information. For example, data 320A may be located on different time and/or frequency resources in PDSCH <NUM> than data 320B. So, DCIx and DCIy may include different information elements to reflect such differences. In other words, DCIx and DCIy are not repetition DCIs. Moreover, the resource allocation information may be different between DCIx and DCIy, or the number of bits may be different between DCIx and DCIy. However, although data 320A and data 320B are located in different regions (e.g., time and/or frequency regions) of PDSCH <NUM>, they are repetition transmissions of the same data (e.g., URLLC data). As a result, the decoded data (e.g., data 320A and data 320B) can achieve higher time or frequency diversity for a high-reliability data channel (e.g., URLLC data channel).

In one example implementation, DCIy may contain information revealing that the scheduled data (e.g., data 320B) of DCIy is the same as the scheduled data (e.g., data 320A) of DCIx. Moreover, DCIy may contain explicit bits for repetition PDSCH or the same HARQ process number as those of DCIx. The DCIx and DCIy may include information elements, such as a new data indicator and/or a redundancy version, for a UE to obtain information of the corresponding data for each DCI. For example, if both the new data indicator and the redundancy version in DCIy are the same as those in DCIx (although the resource allocation information may be different), then the UE may consider DCIx and DCIy as scheduling the same data.

In one example implementation, not covered by the claims, when the UE successfully decodes both DCIx and DCIy, and successfully decodes data 320A scheduled by DCIx, the UE may decide whether to optionally decode data 320B scheduled by DCIy in consideration of specific latency requirements for the URLLC, as decoding data 320B may increase latency. In another example implementation, not covered by the claims, after decoding data 320A scheduled by DCIx, the UE may continue to decode data 320B scheduled by DCIy, and perform soft combining among data 320A and data 320B (e.g., respectively indicated by DCIx and DCIy) to improve the reliability of the data channel (e.g., URLLC data channel).

It is noted that the modulation and coding scheme (MCS) applied to the URLLC data can be different between DCIx and DCIy. The UE may apply different corresponding demodulation and decoding schemes for the same data to achieve higher flexibility and/or diversity.

In one example implementation, data 320A and data 320B may be transmitted in the same time slot, and can share their reference signals for data decoding. For example, a UE can refer to time and frequency reference signals transmitted in data 320B to decode data 320A, so that DCIx does not have to include time and frequency reference signals, or vice versa. Data 320A and data 320B received in PDSCH <NUM> based on the corresponding DCIs can be in transport blocks or in code block groups.

It is noted that, in one implementation, only when the UE fails to decode all relative DCIs, then the UE may consider a control channel failure and count the number for further error handling (e.g. beam failure or radio link failure (RLF)). If the UE can decode at least one DCI based on a higher layer CORESET configuration, the UE may not count the number for error handling, even if there are decoding failures for other configured CORESETs. It is also noted that implementations of the present disclosure can be also used for the grant-free DL transmission, such as preemption transmission. In the present example implementation shown in <FIG>, a high-reliability data channel is achieved by using repetition transmissions of repetition data 320A and data 320B within the same time slot. In other implementations, repetition transmissions of repetition data 320A and data 320B may occur in different time and/or frequency resources.

<FIG> illustrates a flowchart of a method for a high-reliability URLLC control channel, according to an example implementation of the present disclosure.

In action <NUM>, a UE (e.g., for transmitting/receiving URLLC data) receives a CORESET configuration (having multiple CORESETs) from a base station (e.g., a gNB) through higher layer signaling (e.g., MAC control elements (CEs) or RRC signaling).

With reference to <FIG> is a diagram illustrating a CORESET configuration having an explicit indication of decoding order for a high-reliability control channel (e.g., URLLC control channel), according to an example implementation of the present disclosure. In <FIG>, CORESET configuration 500A includes CORESET <NUM> and CORESET <NUM>. CORESET <NUM> indicates that the aggregation level is <NUM>, the number of blind detection/decoding (BD) candidates is <NUM>, the resource allocation starts from resource block (RB) <NUM> and ends at RB <NUM>, the coding rate is <NUM>/<NUM>, and the decoding order is <NUM>. CORESET <NUM> indicates that the aggregation level is <NUM>, the number of BD candidates is <NUM>, the resource allocation starts from RB <NUM> and ends at RB <NUM>, the coding rate is <NUM>/<NUM>, and the decoding order is <NUM>. In one implementation, the number of BD candidates is configured per CORESET. In another implementation, the number of BD candidates can be configured per aggregation level.

With reference to <FIG> is a diagram illustrating a CORESET configuration having an implicit indication of decoding order for a high-reliability control channel (e.g., URLLC control channel), according to an example implementation of the present disclosure. In <FIG>, CORESET configuration 500B includes CORESET <NUM> and CORESET <NUM>, which are substantially similar to CORESET <NUM> and CORESET <NUM>, respectively, in <FIG>. The difference between <FIG> is that, in <FIG>, the decoding order number is not explicitly indicated in CORESET <NUM> and CORESET <NUM>. It should be noted that in <FIG>, the respective DCIs obtained from blind decoding CORESET <NUM> and CORESET <NUM> are the same, which are aimed to provide scheduling information for the same data (e.g., URLLC data) in the PDSCH.

Referring back to <FIG>, in action <NUM> of flowchart <NUM>, the UE performs blind decoding based on the CORESET configuration according to either an explicit or implicit indication of decoding order. In action <NUM>, the UE decodes CORESET <NUM> first based on the decoding order, for example.

With reference to <FIG>, since CORESET <NUM> has an explicit indication of decoding order of <NUM>, the UE may decode CORESET <NUM> first (in action <NUM>) before deciding whether to decode CORESET <NUM>. With reference to <FIG>, the UE may receive DCI corresponding to CORESET <NUM> by blind decoding RB <NUM> to RB <NUM> of control region <NUM> in PDCCH <NUM>, based on the aggregation level of <NUM> and coding rate of <NUM>/<NUM>.

Since CORESET <NUM> has an explicit indication of decoding order of <NUM> as shown in <FIG>, the UE may decode CORESET <NUM> (in action <NUM>) if the UE fails to receive DCI by blind decoding CORESET <NUM> (in action <NUM>). The UE may also decide (in action <NUM>) to optionally decode CORESET <NUM> to improve reliability, after the UE successfully receives DCI by decoding CORESET <NUM> (in action <NUM>). With reference to <FIG>, the UE may receive DCI corresponding to CORESET <NUM> by blind decoding RB <NUM> to RB <NUM> of control region <NUM> in PDCCH <NUM>, based on the aggregation level of <NUM> and coding rate of <NUM>/<NUM>.

With reference to <FIG>, since a decoding order number is not explicitly indicated in CORESET <NUM> and CORESET <NUM>, the order in which the CORESETs are arranged in the CORESET configuration is regarded as the decoding order for the UE to blind decode to receive the respective DCIs in the CORESETs. Thus, since CORESET <NUM> is arranged in the CORESET configuration before CORESET <NUM>, as shown in <FIG>, the UE may decode CORESET <NUM> first (in action <NUM>) before deciding whether to decode CORESET <NUM>. With reference to <FIG>, the UE may receive DCI corresponding to CORESET <NUM> by blind decoding RB <NUM> to RB <NUM> of control region <NUM> in PDCCH <NUM>, according to the aggregation level of <NUM> and coding rate of <NUM>/<NUM>.

Still in <FIG>, since CORESET <NUM> is arranged in the CORESET configuration after CORESET <NUM> in <FIG>, the UE may decode CORESET <NUM> (in action <NUM>) if the UE fails to receive a DCI by blind decoding CORESET <NUM> (in action <NUM>). The UE may also decide (in action <NUM>) to blind decode CORESET <NUM> to receive DCI to improve reliability, after the UE successfully receives a DCI by decoding CORESET <NUM> (in action <NUM>). With reference to <FIG>, the UE may receive a DCI corresponding to CORESET <NUM> by blind decoding RB <NUM> to RB <NUM> of control region <NUM> in PDCCH <NUM>, according to the aggregation level of <NUM> and coding rate of <NUM>/<NUM>.

Referring back to <FIG>, action <NUM> of flowchart <NUM> determines whether the UE successfully decodes DCI from CORESET <NUM>. In action <NUM>, if the UE successfully decodes DCI from CORESET <NUM>, then flowchart <NUM> proceeds to action <NUM>, where the UE decides whether to continue to decode the remaining CORESETs in the CORESET configuration according to the decoding order. In action <NUM>, if the UE decides to decode the remaining CORESETs in the CORESET, then flowchart <NUM> proceeds to action <NUM>, where the UE decodes the next CORESET (e.g., CORESET <NUM>) according to the decoding order. Deciding to decode the remaining CORESETs may be beneficial to the URLLC as multiple DCIs from different CORESETs may be soft combined to increase reliability. In action <NUM>, if the UE decides not to decode the remaining CORESETs in the CORESET configuration, then flowchart <NUM> proceeds to action <NUM>, where the UE decodes the allocated PDSCH resource based on the DCI information to obtain the URLLC data. Deciding not to decode the remaining CORESETs may reduce latency of the URLLC.

In action <NUM>, if the UE does not successfully decode DCI from CORESET <NUM>, then flowchart <NUM> proceeds to action <NUM>, where the UE decodes the next CORESET (e.g., CORESET <NUM>) according to the decoding order.

Action <NUM> of flowchart <NUM> determines whether the UE successfully decodes DCI from CORESET <NUM>. If the UE successfully decodes DCI from CORESET <NUM>, then flowchart <NUM> proceeds to action <NUM>, where the UE performs soft combining of all the decoded DCIs. Subsequently, in action <NUM>, the UE decodes the allocated PDSCH resources based on the DCI information to obtain the URLLC data.

In action <NUM>, if the UE does not successfully decode DCI from CORESET <NUM>, then flowchart <NUM> proceeds to action <NUM>, where the UE recognizes a failure in decoding all of the CORESETs in the CORESET configuration, and considers it as a control channel failure. For example, the UE may identify a PDCCH decoding error, and trigger an error handling procedure.

<FIG> illustrates a flowchart of a method for a high-reliability data channel, according to an example implementation of the present disclosure.

In action <NUM>, a base station (e.g., a gNB) transmits, and a UE (e.g., a UE for transmitting/receiving URLLC data) receives, a CORESET configuration (having multiple CORESETs) through higher layer signaling (e.g., MAC CE or RRC signaling).

With reference to <FIG> is a diagram illustrating an exemplary CORESET configuration having an explicit indication of decoding order for a high-reliability data channel, according to an example implementation of the present disclosure. In <FIG>, CORESET configuration <NUM> includes CORESET <NUM>, CORESET <NUM>, and CORESET <NUM>. CORESET <NUM> indicates that the aggregation level is <NUM>, the number of BD candidates is <NUM>, the resource allocation starts from RB <NUM> and ends at RB <NUM>, the coding rate is <NUM>/<NUM>, and the decoding order is <NUM>. CORESET <NUM> indicates that the aggregation level is <NUM>, the number of BD candidates is <NUM>, the resource allocation starts from RB <NUM> and ends at RB <NUM>, the coding rate is <NUM>/<NUM>, and the decoding order is <NUM>. CORESET <NUM> indicates that the aggregation level is <NUM>, the number of BD candidates is <NUM>, the resource allocation starts from RB <NUM> and ends at RB <NUM>, the coding rate is <NUM>/<NUM>, and the decoding order is <NUM>. In one implementation, the number of BD candidates is configured per CORESET. In another implementation, the number of BD candidates can be configured per aggregation level.

It should be noted that, a decoding order number may not be explicitly indicated in CORESET <NUM>, CORESET <NUM>, and CORESET <NUM>. In such a case, the order in which the CORESETs are arranged in the CORESET configuration may be regarded as the decoding order for the UE to blind decode to receive the respective DCIs in the CORESETs.

Referring back to <FIG>, in action <NUM> of flowchart <NUM>, the UE performs blind decoding based on the CORESET configuration according to either an explicit or implicit indication of decoding order. In action <NUM>, the UE decodes CORESET <NUM> first according to the decoding order, for example, as indicated in CORESET configuration <NUM> in <FIG>.

With reference to <FIG>, since CORESET <NUM> has an explicit indication of decoding order of <NUM>, the UE may decode CORESET <NUM> first (in action <NUM>) before deciding whether to decode CORESET <NUM> and CORESET <NUM>. With reference to <FIG> and <FIG>, the UE may receive DCI corresponding to CORESET <NUM> by blind decoding RB <NUM> to RB <NUM> of control region <NUM> in PDCCH <NUM>, based on the aggregation level of <NUM> and coding rate of <NUM>/<NUM>. Decoding order may be determined by implementation since determination to combine DCI is made by the UE. Moreover, DCIs may not contain the same content, however, DCIs may still indicate to the same data in the PDSCH.

Since CORESET <NUM> has an explicit indication of decoding order of <NUM> as shown in <FIG>, the UE may decode CORESET <NUM> (in action <NUM>) if the UE fails to receive DCI by blind decoding CORESET <NUM> (in action <NUM>). The UE may also decide (in action <NUM>) to decode CORESET <NUM> to improve reliability, after the UE successfully receives DCI by decoding CORESET <NUM> (in action <NUM>). With reference to <FIG> and <FIG>, the UE may receive DCI corresponding to CORESET <NUM> by blind decoding RB <NUM> to RB <NUM> of control region <NUM> in PDCCH <NUM>, based on the aggregation level of <NUM> and coding rate of <NUM>/<NUM>.

Since CORESET <NUM> has an explicit indication of decoding order of <NUM> as shown in <FIG>, the UE may decode CORESET <NUM> if the UE fails to receive DCI by blind decoding CORESET <NUM> (in action <NUM>). The UE may also decide (in action <NUM>) to optionally decode CORESET <NUM> to improve reliability, after the UE successfully receives DCI by decoding CORESET <NUM> (in action <NUM>). With reference to <FIG> and <FIG>, the UE may receive DCI corresponding to CORESET <NUM> by blind decoding RB <NUM> to RB <NUM> of control region <NUM> in PDCCH <NUM>, based on the aggregation level of <NUM> and coding rate of <NUM>/<NUM>.

Referring back to <FIG>, action <NUM> of flowchart <NUM> determines whether the UE successfully decodes DCI from CORESET <NUM>. In action <NUM>, if the UE successfully decodes DCI from CORESET <NUM>, then flowchart <NUM> proceeds to action <NUM>, where the UE decides whether to continue to decode the remaining CORESETs in the CORESET configuration according to the decoding order. In action <NUM>, if the UE decides to decode the remaining CORESETs in the CORESET configuration, then flowchart <NUM> proceeds to action <NUM>, where the UE decodes the next CORESET (e.g., CORESET <NUM>) according to the decoding order. Deciding to decode the remaining CORESETs may be beneficial to the URLLC as multiple DCIs from different CORESETs may be soft combined to increase reliability. In action <NUM>, if the UE decides not to decode the remaining CORESETs in the CORESET configuration, then flowchart <NUM> proceeds to action <NUM>, where the UE compares the received (e.g., decoded) DCIs to see whether the received DCIs schedule repetition data. Deciding not to decode the remaining CORESETs may be beneficial to the URLLC to reduce latency.

Action <NUM> of flowchart <NUM> determines whether the UE successfully decodes DCI from CORESET <NUM>. If the UE successfully decodes DCI from CORESET <NUM>, then flowchart <NUM> proceeds to action <NUM>, where the UE decides whether to continue to decode the remaining CORESETs in the CORESET configuration. In action <NUM>, if the UE decides to decode the remaining CORESETs in the CORESET configuration, then flowchart <NUM> proceeds to action <NUM>, where the UE decodes the next CORESET (e.g., CORESET <NUM>) according to the decoding order. Deciding to decode the remaining CORESETs may be beneficial to the URLLC as multiple DCIs from different CORESETs may be soft combined to increase reliability. In action <NUM>, if the UE decides not to decode the remaining CORESETs in the CORESET configuration, then flowchart <NUM> proceeds to action <NUM>, where the UE compares the received (e.g., decoded) DCIs to see whether the received DCIs schedule repetition data. Deciding not to decode the remaining CORESETs may be beneficial to the URLLC to reduce latency.

In action <NUM>, if the UE does not successfully decode a DCI from CORESET <NUM>, then flowchart <NUM> proceeds to action <NUM>, where the UE decodes the next CORESET (e.g., CORESET <NUM>) according to the decoding order. Action <NUM> of flowchart <NUM> determines whether the UE successfully decodes DCI from CORESET <NUM>. If the UE successfully decodes DCI from CORESET <NUM>, and there are no more CORESETs remaining in the CORESET configuration to be decoded, then flowchart <NUM> proceeds to action <NUM>, where the UE compares the received (e.g., decoded) DCIs to see whether the received DCIs schedule repetition data.

If the UE does not successfully decode DCI from CORESET <NUM> in action <NUM>, then flowchart <NUM> proceeds to action <NUM>, where the UE recognizes a control channel failure, since the decoding of all CORESETs in the CORESET configuration have been unsuccessful. For example, the UE may identify a PDCCH decoding error, and trigger an error handling procedure.

Referring to <FIG>, as shown in <FIG>, the DCI is from control region <NUM>, and includes information elements, such as a carrier indicator, a resource allocation header, resource allocation information (Start RB # and RB length), a modulation and coding scheme (MCS) index, a HARQ process number, a new data indicator, transmit power control (TPC) for PUCCH, and a downlink assignment index (DAI). In <FIG>, the resource allocation for the scheduled data starts from RB <NUM>, and has an RB length of <NUM>, which corresponds to data region X in <FIG>. Also shown in <FIG>, the MCS index is <NUM>. The HARQ number is <NUM>. The new data indicator is <NUM>.

As shown in <FIG>, the DCI is from control region <NUM>, and includes information elements, such as carrier indicator, resource allocation header, resource allocation information (Start RB # and RB length), MCS index, HARQ number, new data indicator, TPC for PUCCH, and DAI. As shown in <FIG>, the resource allocation for the scheduled data starts from RB <NUM>, and has an RB length of <NUM>, which corresponds to data region Y in <FIG>. Also shown in <FIG>, the MCS index is <NUM>. The HARQ number is <NUM>. The new data indicator is <NUM>.

As shown in <FIG>, the DCI is from control region <NUM>, and includes information elements, such as carrier indicator, resource allocation header, resource allocation information (Start RB # and RB length), MCS index, HARQ number, new data indicator, TPC for PUCCH, and DAI. As shown in <FIG>, the resource allocation for the scheduled data starts from RB <NUM>, and has an RB length of <NUM>, which corresponds to data region Z in <FIG>. Also shown in <FIG>, the MCS index is <NUM>. The HARQ number is <NUM>. The new data indicator is <NUM>.

In one implementation, the DCIs in <FIG>, and <FIG> may further include bandwidth part(s) (BWP(s)) to indicate the corresponding frequency band(s) (e.g., by indicating the center frequency or using a BWP index where the indexing of BWP is pre-configured). In one implementation, the repetition data may be transmitted through different BWPs.

Referring back to <FIG>, after decoding all of the CORESETs, the UE may decide to decode and receiving all the corresponding DCIs in action <NUM> of flowchart <NUM>, the UE compares the received DCIs to determine whether there are received DCIs for scheduling repetition data in the PDSCH. For example, the UE may compare the corresponding information elements contained each DCI.

With reference to <FIG>, in one implementation, because the DCI from control region <NUM> and the DCI from control region <NUM> have the same new data indicator (e.g., <NUM>) and redundancy version, the UE considers these two DCIs schedule repetition data in the PDSCH. That is, data region X and data region Y in <FIG> contain repetition data. The UE may decide (in action <NUM>) whether to decode the data in data region Y, if data from data region X can be successfully recovered, and vice versa. The UE may decide (in action <NUM>) to decode both the data in data region X and in data region Y, and soft combining the data obtained from the two regions to increase reliability. If the UE decides (in action <NUM>) not to decode both the repetition data in data region X and in data region Y, then the UE may decode the allocated PDSCH resource based on only one of the DCIs scheduling the respective data (in action <NUM>), and ignore the rest of the redundant DCI(s) scheduling the respective data (in action <NUM>).

With reference to <FIG>, in one implementation, because the DCI from control region <NUM> has a different new data indicator (e.g., <NUM>) and redundancy version than those from DCIs shown in <FIG>, the UE considers the DCI in region <NUM> schedule different data in data region Z than those contained in data regions X and Y. That is, data region Z in <FIG> does not contain repetition data as compared to data regions X and Y. Then, the UE needs to decode data region Z (in action <NUM>), since data regions Z contains different data than what is contained in data regions X and Y.

Referring back to <FIG>, in action <NUM> of flowchart <NUM>, if the UE determines that there are no DCIs received for scheduling repetition data (same data), then flowchart <NUM> proceeds to action <NUM>, where the UE decodes the allocated PDSCH resource based on the DCI to acquire the URLLC data. In action <NUM>, if the UE determines that there are DCIs received for scheduling repetition data (same data), then flowchart <NUM> proceeds to action <NUM>, where the UE decides whether to decode the repetition data. In action <NUM>, if the UE decides to not decode the repetition data, then flowchart <NUM> proceeds to action <NUM>, where the UE ignores the redundant DCIs which schedule repetition data, and then proceeds to action <NUM>, where the UE decodes the allocated PDSCH resources based on the DCI to acquire the URLLC data. In action <NUM>, if the UE decides to decode the repetition data, then flowchart <NUM> proceeds to action <NUM>, where the UE decodes the allocated PDSCH resources based on the DCIs, and performs soft combining of the repetition data to obtain data (e.g., URLLC data) with improved reliability.

<FIG> illustrates a block diagram of a node for wireless communication, in accordance with various aspects of the present disclosure. As shown in <FIG>, a node <NUM> may include a transceiver <NUM>, a processor <NUM>, a memory <NUM>, one or more presentation components <NUM>, and at least one antenna <NUM>. The node <NUM> may also include an RF spectrum band module, a base station communications module, a network communications module, and a system communications management module, input/output (I/O) ports, I/O components, and power supply (not explicitly shown in <FIG>). Each of these components may be in communication with each other, directly or indirectly, over one or more buses <NUM>. In one implementation, the node <NUM> may be a UE or a base station that performs various functions described herein, for example, with reference to <FIG>.

The transceiver <NUM> having a transmitter <NUM> and a receiver <NUM> may be configured to transmit and/or receive time and/or frequency resource partitioning information. In some implementations, the transceiver <NUM> may be configured to transmit in different types of subframes and slots including, but not limited to, usable, non-usable and flexibly usable subframes and slot formats.

The node <NUM> may include a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the node <NUM> and include both volatile and non-volatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data.

Computer storage media includes RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. Computer storage media does not comprise a propagated data signal. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

The memory <NUM> may include computer-storage media in the form of volatile and/or non-volatile memory. The memory <NUM> may be removable, non-removable, or a combination thereof. Exemplary memory includes solid-state memory, hard drives, optical-disc drives, and etc. As illustrated in <FIG>, The memory <NUM> may store computer-readable, computer-executable instructions <NUM> (e.g., software codes) that are configured to, when executed, cause the processor <NUM> to perform various functions described herein, for example, with reference to <FIG>. Alternatively, the instructions <NUM> may not be directly executable by the processor <NUM> but be configured to cause the node <NUM> (e.g., when compiled and executed) to perform various functions described herein.

The processor <NUM> may include an intelligent hardware device, e.g., a central processing unit (CPU), a microcontroller, an ASIC, and etc. The processor <NUM> may include memory. The processor <NUM> may process the data <NUM> and the instructions <NUM> received from the memory <NUM>, and information through the transceiver <NUM>, the base band communications module, and/or the network communications module. The processor <NUM> may also process information to be sent to the transceiver <NUM> for transmission through the antenna <NUM>, to the network communications module for transmission to a core network.

One or more presentation components <NUM> presents data indications to a person or other device. Exemplary presentation components <NUM> include a display device, speaker, printing component, vibrating component, and etc..

Claim 1:
A method comprising:
receiving (<NUM>), by a user equipment, UE, first downlink control information, DCI, in a first control resource set, CORESET, the first DCI providing first scheduling information for transmission of first data over a first physical downlink shared channel, PDSCH;
receiving (<NUM>), by the UE, second DCI in a second CORESET, the second DCI providing second scheduling information for transmission of second data, which is the same as the first data, over a second PDSCH;
receiving, by the UE, the first data over the first PDSCH and the second data over the second PDSCH using, respectively, the first scheduling information and second scheduling information; and
receiving (<NUM>), by the UE, a CORESET configuration, wherein the first CORESET and the second CORESET are decoded, by the UE, in an order in which the first CORESET and the second CORESET are arranged in the CORESET configuration, wherein if the CORESET arranged first in the CORESET configuration is successfully decoded, the UE does not decode the CORESET arranged second in the CORESET configuration, and wherein if decoding the CORESET arranged first in the CORESET configuration fails, the UE decodes the CORESET arranged second in the CORESET configuration,
wherein the first and second CORESETs are received using at least one of different time resources, different frequency resources, and different beams.