Control resource set zero for new radio equipment with reduced capabilities

Abstract

The present disclosure provides a communication device and a communication method for implementing a control resource set zero (CORESET#0) for a reduced capability (RedCap) new radio device. The communication device includes a communication device comprising: a receiver that receives a physical downlink control channel (PDCCH) on the control resource set zero (CORESET#0), wherein the time and frequency resources of the control resource set zero are defined based on the bandwidth configuration of the reduced capability user equipment (RedCap UE), and receives a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) scheduled based on CORESET#0; and a circuit that determines control information and parameters from the PDCCH on CORESET#0 to read the SIB1 for initial access, handover, or beam failure recovery.

Description

Technical Field

[0001] The following disclosure relates to a communication apparatus and a communication method for implementing a control resource set zero (CORESET#0) of a Reduced Capability (RedCap) device, specifically CORESET#0 of a RedCap New Radio (NR) device. Background Art

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

[0003] A key goal of 5G is to enable connected industry. 5G connectivity can serve as a catalyst for the next wave of industrial transformation and digitalization, increasing flexibility, enhancing productivity and efficiency, reducing maintenance costs, and improving operational safety. Devices in this environment can include, for example, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, actuators, and more. Connecting these sensors and actuators to 5G networks is desirable.

[0004] 5G connectivity can also serve as a catalyst for the next wave of smart city innovation. For example, small devices, including wearables such as smart watches, rings, e-health devices, medical monitoring devices, and reduced capability (RedCap) devices, will benefit from improved 5G connectivity.

[0005] However, there has been no discussion of CORESET#0 for RedCap devices so far.

[0006] Therefore, there is a need for a communication device and method that can solve the above problems. Furthermore, other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and this background of the disclosure. Summary of the Invention

[0007] One non-limiting and exemplary embodiment facilitates implementing CORESET#0 of a RedCap device in 5G NR based communications.

[0008] In one aspect, the technology disclosed herein provides a communication device. For example, the communication device can be a subscriber UE, which can be a normal (non-RedCap or Rel-15 / 16 / 17 or higher) UE, a RedCap UE, or other similar type of UE. The communication device includes: a receiver that receives a physical downlink control channel (PDCCH) on a control resource set zero (CORESET#0), the time and frequency resources of which are defined based on the bandwidth configuration of a reduced-capability user equipment (RedCap UE), and receives a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) scheduled based on CORESET#0; and a circuit that determines control information and parameters from the PDCCH on CORESET#0 to read SIB1, message 2 (Msg2) PDSCH, and message 4 (Msg4) PDSCH for initial access, handover, or beam failure recovery.

[0009] In another aspect, the technology disclosed herein provides a communication device. For example, the communication device can be a base station or gNodeB (gNB), comprising: a circuit that configures a control resource set zero (CORESET#0), wherein time and frequency resources of the control resource set zero are defined based on a minimum bandwidth configuration associated with one or more UEs in a set of normal (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 transmits the PDCCH, SIB1 PDSCH, Msg2 PDSCH, and Msg4 PDSCH on CORESET#0 to the communication device.

[0010] In another aspect, the technology disclosed herein provides a communication method. The communication method includes receiving CORESET#0, where time and frequency resources of CORESET#0 are defined based on a minimum bandwidth configuration associated with one or more UEs in a set of normal (non-RedCap) UEs and RedCap UEs, receiving a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) scheduled based on CORESET#0; and determining control information and parameters from a PDCCH on CORESET#0 to read SIB1, Msg2 PDSCH, and Msg4 PDSCH for initial access, handover, or beam failure recovery.

[0011] It should be noted that the general or specific embodiments may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any selective combination thereof.

[0012] Other benefits and advantages of the disclosed embodiments will become apparent from the description and drawings. Benefits and / or advantages may be achieved individually through various embodiments and features of the description and drawings, and it is not necessary to provide all of these embodiments and features in order to achieve one or more such benefits and / or advantages. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Embodiments of the present disclosure will be better understood and apparent to those skilled in the art from the following written description, which is given by way of example only, taken in conjunction with the accompanying drawings, in which:

[0014] Figure 1 An exemplary architecture of a 3GPP NR system is shown.

[0015] Figure 2 Figure 2 is a schematic diagram showing the functional division between NG-RAN and 5GC.

[0016] Figure 3 It is a timing diagram of the RRC connection establishment / reconfiguration process.

[0017] Figure 4 is a schematic diagram illustrating usage scenarios of enhanced mobile broadband (eMBB), massive machine type communication (mMTC), and ultra-reliable low latency communication (URLLC).

[0018] Figure 5 is a block diagram illustrating an exemplary 5G system architecture for a non-roaming scenario.

[0019] Figure 6 An example of bandwidth comparison between a Rel-15 CORESET with index 0 (CORESET#0) and a RedCap UE is shown.

[0020] Figure 7 An example of bandwidth comparison between a Rel-15 CORESET with index 0 (CORESET#0) and CORESET#0 of a RedCap UE according to various embodiments is shown.

[0021] Figure 8A A table showing a subset of Rel-15 CORESET#0 of RedCap UE when the bandwidth of RedCap UE is 5 MHz and the {synchronization signal block, physical downlink control channel} subcarrier spacing ({synchronization signal block (SSB), PDCCH} SCS) is {15, 15} kHz according to embodiment 1 is shown.

[0022] Figure 8BA table showing a subset of Rel-15 CORESET#0 of RedCap UE when the bandwidth of RedCap UE is 10 MHz and {SSB, PDCCH}SCS is {15, 15} kHz according to embodiment 1 is shown.

[0023] Figure 9 A schematic diagram illustrating transmission of a subset of Rel-15 CORESET#0 according to embodiment 2 is shown.

[0024] Figure 10 An example of equal partitioning of Rel-15 CORESET#0 according to Embodiment 2 is shown.

[0025] Figure 11 An example of unequal partitioning of Rel-15 CORESET#0 according to Embodiment 2 is shown.

[0026] Figure 12 An example of equal partitioning of Rel-15 CORESET#0 according to a variation of Embodiment 2 is shown.

[0027] Figure 13 An example of unequal partitioning of Rel-15 CORESET#0 according to a variation of Embodiment 2 is shown.

[0028] Figure 14 An example of transmission of Rel-15 CORESET#0 and its subset(s) according to embodiment 3 is shown.

[0029] Figure 15 An example of transmission of Rel-15 CORESET#0 and its subset(s) according to a variation of Embodiment 3 is shown.

[0030] Figure 16 An example of how a RedCap UE receives the transmission rules of Rel-15 CORESET#0 according to a variation of Embodiment 3 is shown.

[0031] Figure 17 An example of Rel-15 CORESET#0 and CORESET#0 of RedCap UE according to embodiment 4 is shown.

[0032] Figure 18 An example of Rel-15 CORESET#0 signaling for normal UE and RedCap UE according to embodiment 5A is shown.

[0033] Figure 19An example of a table of a set of resource blocks and time slot symbols of a CORESET of a type 0-PDCCH search space set including normal UEs and RedCap UEs when the frequency band is {15,15}kHz for a minimum channel bandwidth of 5MHz or 10MHz in {search space / physical broadcast channel block, PDCCH}SCS ({SS / PBCH block, PDCCH}SCS) according to embodiment 5A is shown.

[0034] Figure 20 An example of a separate table of sets of resource blocks and slot symbols of a CORESET including a type 0-PDCCH search space set for RedCap UEs when the frequency band is {15,15}kHz for {SS / PBCH block, PDCCH}SCS with a minimum channel bandwidth of 5MHz according to embodiment 5A is shown.

[0035] Figure 21 An example of a table of sets of resource blocks and time slot symbols of a CORESET of a type 0-PDCCH search space set including normal UEs and RedCap UEs when the frequency band is {15,15}kHz for a minimum channel bandwidth of 5MHz or 10MHz for {SS / PBCH block, PDCCH}SCS according to a variation of embodiment 5A is shown.

[0036] Figure 22 An example of reinterpretation of the Rel-15 CORESET#0 monitoring opportunity for normal UEs and RedCap UEs according to embodiment 5B is shown.

[0037] Figure 23 A table showing parameters for reinterpretation of PDCCH monitoring occasions for Type 0 - PDCCH CSS Set - SSB and CORESET multiplexing mode 1 and frequency range 1 (FR1) according to embodiment 5B is shown.

[0038] Figure 24 Illustration for reading Figure 23 An example of table details.

[0039] Figure 25 A diagram showing different monitoring occasions for Re-15 CORESET#0 of a normal UE and CORESET#0 of a RedCap UE according to embodiment 5B.

[0040] Figure 26A table illustrating the repetition and aggregation of resource blocks and slot symbols of a CORESET of a type 0-PDCCH search space set for a RedCap UE when {SS / PBCH block, PDCCH}SCS is {15,15}kHz for a frequency band with a minimum channel bandwidth of 5MHz or 10MHz according to embodiment 5C is shown.

[0041] Figure 27 A table including parameters of repetition and PDCCH monitoring occasions for Type 0 - PDCCH CSS Set - SS / PBCH Block and CORESET multiplexing mode 1 and FR1 according to embodiment 5C is shown.

[0042] Figure 28 A flow chart of a communication method for implementing CORESET#0 of a RedCap UE according to various embodiments is shown.

[0043] Figure 29 Schematic examples of communication devices of CORESET#0 that may be used to implement RedCap UE according to various embodiments are shown.

[0044] Those skilled in the art will appreciate that the elements in the drawings are illustrated for simplicity and clarity and are not necessarily drawn to scale. For example, the sizes of some elements in the diagrams, block diagrams, or flow charts may be exaggerated relative to other elements to help improve understanding of the present embodiment. DETAILED DESCRIPTION

[0045] Some embodiments of the present disclosure will be described by way of example only with reference to the accompanying drawings, in which like reference numerals and characters refer to like elements or equivalents.

[0046] 5G NR system architecture and protocol stack

[0047] 3GPP has been working on the next version of fifth-generation cellular technology, or 5G, including the development of new radio access technology (NR) operating in frequencies up to 100 GHz. The first version of the 5G standard was completed in late 2017, allowing for trials and commercial deployments of smartphones compliant with the 5G NR standard.

[0048] The overall system architecture adopts, among other things, the NG-RAN (Next Generation Radio Access Network) including gNBs, providing NG-Radio Access user plane (SDAP / PDCP / RLC / MAC / PHY) and control plane (RRC) protocol terminations towards the UE. The gNBs are connected to each other via Xn interfaces. The gNBs are also 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 implements the AMF) via the NG-C interface, and to the UPF (User Plane Function) (e.g., a specific core entity that implements the UPF) via the NG-U interface. Figure 1 The NG-RAN architecture is shown in (see, for example, 3GPP TS 38.300 v15.6.0 Section 4).

[0049] The NR user plane protocol stack (see, for example, 3GPP TS 38.300, Section 4.4.1) includes the PDCP (Packet Data Convergence Protocol, see Section 6.4 of TS 38.300), the RLC (Radio Link Control, see Section 6.3 of TS 38.300), and the MAC (Medium Access Control, see Section 6.2 of TS 38.300) sublayers, which terminate on the network side in the gNB. Furthermore, a new Access Stratum (AS) sublayer (SDAP, Service Data Adaptation Protocol) is introduced above PDCP (see, for example, 3GPP TS 38.300, Subclause 6.5). A control plane protocol stack is also defined for NR (see, for example, TS 38.300, Section 4.4.2). An overview of Layer 2 functionality is provided in Subclause 6 of TS 38.300. The functions of the PDCP, RLC, and MAC sublayers are listed in Sections 6.4, 6.3, and 6.2 of TS 38.300, respectively. The functions of the RRC layer are listed in subclause 7 of TS 38.300.

[0050] For example, medium access control handles logical channel multiplexing, as well as scheduling and scheduling-related functions, including the handling of different numerologies.

[0051] The physical layer (PHY) is responsible for, for example, coding, PHY HARQ processing, modulation, multi-antenna processing, and mapping of signals to appropriate physical time-frequency resources. It also handles the mapping of transport channels to physical channels. The physical layer provides services to the MAC layer in the form of transport channels. A physical channel corresponds to a set of time-frequency resources used for transmission of a specific transport channel, and each transport channel is mapped to a corresponding physical channel. For example, physical channels are PRACH (Physical Random Access Channel), PUSCH (Physical Uplink Shared Channel), and PUCCH (Physical Uplink Control Channel) for uplink, and PDSCH (Physical Downlink Shared Channel), PDCCH (Physical Downlink Control Channel), and PBCH (Physical Broadcast Channel) for downlink.

[0052] NR use cases / deployment scenarios may include enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), massive machine type communications (mMTC), which have different requirements in terms of data rate, latency and coverage. For example, eMBB is expected to support peak data rates (downlink 20Gbps and uplink 10Gbps) and user experience data rates that are three times higher than those provided by IMT-Advanced. On the other hand, in the case of URLLC, there is a demand for ultra-low latency (user plane latency of 0.5ms for UL and DL respectively) and high reliability (1-10 times within 1ms). -5 ) puts forward more stringent requirements. Finally, mMTC may preferably require high connection density (1,000,000 devices / km in urban environments) 2 ), wide coverage in harsh environments, and extremely long battery life (15 years) for low-cost devices.

[0053] Therefore, an OFDM parameter set (e.g., subcarrier spacing, OFDM symbol duration, cyclic prefix (CP) duration, number of symbols per scheduling interval) that is suitable for one use case may not be suitable for another use case. For example, low latency services may preferably require shorter symbol duration (and therefore larger subcarrier spacing) and / or fewer symbols per scheduling interval (also called TTI) compared to mMTC services. In addition, deployment scenarios with large channel delay spread may preferably require longer CP duration compared to scenarios with short delay spread. The subcarrier spacing should be optimized accordingly to retain similar CP overhead. NR can support more than one subcarrier spacing value. Accordingly, subcarrier spacings of 15kHz, 30kHz, 60kHz, ... are currently under consideration. Symbol duration T u And the subcarrier spacing Δf is calculated by the formula Δf=1 / T uIn a similar manner as in the LTE system, the term "resource element" may be used to denote a minimum resource unit consisting of one subcarrier of the length of one OFDM / SC-FDMA symbol.

[0054] In the new radio system 5G-NR, for each numerology set and carrier, a resource grid of subcarriers and OFDM symbols is defined for uplink and downlink, respectively. Each element in the resource grid is called a resource element and is identified based on a frequency index in the frequency domain and a symbol position in the time domain (see 3GPP TS 38.211 v15.6.0).

[0055] (Control Signal)

[0056] In the present disclosure, the downlink control signal (information) related to the present disclosure may be a signal (information) transmitted through the PDCCH of the physical layer, or may be a signal (information) transmitted through the MAC control element (CE) or RRC of the higher layer. The downlink control signal may be a predefined signal (information).

[0057] The uplink control signal (information) related to the present disclosure may be a signal (information) transmitted via the PUCCH of the physical layer, or may be a signal (information) transmitted via the MAC CE or RRC of a higher layer. In addition, the uplink control signal may be a predefined signal (information). The uplink control signal may be replaced with uplink control information (UCI), first-stage sidelink control information (SCI), or second-stage SCI.

[0058] (Base Station)

[0059] In the present 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 sidelink communications, a terminal may be employed instead of a base station. A base station may be a relay device that relays communications between a higher-level node and a terminal. A base station may also be a roadside unit.

[0060] (Uplink / Downlink / Sidelink)

[0061] The present disclosure may be applied to any one of uplink, downlink, and sidelink.

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

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

[0064] (Data channel / Control channel)

[0065] The present disclosure can be applied to any data channel and control channel. The channels in the present disclosure can be replaced with data channels including PDSCH, PUSCH and PSSCH and / or control channels including PDCCH, PUCCH, PBCH, PSCCH and PSBCH.

[0066] (Reference signal)

[0067] In the present disclosure, a reference signal is a signal known to both a base station and a mobile station, and each reference signal may be referred to as a reference signal (RS) or sometimes as a pilot signal. The reference signal may be any one of a DMRS, a channel state information-reference signal (CSI-RS), a tracking reference signal (TRS), a phase tracking reference signal (PTRS), a cell-specific reference signal (CRS), and a sounding reference signal (SRS).

[0068] (Time interval)

[0069] In the present disclosure, the time resource unit is not limited to one of a time slot and a symbol or a combination thereof, and may be a time resource unit such as a frame, a superframe, a subframe, a time slot, a time slot subslot, a microslot, or a time resource unit such as a symbol, an orthogonal frequency division multiplexing (OFDM) symbol, a single carrier frequency division multiplexing access (SC-FDMA) symbol, or other time resource units. The number of symbols included in a time slot is not limited to any number of symbols exemplified in the above (multiple) embodiments, and may be other numbers of symbols.

[0070] (frequency band)

[0071] The present disclosure may be applied to any of licensed and unlicensed frequency bands.

[0072] (communication)

[0073] The present disclosure can be applied to any of the communication between a base station and a terminal (Uu link communication), the communication between terminals (sidelink communication), and vehicle-to-everything (V2X) communication. The channels in the present disclosure can be replaced with PSCCH, PSSCH, physical sidelink feedback channel (PSFCH), PSBCH, PDCCH, PUCCH, PDSCH, PUSCH, and PBCH.

[0074] Furthermore, the present disclosure can be applied to any of terrestrial networks or networks other than terrestrial networks (NTN: non-terrestrial network) using satellites or high-altitude pseudo-satellites (HAPS). Furthermore, the present disclosure can be applied to networks with large cell sizes and terrestrial networks with large delays compared to symbol lengths or slot lengths (such as ultra-wideband transmission networks).

[0075] (Antenna port)

[0076] 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 and may sometimes refer to an array antenna formed by multiple antennas, for example. For example, there is no definition of how many physical antennas form an antenna port; instead, an antenna port is defined as the smallest unit through which a terminal can transmit a reference signal. An antenna port can also be defined as the smallest unit used for multiplication of precoding vector weights.

[0077] 5G NR functional division between NG-RAN and 5GC

[0078] Figure 2 The functional division between NG-RAN and 5GC is shown. The NG-RAN logical node is the gNB or ng-eNB. The 5GC has the logical nodes AMF, UPF, and SMF.

[0079] Specifically, gNB and ng-eNB host the following key functions:

[0080] - Functions for radio resource management, such as radio bearer control, radio admission control, connection mobility control, dynamic allocation of resources to UEs in uplink and downlink (scheduling);

[0081] -IP header compression, encryption and integrity protection of data;

[0082] - Select the AMF at UE attach when the route to the AMF cannot be determined from the information provided by the UE;

[0083] - Routing user plane data towards UPF(s);

[0084] - routing control plane information towards the AMF;

[0085] -Connection establishment and release;

[0086] - Scheduling and transmission of paging messages;

[0087] - Scheduling and transmission of system broadcast information (from AMF or OAM);

[0088] - Measurement and measurement reporting configuration for mobility and scheduling;

[0089] - Transport layer packet marking in uplink;

[0090] -Session management;

[0091] -Support network slicing;

[0092] -QoS flow management and mapping to data radio bearers;

[0093] -Support UE in RRC_INACTIVE state;

[0094] -NAS message distribution function;

[0095] - Radio access network sharing;

[0096] -Dual connectivity;

[0097] - Tight interworking between NR and E-UTRA.

[0098] The Access and Mobility Management Function (AMF) is responsible for the following main functions:

[0099] - Non-access stratum NAS signaling termination;

[0100] -NAS signaling security;

[0101] -Access layer AS security control;

[0102] -Inter-core network CN node signaling for mobility between 3GPP access networks;

[0103] - Idle mode UE reachability (including control and execution of paging retransmissions);

[0104] -Registration area management;

[0105] -Support intra-system and inter-system mobility;

[0106] -Access authentication;

[0107] - Access authorization, including checking roaming permissions;

[0108] - Mobility management control (subscription and policy);

[0109] -Support network slicing;

[0110] -Session Management Function SMF selection.

[0111] In addition, the user plane function UPF is responsible for the following main functions:

[0112] - Anchor point for intra-RAT / inter-RAT mobility (when applicable);

[0113] - External PDU session points for interconnection with data networks;

[0114] -Packet routing & forwarding;

[0115] - User plane part of packet inspection and policy rule enforcement;

[0116] -Business usage reports;

[0117] - Uplink classifier that supports routing traffic to the data network;

[0118] -Support branch points for multi-homed PDU sessions;

[0119] - QoS processing in the user plane, such as packet filtering, gating, and UL / DL rate enforcement;

[0120] - Uplink service verification (SDF to QoS flow mapping);

[0121] - Downlink packet buffering and downlink data notification triggering.

[0122] Finally, the session management function SMF is responsible for the following main functions:

[0123] -Session management;

[0124] -UE IP address allocation and management;

[0125] -Selection and control of UP function;

[0126] -Configure traffic steering at the User Plane Function (UPF) to route traffic to the correct destination;

[0127] -Control part of policy implementation and QoS;

[0128] - Downlink data notification.

[0129] RRC connection establishment and reconfiguration process

[0130] Figure 3This document shows some interactions between the UE, gNB, and AMF (5GC entity) in the context of the UE transitioning from RRC_IDLE to RRC_CONNECTED (see TS 38.300 v15.6.0). RRC is the higher-layer signaling protocol used for UE and gNB configuration. Specifically, the transition involves the AMF preparing UE context data (including, for example, PDU session context, security keys, UE radio capabilities, and UE security capabilities) and transmitting it to the gNB along with an INITIAL CONTEXT SETUP REQUEST. The gNB then activates AS security with the UE by sending a SecurityModeCommand message to the UE and the UE responding to the gNB with a SecurityModeComplete message. The gNB then performs reconfiguration to establish Signaling Radio Bearer 2 (SRB 2) and Data Radio Bearer (DRBs) by sending an RRCReconfiguration message to the UE and, in response, receiving an RRCReconfigurationComplete message from the UE. For signaling-only connections, steps related to RRCReconfiguration are skipped since SRB2 and DRB are not established. Finally, the gNB notifies the AMF that the setup procedure is complete with an INITIAL CONTEXT SETUP RESPONSE.

[0131] Therefore, the present disclosure provides an entity (e.g., AMF, SMF, etc.) of a 5th Generation Core (5GC), which includes a control circuit for establishing a next generation (NG) connection with a gNodeB, and a transmitter for sending an initial context setup message to the gNodeB via the NG connection to establish a signaling radio bearer between the gNodeB and a user equipment (UE). Specifically, the gNodeB sends radio resource control (RRC) signaling including a resource allocation configuration information element to the UE via the signaling radio bearer. The UE then performs uplink transmission or downlink reception based on the resource allocation configuration.

[0132] IMT usage scenarios in 2020 and beyond

[0133] Figure 4Some use cases for 5G NR are shown. Within the 3rd Generation Partnership Project New Radio (3GPP NR), three use cases are being considered that are envisioned to support a wide range of services and applications within IMT-2020. The specifications for enhanced mobile broadband (eMBB) Phase 1 have been finalized. In addition to further expanding eMBB support, current and future work will involve standardization of ultra-reliable low-latency communications (URLLC) and massive machine-type communications. Figure 4 Some examples of envisaged usage scenarios for IMT for 2020 and beyond are shown (see for example ITU-R M.2083 Figure 2 ).

[0134] URLLC use cases have stringent requirements on capabilities such as throughput, latency, and availability, and are envisioned as one of the enablers of future vertical applications such as wireless control of industrial manufacturing or production processes, remote medical surgery, distribution automation in smart grids, transportation safety, etc. The ultra-reliability of URLLC is to be supported by confirming technologies that meet the requirements set by TR38.913. For NR URLLC in Release 15, the key requirements include a target user plane delay of 0.5ms for UL (uplink) and a target user plane delay of 0.5ms for DL ​​(downlink). For a packet size of 32 bytes and a user plane delay of 1ms, the general URLLC requirement for one transmission of a packet is a BLER (block error rate) of 1E-5.

[0135] From a physical layer perspective, reliability can be improved in a number of possible ways. The current scope for improving reliability involves defining a separate CQI table for URLLC, a more compact downlink control information (DCI) format, repetition of the PDCCH, etc. However, as NR becomes more stable and developed (for NR URLLC key requirements), the scope for achieving ultra-reliability is likely to 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.

[0136] In addition, the technical enhancements targeted by NR URLLC are aimed at latency improvement and reliability improvement. The technical enhancements for latency improvement include configurable parameter sets, non-slot-based (mini-slot-based) scheduling with flexible mapping, ungranted (configured grant) uplink, slot-level repetition of data channels, and downlink pre-emption. Preemption means that the transmission for which resources have been allocated is stopped, and the allocated resources are used for another transmission that is requested later but has lower latency / higher priority requirements. Therefore, the authorized transmission is preempted by the later transmission. Preemption is applicable independently of the specific service type. For example, a transmission of service type A (URLLC) may be preempted by a transmission of service type B (such as eMBB). Technical enhancements for reliability improvement include a dedicated CQI / MCS table with a target BLER of 1E-5.

[0137] The mMTC (Massive Machine Type Communication) use case is characterized by a very large number of connected devices, often sending relatively small amounts of non-latency-sensitive data. Devices need to be low-cost and have very long battery life. From an NR perspective, utilizing very narrow bandwidth portions is a possible solution to save power and achieve long battery life from the UE's perspective.

[0138] As mentioned above, the scope of reliability in NR is expected to be even wider. A key requirement in all cases, but particularly essential for URLLC and mMTC, is high or ultra-reliability. From both a radio and network perspective, several mechanisms can be considered to improve reliability. Generally speaking, there are several key potential areas that can help improve reliability. These include compact control channel information, data / control channel repetition, and diversity in the frequency, time, and / or spatial domains. These areas apply to general reliability, regardless of the specific communication scenario.

[0139] For NR URLLC, further use cases with more stringent requirements have been identified, such as factory automation, transportation industry and power distribution. The more stringent requirements are higher reliability (up to 10 -6 level), higher availability, packet sizes of up to 256 bytes, time synchronization down to the order of a few μs (where this value can be 1 μs or a few μs, depending on the frequency range), and short latency on the order of 0.5 to 1 ms (specifically a target user plane latency of 0.5 ms, depending on the use case).

[0140] In addition, for NR URLLC, several technical enhancements from the physical layer perspective have been confirmed. Among them are PDCCH (Physical Downlink Control Channel) enhancements related to compact DCI, PDCCH repetition, and increased PDCCH monitoring. In addition, UCI (Uplink Control Information) enhancements are related to enhanced HARQ (Hybrid Automatic Repeat Request) and CSI feedback enhancements. PUSCH enhancements related to mini-slot level hopping and retransmission / repetition enhancements have also been confirmed. The term "mini-slot" refers to a transmission time interval (TTI) that includes a smaller number of symbols than a slot (a slot including 14 symbols).

[0141] QoS control

[0142] The 5G QoS (Quality of Service) model is based on QoS flows and supports QoS flows that require guaranteed bit rates (GBR QoS flows) and QoS flows that do not require guaranteed bit rates (non-GBR QoS flows). At the NAS level, QoS flows are therefore the finest granularity of QoS differentiation within a PDU session. QoS flows are identified within a PDU session by a QoS Flow ID (QFI) carried in the encapsulation header on the NG-U interface.

[0143] For each UE, the 5GC establishes one or more PDU Sessions. For each UE, the NG-RAN establishes at least one Data Radio Bearer (DRB) along with the PDU Session and may subsequently configure additional DRBs for the QoS Flow(s) of that PDU Session (when to do so depends on the NG-RAN), e.g. as described above with reference to Figure 3 As shown in Figure 2, NG-RAN maps packets belonging to different PDU sessions to different DRBs. NAS-level packet filters in the UE and 5GC associate UL and DL packets with QoS flows, while AS-level mapping rules in the UE and NG-RAN associate UL and DL QoS flows with DRBs.

[0144] Figure 5 The 5G NR non-roaming reference architecture is shown (see TS 23.501 v16.0.0 section 4.23). Figure 4 The application function (AF) (e.g., an external application server hosting 5G services) described in the example interacts with the 3GPP core network to provide services, such as supporting application impact on service routing, accessing the network exposure function (NEF), or interacting with the policy framework (see Policy Control Function PCF) for policy control, such as QoS control. Based on operator deployment, application functions that are considered to be trusted by the operator may be allowed to interact directly with related network functions. Application functions that the operator does not allow direct access to network functions use the external exposure framework to interact with related network functions via the NEF.

[0145] Figure 5 Further functional units of the 5G architecture are shown, namely, the Network Slice Selection Function (NSSF), the Network Repository Function (NRF), the Unified Data Management (UDM), the Authentication Server Function (AUSF), the Access and Mobility Management Function (AMF), the Session Management Function (SMF), and the Data Network (DN), such as operator services, Internet access, or third-party services. All or part of the core network functions and application services can be deployed and run in a cloud computing environment.

[0146] A new Study Item (SI) for Supporting Reduced Capability (RedCap) NR Devices (also known as NR Light / Lite) was approved in RANP#86 [RP-193238]. The purpose of this SI is to provide a lighter version of NR for mid-tier NR devices (e.g., smartwatches, video surveillance cameras, and industrial sensors), where the requirements for high throughput, latency, and reliability are less stringent. One of the main goals of this SI is to identify and study potential UE complexity reduction features, such as:

[0147] - Reduced number of UE RX / TX antennas

[0148] -UE bandwidth reduction (where Rel-15 SSB bandwidth should be reused and L1 changes minimized)

[0149] -Half-duplex-Frequency Division Duplex (FDD)

[0150] - Relaxed UE processing time

[0151] -Loose UE processing capabilities

[0152] The UE can be configured with up to 12 control resource sets (CORESETs) (indexed 0-11) on the serving cell. A CORESET is configured in units of six physical resource blocks (PRBs) on a six-PRB frequency grid and in units of one, two, or three consecutive OFDM symbols in the time domain. Before any dedicated higher-layer configuration is provided, the UE acquires the CORESET with index 0 (i.e., CORESET #0, also referred to as the first CORESET) for such initial cell selection or initial access. CORESET #0 can be configured through some predefined procedures and predefined parameters.

[0153] The Master Information Block (MIB) is derived by the UE from the Physical Broadcast Channel (PBCH) when a Synchronization Signal Block (SSB) is detected. If for frequency range 1 (FR1), k SSB ≤23, or if for frequency range 2 (FR2), k SSB≤11, the UE determines the number of consecutive resource blocks and the number of consecutive symbols of the CORESET of type 0-PDCCH CSS set (i.e., CORESET#0) from controlResourceSetZero in pdcch-ConfigSIB1 of the MIB Information Element (IE), as described in Tables 13.1-13.10 of TS 38.213, and determines the PDCCH monitoring opportunities from searchSpaceZero in pdcch-ConfigSIB1, as described in Tables 13.11-13.15 of TS 38.213. On the other hand, if for FR1, k SSB >23, or if for FR2, k SSB >11, CORESET#0 is not present in the MIB IE and may be provided by controlResourceSetZero in PDCCH-ConfigCommon or by searchSpaceZero in PDCCH-ConfigCommon for a DCI format with a cyclic redundancy check (CRC) scrambled by the system information-radio network temporary identifier (SI-RNTI) on the primary cell of the primary cell group (MCG).

[0154] However, when the bandwidth (BW) of Rel-15 CORESET#0 is / can be larger than the BW of RedCap UE, potential problems arise, such as Figure 6 As shown in Figure 6, the Rel-CORESET#0 BW 602 exceeds the RedCap UE BW 604. In addition, the bandwidth of the SIB1 PDSCH scheduled by the current Rel-15 CORESET#0 may also be larger than the BW of the RedCap NR device. This may lead to failures in initial cell selection, handover, etc.

[0155] Therefore, the present disclosure provides a solution for a UE to receive a PDCCH on CORESET#0, whose 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 for the RedCap UE. Advantageously, this allows NR light / lite (or RedCap) UEs with narrower bandwidth capabilities to read SIB1 for initial access. In addition, during initial access, Msg2 PDSCH and Msg4 PDSCH are sent within the CORESET#0 bandwidth. According to embodiment 1, based on the appropriate BW of the RedCap UE, a subset / portion of Rel-15 CORESET#0 may be configured for the RedCap UE, i.e., a subset of the entries of Tables 13.1-13.10 described in TS38.213. As Figure 7 As shown in the example diagram 700 of FIGURE 700, only a subset / portion 706 of Rel-15 CORESET#0 702 is available for configuration for all types of UEs in the network of interest (i.e., normal Rel-15 / 16 / 17 UEs and RedCap UEs). The subset / portion 706 is defined based on the BW of the RedCap UE such that it has a smaller BW than the RedCap UE BW 704, as can be seen in FIGURE 700. Figure 7 As seen in the UE's traditional operations and instructions can still be reused.

[0156] According to embodiment 1, RedCap UEs can assume that the BW of CORESET#0 indicated in the MIB based on Tables 13.1-13.10 in TS 38.213 is equal to or less than their BW, or if the BW of CORESET#0 indicated in the MIB based on Tables 13.1-13.10 in TS 38.213 is greater than the UE's BW, the UE should discard (or ignore) the SSB. Advantageously, the search complexity is simplified due to the reduction of the common search space (CSS) and / or UE-specific search space (USS) set. In addition, due to the introduction of NR light / lite (or RedCap) UEs, additional overhead is avoided.

[0157] When the BW of RedCap UE is 5MHz or 10MHz, {SSB,PDCCH}SCS is {15,15}kHz, and the examples of subsets of Rel-15 CORESET#0 of RedCap UE are respectively Figure 8A Table 800 and Figure 8B13.10 for RedCap UEs.

[0158] According to embodiment 2, Rel-15 CORESET#0 is partitioned into m equal or unequal subsets, such that when the BW of Rel-15 CORESET#0 is greater than the BW of RedCap UE, m≥1. Figure 9 A diagram 900 is shown illustrating the transmission of subsets of Rel-15 CORESET #0 902 according to Embodiment 2. Rel-15 CORESET #0 902 is partitioned into two subsets 904 and 906, where subset 904 is mapped to time slot n and subset 906 is mapped to time slot n-1. The bandwidth of each subset 904, 906 of Rel-15 CORESET #0 is no greater than the bandwidth of a RedCap UE. Each subset of Rel-15 CORESET #0 (i.e., CORESET #0 for RedCap UEs) can be a subset of the entries in Tables 13.1-13.10 of TS 38.213 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 UE capabilities, considerations for channel delay / estimation, or the period of SSBs.

[0159] The PDCCH can be carried by 1, 2, 4, 8 or 16 CCEs to accommodate different DCI payload sizes or different coding rates, where the number of CCEs for the PDCCH is specified by the aggregation level. Each CCE consists of 6 resource element groups (REGs), where each REG consists of 12 resource elements (REs) of one OFDM symbol in one PRB.

[0160] The current indication of Rel-15 CORESET#0 for normal UEs is used to present CORESET#0 for RedCap UEs, i.e., the existing entries of the ControlResourceSetZero and SearchSpaceZero IEs in the MIB. The i-th subset of Rel-15 CORESET#0 is configured in the corresponding time slot n-i, where 0 ≤ i < m, and the time slot n can be the PDCCH monitoring occasion (time slot or symbol) of Rel.15 CORESET#0 or the PDCCH monitoring occasion configured for the RedCap UE. When the RedCap UE monitors m consecutive time slots, it performs blind decoding (BD) attempts by combining the m subsets to decode Rel-15 CORESET#0, as shown in Figure 9 shown in diagram 900. When m > 1, the RedCap UE may need to monitor the split Rel.15 CORESET#0 in time slots different from the monitoring occasions defined for Rel.15 / 16 UEs. Advantageously, the BW of the RedCap UE can be narrower than the BW of Rel-15 CORESET#0. When m = 2, the existing behavior of the monitoring occasion of CORESET#0 is applied to both normal UEs and RedCap UEs.

[0161] In the first variant of embodiment 2, the subset mapping and UE behavior can be as follows:

[0162] - The complete Rel-15 CORESET#0 is mapped in time slot n to support normal Rel-15 / 16 UEs

[0163] - The i-th subset of Rel-15 CORESET#0 is separately configured in the corresponding time slot n-i to support the RedCap UE, where 1 ≤ i < m-1

[0164] - For example: The complete Rel-15 CORESET#0 is split into subset #0 and subset #1. The complete Rel-15 CORESET#0 is mapped in time slot n (i.e., subset #0 is included in time slot n by Rel-15 CORESET#0), while subset #1 is mapped in time slot n-1

[0165] - Normal Rel-15 / 16 UEs perform BD attempts to decode Rel-15 CORESET#0 in time slot n

[0166] - The RedCap UE performs BD attempts by combining the m subsets in m consecutive time slots to decode Rel-15 CORESET#0

[0167] In the second variant of embodiment 2, the subset mapping and UE behavior can be as follows:

[0168] -The complete Rel-15 CORESET#0 is mapped in time slot n to support common Rel-15 / 16 UEs

[0169] - The i-th subset of Rel-15 CORESET#0 is configured separately in the corresponding time slot ki to support RedCap UE, where 0≤i <m

[0170] The value of -k can be predefined

[0171] - A normal Rel-15 / 16 UE makes a BD attempt to decode Rel-15 CORESET#0 in slot n

[0172] - RedCap UE makes a BD attempt to decode Rel-15 CORESET#0 by combining m subsets of m consecutive slots

[0173] Figure 10 Diagram 1000 illustrates an example of equal partitioning of Rel-15 CORESET #0 according to Embodiment 2. In this example, it is assumed that the bandwidths of standard UEs and RedCap UEs are 48 PRBs and 36 PRBs, respectively, and that the bandwidth of Rel-15 CORESET #0 is 48 PRBs. Rel-15 CORESET #0 1002 is equally partitioned into two subsets: Subset #0 1004 and Subset #1 1006, each with 24 PRBs. Subset #0 1004 of 24 PRBs is mapped to slot n, while Subset #1 1006 of 24 PRBs is mapped to slot n-1. Standard and RedCap UEs use a combination of received PRBs in slot n-1 and slot n to perform BD attempts to decode Rel-15 CORESET #0.

[0174] Figure 11An example diagram 1100 illustrates unequal partitioning of Rel-15 CORESET #0 according to Embodiment 2. In this example, it is also assumed that the bandwidths of standard UEs and RedCap UEs are 48 PRBs and 36 PRBs, respectively, and that the bandwidth of Rel-15 CORESET #0 is 48 PRBs. Rel-15 CORESET #0 1102 is unequally partitioned into two subsets, with Subset #0 1004 having 12 PRBs and Subset #1 1006 having 36 PRBs. Of Subset #0 1004 and Subset #1 1006, the longer subset is assigned to the previous or next slot, or the longer subset of the two subsets can be assigned to a slot with better channel conditions than the other slot. In this example, subset #0 1004 of 12 PRBs is mapped to slot n, while subset #1 1006 of 36 PRBs is mapped to slot n - 1. Normal and RedCap UEs then make a BD attempt to decode Rel-15 CORESET #0 using a combination of received PRBs in slot n - 1 and slot n.

[0175] Figure 12 An example diagram 1200 illustrates an equal partitioning of Rel-15 CORESET #0 1202 according to a first variation of Embodiment 2. In this example, it is also assumed that the bandwidths of standard UEs and RedCap UEs are 48 PRBs and 36 PRBs, respectively, and that the bandwidth of Rel-15 CORESET #0 is 48 PRBs. Rel-15 CORESET #0 1202 is equally partitioned into two subsets: Subset #0 1204 and Subset #1 1206, each with 24 PRBs. The entire unpartitioned Rel-15 CORESET #0 1202 is mapped to slot n, while Subset #1 1204, consisting of 24 PRBs, is mapped to slot n-1. A normal Rel-15 / 16 UE makes a BD attempt to decode Rel-15 CORESET#0 in slot n, while a RedCap UE makes a BD attempt to decode Rel-15 CORESET#0 by combining m subsets of m consecutive slots (i.e., slot n and slot n-1 in this example).

[0176] Figure 13An example diagram 1300 illustrates unequal partitioning of Rel-15 CORESET #0 1302 according to a first variation of Embodiment 2. In this example, it is also assumed that the bandwidths of standard UEs and RedCap UEs are 48 PRBs and 36 PRBs, respectively, and that the bandwidth of Rel-15 CORESET #0 is 48 PRBs. Rel-15 CORESET #0 1302 is unequally partitioned into two subsets: Subset #0 1304 and Subset #1 1306, where Subset #0 1304 has 12 PRBs and Subset #1 1306 has 36 PRBs. The entire unpartitioned Rel-15 CORESET #0 1302 is mapped to slot n, while Subset #1 1304, consisting of 24 PRBs, is mapped to slot n-1. A normal Rel-15 / 16 UE makes a BD attempt to decode Rel-15 CORESET#0 in slot n, while a RedCap UE makes a BD attempt to decode Rel-15 CORESET#0 by combining m subsets of m consecutive slots (i.e., slot n and slot n-1 in this example).

[0177] According to embodiment 3, the portion of the Rel-15 CORESET#0 BW outside the RedCap UE BW is partitioned into q equal or unequal subsets such that q ≥ 1 when the BW of Rel-15 CORESET#0 is greater than the BW of the RedCap UE. The BW of each subset of Rel-15 CORESET#0 is no greater than the BW of the RedCap UE. Each subset of Rel-15 CORESET#0 (i.e., CORESET#0 for RedCap UEs) can be a subset of the entries of Tables 13.1-13.10 in TS 38.213 or a subset of physical resources such as CCEs of Rel-15 CORESET#0. These subsets are replicated and mapped within the BW of the RedCap UE at different monitoring occasions (i.e., time slots or symbols). The upper limit of q depends on UE capabilities, considerations for channel delay / estimation, or the period of SSBs. The current indication of Rel-15 CORESET#0 for normal UEs is used to render the existing entries in CORESET#0 for RedCap UEs, ie, ControlResourceSetZero and SearchSpaceZero IEs in the MIB.

[0178] Rel-15 CORESET#0 is signaled to normal UEs and RedCap UEs using (pre-)configured rules:

[0179] - Rel-15 CORESET#0 is mapped in time slot n. The i-th subset of Rel-15 CORESET#0 is replicated and mapped within the BW of the RedCap UE in the corresponding time slot ni, where 1≤i≤q

[0180] - Normal UE makes BD attempt to decode Rel-15 CORESET#0 by monitoring slots n and n-1

[0181] -RedCap UE can assume the number of RBs used for PDSCH resource allocation field Based on Rel-15CORESET#0BW indicated in the MIB, not on RedCap UE BW

[0182] - RedCap UE makes BD attempts to decode Rel-15 CORESET#0 by monitoring q+1 consecutive slots

[0183] Figure 14 An example diagram 1400 of the transmission of Rel-15 CORESET #0 1402 and its subsets according to Embodiment 3 is shown. In this example, the portion of Rel-15 CORESET #0 1402 BW within the RedCap UE BW is Rel-15 CORESET #0 portion 1404, while the portion of Rel-15 CORESET #0 1402 BW outside the RedCap UE BW is Subset #0 1406. Since the BW of Subset #0 1406 does not exceed the RedCap UE BW, it is not split into further subsets (i.e., q=1). Subset #0 1406 is replicated and mapped within the BW of the RedCap UE in time slot n-1. A normal UE performs a BD attempt to decode Rel-15 CORESET #0 by monitoring time slots n and n-1. The RedCap UE makes a BD attempt to decode Rel-15 CORESET#0 by monitoring q+1 consecutive slots (ie, in this example, also slots n and n-1 since q=1).

[0184] Advantageously for embodiment 3, the BW of RedCap UE can be narrower than the BW of Rel-15 CORESET#0. In addition, when q=1, the existing behavior of monitoring occasions of CORESET#0 is applied to both normal UEs and RedCap UEs, as can be seen in Figure 14 As seen in FIG1400 .

[0185] Figure 15An example diagram 1500 is shown of the transmission of Rel-15 CORESET#0 1502 and its subsets according to a variation of embodiment 3. In this variation, Rel-15 CORESET#0 1502 is signaled to normal UEs and RedCap UEs using the following (pre-)configured rules:

[0186] -Rel-15 CORESET#0 1502 is mapped in time slot n

[0187] - In time slot ni, where 1≤i≤q, the portion 1504 of the Rel-15 CORESET#0 mapping within the BW that only RedCap UEs can monitor is replaced with the i-th subset of the Rel-15 CORESET#0 mapping outside the BW of the RedCap UE in time slot n

[0188] - Normal UE makes BD attempt to decode Rel-15 CORESET#0 by monitoring slots n and n-1

[0189] - RedCap UE makes BD attempts to decode Rel-15 CORESET#0 by monitoring q+1 consecutive slots

[0190] Similar to Figure 14 In the example of , since the BW of subset #0 1506 (i.e., the portion of Rel-15 CORESET #0 1502 mapped outside the BW of the RedCap UE in time slot n) does not exceed the RedCap UE BW, it is not split into further subsets (i.e., q=1). Subset #0 1506 is replicated and mapped within the BW of the RedCap UE in time slot n-1. The normal UE makes a BD attempt to decode Rel-15 CORESET #0 by monitoring time slots n and n-1. The RedCap UE makes a BD attempt to decode Rel-15 CORESET #0 by monitoring q+1 consecutive time slots (i.e., in this example, also time slots n and n-1 since q=1).

[0191] Figure 16 An example diagram 1600 shows how a RedCap UE receives the transmission rule of Rel-15 CORESET#0 according to a variation of Embodiment 3. Assume that the BW of Rel-15 CORESET#0 1602 is 48 PRBs and it has 8 CCEs. The BW of the RedCap UE is only 24 PRBs.

[0192] The rules shown in diagram 1600 are as follows:

[0193] - CCEs indexed 0, 2, 4 and 6 of Rel-15 CORESET#0 1602 that are outside the BW of the RedCap UE (i.e., portion 1606) are duplicated and mapped within the BW of the RedCap UE in slot n-1

[0194] The gNB transmits only CCEs with indices 0, 2, 4, and 6 in slot n-1 (i.e., part 1606), whereas it transmits all CCEs with indices from 0 to 7 of Rel-15 CORESET#0 1602 with 8 CCEs in slot n (parts 1604 and 1606 of Rel-15 CORESET#0).

[0195] - Normal UE makes BD attempt to decode Rel-15 CORESET#0 in slot n-1 and slot n 1602

[0196] - RedCap UE uses a combination of CCEs 0, 2, 4, 6 in slot n-1 and CCEs 1, 3, 5, 7 in slot n to decode Rel-15 CORESET#0 1602

[0197] Although the CORESET#0 transmission BW is narrower than the BW of Rel-15 CORESET#0, the BW of the frequency domain resource allocation for PDSCH in the DCI sent on CORESET#0 (i.e., ) can be based on Rel-15 CORESET#0 bandwidth (this is necessary because CCE 1, 3, 5, 7 are shared between Rel-15 UEs and RedCap UEs).

[0198] For scenarios when the RedCap UE monitors more than 2 consecutive time slots, such as n-2, n-1, and n time slots, the above rules of the example diagram 1600 may be extended:

[0199] - The gNB transmits CCEs with indices 0, 2, 4, and 6 only in slot n-2

[0200] - The gNB transmits CCEs with indices 1, 3, 5, and 7 only in slot n-1

[0201] - The gNB transmits all CCEs with indices 0-7 in timeslot n

[0202] - RedCap UE uses a combination of CCEs 0, 2, 4, 6 in slot n-2 and CCEs 1, 3, 5, 7 in slot n-1 to decode Rel-15 CORESET#0

[0203] It should be understood that depending on the RedCap UE capabilities and / or gNB implementation, there may be other possibilities in terms of the number / order of CCEs transmitted in a timeslot (such as n-2, n-1 or n).

[0204] Figure 17 An example diagram 1700 of Rel-15 CORESET#0 1702 and CORESET#0 1704 for RedCap UEs according to embodiment 4 is shown. According to this embodiment, Rel-15 CORESET#0 1702 for normal (Rel-15 / 16 / 17) UEs and information 1706 indicating a subset of Rel-15 CORESET#0 for RedCap UEs (i.e., CORESET#0 1704 for RedCap UEs) are configured as follows:

[0205] - CORESET#0 of RedCap UE is designed based on their appropriate BW, similar to that shown in Example 1,

[0206] - CORESET#0 for RedCap UE is a subset of the entries of Tables 13.1-13.10 described in TS 38.213.

[0207] In embodiment 4, independent indications of Rel-15 CORESET#0 for normal UEs and CORESET#0 for RedCap UEs are used. The physical resources of CORESET#0 for RedCap UEs are indicated by using new entries in the ControlResourceSetZero and SearchSpaceZero IEs in the MIB or PDCCH-ConfigCommon. For example, additional ControlResourceSetZero_NRLight and SearchSpaceZero_NRLight are proposed to indicate CORESET#0 and PDCCH monitoring opportunities for RedCap UEs, respectively, while the existing ControlResourceSetZero and SearchSpaceZero indicate CORESET#0 and PDCCH monitoring opportunities for normal UEs, respectively, as follows:

[0208] ControlResourceSetZero::=SEQUENCE{

[0209] ControlResourceSetZeroINTEGER(0..15)

[0210] ControlResourceSetZero_NRLight INTEGER(0..15)}

[0211] SearchSpaceZero::=SEQUENCE{

[0212] SearchSpaceZeroINTEGER(0..15)

[0213] SearchSpaceZero_NRLight INTEGER(0..15)}

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

[0215] According to embodiment 5A, the current indication of Rel-15 CORESET#0 (ie, the existing ControlResourceSetZero and SearchSpaceZero IEs in the MIB) is reinterpreted for normal and RedCap UEs. Figure 18 An example diagram 1800 illustrates the reinterpretation of Rel-15 CORESET#0 for both normal UEs and RedCap UEs according to embodiment 5A. The same indication of Rel-15 CORESET#0 (i.e., signaling 1802) is used for both normal and RedCap UEs, but the actual value indicated in the configuration field of CORESET#0 is different for normal UEs and RedCap UEs. A different interpretation of the configuration field of Rel-15 CORESET#0 in ControlResourceSetZero is proposed for RedCap UEs as follows:

[0216] -Additional new entries (rows / columns) for RedCap UE CORESET#0 in Tables 13.1-13.10 of TS 38.213

[0217] - The values ​​in the new entries (physical resources) are designed based on the capabilities of RedCap UE

[0218] The size of the configuration fields for Rel-15 CORESET#0 for normal UEs and CORESET#0 for RedCap UEs is the same. Furthermore, the actual values ​​(indicated physical resources) in the entries of the proposed Tables 13.1-13.10 of 38.213 for RedCap UEs may differ from those for normal UEs. Normal UEs read the information in the current MIB and use the existing values ​​in Tables 13.1-13.10 of 38.213 to obtain Rel-15 CORESET#0 by monitoring time slots n and n-1. RedCap UEs read the information in the current MIB and use the corresponding values ​​in the new entries (rows and / or columns) of Tables 13.1-13.10 to obtain their CORESET#0 by monitoring time slots n and n-1. It should be understood that the above signaling method for CORESET#0 and monitoring opportunities for RedCap UEs also applies to Embodiments 2 and 3. Advantageously, the additional overhead caused by the introduction of RedCap UEs can be avoided, and there is no impact on the MIB.

[0219] CORESET#0 for normal UEs and RedCap UEs may be presented in the same table as TS 38.213 or in a separate table. Figure 19 An example of presenting CORESET#0 in the same table as Table 13.1 of TS 38.213 is shown. According to embodiment 5A, when {search space / physical broadcast channel block, PDCCH}SCS ({SS / PBCH block, PDCCH}SCS) is {15,15}kHz for a frequency band with a minimum channel bandwidth of 5MHz or 10MHz, Figure 19 Table 1900 includes the resource block and time slot symbol sets of the CORESET of type 0-PDCCH search space set for normal UEs and RedCap UEs. When the BW of the RedCap UE is 5MHz, {SSB,PDCCH}SCS is {15,15}kHz, based on Table 13.1 of TS 38.213, an example of new rows and columns for RedCap UE CORESET#0 is added, as shown in Table 1900. For indexes 0-5, with 24 PRBs The values ​​of the entries shown in table portion 1902 are the same for both normal and RedCap UEs, i.e., the legacy values. For indices 6-15, the values ​​of the remaining entries shown in table portion 1904 for RedCap UEs differ from those for normal UEs. It should be understood that this approach can also be used to define new rows and columns in Tables 13.2-13.10 for RedCap UEs.

[0220] Figure 20An example of presenting CORESET#0 in a table independent of Table 13.1 of TS 38.213 is shown. According to embodiment 5A, when {SS / PBCH block, PDCCH} SCS is {15,15}kHz for a frequency band with a minimum channel bandwidth of 5MHz, Figure 20 Table 2000 includes a set of resource blocks and time slot symbols for the CORESET of the Type 0 PDCCH search space set for RedCap UEs. In this independent table arrangement, the current Table 13.1 of TS 38.213 is used to represent Rel-15 CORESET #0 for normal UEs, while the independent Table 2000 (which is based on Table 1900) is used to represent CORESET #0 for RedCap UEs. For the different scenarios shown in Tables 13.2-13.10 of TS 38.213, it should be understood that a similar above method can be applied to define corresponding independent tables for RedCap UEs.

[0221] Figure 21 Table 2100 shows an example of a set of resource blocks and time slot symbols for a CORESET of a Type 0 PDCCH search space set for normal UEs and RedCap UEs when {SSB / PBCH block, PDCCH} SCS is {15, 15} kHz for a frequency band with a minimum channel bandwidth of 5 MHz or 10 MHz according to a variation of embodiment 5A. In this variation, Table 2100 shows a different interpretation of Table 13.1 in TS 38.213, which defines RedCap UE CORESET#0. When the BW of a RedCap UE is 5 MHz, {SSB, PDCCH} SCS is {15, 15} kHz. Based on Table 13.1 in TS 38.213, an example of a new row and column for RedCap UE CORESET#0 is added, as shown in Table 2100. For indices 0-5, a 24-PRB-containing UE is used. The values ​​of the entries shown in table portion 2102 are the same for normal and RedCap UEs. For indexes 6-15, the values ​​of the remaining entries shown in table portion 2104 are not applicable (NA) or reserved. It should be understood that a similar approach can be used to define new entries in the rows and columns of Tables 13.2-13.10 for RedCap UEs.

[0222] In embodiment 5B, the current indication of Rel-15 CORESET#0 (i.e., the existing ControlResourceSetZero and SearchSpaceZero IEs in the MIB) is reinterpreted for normal and RedCap UEs. A different interpretation of the configuration fields of Rel-15 CORESET#0 is proposed for RedCap UEs as follows:

[0223] -Additional new entries (rows / columns) for RedCap UE CORESET#0 in Tables 13.1-13.10 of TS 38.213

[0224] - The values ​​in the new entries (physical resources) are designed based on the capabilities of RedCap UE

[0225] - These values ​​can be a subset of the entries in Rel-15 CORESET#0

[0226] - The size of the configuration field of Rel-15 CORESET#0 of a normal UE and CORESET#0 of a RedCap UE is different

[0227] In addition, different monitoring opportunities in SearchSpaceZero are proposed for normal UEs and RedCap UEs. Figure 22 An example diagram 2200 illustrates a reinterpretation of the Rel-15 CORESET#0 monitoring opportunities for normal UEs and RedCap UEs according to embodiment 5B. The gNB transmits Rel-15 CORESET#0 only in slot n, while it transmits CORESET#0 for RedCap UEs only in slot n-1. Normal UEs read the information in the current MIB and use their existing values ​​to perform a BD attempt to decode Rel-15 CORESET#0 by monitoring only slot n, as shown in FIG. Figure 22 On the other hand, the RedCap UE reads the information in the current MIB and uses the corresponding value in the new entry to make a BD attempt to decode its CORESET#0 by monitoring the time slot such as n-1, as shown in FIG. Figure 22 This advantageously reduces the monitoring occasions of all UEs to save power. It should be understood that the size and monitoring occasions of the new entry for the RedCap UE in embodiments 5A and 5B may be different.

[0228] According to embodiment 5B, the method shown in Tables 2000 and 2200 can be used to define CORESET#0 for RedCap UEs. That is, CORESET#0 for RedCap UEs is defined based on the BW capabilities of RedCap UEs. The monitoring opportunity is given in SearchSpaceZero, and the parameters are defined in Tables 13.11-13.15 of TS 38.213. Therefore, the reinterpretation of the Rel-15 CORESET#0 monitoring opportunity is based on Tables 13.11-13.15. Figure 23Table 2300 shows the parameters for reinterpreting the PDCCH monitoring occasion for Type 0 - PDCCH CSS Set - SSB and CORESET reuse mode 1 and frequency range 1 (FR1) according to embodiment 5B. A new column 2302 is added to indicate in which time slot (index p) the RedCap UE CORESET #0 is mapped, as shown in Table 2300. If p = 0, the monitoring occasion for RedCap UE CORESET #0 is time slot n-1, where time slot n is the monitoring occasion for Rel. 15 CORESET #0. If p = 1, the monitoring occasion for RedCap UE CORESET #0 is time slot n+1, where time slot n is the monitoring occasion for Rel. 15 CORESET #0.

[0229] Figure 24 Shown for reading Figure 23 An example of the detailed steps of Table 2300:

[0230] -Step 1: Define odd or even System Frame Number (SFN)

[0231] -Step 2: Define the index of time slot n

[0232] -Step 3: Based on the value of p, define the time slot for mapping RedCap UE CORESET#0

[0233] Figure 25 A diagram 2500 shows different monitoring timings for Rel-15 CORESET#0 of a normal UE and CORESET#0 of a RedCap UE according to embodiment 5B. Assume that Rel-15 CORESET#0 is 48 PRBs and CORESET#0 of a RedCap UE is 24 PRBs. The detailed monitoring timings are Figure 25 As shown below:

[0234] - The gNB transmits Rel-15 CORESET#0 of 48 PRBs for normal UEs only in time slot n, as shown in Table 2100

[0235] - The gNB transmits CORESET#0 of 24 PRBs for RedCap UEs only in slot n-1, as shown in Table 2100

[0236] - Normal UE reads the information in the current MIB and makes a BD attempt to decode Rel-15 CORESET#0 by monitoring only timeslot n

[0237] - RedCap UE reads the information in the current MIB and makes a BD attempt to decode Rel-15 CORESET#0 by monitoring timeslot n-1 or n+1

[0238] It should be understood that Rel-15 CORESET#0 of normal UEs and CORESET#0 of RedCap UEs may be used to schedule to the same or different system information blocks (SIBs) PDSCH, also referred to as SIBx (SIB with index x).

[0239] According to embodiment 5C, the current indication of Rel-15 CORESET#0 (i.e., the existing ControlResourceSetZero and SearchSpaceZero IEs in the MIB) is reinterpreted for both normal UEs and RedCap UEs. A different interpretation of the configuration field of Rel-15 CORESET#0 is also proposed for RedCap UEs, so that new entries (rows / columns) for RedCap UE CORESET#0 are additionally proposed in Tables 13.1-13.10 of TS38.213, where the values ​​(physical resources) in the new entries are designed based on the capabilities of the RedCap UE. These values ​​can be defined using a similar method as shown in the examples of embodiment 5A or 5B (Tables 1900, 2100, or 2300).

[0240] Furthermore, the repetition of CORESET#0 may be explicitly and / or implicitly signaled to the RedCap UE. In the implicit approach, the signaling may be via (pre)configured rules. In the explicit approach, the signaling may be via higher layer signaling. For example, additional columns are added to Table 13.1 or Table 13.11 of TS 38.213 to indicate the repetition of CORESET#0 in the CORESET#0 state, respectively. Figure 26 Table 2600 or Figure 27 The gNB transmits the Rel-15 CORESET#0 for normal UEs specified in SSBx, while simultaneously transmitting the CORESET#0 for RedCap UEs specified in both SSBx and SSBy (as a repetition). Therefore, normal UEs detect SSBx to obtain Rel-15 CORESET#0, and RedCap UEs detect SSBx and SSBy to obtain their CORESET#0. Advantageously, the common channel coverage can be reduced due to the potential reduction in the BW of RedCap UEs. This solution can improve coverage performance for RedCap UEs.

[0241] refer to Figure 26Table 2600 is based on Table 13.1 of TS 38.213, with the addition of an additional column 2602 to indicate the new entry for RedCapUE CORESET#0 and the number of repetitions in ControlResourceSetZero. As similarly shown in Table 2000, Table 2600 can be divided into separate tables for normal UEs and RedCap UEs. It should be understood that this is merely an example, and that other possibilities exist in terms of the number of rows / columns defined based on the capabilities of the RedCap UE and the values ​​in these rows / columns that can be additionally configured in Tables 13.1-13.10.

[0242] refer to Figure 27 Table 2700 is based on Table 13.11 of TS 38.213, with an additional column 2702 added to indicate the number of repetitions in SearchSpaceZero. It should be understood that this is merely an example, and there may be other possibilities in terms of the values ​​that may be additionally configured in Tables 13.1-13.15 in these rows / columns defined based on the capabilities of the RedCap UE.

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

[0244] RedCap UEs are proposed to support a bandwidth at least equal to the maximum bandwidth of CORESET#0 defined in Rel-15 / 16 (i.e., the BW of RedCap 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 with RedCap UEs (i.e., normal 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 configuration associated with one or more UEs in the set of normal (non-RedCap or Rel-15 / 16 / 17...) UEs and RedCap UEs. UEs perform blind decoding on PDCCH candidates in the search space carried by CORESET#0 according to the CORESET#0 bandwidth, physical resource mapping scheme, or monitoring opportunity to obtain all control information on one or more consecutive time slots.

[0245] When the RedCap UE bandwidth is equal to or greater than the CORESET#0 bandwidth in both frequency range 1 (FR1) and frequency range 2 (FR2), both SSB and CORESET#0 can be shared between RedCap UEs and non-RedCap UEs. Furthermore, if the network wishes to offload transmissions for RedCap UEs, it can configure a separate CORESET#0 or initial downlink bandwidth part (BWP) that is frequency division multiplexed (FDMed) with non-RedCap UEs. For example, for reuse modes 2 and 3 in FR2, SSB and CORESET#0 can be frequency domain multiplexed. In some specific cases, the total bandwidth may span more than the maximum bandwidth of the RedCap UE. This may require frequency retuning and sequential acquisition of SSB and CORESET#0, which may incur additional latency. However, such additional latency is acceptable for RedCap use cases. Therefore, enhanced acquisition of SSB and / or CORESET#0 may not be required.

[0246] Figure 28A flowchart 2800 illustrating a communication method according to various embodiments is shown. In step 2802, CORESET#0 is received, the time and frequency resources of CORESET#0 being defined based on a minimum bandwidth configuration associated with one or more UEs in a set of normal (non-RedCap) UEs and RedCap UEs, and a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) scheduled based on CORESET#0 is also received. In step 2804, control information and parameters from the PDCCH on CORESET#0 are determined to read SIB1, Msg2 PDSCH, and Msg4 PDSCH for initial access, handover, or beam failure recovery.

[0247] Figure 29 A schematic partial cross-sectional view of a communication apparatus 2900 that can be implemented to facilitate implementation of a RedCap device CORESET#0 according to various embodiments is shown. According to various embodiments, the communication apparatus 2900 can be implemented as a gNB, a normal UE, or a RedCap UE.

[0248] The various functions and operations of the communication device 2900 are arranged into layers according to a layered model. In this model, according to the 3GPP specification, the lower layers report to the upper layers and receive instructions from them. For the sake of simplicity, the details of the layered model are not discussed in this disclosure.

[0249] like Figure 29 As shown, the communication device 2900 may include circuitry 2914, at least one radio transmitter 2902, at least one radio receiver 2904, and multiple antennas 2912 (for simplicity, for illustration purposes, the antennas 2912 are not shown in FIG). Figure 29 Only one antenna is depicted in FIG). The circuit 2914 may include at least one controller 2906 for software and hardware assistance in performing the tasks it is designed to perform, including controlling communications with one or more other communication devices in the MIMO wireless network. The at least one controller 2906 may control at least one transmit signal generator 2908 for generating SIBs, SL-UEInfo and / or RRC-Reconfig messages to be sent to one or more other communication devices via at least one radio transmitter 2902, and at least one receive signal processor 2910 for processing the SIBs, SL-UEInfo and / or RRC-Reconfig messages received from one or more other communication devices via at least one radio receiver 2904. Figure 29As shown, at least one transmit signal generator 2908 and at least one receive signal processor 2910 can be independent modules of the communication device 2900, which communicate with at least one controller 2906 to perform the above functions. Alternatively, at least one transmit signal generator 2908 and at least one receive signal processor 2910 can be included in at least one controller 2906. It will be apparent to those skilled in the art that the arrangement of these functional modules is flexible and can vary according to actual needs and / or requirements. Data processing, storage and other related control devices can be provided on appropriate circuit boards and / or in chipsets. In various embodiments, at least one radio transmitter 2902, at least one radio receiver 2904 and at least one antenna 2912 can be controlled by at least one controller 2906.

[0250] exist Figure 29 In the embodiment shown in FIG, at least one radio receiver 2904 together with at least one receive signal processor 2910 form the receiver of the communication device 2900. The receiver of the communication device 2900 provides the functionality required to facilitate the implementation of CORESET#0 of the RedCap device.

[0251] Communication apparatus 2900 provides functionality required to facilitate implementation of CORESET#0 of a RedCap device. For example, communication apparatus 2900 may be a communication apparatus, and receiver 2904 may receive a physical downlink control channel (PDCCH) on control resource set zero (CORESET#0), the time and frequency resources of which are defined based on the bandwidth configuration of a reduced-capability user equipment (RedCap UE), and receive a system information block type 1 (SIB1) physical downlink shared channel (PDSCH) scheduled based on CORESET#0. Circuit 2914 may determine control information and parameters from the PDCCH on CORESET#0 to read SIB1 for initial access, handover, or beam failure recovery.

[0252] If CORESET#0 has a greater bandwidth than the bandwidth of the communication device 2900, the circuit 2914 may also discard or ignore the control information on CORESET#0.

[0253] CORESET#0 of a RedCap UE may be a subset of the entries of Tables 13.1-13.10 in TS 38.213 or a subset of the physical resources such as control channel elements (CCEs) or physical resource blocks (PRBs) of Rel-15 CORESET#0.

[0254] CORESET #0 can be a subset of Rel-15 CORESET #0 such that only this subset can be used to configure for all types of UEs, including normal (non-RedCap) UEs and RedCap UEs in the associated network.

[0255] CORESET #0 can be Rel-15 CORESET #0, which is divided into m equal or unequal subsets such that m ≥ 1, and each subset has a bandwidth smaller than that of the RedCap UE. Each subset can correspond to a subset of the entries in Tables 13.1 - 13.10 in TS 38.213 or a subset of the 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 time slots. The upper limit of m can depend on UE capabilities, considerations of channel delay / estimation, or the period of the SSB. The subset can be mapped to m consecutive time slots such that the i-th subset in the subset is mapped in the corresponding time slot n - i, where 0 ≤ i < m, and where the time slot n can be the PDCCH monitoring occasion (time slot or symbol) of Rel.15 CORESET #0 or the PDCCH monitoring occasion configured for the RedCap UE. The upper limit of m can depend on UE capabilities, considerations of channel delay / estimation, or the period of the SSB.

[0256] CORESET #0 can be Rel-15 CORESET #0, which is divided into m equal or unequal subsets such that m ≥ 1, and each subset has a bandwidth smaller than that of the RedCap UE; where Rel-15 CORESET #0 is mapped in the first time slot; and where each subset is mapped to each of the m - 1 consecutive time slots different from the first time slot. The upper limit of m can depend on UE capabilities, considerations of channel delay / estimation, or the period of the SSB.

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

[0258] CORESET#0 may be Rel-15 CORESET#0, wherein the portion of Rel-15 CORESET#0 outside the RedCap UE bandwidth is partitioned into q equal or unequal subsets such that q ≥ 1, each subset having a bandwidth smaller than the RedCap UE bandwidth; wherein Rel-15 CORESET#0 is mapped in the first time slot; wherein each of the q equal or unequal subsets is replicated and mapped within the RedCap UE bandwidth in each of q consecutive time slots different from the first time slot. The upper limit of q may depend on UE capabilities, considerations for channel delay / estimation, or the period of the SSB.

[0259] CORESET#0 may be a Rel-15 CORESET#0, wherein the portion of Rel-15 CORESET#0 outside the RedCap UE bandwidth is partitioned into q equal or unequal subsets such that q ≥ 1, each subset having a bandwidth smaller than the bandwidth of the RedCap UE; wherein Rel-15 CORESET#0 is mapped in the first time slot; wherein at each of q consecutive time slots different from the first time slot, the portion of CORESET#0 mapped within the BW that only the RedCap UE can monitor is replaced with a subset of the q equal or unequal subsets of CORESET#0. The upper limit of q may depend on UE capabilities, considerations for channel delay / estimation, or the period of the SSB.

[0260] Information indicating Rel-15 CORESET#0 and PDCCH monitoring occasions for normal UEs, including existing entries in ControlResourceSetZero and SearchSpaceZero IEs in the MIB, may be used to present CORESET#0 for RedCap UEs.

[0261] The information indicating the Rel-15 CORESET#0 and PDCCH monitoring timing of a normal (non-RedCap) UE and the information indicating the CORESET#0 and PDCCH monitoring timing of a RedCap UE may be independent of each other, wherein the receiver 2904 receives these two pieces of information, and wherein the circuit 2914 determines the control information and parameters for reading SIB1 based on the indication information of the normal UE when the communication device is a normal UE or based on the indication information of the RedCap UE when the communication device is a RedCap UE.

[0262] Information indicating the Rel-15 CORESET#0 of a normal (non-RedCap) UE may be interpreted differently for a RedCap UE such that the information indicates the physical resources of the CORESET#0 of the RedCap UE (which may be the same as or different from those of the normal UE), wherein a receiver 2904 receives the information; and wherein, based on the information, a circuit 2914 obtains control information and parameters to read SIB1 from the Rel-15 CORESET#0 of the normal UE if the communication device is a normal UE, or from the CORESET#0 of the RedCap UE if the communication device is a RedCap UE.

[0263] Information indicating the Rel-15 CORESET#0 of a normal (non-RedCap) UE may be interpreted differently for a RedCap UE, such that the information indicates the physical resources of the CORESET#0 of the RedCap UE (which may be different from those of a normal UE) and indicates the monitoring opportunity of the RedCap UE (which is different from that of a normal UE), wherein the receiver 2904 receives the information; and wherein, based on the information, the circuit 2914 obtains control information and parameters to read SIB1 from the Rel-15 CORESET#0 if the communication device is a normal UE or from the CORESET#0 of the RedCap UE if the communication device is a RedCap UE in the corresponding monitoring opportunity.

[0264] Information indicating the Rel-15 CORESET#0 of a normal (non-RedCap) UE may be interpreted differently for a RedCap UE such that the information indicates the physical resources of the RedCap UE CORESET#0 (which may be different from the normal UE) and indicates one or more repetitions of CORESET#0, wherein the one or more repetitions may be signaled to the RedCap UE implicitly via (pre-)configured rules or explicitly via higher layer signaling, wherein the receiver receives the information, and wherein, based on the information, circuit 2914 obtains control information and parameters to read SIB1 from the Rel-15 CORESET#0 of the normal UE if the communication device is a normal UE or from the CORESET#0 of the RedCap UE if the communication device is a RedCap UE.

[0265] Within the same beam, the associated gNB may transmit Rel-15 CORESET#0 for normal UEs specified in SSBx and CORESET#0 for RedCap UEs specified in SSB with index x and SSB with index y, where CORESET#0 specified in SSB with index y is a repetition of CORESET#0 in SSB with index x, such that normal UEs detect SSBx to obtain Rel-CORESET#0 and RedCap UEs detect SSB with index x and SSB with index y to obtain CORESET#0 for RedCap UEs, where one or more repetitions are signaled implicitly via (pre-)configured rules or explicitly via higher layer signaling.

[0266] The CORESET#0 for RedCap UEs may be pre-configured by the application layer. A serving cell (Pcell / PSCell / Scell) that is only capable of Rel-15 / 16 may not support RedCap UEs, and a message such as "this cell does not support RedCap UEs" may need to be signaled in the MIB / SIB1, or a new physical layer cell identifier (PCID) range may be used for RedCap UEs so that the communication device 2900 may discard or ignore these cells if the communication device is a RedCap UE. RedCap UEs may support a bandwidth at least equal to the maximum bandwidth of CORESET#0 defined in Rel-15 / 16, where Rel-15 CORESET#0 may be used to configure for all types of non-RedCap and RedCap UEs. The physical resources of CORESET#0 can be defined based on the minimum bandwidth configuration associated with one or more UEs in the set of normal (non-RedCap) UEs and RedCap UEs in the serving cell, where the UE performs blind decoding on the PDCCH candidates in the search space carried by CORESET#0 according to the CORESET#0 bandwidth, physical resource mapping scheme or monitoring opportunity to achieve all control information on one or more consecutive time slots.

[0267] The communication device 2900 provides the functionality required to facilitate the implementation of CORESET#0 of a RedCap device. For example, the communication device 2900 may be a base station or a gNB, and the circuit 2914 may configure a control resource set zero (CORESET#0) whose time and frequency resources are defined based on a minimum bandwidth configuration associated with one or more UEs in a set of normal (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; and the transmitter 2902 may transmit the PDCCH on CORESET#0 and the SIB1 PDSCH to the communication device.

[0268] As described above, the embodiments of the present disclosure provide an advanced communication method and a communication apparatus capable of implementing CORESET#0 of a RedCap device.

[0269] The present disclosure can be implemented by software, hardware, or software in collaboration with hardware. Each functional block used in the description of each of the above embodiments can be partially or entirely implemented by an LSI such as an integrated circuit, and each process described in each embodiment can be partially or entirely controlled by the same LSI or a combination of LSIs. The LSI can be formed as a chip individually, or can be formed as a chip to include some or all functional blocks. The LSI can include data inputs and outputs coupled thereto. Depending on the degree of integration, the LSI here can be referred to as an IC, a system LSI, a super LSI, or an ultra LSI. However, the technology for implementing the integrated circuit is not limited to the LSI and can be implemented by using a dedicated circuit, a general-purpose processor, or a dedicated processor. In addition, an FPGA (Field Programmable Gate Array) that can be programmed after the LSI is manufactured or a reconfigurable processor in which the connections and settings of the circuit units arranged inside the LSI can be reconfigured can be used. The present disclosure can be implemented as digital processing or analog processing. If future integrated circuit technology replaces the LSI due to advances in semiconductor technology or other derivative technologies, the future integrated circuit technology can be used to integrate the functional blocks. Biotechnology can also be applied.

[0270] The present disclosure may be implemented by any type of device, apparatus, or system having a communication function, which is referred to as a communication device.

[0271] The communication device may include a transceiver and processing / control circuitry. The transceiver may include and / or function as a receiver and a transmitter. As a transmitter and receiver, the transceiver may include an RF (radio frequency) module including an amplifier, an RF modulator / demodulator, etc., and one or more antennas.

[0272] Some non-limiting examples of such communication devices include phones (e.g., cellular (mobile) phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, netbooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smart watches, tracking devices), game consoles, digital book readers, telehealth / telemedicine (remote health and medical) devices, and vehicles providing communication capabilities (e.g., cars, airplanes, ships), and various combinations thereof.

[0273] Communication devices are not limited to being portable or movable and may also include any type of device, equipment, or system that is not portable or stationary, 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.

[0274] Communications may include exchanging data via, for example, cellular systems, wireless LAN systems, satellite systems, etc., and various combinations thereof.

[0275] A communication apparatus may include a device, such as a controller or a sensor, coupled to a communication device that performs the communication functions described in the present disclosure. For example, a communication apparatus may include a controller or a sensor that generates a control signal or a data signal that is used by the communication device that performs the communication functions of the communication apparatus.

[0276] The communication device may also include infrastructure such as base stations, access points, and any other device, equipment, or system that communicates with or controls devices such as the non-limiting examples above.

[0277] It will be appreciated by those skilled in the art that various changes and / or modifications may be made to the disclosure shown in the specific embodiments without departing from the spirit or scope of the disclosure as broadly described. Therefore, the present embodiments are to be considered in all respects as illustrative and not restrictive.

Claims

1. A communication device, comprising: A receiver, receiving a physical downlink control channel PDCCH on a control resource set zero CORESET#0; as well as Circuit: Determine control information and parameters based on the PDCCH on CORESET#0 to read the system information block type 1 SIB1 for initial access, handover or beam failure recovery; The time and frequency resources of CORESET#0 are defined based on a minimum bandwidth configuration associated with one or more UEs in a set of reduced capability user equipment (RedCap) UEs and a set of normal (non-RedCap) UEs, and Receive the SIB1 physical downlink shared channel PDSCH scheduled based on CORESET#0; and The RedCap UE supports a maximum bandwidth at least equal to that of the CORESET#0 configured for all types of non-RedCap and RedCap UEs.

2. The communication device of claim 1 , wherein the circuit discards or ignores control information on CORESET # 0 if CORESET # 0 has a bandwidth greater than a bandwidth of the communication device.

3. The communication apparatus according to claim 1, wherein CORESET#0 of a RedCap UE can be a subset of entries of Tables 13.1-13.10 in TS 38.213 or a subset of physical resources such as control channel elements (CCEs) or physical resource blocks (PRBs) of Rel-15 CORESET#0.

4. The communication apparatus according to claim 1 , wherein the CORESET#0 is a subset of Rel-15 CORESET#0, such that only the subset can be used for configuration for all types of UEs including normal (non-RedCap) UEs and RedCap UEs in an associated network.

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

6. The communication apparatus according to claim 5, wherein each subset is mapped to each of m consecutive time slots.

7. The communication device according to claim 1 , wherein the CORESET#0 is a Rel-15 CORESET#0, the Rel-15 CORESET#0 being divided into m equal or unequal subsets such that m≥1, and each subset having a bandwidth smaller than a bandwidth of the RedCap UE; The Rel-15 CORESET#0 is mapped in the first time slot; Each subset is mapped to each of m-1 consecutive time slots different from the first time slot.

8. The communication device according to claim 5 or 7, wherein the upper limit of m depends on UE capability, consideration of channel delay / estimation, or period of SSB.

9. The communication apparatus according to any one of claims 1 to 7, wherein information indicating Rel-15 CORESET#0 and PDCCH monitoring opportunities of a normal UE is used to present CORESET#0 of a RedCap UE, the information including existing entries in ControlResourceSetZero and SearchSpaceZero IEs in the MIB.

10. The communication device according to any one of claims 1 to 7, wherein the information indicating the Rel-15 CORESET#0 and PDCCH monitoring timing of a normal non-RedCap UE and the information indicating the CORESET#0 and PDCCH monitoring timing of a RedCap UE are independent of each other, the receiver receives the two pieces of information, and the circuit determines control information and parameters to read the SIB1 based on the indication information of the normal UE when the communication device is the normal UE or based on the indication information of the RedCap UE when the communication device is the RedCap UE.

11. The communication device according to any one of claims 1 to 7, wherein CORESET#0 of the RedCap UE is pre-configured by an application layer.

12. According to any one of claims 1 to 7, one or more cells (Pcell / PSCell / Scell) with only Rel-15 / 16 capabilities cannot support RedCap UEs, and a message such as "this cell does not support RedCap UEs" needs to be signaled in MIB / SIB1, or a new physical layer cell identifier PCID range is used for the RedCap UE, so that if the communication device is the RedCap UE, the communication device can discard or ignore these cells.

13. The communication apparatus of claim 1 , wherein the physical resources of CORESET #0 are defined based on a minimum bandwidth configuration associated with one or more UEs in a set of normal non-RedCap UEs and RedCap UEs in a serving cell, wherein the UEs perform blind decoding on PDCCH candidates in a search space carried by CORESET #0 to achieve all control information on one or more consecutive time slots according to the CORESET #0 bandwidth, a physical resource mapping scheme, or a monitoring opportunity.

14. A base station, comprising: Circuit, configuration control resource set zero CORESET#0; as well as Transmitter: Send the physical downlink control channel PDCCH and system information block type 1 SIB1 physical downlink shared channel PDSCH on CORESET#0 to the communication device, The time and frequency resources are defined based on the minimum bandwidth configuration associated with one or more UEs in the set of normal (non-RedCap) UEs and RedCap UEs, Generate a PDCCH on the CORESET#0 and schedule a SIB1 physical downlink shared channel PDSCH based on the CORESET#0, The RedCap UE supports a maximum bandwidth at least equal to that of the CORESET#0 configured for all types of non-RedCap and RedCap UEs.

15. A communication method, comprising: receiving CORESET#0, wherein time and frequency resources of CORESET#0 are defined based on a minimum bandwidth configuration associated with one or more UEs in a set of normal 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; as well as Determine control information and parameters according to the PDCCH on CORESET#0 to read SIB1 for initial access, handover or beam failure recovery, The time and frequency resources of CORESET#0 are defined based on the minimum bandwidth configuration associated with one or more UEs in a set of normal (non-RedCap) UEs and RedCap UEs, wherein the RedCap UE supports at least a maximum bandwidth of the CORESET#0 configured for all types of non-RedCap and RedCap UEs.

16. A communication method, comprising: Configuration control resource set zero CORESET#0; as well as Send the physical downlink control channel PDCCH and system information block type 1 SIB1 physical downlink shared channel PDSCH on CORESET#0 to the communication device, The time and frequency resources are defined based on the minimum bandwidth configuration associated with one or more UEs in the set of normal (non-RedCap) UEs and RedCap UEs, Generate a PDCCH on the CORESET#0 and schedule a SIB1 physical downlink shared channel PDSCH based on the CORESET#0, The RedCap UE supports a maximum bandwidth at least equal to that of the CORESET#0 configured for all types of non-RedCap and RedCap UEs.

17. An integrated circuit comprising a circuit, wherein: controlling reception of CORESET#0, wherein time and frequency resources of CORESET#0 are defined based on a minimum bandwidth configuration associated with one or more UEs in a set of normal (non-RedCap) UEs and RedCap UEs, Control reception of the system information block type 1 SIB1 physical downlink shared channel PDSCH scheduled based on the CORESET#0, Determine control information and parameters according to the PDCCH on CORESET#0 to read the SIB1 for initial access, handover or beam failure recovery, The time and frequency resources of CORESET#0 are defined based on the minimum bandwidth configuration associated with one or more UEs in a set of normal (non-RedCap) UEs and RedCap UEs, wherein the RedCap UE supports at least the maximum bandwidth of CORESET#0 configured for all types of non-RedCap and RedCap UEs.

18. An integrated circuit comprising a circuit, wherein: Control configuration control resource set zero CORESET#0; and Control the transmission of the physical downlink control channel PDCCH and system information block type 1 SIB1 physical downlink shared channel PDSCH on CORESET#0 to the communication device, The time and frequency resources are defined based on the minimum bandwidth configuration associated with one or more UEs in the set of normal (non-RedCap) UEs and RedCap UEs, Generate a PDCCH on the CORESET#0 and schedule a SIB1 physical downlink shared channel PDSCH based on the CORESET#0, The RedCap UE supports a maximum bandwidth at least equal to that of the CORESET#0 configured for all types of non-RedCap and RedCap UEs.

Images