Data scheduling for reduced-capability ues

Abstract

A user equipment (UE) receives scheduling information from a base station of a wireless network. The UE monitors a first physical resource to receive a common downlink control information (DCI) portion of scheduling information for the UE, decodes the common DCI portion to determine information for a UE-specific DCI portion, which is transmitted by the base station on a second physical resource, monitors the second physical resource for the UE-specific DCI portion based at least on the information from the common DCI, and decodes the UE-specific DCI portion based at least on the information from the common DCI.

Description

Background Technology

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

[0002] Some exemplary embodiments relate to a user equipment (UE) having: a transceiver configured to connect to a base station of a network; and a processor communicatively coupled to the transceiver and configured to perform operations. These operations include: monitoring a first physical resource to receive a common downlink control information (DCI) portion of scheduling information for the UE; decoding the common DCI portion to determine information for a UE-specific DCI portion transmitted by the base station on a second physical resource; monitoring the second physical resource for the UE-specific DCI portion based at least on the information from the common DCI; and decoding the UE-specific DCI portion based at least on the information from the common DCI.

[0003] Other exemplary embodiments relate to a baseband processor configured to perform operations. These operations include: monitoring a first physical resource to receive a common downlink control information (DCI) portion of scheduling information for the UE; decoding the common DCI portion to determine information for a UE-specific DCI portion transmitted by the base station on a second physical resource; monitoring the second physical resource for the UE-specific DCI portion based at least on the information from the common DCI; and decoding the UE-specific DCI portion based at least on the information from the common DCI. Attached Figure Description

[0004] Figure 1 Exemplary network arrangements according to various exemplary implementations are shown.

[0005] Figure 2 Exemplary UEs according to various exemplary implementations are shown.

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

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

[0008] Figure 5 An exemplary FRDA field is shown for the public DCI portion according to various exemplary implementations.

[0009] Figure 6 Exemplary illustrations are shown of a common DCI portion that provides a set of resource configurations for Frequency Domain Resource Allocation (FDRA) according to various exemplary embodiments.

[0010] Figure 7 An exemplary UE-specific DCI portion is shown according to various exemplary implementations. Detailed Implementation

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

[0012] Exemplary implementations are described with reference to networks including 5G New Radio (NR) radio access technology (RAT). However, the principles described herein can be used to implement exemplary implementations in other types of networks.

[0013] Exemplary embodiments are described with reference to the UE. However, the use of the UE is for illustrative purposes only. The exemplary embodiments can be used with any electronic component capable of establishing a connection to a network and configured with hardware, software, and / or firmware for exchanging information and data with that network. Therefore, 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 5G NR networks. Before describing exemplary implementations, several examples of RedCap UEs and their characteristics will be described. In the first example, devices in an industrial environment, such as temperature or humidity sensors, can be connected industrial devices. However, such devices are stationary, not latency-critical, and their capabilities and hardware are not particularly complex. These devices typically do not require low-latency data exchange provided by Ultra-Reliable Low-Latency Communication (URLLC) or IIoT. These devices are also expected to operate in the field for many years with little or no maintenance (including battery replacement). Therefore, power-saving operation can be critical for these types of devices.

[0015] Another example of a RedCap-type device with capabilities different from other UEs is a surveillance device (e.g., a camera). These devices are similar to the devices in the first example because they are typically stationary and do not have strict latency requirements. However, they can differ from the first example because these devices can be connected to a permanent power source (although not required) and can have much higher upload data rates than many other UEs, for example, due to the video upload feeds they provide.

[0016] Another example of a RedCap-type device with capabilities distinct from many other UEs is the wearable device. Unlike the examples mentioned above, wearable devices typically offer mobility similar to mobile phones and the same types of operations that can be performed on mobile phones. However, due to their smaller form factor resulting in smaller batteries, 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 devices with 5G capabilities, but rather are provided as examples of the varying capabilities of different UEs connected to a 5G NR wireless network at any given time. Devices considered 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, surveillance device, etc.). In another example, a RedCap device can be defined by the device's capabilities / features (e.g., battery life, processing power, latency requirements, etc.). The definition of a UE's eligibility as a RedCap UE can be set by standards (e.g., 3GPP standards) or determined by individual network providers.

[0018] As mentioned above, one consideration for RedCap devices might be more stringent power conservation than standard UEs to reduce battery usage and extend battery life. An exemplary way to reduce power consumption could be to reduce monitoring of the Physical Downlink Control Channel (PDCCH) by the RedCap device. This reduced monitoring of the PDCCH could include a smaller number of blind decoding and control channel element (CCE) limits. However, there may be problems associated with reducing the number of blind decoding and CCE limits. For example, this could lead to an increased probability of PDCCH blocking, which could result in increased latency. This problem could be more severe for RedCap devices, which typically use a larger aggregation level / CCE due to the reduced number of Rx antennas and bandwidth.

[0019] According to some exemplary implementations, downlink (DL) and / or uplink (UL) scheduling information can be divided into two parts: a common DCI part and a UE-specific DCI part. These different parts of a single schedule can 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 according to various exemplary embodiments is illustrated. 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 a mobile phone, tablet, desktop computer, smartphone, phablet, embedded device, wearable device, Internet of Things (IoT) device, etc. It should also be understood that a practical 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] UE 110 can be configured to communicate with one or more networks. In the example of network configuration 100, the networks with which UE 110 can wirelessly communicate are 5G New Radio (NR) Radio Access Network (5G NR-RAN) 120, LTE Radio Access Network (LTE-RAN) 122, and Wireless Local Area Network (WLAN) 124. However, it should be understood that UE 110 can also communicate with other types of networks, and UE 110 can also communicate with networks via wired connections. Therefore, UE 110 may include a 5G NR chipset communicating with 5G NR-RAN 120, an LTE chipset communicating with LTE-RAN 122, and an ISM chipset communicating with WLAN 124.

[0022] 5G NR-RAN 120 and LTE-RAN 122 may be portions of a cellular network that can 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, macrocell base stations, microcell base stations, small cell base stations, femtocell base stations, etc.) configured to send and receive traffic from UEs equipped with appropriate cellular chipsets. WLAN 124 may include any type of wireless local area network (WiFi, hotspot, IEEE 802.11x network, etc.).

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

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

[0025] In addition to networks 120, 122, and 124, network deployment 100 also includes a cellular core network 130, an Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network service backbone 160. The cellular core network 130 (e.g., NR's 5GC) can be viewed as an interconnected collection of components that manage the operation 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] IMS 150 can generally be described as an architecture for delivering multimedia services to UE 110 using the IP protocol. IMS 150 can communicate with cellular core network 130 and Internet 140 to provide multimedia services to UE 110. Network service backbone 160 communicates directly or indirectly with Internet 140 and cellular core network 130. Network service backbone 160 can generally be described as a set of components (e.g., servers, network storage deployments, etc.) that implement a set of services that can be used to extend the functionality of UE 110 to communicate with various networks.

[0027] Figure 2 An exemplary UE 110 according to various exemplary embodiments is shown. Reference will be made to... Figure 1The network layout 100 is used to describe UE 110. For the purposes of this discussion, UE 110 may be considered a red-capped UE. However, it should be noted that UE 110 can represent any electronic device and may include processor 205, memory layout 210, display device 215, input / output (I / O) device 220, transceiver 225, and other components 230. Other components 230 may include, for example, audio input devices, audio output devices, batteries providing a limited power source, data acquisition devices, ports for electrically connecting UE 110 to other electronic devices, one or more antenna panels, etc. For example, UE 110 may be coupled to industrial equipment via one or more ports.

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

[0029] The engine described above, as an application (e.g., a program) executed by processor 205, is merely exemplary. The functionality associated with the engine may also be represented as a separate, integrated component of UE 110, or as a modular component coupled to UE 110, such as an integrated circuit with or without firmware. For example, the integrated circuit may include an input circuitry for receiving signals and a processing circuitry for processing signals and other information. The engine may also be embodied as a single application or multiple separate applications. Furthermore, in some UEs, the functionality described for processor 205 is distributed among two or more processors, such as a baseband processor and an application processor. Exemplary implementations can be implemented according to any of these or other configurations of the UE.

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

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

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

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

[0034] The engine described above, as an application (e.g., a program) executed by processor 305, is merely exemplary. The functionality associated with the engine may also be represented as a separate integrated component of gNB 120A, or as a modular component coupled to gNB 120A, such as an integrated circuit with or without firmware. For example, the integrated circuit may include an input circuitry for receiving signals and a processing circuitry for processing signals and other information. Furthermore, in some gNBs, the functionality described for processor 305 is split among multiple processors (e.g., a baseband processor, an application processor, etc.). Exemplary aspects may be implemented according to any of these or other configurations of the gNB.

[0035] Memory 310 may be a hardware component configured to store data related to operations performed by UEs 110 and 112. I / O device 320 may be a hardware component or port enabling a user to interact with gNB 120A. Transceiver 325 may be a hardware component configured to exchange data with UE 110 and any other UE in system 100. Transceiver 325 may operate on a variety of different frequencies or channels (e.g., a set of consecutive frequencies). Therefore, 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 can be divided into two parts: a common DCI part and a UE-specific DCI part. These different parts of a single schedule can be transmitted on different physical channels / signals. For example, the common DCI part can be transmitted on the PDCCH, and the UE-specific DCI part can be mapped on the Physical Downlink Control Channel (PDSCH). In some exemplary embodiments, frequency domain resource allocation (FDRA) for the PDSCH including the UE-specific DCI part can be transmitted to the UE within the common DCI part.

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

[0038] In 410, the gNB 120A has scheduling information bits for UE 110. As will be described in more detail below, scheduling information bits 410 may include scheduling information for multiple UEs. The gNB 120A may then divide scheduling information bits 410 into a common DCI portion 420 and a UE-specific DCI portion 430. The gNB 120A may then encode each of these portions individually. For example, the common DCI portion 420 may be encoded by the following steps: Cyclic Redundancy Check (CRC) calculation 440, Applied Radio Network Temporary Identifier (RNTI) mask 450, additional CRC 460, channel coding 470, rate matching 480, and mapping the encoded common DCI portion 490 to the PDCCH. Similarly, the UE-specific DCI portion 430 can be encoded by the following steps: Cyclic Redundancy Check (CRC) calculation 445, Application Radio Network Temporary Identifier (RNTI) mask 455, additional CRC 465, channel coding 475, rate matching 485, and mapping the encoded common DCI portion 495 to the PDSCH.

[0039] In some exemplary implementations, a common RNTI can be used to mask the CRC of a common DCI portion and a UE-specific DCI portion, enabling the UE to identify the corresponding DCI portion. For example, RNTI "X" for 450 and RNTI "Y" for 455 can be the same. For example, an RNTI can be a group of common RNTIs assigned by gNB 120A to more than one UE. Consider the example of a RedCap device as an industrial sensor. Multiple industrial sensors can be assigned the same RNTI by gNB 120A. Therefore, UE 110 can be assigned the same RNTI as multiple other UEs.

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

[0041] In some exemplary implementations, the lengths of CRC 440 and 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 onto the PDSCH resource. A masked CRC bit can be appended to the associated portion of the bits using a CRC append operation.

[0042] The following provides a description of exemplary information (or fields) that may be included in the public DCI portion 420 of the scheduling information. It should be understood that the following fields are merely exemplary. The public DCI portion 420 may include all described fields, a subset of described fields, or additional fields not specifically described herein. In a first example, the public DCI portion 420 may include a DCI format flag that can be used to distinguish DCI formats having the same size. In a second example, the public DCI portion 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 public DCI portion 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 public DCI portion 420 may include a UE-specific DCI portion payload size indicator field that can be used to transmit the payload size of the UE-specific DCI portion 430 in signal form. In a fifth example, the public DCI portion 420 may include a UE-specific DCI portion resource size indicator field that can be used to transmit the resource size of the UE-specific DCI portion 430 in signal form. In the sixth example, the public DCI section 420 may include a modulation and coding scheme (MCS) field. Some examples of these examples will be described in more detail below.

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

[0044] Equation (1):

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

[0046] With [log2(N RedCap (N RedCapThe bitmap with resource allocation type 1 in subfield 520 of bit +1) / 2)] can be used to indicate to the scheduled UE a set of contiguously allocated non-interleaved virtual resource blocks within a Redcap subband (Redcap-SB).

[0047] In other exemplary embodiments, subfield 510 may include a bitmap corresponding to a first expression of the following equation (2), and subfield 520 may include a bitmap corresponding to a 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. NB It can be a non-overlapping contiguous physical resource block (PRB) in the frequency domain. The total NB in ​​the RedCap bandwidth can be given by the following equation: In some exemplary implementations, N NB The value of can be configured on a per-UE basis by system information blocks or dedicated radio resource control (RRC) signaling. In other exemplary embodiments, N NB The value can be provided by standards (e.g., 3GPP standards) based on numeric principles.

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

[0051] Equation (3):

[0052] The first expression is the same as the first expression in equation (2). In this example, a set of resource configurations can be provided to one or more UEs by the gNB 120A. This information includes the starting RB and the number of consecutive RBs. The [log2K] is used by the FDRA subfield 520 section to dynamically indicate one of the configured resource sets, where K is the number of RB resource sets. See below for reference. Figure 6 Examples of exemplary implementations of this type are provided.

[0053] Figure 6 An exemplary illustration 600 is shown, illustrating a common DCI portion that provides a set of resource configurations for Frequency Domain Resource Allocation (FDRA) according to various exemplary embodiments. Figure 6 In the example, consider K=4, for example, there are 4 RB resource sets. Figure 6In this context, these four RB resource sets are shown as resource sets 0-610, 1-620, 2-630, and 4-640. It is also possible to consider that the FDRA subfield 520 is 2 bits, allowing the field to identify any one of resource sets 610-640 (e.g., 00, 01, 10, 11, each corresponding to one of the four resource sets).

[0054] Therefore, in this example, the public DCI section 605 may include bitmaps corresponding to the two expressions in equation (3). The first expression... The number of start RBs and consecutive RBs for the UE-specific DCI section 650 can be identified. The second expression [log2K] identifies the resource set including the UE-specific DCI section 630. In this example, [log2K] is set to identify 0,0 for resource set 0-610. Therefore, when UE 110 decodes the common DCI section 605, UE 110 will understand that the UE-specific DCI section 650 is associated with resource set 0-610, and according to the first expression, identify the number of start RBs and consecutive RBs for the UE-specific DCI section 650, such as... Figure 6 As shown.

[0055] In an additional exemplary implementation, the frequency domain location of a UE-specific DCI section 430 can be transmitted in signal form using an offset relative to the start PRB of the common DCI section 420. For example, a set of offset values ​​can be configured first by a higher layer, and then one of these offset values ​​can be dynamically transmitted in signal form using the FDRA field.

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

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

[0058] In some exemplary implementations, the UE-specific DCI portion payload size indicator field can be specified by a standard (e.g., a 3GPP standard) UE-specific DCI portion payload size indicator field or configured by RRC signaling. The UE-specific DCI portion payload size indicator field can then be used to dynamically send one of the candidate sizes in signaled form.

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

[0060] As described above, the common DCI section 420 may also include a UE-specific DCI section resource size indicator field, which can be used to transmit the resource size of the UE-specific DCI section 430 in signal form. This information can be used to reduce the amount of blind decoding performed by the UE 110, for example, 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 portion 430 are sent in signal form using an aggregation level. The aggregation level can be converted into the number of six RBs on multiple consecutive symbols or multiple resource elements (REs) where the UE-specific DCI portion 430 resides, which can be received and decoded by the RedCap device.

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

[0063] In a further exemplary implementation, the UE-specific DCI portion resource size field is transmitted in signal form from one of a set of offset values ​​that can be configured by RRC signaling. Values. UE 110 may determine the value based on, for example, the UE-specific DCI portion payload size (as described above), the number of CRC bits, and / or The value determines the number of modulation and coding symbols / REs for a specific DCI portion of the UE.

[0064] As described above, the common DCI section 420 may also include an MCS field. In some exemplary embodiments, a value may be transmitted in signal form and applied collectively to the UE-specific DCI section 430 and the PDSCH / PUSCH transmissions of DL-SCH and UL-SCH.

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

[0066] The UE-specific DCI portion 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 the DL and UL scheduling of a single UE.

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

[0068] The following fields are available for DL ​​and / or UL scheduling. In the case of UL scheduling, the following fields can be determined by the UE. In the first example, the UE-specific DCI section 430 may include the MCS field. In some exemplary embodiments, when the MCS field is also present in the common DCI section 420, incremental MCS or MCS update information relative to the MCS indicated by the common DCI section 430 with fewer bits may be included in that field. In other exemplary embodiments, an MCS field may be shared across all blocks rather than within each block to reduce signaling overhead.

[0069] In the second example, the UE-specific DCI portion 430 may include a New Data Indicator (NDI) field. In the third example, the UE-specific DCI portion 430 may include a Redundancy Version (RV) field. In the fourth example, the UE-specific DCI portion 430 may include a HARQ Process Count (HPI) field. In the fifth example, the UE-specific DCI portion 430 may include a UE-ID or a UE-specific index field determined by the UE-ID. The UE-index may be configured by RRC signaling or determined based on a hard-coded equation according to the UE-ID. In the sixth example, the UE-specific DCI portion 430 may include a TPC command field for the scheduled PUCCH / PUSCH.

[0070] The following fields can be used for PDSCH scheduling. In the first example, the UE-specific DCI section 430 may include a Downlink Allocation Index (DAI) field. In the second example, the UE-specific DCI section 430 may include a PUCCH Resource Indicator (PRI) field. In the third example, the UE-specific DCI section 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 section 420.

[0071] Figure 7 An exemplary UE-specific DCI portion 430 according to various exemplary embodiments is shown. The exemplary UE-specific DCI portion 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 portion 430 has a shared MCS field 715 and can be applied to all transport blocks (TBs) 720 scheduled by this DCI. TBs 720 for different UEs may be scrambled with a UE-specific sequence prior to 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 portion 430 bits are scrambled by a group common sequence based on the same group common RNTI as the common DCI portion 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 used for scrambling operations. Additionally, Figure 7 An example field 730 of the UE-specific DCI section 430 for block K is shown. As mentioned above, block K (and other blocks) do not need to have all of these fields.

[0072] Several methods can be used for resource elements (Re) transmitted for a UE-specific DCI section 430. In some exemplary embodiments, modulated symbols may be mapped in ascending frequency order, starting with the first symbol of the resource allocated by the common DCI section 420 and proceeding from the lowest frequency. Data symbols from the PDSCH may then be appended to the end of the sequence for the UE-specific DCI section 430, after which RE mapping can be performed. In other exemplary embodiments, modulated symbols may be mapped from the first RE, starting with the lowest frequency of the resource allocated by the common DCI section 420, in ascending symbol index order (e.g., time domain). In any method, these symbols should be rate-matched around DMRS symbols.

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

[0074] Although this patent application describes various combinations of aspects, each with different features, those skilled in the art will understand that any feature of one aspect can be combined with features of other aspects or features that are not functionally or logically inconsistent with the operation or function of the device of the aspect disclosed in this invention in any manner not disclosed to be denied.

[0075] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of 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 this disclosure without departing from its spirit or scope. Therefore, this disclosure is intended to cover all modifications and variations thereof, provided that such modifications and variations are within the scope of the appended claims and their equivalents.

Claims

1. A user equipment (UE), comprising: a transceiver configured to connect to a base station of a network; and a processor communicatively coupled to the transceiver and configured to perform operations comprising: monitoring a first physical resource to receive a common downlink control information (DCI) portion of scheduling information for the UE; decoding the common DCI portion to determine information for a UE-specific DCI portion, the UE-specific DCI portion being transmitted by the base station on a second physical resource, the common DCI portion including a frequency domain resource allocation (FDRA) field for the second physical resource that includes the UE-specific DCI portion, wherein the FDRA field includes 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 bandwidth allocated to the UE, or the first bitmap 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; monitoring the second physical resource for the UE-specific DCI portion based at least on the information from the common DCI; and decoding the UE-specific DCI portion based at least on the information from the common DCI.

2. The UE of claim 1, wherein the common DCI portion further includes 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. (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 bandwidth allocated to the UE; and (ii) a second bitmap that includes a set of contiguously allocated non-interleaved virtual resource blocks.

3. The UE of claim 1, 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 contiguous physical resource blocks (PRBs) associated with the narrow bandwidth.

4. The UE of claim 1, 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 set of resources that includes the UE-specific DCI portion.

5. The UE of claim 1, wherein the FDRA field comprises: ​ 6. The UE of claim 2, wherein a UE-specific DCI portion payload size comprises a plurality of preconfigured sizes, and the UE-specific DCI portion payload size indicator field comprises an indication of one of the plurality of preconfigured sizes.

7. The UE of claim 2, wherein the UE-specific DCI portion payload size indicator field comprises an indication of whether a UE-specific DCI portion payload is present for the UE.

8. The UE of claim 2, wherein the UE-specific DCI portion resource size indicator field comprises one of (i) an aggregation level of the UE-specific DCI portion, (ii) a number of contiguous symbols 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.

9. The UE of claim 1, wherein the UE-specific DCI portion comprises a plurality of blocks, and wherein one of (i) each block is configured for a particular one of a plurality of UEs or (ii) each block is allocated for one of downlink scheduling or uplink scheduling for a single UE.

10. The UE of claim 1, wherein the UE-specific DCI portion comprises 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 assignment index (DAI) field, a PUCCH resource indicator (PRI) field, or a PDSCH-to-HARQ feedback timing indicator field.

11. The UE of claim 1, wherein the common DCI portion is scrambled with a group common radio network temporary identifier (RNTI) and the UE-specific DCI portion is scrambled based on the group common RNTI or based on a common RNTI (C-RNTI).

12. An electronic device for a user equipment (UE), comprising: a baseband processor configured to perform operations comprising: monitoring a first physical resource to receive a common downlink control information (DCI) portion of scheduling information for the UE; decoding the common DCI portion to determine information for a UE-specific DCI portion, the UE-specific DCI portion being transmitted by the base station on a second physical resource, the common DCI portion including a frequency domain resource allocation (FDRA) field for the second physical resource including the UE-specific DCI portion, wherein the FDRA field includes a first bitmap including 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 bandwidth allocated to the UE, or the first bitmap 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; monitoring the second physical resource for the UE-specific DCI portion based at least on the information from the common DCI; and decoding the UE-specific DCI portion based at least on the information from the common DCI.

13. The electronic device of claim 12, wherein the common DCI portion further includes 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. (i) a first bitmap including 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 bandwidth allocated to the UE; and (ii) a second bitmap including a set of contiguous allocated non-interleaved virtual resource blocks.

14. The electronic device of claim 12, wherein the FDRA field comprises: (i) a first bitmap including 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 including a set of non-overlapping contiguous physical resource blocks (PRBs) associated with the narrow bandwidth.

15. The electronic device of claim 12, wherein the FDRA field comprises: (i) a first bitmap including 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 including an identification of a resource set, the resource set including the UE-specific DCI portion.

16. The electronic device of claim 12, wherein the FDRA field comprises:

17. The electronic device of claim 13, wherein UE-specific DCI portion payload size includes a plurality of preconfigured sizes, and the UE-specific DCI portion payload size indicator field includes an indication of one of the plurality of preconfigured sizes.

18. The electronic device of claim 13, wherein the UE-specific DCI portion payload size indicator field includes an indication of whether a UE-specific DCI portion payload exists for the UE. ​ 19. The electronic device of claim 13, wherein the UE-specific DCI portion resource size indicator field comprises one of: (i) an aggregation level of the UE-specific DCI portion, (ii) a number of contiguous symbols 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.

20. The electronic device of claim 12, wherein the UE-specific DCI portion comprises a plurality of blocks, and wherein one of: (i) each block is configured for a particular one of a plurality of UEs, or (ii) each block is allocated for one of downlink scheduling or uplink scheduling for a single UE.

21. The electronic device of claim 12, wherein the UE-specific DCI portion comprises 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 assignment index (DAI) field, a PUCCH resource indicator (PRI) field, or a PDSCH-to-HARQ feedback timing indicator field.

22. The electronic device of claim 12, wherein the common DCI portion is scrambled with a group common radio network temporary identifier (RNTI), and the UE-specific DCI portion is scrambled based on the group common RNTI or based on a common RNTI (C-RNTI).

Images