PDCCH Transmission in the RACH Procedure for a Capacity Reduction Device

Abstract

The base station configures a physical downlink control channel (PDCCH) for transmission to one or more user equipments (UEs). The base station divides a component carrier (CC) bandwidth into a plurality of subbands, transmits a physical random access channel (PRACH) resource on at least one of the subbands, and transmits a type 1-PDCCH CSS (physical downlink control channel common search space) set on at least one of the subbands, where the type 1-PDCCH CSS set corresponds to the PRACH resource.

Description

Technical Field

[0001] This application generally relates to wireless communication systems, and more particularly to PDCCH transmissions in the RACH procedure for devices with reduced capabilities. 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, and the like. 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 base station in 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. The operations include: dividing a component carrier (CC) bandwidth into a plurality of sub-bands, transmitting a physical random access channel (PRACH) resource on at least one of the sub-bands, and transmitting a type 1-PDCCH CSS (Physical Downlink Control Channel Common Search Space) set on at least one of the sub-bands, wherein 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: dividing a component carrier (CC) bandwidth into a plurality of sub-bands, transmitting a physical random access channel (PRACH) resource on at least one of the sub-bands, and transmitting a type 1-PDCCH CSS (Physical Downlink Control Channel Common Search Space) set on at least one of the sub-bands, wherein the type 1-PDCCH CSS set corresponds to the PRACH resource.

[0005] Another exemplary embodiment relates to a method that includes: dividing a component carrier (CC) bandwidth into a plurality of sub-bands, transmitting a physical random access channel (PRACH) resource on at least one of the sub-bands, and transmitting a type 1-PDCCH CSS (Physical Downlink Control Channel Common Search Space) set on at least one of the sub-bands, wherein the type 1-PDCCH CSS set corresponds to the PRACH resource, wherein the PRACH resource and the type 1-PDCCH CSS set are transmitted on different sub-bands. Brief Description of the Drawings

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

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

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

[0009] Figure 4a and Figure 4b A component carrier (CC) bandwidth divided into sub - bands according to various exemplary embodiments is shown.

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

[0011] Figure 6 An example of a PRACH subgroup index according to various exemplary embodiments is shown.

[0012] Figure 7 An example corresponding to Figure 6 of a mapping table according to various exemplary embodiments is shown. Detailed Description

[0013] Exemplary embodiments may 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 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 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.

[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 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). 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 generally 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, than 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 generally have mobility similar to that of a mobile phone and operations related to the same types of applications that can be performed 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 a mobile phone.

[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 that are 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., a wearable device, a 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 with 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 up to 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 a 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 recovery 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 system information block (SIB1) for downlink control information (DCI) format with a cyclic redundancy check (CRC) scrambled by an RA-RNTI, a MsgB-RNTI, or a temporary cell RNTI (TC-RNTI) on a primary cell. This 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 (5G NR-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. Therefore, 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 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 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 5G NR-RAN 120 via the gNBs 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 5G NR-RAN 120.

[0026] The UE 110 can be connected to the 5G NR-RAN 120 via at least one of the next-generation node B (gNB) 120A and / or gNB 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 for 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 (e.g., 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, such as 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 or multiple separate applications. 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 touchscreen). 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 according to various exemplary embodiments is shown, in this example, the gNB 120A. The gNB 120A can represent a cell that serves as a primary cell (PCell) or a secondary cell (SCell), or a cell that 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 the 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, a data acquisition device, 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, the engine 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-described engine, as an application (e.g., a program) executed by the processor 305, is merely exemplary. The functions associated with the engine may also be represented as stand-alone integrated components of the gNB 120A or may be modular components coupled to the gNB 120A, e.g., integrated circuits with or without firmware. For example, an integrated circuit may 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 may be implemented in any of these or other configurations of the gNB.

[0037] The memory 310 may be a hardware component configured to store data related to operations performed by the UEs 110, 112. The I / O device 320 may be a hardware component or port that enables a user to interact with the gNB 120A. The transceiver 325 may be a hardware component configured to exchange data with the UE 110 and any other UEs 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.

[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 may 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), and 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. The 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 capability, 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 Physical Downlink Control Channel (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 with a Cyclic Redundancy Check (CRC) scrambled by a RA-RNTI, MsgB-RNTI, or Temporary Cell RNTI (TC-RNTI).

[0042] Figure 4a and Figure 4b illustrate component carrier (CC) bandwidths 400, 450 divided into sub-bands according to various exemplary embodiments. In Figure 4a and Figure 4b 's example, each of the CC bandwidths 400, 450 is divided into three sub-bands 405a, 405b, 410a, 410b, 415a, 415b and 455a, 455b, 460a, 460b, 465a, 465b. The left sub-bands of Figure 4a and Figure 4b marked with (a) can be considered as frequency resources for the physical random access channel (PRACH), and the right sub-bands of Figure 4a and Figure 4b marked 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 sub-bands. In some exemplary embodiments, the CC bandwidth can be divided into n SB sub-bands 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 sub-band, which can be a function of the DL CC bandwidth or be fixed by a standard (e.g., the minimum bandwidth (BW) of a RedCap device) or be implicitly indicated by the physical broadcast channel (PBCH) (e.g., equal to the size of CORESET0). 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 sub-band as the corresponding PRACH. Figure 4a illustrates an example of this type of exemplary embodiment. In Figure 4a 's example, the PRACH resources are illustrated in sub-bands 410a and 415a. Therefore, since 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 sub-bands 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 different sub-bands. Figure 4b An example of such an exemplary embodiment is shown. In Figure 4b the example, the PRACH resource is illustrated in sub-band 460a. However, the corresponding Type 1-PDCCH CSS set is illustrated in sub-bands 460b and 465b. When the PRACH and the Type 1-PDCCH CSS set are in different sub-bands, as in this example, the UE needs to determine which sub-band includes the Type 1-PDCCH CSS set because, unlike in Figure 4a the example, 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 in 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 the msg-FDM IE corresponding to the identification of a specific search space (e.g., SearchSpaceID). The RACH-ConfigGeneric IE may also include a field identifying the sub-band identification of the corresponding DL sub-band 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 sub-band. The sub-band 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 sub-band identification field will be included in the RACH-ConfigGeneric IE.

[0049] In some exemplary embodiments, instead of broadcasting the sub-band ID for the RedCap device in SIB1, the legacy controlResourceSetId is 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 other than the initial DL BWP, and the BWP with the switched Type 1-PDCCH CSS monitoring becomes the active BWP for the serving cell.

[0050] Figure 5 shows an example of sub - band switching when a type 1 - PDCCH CSS set is in a different sub - band from the PRACH according to various exemplary embodiments. In this example, it is considered that the CC bandwidth 500 is divided into two sub - bands 510 and 520. As Figure 5 can be seen, the sub - band 510 includes PRACH resources 511 - 514, and corresponding type 1 - PDCCH CSS sets 521 and 523 exist in the sub - bands 510 and 520 respectively. For example, PRACH resources 511 and 512 correspond to the type 1 - PDCCH CSS set 521 in the sub - band 510, and PRACH resources 513 and 514 correspond to the type 1 - PDCCH CSS set 523 in the sub - band 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 the PRACH resources 513 and 514 and the type 1 - PDCCH CSS set 523, the UE will monitor the 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 shown by the handover gap 530 in. This time gap can be greater than or equal to a predetermined threshold to allow the UE to monitor a different BWP for type 1 - PDCCH CSS transmission. The predetermined threshold can be based on, for example, the sub - carrier spacing. If the monitored bandwidth part does not change compared to the PRACH transmission, for example, the UE is monitoring the type 1 - PDCCH CSS set 521 in the sub - band 510 corresponding to the PRACH resources 511 and 512, then no bandwidth switching 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 described 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+sub -

[0054] group - id x K

[0055] wherein, s_id is the index of the first OFDM symbol of the PRACH occasion (0 ≤ s_id < 14);

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

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

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

[0059] sub-group-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.

[0060] As can be seen from the above equation, by introducing sub-group-id, 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. This allows for flexibility and increases the probability of scheduling type 1-PDCCH transmissions compared to Rel-15 / Rel-16 systems.

[0061] Figure 6 Shows an example of the PRACH subgroup index 600 according to various exemplary embodiments. In Figure 6 the example, it can be considered that there are G PRACH subgroups, which have indices from 0, …, G - 1 (or as Figure 6 shown, 0, …, 7). 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.

[0062] It can also be considered to provide a mapping table for the UE to associate subgroups in the intermediate group with type 1-PDCCH CSS subband indices. Figure 7 Shows according to various exemplary embodiments the Figure 6An example of the mapping table 700 corresponding to the example. Therefore, 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.

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

[0064] 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 functionally or logically inconsistent with the operation of the devices of the aspects disclosed in the present invention or the said functions.

[0065] 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.

[0066] 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 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: dividing a component carrier CC bandwidth into a plurality of subbands; transmitting a physical random access channel PRACH resource on at least one of the subbands; and transmitting a type 1 - physical downlink control channel common search space PDCCH CSS set on at least one of the subbands, wherein the type 1 - PDCCH CSS set corresponds to the PRACH resource, wherein the PRACH resource and the type 1 - PDCCH CSS set are transmitted on different subbands, and wherein a predefined switching gap is defined between the transmission of the PRACH resource and the type 1 - PDCCH CSS set, wherein the predefined switching gap is based on the subcarrier spacing and is greater than or equal to a threshold.

2. The base station according to claim 1, wherein at least one of the subbands on which the type 1 - PDCCH CSS set is transmitted is identified in a system information block SIB corresponding to the PRACH resource.

3. The base station according to claim 1, wherein at least one of the subbands on which the type 1 - PDCCH CSS set is transmitted is identified using a controlResourceSetId.

4. The base station 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.

5. The base station according to claim 4, wherein the different PRACH resources include an indexed subgroup corresponding to at least one of the subbands for the type 1 - PDCCH CSS set.

6. One or more processors configured to perform operations including the following: dividing a component carrier CC bandwidth into a plurality of subbands; transmitting a physical random access channel PRACH resource on at least one of the subbands; and transmitting a type 1 - physical downlink control channel common search space PDCCH CSS set on at least one of the subbands, wherein the type 1 - PDCCH CSS set corresponds to the PRACH resource, wherein the PRACH resource and the type 1 - PDCCH CSS set are transmitted on different subbands, and wherein a predefined switching gap is defined between the transmission of the PRACH resource and the type 1 - PDCCH CSS set, wherein the predefined switching gap is based on the subcarrier spacing.

7. The one or more processors according to claim 6, wherein at least one of the subbands on which the type 1 - PDCCH CSS set is transmitted is identified in a system information block SIB corresponding to the PRACH resource.

8. One or more processors according to claim 6, wherein at least one of the subbands on which the type 1-PDCCH CSS set is transmitted is identified by controlResourceSetId.

9. One or more processors according to claim 6, wherein different PRACH resources in the same PRACH occasion are associated with different random access radio network temporary identifiers RA-RNTIs.

10. One or more processors according to claim 9, wherein the different PRACH resources include an indexed subgroup corresponding to at least one of the subbands for the type 1-PDCCH CSS set.

11. A method for wireless communication, comprising: Dividing a component carrier CC bandwidth into a plurality of subbands; Transmitting physical random access channel PRACH resources on at least one of the subbands; And Transmitting a type 1-physical downlink control channel common search space PDCCH CSS set on at least one of the subbands, wherein the type 1-PDCCH CSS set corresponds to the PRACH resources, wherein the PRACH resources and the type 1-PDCCH CSS set are transmitted on different subbands, wherein a switching gap is predefined between transmitting the PRACH resources and the type 1-PDCCH CSS set, and wherein the predefined switching gap is based on a subcarrier spacing.

12. The method according to claim 11, wherein at least one of the subbands on which the type 1-PDCCH CSS set is transmitted is identified in a system information block SIB corresponding to the PRACH resources.

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

Images