Control resource set 0 for capacity-reduced NR (New Radio) devices

Abstract

The present disclosure provides a communications apparatus and a communications method for implementing a control resource set 0 (CORESET#0) for a reduced-capability (RedCap) new radio (NR) device. The communications apparatus includes a receiver and a circuit for receiving a physical downlink control channel (PDCCH) on control resource set 0 (CORESET#0), in which time-frequency resources are defined based on a bandwidth configuration of the reduced-capability user equipment (RedCap UE), and for receiving a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) scheduled based on CORESET#0. The circuit for determining, from the PDCCH on CORESET#0, control information and parameters for reading SIB1 for initial access, handover, or beam failure recovery.

Description

[Technical Field]

[0001] The following disclosure relates to a communication device and communication method that implements Control Resource Set Zero (CORESET#0) for Reduced Capability (RedCap) devices, and more particularly for RedCap NR (New Radio) devices. [Background technology]

[0002] New Radio (NR) is a new radio air interface developed by 3GPP (3rd Generation Partnership Project) for fifth-generation (5G) mobile communication systems. 5G is expected to offer high flexibility, scalability, and efficiency, supporting a wide range of use cases, including enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC).

[0003] One of the key objectives of 5G is to enable connected industries. 5G connectivity can act as a catalyst for the next wave of industrial transformation and digitalization, bringing about increased flexibility, improved productivity and efficiency, reduced maintenance costs, and enhanced operational safety. Devices in such an environment include, for example, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, and actuators. Connecting these sensors and actuators to the 5G network is highly desirable.

[0004] Furthermore, 5G connectivity can also act as a catalyst for the next wave of smart city innovation. For example, wearables such as smartwatches and smart rings, e-health devices, medical monitoring equipment, and small devices such as capacity-reducing (RedCap) devices will benefit from improved 5G connectivity. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] 3GPP TS 38.300 v15.6.0 [Non-Patent Document 2] 3GPP TS 38.211 v15.6.0 [Non-Patent Document 3] ITU-R M.2083 [Non-Patent Document 4] TR 38.913 [Non-Patent Document 5] TS 23.501 v16.1.0 [Non-Patent Document 6] RP-193238 [Non-Patent Document 7] TS 38.213 [Overview of the project] [Problems that the invention aims to solve]

[0006] However, CORESET#0 for RedCap devices has not been discussed to date.

[0007] Therefore, there is a need for a communication device and communication method that can solve the aforementioned problems. Furthermore, by considering the following detailed description and the attached claims together with the attached drawings and the section on the background art of this disclosure, other desirable features and characteristics will become apparent. [Means for solving the problem]

[0008] One non-limiting and exemplary embodiment facilitates the implementation of CORESET#0 for RedCap devices in 5G NR-based communications.

[0009] In one embodiment, the technology disclosed herein provides a communication device. For example, the communication device may be a subscriber UE, which may be a standard (non-RedCap, or release 15 / 16 / 17, or later) UE, a RedCap UE, or other similar type of UE. This communication device includes a receiver that, during operation, receives a physical downlink control channel (PDCCH) on Control Resource Set 0 (CORESET#0), where time and frequency resources are defined based on the bandwidth settings of reduced capability user equipment (RedCap UE), and also receives a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) scheduled based on CORESET#0; and a circuit that, during operation, determines control information and parameters from the PDCCH on CORESET#0 for reading SIB1, message 2 (Msg2) PDSCH, and message 4 (Msg4) PDSCH for initial access, handover, or beam fault recovery.

[0010] In another embodiment, the technology disclosed herein provides a communication device. For example, the communication device may be a base station or a gNodeB (gNB), the base station or gNodeB (gNB) comprising: a circuit that, in operation, sets up a control resource set 0 (CORESET#0) in which time and frequency resources are defined based on a minimum bandwidth setting associated with one or more UEs in a set of standard (non-RedCap) UEs and RedCap UEs; generates a physical downlink control channel (PDCCH) on CORESET#0; and schedules a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) based on CORESET#0; and a transmitter that, in operation, transmits the PDCCH, SIB1 PDSCH, Msg2 PDSCH, and Msg4 PDSCH on CORESET#0 to the communication device.

[0011] In another embodiment, the technology disclosed herein provides a communication method. This communication method includes the steps of: receiving a CORESET#0 in which time and frequency resources are defined based on a minimum bandwidth setting associated with one or more UEs in a set of standard (non-RedCap) UEs and RedCap UEs; receiving a System Information Block Type 1 (SIB1) Physical Downlink Shared Channel (PDSCH) scheduled based on the CORESET#0; and determining control information and parameters from the PDCCH on the CORESET#0 for reading the SIB1, Msg2 PDSCH, and Msg4 PDSCH for initial access, handover, or beam fault recovery.

[0012] It should be noted that general or specific embodiments can be implemented as systems, methods, integrated circuits, computer programs, storage media, or any selective combination thereof.

[0013] Further benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. These benefits and / or advantages may be obtained individually by various embodiments and features of the specification and drawings, and it is not necessary to provide all of these features in order to obtain one or more of such benefits and / or advantages.

Brief Description of Drawings

[0014] Those having ordinary skill in the art will gain a deep understanding of and readily appreciate the embodiments of the present disclosure by reading the following description, which is merely an example, with reference to the drawings. [Figure 1] An exemplary architecture of a 3GPP NR system is shown. [Figure 2] A schematic diagram showing the separation of functions between NG-RAN and 5GC. [Figure 3] A sequence diagram of an RRC connection establishment / reconfiguration procedure. [Figure 4] A schematic diagram showing usage scenarios of extended mobile broadband (eMBB), massive machine type communication (mMTC), and ultra-reliable and low-latency communication (URLLC). [Figure 5] A block diagram showing the architecture of an exemplary 5G system in a non-roaming scenario. [Figure 6] An example of the bandwidth comparison between the Rel-15 CORESET (CORESET#0) of index 0 and the RedCap UE is shown. [Figure 7] An example of the bandwidth comparison between the Rel-15 CORESET (CORESET#0) of index 0 and the CORESET#0 for the RedCap UE according to various embodiments is shown. [Figure 8A]Table of a subset of Rel-15 CORESET#0 for a RedCap UE when the bandwidth of the RedCap UE according to Embodiment 1 is 5 MHz and the subcarrier spacing ({synchronization signal block, physical downlink control channel} subcarrier spacing ({synchronization signal block (SSB), PDCCH} SCS)) is {15, 15} kHz. [Figure 8B] Table of a subset of Rel-15 CORESET#0 for a RedCap UE when the bandwidth of the RedCap UE according to Embodiment 1 is 10 MHz and the {SSB, PDCCH} SCS is {15, 15} kHz. [Figure 9] Schematic diagram illustrating the transmission of a subset of Rel-15 CORESET#0 according to Embodiment 2. [Figure 10] An example of equal division of Rel-15 CORESET#0 according to Embodiment 2. [Figure 11] An example of unequal division of Rel-15 CORESET#0 according to Embodiment 2. [Figure 12] An example of equal division of Rel-15 CORESET#0 according to a variation of Embodiment 2. [Figure 13] An example of unequal division of Rel-15 CORESET#0 according to a variation of Embodiment 2. [Figure 14] An example of the transmission of Rel-15 CORESET#0 and its (one or more) subsets according to Embodiment 3. [Figure 15] An example of the transmission of Rel-15 CORESET#0 and its (one or more) subsets according to a variation of Embodiment 3. [Figure 16] An example of the transmission rule of how a RedCap UE receives Rel-15 CORESET#0 according to a variation of Embodiment 3. [Figure 17] An example of Rel-15 CORESET#0 and the CORESET#0 of a RedCap UE according to Embodiment 4. [Figure 18] Embodiment 5A shows an example of Rel-15 CORESET#0 signaling targeting both standard UEs and RedCap UEs. [Figure 19] This example table shows a set of resource blocks and slot symbols for the CORESET in the Type0-PDCCH search space set for standard UEs and RedCap UEs, where the {search space / physical broadcast channel block, PDCCH}SCS ({SS / PBCH block, PDCCH}SCS) is {15, 15}kHz for a minimum channel bandwidth of 5MHz or 10MHz according to Embodiment 5A. [Figure 20] This example shows a separate table containing the set of resource blocks and slot symbols for the CORESET in the Type0-PDCCH search space set for RedCap UE, when the {SS / PBCH block, PDCCH}SCS) is {15,15}kHz for a minimum channel bandwidth of 5MHz according to Embodiment 5A. [Figure 21] This example table shows a set of resource blocks and slot symbols for the CORESET in the Type0-PDCCH search space set for standard UEs and RedCap UEs, when the {SS / PBCH block, PDCCH}SCS) is {15, 15}kHz for a minimum channel bandwidth of 5MHz or 10MHz according to Embodiment 5A. [Figure 22] Embodiment 5B illustrates an example of reinterpreting the monitoring opportunity for Rel-15 CORESET#0 for standard UEs and RedCap UEs. [Figure 23] Embodiment 5B shows a table of parameters for reinterpreting PDCCH monitoring opportunities in the case of Type0-PDCCH CSS set-SSB and CORESET multiplexing pattern 1 and frequency range 1 (FR1). [Figure 24] Figure 23 shows an example of how to read the table in detail. [Figure 25]Embodiment 5B illustrates the different monitoring opportunities for Re-15 CORESET#0 for a standard UE and CORESET#0 for a RedCap UE. [Figure 26] The table shows the iterations of the CORESET in the Type0-PDCCH search space set for RedCap UE, as well as the sets of resource blocks and slot symbols, when {SS / PBCH block, PDCCH}SCS is {15, 15}kHz for a minimum channel bandwidth of 5MHz or 10MHz according to Embodiment 5C. [Figure 27] The table shows the parameters for repetition and PDCCH monitoring opportunities in the case of Type0-PDCCH CSS set-SS / PBCH block and CORESET multiplexing patterns 1 and FR1 according to Embodiment 5C. [Figure 28] This shows flowcharts of communication methods for implementing CORESET#0 for RedCap UE using various embodiments. [Figure 29] This document provides schematic examples of communication devices that can be used to implement CORESET#0 for RedCap UE in various embodiments.

[0015] Those skilled in the art will understand that the elements in the figures are illustrated in a concise and clear manner and are not necessarily drawn to the correct scale. To facilitate a deeper understanding of embodiments of the present invention, for example, the dimensions of some elements in the illustrations, block diagrams, or flowcharts may be exaggerated compared to other elements. [Modes for carrying out the invention]

[0016] Some embodiments of this disclosure will be described only as examples, with reference to the drawings. Similar reference numerals and letters in the drawings refer to similar or equivalent elements.

[0017] <5G NR System Architecture and Protocol Stack> 3GPP is working on the next release of fifth-generation cellular technology (simply called 5G), which will include the development of a new radio access technology (NR) that will operate at frequencies up to 100 GHz. The first version of the 5G standard will be completed at the end of 2017, which will allow for testing and commercial deployment of smartphones compliant with the 5G NR standard.

[0018] In particular, the overall system architecture envisions an NG-RAN (Next Generation Radio Access Network) with gNBs, which terminate the NG Radio Access User Plane (SDAP / PDCP / RLC / MAC / PHY) and Control Plane (RRC) protocols toward the UE. The gNBs are interconnected with each other via Xn interfaces. Furthermore, the gNBs are connected to the NGC (Next Generation Core) via Next Generation (NG) interfaces, more specifically to the AMF (Access and Mobility Management Function) (e.g., a specific core entity that performs the AMF) via the NG-C interface, and to the UPF (User Plane Function) (e.g., a specific core entity that performs the UPF) via the NG-U interface. Figure 1 shows the NG-RAN architecture (see Section 4 of Non-Patent Literature 1).

[0019] The user plane protocol stack in NR (see, for example, section 4.4.1 of Non-Patent Literature 1) includes the PDCP (Paper Data Convergence Protocol, see section 6.4 of Non-Patent Literature 1) sublayer, the RLC (Radio Link Control, see section 6.3 of Non-Patent Literature 1) sublayer, and the MAC (Medium Access Control, see section 6.2 of Non-Patent Literature 1) sublayer, which are terminated at the gNB on the network side. In addition, a new access layer (AS) sublayer (SDAP: Service Data Adaptation Protocol) is introduced on top of PDCP (see, for example, section 6.5 of Non-Patent Literature 1). A control plane protocol stack is also defined in NR (see, for example, section 4.4.2 of Non-Patent Literature 1). An overview of the Layer 2 functions is described in section 6 of Non-Patent Literature 1. The functions of the PDCP sublayer, RLC sublayer, and MAC sublayer are described in sections 6.4, 6.3, and 6.2 of Non-Patent Document 1, respectively. The function of the RRC layer is described in section 7 of Non-Patent Document 1.

[0020] The Media Access Control (MAC) layer handles, for example, logical channel multiplexing and scheduling and scheduling-related functions (including processing various numerologies).

[0021] The physical layer (PHY) is responsible for tasks such as encoding, PHY HARQ processing, modulation, multi-antenna processing, and mapping signals to appropriate physical time-frequency resources. Furthermore, the physical layer (PHY) handles the mapping of transport channels to physical channels. The physical layer (PHY) serves the MAC layer in the form of transport channels. A physical channel corresponds to a set of time-frequency resources used for transmitting a particular transport channel, and each transport channel is mapped to a corresponding physical channel. For example, physical channels for uplinks include PRACH (Physical Random Access Channel), PUSCH (Physical Uplink Shared Channel), and PUCCH (Physical Uplink Control Channel), while for downlinks, there are PDSCH (Physical Downlink Shared Channel), PDCCH (Physical Downlink Control Channel), and PBCH (Physical Broadcast Channel).

[0022] NR use cases / deployment scenarios include Enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and Massive Machine-Type Communications (mMTC), and these services have diverse requirements regarding data rate, latency, and coverage. For example, eMBB is expected to support peak data rates of the order of three times that provided by IMT-Advanced (20 Gbps downlink and 10 Gbps uplink) and user-perceived data rates. URLLC, on the other hand, has even more stringent requirements, including extremely low latency (user plane latency of 0.5 ms for both uplink and downlink) and high reliability (1-10 ms within 1 ms). -5) is imposed. Furthermore, in mMTC, a high connection density (1km in urban environments) is required. 2 Preferably, a capacity of 1,000,000 devices per unit, wide coverage in harsh environments, and extremely long-life batteries (15 years) to reduce device costs may be required.

[0023] Therefore, OFDM numerology suitable for one use case (e.g., subcarrier interval, OFDM symbol duration, cyclic prefix (CP) duration, number of symbols per scheduling interval) may not work well for another use case. For example, low-latency services may prefer shorter symbol durations (and thus larger subcarrier intervals) and / or fewer symbols per scheduling interval (also known as TTI) than mMTC services. Furthermore, in placement scenarios with large channel delay spreads, longer cyclic prefix (CP) durations may be preferred than in scenarios with smaller delay spreads. To maintain a similar level of cyclic prefix (CP) overhead, the subcarrier interval should be optimized according to the delay spread. NR may support two or more values ​​for the subcarrier interval. Currently, subcarrier intervals of 15kHz, 30kHz, 60kHz, ... are being considered. Symbol duration T u The subcarrier spacing Δf is given by the equation Δf = 1 / T u Therefore, it is directly related. As with LTE systems, the term “resource element” can be used to represent the smallest resource unit consisting of one subcarrier for the length of one OFDM / SC-FDMA symbol.

[0024] In the new 5G NR wireless system, resource grids for subcarriers and OFDM symbols are defined for each numerology and carrier, both in the uplink and downlink. Each element within the resource grid is called a resource element and is identified based on its frequency index in the frequency domain and its symbol position in the time domain (see Non-Patent Literature 2).

[0025] (Control signal) In this disclosure, the downlink control signals (information) related to this disclosure may be signals (information) transmitted via the PDCCH of the physical layer, or signals (information) transmitted via the MAC control element (CE) or RRC of the upper layer. The downlink control signals may be predefined signals (information).

[0026] The uplink control signals (information) related to this disclosure may be signals (information) transmitted via the physical layer PUCCH, or signals (information) transmitted via the upper layer MAC CE or RRC. Furthermore, the uplink control signals may be predefined signals (information). The uplink control signals may be replaced with uplink control information (UCI), first-stage sidelink control information (SCI), or second-stage SCI.

[0027] (base station) In this disclosure, a base station may be, for example, a Transmission Reception Point (TRP), a cluster head, an access point, a Remote Radio Head (RRH), an eNodeB (eNB), a gNodeB (gNB), a base station (BS), a Base Transceiver Station (BTS), a base unit, or a gateway. Furthermore, in side-link communication, a terminal may be used instead of a base station. A base station may also be a relay device that relays communication between a higher-level node and a terminal. A base station may also be a roadside unit.

[0028] (Uplink / Downlink / Sidelink) This disclosure can be applied to uplinks, downlinks, and sidelinks.

[0029] This disclosure can be applied, for example, to uplink channels such as PUSCH, PUCCH, and PRACH, downlink channels such as PDSCH, PDCCH, and PBCH, and sidelink channels such as Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Control Channel (PSCCH), and Physical Sidelink Broadcast Channel (PSBCH).

[0030] PDCCH, PDSCH, PUSCH, and PUCCH are examples of downlink control channels, downlink data channels, uplink data channels, and uplink control channels, respectively. PSCCH and PSSCH are examples of sidelink control channels and sidelink data channels, respectively. PBCH and PSBCH are examples of broadcast channels, respectively, and PRACH is an example of a random access channel.

[0031] (Data channel / Control channel) This disclosure can be applied to either data channels or control channels. The channels in this disclosure can be replaced with data channels including PDSCH, PUSCH, and PSSCH, and / or control channels including PDCCH, PUCCH, PBCH, PSCCH, and PSBCH.

[0032] (Reference signal) In this disclosure, a reference signal is a signal known to both the base station and the mobile station, and each reference signal may be called a Reference Signal (RS) or, if applicable, a pilot signal. A reference signal may be any of the following: DMRS, Channel State Information - Reference Signal (CSI-RS), Tracking Reference Signal (TRS), Phase Tracking Reference Signal (PTRS), Cell-Specific Reference Signal (CRS), and Sounding Reference Signal (SRS).

[0033] (Time interval) In this disclosure, the time resource unit is not limited to slots and symbols, or a combination thereof, but may be a time resource unit such as a frame, superframe, subframe, slot, time slot subslot, or minislot, or a time resource unit such as a symbol, orthogonal frequency division multiplexing (OFDM) symbol, single carrier-frequency division multiplexing access (SC-FDMA) symbol, or any other time resource unit. The number of symbols contained in one slot is not limited to the number exemplified in the embodiments described above, but may be a different number of symbols.

[0034] (Frequency band) This disclosure can be applied to both licensed and unlicensed bands.

[0035] (communication) This disclosure can be applied to any of the following: communication between a base station and a terminal (Uu-link communication), communication between terminals (side-link communication), and communication between a vehicle and any entity (V2X: Vehicle to Everything). The channels in this disclosure can be replaced with PSCCH, PSSCH, Physical Sidelink Feedback Channel (PSFCH), PSBCH, PDCCH, PUCCH, PDSCH, PUSCH, and PBCH.

[0036] Furthermore, this disclosure can be applied to either terrestrial networks or non-terrestrial networks (NTNs) that use satellites or high-altitude pseudo-satellites (HAPS). In addition, this disclosure may be applied to networks with large cell sizes or terrestrial networks where the delay is large relative to the symbol length or slot length, such as ultra-wideband transmission networks.

[0037] (Antenna port) An antenna port refers to a logical antenna (antenna group) formed by one or more physical antennas. That is, an antenna port does not necessarily refer to a single physical antenna, but can also refer to an array antenna or other structure formed by multiple antennas. For example, the number of physical antennas forming an antenna port is not defined; instead, an antenna port is defined as the smallest unit on which a terminal can transmit a reference signal. Furthermore, an antenna port may also be defined as the smallest unit for multiplication of pre-coding vector weights.

[0038] <Split of 5G NR functions between NG-RAN and 5GC> Figure 2 shows the split of functions between NG-RAN and 5GC. The logical nodes of NG-RAN are gNB or ng-eNB. The logical nodes of 5GC are AMF, UPF, and SMF.

[0039] gNB and ng-eNB particularly handle the following major functions. - Functions of radio resource management, such as radio bearer control, radio admission control, connection mobility control, and dynamic resource allocation (scheduling) to the UE in both the uplink and downlink directions - IP header compression, encryption, and data integrity protection - Selection of the AMF at the time of UE attachment when the routing to the AMF cannot be determined from the information provided by the UE - Routing of user plane data to the UPF - Routing of control plane information to the AMF - Establishment and release of connections - Scheduling and transmission of paging messages - Scheduling and transmission of system broadcast information (sent from the AMF or OAM) - Setting of measurements and measurement reports for mobility and scheduling - Transport-level packet marking in the uplink - Session management - Support for network slicing - QoS flow management and mapping to data radio bearers - Support for UEs in the RRC_INACTIVE state - Delivery function of NAS messages - Radio access network sharing - Double connection - Close interworking between NR and E-UTRA

[0040] The Access and Mobility Management Function (AMF) handles the following key functions: - Termination of Non-Access Stratum (NAS) signaling - NAS signaling security - Security control at the Access Layer (AS) - Core Network (CN) node-to-node signaling for mobility between 3GPP access networks - Reachability of idle mode UE (including control and execution of paging retransmissions) - Registration Area Management - Support for intra-system and inter-system mobility - Access Authentication - Access authentication including roaming rights check - Mobility management and control (subscriptions and policies) - Support for network slicing - Selection of Session Management Function (SMF)

[0041] Furthermore, the User Plane Function (UPF) handles the following key functions: - Anchor points for mobility within / between RATs (when applicable) - External PDU session points for interconnection with the data network - Packet routing and forwarding - User plane portion of packet inspection and policy rule enforcement - Traffic usage report - Uplink classifier to support routing of traffic flows to the data network - Branching point to support multi-homed PDU sessions - User plane QoS processing (e.g., packet filtering, gating, UL / DL rate enforcement) - Verification of uplink traffic (mapping from SDF to QoS flow) - Buffering of downlink packets and triggering of downlink data notifications

[0042] Finally, the Session Management Function (SMF) processes the following main functions. - Session management - Allocation and management of UE IP addresses - Selection and control of the UP function - Setting up traffic steering in the User Plane Function (UPF) to route traffic to the correct destination - Policy enforcement and QoS control part - Downlink data notification

[0043] <Procedures for RRC connection setup and reconfiguration> Figure 3 illustrates the interaction between the UE, gNB, and AMF in the NAS portion when the UE transitions from RRC_IDLE to RRC_CONNECTED (see Non-Patent Literature 1). RRC is a higher-layer signaling (protocol) used for configuring the UE and gNB. Specifically, in this transition, the AMF creates UE context data (e.g., including PDU session context, security key, UE radio capability, UE security capability, etc.) and sends it to the gNB via INITIAL CONTEXT SETUP REQUEST. The gNB then activates AS security with the UE, which is done by the gNB sending a SecurityModeCommand message to the UE, and the UE responding to the gNB with a SecurityModeComplete message. The gNB then performs a reconfiguration to establish the signaling radio bearer 2 (SRB2) and data radio bearer (DRB), which is done by the gNB sending an RRCReconfiguration message to the UE, and the gNB receiving an RRCReconfigurationComplete from the UE in response. In the case of a signaling-only connection, SRB2 and DRB are not established, so these steps related to RRCReconfiguration are skipped. Finally, the gNB notifies the AMF that the establishment procedure is complete via the INITIAL CONTEXT SETUP RESPONSE.

[0044] Accordingly, this disclosure provides a fifth-generation core (5GC) entity (e.g., AMF, SMF, etc.) comprising, during operation, a control circuit for establishing a next-generation (NG) connection with a gNodeB, and, during operation, a transmitter for sending an initial context setting message to the gNodeB via the NG connection to establish a signaling radio bearer between the gNodeB and the user equipment (UE). Specifically, the gNodeB sends RRC (Radio Resource Control) signaling, including resource allocation setting information elements, to the UE via the signaling radio bearer. The UE performs uplink transmission or downlink reception based on the resource allocation setting.

[0045] <IMT Usage Scenarios from 2020 Onward> Figure 4 illustrates some use cases for 5G NR. The 3GPP (Third Generation Partnership Project) New Radio (3GPP NR) considers three use cases envisioned to support various services and applications under IMT-2020. Phase 1 specifications for Enhanced Mobile Broadband (eMBB) have been finalized. Current and future work includes further expanding eMBB support, as well as standardization of Ultra-Reliable Low-Latency Communications (URLLC) and Massive Machine-Type Communications. Figure 4 shows some examples of envisioned use scenarios for IMT-2000 and beyond (see, for example, Figure 2 in Non-Patent Document 3).

[0046] URLLC use cases have stringent requirements regarding capabilities such as throughput, latency, and availability, and are envisioned as one means of realizing future vertical applications such as wireless control of industrial manufacturing and production processes, remote medical surgery, power distribution automation in smart grids, and transportation safety. The ultra-high reliability of URLLC is supported by identifying the technology to meet the requirements set out in Non-Patent Document 4. In NR URLLC of Release 15, a key requirement is a target user plane latency of 0.5 ms for both UL (uplink) and DL (downlink), respectively. Typical URLLC requirements for a single packet transmission are a BLER (block error rate) of 1E-5 for a packet size of 32 bytes with a user plane latency of 1 ms.

[0047] From a physical layer perspective, several ways to improve reliability are possible. Current approaches to reliability improvements include defining separate CQI tables for URLLC, a more compact Downlink Control Information (DCI) format, and PDCCH iteration. However, as NR becomes more stable and development progresses (regarding key requirements for NR URLLC), the scope for achieving ultra-high reliability may expand. Specific use cases for NR URLLC in Release 15 include augmented reality / virtual reality (AR / VR), e-health, e-safety, and mission-critical applications.

[0048] Furthermore, the technical enhancements targeted by NR URLLC aim to improve latency and reliability. Technical enhancements to improve latency include configurable numerology, non-slot-based (mini-slot-based) scheduling using flexible mapping, grant-free (configured grant) uplinks, slot-level iteration on data channels, and downlink preemption. Preemption means that a transmission for which resources have already been allocated is aborted, and the allocated resources are used for another transmission requested later with lower latency / higher priority requirements. Thus, a transmission that has already been permitted is preempted by a later transmission. Preemption applies regardless of service type. For example, a transmission of service type A (URLLC) can be preempted by a transmission of service type B (e.g., eMBB). Technical enhancements related to improved reliability include a dedicated CQI / MCS table for the 1E-5 target BLER.

[0049] The use case for mMTC (Massive Machine Type Communication) is characterized by a very large number of connected devices transmitting relatively small amounts of data, which are generally less affected by latency. These devices are required to be low-cost and have extremely long battery life. From a noise reduction (NR) perspective, utilizing a very narrow bandwidth is one possible solution to achieve power savings from a UE perspective and enable long battery life.

[0050] As mentioned above, the range of reliability in NR is expected to broaden. One important requirement in all cases, especially for URLLC and mMTC, is high or very high reliability. Several mechanisms can be considered to improve reliability from both a radio and network perspective. In general, there are several important areas that can help improve reliability. These areas include compact control channel information, data channel / control channel repetition, and diversity related to the frequency domain, time domain, and / or spatial domain. These areas are generally applicable to reliability, regardless of the specific communication scenario.

[0051] In the case of NR URLLC, further use cases with more stringent requirements have been identified, such as factory automation, transportation, and power distribution. These stringent requirements, depending on the use case, include higher reliability (up to 10%). -6 The features include higher availability, a maximum packet size of 256 bytes, time synchronization on the order of a few microseconds (1 microsecond to several microseconds depending on the frequency range), and low latency on the order of 0.5 to 1 ms, especially a target user plane latency of 0.5 ms.

[0052] Furthermore, in the case of NR URLLC, several technical enhancements have been identified from a physical layer perspective. In particular, enhancements related to the PDCCH (Physical Downlink Control Channel) include a more compact DCI, PDCCH repetition, and increased PDCCH monitoring. Enhancements related to the UCI (Uplink Control Information) include improved HARQ (Hybrid Auto Retransmission Request) and enhanced CSI feedback. Enhancements to PUSCH related to mini-slot level hopping and retransmission / repetition have also been recognized. The term "mini-slot" refers to a TTI (Transmission Time Interval) containing fewer symbols than a slot (a slot contains 14 symbols).

[0053] <QoS Control> The 5G QoS (Quality of Service) model is based on QoS flows and supports both QoS flows that require a guaranteed flow bit rate (GBR QoS flows) and QoS flows that do not require a guaranteed flow bit rate (non-GBR QoS flows). Therefore, at the NAS level, a QoS flow is the finest granularity of QoS differentiation in a PDU session. A QoS flow is identified within a PDU session by a QoS flow ID (QFI) that is carried in the encapsulation header through the NG-U interface.

[0054] The 5GC establishes one or more PDU sessions for each UE. The NG-RAN can establish, for each UE, at least one data radio bearer (DRB) together with the PDU session and then configure additional DRBs for the QoS flows of that PDU session as described above, for example, while referring to Figure 3 (when to configure is determined by the NG-RAN). The NG-RAN maps packets belonging to different PDU sessions to different DRBs. UL and DL packets are associated with QoS flows by NAS-level packet filters in the UE and 5GC, and UL and DL QoS flows are associated with DRBs by AS-level mapping rules in the UE and NG-RAN.

[0055] Figure 5 shows the non-roaming standard architecture for 5G NR (see Section 4.23 of Non-Patent Document 5). Application Functions (AFs) (e.g., external application servers handling 5G services as illustrated in Figure 4) interact with the 3GPP core network for the purpose of providing services. For example, they support the application's influence on traffic routing, access Network Exposure Functions (NEFs), and interact with policy frameworks for policy control (e.g., QoS control) (see Policy Control Functions (PCFs)). Based on the operator's deployment, application functions (AFs) that are considered trusted by the operator may be allowed to interact directly with the relevant Network Functions. Application functions (AFs) that are not authorized by the operator to directly access Network Functions interact with the relevant Network Functions using external exposure frameworks via NEFs.

[0056] Figure 5 shows further functional units of the 5G architecture, namely the Network Slice Selection Function (NSSF), Network Repository Function (NRF), Unified Data Management (UDM), Authentication Server Function (AUSF), Access and Mobility Management Function (AMF), Session Management Function (SMF), and Data Network (DN) (e.g., operator services, internet access, or third-party services). All or some of the core network functions and application services may be deployed and run in a cloud computing environment.

[0057] In RANP#86 [Non-Patent Literature 6], a new study item (SI) concerning support for RedCap (RedCap) NR devices (also known as NR Light / Lite) was approved. The objective of this SI is to support a lighter version of NR for mid-range NR devices (e.g., smartwatches, video surveillance cameras, industrial sensors) where high throughput, latency, and reliability requirements are not critical. One of the main objectives of this SI is to identify and examine features that may reduce the complexity of the UE, such as: - Reduce the number of receive / transmit antennas in the UE. - Reduce UE bandwidth (reuse Rel-15 SSB bandwidth and minimize L1 changes). - Half-duplex - Frequency-division duplex (FDD) - Reduced UE processing time - Relaxation of UE processing capacity

[0058] A UE can configure up to 12 control resource sets (CORESETs) (indexes 0-11) in a single serving cell. A CORESET is configured in units of six physical resource blocks (PRBs) on six PRB frequency grids and one, two, or three consecutive OFDM symbols in the time domain. The CORESET at index 0 (i.e., CORESET#0, also called the first CORESET) is acquired by the UE for initial cell selection and initial access before dedicated higher-layer configurations are provided. CORESET#0 can be configured by some predefined process and predefined parameters.

[0059] When a synchronization signal block (SSB) is detected, the UE derives the master information block (MIB) from the physical broadcast channel (PBCH). In frequency range 1 (FR1), when k SSB ≤ 23, or in frequency range 2 (FR2), when k SSB ≤ 11, the UE determines the number of consecutive resource blocks and the number of consecutive symbols of the CORESET of the Type0-PDCCH CSS set (i.e., CORESET#0) from the controlResourceSetZero of the pdcch-ConfigSIB1 information element (IE) of the MIB, as described in Tables 13.1 to 13.10 of Non-Patent Document 7, and determines the PDCCH monitoring occasion from the searchSpaceZero of pdcch-ConfigSIB1, as described in Tables 13.11 to 13.15 of Non-Patent Document 7. On the other hand, in FR1, when k SSB > 23, or in FR2, when k SSB > 11, CORESET#0 does not exist in the MIB IE, and in the DCI format in which the cyclic redundancy check (CRC) is scrambled by the system information - radio network temporary identifier (SI-RNTI) in the primary cell of the master cell group (MCG), it can be provided by the controlResourceSetZero of PDCCH-ConfigCommon or the searchSpaceZero of PDCCH-ConfigCommon.

[0060] However, potential problems arise when the bandwidth (BW) of Rel-15 CORESET#0 is greater than, or could be greater than, the BW of the RedCap UE, for example, when Rel-CORESET#0's BW 602 exceeds RedCap UE's BW 604, as shown in Figure 6. Furthermore, the bandwidth of the SIB1 PDSCH currently scheduled by Rel-15 CORESET#0 may also be greater than the BW of the RedCap NR device. This can lead to failures in initial cell selection or handover.

[0061] Accordingly, this disclosure provides a solution for a UE to receive a PDCCH on CORESET#0, where time and frequency resources are defined based on the bandwidth configuration associated with the RedCap UE. This PDCCH on CORESET#0 is used to schedule System Information Type 1 (SIB1) PDSCH, Msg2 PDSCH, and Msg4 PDSCH targeting the RedCap UE. Advantageously, this allows NR Light / Lite (or RedCap) UEs with narrower bandwidth capabilities to read SIB1 for initial access. Furthermore, during initial access, the Msg2 PDSCH and Msg4 PDSCH are transmitted within the CORESET#0 bandwidth. According to Embodiment 1, based on the appropriate BW of the RedCap UE, a subset / part of Rel-15 CORESET#0, i.e., a subset of the entries in Tables 13.1 to 13.10 described in Non-Patent Literature 7, can be configured for the RedCap UE. As illustrated in the exemplary diagram 700 of Figure 7, only a subset / part 706 of Rel-15 CORESET#0 702 is configurable for all types of UEs in the involved network (i.e., standard Rel-15 / 16 / 17 UEs and RedCap UEs). The subset / part 706 is defined based on the BW of the RedCap UE so that it has a smaller BW than the BW 704 of the RedCap UE, as can be seen in Figure 7. Legacy operation and instruction information for the UE can still be reused.

[0062] According to Embodiment 1, the RedCap UE can assume that the BW of CORESET#0 shown in the MIB, based on Tables 13.1 to 13.10 of Non-Patent Literature 7, is equal to or smaller than its own BW, or if the CORESET#0 BW shown in the MIB, based on Tables 13.1 to 13.10 of Non-Patent Literature 7, is greater than the UE's BW, the UE discards (or ignores) the SSB. Advantageously, the complexity of the search is simplified by reducing the common search space (CSS) set and / or the UE-specific search space (USS) set. Furthermore, the introduction of the NR Light / Lite (or RedCap) UE avoids additional overhead.

[0063] Examples of subsets of Rel-15 CORESET#0 for RedCap UE when the RedCap UE's BW is 5MHz or 10MHz and the {SSB,PDCCH}SCS is {15,15}kHz are shown in Table 800 in Figure 8A and Table 802 in Figure 8B, respectively, both tables based on Table 13.1 of Non-Patent Literature 7. For example, Table 800 shows a subset of CORESET#0 RB and slot symbols for indices 0-5 when the {SSB,PDCCH}SCS is {15,15}kHz in a frequency band with a minimum channel BW of 5MHz. Table 802, on the other hand, shows a subset of CORESET#0 RB and slot symbols for indices 0-11 when the {SSB,PDCCH}SCS is {15,15}kHz in a frequency band with a minimum channel BW of 10MHz. It should be understood that, just as a subset of entries in Tables 13.1 to 13.10 is defined based on the BW of RedCap UE, a similar approach can be used to define a subset of entries in Tables 13.2 to 13.10 that targets RedCap UE.

[0064] According to Embodiment 2, when the BW of Rel-15 CORESET#0 is greater than the BW of the RedCap UE, Rel-15 CORESET#0 is divided into m equal or unequal subsets such that m ≥ 1. Figure 9 shows a schematic diagram 900 illustrating the transmission of a subset of Rel-15 CORESET#0 902 according to Embodiment 2. Rel-15 CORESET#0 902 is divided into two subsets 904 and 906, subset 904 is mapped to slot n, and subset 906 is mapped to slot n-1. The BW of each subset 904 and 906 of Rel-15 CORESET#0 is not greater than the BW of the RedCap UE. Each subset of Rel-15 CORESET#0 (i.e., CORESET#0 for RedCap UE) can be a subset of the entries in Tables 13.1 to 13.10 of Non-Patent Literature 7, or a subset of physical resources such as control channel elements (CCEs) or physical resource blocks (PRBs) of Rel-15 CORESET#0. The upper limit of m depends on the capabilities of the UE, consideration of channel delay / estimates, or the periodicity of the SSB.

[0065] A PDCCH can be communicated by 1, 2, 4, 8, or 16 CCEs to accommodate different DCI payload sizes or coding rates, with the number of CCEs in a PDCCH specified by the aggregation level. Each CCE consists of 6 resource element groups (REGs), and each REG consists of 12 resource elements (REs) of one OFDM symbol within a single PRB.

[0066] Indicate CORESET#0 for RedCap UE (i.e., the existing entries of the ControlResourceSetZero IE and SearchSpaceZero IE in the MIB) using the current indication information of Rel-15 CORESET#0 for the standard UE. The i-th subset of Rel-15 CORESET#0 is set in the corresponding slot n - i (0 ≤ i < m), and slot n can be the PDCCH monitoring opportunity (slot or symbol) of Rel-15 CORESET#0 or the PDCCH monitoring opportunity set for the RedCap UE. When the RedCap UE monitors m consecutive slots, as shown in the schematic diagram 900 of FIG. 9, it attempts blind decoding (BD: blind decoding) to decode Rel-15 CORESET#0 by combining m subsets. When m > 1, the RedCap UE may need to monitor the split Rel-15 CORESET#0 in a slot different from the monitoring opportunity defined for Rel-15 / 16 UEs. Advantageously, the BW of the RedCap UE can be made narrower than the BW of Rel-15 CORESET#0. When m = 2, the existing behavior regarding the monitoring opportunity of CORESET#0 applies to both the standard UE and the RedCap UE.

[0067] In the first variation of Embodiment 2, the subset mapping and UE behavior can be as follows. - To support standard Rel-15 / 16 UEs, the complete Rel-15 CORESET#0 is mapped to slot n - To support RedCap UEs, the i-th subset of Rel-15 CORESET#0 is individually set in the corresponding slot n - i (1 ≤ i < m - 1) - Example: The complete Rel-15 CORESET#0 is split into subset #0 and subset #1. The complete Rel-15 CORESET#0 is mapped to slot n (i.e., subset #0 is included in Rel-15 CORESET#0 in slot n), and subset #1 is mapped to slot n-1. - The standard Rel-15 / 16 UE attempts blind decoding in slot n and decodes Rel-15 CORESET#0. - RedCap UE attempts blind decoding by combining m subsets in m consecutive slots to decode Rel-15 CORESET#0.

[0068] In a second variation of Embodiment 2, the subset mapping and UE behavior can be as follows: - To support the standard Rel-15 / 16 UE, the full Rel-15 CORESET#0 is mapped to slot n. - To support RedCap UE, the i-th subset of Rel-15 CORESET#0 is set individually in the corresponding slot ki (0≦i <m) - The value of k can be defined in advance. - The standard Rel-15 / 16 UE attempts blind decoding in slot n and decodes Rel-15 CORESET#0. - RedCap UE attempts blind decoding by combining m subsets in m consecutive slots to decode Rel-15 CORESET#0.

[0069] Figure 10 shows an exemplary diagram of the even division of Rel-15 CORESET#0 according to Embodiment 2. In this example, we assume that the BW of the standard UE and the RedCap UE are 48PRB and 36PRB, respectively, and that the BW of Rel-15 CORESET#0 is 48PRB. Rel-15 CORESET#0 is evenly divided into two subsets (i.e., subset #0 1004 and subset #1 1006), each subset having 24PRB. The 24PRB subset #0 1004 is mapped to slot n, and the 24PRB subset #1 1006 is mapped to slot n-1. The standard UE and the RedCap UE attempt to decode Rel-15 CORESET#0 by attempting blind decoding using the combination of received PRBs in slot n-1 and slot n.

[0070] Figure 11 shows an illustrative diagram 1100 of the uneven partitioning of Rel-15 CORESET#0 according to Embodiment 2. In this example, we assume that the BW of the standard UE and the RedCap UE are 48PRB and 36PRB, respectively, and that the BW of Rel-15 CORESET#0 is 48PRB. Rel-15 CORESET#0 1102 is unevenly partitioned into two subsets, subset #0 1104 having 12PRB and subset #1 1106 having 36PRB. The longer subset of subset #0 1104 and subset #1 1106 can be assigned to the earlier or later slot, or the longer subset of the two subsets can be assigned to a slot with better channel condition than the other slot. In this example, subset #0 1104 of the 12PRB is mapped to slot n, and subset #1 1106 of the 36PRB is mapped to slot n-1. The standard UE and RedCap UE attempt blind decoding of Rel-15 CORESET#0 using the combination of received PRBs in slot n-1 and slot n.

[0071] Figure 12 shows an exemplary diagram of the equal division of Rel-15 CORESET#0 1202 according to the first variation of Embodiment 2. In this example, we assume that the BW of the standard UE and the RedCap UE are 48PRB and 36PRB, respectively, and that the BW of Rel-15 CORESET#0 is 48PRB. Rel-15 CORESET#0 1202 is equally divided into two subsets (i.e., subset #0 1204 and subset #1 1206), each subset having 24PRB. The undivided, complete Rel-15 CORESET#0 1202 is mapped to slot n, and the 24PRB subset #1 1206 is mapped to slot n-1. A standard Rel-15 / 16 UE attempts blind decoding in slot n to decode Rel-15 CORESET#0, while a RedCap UE attempts blind decoding by combining m subsets in m consecutive slots (i.e., slots n and n-1 in this example) to decode Rel-15 CORESET#0.

[0072] Figure 13 shows an exemplary illustration of the uneven partitioning of Rel-15 CORESET#0 1302 according to a first variation of Embodiment 2. In this example, we assume that the BW of the standard UE and the RedCap UE are 48PRB and 36PRB, respectively, and that the BW of Rel-15 CORESET#0 is 48PRB. Rel-15 CORESET#0 1302 is unevenly partitioned into two subsets (i.e., subset #0 1304 and subset #1 1306), with subset #0 1304 having 12PRB and subset #1 1306 having 36PRB. The unpartitioned, complete Rel-15 CORESET#0 1302 is mapped to slot n, and the 36PRB subset #1 1306 is mapped to slot n-1. A standard Rel-15 / 16 UE attempts blind decoding in slot n to decode Rel-15 CORESET#0, while a RedCap UE attempts blind decoding by combining m subsets in m consecutive slots (i.e., slots n and n-1 in this example) to decode Rel-15 CORESET#0.

[0073] According to Embodiment 3, when the BW of Rel-15 CORESET#0 is greater than the BW of the RedCap UE, the portion of the Rel-15 CORESET#0 BW that is outside the RedCap UE BW is divided into q equal or unequal subsets such that q ≥ 1. The BW of each subset of Rel-15 CORESET#0 is not greater than the BW of the RedCap UE. Each subset of Rel-15 CORESET#0 (i.e., CORESET#0 for RedCap UE) can be a subset of the entries in Tables 13.1 to 13.10 of Non-Patent Literature 7, or a subset of physical resources such as the CCE of Rel-15 CORESET#0. These subsets are copied and mapped within the BW of the RedCap UE in different monitoring opportunities (i.e., slots or symbols). The upper limit of q depends on the capabilities of the UE, consideration of channel delay / estimates, or the periodicity of the SSB. Using the current directive information for Rel-15 CORESET#0 for standard UEs, we show the existing entries in CORESET#0 for RedCap UEs, i.e., the ControlResourceSetZero IE and SearchSpaceZero IE of the MIB.

[0074] Rel-15 CORESET#0 signals standard UEs and RedCap UEs using the following (pre-configured) rules. - Rel-15 CORESET#0 is mapped to slot n. The i-th subset of Rel-15 CORESET#0 is copied and mapped into the BW of the RedCap UE in the corresponding slot ni (1 ≤ i <q)。 - The standard UE attempts to decode Rel-15 CORESET#0 by blind decoding, monitoring slot n and slot n-1. - RedCap UE is the number of RBs used in the PDSCH resource allocation field.

number

[0075] Figure 14 shows an exemplary diagram 1400 of the transmission of Rel-15 CORESET#0 1402 and a subset thereof according to Embodiment 3. In this example, the portion of the BW of Rel-15 CORESET#0 1402 that is within the scope of the RedCap UE BW is portion 1404 of Rel-15 CORESET#0, and the portion of the BW of Rel-15 CORESET#0 1402 that is outside the RedCap UE BW is subset #0 1406. Since the BW of subset #0 1406 does not extend beyond the RedCap UE BW, it is not divided into further subsets (i.e., q=1). Subset #0 1406 is copied and mapped into the RedCap UE BW in slot n-1. The standard UE attempts to decode Rel-15 CORESET#0 by blind decoding by monitoring slots n and n-1. The RedCap UE attempts to decode Rel-15 CORESET#0 by monitoring q+1 consecutive slots (same for slots n and n-1 in this example, since q=1).

[0076] In Embodiment 3, advantageously, the BW of the RedCap UE can be made narrower than the BW of the Rel-15 CORESET#0. Furthermore, when q=1, the existing behavior of the monitoring opportunities of CORESET#0 is applied to the standard UE and the RedCap UE, as can be seen in Diagram 1400 of Figure 14.

[0077] Figure 15 shows an illustrative diagram 1500 of the transmission of Rel-15 CORESET#0 1502 and a subset thereof, according to a variation of Embodiment 3. In this variation, Rel-15 CORESET#0 1502 signals to standard UEs and RedCap UEs by using pre-configured rules as follows: - Rel-15 CORESET#0 1502 is mapped to slot n. - In slot ni (1≦i≦q), only the 1504 portion of the Rel-15 CORESET#0 mapping that RedCap UE can monitor inside the BW is replaced by the i-th subset of the Rel-15 CORESET#0 mapping outside the RedCap UE's BW in slot n. - The standard UE attempts to decode Rel-15 CORESET#0 by blind decoding, monitoring slot n and slot n-1. - RedCap UE attempts to decode Rel-15 CORESET#0 by blind decoding, monitoring q+1 consecutive slots.

[0078] Similar to the example in Figure 14, the BW of subset #0 1506 (i.e., the portion of the mapping of Rel-15 CORESET#0 1502 in slot n that is outside the BW of the RedCap UE) does not extend beyond the RedCap UE BW and is therefore not split into further subsets (i.e., q=1). Subset #0 1506 is copied and mapped into the BW of the RedCap UE in slot n-1. The standard UE attempts to decode Rel-15 CORESET#0 by blind decoding by monitoring slots n and n-1. The RedCap UE attempts to decode Rel-15 CORESET#0 by blind decoding by monitoring q+1 consecutive slots (similarly slots n and n-1 in this example, since q=1).

[0079] Figure 16 shows an illustrative diagram 1600 of the transmission rules for how the RedCap UE receives Rel-15 CORESET#0, according to a variation of Embodiment 3. Here, it is assumed that Rel-15 CORESET#0 1602 has a BW of 48PRB and 8 CCEs. The RedCap UE has a BW of only 24PRB. The rules shown in diagram 1600 are as follows: - Of the CCEs in Rel-15 CORESET#0 1602, the CCEs at indices 0, 2, 4, and 6 located outside the BW of the RedCap UE (i.e., part 1606) are copied and mapped into the BW of the RedCap UE in slot n-1. - gNB sends only CCEs at indices 0, 2, 4, and 6 (i.e., part 1606) in slot n-1, but in slot n, it sends all CCEs at indices 0-7 of Rel-15 CORESET#0 1602, which has 8 CCEs (both parts 1604 and 1606 of Rel-15 CORESET#0). - The standard UE attempts blind decoding to decode Rel-15 CORESET#0 1602 in slots n-1 and n. - RedCap UE decodes Rel-15 CORESET#0 1602 using the combination of CCE0,2,4,6 in slot n-1 and CCE1,3,5,7 in slot n.

[0080] The transmit bandwidth of CORESET#0 is narrower than the transmit bandwidth of Rel-15 CORESET#0, but the bandwidth used for allocating PDSCH frequency domain resources in DCI transmitted by CORESET#0 is (i.e.)

number

[0081] The above rule in Exemplary Figure 1600 can be extended as follows in a scenario where RedCap UE is configured to monitor three or more consecutive slots, such as slots n-2, n-1, and n: - gNB will only send CCEs with indices 0, 2, 4, and 6 in slot n-2. - gNB sends only CCEs with indices 1, 3, 5, and 7 in slot n-1. - gNB sends all CCEs from index 0 to 7 in slot n. - RedCap UE decodes Rel-15 CORESET#0 using the combination of CCE0,2,4,6 in slot n-2 and CCE1,3,5,7 in slot n-1.

[0082] It should be understood that, depending on the capabilities of the RedCap UE and / or the implementation of the gNB, there may be other possibilities regarding the number / order of CCEs sent within a slot (such as n-2, n-1, n).

[0083] Figure 17 shows an exemplary illustration 1700 of Rel-15 CORESET#0 1702 and CORESET#0 1704 for RedCap UE according to Embodiment 4. According to this embodiment, information 1706 indicating Rel-15 CORESET#0 1702 for standard (Rel-15 / 16 / 17) UEs and a subset of Rel-15 CORESET#0 for RedCap UEs (i.e., CORESET#0 1704 for RedCap UEs) is set as follows: - CORESET#0 for RedCap UE is designed based on its appropriate BW, as shown in Embodiment 1. - CORESET#0 for RedCap UE is a subset of the entries in Tables 13.1-13.10 described in Non-Patent Document 7.

[0084] In Embodiment 4, separate directive information for Rel-15 CORESET#0 for the standard UE and CORESET#0 for the RedCap UE is used. The physical resources for CORESET#0 for the RedCap UE are indicated by using new entries in the ControlResourceSetZero IE and SearchSpaceZero IE of the MIB or PDCCH-ConfigCommon. For example, additional ControlResourceSetZero_NRLight and SearchSpaceZero_NRLight are proposed to indicate CORESET#0 and PDCCH monitoring opportunities for the RedCap UE, respectively, while the existing ControlResourceSetZero and SearchSpaceZero indicate CORESET#0 and PDCCH monitoring opportunities for the standard UE, respectively. ControlResourceSetZero ::= SEQUENCE{ ControlResourceSetZero INTEGER (0..15) ControlResourceSetZero_NRLight INTEGER (0..15)} SearchSpaceZero ::= SEQUENCE{ SearchSpaceZero INTEGER (0..15) SearchSpaceZero_NRLight INTEGER (0..15)}

[0085] It should be understood that the above signaling method is also applicable to Embodiments 2 and 3.

[0086] According to Embodiment 5A, the current directive information of Rel-15 CORESET#0 (i.e., the existing ControlResourceSetZero IE and SearchSpaceZero IE in the MIB) is reinterpreted for use for both standard UEs and RedCap UEs. Figure 18 shows an exemplary diagram 1800 of the reinterpretation of Rel-15 CORESET#0 for both standard UEs and RedCap UEs according to Embodiment 5A. The same directive information of Rel-15 CORESET#0 (i.e., signaling 1802) is used for both standard UEs and RedCap UEs, but the actual values ​​indicated in the setting fields of CORESET#0 differ between standard UEs and RedCap UEs. For RedCap UEs, a different interpretation is proposed for the setting field of Rel-15 CORESET#0 in ControlResourceSetZero, as follows: - In Tables 13.1 to 13.10 of Non-Patent Document 7, we propose additional new entries (rows / columns) for CORESET#0 in RedCap UE. - The value of a new entry (physical resource) is designed based on the capabilities of RedCap UE. - The size of the configuration fields for Rel-15 CORESET#0 for standard UEs and CORESET#0 for RedCap UEs is the same.

[0087] Furthermore, the actual values ​​(indicated physical resources) in the entries of Tables 13.1-13.10 proposed in Non-Patent Literature 7 for RedCap UE may differ from the values ​​of the standard UE. The standard UE reads the current MIB information by monitoring slots n and n-1 and obtains Rel-15 CORESET#0 using the existing values ​​in Tables 13.1-13.10 of Non-Patent Literature 7. The RedCap UE reads the current MIB information by monitoring slots n and n-1 and obtains CORESET#0 using the corresponding values ​​in the new entries (rows and / or columns) in Tables 13.1-13.10. It will be understood that the above signaling method for CORESET#0 and monitoring opportunities of the RedCap UE is also applicable to Embodiments 2 and 3. Advantageously, this avoids the additional overhead of introducing the RedCap UE and has no impact on the MIB.

[0088] CORESET#0 for standard UEs and RedCap UEs can be shown in the same table as in Non-Patent Literature 7, or in a separate table. Figure 19 shows an example of showing CORESET#0 in the same table as in Table 13.1 of Non-Patent Literature 7. Table 1900 in Figure 19 contains the set of resource blocks and slot symbols for the CORESET in the Type0-PDCCH search space set for standard UEs and RedCap UEs, when {search space / physical broadcast channel block,PDCCH}SCS ({SS / PBCH block,PDCCH}SCS) is {15,15}kHz for a minimum channel bandwidth of 5MHz or 10MHz in the frequency band according to Embodiment 5A. When the BW of the RedCap UE is 5MHz, {SSB,PDCCH}SCS is {15,15}kHz, and new row and column examples for RedCap UE CORESET#0 are added as shown in Table 1900, based on Table 13.1 of Non-Patent Literature 7. For indices 0-5,

number

[0089] Figure 20 shows an example of CORESET#0 as presented in a table independent of Table 13.1 of Non-Patent Literature 7. Table 2000 in Figure 20 contains the set of resource blocks and slot symbols for the CORESET in the Type0-PDCCH search space set for RedCap UE, when {SS / PBCH block,PDCCH}SCS is {15,15}kHz for a minimum channel bandwidth of 5MHz according to Embodiment 5A. In this independent table configuration, the current Table 13.1 of Non-Patent Literature 7 is used to show Rel-15 CORESET#0 for standard UEs, while the independent Table 2000 (which is based on Table 1900) is used to show CORESET#0 for RedCap UEs. It will be understood that a similar approach can be applied to define corresponding independent tables for RedCap UEs in the various scenarios shown in Tables 13.2 to 13.10 of Non-Patent Literature 7.

[0090] Figure 21 shows an example of Table 2100 containing the set of resource blocks and slot symbols for the CORESET in the Type0-PDCCH search space set for standard UEs and RedCap UEs, when the {SS / PBCH block,PDCCH}SCS is {15,15}kHz for a minimum channel bandwidth of 5MHz or 10MHz, according to a variation of Embodiment 5A. In this variation, a different interpretation of Table 13.1 of Non-Patent Literature 7 for defining CORESET#0 for RedCap UEs is shown in Table 2100. When the BW of the RedCap UE is 5MHz, the {SSB,PDCCH}SCS is {15,15}kHz, and new row and column examples for CORESET#0 for RedCap UEs are added based on Table 13.1 of Non-Patent Literature 7, as shown in Table 2100. For indices 0-5,

number

[0091] Embodiment 5B reinterprets the current instruction information of Rel-15 CORESET#0 (i.e., the existing ControlResourceSetZero IE and SearchSpaceZero IE in the MIB) for use with standard UEs and RedCap UEs. For RedCap UEs, a different interpretation is proposed for the Rel-15 CORESET#0 configuration fields, as follows: - We propose adding new entries (rows / columns) for RedCap UE's CORESET#0 to Tables 13.1-13.10 of Non-Patent Document 7. - The value of a new entry (physical resource) is designed based on the capabilities of RedCap UE. - These values ​​can be a subset of the entries in Rel-15 CORESET#0. - The size of the configuration fields for Rel-15 CORESET#0 for standard UEs and CORESET#0 for RedCap UEs are different.

[0092] Furthermore, we propose different monitoring opportunities in SearchSpaceZero for standard UEs and RedCap UEs. Figure 22 illustrates an exemplary diagram of a reinterpretation of the monitoring opportunity for Rel-15 CORESET#0 for standard UEs and RedCap UEs according to Embodiment 5B. The gNB transmits Rel-15 CORESET#0 only in slot n, while transmitting CORESET#0 for RedCap UEs only in slot n-1. The standard UE reads the information of the current MIB by monitoring only slot n, as shown in Figure 22, and attempts blind decoding to decode Rel-15 CORESET#0 using its existing values. The RedCap UE, on the other hand, reads the information of the current MIB by monitoring slots such as n-1, as shown in Figure 22, and attempts blind decoding to decode CORESET#0 using the corresponding values ​​in the new entries. Advantageously, this reduces the monitoring opportunity for all UEs for the purpose of power saving. It should be understood that the size of new entries and monitoring opportunities for RedCap UE in Embodiment 5A and Embodiment 5B may differ.

[0093] According to Embodiment 5B, CORESET#0 for RedCap UE can be defined using the methods shown in Tables 2000 and 2200, i.e., CORESET#0 for RedCap UE is defined based on its BW capability. The monitoring opportunity is given in SearchSpaceZero, and the parameters are defined in Tables 13.11 to 13.15 of Non-Patent Literature 7. Therefore, the reinterpretation of the monitoring opportunity for Rel-15 CORESET#0 is based on Tables 13.11 to 13.15. Figure 23 shows Table 2300 of the parameters for the reinterpretation of the PDCCH monitoring opportunity for Type0-PDCCH CSS set-SSB and CORESET multiplexing pattern 1 and frequency range 1 (FR1) according to Embodiment 5B. As shown in Table 2300, a new column 2302 has been added to indicate which slot (index p) CORESET#0 of RedCap UE is mapped to. If p=0, the monitoring opportunity for RedCap UE's CORESET#0 is slot n-1, and slot n is the monitoring opportunity for Rel-15 CORESET#0. If p=1, the monitoring opportunity for RedCap UE's CORESET#0 is slot n+1, and slot n is the monitoring opportunity for Rel-15 CORESET#0.

[0094] Figure 24 shows an example of detailed steps for reading Table 2300 in Figure 23. - Step 1: Define an odd or even system frame number (SFN). - Step 2: Define the index for slot n. - Step 3: Define a slot for mapping RedCap UE CORESET#0 based on the value of p.

[0095] Figure 25 illustrates the different monitoring opportunities for Re-15 CORESET#0 for a standard UE and CORESET#0 for a RedCap UE according to Embodiment 5B. It is assumed that Re-15 CORESET#0 has 48 PRB and CORESET#0 for RedCap UE has 24 PRB. The detailed monitoring opportunities are as follows, as shown in Figure 25. - The gNB simply sends Rel-15 CORESET#0 of 48PRB as shown in Table 2100 to the standard UE in slot n. - The gNB simply sends CORESET#0 for 24PRB as shown in Table 2100 to the RedCap UE in slot n-1. - The standard UE attempts to decode Rel-15 CORESET#0 by reading the current MIB information and monitoring only slot n, thereby attempting blind decoding. - RedCap UE attempts to decode Rel-15 CORESET#0 by reading the current MIB information and monitoring slot n-1 or slot n+1 in a blind decryption.

[0096] It should be understood that Rel-15 CORESET#0 for standard UEs and CORESET#0 for RedCap UEs can be used for scheduling to the same or different System Information Block (SIB) PDSCH, also known as SIBx (SIB at index x).

[0097] According to Embodiment 5C, the current instruction information of Rel-15 CORESET#0 (i.e., the existing ControlResourceSetZero IE and SearchSpaceZero IE in the MIB) is reinterpreted for use targeting both standard UEs and RedCap UEs. A different interpretation of the setting fields of Rel-15 CORESET#0 targeting RedCap UEs is also proposed, and therefore new entries (rows / columns) for RedCap UE CORESET#0 are proposed in addition to Tables 13.1-13.10 of Non-Patent Literature 7, where the values ​​(physical resources) within the new entries are designed based on the capabilities of the RedCap UE. These values ​​can be defined using an approach similar to that shown in the examples of Embodiment 5A or Embodiment 5B (Tables 1900, 2100, or 2300).

[0098] Furthermore, repetitions of CORESET#0 can be explicitly and / or implicitly signaled to the RedCap UE. In the implicit approach, signaling can be done through pre-configured rules. In the explicit approach, signaling can be done through higher-layer signaling. For example, an additional column is added to Table 13.1 or Table 13.11 of Non-Patent Literature 7 to indicate repetitions for the RedCap UE in ControlResourceSetZero or SearchSpaceZero, shown in Table 2600 of Figure 26 or Table 2700 of Figure 27, respectively. At the time-domain position of the repetition, CORESET#0 of SSBy is used as a repetition of CORESET#0 of SSBx. gNB transmits Rel-15 CORESET#0 for the standard UE specified in SSBx within the same beam, while transmitting CORESET#0 for the RedCap UE specified in SSBx and (as a repetition) SSBy. Therefore, the standard UE detects SSBx and obtains Rel-15 CORESET#0, while the RedCap UE detects both SSBx and SSBy and obtains CORESET#0. Advantageously, this can reduce the coverage of common channels because the RedCap UE's bandwidth may be reduced. This solution can improve the coverage performance of the RedCap UE.

[0099] Referring to Table 2600 in Figure 26, an additional column 2602 has been added to show a new entry for RedCap UE CORESET#0 and the number of iterations in ControlResourceSetZero, based on Table 13.1 of Non-Patent Literature 7. Table 2600 can be split into separate tables for standard UEs and RedCap UEs, as similarly shown in Table 2000. It should be understood that this is just one example, and other possibilities exist regarding the number of rows / columns that can be additionally set in Tables 13.1 to 13.10 and the values ​​of these rows / columns, defined based on the capabilities of the RedCap UE.

[0100] Referring to Table 2700 in Figure 27, an additional column 2702 has been added to indicate the number of iterations in SearchSpaceZero, based on Table 13.11 of Non-Patent Literature 7. It should be noted that this is just one example, and other possibilities exist regarding the values ​​of these rows / columns that can be additionally set in Tables 13.1 to 13.15, which are defined based on the capabilities of RedCap UE.

[0101] Depending on the network availability and capabilities of RedCap UE, multiple embodiments can be applied together in the network targeting RedCap UE. The CORESET#0 for RedCap UE shown in embodiments 1-5 can be pre-configured via the application layer. For embodiments 2, 3, 4, 5A, 5B, and 5C, current cells (Pcell / PSCell / Scell) that only have Rel-15 / 16 capabilities cannot support RedCap UE. For example, a message such as "This cell does not support RedCap UE" needs to be signaled in the MIB or SIB1, or a new physical-layer cell identity (PCID) range should be used for RedCap UE, so that RedCap UE can discard these cells.

[0102] RedCap UEs are proposed to support a bandwidth (BW) at least equal to the maximum BW of CORESET#0 defined in Rel-15 / 16 (i.e., RedCap's BW is equal to or greater than the maximum BW of CORESET#0 defined in Rel-15 / 16). The current Rel-15 CORESET#0 is reused or shared for RedCap UEs (i.e., standard Rel-15 / 16 / 17 UEs and RedCap UEs are configured with the current Rel-15 CORESET#0). The physical resources of CORESET#0 are defined based on the minimum bandwidth setting associated with one or more UEs within the set of standard (non-RedCap or Rel-15 / 16 / 17...) UEs and RedCap UEs. Depending on the bandwidth of CORESET#0, the physical resource mapping scheme, or the monitoring opportunity, the UE performs blind decoding on PDCCH candidates in the search space communicated by CORESET#0 to acquire all control information across one or more consecutive slots.

[0103] In both frequency range 1 (FR1) and frequency range 2 (FR2), when the RedCap UE bandwidth is equal to or greater than the CORESET#0 bandwidth, both SSB and CORESET#0 can be shared between the RedCap UE and non-RedCap UEs. Furthermore, if a network wishes to offload RedCap UE transmissions, it can configure a separate CORESET#0 or initial downlink bandwidth part (BWP) that is frequency-division multiplexed (FDM) with non-RedCap UEs. For example, SSB and CORESET#0 can be frequency-domain multiplexed for multiplexing patterns 2 and 3 in FR2. In some specific cases, the total bandwidth may exceed the maximum bandwidth of the RedCap UE. In this case, frequency readjustment and sequential acquisition of SSB and CORESET#0 may be required, potentially leading to additional latency. However, in RedCap use cases, such additional latency is acceptable. Therefore, enhanced acquisition of SSB and / or CORESET#0 may not be necessary.

[0104] Figure 28 shows a flowchart 2800 illustrating communication methods according to various embodiments. In step 2802, CORESET#0 is received, in which time and frequency resources are defined based on the minimum bandwidth setting associated with one or more UEs in a set of standard (non-RedCap) UEs and RedCap UEs, and further, a System Information Block Type 1 (SIB1) Physical Downlink Shared Channel (PDSCH) scheduled based on CORESET#0 is received. In step 2804, control information and parameters for reading SIB1, Msg2 PDSCH, and Msg4 PDSCH for initial access, handover, or beam fault recovery are determined from the PDCCH on CORESET#0.

[0105] Figure 29 shows a schematic partial cross-sectional view of a communication device 2900 that can be implemented to facilitate the implementation of CORESET#0 for RedCap devices according to various embodiments. The communication device 2900 can be implemented as a gNB, a standard UE, or a RedCap UE according to various embodiments.

[0106] The various functions and operations of the communication device 2900 are arranged in layers according to a hierarchical model. In this model, lower layers report to higher layers and receive instructions from higher layers according to the 3GPP specification. For the sake of brevity, the details of the hierarchical model are not described in this disclosure.

[0107] As shown in Figure 29, the communication device 2900 may include a circuit 2914, at least one radio transmitter 2902, at least one radio receiver 2904, and multiple antennas 2912 (for simplicity, only one antenna is shown in Figure 29 for illustrative purposes). The circuit 2914 may include at least one controller 2906, which is used to perform tasks designed to be performed, including controlling communication with one or more other communication devices in a MIMO radio network, with the assistance of software and hardware. At least one controller 2906 can control at least one transmit signal generator 2908 to generate SIB, SL-UEInfo, and / or RRC-Reconfig messages to be transmitted to one or more other communication devices via at least one radio transmitter 2902, and can further control at least one receive signal processor 2910 to process SIB, SL-UEInfo, and / or RRC-Reconfig messages received from one or more other communication devices via at least one radio receiver 2904. The at least one transmit signal generator 2908 and the at least one receive signal processor 2910 can be independent modules of the communication device 2900 that communicate with at least one controller 2906 for the functions described above, as shown in Figure 29. Alternatively, the at least one transmit signal generator 2908 and the at least one receive signal processor 2910 can be included in at least one controller 2906. It will be understood by those skilled in the art that the arrangement of these functional modules is flexible and may vary according to actual needs and / or requirements. Data processing devices, memory devices, and other related control devices can be provided on a suitable circuit board and / or chipset. In various embodiments, at least one wireless transmitter 2902, at least one wireless receiver 2904, and at least one antenna 2912 can be controlled by at least one controller 2906 during operation.

[0108] In the embodiment shown in Figure 29, at least one wireless receiver 2904, together with at least one received signal processor 2910, forms the receiver of the communication device 2900. The receiver of the communication device 2900 provides the necessary functions to facilitate the implementation of CORESET#0 for the RedCap device during operation.

[0109] The communication device 2900 provides the necessary functions to facilitate the implementation of CORESET#0 for RedCap devices during operation. For example, the communication device 2900 can be a communication device, and the wireless receiver 2904 can, during operation, receive a physical downlink control channel (PDCCH) on Control Resource Set 0 (CORESET#0), where time and frequency resources are defined based on the bandwidth settings of the capacity-reduced user equipment (RedCap UE), and can also receive a System Information Block Type 1 (SIB1) physical downlink shared channel (PDSCH) scheduled based on CORESET#0. Circuit 2914 can, during operation, determine control information and parameters from the PDCCH on CORESET#0 for reading SIB1 for initial access, handover, or beam fault recovery.

[0110] Circuit 2914 can be further configured to discard or ignore control information on CORESET#0 if CORESET#0 has a bandwidth greater than the bandwidth of communication device 2900.

[0111] CORESET#0 for RedCap UE may be a subset of the entries in Tables 13.1 to 13.10 of Non-Patent Literature 7, or a subset of physical resources such as control channel elements (CCEs) or physical resource blocks (PRBs) of Rel-15 CORESET#0.

[0112] CORESET#0 can be a subset of Rel-15 CORESET#0, and only these subsets are available for the purpose of being configured for all types of UEs including standard (non-RedCap) UEs and RedCap UEs within the relevant network.

[0113] CORESET#0 can be Rel-15 CORESET#0 divided into m equal or unequal subsets where m≧1, and each subset has a bandwidth smaller than the bandwidth of the RedCap UE. Each subset can correspond to a subset of the entries in Tables 13.1 to 13.10 of Non-Patent Document 7, or can correspond to a subset of physical resources such as control channel elements (CCEs) or physical resource blocks (PRBs) of Rel-15 CORESET#0. Each subset can be mapped to each of m consecutive slots. The upper limit of m can depend on the UE's capabilities, consideration of channel delay / estimation values, or the periodicity of SSB. The subsets can be mapped to m consecutive slots such that the i-th subset among the subsets is mapped to slot n - i (0≦i<m), and slot n can be the PDCCH monitoring opportunity (slot or symbol) of Rel-15 CORESET#0 or the PDCCH monitoring opportunity set for the RedCap UE. The upper limit of m can depend on the UE's capabilities, consideration of channel delay / estimation values, or the periodicity of SSB.

[0114] CORESET#0 can be Rel-15 CORESET#0 divided into m equal or unequal subsets where m≧1, and each subset has a bandwidth smaller than the bandwidth of the RedCap UE. Rel-15 CORESET#0 is mapped to the first slot, and each subset is mapped to each of m - 1 consecutive slots different from the first slot. The upper limit of m can depend on the UE's capabilities, consideration of channel delay / estimation values, or the periodicity of SSB.

[0115] CORESET #0 can be a Rel-15 CORESET #0 that is divided into m equal or unequal subsets such that m ≥ 1, and each subset has a bandwidth smaller than the bandwidth of the RedCap UE. The Rel-15 CORESET #0 is mapped to slot n. The i-th subset is mapped to the corresponding slot k - i, where k is a predefined value and 0 ≤ i < m. The upper limit of m can depend on the UE's capabilities, consideration of channel delay / estimation values, or the periodicity of the SSB.

[0116] CORESET #0 can be a Rel-15 CORESET #0, and the portion of the Rel-15 CORESET #0 outside the bandwidth of the RedCap UE is divided into q equal or unequal subsets such that q ≥ 1, and each subset has a bandwidth smaller than the bandwidth of the RedCap UE. The Rel-15 CORESET #0 is mapped to the first slot, and each subset of the q equal or unequal subsets is copied and mapped within the bandwidth of the RedCap UE in each of q consecutive slots different from the first slot. The upper limit of q can depend on the UE's capabilities, consideration of channel delay / estimation, or the periodicity of the SSB.

[0117] CORESET #0 can be a Rel-15 CORESET #0, and the portion of the Rel-15 CORESET #0 outside the bandwidth of the RedCap UE is divided into q equal or unequal subsets such that q ≥ 1, and each subset has a bandwidth smaller than the bandwidth of the RedCap UE. The Rel-15 CORESET #0 is mapped to the first slot, and in each of q consecutive slots different from the first slot, only the portion of the mapping of CORESET #0 that is inside the BW and can be monitored by the RedCap UE is replaced by a subset of the q equal or unequal subsets of CORESET #0. The upper limit of q can depend on the UE's capabilities, consideration of channel delay / estimation values, or the periodicity of the SSB.

[0118] Using information indicating Rel-15 CORESET#0 and PDCCH monitoring opportunities for standard UEs, CORESET#0 for RedCap UEs can be indicated, and this information includes existing entries in the MIB's ControlResourceSetZero IE and SearchSpaceZero IE.

[0119] Information indicating Rel-15 CORESET#0 and PDCCH monitoring opportunities for standard (non-RedCap) UEs and information indicating CORESET#0 and PDCCH monitoring opportunities for RedCap UEs can be configured to be independent of each other, and the radio receiver 2904 is configured to receive both information, and the circuit 2914 is configured to determine control information and parameters for reading SIB1 based on the indicated information for standard UEs when the communication device is a standard UE, and based on the indicated information for RedCap UEs when the communication device is a RedCap UE.

[0120] Information indicating Rel-15 CORESET#0 for a standard (non-RedCap) UE may be configured to be interpreted differently for a RedCap UE so that this information indicates the physical resources of CORESET#0 for a RedCap UE, which may be the same as or different from the physical resources of CORESET#0 for a standard UE, and the radio receiver 2904 is configured to receive this information. Based on this information, the circuit 2914 is configured to obtain control information and parameters for reading SIB1 from Rel-15 CORESET#0 for a standard UE if the communication device is a standard UE, or from CORESET#0 for a RedCap UE if the communication device is a RedCap UE.

[0121] Information indicating Rel-15 CORESET#0 for a standard (non-RedCap) UE may be configured to be interpreted differently for a RedCap UE, such that this information indicates physical resources for CORESET#0 for a RedCap UE which may differ from the physical resources for CORESET#0 of a standard UE, and indicates monitoring opportunities for a RedCap UE which differ from monitoring opportunities for a standard UE. The radio receiver 2904 is configured to receive this information. Based on this information, the circuit 2914 is configured to obtain control information and parameters for reading SIB1 at the corresponding monitoring opportunity, from Rel-15 CORESET#0 for a standard UE if the communication device is a standard UE, or from CORESET#0 for a RedCap UE if the communication device is a RedCap UE.

[0122] Information indicating Rel-15 CORESET#0 for a standard (non-RedCap) UE may be configured to be interpreted differently for a RedCap UE, such that this information indicates physical resources for a RedCap UE CORESET#0 which may differ from the physical resources for a standard UE's CORESET#0, and indicates one or more repetitions of CORESET#0, which may signal to the RedCap UE implicitly through (pre-)established rules or explicitly through higher-layer signaling, and the receiver is configured to receive this information, and based on this information, circuit 2914 is configured to obtain control information and parameters for reading SIB1 from Rel-15 CORESET#0 for a standard UE if the communication device is a standard UE, or from CORESET#0 for a RedCap UE if the communication device is a RedCap UE.

[0123] A related gNB may be configured to transmit, within the same beam, a Rel-15 CORESET#0 for a standard UE specified in SSBx, and a CORESET#0 for a RedCap UE specified in the SSB at index x and the SSB at index y, where the CORESET#0 specified in the SSB at index y is a repetition of the CORESET#0 in the SSB at index x, and so a standard UE detects SSBx and obtains the Rel-CORESET#0, and a RedCap UE detects the SSB at index x and the SSB at index y and obtains the CORESET#0 for the RedCap UE, with one or more repetitions signaled implicitly through (pre-)established rules or explicitly by upper-layer signaling.

[0124] CORESET#0 for RedCap UE can be pre-configured by the application layer. Serving cells (Pcell / PSCell / Scell) that only have Rel-15 / 16 capabilities may not support RedCap UE, and if the communication device is a RedCap UE, it may be necessary to signal a message such as "This cell does not support RedCap UE" in MIB / SIB1 so that the communication device 2900 can discard or ignore these cells, or a new physical-layer cell identity (PCID) range can be used for RedCap UE. RedCap UE can support bandwidth at least equal to the maximum bandwidth of CORESET#0 defined for Rel-15 / 16, and Rel-15 CORESET#0 can be used for the purpose of configuring all types of non-RedCap and RedCap UE. The physical resources of CORESET#0 can be defined based on a minimum bandwidth setting associated with one or more UEs within a set of standard (non-RedCap) UEs and RedCap UEs in a serving cell, and the UEs are configured to perform blind decoding on PDCCH candidates in a search space communicated by CORESET#0 to acquire all control information across one or more consecutive slots, depending on the bandwidth of CORESET#0, the physical resource mapping scheme, or the monitoring opportunity.

[0125] The communication device 2900, in operation, provides the necessary functions to facilitate the implementation of CORESET#0 for RedCap devices. For example, the communication device 2900 may be a base station or a gNB, and the circuit 2914, in operation, can set up Control Resource Set 0 (CORESET#0), in which time and frequency resources are defined based on the minimum bandwidth setting associated with one or more UEs in a set of standard (non-RedCap) UEs and RedCap UEs; generate a Physical Downlink Control Channel (PDCCH) on CORESET#0; and schedule a System Information Block Type 1 (SIB1) Physical Downlink Shared Channel (PDSCH) based on CORESET#0. The radio transmitter 2902, in operation, can transmit the PDCCH and SIB1 PDSCH on CORESET#0 to the communication device.

[0126] As described above, embodiments of this disclosure provide advanced communication methods and communication devices that enable the implementation of CORESET#0 for RedCap devices.

[0127] This disclosure can be implemented by software, by hardware, or by software working in conjunction with hardware. Each functional block used in the description of each embodiment above can be implemented in whole or in part by an LSI such as an integrated circuit, and each process described in each embodiment can be controlled in whole or in part by the same LSI or combination of LSIs. An LSI can be formed individually as a chip, or it can be formed as a single chip containing some or all of the functional blocks. An LSI can include data input / output units coupled to itself. Depending on the degree of integration, an LSI is also called an IC, a system LSI, a super LSI, or an ultra LSI. However, the technology for implementing an integrated circuit is not limited to LSIs and can be implemented using dedicated circuits, general-purpose processors, or dedicated processors. Furthermore, an FPGA (Field-Programmable Gate Array), which can be programmed after the manufacture of the LSI, or a reconfigurable processor, which can reconfigure the connections and settings of circuit cells located inside the LSI, can also be used. This disclosure can be implemented as a digital process or an analog process. If LSIs are replaced by future integrated circuit technologies as a result of advancements in semiconductor technology or other derivative technologies, functional blocks can be integrated using those future integrated circuit technologies. Biotechnology can also be applied.

[0128] This disclosure can be implemented by any type of device or system having communication capabilities (referred to as a communication device).

[0129] A communication device may comprise a transceiver and a processing / control circuit. The transceiver may comprise a receiver and a transmitter, and / or may function as both a receiver and a transmitter. A transceiver acting as both a transmitter and a receiver may include an RF (radio frequency) module, including an amplifier, an RF modulator / demodulator, etc., and one or more antennas.

[0130] Some non-exclusive examples of such communication devices include telephones (e.g., mobile phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, notebooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smartwatches, tracking devices), game consoles, e-readers, telemedicine / telemedicine devices, vehicles providing communication capabilities (e.g., automobiles, airplanes, ships), and various combinations thereof.

[0131] Communication devices are not limited to portable or mobile devices, but may include any type of non-portable or fixed device, device, or system, such as smart home devices (e.g., appliances, lighting, smart meters, control panels), vending machines, and any other "things" in the "Internet of Things (IoT)" network.

[0132] Communication may include steps such as exchanging data through cellular systems, wireless LAN systems, satellite systems, and others, and various combinations thereof.

[0133] A communication device may include devices such as controllers and sensors coupled to a communication device that performs the communication functions described in this disclosure. For example, a communication device may include a controller or sensor that generates control signals or data signals used by the communication device that performs the communication functions of the communication device.

[0134] Communication equipment may further include base stations, access points, and any other devices, devices, or systems that communicate with or control infrastructure equipment, such as the devices in the non-limiting examples above.

[0135] Those skilled in the art will understand that the disclosures shown in particular embodiments can be modified and / or changed in numerous ways without departing from the broadly described spirit or scope of the disclosure. Therefore, the embodiments described herein should be considered in all respects to be illustrative and not limiting to the invention.

Claims

1. A communication device, A receiver that receives a physical downlink control channel (PDCCH) on control resource set 0 (CORESET #0), where time resources and frequency resources are defined based on the bandwidth settings of a capacity-reduced user device (RedCap UE), and a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) that is scheduled based on CORESET #0, A circuit for determining control information and parameters for reading SIB1 for initial access, handover, or beam fault recovery from the PDCCH on CORESET#0, Equipped with, Non-RedCap UE supports the first bandwidth, The RedCap UE supports a second bandwidth, The first bandwidth is used to set the non-RedCap UE and is greater than the bandwidth of CORESET#0. The second bandwidth is used to configure the RedCap UE and is smaller than the bandwidth of CORESET#0. The number of first physical resource blocks (PRBs) corresponding to the frequency resource is unevenly divided into a second number of PRBs and a third number of PRBs. The bandwidth of the second subset of PRB numbers and the bandwidth of the third subset of PRB numbers are both less than or equal to the second bandwidth. Communication device.

2. The circuit is configured to discard or ignore control information on CORESET#0 when CORESET#0 has a bandwidth greater than the bandwidth of the communication device. The communication device according to claim 1.

3. Rel-15 CORESET#0 is set for the non-RedCap UE, and when CORESET#0 is a subset of Rel-15 CORESET#0, the subset is available for all types of UE, including the non-RedCap UE and the RedCap UE. The communication device according to claim 1.

4. The CORESET#0 is a Rel-15 CORESET#0 divided into m equal or unequal subsets such that m is a positive integer and m > 1, and each subset has a bandwidth smaller than the bandwidth of the RedCap UE. The communication device according to claim 1.

5. The upper limit of m depends on the capabilities of the UE, the consideration of channel delay / estimate, or the periodicity of the SSB. The communication device according to claim 3 or claim 4.

6. Information indicating Rel-15 CORESET #0 and PDCCH monitoring opportunities for the non-RedCap UE is used to indicate the CORESET #0 for the RedCap UE. The communication device according to claim 1.

7. The information indicating Rel-15 CORESET #0 and PDCCH monitoring opportunities for the non-RedCap UE and the information indicating CORESET #0 and PDCCH monitoring opportunities for the RedCap UE are configured to be independent of each other, the receiver is configured to receive both types of information, and the circuit is configured to determine control information and parameters for reading the SIB1 based on the indicated information for the non-RedCap UE if the communication device is the non-RedCap UE, and based on the indicated information for the RedCap UE if the communication device is the RedCap UE. The communication device according to claim 1.

8. CORESET#0 for the RedCap UE is pre-configured by the application layer. The communication device according to claim 1.

9. Cells (Pcell / PSCell / Scell) that only have Rel-15 / 16 capability cannot support the RedCap UE, and the communication device signals the message "This cell does not support RedCap UE" in MIB / SIB1 in order to discard or ignore these cells when the communication device is the RedCap UE, or a new physical layer cell identifier (PCID) range is used for the RedCap UE. The communication device according to claim 1.

10. The physical resources of CORESET#0 are defined based on a minimum bandwidth setting associated with one or more UEs in the set of non-RedCap UEs and RedCap UEs, and the UEs are configured to perform blind decoding on PDCCH candidates in a search space communicated by CORESET#0 in order to acquire all control information across one or more consecutive slots, depending on the bandwidth of CORESET#0, the physical resource mapping scheme, or the monitoring opportunity. The communication device according to claim 1.

11. It is a base station, A circuit that sets a control resource set 0 (CORESET #0) in which time resources and frequency resources are defined based on the bandwidth setting of a capacity-reducing user device (RedCap UE), generates a physical downlink control channel (PDCCH) on CORESET #0, and schedules a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) based on CORESET #0, A transmitter that transmits the PDCCH and the SIB1 PDSCH on CORESET#0 to a communication device, Equipped with, Non-RedCap UE supports the first bandwidth, The RedCap UE supports a second bandwidth, The first bandwidth is used to set the non-RedCap UE and is greater than the bandwidth of CORESET#0. The second bandwidth is used to configure the RedCap UE and is smaller than the bandwidth of CORESET#0. The number of first physical resource blocks (PRBs) corresponding to the frequency resource is unevenly divided into a second number of PRBs and a third number of PRBs. The bandwidth of the second subset of PRB numbers and the bandwidth of the third subset of PRB numbers are both less than or equal to the second bandwidth. Base station.

12. A method of communication, The steps include receiving a CORESET#0 in which time resources and frequency resources are defined based on the bandwidth settings of a capacity-reducing user device (RedCap UE), The steps include receiving a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) scheduled based on the CORESET #0, The steps include determining control information and parameters for reading SIB1 for initial access, handover, or beam fault recovery from the PDCCH on CORESET#0, Includes, Non-RedCap UE supports the first bandwidth, The RedCap UE supports a second bandwidth, The first bandwidth is used to set the non-RedCap UE and is greater than the bandwidth of CORESET#0. The second bandwidth is used to configure the RedCap UE and is smaller than the bandwidth of CORESET#0. The number of first physical resource blocks (PRBs) corresponding to the frequency resource is unevenly divided into a second number of PRBs and a third number of PRBs. The bandwidth of the second subset of PRB numbers and the bandwidth of the third subset of PRB numbers are both less than or equal to the second bandwidth. Communication method.

13. A method of communication, The steps include: setting up a control resource set 0 (CORESET #0) in which time resources and frequency resources are defined based on the bandwidth settings of a capacity-reducing user device (RedCap UE); generating a physical downlink control channel (PDCCH) on CORESET #0; and scheduling a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) based on CORESET #0; The steps include transmitting the PDCCH and SIB1 PDSCH on CORESET#0 to the communication device, Includes, Non-RedCap UE supports the first bandwidth, The RedCap UE supports a second bandwidth, The first bandwidth is used to set the non-RedCap UE and is greater than the bandwidth of CORESET#0. The second bandwidth is used to configure the RedCap UE and is smaller than the bandwidth of CORESET#0. The number of first physical resource blocks (PRBs) corresponding to the frequency resource is unevenly divided into a second number of PRBs and a third number of PRBs. The bandwidth of the second subset of PRB numbers and the bandwidth of the third subset of PRB numbers are both less than or equal to the second bandwidth. Communication method.

14. An integrated circuit that controls the processing of a communication device, wherein the processing is The process of receiving CORESET#0, which defines time resources and frequency resources based on the bandwidth settings of a capacity-reduced user device (RedCap UE), The steps include receiving a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) scheduled based on the CORESET #0, A process for determining control information and parameters for reading SIB1 for initial access, handover, or beam fault recovery from the PDCCH on CORESET#0, Includes, Non-RedCap UE supports the first bandwidth, The RedCap UE supports a second bandwidth, The first bandwidth is used to set the non-RedCap UE and is greater than the bandwidth of CORESET#0. The second bandwidth is used to configure the RedCap UE and is smaller than the bandwidth of CORESET#0. The number of first physical resource blocks (PRBs) corresponding to the frequency resource is unevenly divided into a second number of PRBs and a third number of PRBs. The bandwidth of the second subset of PRB numbers and the bandwidth of the third subset of PRB numbers are both less than or equal to the second bandwidth. Integrated circuit.

15. An integrated circuit that controls the processing of a base station, wherein the processing is The process involves setting a control resource set 0 (CORESET #0) where time resources and frequency resources are defined based on the bandwidth settings of a capacity-reducing user device (RedCap UE), generating a physical downlink control channel (PDCCH) on CORESET #0, and scheduling a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) based on CORESET #0. The process of transmitting the PDCCH and SIB1 PDSCH on CORESET#0 to the communication device, Includes, Non-RedCap UE supports the first bandwidth, The RedCap UE supports a second bandwidth, The first bandwidth is used to set the non-RedCap UE and is greater than the bandwidth of CCORESET#0. The second bandwidth is used to configure the RedCap UE and is smaller than the bandwidth of CORESET#0. The number of first physical resource blocks (PRBs) corresponding to the frequency resource is unevenly divided into a second number of PRBs and a third number of PRBs. The bandwidth of the second subset of PRB numbers and the bandwidth of the third subset of PRB numbers are both less than or equal to the second bandwidth. Integrated circuit.

Images