Monitoring PDCCH Transmissions During the RACH Procedure

Abstract

A user equipment (UE) that monitors a physical downlink control channel (PDCCH) during a physical random access channel (PRACH) procedure. The UE receives a physical random access channel (PRACH) resource on a first subband of a component carrier (CC), where the CC is divided into a plurality of subbands; and receives a set of type 1-PDCCH CSS (physical downlink control channel common search space) on a second subband of the CC, where the set of type 1-PDCCH CSS corresponds to the PRACH resource.

Description

Technical Field

[0001] The present application generally relates to wireless communication systems and, in particular, to monitoring PDCCH transmissions during the RACH procedure. Background Art

[0002] 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

[0003] Some exemplary embodiments relate to a user equipment (UE) having: a transceiver configured to connect to a base station; and a processor communicatively coupled to the transceiver and configured to perform operations. The operations include: receiving a Physical Random Access Channel (PRACH) resource on a first subband of a Component Carrier (CC), where the CC is divided into a plurality of subbands; and receiving a Type 1-PDCCH CSS (Physical Downlink Control Channel Common Search Space) set on a second subband of the CC, where the Type 1-PDCCH CSS set corresponds to the PRACH resource.

[0004] Other exemplary embodiments relate to one or more processors configured to perform operations. The operations include: receiving a Physical Random Access Channel (PRACH) resource on a first subband of a Component Carrier (CC), where the CC is divided into a plurality of subbands; and receiving a Type 1-PDCCH CSS (Physical Downlink Control Channel Common Search Space) set on a second subband of the CC, where the Type 1-PDCCH CSS set corresponds to the PRACH resource.

[0005] Another exemplary embodiment relates to a method that includes: receiving a Physical Random Access Channel (PRACH) resource on a first subband of a Component Carrier (CC), where the CC is divided into a plurality of subbands; and receiving a Type 1-PDCCH CSS (Physical Downlink Control Channel Common Search Space) set on a second subband of the CC, where the Type 1-PDCCH CSS set corresponds to the PRACH resource, where the first subband and the second subband are different subbands. Brief Description of the Drawings

[0006] Figure 1 An exemplary network arrangement is shown in accordance with various exemplary embodiments.

[0007] Figure 2 FIG. 2 shows an exemplary UE according to various exemplary embodiments.

[0008] Figure 3 FIG. 6 shows an exemplary base station configured to establish a connection with a user equipment according to various exemplary embodiments.

[0009] FIGS. 4A and 4B show a component carrier (CC) bandwidth divided into subbands according to various exemplary embodiments.

[0010] Figure 5 FIG. 13 shows an example of subband switching when a type 1-PDCCH CSS (Physical Downlink Control Channel Common Search Space) set is in a different subband from a Physical Random Access Channel (PRACH) according to various exemplary embodiments.

[0011] Figure 6 FIG. 17 shows an example of a PRACH subgroup index according to various exemplary embodiments.

[0012] Figure 7 FIG. 21 shows an example of a mapping table corresponding to an example of Figure 6 according to various exemplary embodiments. DETAILED DESCRIPTION

[0013] Exemplary embodiments may be further understood with reference to the following description and the related drawings, in which like elements are denoted by like reference numerals. The exemplary embodiments describe PDCCH monitoring by a RedCap UE. For example, a RedCap UE may monitor PDCCH candidates in a type 1-PDCCH CSS set configured by a random access search space for a downlink control information (DCI) format.

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

[0015] 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 capable of establishing a connection with a network and 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.

[0016] As described above, there are various types of UEs, each of which has different capabilities to connect to a 5G NR network. Before describing 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 typically 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). Therefore, power-saving operations may be critical for these types of devices.

[0017] 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 in that they are typically fixed and do not have strict latency requirements. However, they may differ from the first example in that these devices can be connected to a permanent power source (although not necessarily) and may have a much higher upload data rate, for example, due to the video upload feed they are providing, compared to many other UEs.

[0018] 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 a smaller form factor leading to a smaller battery, these devices have more stringent power-saving requirements than mobile phones.

[0019] 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, surveillance 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., a 3GPP standard) or can be decided by an individual network provider.

[0020] In the current standard version, random access channel (RACH) response (RAR) messages for different UEs are multiplexed into a single jointly coded transport block scheduled by a random access radio network temporary identifier (RA-RNTI) in a type 1-PDCCH CSS (physical downlink control channel common search space) set. Due to the reduced bandwidth and the reduced number of Rx antennas, this may cause problems for RedCap devices. For example, the maximum number of multiplexed RAR messages can be as high as six to meet the 1% target block error rate (BLER). Due to the reduced number of Rx antennas on the UE side, the number of multiplexed RARs will be further reduced. Additionally, there may be a large number of RedCap devices deployed in the network. If a large number of RedCap UEs initiate the random access procedure, the RAR capacity may become limited and the initial access delay may increase due to RAR transmission blocking. Therefore, a solution needs to be provided for RedCap devices, especially for coverage restoration scenarios, to achieve a low RAR blocking probability.

[0021] According to some exemplary embodiments, a RedCap UE may monitor PDCCH candidates in a type 1-PDCCH CSS set configured by a random access search space (e.g., ra-SearchSpace) in a system information block (SIB1) for downlink control information (DCI) format using a cyclic redundancy check (CRC) scrambled by an RA-RNTI, a MsgB-RNTI, or a temporary cell RNTI (TC-RNTI) on a primary cell. Exemplary monitoring will be described in more detail below.

[0022] Figure 1 An exemplary network arrangement 100 according to various exemplary embodiments is shown. 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, 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.

[0023] The UE 110 can be configured to communicate with one or more networks. In an example of network configuration 100, the networks with which the UE 110 can communicate wirelessly are the 5G New Radio (NR) Radio Access Network (5GNR-RAN) 120, the Long-Term Evolution (LTE) Radio Access Network (LTE-RAN) 122, and the Wireless Local Area Network (WLAN) 124. However, it should be understood that the UE 110 can also communicate with other types of networks, and the UE 110 can also communicate with networks via a wired connection. Thus, the UE 110 can 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.

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

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

[0026] The UE 110 can be connected to the 5G NR-RAN 120 via at least one of the next-generation node Bs (gNBs) 120A and / or 120B. Exemplary embodiments can be applied to any suitable number of gNBs. For example, the UE can be connected to and exchange data with multiple gNBs simultaneously in a multi-cell carrier aggregation (CA) configuration. Exemplary details of CA operation will be described below. The UE 110 can also be connected to the LTE-RAN 122 via any one or both of the eNBs 122A, 122B, or to any other type of RAN, as described above.

[0027] In addition to networks 120, 122, and 124, 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 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.

[0028] IMS 150 can generally be described as an architecture for delivering multimedia services to UE 110 using IP protocols. 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 of UE 110 to communicate with various networks.

[0029] Figure 2 An exemplary UE 110 is shown in accordance with various exemplary embodiments. UE 110 will be described with reference to Figure 1 network arrangement 100. For the purposes of this discussion, UE 110 can be considered a Reduced Capability (RedCap) UE. However, it should be noted that UE 110 can represent any electronic device and can 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. Other components 230 can 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 UE 110 to other electronic devices, one or more antenna panels, etc. For example, UE 110 can be coupled to an industrial device via one or more ports.

[0030] Processor 205 can be configured to execute multiple engines of UE 110. For example, the engines can include a PDCCH CSS set monitoring engine 235. The PDCCH CSS set monitoring engine 235 can perform various operations related to monitoring the PDCCH, which will be described in more detail below.

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

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

[0033] Figure 3 An exemplary network cell, in this example gNB 120A, is shown according to various exemplary embodiments. The gNB 120A can represent a cell that serves as a primary cell (PCell) or a secondary cell (SCell), or provides services in an independent configuration with the UE 110. The gNB 120A can represent any access node belonging to the 5G NR network that the UE 110 can use to establish connections and manage network operations. Figure 3 The shown gNB 120A can also represent gNB 120B.

[0034] The gNB 120A can 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 can include, for example, a power supply, data acquisition devices, ports for electrically connecting the gNB 120A to other electronic devices, etc.

[0035] The processor 305 can be configured to execute multiple engines of the gNB 120A. For example, these engines can include a RedCap RAR engine 335 for sending RAR messages to RedCap devices. Examples of sending RAR messages to RedCap devices will be described in more detail below.

[0036] The above-mentioned engine, as an application (e.g., a program) executed by the processor 305, is merely exemplary. The functions associated with the engine can also be represented as standalone integrated components of the gNB 120A, or can be modular components coupled to the gNB 120A, e.g., integrated circuits with or without firmware. For example, an integrated circuit can include input circuitry for receiving signals and processing circuitry for processing 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 can be implemented in any of these or other configurations of the gNB.

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

[0038] Exemplary embodiments are described with reference to carrier aggregation performed at a 5G NR network and including a SCell activation mechanism. However, the use of a 5G NR network is merely exemplary. The exemplary embodiments can be modified and / or used with any network that supports carrier aggregation (CA) or substantially similar functionality where multiple component carriers (CCs) are used.

[0039] CA may include a primary component carrier (PCC) and at least one secondary component carrier (SCC), where the PCC and the at least one SCC correspond to the same radio access technology (RAT) used to facilitate communication with the network. Additionally, in 5G NR, in the case of establishing connections with both 5G NR RAT and LTE RAT, Eutra NR dual connectivity (ENDC) may be enabled and exemplary embodiments may be used. The PCC may be partially used for control information such as scheduling requests, uplink grants, downlink grants, etc. CA functionality enables the PCC and the at least one SCC to combine bandwidths to exchange data with the UE. Thus, with CA, the PCC may provide a first portion of the total bandwidth for the data to be exchanged, while the SCC may provide a second portion of the total bandwidth. The combination of the PCC and a single SCC may be characterized as a CC combination including two carriers. To further increase the total available bandwidth of the data to be exchanged with the UE, additional SCCs may be incorporated. For example, for CA used in LTE, there may be CC combinations including but not limited to two carriers, four carriers, five carriers, eight carriers, ten carriers, thirty-two carriers, etc. For CA used in 5G NR, there may be CC combinations including but not limited to two carriers, five carriers, ten carriers, twelve carriers, sixteen carriers, twenty carriers, twenty-five carriers, thirty-two carriers, sixty-four carriers, etc.

[0040] An exemplary system may be configured with CA functionality and include a PCell that provides the PCC and at least one SCell that correspondingly provides the SCC. The PCell may control how to exchange data with the UE, such as how to use the PCC and any SCCs in the CA functionality. When the UE has CA capabilities, the CA functionality enables the PCell and additional SCells to combine bandwidths to exchange data with the UE, thereby increasing the rate of data exchange. Thus, with CA, the PCell may provide a first portion of the total bandwidth for the data to be exchanged, while the SCell may provide a second portion of the total bandwidth. When using additional SCells, the PCell may provide a first portion of the total bandwidth, the first SCell may provide a second portion of the total bandwidth, the second SCell may provide a third portion of the total bandwidth, and so on.

[0041] As described above, in some exemplary embodiments, a RedCap UE may monitor a component carrier (CC) of a primary cell (PCell) for a type 1-PDCCH CSS set configured by a random access search space (e.g., ra-SearchSpace) in a system information block (SIB1) for downlink control information (DCI) formats using a cyclic redundancy check (CRC) scrambled by a RA-RNTI, MsgB-RNTI, or temporary cell RNTI (TC-RNTI).

[0042] Figures 4A and 4B illustrate component carrier (CC) bandwidths 400, 450 divided into subbands according to various exemplary embodiments. In the examples of Figures 4A and 4B, each of the CC bandwidths 400, 450 is divided into three subbands 405a, 405b, 410a, 410b, 415a, 415b, and 455a, 455b, 460a, 460b, 465a, 465b. The left subbands of Figures 4A and 4B labeled with (a) can be considered as frequency resources for the physical random access channel (PRACH), and the right subbands of Figures 4A and 4B labeled with (b) can be considered as frequency resources for type 1-PDCCH CSS sets.

[0043] It should be understood that the CC bandwidth can be divided into any number of subbands. In some exemplary embodiments, the CC bandwidth can be divided into n SB subbands based on the following formula:

[0044]

[0045] where represents the downlink (DL) bandwidth configuration expressed in resource blocks (RBs), and is the number of RBs per subband, which can be a function of the DL CC bandwidth or implicitly indicated by a standard fixed value (e.g., the minimum bandwidth (BW) of a RedCap device) or by the physical broadcast channel (PBCH) (e.g., equal to the size of CORESET 0). The n SB >0 can be numbered in ascending order starting from the lowest frequency.

[0046] In some exemplary embodiments, for a RedCap device, the type 1-PDCCH CSS set associated with a PRACH resource can be transmitted in the same subband as the corresponding PRACH. Figure 4A shows an example of this type of exemplary embodiment. In the example of Figure 4A, the PRACH resources are illustrated in subbands 410a and 415a. Therefore, because there is a one-to-one correspondence between the PRACH resources and the type 1-PDCCH CSS sets, the corresponding type 1-PDCCH CSS sets are illustrated in subbands 410b and 415b.

[0047] In other exemplary embodiments, for a RedCap device, a type 1-PDCCH CSS set associated with one PRACH resource may be transmitted in another subband. FIG. 4B shows an example of such an exemplary embodiment. In the example of FIG. 4B, the PRACH resource is illustrated in subband 460a. However, the corresponding type 1-PDCCH CSS set is illustrated in subbands 460b and 465b. When the PRACH and the type 1-PDCCH CSS set are in different subbands, as in this example, the UE needs to determine which subband includes the type 1-PDCCH CSS set because, unlike the example of FIG. 4A, there is not a one-to-one correspondence between the PRACH resource and the type 1-PDCCH CSS set.

[0048] In some exemplary embodiments, the associated type 1-PDCCH CSS may be explicitly signaled in an information element (IE) associated with the RACH (e.g., the RACH-ConfigGeneric IE of SIB1) and may depend on the value of the msg-FDM IE. Those skilled in the art will understand that the msg-FDM IE specifies how many ROs are allocated in the frequency domain (at the same position in the time domain). For example, the RACH-ConfigGeneric IE may include a msg-FDM IE corresponding to the identification of a particular search space (e.g., SearchSpaceID). The RACH-ConfigGeneric IE may also include a field identifying the subband identification of the corresponding DL subband that includes the type 1-PDCCH CSS set. This field may include a series of bits (e.g., a bitmap string), where each bit corresponds to a subband. The subband identification field may be conditionally set based on whether the network supports the RedCap function. For example, if the network supports the RedCap function, the subband identification field will be included in the RACH-ConfigGeneric IE.

[0049] In some exemplary embodiments, instead of broadcasting the subband ID for the RedCap device in SIB1, the traditional controlResourceSetId may be utilized by allowing the associated CORESET for the type 1-PDCCH CSS set to be outside the initial DL BWP. In these exemplary embodiments, the RedCap device may monitor the type 1-PDCCH CSS for the corresponding RNTI in another BWP outside the initial DL BWP, and the switched BWP with type 1-PDCCH CSS monitoring becomes the active BWP for the serving cell.

[0050] Figure 5Shows an example of subband switching when a type 1-PDCCH CSS set is in a different subband from the PRACH according to various exemplary embodiments. In this example, it can be considered that the CC bandwidth 500 is divided into two subbands 510 and 520. As Figure 5 can be seen, subband 510 includes PRACH resources 511-514, and corresponding type 1-PDCCH CSS sets 521 and 523 exist in subbands 510 and 520 respectively. For example, PRACH resources 511 and 512 correspond to type 1-PDCCH CSS set 521 in subband 510, and PRACH resources 513 and 514 correspond to type 1-PDCCH CSS set 523 in subband 520.

[0051] In some exemplary embodiments, when the corresponding type 1-PDCCH CSS set is in a different DL BWP from the selected PRACH resource, as shown by PRACH resources 513 and 514 and type 1-PDCCH CSS set 523, the UE will monitor type 1-PDCCH CSS set 523, for which there is a time gap between the last symbol of the PRACH transmission and the first symbol of the associated type 1-PDCCH CSS transmission. This time gap can be referred to as as Figure 5 the handover gap 530 shown in. This time gap can be greater than or equal to a predetermined threshold to allow the UE to monitor different BWPs for type 1-PDCCH CSS transmission. The predetermined threshold can be based on, for example, the subcarrier spacing. If the monitored bandwidth part does not change compared to the PRACH transmission, for example, the UE is monitoring type 1-PDCCH CSS set 521 in subband 510 corresponding to PRACH resources 511 and 512, then no bandwidth handover will occur, and the handover gap can be set to 0.

[0052] In some exemplary embodiments, different PRACH resources in the same PRACH occasion in the frequency domain can be associated with different RA-RNTIs. As mentioned above, considering the large PRACH load requirements of RedCap devices, this can increase the type 1-PDCCH capacity. The RA-RNTI associated with the PRACH occasion in which the random access preamble is transmitted can be calculated as follows:

[0053] RA-RNTI = 1 + s_id + 14xt_id + 14x80xf_id + 14x80x8xul_carrier_id + subgroup id x K where: s_id is the index of the first OFDM symbol of the PRACH occasion (0 ≤ s_id < 14);

[0054] t_id is the index of the first time slot of the PRACH occasion in the system frame (0 ≤ t_id < 80);

[0055] f_id is the index of the PRACH occasion in the frequency domain (0 ≤ f_id < 8);

[0056] ul_carrier_id is the UL carrier used for random access preamble transmission (0 represents the NUL carrier, 1 represents the SUL); and

[0057] The subgroup id is determined based at least on the number of subgroups associated with type 1-PDCCH CSS monitoring in the corresponding subband within the PRACH occasion.

[0058] As can be seen from the above equation, by introducing the subgroup id, the PRACH resources in different subgroups can be associated with different RA-RNTIs, thus allowing more than one type 1-PDCCH CSS transmission to be scheduled in a single subband. Compared with the Rel-15 / Rel-16 system, this allows flexibility and increases the probability of scheduling type 1-PDCCH transmissions.

[0059] Figure 6 An example of the PRACH subgroup index 600 according to various exemplary embodiments is shown. In Figure 6 the example, it can be considered that there are G PRACH subgroups, which have indices from 0,…,G - 1 (or 0,…,7 as Figure 6 shown). Each subgroup includes 8 PRACH resources, as shown below the subgroup. For example, subgroup 0 has PRACH resources 0 - 7. Subgroups 0 - 7 can also be further grouped into intermediate groups consisting of two consecutive subgroups. For example, subgroups 0 and 1 are included in intermediate group 610, subgroups 2 and 3 are included in intermediate group 620, subgroups 4 and 5 are included in intermediate group 630, and subgroups 6 and 7 are included in intermediate group 640. In each intermediate group, two RA-RNTIs can be generated for type 1-PDCCH CSS monitoring in a single subband associated with these two PRACH subgroups to reduce latency.

[0060] It can also be considered to provide a mapping table for the UE to associate the subgroups in the intermediate group with the type 1-PDCCH CSS subband index. Figure 7 An example according to various exemplary embodiments of Figure 6An example of the mapping table 700 corresponding to the example. Thus, by referring to Table 700, it can be seen that group 610 corresponds to the type 1-PDCCH CSS set in sub-band 650, group 620 corresponds to the type 1-PDCCH CSS set in sub-band 660, group 630 corresponds to the type 1-PDCCH CSS set in sub-band 670, and group 640 corresponds to the type 1-PDCCH CSS set in sub-band 680.

[0061] Those skilled in the art will understand that the above-described exemplary embodiments can be implemented in any suitable software configuration or hardware configuration or a combination thereof. An exemplary hardware platform for implementing the exemplary embodiments may include, for example, an Intel x86-based platform with a compatible operating system, Windows OS, Mac platform and MAC OS, and 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 can be executed on a processor or microprocessor when compiled.

[0062] 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 way not negated by the disclosure or features that are not inconsistent in function or logic with the operation of the devices of the aspects disclosed in the present invention or the said functions.

[0063] 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 the user.

[0064] 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. Therefore, 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 user equipment (UE), comprising: a transceiver configured to connect to a base station; and a processor communicatively coupled to the transceiver and configured to perform operations including: receiving a Physical Random Access Channel (PRACH) resource on a first sub-band of a component carrier (CC), where the CC is divided into a plurality of sub-bands; and receiving a Type 1 - Physical Downlink Control Channel Common Search Space Set, i.e., a Type 1 - PDCCH CSS set, on a second sub-band of the CC, where the Type 1 - PDCCH CSS set corresponds to the PRACH resource, where a switching gap is predefined between the PRACH resource and the Type 1 - PDCCH CSS set, and where the predefined switching gap is based on the subcarrier spacing and is greater than or equal to a threshold.

2. The UE according to claim 1, wherein the operations further include: receiving a System Information Block (SIB) identifying the second sub-band corresponding to the PRACH resource.

3. The UE according to claim 1, wherein the operations further include: receiving a controlResourceSetId identifying the second sub-band corresponding to the PRACH resource.

4. The UE according to claim 3, wherein the operations further include: monitoring the second sub-band for a corresponding Radio Network Temporary Identifier (RNTI) associated with the PRACH resource.

5. The UE according to claim 1, wherein different PRACH resources in the same PRACH occasion are associated with different Random Access Radio Network Temporary Identifiers (RA-RNTIs).

6. The UE according to claim 5, wherein the different PRACH resources include an indexed subgroup corresponding to at least one sub-band for the Type 1 - PDCCH CSS set.

7. One or more processors configured to perform operations including: receiving a Physical Random Access Channel (PRACH) resource on a first sub-band of a component carrier (CC), where the CC is divided into a plurality of sub-bands; and receiving a Type 1 - Physical Downlink Control Channel Common Search Space Set, i.e., a Type 1 - PDCCH CSS set, on a second sub-band of the CC, where the Type 1 - PDCCH CSS set corresponds to the PRACH resource, where a switching gap is predefined between the PRACH resource and the Type 1 - PDCCH CSS set, and where the predefined switching gap is based on the subcarrier spacing and is greater than or equal to a threshold.

8. The one or more processors according to claim 7, wherein the operations further include: receiving a System Information Block (SIB) identifying the second sub-band corresponding to the PRACH resource.

9. The one or more processors according to claim 7, wherein the operations further include: receiving a controlResourceSetId identifying the second sub-band corresponding to the PRACH resource.

10. The one or more processors according to claim 9, wherein the operations further Comprising: Monitoring the second sub - band for a corresponding radio network temporary identifier (RNTI) corresponding to the PRACH resource.

11. The one or more processors according to claim 7, wherein different PRACH resources in the same PRACH occasion are associated with different random access radio network temporary identifiers (RA - RNTIs).

12. The one or more processors according to claim 11, wherein the different PRACH resources include an indexed subgroup corresponding to at least one sub - band for the type 1 - PDCCH CSS set.

13. A method for wireless communication, Comprising: Receiving a physical random access channel (PRACH) resource on a first sub - band of a component carrier (CC), wherein the CC is divided into a plurality of sub - bands; And Receiving a type 1 - physical downlink control channel common search space set, i.e., a type 1 - PDCCH CSS set, on a second sub - band of the CC, wherein the type 1 - PDCCH CSS set corresponds to the PRACH resource, wherein the first sub - band and the second sub - band are different sub - bands and a switching gap is predefined between the PRACH resource and the type 1 - PDCCH CSS set, wherein the predefined switching gap is based on the sub - carrier spacing and is greater than or equal to a threshold.

14. The method according to claim 13, further Comprising: Receiving one of a system information block (SIB) or a controlResourceSetId corresponding to the PRACH resource that identifies the second sub - band.

15. The method according to claim 14, further Comprising: Monitoring the second sub - band for a corresponding radio network temporary identifier (RNTI) corresponding to the PRACH resource.

16. The method according to claim 13, wherein different PRACH resources in the same PRACH occasion are associated with different random access radio network temporary identifiers (RA - RNTIs).

Images