Enhancements for reduced capability new radio devices

Abstract

The present disclosure relates to enhancements for reduced capability new radio devices. A user equipment (UE) is configured to receive a system information block (SIB) from a base station and transmit an indication of a reduced capability (redcap) device type to the base station during a random access procedure, where the indication is associated with a UE configuration that includes one or more UE complexity reduction features.

Description

[0001] This application is a divisional application of the PCT application filed on August 5, 2021, with national application number 202180012697.2 and entitled "Enhancement of a New Wireless Device with Reduced Capabilities", which has entered the Chinese national phase. Technical Field

[0002] This application generally relates to wireless communication systems, and more particularly to enhancements to new wireless devices with reduced capabilities. Background Technology

[0003] New radio (NR) networks can support redcap devices. Typically, redcap devices are not configured with the same characteristics as non-redcap devices. For example, compared to traditional NR user equipment (UE), redcap devices may have a lower maximum bandwidth and / or be configured for half-duplex (HD) frequency division duplex (FDD) operation. These types of characteristics offer the benefit of reduced cost and / or complexity. Summary of the Invention

[0004] Some exemplary embodiments relate to a processor of a user equipment (UE) configured to perform operations. These operations include receiving a system information block (SIB) from a base station and transmitting an indication of a redcap device type to the base station during a random access procedure, wherein the indication is associated with a UE configuration including one or more UE complexity reduction features.

[0005] Other exemplary embodiments relate to a processor of a base station configured to perform operations. These operations include transmitting a System Information Block (SIB) to one or more User Equipments (UEs) and receiving an indication of a redcap device type from the UE during a random access procedure, wherein the indication is associated with a UE configuration including one or more UE complexity reduction features. Attached Figure Description

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

[0007] Figure 2 Exemplary user equipment (UE) according to various exemplary embodiments are shown.

[0008] Figure 3 An exemplary base station according to various exemplary embodiments is shown.

[0009] Figure 4 A signaling diagram is shown, illustrating scenarios during which various enhancements to a redcap device can be implemented according to various exemplary embodiments.

[0010] Figure 5 An example of the downlink control information (DCI) format 1_0 configured for redcap device access control according to various exemplary implementations is shown.

[0011] Figure 6 Examples of initial uplink BWPs with dedicated PRACH resource sets for redcap UEs and dedicated PRACH resource sets for non-redcap UEs are shown according to various exemplary embodiments.

[0012] Figure 7 Examples of TDM-dedicated PRACH resource sets for redcap UEs and dedicated PRACH resource sets for non-redcap UEs are shown according to various exemplary implementations.

[0013] Figure 8 Examples of preamble partitioning within a random access channel (RACH) timing (RO) between a redcap device and a non-redcap device are shown according to various exemplary implementations.

[0014] Figure 9 A table showing an exemplary set of parameters for configuring how preambles within a redcap device and a non-redcap device are partitioned, according to various exemplary implementations.

[0015] Figure 10 Examples are shown of preambles within the partitioned RO according to various exemplary embodiments for identifying redcap devices with and without coverage enhancement (CE) and non-redcap devices with and without coverage enhancement (CE).

[0016] Figure 11 A table showing an exemplary set of parameters for configuring how to partition the preamble within a RO between redcap devices with and without CE and non-redcap devices with and without CE, according to various exemplary embodiments. Detailed Implementation

[0017] The exemplary embodiments can be further understood with reference to the following description and related figures, wherein similar elements have the same reference numerals. The exemplary embodiments relate to improved support for redcap new radio (NR) devices.

[0018] The exemplary implementation is described in relation to a redcap device. The term "redcap device" generally refers to a 3GPP (3rd Generation Partnership Project) concept for NR devices that offers lower cost and / or complexity compared to traditional NR devices. In some cases, a redcap device can be characterized as a device with lower-end capabilities compared to version 16 Enhanced Mobile Broadband (eMBB) devices and Ultra-Reliable Low-Latency Communication (URLLC) devices. To provide some concrete examples, redcap devices can be associated with use cases such as, but not limited to, industrial wireless sensors, video surveillance, and wearable devices.

[0019] Redcap devices can be configured with complexity-reducing features, such as, but not limited to: lower maximum bandwidth compared to traditional NR devices, fewer antenna branches compared to traditional NR devices, half-duplex (HD) frequency division duplex (FDD) capability, relaxed processing time compared to traditional NR devices, and relaxed processing power compared to traditional NR devices. These features can provide cost and / or complexity reduction benefits. However, any reference to redcap devices with specific complexity-reducing features is for illustrative purposes only. Different types of redcap devices may exist, and different networks may use different complexity-reducing features to define redcap devices.

[0020] Throughout this specification, the terms “User Equipment (UE),” “redcap device,” and “redcap UE” are used interchangeably to refer to any electronic component capable of establishing a connection to a network and equipped with capabilities that can be characterized as a 3GPP NR redcap device. Therefore, the terms “UE,” “redcap device,” and “redcap UE” as used herein are not used to refer to any type of UE. Rather, these terms are used to identify a specific NR UE that differs from non-redcap devices (e.g., conventional NR UEs). Exemplary embodiments are configured to address issues related to specific aspects of redcap devices (or devices with similar reduced capabilities).

[0021] Some of the exemplary implementations described herein relate to implementing dedicated redcap resources and / or resources that can be shared by redcap and non-redcap devices. Throughout this specification, the terms "non-redcap device," "non-redcap UE," and "traditional NR UE" are used interchangeably to refer to any 3GPP NR device other than a 3GPP NR redcap device.

[0022] In one aspect, exemplary embodiments introduce techniques for indicating whether a particular cell and / or frequency is configured to provide network access to the redcap device. These exemplary redcap access control techniques offer a sufficient balance between redcap device power consumption, cost reduction, implementation feasibility, and network performance.

[0023] It can be beneficial for a redcap device to explicitly identify itself as a redcap device through early indication. Accordingly, exemplary implementations introduce techniques that enable a redcap UE to explicitly identify itself during the random access procedure. These exemplary techniques offer a sufficient balance between redcap device power consumption, cost reduction, implementation feasibility, and network performance.

[0024] Specific examples of these exemplary access control and redcap device identification technologies are provided below. These exemplary technologies can be used in conjunction with other currently implemented NR redcap mechanisms, with future implementations of NR redcap mechanisms, or independently of other NR redcap mechanisms.

[0025] Figure 1 An exemplary network arrangement 100 according to various exemplary embodiments is shown. The exemplary network arrangement 100 includes a UE 110. Those skilled in the art will understand that the UE 110 can be any type of electronic component configured to communicate via a network, such as a mobile phone, tablet computer, desktop computer, smartphone, phablet, embedded device, Internet of Things (IoT) device, wearable device (e.g., medical device, augmented reality goggles, virtual reality goggles, smartwatch, etc.), industrial wireless sensor, video surveillance, etc. It should also be understood that a practical network arrangement can include any number of UEs used by any number of users. Therefore, for illustrative purposes, only an example with a single UE 110 is provided.

[0026] UE 110 can be configured to communicate with one or more networks. In the example of network deployment 100, the network with which UE 110 can wirelessly communicate is the 5G NR radio access network (RAN) 120. However, UE 110 can also communicate with other types of networks (e.g., 5G cloud RAN, next-generation RAN (NG-RAN), LTE RAN, legacy cellular networks, WLAN, etc.), and UE 110 can also communicate with the network via a wired connection. Regarding an exemplary implementation, UE 110 can establish a connection with 5G NR RAN 120. Therefore, UE 110 may have a 5G NR chipset to communicate with 5G NR RAN 120.

[0027] The 5G NR RAN 120 can be part of a cellular network that can be deployed by network operators (e.g., Verizon, AT&T, T-Mobile, etc.). The 5G NR RAN 120 may include, for example, nodes, cells, or base stations (e.g., Node B, eNodeB, HeNB, eNBS, gNB, gNodeB, macrocell base stations, microcell base stations, small cell base stations, femtocell base stations, etc.) configured to send and receive communication services from UEs equipped with appropriate cellular chipsets.

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

[0029] Network deployment 100 also includes a cellular core network 130, an Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. The cellular core network 130 can be viewed as an interconnected set of components that manage the operation and traffic of the cellular network. It may include an evolved packet core (EPC) and / or a fifth-generation core (5GC). The cellular core network 130 also manages the traffic flowing between the cellular network and the Internet 140. The IMS 150 can generally be described as an architecture for delivering multimedia services to the UE 110 using IP protocols. The IMS 150 can communicate with the cellular core network 130 and the Internet 140 to provide multimedia services to the UE 110. The network services backbone 160 communicates directly or indirectly with the Internet 140 and the cellular core network 130. The network services backbone 160 can generally be described as a set of components (e.g., servers, network storage deployments, etc.) that implement a set of services that can be used to extend the functionality of the UE 110 to communicate with various networks.

[0030] Figure 2 An exemplary UE 110 according to various exemplary embodiments is shown. Reference will be made to... Figure 1The network layout 100 is used to describe UE 110. UE 110 may include a processor 205, a memory layout 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. The other components 230 may include, for example, audio input devices, audio output devices, power sources, data acquisition devices, ports for electrically connecting UE 110 to other electronic devices, etc.

[0031] Processor 205 can be configured to execute multiple engines for UE 110. For example, engines may include an access barring engine 235 and a random access engine 240. Access barring engine 235 can perform various operations related to determining whether a redcap device is allowed access to a cell and / or frequency. Random access engine 240 can perform various operations related to performing a random access procedure, such as, but not limited to, selecting a Physical Random Access Channel (PRACH) resource configured for the redcap device and providing explicit indication to UE 110 as a redcap device.

[0032] The engines 235 and 240 referred to above are provided for illustrative purposes only as applications (e.g., programs) executed by processor 205. The functionality associated with engines 235 and 240 may also be represented as separate components of UE 110, or as modular components coupled to UE 110, such as integrated circuits with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. The engine may also be embodied as a single application or multiple separate applications. Furthermore, in some UEs, the functionality described for processor 205 is distributed among two or more processors, such as a baseband processor and an application processor. Exemplary implementations may be implemented according to any of these or other configurations of the UE.

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

[0034] Figure 3An exemplary base station 300 according to various exemplary embodiments is shown. Base station 300 may represent any other access node through which gNB 120A or UE 110 can establish connections and manage network operations.

[0035] Base station 300 may include processor 305, memory arrangement 310, input / output (I / O) devices 315, transceiver 320, and other components 325. Other components 325 may include, for example, audio input devices, audio output devices, batteries, data acquisition devices, ports for electrically connecting base station 300 to other electronic devices, etc.

[0036] Processor 305 may be configured to execute multiple engines of base station 300. For example, engines may include redcap access control engine 330 and random access engine 335. Redcap access control engine 330 may perform various operations related to instructing base station 300 and / or whether the frequency band in which base station 300 operates is configured to provide network access to redcap devices. Random access engine 335 may perform various operations related to the random access process, including but not limited to determining whether a device is a redcap device or a non-redcap device and indicating whether to enable or disable certain features related to explicit redcap device identification.

[0037] The engines 330 and 335 described above, each acting as an application (e.g., a program) executed by processor 305, are merely exemplary. The functions associated with engines 330 and 335 may also be represented as separate components of base station 300, or as modular components coupled to base station 300, such as integrated circuits with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. Furthermore, in some base stations, the functions described for processor 305 are distributed among multiple processors (e.g., baseband processor, application processor, etc.). Exemplary implementations can be implemented according to any of these or other configurations of the base station.

[0038] Memory 310 may be a hardware component configured to store data related to operations performed by base station 300. I / O device 315 may be a hardware component or port enabling a user to interact with base station 300. Transceiver 320 may be a hardware component configured to exchange data with UE 110 and any other UE in system 100. Transceiver 320 may operate on a variety of different frequencies or channels (e.g., a set of consecutive frequencies). Therefore, transceiver 320 may include one or more components (e.g., radio components) to enable data exchange with various networks and UEs.

[0039] As will be described in more detail below, exemplary embodiments introduce various ways in which UE 110 can identify itself as a redcap device of the network. Several different redcap device types may exist. For example, the general group of redcap devices may be classified into a first type of redcap device or a second type of redcap device that differs from the first type. Throughout this specification, references may be made to “redcap device type 1” and “redcap device type 2” to illustrate the concepts of different redcap device types. However, these terms are provided for illustrative purposes only. Exemplary embodiments may utilize any type of labeling or classification to distinguish different redcap device types. Furthermore, those skilled in the art will understand how the exemplary concepts described herein apply to scenarios where only one redcap device type exists and scenarios where more than two redcap device types exist.

[0040] From the network's perspective, a UE can be identified as a redcap device type based on one or more UE complexity reduction features. These features may include, but are not limited to, maximum bandwidth, multiple receive (RX) antenna branches, maximum number of downlink multiple-input multiple-output (MIMO) layers, maximum downlink modulation order (e.g., quadrature amplitude modulation (QAM)), and HD FDD capability. Each redcap device type definition can be hardcoded into a protocol, standard, or specification such that when the UE 110 indicates or reports its redcap device type to the network, the network knows the UE complexity reduction features and / or physical layer parameter values ​​associated with that redcap device type.

[0041] In one approach, the redcap device type can be defined based on the maximum bandwidth (e.g., 20 MHz for FR1, 100 MHz for FR2, etc.). Therefore, in this approach, when UE 110 identifies itself as a specific type of redcap device, the only UE complexity reduction characteristic inferred by the network is the maximum bandwidth. This ensures that the network knows the appropriate bandwidth scheduled for messages 3 (Msg3) and 4 (Msg4) during initial access. Other relevant UE complexity reduction characteristics can be reported to the network via UE capability information.

[0042] In another approach, a redcap device type can be defined based on a set of two or more UE complexity reduction features supported by the redcap device type. For example, redcap device type 1 could support a maximum bandwidth (w) MHz for FR1 and a maximum bandwidth (x) MHz for FR2, a maximum modulation order (y) QAM, HD FDD capability, Time Division Duplex (TDD) capability, and a minimum number (z) of RX branches. Therefore, when UE 110 identifies itself as this type of redcap device, the network can infer that UE 110 is configured with a set of UE complexity reduction features and / or physical layer parameter values ​​associated with the redcap device type.

[0043] Figure 4 Signaling diagram 400 is shown, illustrating scenarios in which various enhancements to the redcap device can be implemented. However, exemplary implementations are not limited to the scenarios depicted in signaling diagram 400. The exemplary techniques described herein can be used in conjunction with currently implemented redcap mechanisms, future implementations of redcap mechanisms, or independently of other redcap mechanisms.

[0044] Signaling diagram 400 includes UE 110 and gNB 120A. In diagram 405, UE 110 receives a signal from gNB 120A. This signal may be, for example, a Master Information Block (MIB), Synchronization Signal (SS), Physical Broadcast Channel (PBCH) payload, System Information Block (SIB), Downlink Control Information (DCI), Reference Signal, or any other signal that can be received by a UE not in a Radio Resource Control (RRC) connected state. As will be described in more detail below, this signal may indicate to UE 110 whether the redcap device is prohibited from using gNB 120A and / or its frequency band for cell access.

[0045] In diagram 410, UE 110 can perform an access denial check. Those skilled in the art will understand that an access denial procedure can be triggered when UE 110 wants to transition to an RRC connected state or in response to any other suitable condition. In signaling diagram 400, it is assumed that gNB 120A is configured to provide network access to redcap UEs. However, if the access denial check instructs UE 110 to prohibit UE 110 from camping on gNB 120A, UE 110 can search for different cells and / or frequency bands configured to provide access to redcap devices.

[0046] As described above, in one aspect, exemplary embodiments relate to introducing techniques for controlling access to redcap devices. In one technique, the MIB can be configured to indicate whether a redcap device type is prohibited from entering a cell and / or frequency band. For example, sparse bits in the MIB payload can be reused to indicate that a cell and / or frequency band is prohibited for a redcap UE. When the bit is set to a first value (e.g., 0), it can indicate that the redcap device type is prohibited from reserving on the cell and / or frequency. When the bit is set to a second value (e.g., 1), it can indicate that the cell and / or frequency is configured to provide access to the redcap device type. The sparse bit can be reused as a “RedcapCellBarred” information element (IE) or any other suitable type of indication. Thus, within the context of signaling diagram 400, at 405, a RedcapCellBarred IE can be received as part of the MIB and at least partially provides a basis for access prohibition checks at 410.

[0047] In another technique, the PBCH payload can be configured to indicate whether a redcap device type is barred from entering a cell and / or frequency. For example, reserved bits in the PBCH payload (e.g., a(6), a(7), etc.) can be configured to indicate that a cell and / or frequency band is barred for use by a redcap UE. When the reserved bit is set to a first value (e.g., 0), it can indicate that the redcap device type is barred from being reserved on a cell and / or frequency. When the reserved bit is set to a second value (e.g., 1), it can indicate that the cell and / or frequency is configured to provide access to the redcap device type. The reserved bit can be reinterpreted as a “RedcapCellBarred” IE or any other appropriate type of indication. Thus, within the context of signaling diagram 400, in 405, a RedcapCellBarred IE can be received as part of the PBCH payload (e.g., SSB) and in 410, it provides at least partially the basis for access barring checks.

[0048] In some implementations, multiple reserved bits in the PBCH payload can be utilized. A first reserved bit can be used as the RedcapCellBarred IE for redcap device type 1, and a second reserved bit can be used as the RedcapCellBarred IE for redcap device type 2. In another example, when the redcap device type can be equipped with either a 1-RX antenna branch or a 2-RX branch, the first reserved bit can be used as the RedcapCellBarred IE for the redcap device type with the 1-RX antenna branch, and the second reserved bit can be used as the RedcapCellBarred IE for the redcap device type with the 2-RX antenna branch.

[0049] In another technique, the DCI can be configured to indicate whether a redcap device type is prohibited from entering a cell and / or frequency. For example, in DCI format 1_0 (which can be used to schedule SIB messages), 15 reserved bits may exist, where Cyclic Redundancy Check (CRC) is scrambled by System Information (SI) – Radio Network Temporary Identifier (RNTI). One or more of the 15 reserved bits in DCI format 1_0 can be configured to indicate that a cell and / or frequency is prohibited for use by a redcap UE. When a reserved bit is set to a first value (e.g., 0), it can indicate that a redcap device type is prohibited from being reserved on a cell and / or frequency. When a reserved bit is set to a second value (e.g., 1), it can indicate that a cell and / or frequency is configured to provide access to a redcap device type. Similar to the example provided above, multiple bits can be utilized, each bit for a different redcap device type and / or multiple RX antenna branches on the UE 110 side. In the context of signaling diagram 400, gNB 120A is configured to provide an indication of access to the redcap UE, which can be received in 405 via DCI format 1_0 and, at least in part, provide a basis for access prohibition checks in 410.

[0050] Figure 5 An example of DCI format 1_0 configured for redcap device access control is shown. In this example, for redcap access control, 2 of the 15 reserved bits are considered. One advantage of the DCI format 1_0 method is that once the DCI format 1_0 is decoded and the access prohibition information is known, the UE 110 can stop SIB1 acquisition.

[0051] In another technique, an IE (e.g., a RedcapCellBarred IE or a similar indication) can be added to SIB1 as an extension. When the IE is set to a first value (e.g., 0), it can indicate that redcap device type reservations are prohibited on cells and / or frequencies. When the IE is set to a second value (e.g., 1), it can indicate that cells and / or frequencies are configured to provide access to redcap UEs or specific redcap device types. In the context of signaling diagram 400, the IE can be received as part of SIB1 in 405, and in 410 it provides at least partially the basis for access prohibition checks.

[0052] In another technique, implicit indications based on one or more conditions can be utilized. For example, if the initial downlink or uplink bandwidth portion (BWP) configured in SIB1 has a bandwidth wider than the maximum bandwidth supported by the redcap device type, and there is no separate downlink or uplink BWP configured in SIB1 for the redcap device, then UE110 can be assumed to be blocked by the cell and / or frequency band. However, if the initial downlink and uplink BWPs are equal to the maximum bandwidth of the redcap device type, or if there are separate downlink and uplink BWPs for the redcap device, then the cell and / or frequency band can be indicated to provide access to the redcap UE or a specific redcap device type. In the context of signaling diagram 400, these conditions can be indicated by the SIB1 received in 405.

[0053] Following the access denial check, UE 110 and gNB 120A can participate in the random access procedure. Signaling diagram 400 illustrates a 4-step random access procedure (e.g., Msg1, Msg2, Msg3, Msg4). However, the exemplary implementation is not limited to a 4-step random access procedure. Those skilled in the art will understand how the exemplary implementation can be applied to a 2-step random access procedure (e.g., MsgA, MsgB). For example, the techniques described above regarding Msg1 in the 4-step random access procedure can be applied to MsgA in the 2-step random access procedure, and the techniques described above regarding Msg3 in the 4-step random access procedure can be applied to MsgB in the 2-step random access procedure. Furthermore, those skilled in the art will understand that each of these messages (e.g., Msg1, Msg2, Msg3, Msg4, MsgA, MsgB) is defined in the 3GPP standard.

[0054] The following description of 415-430 provides a general overview of signaling exchange for a four-step random access procedure. Following the description of 415-430, specific examples of exemplary techniques related to a redcap device that identifies itself as a redcap device during the random access procedure are provided. In 415, UE 110 transmits Msg1 to gNB 120A. Msg1 may include a PRACH preamble. In 420, gNB 120A may transmit Msg2 to UE 110 in response to Msg1. Msg2 may include a random access response (RAR), which may include a random access preamble ID (RAPID), a temporary RNTI, and an uplink grant for scheduling the Physical Uplink Shared Channel (PUSCH) (e.g., Msg3). In 425, UE 110 transmits Msg3 to gNB 120A via PUSCH. In 430, gNB 120A transmits Msg4 to UE 110. Msg4 can represent a race-resolved message.

[0055] As described above, the exemplary implementation introduces a technique for UE 110 to identify itself as a redcap device via early indication (e.g., during a random access procedure, before configuring an RRC connection mode, etc.). In one approach, the network can identify UE 110 as a redcap device type based on selecting the uplink PRACH resource associated with the redcap UE. For this approach, it is assumed that the initial uplink BWP configured by SIB1 is shared by both redcap and non-redcap devices.

[0056] In some implementations, a dedicated PRACH resource set for the redcap UE (e.g., random access timing (RO), PRACH slots, etc.) and a dedicated PRACH resource set for the non-redcap UE can be frequency-division multiplexed (FDM) within a shared initial uplink BWP. Therefore, a first portion of the initial uplink BWP can be dedicated to the redcap UE, and a second portion of the initial BWP can be dedicated to the non-redcap UE. The redcap device RO can be indicated to UE110 via one or more RRC parameters in SIB1. For example, a first IE (e.g., msg1-FrequencyStart-Redcap) can indicate the starting frequency of the PRACH resource set within the initial uplink BWP for the redcap UE. Other IEs can indicate the number of ROs in the PRACH resource set for the redcap UE, the starting frequency of the PRACH resource set within the initial uplink BWP for the non-redcap UE, and the number of ROs within the PRACH resource set for the non-redcap UE. Alternatively, resource block (RB) offset values ​​can be signaled to indicate the gap between the starting physical resource block (PRB) of the PRACH resource set for redcap UEs and the starting PRB of the initial uplink BWP, or the starting or ending PRB of the PRACH resource set for non-redcap UEs.

[0057] To provide an example within the context of signaling diagram 400, prior to 415 (e.g., 405 or a signal not shown), UE 110 may receive SIB1 from gNB 120A. SIB1 may indicate that the uplink BWP of gNB 120A is configured to be shared by both redcap and non-redcap UEs. Furthermore, SIB1 may include one or more parameters related to the FDM configuration of dedicated PRACH resources for redcap UEs and dedicated PRACH resources within the initial BWP for non-redcap UEs. In 415, UE 110 may select an RO from the dedicated PRACH resource set for redcap UEs to transmit Msg1. When gNB 120A receives Msg1 from UE 110, the network can infer that UE 110 is a redcap device type because the RO used for transmitting Msg1 is configured as a dedicated PRACH resource for redcap UEs. The RO may be selected by UE 110 based on the association between the RO, SSB, and downlink beam. However, the basis for selecting a specific redcap PRACH resource is beyond the scope of the exemplary implementation. Instead, the exemplary implementation involves UE 110 identifying itself as a redcap device type by using PRACH resources for uplink transmissions.

[0058] Figure 6 An example of an initial uplink BWP with a dedicated PRACH resource set for redcap UEs and a dedicated PRACH resource set for non-redcap UEs is shown. In this example, a frequency start indication (e.g., msg1-FrequencyStart-Redcap) and an offset (starting PRB relative to the initial uplink BWP) are shown. However, in practical operating scenarios, only one of these parameters may be provided. Furthermore, the parameter "msg1-FDM-Redcap" indicates the number of IEs indicating the number of redcap ROs, and the parameter "msg1-FDM" indicates the number of IEs indicating the number of non-redcap ROs. FDM technology provides the gNB 120A with flexibility in controlling the location of redcap PRACH resources in the frequency domain and the PRACH overhead for redcap devices.

[0059] In some implementations, to minimize RRC signaling overhead, the PRACH resource set for the redcap UE and the PRACH resource set for the non-redcap UE can have the same PRACH capacity (e.g., number or ROs). This allows UE 110 to determine the number of ROs in the PRACH resource set for the redcap UE and the number of ROs in the non-redcap PRACH resource set for the non-redcap UE using a single parameter indicated in SIB1 (e.g., “Msg1-FDM”, etc.). Furthermore, to minimize RRC signaling overhead, the PRACH resources for the redcap UE can be continuously mapped from the last PRB in the PRACH resource set for the non-redcap UE in the frequency domain. Therefore, an explicit indication of the start frequency of the PRACH resource set for the redcap UE (e.g., “msg1-FrequencyStart-redcap”, etc.) may not be utilized, as UE 110 can infer the start PRB from the PRACH resource configuration for the non-redcap device.

[0060] Continuing with the method by which UE 110 identifies itself as a redcap device type based on selecting uplink PRACH resources from a dedicated PRACH resource set for redcap UEs, in some implementations, the dedicated RO for redcap UEs and the dedicated RO for non-redcap UEs can be time-division multiplexed (TDM). As described above, for this method, it is assumed that the initial uplink BWP configured by SIB1 is shared by both redcap and non-redcap devices. Therefore, compared to FDM technology, which uses the frequency location of Msg1 (or MsgA) to indicate the device type, TDM technology indicates the device type based on when UE 110 transmits Msg1 (or MsgA).

[0061] Figure 7 Examples of TDM-specific PRACH resource sets for redcap UEs and dedicated PRACH resource sets for non-redcap UEs, according to various exemplary embodiments, are shown. In this example, PRACH preamble format A3 is configured for redcap RO, and PRACH preamble format A2 is configured for non-redcap RO. Therefore, in Figure 7 In the diagram, subframe number (SFN) indices 0, 2, 4, and 6 are shown to include redcap ROs, while SFN indices 1 and 5 are shown to include non-redcap ROs. Providing the network with flexibility to implement different PRACH preamble formats or different temporal RO densities for redcap and non-redcap devices can be beneficial. For example, there may be scenarios where redcap and non-redcap devices have different RACH load requirements.

[0062] During operation, a first PRACH configuration index value can be provided to UE 110 to indicate the PRACH format for non-redcap UEs, and a second PRACH configuration index value can be provided to UE 110 to indicate the PRACH format for redcap UEs. Figure 7 In the code, these parameters are identified as "prach-ConfigurationIndex" and "prach-ConfigurationIndex-redcap". Figure 7 The values ​​shown refer to the mapping to the 3GPP TS 38.211 random access configuration. However, exemplary embodiments are not limited to this. Figure 7 The example shown can be implemented with any appropriate TDM scheme for the initial uplink BWP, which is configured for PRACH resources of redcap UEs and PRACH resources of non-redcap UEs.

[0063] In addition, an IE representing the offset value of the TDM arrangement can be provided in SIB1. The offset value can be configured to ensure that conflicts between redcap ROs and non-redcap ROs are avoided. The offset value can be in radio frames (e.g., SFNs), subframes, time slots, or any other suitable unit. In some implementations, an offset value can be provided even if the prach-ConfigIndex-redcap parameter is not present. In this scenario, the prach-ConfigIndex value can be applied to both redcap and non-redcap UEs to determine the location of their respective ROs in the time domain.

[0064] Continuing with the method by which UE 110 identifies itself as a redcap device based on selecting uplink PRACH resources from a dedicated PRACH resource set for Redcap UEs, in some implementations, the preamble within the RO can be divided between redcap and non-redcap devices.

[0065] Figure 8 An example of dividing the preamble within the RO is shown between redcap and non-redcap devices. Figure 8 In this example, the initial uplink BWP for non-redcap UEs overlaps with the initial uplink BWP for redcap UEs. In this example, it is assumed that there are 8 Synchronization Signal Blocks (SSBs). Those skilled in the art will understand that an SSB-RO mapping can exist for beam selection. For example, UE 110 can perform measurements on SSBs and indicate the selected beam by transmitting on the ROs associated with the SSBs. Since there are 8 SSBs, 8 ROs are also configured. In this example, non-redcap UEs can use any RO with indices 0-7, where ROs with indices 0-3 are shared with redcap UEs, and ROs with indices 4-7 are dedicated to non-redcap UEs. Redcap UEs can use any RO with indices 0-3.

[0066] Within a Preamble (RO) that can be used by either a redcap UE or a non-redcap UE (e.g., ROs 0-3), the preamble can be divided between the redcap UE and the non-redcap UE. Therefore, a first portion of the preamble within the RO can be used by the redcap UE, and a second distinct portion of the preamble within the RO can be used by the non-redcap UE. In this example, it is assumed that there are 64 preambles. However, this value is provided for illustrative purposes only, and the exemplary implementation can be applied to any appropriate number of preambles within the RO. This parameter can be signaled to the UE 110 via the IE “totalNumberOfRA-Preambles” in SIB1 or by any other suitable means.

[0067] To provide an example within the context of signaling diagram 400, prior to 415 (e.g., 405 or a signal not shown), UE 110 may receive SIB1 from gNB 120A. SIB1 may indicate that the uplink BWP of gNB 120A is configured to be shared by both redcap and non-redcap UEs. Furthermore, SIB1 may include one or more parameters relating to how preambles within one or more ROs are partitioned between redcap and non-redcap UEs. UE 110 may select the RO configured for the redcap device for transmitting Msg1 at 415. When gNB 120A receives Msg1 from UE 110, the network can infer that UE 110 is a redcap device type because the RO used for transmitting Msg1 is configured as a redcap PRACH resource. The RO may be selected by UE 110 based on the association between the RO, SSB, and downlink beam. However, the basis for selecting a particular redcap PRACH resource is beyond the scope of this exemplary implementation. Alternatively, an exemplary implementation involves UE 110 identifying itself as a redcap device type by using PRACH resources for uplink transmissions (e.g., Msg1, MsgA, etc.).

[0068] To implement the preamble partitioning technique, various parameters were introduced. Figure 9 Table 900 shows Figure 8 This describes a set of example IEs and their corresponding values ​​within the context of the described scenario. However, any references to specific parameters are provided for illustrative purposes only. Different networks may use different names to refer to similar IEs.

[0069] The IE "totalNumberofRA-Preambles-Redcap" represents the total number of preambles used by the redcap UE for contention-based and contention-free random access (e.g., 2-step or 4-step random access) relative to the RACH resources defined in RACH ConfigCommon. The preambles for the redcap UE can be selected from n RA Starting with +1, where n RA It is the index of the last preamble used by a non-redcap UE within the same RO. In some implementations, the IE "totalNumberOfRA-preambids" can indicate the number of preambles used for non-redcap devices within an RO shared by both redcap and non-redcap devices.

[0070] Within a redcap shared by redcap and non-redcap devices, the preamble of each device can be organized into groups (e.g., group A, group B, no contention). Figure 8 An example of such grouping is shown. To enable grouping for redcap devices, the following parameters can be introduced. The UE "ra-Msg3SizeGroupA-Redcap" is introduced to indicate a bit-based block size threshold for transmission, which indicates when UE 110 will use a preamble from group A for the random access procedure. The IE "numberOfRApreamblesgroup A Redcap" can represent the number of contention-based preambles per SSB in group A, which also implicitly indicates the number of contention-based preambles available per SSB in group B. In other implementations, implicit rules can be defined, including the related IEs of "ra-Msg3SizeGroupA" and "numberOfRA-PreamblesGroupA" (in the case of SIB1 configuration), which are typically applied to both redcap and non-redcap UEs.

[0071] The IE parameter “ssb-perRACH-OCcasionAndCB-PreamblesPerSSB-Redcap” can represent two values. The first value conveys information about the number of SSBs per RO, and the second value indicates the number of contention-based preambles per SSB. This parameter provides the network with the flexibility to associate different preamble numbers for redcap UEs and non-redcap UEs within the same beam (e.g., SSB).

[0072] In addition, various parameters are introduced to represent the coverage enhancement (CE) level for both redcap and non-redcap devices. A reference signal received power (RSRP) threshold (e.g., "RSRP-Threshold-Redcap") for the redcap UE in the CE can be introduced to select preamble resources. In some implementations, a single IE (e.g., "RSRP-Threshold") can be configured in SIB1 and is typically applied to both redcap and non-redcap devices.

[0073] For TDM ROs, there may be CE mode indicators for non-redcap UEs (e.g., "prach-ConfigIndex-CE") and CE mode indicators for redcap UEs (e.g., "prach-ConfigIndex-Redcap-CE"). For FDM ROs, there may be CE mode indicators for non-redcap UEs (e.g., "msg1-FrequencyStart-CE") and CE mode indicators for redcap UEs (e.g., "msg1-FrequencyStart-Redcap-CE"). For preamble partitioning within the RO, there may be CE mode indicators for non-redcap UEs (e.g., "totalNumberOfRAPreambles-CE") and CE mode indicators for redcap UEs (e.g., "totalNumberOfRAPreambles-Redcap-CE"). In this example, the preamble for the redcap UE starts from n RA Starting with +1, where n RA It is the index of the last preamble used by a non-redcap UE in the same RO, including preambles used by non-redcap UEs for CE indication when consecutive preambles are used for CE indication.

[0074] Figure 10 An example is shown where a preamble is partitioned within the RO to identify redcap devices with and without CE, as well as non-redcap devices with and without CE. Several parameters can be introduced to enable this feature. Figure 11 Table 1100 shows Figure 10 Examples of these parameters and their corresponding values ​​within the context of the scene being described.

[0075] exist Figure 10In this example, it is assumed that there are up to 64 preambles within the RO. The preambles can be divided into a first group 1010 for non-redcap UEs and a second group 1020 for redcap UEs. The first group 1010 includes a set of consecutive preambles for non-redcap UEs using the RRC parameters shown in Table 1100. In this example, as indicated by the parameter “totalNumberofRA-Preambles”, a non-redcap UE without a CE has 24 preambles, and as indicated by the parameter “ssb-perRACH-OccasionAndCB-PreamblesPerSSB”, 16 preambles are associated with a single SSB for contention-based random access. Furthermore, as indicated by the parameter “totalNumberOfRA-Preambles-CE”, a non-redcap UE with a CE has 16 preambles. Therefore, the first group 1010 includes a set of preambles, wherein a first part of the preamble is used for contention-based random access by a non-redcap UE without a CE, a second part of the preamble is used for contention-free random access by a non-redcap UE without a CE, and a third part of the preamble is used for a non-redcap UE with a CE.

[0076] The second group 1020 includes a set of consecutive preambles for redcap UEs using the RRC parameters shown in Table 1100. In this example, as indicated by the parameter “totalNumberOfRA-Preambles-Redcap”, a redcap UE without a CE has 12 preambles, and as indicated by the parameter “ssb-perRACH-OccasionAndCB-PreamblesPerSSB-Redcap”, 8 preambles are associated with a single SSB for contention-based random access. Furthermore, as indicated by the parameter “totalNumberOfRA-Preambles-Redcap-CE”, 8 preambles are used for redcap UEs with a CE. Therefore, the second group 1020 includes a set of preambles where the first portion of the preamble is used for contention-based random access by a redcap UE without a CE, the second portion of the preamble is used for contention-free random access by a redcap UE without a CE, and the third portion of the preamble is used for a redcap UE with a CE.

[0077] Exemplary implementations also introduce techniques for early indication of the redcap device type that is not based on the selected PRACH resource. In one technique, a redcap device type indicator can be introduced for the Msg3 payload. For example, a bit flag can be added to the Msg3 payload to indicate whether the device is a redcap device or a non-redcap device.

[0078] In another technique, a dedicated Logical Channel ID (LCID) can be introduced to identify the device type, instead of using any bits in the Msg3 payload. The LCID can be configured as a Media Access Control (MAC) Service Data Unit (SDU) for Msg3. For example, a redcap UE can indicate a unique LCID value for a redcap device in the Common Control Channel (CCCH). A non-redcap UE can indicate the LCID associated with a non-redcap device in the CCH.

[0079] Exemplary implementations also introduce techniques for enabling and disabling early indication for redcap UEs. In one technique, a dedicated redcap PRACH resource configuration exists in SIB1 (RO or preamble) that can indicate whether early indication for the redcap device type is enabled. Alternatively, a new flag IE (e.g., "enableMsg3Indicator") can be introduced in SIB1 and used to enable Msg3 early indication. In some implementations, the flag IE can be used when a dedicated redcap PRACH resource configuration is not present in SIB1.

[0080] In some implementations, frequency hopping for Physical Uplink Control Channel (PUCCH) and PUSCH transmissions during the initial access procedure or random access procedure can be disabled for redcap UEs. This can be implemented to avoid uplink resource partitioning.

[0081] Example

[0082] In a first embodiment, a processor of a base station is configured to perform operations including transmitting a System Information Block (SIB) to one or more User Equipments (UEs) and receiving an indication of a redcap device type from the UE during a random access procedure, wherein the indication is associated with a UE configuration including one or more UE complexity reduction features.

[0083] In a second embodiment, according to the processor of the first embodiment, the operation further includes determining, based on the indication, that the UE is associated with a reduced maximum bandwidth, wherein the reduced maximum bandwidth is a unique UE complexity reduction feature associated with the indication.

[0084] In a third embodiment, according to the processor of the first embodiment, the operation further includes transmitting a signal before receiving the indication of the redcap device type, the signal including an indication of whether the redcap device type is prohibited from cell access from the base station.

[0085] In the fourth embodiment, according to the processor of the third embodiment, the signal is one of the SIB, the Master Information Block (MIB), the Physical Broadcast Channel (PBCH) payload, or the Downlink Control Information (DCI).

[0086] In the fifth embodiment, according to the processor of the first embodiment, wherein the SIB indicates that the initial uplink bandwidth portion (BWP) will be shared by the redcap device and the non-redcap device.

[0087] In the sixth embodiment, according to the processor of the fifth embodiment, the initial uplink BWP includes a set of dedicated redcap random access channel (RACH) timings (ROs) and a set of dedicated non-redcap ROs multiplexed in frequency division multiplexing (FDM).

[0088] In the seventh embodiment, according to the processor of the sixth embodiment, wherein the SIB includes one or more information elements (IEs) indicating the frequency position of the dedicated redcap RO within the initial uplink BWP and the frequency position of the dedicated non-redcap RO within the initial uplink BWP.

[0089] In the eighth embodiment, according to the processor of the sixth embodiment, wherein the SIB includes an information element (IE) indicating a resource block (RB) offset value, the RB offset value being an element provided by the redcap UE to determine the frequency position of the dedicated redcap RO relative to the starting RB of the dedicated non-redcap RO within the initial uplink BWP.

[0090] In the ninth embodiment, the processor according to the sixth embodiment is provided, wherein a single information element (IE) provides an indication of the number of ROs in the set of dedicated redcap ROs and the number of ROs in the set of dedicated non-redcap ROs.

[0091] In the tenth embodiment, according to the processor of the fifth embodiment, the initial uplink BWP includes a set of dedicated redcap random access channel (RACH) timings (ROs) and a set of dedicated non-redcap ROs multiplexed in a time-division multiplexing (TDM) manner.

[0092] In the eleventh embodiment, the processor according to the tenth embodiment, wherein the SIB includes an information element (IE) indicating a Physical Random Access Channel (PRACH) configuration index value specific to the redcap device type.

[0093] In the twelfth embodiment, according to the processor of the tenth embodiment, the SIB includes an information element (IE) indicating the physical random access channel (PRACH) configuration index value to be applied by both the redcap UE and the non-redcap UE, and the SIB also includes an IE indicating the time-domain location of the dedicated redcap RO and the offset value of the dedicated non-redcap UE.

[0094] In the thirteenth embodiment, according to the processor of the fifth embodiment, the initial uplink BWP includes one or more random access channel (RACH) timings (ROs) to be shared by the redcap UE and the non-redcap UE, each of the one or more ROs including a set of dedicated redcap preambles and a set of dedicated non-redcap preambles.

[0095] In the fourteenth embodiment, the processor according to the thirteenth embodiment, wherein the SIB includes an information element (IE) indicating the total number of preambles for contention-based and contention-free random access allocations for redcap device types.

[0096] In the fifteenth embodiment, the processor according to the thirteenth embodiment, wherein the set of dedicated redcap preambles is configured in three separate groups, and wherein the SIB includes one or more information elements (IEs) indicating the number of preambles in the first group, the number of preambles in the second group, the number of synchronization signal blocks (SSBs) per RO, and the number of contention-based preambles per SSB.

[0097] In the sixteenth embodiment, according to the processor of the thirteenth embodiment, the set of dedicated redcap preambles includes multiple preambles specifically for redcap UEs operating in coverage enhancement (CE) mode.

[0098] In the seventeenth embodiment, according to the processor of the first embodiment, the indication of the redcap device type is an information element (IE) received as part of the payload of message 3 (Msg3) during the random access procedure.

[0099] In the eighteenth embodiment, according to the processor of the first embodiment, the indication of the redcap device type is a unique logical channel ID (LCID) provided as part of message 3 (Msg3) during the random access procedure.

[0100] In the nineteenth embodiment, the processor of the first embodiment, wherein the SIB includes an indication of a dedicated redcap Physical Random Access Channel (PRACH) resource.

[0101] In the twentieth embodiment, according to the processor of the first embodiment, wherein the SIB includes an Information Element (IE) that indicates the redcap device type in message 3 (Msg3).

[0102] In the twenty-first embodiment, the processor according to the first embodiment is wherein frequency hopping for Physical Uplink Control Channel (PUCCH) transmission and Physical Uplink Shared Channel (PUSCH) transmission is disabled during the random access procedure.

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

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

[0105] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0106] It will be apparent to those skilled in the art that various modifications can be made to this disclosure without departing from its spirit or scope. Therefore, this disclosure is intended to cover all modifications and variations thereof, provided that such modifications and variations are within the scope of the appended claims and their equivalents.

Claims

1. A processor of a base station, the processor configured to perform operations comprising: transmitting a system information block (SIB) to one or more user equipments (UEs), wherein a first bit of the SIB is configured to indicate whether a reduced capability (redcap) device type equipped with a single receive (RX) antenna branch is barred for cell access by the base station and a second bit of the SIB is configured to indicate whether a redcap device type equipped with two RX antenna branches is barred for cell access by the base station; and receiving, from a UE during a random access procedure, an indication of a redcap device type in a common control channel (CCH), wherein the indication is a logical channel ID (LCID) that is dedicated to redcap device types and is associated with a UE configuration that includes one or more UE complexity reduction features.

2. The processor of claim 1, wherein the one or more UE complexity reduction features associated with the indication include only a reduced maximum bandwidth.

3. The processor of claim 1, the operations further comprising: after receiving the indication of the redcap device type, receiving UE capability information that also includes a UE complexity reduction feature.

4. The processor of claim 1, the operations further comprising: transmitting a physical broadcast channel (PBCH) payload that includes one or more bits configured to indicate whether the redcap device type is barred for cell access by the base station.

5. The processor of claim 1, wherein the SIB includes an information element (IE) that indicates whether the redcap device type is barred for cell access by the base station.

6. The processor of claim 1, wherein the SIB indicates that an initial uplink bandwidth part (BWP) is to be shared by redcap devices and non-redcap devices.

7. The processor of claim 6, wherein the initial uplink BWP includes a set of dedicated redcap random access channel (RACH) occasions (ROs) and a set of dedicated non-redcap ROs multiplexed in a frequency division multiplexing (FDM) manner.

8. The processor of claim 7, wherein the SIB includes one or more information elements (IEs) that indicate a frequency location of the dedicated redcap ROs within the initial uplink BWP.

9. The processor of claim 7, wherein a single information element (IE) provides an indication of a number of ROs in the set of dedicated redcap ROs and a number of ROs in the set of dedicated non-redcap ROs.

10. The processor of claim 6, wherein the initial uplink BWP includes a set of dedicated redcap random access channel (RACH) occasions (ROs) and a set of dedicated non-redcap ROs multiplexed in a time division multiplexing (TDM) manner. ​ 11. The processor of claim 10, wherein the SIB includes an information element (IE) indicating a physical random access channel (PRACH) configuration index value specific to the redcap device type.

12. The processor of claim 10, wherein the SIB includes an information element (IE) indicating a physical random access channel (PRACH) configuration index value to be applied by both redcap UEs and non-redcap UEs, and wherein the SIB further includes an IE indicating an offset value for determining a time domain location of the dedicated redcap RO.

13. The processor of claim 6, wherein the initial uplink BWP includes one or more random access channel (RACH) occasions (ROs) to be shared by redcap UEs and non-redcap UEs, each of the one or more ROs including a set of dedicated redcap preambles and a set of dedicated non-redcap preambles.

14. The processor of claim 13, wherein the SIB includes an information element (IE) indicating a total number of preambles allocated for contention-based random access and contention-free random access for redcap device types.

15. The processor of claim 13, wherein the set of dedicated redcap preambles is configured in three separate groups, and wherein the SIB includes one or more information elements (IEs) indicating a number of preambles in a first group, a number of preambles in a second group, a number of synchronization signal blocks (SSBs) per RO, and a number of contention-based preambles per SSB.

16. The processor of claim 13, wherein the set of dedicated redcap preambles includes a plurality of preambles dedicated to redcap UEs operating in a coverage enhancement (CE) mode.

17. The processor of claim 1, wherein the SIB includes one of: (i) an indication of dedicated redcap physical random access channel (PRACH) resources for random access, or (ii) an information element (IE) indicating that the indication of the redcap device type is to be provided in a message 3 (Msg3).

18. A base station comprising: a transceiver configured to communicate with one or more user equipment (UEs); and the processor of any of claims 1-17.

Images