Network Data Scheduling and Transmission for UEs with Reduced Capabilities

Abstract

A base station of a wireless network transmits scheduling information to a user equipment (UE). The base station divides the scheduling information for the UE into a common downlink control information (DCI) part and a UE-specific DCI part, encodes the common DCI part for transmission on a first physical resource, encodes the UE-specific DCI part for transmission on a second physical resource, transmits the encoded common DCI part on the first physical resource, and transmits the encoded UE-specific DCI part on the second physical resource.

Description

Background Art

[0001] 5G New Radio (NR) wireless communication supports a variety of different types of user equipment (UE). For example, in addition to mobile phones, 5G NR supports Internet of Things (IoT) devices, industrial IoT (IIoT) devices, wearable devices, etc. Some of these devices are referred to as Reduced Capability (RedCap) UEs, which have varying wireless capabilities compared to other UEs. There may be situations in which the network wants to treat RedCap UEs differently from other types of UEs. Summary of the Invention

[0002] Some exemplary embodiments relate to a base station of a wireless network, the base station having: a transceiver configured to connect to a user equipment (UE); and a processor communicatively coupled to the transceiver and configured to perform operations. These operations include: dividing scheduling information for the UE into a common downlink control information (DCI) part and a UE-specific DCI part; encoding the common DCI part for transmission on a first physical resource; encoding the UE-specific DCI part for transmission on a second physical resource; transmitting the encoded common DCI part on the first physical resource; and transmitting the encoded UE-specific DCI part on the second physical resource.

[0003] Other exemplary embodiments relate to a baseband processor configured to perform operations. These operations include: dividing scheduling information for a user equipment (UE) into a common downlink control information (DCI) part and a UE-specific DCI part; encoding the common DCI part for transmission on a first physical resource; encoding the UE-specific DCI part for transmission on a second physical resource; transmitting the encoded common DCI part on the first physical resource; and transmitting the encoded UE-specific DCI part on the second physical resource. Brief Description of the Drawings

[0004] Figure 1 An exemplary network arrangement according to various exemplary embodiments is shown.

[0005] Figure 2 An exemplary UE according to various exemplary embodiments is shown.

[0006] Figure 3 An exemplary base station configured to establish a connection with a user equipment according to various exemplary embodiments is shown.

[0007] Figure 4 An exemplary encoding process for scheduling information according to various exemplary embodiments is shown.

[0008] Figure 5 Illustrates exemplary FRDA fields of a common DCI part according to various exemplary embodiments.

[0009] Figure 6 Illustrates an exemplary diagram of a common DCI part that shows a set of resource configurations for frequency domain resource allocation (FDRA) according to various exemplary embodiments.

[0010] Figure 7 Illustrates an exemplary UE-specific DCI part according to various exemplary embodiments. Detailed Description

[0011] The exemplary embodiments can be further understood with reference to the following description and the related drawings, in which like elements have the same reference numerals. The exemplary embodiments describe a way of dividing downlink (DL) and / or uplink (UL) scheduling information into two parts and transmitting different parts on different physical channels / signals.

[0012] The exemplary embodiments are described with reference to a network including 5G New Radio (NR) radio access technology (RAT). However, the exemplary embodiments can be implemented in other types of networks using the principles described herein.

[0013] The exemplary embodiments are also described with reference to a UE. However, the use of the UE is for illustrative purposes only. The exemplary embodiments can be utilized with any electronic component that can establish a connection with a network and is configured with hardware, software, and / or firmware for exchanging information and data with the network. Thus, the UE described herein is used to represent any electronic component.

[0014] As mentioned above, there are various types of UEs, each with different capabilities to connect to a 5G NR network. Before describing the exemplary embodiments, several examples of RedCap UEs and their characteristics will be described. In a first example, devices in an industrial environment such as temperature or humidity sensors can be connected industrial devices. However, such devices are fixed, not latency-critical, and are completely uncomplicated with respect to their capabilities and hardware. These devices generally do not require low-latency data exchange provided by ultra-reliable low-latency communication (URLLC) or IIoT. It is also expected that these devices will operate in the field for many years with little or no maintenance (including battery replacement). Thus, power-saving operations may be critical for these types of devices.

[0015] Another example of a RedCap type device with capabilities different from other UEs is a monitoring device (e.g., a camera). These devices are similar to the devices in the first example in that they are typically stationary and do not have strict latency requirements. However, they can be different from the first example in that these devices can be connected to a permanent power source (although not necessarily) and can have a much higher upload data rate, for example, due to the video upload feed they are providing, compared to many other UEs.

[0016] Yet another example of a RedCap type device with capabilities different from many other UEs is a wearable device. Different from the above examples, wearable devices typically have a mobility similar to that of a mobile phone and operations related to the same types of applications that can be executed on a mobile phone. However, due to the smaller form factor resulting in a smaller battery, these devices have more stringent power saving requirements than mobile phones.

[0017] These examples of different types of UEs are by no means an exhaustive list of 5G-capable devices, but are provided as examples of the varying capabilities of different UEs connected to a 5G NR wireless network at any given time. Devices considered to be RedCap devices can be determined in various ways. For example, a RedCap device can be defined by the type of device (e.g., wearable device, monitoring device, etc.). In another example, a RedCap device can be defined by the capabilities / functions of the device (e.g., battery life, processing power, latency requirements, etc.). The definition of a UE's qualification as a RedCap UE can be set by a standard (e.g., 3GPP standard) or can be decided by an individual network provider.

[0018] As mentioned above, one consideration in the case of RedCap devices may be more stringent power saving than standard UEs to reduce battery usage and extend battery life. An exemplary way to reduce power consumption can be to reduce the monitoring of the physical downlink control channel (PDCCH) by the RedCap device. This reduced monitoring of the PDCCH can include a smaller number of blind decodings and control channel element (CCE) restrictions. However, there may be issues associated with the reduced number of blind decodings and CCE restrictions. For example, this can lead to an increased PDCCH blocking probability, which can result in increased latency. This problem may be more severe for RedCap devices because these RedCap devices typically use a larger aggregation level / CCE due to the reduced number of Rx antennas and bandwidth.

[0019] According to some exemplary embodiments, downlink (DL) and / or uplink (UL) scheduling information may be divided into two parts: a common DCI part and a UE-specific DCI part. These different parts of a single scheduling may be transmitted on different physical channels / signals. Exemplary scheduling information will be described in more detail below.

[0020] Figure 1 An exemplary network arrangement 100 is shown according to various exemplary embodiments. The exemplary network arrangement 100 includes a UE 110. It should be noted that any number of UEs may be used in the network arrangement 100. Those skilled in the art will understand that the UE 110 may alternatively be any type of electronic component configured to communicate via a network, such as, for example, a mobile phone, a tablet computer, a desktop computer, a smart phone, a phablet, an embedded device, a wearable device, an Internet of Things (IoT) device, etc. It should also be understood that an actual network arrangement may include any number of UEs used by any number of users. Therefore, for illustrative purposes, only an example with a single UE 110 is provided.

[0021] The UE 110 may be configured to communicate with one or more networks. In the example of the network configuration 100, the networks with which the UE 110 may communicate wirelessly are a 5G New Radio (NR) radio access network (5GNR-RAN) 120, an LTE radio access network (LTE-RAN) 122, and a wireless local area network (WLAN) 124. However, it should be understood that the UE 110 may also communicate with other types of networks, and the UE 110 may also communicate with a network via a wired connection. Therefore, the UE 110 may include a 5G NR chipset for communicating with the 5G NR-RAN 120, an LTE chipset for communicating with the LTE-RAN 122, and an ISM chipset for communicating with the WLAN 124.

[0022] The 5G NR-RAN 120 and the LTE-RAN 122 may be part of a cellular network that may be deployed by a cellular provider (e.g., Verizon, AT&T, T-Mobile, etc.). These networks 120, 122 may include, for example, cells or base stations (NodeB, eNodeB, HeNB, eNBS, gNB, gNodeB, macro cell base stations, micro cell base stations, small cell base stations, femto cell base stations, etc.) configured to send and receive traffic from UEs equipped with appropriate cellular chipsets. The WLAN 124 may include any type of wireless local area network (WiFi, hotspots, IEEE 802.11x networks, etc.).

[0023] UE 110 can be connected to the 5G NR-RAN 120 via gNB 120A and / or gNB 120B. During operation, UE 110 can be within the range of multiple gNBs. Thus, simultaneously or alternatively, UE 110 can be connected to the 5G NR-RAN 120 via gNBs 120A and 120B. Additionally, UE 110 can communicate with eNB 122A of the LTE-RAN 122 to transmit and receive control information for downlink and / or uplink synchronization for connection with the 5G NR-RAN 120.

[0024] Those skilled in the art will understand that any relevant processes can be performed for UE 110 to connect to the 5G NR-RAN 120. For example, as described above, the 5G NR-RAN 120 can be associated with a specific cellular provider where UE 110 and / or its user has protocol and credential information (e.g., stored on a SIM card). When the presence of the 5G NR-RAN 120 is detected, UE 110 can transmit the corresponding credential information to be associated with the 5G NR-RAN 120. More specifically, UE 110 can be associated with a specific base station (e.g., gNB 120A of the 5G NR-RAN 120).

[0025] In addition to networks 120, 122, and 124, the network arrangement 100 further includes a cellular core network 130, the Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network service backbone 160. The cellular core network 130 (e.g., 5GC of NR) can be regarded as an interconnected collection of components that manage the operations and traffic of the cellular network. The cellular core network 130 also manages the traffic flowing between the cellular network and the Internet 140.

[0026] The IMS 150 can generally be described as an architecture for delivering multimedia services to UE 110 using IP protocols. The IMS 150 can communicate with the cellular core network 130 and the Internet 140 to provide multimedia services to UE 110. The network service backbone 160 communicates directly or indirectly with the Internet 140 and the cellular core network 130. The network service backbone 160 can generally be described as a set of components (e.g., servers, network storage arrangements, etc.) that implement a set of services that can be used to extend the functions for UE 110 to communicate with various networks.

[0027] Figure 2 An exemplary UE 110 is shown in accordance with various exemplary embodiments. It will be referred to Figure 1The UE 110 is described with respect to the network arrangement 100. For the purposes of this discussion, the UE 110 may be considered a Reduced Capability (RedCap) UE. However, it should be noted that the UE 110 may represent any electronic device and may include a processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. The other components 230 may include, for example, an audio input device, an audio output device, a battery providing a limited power source, a data acquisition device, a port for electrically connecting the UE 110 to other electronic devices, one or more antenna panels, etc. For example, the UE 110 may be coupled to an industrial device via one or more ports.

[0028] The processor 205 may be configured to execute multiple engines of the UE 110. For example, the engines may include a scheduling information monitoring engine 235. The scheduling information monitoring engine 235 may perform various operations related to monitoring scheduling information from the network.

[0029] The above engines are merely exemplary as applications (e.g., programs) executed by the processor 205. The functions associated with the engines may also be represented as separate integrated components of the UE 110 or may be modular components coupled to the UE 110, e.g., integrated circuits with or without firmware. For example, an integrated circuit may include an input circuitry for receiving signals and a processing circuitry for processing the signals and other information. The engines may also be embodied as one application or separate multiple applications. Additionally, in some UEs, the functionality described for the processor 205 is shared between two or more processors such as a baseband processor and an application processor. The exemplary embodiments may be implemented in any of these or other configurations of the UE.

[0030] The memory arrangement 210 may be a hardware component configured to store data related to operations performed by the UE 110. The display device 215 may be a hardware component configured to display data to a user, while the I / O device 220 may be a hardware component that enables a user to make inputs. The display device 215 and the I / O device 220 may be separate components or may be integrated together (such as a touchscreen). The transceiver 225 may be a hardware component configured to establish connections with the 5G NR-RAN 120, LTE-RAN 122, WLAN 124, etc. Thus, the transceiver 225 may operate on multiple different frequencies or channels (e.g., a set of contiguous frequencies).

[0031] Figure 3An exemplary network cell according to various exemplary embodiments is shown, in this example, as gNB 120A. gNB 120A may represent any access node of a 5G NR network that a UE 110 may use to establish a connection. Figure 3 The gNB 120A shown may also represent gNB 120B.

[0032] gNB 120A may include a processor 305, a memory arrangement 310, an input / output (I / O) device 320, a transceiver 325, and other components 330. The other components 330 may include, for example, a power supply, a data acquisition device, ports that electrically connect gNB 120A to other electronic devices, and the like.

[0033] The processor 305 may be configured to execute multiple engines of gNB 120A. For example, the engines may include a RedCap scheduling engine 335 for performing operations related to scheduling RedCap devices. Examples of scheduling RedCap devices will be described in more detail below.

[0034] The above engines, as applications (e.g., programs) executed by the processor 305, are merely exemplary. The functions associated with the engines may also be represented as standalone integrated components of gNB 120A, or may be modular components coupled to gNB 120A, e.g., integrated circuits with or without firmware. For example, an integrated circuit may include an input circuitry for receiving signals and a processing circuitry for processing the signals and other information. Additionally, in some gNBs, the functions described for the processor 305 are split among multiple processors (e.g., a baseband processor, an application processor, etc.). The exemplary aspects may be implemented in any of these or other configurations of the gNB.

[0035] The memory 310 may be a hardware component configured to store data related to operations performed by UEs 110, 112. The I / O device 320 may be a hardware component or port that enables a user to interact with gNB 120A. The transceiver 325 may be a hardware component configured to exchange data with UE 110 and any other UE in the system 100. The transceiver 325 may operate at various different frequencies or channels (e.g., a set of contiguous frequencies). Thus, the transceiver 325 may include one or more components (e.g., radio components) to enable data exchange with various networks and UEs.

[0036] As described above, in some exemplary embodiments, downlink (DL) and / or uplink (UL) scheduling information may be divided into two parts: a common DCI part and a UE-specific DCI part. These different parts of a single scheduling may be transmitted on different physical channels / signals. For example, the common DCI part may be transmitted on the PDCCH, and the UE-specific DC part may be mapped on the physical downlink shared channel (PDSCH). In some exemplary embodiments, a frequency domain resource allocation (FDRA) for the PDSCH including the UE-specific DCI part may be conveyed to the UE in the common DCI part.

[0037] Figure 4 An exemplary encoding process 400 for scheduling information according to various exemplary embodiments is shown. This encoding process 400 may be performed, for example, by the gNB 120A when sending scheduling information to the UE 110. In the exemplary encoding process 400, separate encoding steps may be applied to the common DCI part and the UE-specific DCI part, including independent channel coding and corresponding CRC attachment.

[0038] In 410, the gNB 120A has scheduling information bits for the UE 110. As will be described in more detail below, the scheduling information bits 410 may include scheduling information for multiple UEs. The gNB 120A may then divide the scheduling information bits 410 into a common DCI part 420 and a UE-specific DCI part 430. The gNB 120A may then encode each of these parts separately. For example, the common DCI part 420 may be encoded through the following steps: cyclic redundancy check (CRC) calculation 440, applying a radio network temporary identifier (RNTI) mask 450, attaching CRC 460, channel coding 470, rate matching 480, and mapping the encoded common DCI part 490 to the PDCCH. Similarly, the UE-specific DCI part 430 may be encoded through the following steps: cyclic redundancy check (CRC) calculation 445, applying a radio network temporary identifier (RNTI) mask 455, attaching CRC 465, channel coding 475, rate matching 485, and mapping the encoded common DCI part 495 to the PDSCH.

[0039] In some exemplary embodiments, a common RNTI may be used to mask the CRCs of both the common DCI part and the UE-specific DCI part, so that the UE can identify the corresponding DCI part. For example, the RNTI "X" of 450 and the RNTI "Y" of 455 may be the same. For example, the RNTI may be a group common RNTI assigned by gNB 120A to more than one UE. Consider an example of a RedCap device acting as an industrial sensor. Multiple industrial sensors may be assigned the same RNTI by gNB 120A. Thus, UE 110 may be assigned the same RNTI as multiple other UEs.

[0040] In other exemplary embodiments, the RNTI "X" of 450 and the RNTI "Y" of 455 may be different. In further exemplary embodiments, RNTI scrambling may be used for only one of these parts. For example, only the RNTI "X" of 450 is used to scramble the common DCI part 420, and no RNTI scrambling is applied to the UE-specific DCI part 130 because it is mapped to dedicated PDSCH resources. In Figure 4 the example, the scrambling is based on an XOR operation. However, any type of operation may be used for scrambling.

[0041] In some exemplary embodiments, the lengths of the CRCs 440, 445 may be the same or different. For example, a shorter CRC (e.g., length-8) may be used in 445 because it is mapped on the PDSCH resource. A CRC appending operation may be used to append the masked CRC bits to the associated partial bits.

[0042] A description of exemplary information (or fields) that may be included in the common DCI part 420 of scheduling information is provided below. It should be understood that the following fields are merely exemplary. The common DCI part 420 may include all of the described fields, a subset of the described fields, or additional fields not specifically described herein. In a first example, the common DCI part 420 may include a DCI format flag that can be used to distinguish DCI formats of the same size. In a second example, the common DCI part 420 may include a frequency domain resource allocation (FDRA) field that can be used to allocate resources in the frequency domain. In a third example, the common DCI part 420 may include a time domain resource allocation (TDRA) field that can be used to allocate resources in the time domain. In a fourth example, the common DCI part 420 may include a UE-specific DCI part payload size indicator field that can be used to signal the payload size of the UE-specific DCI part 430. In a fifth example, the common DCI part 420 may include a UE-specific DCI part resource size indicator field that can be used to signal the resource size of the UE-specific DCI part 430. In a sixth example, the common DCI part 420 may include a modulation and coding scheme (MCS) field. Some of these examples will be described in more detail below.

[0043] As described above, the common DCI part 420 may include an FDRA field for both DL and UL scheduling. Figure 5 An exemplary FRDA field 500 of the common DCI part 420 is shown according to various exemplary embodiments. In this example, the FRDA field 500 includes a subfield 510 and a subfield 520. In some exemplary embodiments, the subfield 510 may include a bitmap corresponding to the first expression of the following equation (1), and the subfield 520 may include a bitmap corresponding to the second expression of the following equation (1). In some exemplary embodiments, the FRDA may be represented by the following equation:

[0044] Equation (1):

[0045] A bitmap having bits in the subfield 510 may provide a start Redcap-SB index, where N RB is the DL or UL bandwidth configuration expressed in terms of the number of resource blocks (RBs), and N RedCap is the RedCap bandwidth configuration expressed in terms of the number of RBs. In one example, N RedCap may be defined by a standard (e.g., a 3GPP standard) and may correspond to, for example, a 20 MHz bandwidth.

[0046] Having [log2(N RedCap (N RedCapA bitmap with resource allocation type 1 in the sub-field 520 of [(+1) / 2)] bits can be used to indicate to the scheduled UE a set of continuously allocated and non-interleaved virtual resource blocks within a Redcap sub-band (Redcap-SB).

[0047] In other exemplary embodiments, sub-field 510 may include a bitmap corresponding to the first expression of the following equation (2), and sub-field 520 may include a bitmap corresponding to the second expression of the following equation (2). In some exemplary embodiments, FRDA may be represented by the following equation:

[0048] Equation (2):

[0049] In this example, RedCap narrowband (NB) can be used to further reduce signaling overhead. N NB can be non-overlapping consecutive physical resource blocks (PRBs) in the frequency domain. The total NB in the RedCap bandwidth can be given by the following equation: In some exemplary embodiments, N NB value can be configured on a per-UE basis by system information block or dedicated radio resource control (RRC) signaling. In other exemplary embodiments, N NB value can be provided by a standard (e.g., 3GPP standard) based on numerology, for example.

[0050] In a further exemplary embodiment, sub-field 510 may include a bitmap corresponding to the first expression of the following equation (3), and sub-field 520 may include a bitmap corresponding to the second expression of the following equation (3). In some exemplary embodiments, FRDA may be represented by the following equation:

[0051] Equation (3):

[0052] This first expression is the same as the first expression of Equation (2). In this example, a set of resource configurations can be provided to one or more UEs by gNB 120A. This information includes the start RB and the number of consecutive RBs. Part of the FDRA sub-field 520 uses [log2K] to dynamically indicate one of the configured resource sets, where K is the number of RB resource sets. Refer to the following Figure 6 for examples providing such types of exemplary embodiments.

[0053] Figure 6 Exemplary illustration 600 shows a common DCI part for providing a set of resource configurations for frequency domain resource allocation (FDRA) according to various exemplary embodiments. In Figure 6 example, K = 4 can be considered. For example, there are 4 RB resource sets. In Figure 6Among them, these 4 RB resource sets are shown as resource set 0 - 610, resource set 1 - 620, resource set 2 - 630, and resource set 4 - 640. It is also possible to consider that the FDRA sub - field 520 is 2 - bit, such that this field can identify any one of the resource sets 610 - 640 (e.g., 00, 01, 10, 11, each corresponding to one of the 4 resource sets).

[0054] Thus, in this example, the common DCI part 605 may include a bitmap corresponding to the 2 expressions of equation (3). The first expression can identify the starting RB and the number of consecutive RBs for the UE - specific DCI part 650. The second expression [log2K] identifies the resource set that includes the UE - specific DCI part 630. In this example, [log2K] is set to identify 0,0 of resource set 0 - 610. Thus, when UE 110 decodes the common DCI part 605, UE 110 will understand that the UE - specific DCI part 650 is associated with resource set 0 - 610, and according to the first expression, identify the starting RB and the number of consecutive RBs for the UE - specific DCI part 650, as Figure 6 shown.

[0055] In an additional exemplary embodiment, an offset relative to the starting PRB of the common DCI part 420 can be used to signal the frequency - domain position of the UE - specific DCI part 430. For example, a set of offset values can first be configured by a higher layer, and then an FDRA field can be used to dynamically signal one of these offset values.

[0056] As described above, the common DCI part 420 may also include TDRA fields for both DL and UL scheduling. UE 110 can be configured by a higher layer to have multiple TDRAs, and then the TDRA field of the common DCI part 420 can be used to dynamically signal one of these TDRAs.

[0057] As described above, the common DCI part 420 may also include a UE - specific DCI part payload size indicator field that can be used to signal the payload size of the UE - specific DCI part 430.

[0058] In some exemplary embodiments, the UE - specific DCI part payload size indicator field can be specified by a standard (e.g., 3GPP standard) UE - specific DCI part payload size indicator field or configured by RRC signaling. Then, the "UE - specific DCI part payload size indicator field" can be used to dynamically signal one of the candidate sizes.

[0059] In other exemplary embodiments, the UE-specific DCI part payload size may be indicated by bitmap signaling. For example, each bit may indicate the presence of a UE-specific DCI part 430 for a specific UE. For example, if the bit is set to "1" for UE 110, this indicates the presence of a UE-specific DCI part 430 payload. Otherwise, the UE-specific DCI part 430 does not exist. In this design, the size of the UE-specific DCI part payload may vary according to the actual number "M" of UEs scheduled by the common DCI part 420. For example, where Δ is the payload size of the UE-specific DCI part 430 for a single user. The payload size may be specified by a standard (e.g., 3GPP standard) or configured by RRC signaling.

[0060] As described above, the common DCI part 420 may also include a UE-specific DCI part resource size indicator field that can be used to signal the resource size of the UE-specific DCI part 430. This information can be used to reduce the number of blind decodings performed by UE 110, e.g., by reducing the search space for UE-specific information in the PDSCH.

[0061] In some exemplary embodiments, the resources for transmitting the UE-specific DCI part 430 are signaled using an aggregation level. The aggregation level can be converted to the number of six RBs on multiple consecutive symbols or multiple resource elements (REs) on which the UE-specific DCI part 430 can be received and decoded by a RedCap device.

[0062] In other exemplary embodiments, the number of consecutive symbols for UE-specific DCI part 430 transmission is signaled on all RBs allocated by the FDRA field, starting from the first symbol after the demodulation reference signal (DMRS) symbol.

[0063] In a further exemplary embodiment, the UE-specific DCI part resource size field signals one value from a set of offset values that can be configured by RRC signaling. UE 110 can determine the number of modulation coding symbols / REs of the UE-specific DCI part resource based on, for example, the UE-specific DCI part payload size (as described above), the number of CRC bits, and / or the value.

[0064] As described above, the common DCI part 420 may also include an MCS field. In some exemplary embodiments, one value can be signaled and applied jointly to the UE-specific DCI part 430 and the PDSCH / PUSCH transmissions of the DL-SCH and UL-SCH.

[0065] In other exemplary embodiments, the MCS value indicated in the common DCI part 420 is only applied to the UE-specific DCI part 430. The MCS value for the PDSCH / PUSCH is further indicated by the UE-specific DCI part 430. This design allows different MCSs to be used for data transmissions to different UEs, even if they are mapped on a single PDSCH / PUSCH resource. This can improve spectral efficiency.

[0066] The UE-specific DCI part 430 can be divided into blocks, such as block number 1, block number 2, …, block number K. In some exemplary embodiments, each block can be configured by a higher layer for a given UE. In other exemplary embodiments, different blocks can be allocated for DL and UL scheduling of a single UE.

[0067] The following provides a description of exemplary information (or fields) that can be included in the UE-specific DCI part 430 of the scheduling information. It should be understood that the following fields are only exemplary. The UE-specific DCI part 420 can include all the described fields, a subset of the described fields, or additional fields not specifically described herein.

[0068] The following fields can be used for DL and / or UL scheduling. In the case of UL scheduling, the following fields can be determined by the UE. In a first example, the UE-specific DCI part 430 can include an MCS field. In some exemplary embodiments, when the MCS field also exists in the common DCI part 420, the incremental MCS or MCS update information relative to the MCS indicated by the common DCI part 430 with fewer bits can be included in this field. In other exemplary embodiments, one MCS field can be shared by all blocks instead of being shared within each block to reduce signaling overhead.

[0069] In a second example, the UE-specific DCI part 430 can include a new data indicator (NDI) field. In a third example, the UE-specific DCI part 430 can include a redundancy version (RV) field. In a fourth example, the UE-specific DCI part 430 can include a HARQ process number (HPI) field. In a fifth example, the UE-specific DCI part 430 can include a UE-ID or a UE-specific index field determined by the UE-ID. The UE-index can be configured by RRC signaling or determined based on a hard-coded equation according to the UE-ID. In a sixth example, the UE-specific DCI part 430 can include a TPC command field for the scheduled PUCCH / PUSCH.

[0070] The following fields can be used for PDSCH scheduling. In a first example, the UE-specific DCI part 430 may include a Downlink Allocation Index (DAI) field. In a second example, the UE-specific DCI part 430 may include a PUCCH Resource Indicator (PRI) field. In a third example, the UE-specific DCI part 430 may include a PDSCH to HARQ-Feedback Timing Indicator field. It should be noted that in the above examples, one or more of the described fields may be included in the common DCI part 420.

[0071] Figure 7 An exemplary UE-specific DCI part 430 according to various exemplary embodiments is shown. The exemplary UE-specific DCI part 430 includes K blocks 710, and as described above, each block may be associated with a different UE. In this example, the UE-specific DCI part 430 has a shared MCS field 715 and can be applied to all transport blocks (TBs) 720 scheduled by this DCI. The TBs 720 for different UEs may be scrambled with a UE-specific sequence before modulation, which is generated based on a dedicated UE-ID or a common RNTI (C-RNTI). In some exemplary embodiments, different scrambling sequences may be used for UE-specific DCI partition bits. For example, in some embodiments, the UE-specific DCI part 430 bits are scrambled with a group common sequence based on the same group common RNTI as the common DCI part 420. In other exemplary embodiments, different scrambling sequences are generated on a per-UE basis based on the C-RNTI and then applied to different blocks corresponding to the UE associated with the block for the scrambling operation. Additionally, Figure 7 An exemplary field 730 of the UE-specific DCI part 430 for block K is shown. As described above, block K (and other blocks) do not need to have all of these fields.

[0072] Multiple methods can be used for the resource elements (Re) of the UE-specific DCI part 430 transmission. In some exemplary embodiments, the modulated symbols may be mapped in ascending frequency order starting from the first symbol of the resources allocated by the common DCI part 420 and starting from the lowest frequency. Then, the data symbols in the PDSCH may be appended at the end of the sequence of the UE-specific DCI part 430 first, and then the RE mapping may be performed. In other exemplary embodiments, the modulated symbols may be mapped in ascending symbol index order (e.g., time domain) starting from the first RE at the lowest frequency of the resources allocated by the common DCI part 420. In any method, these symbols should be rate-matched around the DMRS symbols.

[0073] Those skilled in the art will understand that the above-described exemplary embodiments can be implemented with any suitable software configuration or hardware configuration or a combination thereof. Exemplary hardware platforms for implementing the exemplary embodiments can include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, mobile devices with operating systems such as iOS, Android, etc. In other examples, the exemplary embodiments of the above methods can be embodied as a program including lines of code stored on a non-transitory computer-readable storage medium, which, when compiled, can be executed on a processor or a microprocessor.

[0074] Although this patent application describes various combinations of various aspects each having different features, those skilled in the art will understand that any feature of one aspect can be combined with the features of other aspects in any manner not precluded by the disclosure or with features that are not operationally or functionally inconsistent with the operation of the devices of the aspects disclosed in the present invention.

[0075] It is well known that the use of personally identifiable information should follow privacy policies and practices that are recognized as meeting or exceeding industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of inadvertent or unauthorized access or use, and the nature of the authorized use should be clearly explained to users.

[0076] It will be apparent to those skilled in the art that various modifications can be made to the present disclosure without departing from the essence or scope of the present disclosure. Accordingly, the present disclosure is intended to cover modifications and variations of the present disclosure provided that these modifications and variations are within the scope of the appended claims and their equivalents.

Claims

1. A base station for a wireless network, comprising: a transceiver configured to connect to a user equipment UE; and a processor communicatively coupled to the transceiver and configured to perform operations including: divide scheduling information for the UE into a common downlink control information DCI part and a UE-specific DCI part, wherein the common DCI part at least includes a frequency domain resource allocation FDRA field, and wherein the FDRA field includes: (i) a first bitmap including a resource block RB start index for the UE-specific DCI part based on at least one of an uplink or downlink bandwidth or a bandwidth allocated to the UE; and (ii) a second bitmap including a set of continuously allocated non-interleaved virtual resource blocks; encode the common DCI part for transmission on a first physical resource; encode the UE-specific DCI part for transmission on a second physical resource; transmit the encoded common DCI part on the first physical resource; and transmit the encoded UE-specific DCI part on the second physical resource.

2. The base station according to claim 1, wherein the common DCI part further includes one of a DCI format flag, a time domain resource allocation (TDRA) field, a UE-specific DCI part payload size indicator field, a UE-specific DCI part resource size indicator field, or a modulation and coding scheme (MCS) field.

3. The base station according to claim 2, wherein the FDRA field includes: (i) a first bitmap including a resource block RB start index for the UE-specific DCI part based on at least one of an uplink or downlink bandwidth or a narrow bandwidth allocated to the UE; and (ii) a second bitmap including a set of non-overlapping consecutive physical resource blocks PRB associated with the narrow bandwidth.

4. The base station according to claim 2, wherein the FDRA field includes: (i) a first bitmap including a resource block RB start index for the UE-specific DCI part based on at least one of an uplink or downlink bandwidth or a narrow bandwidth allocated to the UE; and (ii) a second bitmap including an identification of a resource set including the UE-specific DCI part.

5. The base station according to claim 2, wherein the FDRA field includes an offset relative to a start physical resource block PRB of the common DCI part.

6. The base station according to claim 2, wherein the UE-specific DCI part payload size includes a plurality of pre-configured sizes, and the UE-specific DCI part payload size indicator field includes an indication of one of the plurality of pre-configured sizes.

7. The base station according to claim 2, wherein the UE includes a plurality of UEs, and the scheduling information is for the plurality of UEs, and the UE-specific DCI part payload size indicator field includes an indication of whether there is a UE-specific DCI part payload for one of the plurality of UEs.

8. The base station according to claim 2, wherein the UE-specific DCI part resource size indicator field includes one of the following: (i) the aggregation level of the UE-specific DCI part, (ii) the number of consecutive symbols starting from the first symbol after the demodulation reference signal (DMRS) symbol on all resource blocks allocated by the FDRA field, or (iii) an offset value from a set of offset values.

9. The base station according to claim 1, wherein the UE includes a plurality of UEs, and the encoded UE-specific DCI part includes a plurality of blocks, and one of the following exists: (i) Each block is configured for a specific one of the plurality of UEs, or (ii) Each block is allocated for one of downlink scheduling or uplink scheduling for a single UE.

10. The base station according to claim 1, wherein the UE-specific DCI part includes one of a new data indicator (NDI) field, a redundancy version (RV) field, a HARQ process number (HPI) field, a UE-ID field, a UE-specific index field, a TPC command field, a downlink allocation index (DAI) field, a PUCCH resource indicator (PRI) field, or a PDSCH to HARQ feedback timing indicator field.

11. The base station according to claim 1, wherein the encoding of the common DCI part includes scrambling the common DCI part based on a group common radio network temporary identifier RNTI, and the encoding of the UE-specific DCI part includes one of the following: scrambling the UE-specific DCI part based on the group common RNTI, or scrambling the UE-specific DCI part on a per-UE basis based on a common RNTI (C-RNTI) applied to the blocks corresponding to the UE.

12. The base station according to claim 1, wherein the encoding of the common DCI part includes one of the following: appending the modulated symbols of the UE-specific part at the end of the sequence of the common DCI part and then performing resource element RE mapping, or mapping the modulated symbols in ascending order of symbol index starting from the first RE at the lowest frequency of the resources allocated by the common DCI part.

13. A device for wireless communication, the device includes a baseband processor configured to perform operations including the following: The scheduling information for the user equipment UE is divided into a common downlink control information DCI part and a UE-specific DCI part, where the common DCI part includes at least a frequency domain resource allocation FDRA field, and where the FDRA field includes: (i) a first bitmap, the first bitmap includes a resource block RB start index for the UE-specific DCI part based on at least one of uplink or downlink bandwidth or the bandwidth allocated to the UE; and (ii) a second bitmap, the second bitmap includes a set of continuously allocated non-interleaved virtual resource blocks; encoding the common DCI part for transmission on a first physical resource; encoding the UE-specific DCI part for transmission on a second physical resource; transmitting the encoded common DCI part on the first physical resource; and Transmit the encoded UE-specific DCI portion on the second physical resource.

14. The apparatus according to claim 13, wherein the common DCI portion further comprises one of a DCI format flag, a time domain resource allocation (TDRA) field, a UE-specific DCI portion payload size indicator field, a UE-specific DCI portion resource size indicator field, or a modulation and coding scheme (MCS) field.

15. The apparatus according to claim 14, wherein the FDRA field comprises: (i) A first bitmap that includes a resource block (RB) start index for the UE-specific DCI portion based on at least one of an uplink or downlink bandwidth or a narrow bandwidth allocated to the UE; and (ii) A second bitmap that includes a set of non-overlapping consecutive physical resource blocks (PRBs) associated with the narrow bandwidth.

16. The apparatus according to claim 14, wherein the FDRA field comprises: (i) A first bitmap that includes a resource block (RB) start index for the UE-specific DCI portion based on at least one of an uplink or downlink bandwidth or a narrow bandwidth allocated to the UE; and (ii) A second bitmap that includes an identification of a resource set that includes the UE-specific DCI portion.

17. The apparatus according to claim 14, wherein the FDRA field includes an offset relative to a start physical resource block (PRB) of the common DCI portion.

18. The apparatus according to claim 14, wherein the UE-specific DCI portion payload size includes a plurality of pre-configured sizes, and the UE-specific DCI portion payload size indicator field includes an indication of one of the plurality of pre-configured sizes.

19. The apparatus according to claim 14, wherein the UE includes a plurality of UEs, and the scheduling information is for the plurality of UEs, and the UE-specific DCI portion payload size indicator field includes an indication of whether there is a UE-specific DCI portion payload for one of the plurality of UEs.

20. The apparatus according to claim 14, wherein the UE-specific DCI portion resource size indicator field includes one of the following: (i) an aggregation level of the UE-specific DCI portion, (ii) a number of consecutive symbols starting from a first symbol after a demodulation reference signal (DMRS) symbol on all resource blocks allocated by the FDRA field, or (iii) an offset value from a set of offset values.

21. The apparatus according to claim 13, wherein the UE includes a plurality of UEs, and the encoded UE-specific DCI portion includes a plurality of blocks, and wherein one of the following exists: (i) Each block is configured for a specific one of the plurality of UEs, or (ii) Each block is allocated for one of downlink scheduling or uplink scheduling for a single UE.

22. The apparatus according to claim 13, wherein the UE-specific DCI part includes one of a new data indicator (NDI) field, a redundancy version (RV) field, a hybrid automatic repeat request (HARQ) process number (HPI) field, a UE-ID field, a UE-specific index field, a transmit power control (TPC) command field, a downlink allocation index (DAI) field, a physical uplink control channel (PUCCH) resource indicator (PRI) field, or a physical downlink shared channel (PDSCH) to HARQ feedback timing indicator field.

23. The apparatus according to claim 13, wherein the encoding of the common DCI part includes scrambling the common DCI part based on a group common radio network temporary identifier (RNTI), and the encoding of the UE-specific DCI part includes one of the following: scrambling the UE-specific DCI part based on the group common RNTI, or scrambling the UE-specific DCI part on a per-UE basis based on a common RNTI (C-RNTI) applied to the blocks corresponding to the UE.

24. The apparatus according to claim 13, wherein the encoding of the common DCI part includes one of the following: appending the modulated symbols of the UE-specific part at the end of the sequence of the common DCI part and then performing resource element (RE) mapping, or mapping the modulated symbols in an order of increasing symbol index starting from the first RE of the lowest frequency of the resources allocated by the common DCI part.

Images