Techniques for identifying enhanced reduced capability user equipment in wireless network
By introducing the eRedCap indication mechanism in the random access process, the difficulties in eRedCap UE management and identification in the existing technology are solved, the accuracy of resource scheduling and the optimization of equipment performance are achieved, and energy consumption is reduced.
Patent Information
- Application Number
- CN202380093877.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-02-14
- Publication Date
- 2025-09-19
AI Technical Summary
Existing technologies make it difficult to effectively manage and identify enhanced reduced-capability user equipment (eRedCap UE), resulting in improper allocation of network resources and affecting device performance and energy consumption.
By introducing the eRedCap indication mechanism in the random access process, using MAC control elements, RACH partitions, specific PRACH resources and BWP configuration, the UE is allowed to notify the base station that it is an eRedCap UE, thereby guiding the base station to consider its limited capabilities when scheduling resources.
It achieves accurate identification of eRedCap UEs during random access, ensures resource scheduling within their capabilities, reduces equipment complexity and energy consumption, and improves network resource utilization efficiency.
Smart Images

Figure CN120677828A_ABST
Abstract
Description
Technical Field
[0001] The present application relates generally to communication networks, and more particularly to techniques for identifying and managing enhanced reduced capability user equipment in wireless networks. Background Art
[0002] Reduced Capability (RedCap) devices can be used in 3rd Generation Partnership Project (3GPP) networks. These RedCap devices can be used in industrial wireless sensors, video surveillance, or wearable devices. Compared to non-RedCap UEs, RedCap UEs can have fewer receive / transmit antennas, reduced bandwidth, half-duplex frequency division duplexing (instead of full-duplex), relaxed UE processing time, and relaxed UE processing capabilities. BRIEF DESCRIPTION OF THE DRAWINGS
[0003] Figure 1 A network environment according to some embodiments is illustrated.
[0004] Figure 2 A signaling diagram according to some embodiments is illustrated.
[0005] Figure 3 The configuration of bandwidth portions according to some embodiments is illustrated.
[0006] Figure 4 A signaling diagram according to some embodiments is illustrated.
[0007] Figure 5 An operational flow / algorithm structure according to some embodiments is illustrated.
[0008] Figure 6 An operational flow / algorithm structure according to some embodiments is illustrated.
[0009] Figure 7 User equipment according to some embodiments is illustrated.
[0010] Figure 8 A network node according to some embodiments is illustrated. DETAILED DESCRIPTION
[0011] The following detailed description refers to the accompanying drawings. The same reference numerals may be used in different figures to identify the same or similar elements. In the following description, specific details, such as particular structures, architectures, interfaces and / or technologies, are set forth for purposes of illustration and not limitation, so as to provide a thorough understanding of various aspects of some embodiments. However, it will be apparent to those skilled in the art who benefit from this disclosure that various aspects of the various aspects may be practiced in other examples that deviate from these specific details. In some cases, descriptions of well-known devices, circuits and methods are omitted so as not to obscure the description of various aspects due to unnecessary details. For the purposes of this document, the phrase "A or B" means (A), (B) or (A and B); and the phrase "based on A" means "based at least in part on A", for example, it can be "based only on A" or it can be "based in part on A".
[0012] The following is a glossary of terms that may be used in this disclosure.
[0013] As used herein, the term "circuit" refers to, is part of, or includes a hardware component such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or memory (shared, dedicated, or group) configured to provide the described functionality, an application specific integrated circuit (ASIC), a field programmable device (FPD) (e.g., a field programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high capacity PLD (HCPLD), a structured ASIC, or a programmable system on a chip (SoC)), and / or a digital signal processor (DSP). In some aspects, a circuit may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuit" may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) and program code for executing the functionality of the program code. In these aspects, the combination of hardware elements and program code may be referred to as a specific type of circuit.
[0014] As used herein, the term "processor circuit" refers to, is part of, or includes circuitry that is capable of sequentially and automatically performing a series of arithmetic or logical operations; or recording, storing, or transferring digital data. The term "processor circuit" may refer to an application processor; a baseband processor; a central processing unit (CPU); a graphics processing unit; a single-core processor; a dual-core processor; a triple-core processor; a quad-core processor; or any other device capable of executing or otherwise operating computer-executable instructions (such as program code); a software module; or a functional process.
[0015] As used herein, the term "interface circuitry" refers to circuitry that enables, is part of, or includes circuitry that enables information exchange between two or more components or devices. The term "interface circuitry" may refer to one or more hardware interfaces; for example, a bus, an I / O interface, a peripheral component interface, or a network interface card.
[0016] As used herein, the term "user equipment" or "UE" refers to a device that has radio communication capabilities and can represent a remote user of network resources in a communication network. Furthermore, the terms "user equipment" or "UE" may be considered synonymous and may be referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device that includes a wireless communication interface.
[0017] As used herein, the term "computer system" refers to any type of interconnected electronic devices, computing devices, or components thereof. Additionally, the term "computer system" or "system" may refer to various components of a computer that are communicatively coupled to one another. Furthermore, the term "computer system" or "system" may refer to multiple computing devices or multiple computing systems that are communicatively coupled to one another and configured to share computing resources or networked resources.
[0018] As used herein, the term "resource" refers to a physical or virtual device, a physical or virtual component within a computing environment, or a physical or virtual component within a specific device, such as computer equipment, mechanical equipment, memory space, processor / CPU time, processor / CPU utilization, processor and accelerator load, hardware time or utilization, power, input / output operations, ports or network sockets, channel / link allocation, throughput, memory utilization, storage, network, database, and application, workload units, etc. "Hardware resources" may refer to computer, storage, or network resources provided by physical hardware elements. "Virtualized resources" may refer to computer, storage, or network resources provided by a virtualization infrastructure to an application, device, system, etc. The terms "network resources" or "communication resources" may refer to resources accessible to a computer device / system via a communication network. The term "system resource" may refer to any type of shared entity that provides a service and may include computing resources or network resources. System resources may be considered a set of coherent functions, network data objects, or services that can be accessed through a server, where such system resources reside on a single host or multiple hosts and can be clearly identified.
[0019] As used herein, the term "channel" refers to any tangible or intangible transmission medium for conveying data or data streams. The term "channel" may be synonymous or equivalent with "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," or any other similar term representing a path or medium through which data is conveyed. Additionally, as used herein, the term "link" refers to a connection between two devices for sending and receiving information.
[0020] As used herein, the terms "instantiate," "instantiate," and the like refer to the creation of an instance. "Instance" also refers to a concrete occurrence of an object, which may occur, for example, during the execution of program code.
[0021] The term "connected" may mean that two or more elements at a common communication protocol layer have an established signaling relationship with each other through a communication channel, link, interface, or reference point.
[0022] As used herein, the term "network element" refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with or referred to as a networked computer, networking hardware, network equipment, network node, virtualized network function, etc.
[0023] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to the individual contents of an information element or a data element that contains the contents. An information element may include one or more additional information elements.
[0024] Figure 1 A network environment 100 according to some embodiments is illustrated. The network environment 100 may include a UE 104 and a base station 108. The base station 108 may provide one or more radio access cells through which the UE 104 may communicate with the base station 108. The base station 108 may provide an air interface compatible with 3GPP technical specifications, such as those defining fifth generation (5G) New Radio (NR) or subsequent system standards. The base station 108 may provide the UE 104 with access to other networks (e.g., a 3GPP core network, a data network, etc.). Depending on the technology of the access and core networks, the base station may be referred to as an eNB, gNB, ng-NB, etc.
[0025] The UE 104 can establish a connection with the base station 108 through a random access (RA) procedure. The RA procedure can be triggered based on multiple events, including, for example, initial access from a radio resource control (RRC) idle state, an RRC connection reestablishment or resumption process, small data transmission in an RRC inactive state, etc. The RA procedure can be a 4-step RA type or a 2-step RA type. The 4-step RA type or the 2-step RA type can use contention-based random access (CBRA) or contention-free random access (CFRA). Generally speaking, unless otherwise described herein, the RA procedure can be similar to the RA procedure described in 3GPP 38.300 v17.3.0 (2023-01-13).
[0026] To reduce device complexity and energy consumption, Release 17 3GPP networks include provisions for Reduced Capability (RedCap) UEs. These RedCap UEs have reduced transmit / receive capabilities compared to non-RedCap UEs. For example, RedCap UEs may have the following features: a reduced number of receive / transmit antennas (e.g., fewer than four), reduced UE bandwidth (e.g., up to 20 MHz), half-duplex frequency division duplexing, relaxed UE processing time, and relaxed UE processing capabilities.
[0027] To achieve further reductions in device complexity and energy consumption, enhanced reduced capability (eRedCap) UEs may have further reduced complexity compared to RedCap UEs. For example, further UE baseband bandwidth reduction and UE peak data rate reduction may be provided to eRedCap UEs operating in frequency range 1 (FR1).
[0028] The baseband bandwidth reduction can limit eRedCap UEs to using no more than 5 MHz of baseband bandwidth for physical downlink shared channel (PDSCH) transmissions (both unicast and broadcast) and physical uplink shared channel (PUSCH) transmissions. The radio frequency (RF) bandwidth for uplink and downlink can be larger, for example, 20 MHz (similar to RedCap UEs). In addition, other physical channels in the signal may still be allowed to use a bandwidth portion (BWP) of up to a 20 MHz upper limit of the UE RF plus the baseband bandwidth.
[0029] RedCap UEs may have a constraint for peak data rate reduction (vLayers*Qm*f≥4), where vLayers is the number of transmission layers, Qm is the modulation order, and f is the scaling factor. eRedCap UEs may relax this constraint to vLayers*Qm*f≥1.
[0030] The eRedCap UE can operate with 15 kilohertz (kHz) subcarrier spacing (SCS) or 30 kHz SCS.
[0031] In some embodiments, only one type of eRedCap UE may be defined. This may further reduce UE complexity. However, in other embodiments, more than one type of eRedCap UE may be defined.
[0032] To facilitate the integration of eRedCap UEs into new cellular networks (e.g., networks operating in compliance with 3GPP Release 18 and subsequent TSs), the existing UE capability architecture can be used. Changes to capability signaling may be specified as needed. However, by default, all UE capabilities applicable to RedCap UEs as defined by 3GPP R17 TSs are applicable to eRedCap UEs unless otherwise specified.
[0033] If UE 104 is an eRedCap UE (which will be assumed for the purposes of the embodiments described herein), base station 108 may need to restrict the scheduling of PUSCH / PDSCH transmissions to physical resource block (PRB) allocations of no more than 5 MHz. This restriction may apply even during the RA procedure (e.g., with respect to Message 3 (Msg3) PUSCH). However, in traditional networks, information about the UE's capabilities (including RedCap capabilities) is not communicated to the network until much later. Typically, the UE will camp on a cell, perform an RA procedure, enter connected mode, receive downlink control information (DCI) scheduling resources for the UE to send uplink registration information, and then respond to the UE capability request.
[0034] Embodiments of the present disclosure provide signaling during the RA procedure to inform the base station 108 that the UE 104 is an e RedCap UE. This may allow the base station 108 to ensure that subsequent scheduling does not exceed the limited capabilities of the UE 104.
[0035] Figure 2 Illustrated are signaling operations 200 according to some embodiments. In signaling operations 200, UE 104 may notify base station 108 that UE 104 is operating as an eRedCap UE.
[0036] Signaling operations 200 may include base station 108 supporting eRedCap, at 204. In some embodiments, base station 108 may transmit a broadcast transmission indicating support of eRedCap by one or more cells provided by base station 108.
[0037] The signaling operations 200 may also include a RA procedure 208. The RA procedure 208 may be a 4-step RA type using CBRA.
[0038] The RA procedure 208 may include, at 212, the UE 104 sending a first message (Msg1) to the base station 108. Msg1 may include an RA preamble sent on a physical random access channel (PRACH) resource. The RA preamble may be randomly selected from a shared RA preamble pool. At 216, the RA procedure may include the base station 108 responding to Msg1 by sending a random access response (RAR) in a second message (Msg2). The RAR may include an RA preamble identifier, timing alignment information, an initial uplink grant, and a temporary cell-radio network temporary identifier (TC-RNTI). If the UE 104 receives a PDCCH with the RAR within a defined time window, and the RAR includes a preamble identifier corresponding to the preamble sent in Msg1, the response is successful. The RA procedure 208 may then include the UE 104 transmitting the scheduled uplink transmission via the PUSCH in a third message (Msg3). The third message may include an ID for contention resolution. In a fourth step, the base station 108 may transmit a contention resolution ID in a fourth message (Msg4) at 224. If the UE 104 correctly decodes the contention resolution ID, the RA process 208 may be complete.
[0039] In the case where the RA procedure 208 is CFRA, the network may assign RA preambles dedicated to the UE 104 to the UE 104. These dedicated RA preambles may be sent in the RA preamble assignment message. Therefore, contention resolution of Msg4 may not be required.
[0040] UE 104 may use the RA procedure to indicate that it is an eRedCap UE. Base station 108 may then use this information to schedule uplink and downlink shared channels (e.g., PUSCH / PDSCH) within eRedCap limitations at 228. This may be accomplished, for example, by limiting the scheduled PRBs to have a bandwidth of 5 MHz or less. This limitation may be imposed at least until UE 104 provides a more complete set of eRedCap capabilities to base station 108 at a later time.
[0041] UE 104 may use RA procedure 208 to indicate that it is an eRedCap UE according to one or more of the following options. These options may be used in conjunction with each other or independently. Although some combinations of these options are specifically described, other combinations may also be used in various embodiments.
[0042] In a first option, the UE 104 may include an eRedCap indication in a MAC control element (CE) included in the Msg3 sent at 220. In some embodiments, the eRedCap indication may be a value indicated in the Logical Channel Identifier (LCID) field of the MAC CE. For example, Table 6.2.1-2: LCID Values for UL-SCH of 3GPP TS 38.321 v17.3.0 2023-01-13 may be modified as shown in Table 1 below, with the crossed-out portions deleted and the underlined portions added to accommodate the eRedCap indication.
[0043]
[0044] Table 1
[0045] Thus, if the size of the UL CCCH MAC service data unit (SDU) of Msg3 carrying the LCID is 48 bits, the UE 104 may include a value corresponding to code point / index 37, or if the size of the UL CCCH MAC SDU of Msg3 carrying the LCID is 64 bits, the UE may include a value corresponding to code point / index 38. In either case, the base station 108 will understand that the UE 104 is operating as an eRedCap UE and should not schedule UL / DL shared channels above 5 MHz to the UE.
[0046] In some embodiments, modifications to code points 35 / 36 are included only if modifications to 37 / 38 are not added. This may be the case if the base station 108 supports both RedCap and eRedCap and plans to schedule conservatively even for RedCap (until actual capabilities are received). In other embodiments, modifications to code points 35 / 36 will be added along with modifications to 37 / 38. This may allow legacy base stations that have not implemented the updated eRedCap to treat an eRedCap UE as a RedCap UE and not handle the UE. Base stations that have implemented the updated eRedCap may additionally look at the 37 / 38 code points to determine whether the UE is a RedCap or eRedCap UE. If a base station only supports RedCap and not eRedCap, then eRedCap may not reside on its cell.
[0047] In a second option of using the RA procedure 208 to indicate that the UE 104 is an eRedCap UE, the UE 104 may send Msg1 using the RACH partition configured by the network for eRedCap UEs.
[0048] RACH partitioning can be accomplished by the network associating a RACH resource set with one or more characteristics. A RACH resource set will only be valid for RA procedures with the associated characteristics. In some embodiments, eRedCap operation can be a characteristic that can be associated with a RACH resource set. A RACH resource set (which can also be referred to as a RACH partition) can include an RA preamble.
[0049] In some embodiments, the network may use a FeatureCombination information element (IE) to configure RACH partitioning for an eRedCap UE. The FeatureCombination IE may be used to indicate a feature or feature combination to be associated with a set of RA resources (e.g., an example of a FeatureCombinationPreambles IE). The Abstract Syntax Notation 1 (ASN1) code for the FeatureCombination IE that enables configuration of RACH partitioning for an eRedCap UE is as follows.
[0050]
[0051]
[0052] The presence of the eRedCap value in the FeatureCombination IE indicates that eRedCap is part of the feature combination associated with the RACH partition.
[0053] The FeatureCombinationPreambles IE associates a preamble set with a feature combination. The AS N1 code of the FeatureCombinationPreambles IE that can configure RACH partitioning for eRedCap UE is as follows.
[0054]
[0055] Unless otherwise specified, the FeatureCombination IE and FeatureCombinationPreambles IE may be similar to those defined in 3GPP TS 38.331 v17.3.0 (2022-12).
[0056] In some embodiments, separate RACH partitions may be configured for RedCap UEs and eRedCap UEs. For example, a first RACH partition may be configured for and used by RedCap UEs, and a second RACH partition may be configured for and used by eRedCap UEs. Figure 2 , the RA preamble for the Msg1 transmission at 212 may be selected from the second RACH partition. The base station 108 may then determine that the UE 104 is operating as an eRedCap UE upon receiving the RA preamble. In some instances, the UE 104 may also transmit another eRedCap indication in the Msg3 transmission at 220 (e.g., by selecting an LCID associated with eRedCap). In other instances, no additional eRedCap indication may be provided in the Msg3 transmission at 220.
[0057] In some embodiments, one RACH partition may be configured for and used by both RedCap UEs and eRedCap UEs. This may be achieved by providing a configuration in which both RedCap UEs and eRedCap UEs are configured to use the same RACH configuration (e.g., a featureCombination configuration). In these embodiments, in the case where all types of UEs with reduced capabilities use the RACH configuration, it may be advantageous to additionally include an eRedCap indication in the Msg3 transmission at 220 to achieve further differentiation.
[0058] In some embodiments, the network (e.g., base station 108) may instruct UE 104 to use Msg1-based indications (e.g., using a RA preamble configured for a RACH partition for eRedCap UEs), Msg3-based indications (e.g., using an LCID that conveys eRedCap indications), or both Msg1-based indications and Msg3-based indications.
[0059] In some embodiments, the network may provide instructions for using Msg1 / Msg3-based indications via RACH partition configuration (e.g., FeatureCombination IE and FeatureCombinationPreambles IE). Additionally / alternatively, the network may provide instructions for using Msg1 / Msg3-based indications via a broadcast message (such as, for example, a System Information Broadcast 1 (SIB1) transmission). The ASN1 code for SIB1 that enables the network to instruct the UE to provide an eRedCap indication may be provided as follows.
[0060]
[0061]
[0062] The base station 108 may use SIB1 to indicate that the network supports eRedCap. The indication that the network supports eRedCap may mean that the UE 104 may use the same RACH partition used by RedCap UEs, and further differentiation may be provided by the LCID sent using Msg3.
[0063] Unless otherwise specified, SIB1 may be similar to SIB1 defined in 3GPP TS 38.331.
[0064] In an implementation where there is no indication in the RACH partition for eRedCap but SIB1 indicates that the network supports eRedCap, the UE 104 may use a Msg3 based indication instead of a Msg1 based indication.
[0065] In some embodiments, rather than relying on the RACH partitioning framework to provide eRedCap indication as described above, separate PRACH resources may be configured for eRedCap indication. UE 104 will use eRedCap-specific PRACH resources for RA procedure 208 to indicate that it is operating as an eRedCap UE. Specifically, eRedCap-specific PRACH resources may be used for Msg1 transmission at 212.
[0066] eRedCap-specific PRACH resources can be configured without using the feature combination resources defined for RACH partitioning. Instead, eRedCap-specific PRACH resources can be configured using BWP configuration. For example, the BWP-UplinkCommon IE, which is used to configure common parameters for the uplink BWP, can be modified to configure eRedCap-specific PRACH resources as follows.
[0067]
[0068]
[0069] The rach-ConfigCommonE-RedCap-r18 IE may indicate that the BWP is specifically configured for eRedCap UEs. Therefore, when the UE 104 performs a RA procedure in the BWP, the base station 108 may know that the UE is an eRedCap UE.
[0070] Unless otherwise specified, the BWP-UplinkCommon IE may be similar to the BWP-UplinkCommon IE defined in 3GPP TS 38.331 v17.3.0 (2022-12).
[0071] In some embodiments, the eRedCap-specific PRACH resources may be a feature that is not combined with other features associated with the eRedCap identification. In other embodiments, the eRedCap-specific PRACH resources may be combined with other eRedCap identification features. For example, in some embodiments, the UE 104 may use the eRedCap-specific PRACH resources in conjunction with Msg3-based identification.
[0072] In some embodiments, the UE 104 may use Msg3 to send an indication of whether it is configured to use eRedCap-specific PRACH resources.
[0073] In other embodiments, the UE 104 may not need to use Msg3 to send an indication of whether it is configured to use eRedCap-specific PRACH resources. In these embodiments, one or more of the following options may be used. In the first option, the UE 104 may still use the LCID value for RedCap UEs from R17 (e.g., code point 35 or 36 from Table (without the proposed modification)). In the second option, the UE 104 may use a legacy LCID value that does not correspond to a UE with any form of reduced capability.
[0074] Figure 3 A BWP configuration 300 is illustrated according to some embodiments, where different BWPs are configured with different eRedCap notification procedures.
[0075] RACH partitioning configurations can be BWP-specific. Thus, certain BWPs can be configured with RACH partitions that can be used for eRedCap identification. As shown in BWP configuration 300, BWP1 and BWP3 can have configured eRedCap partitions. If UE 104 operates in any of these BWPs, the UE can use a RACH partitioning-based approach for eRedCap identification.
[0076] If the UE 104 is operating in a BWP that does not have RACH partitioning configured for eRedCap identification, the UE 104 can fall back to using other procedures for eRedCap identification. For example, if the UE 104 is operating in BWP0 that is configured to use eRedCap identification based on Msg3, the UE 104 can use the eRedCap-specific LCID in Msg3 to provide the eRedCap identification. If the UE 104 is operating in BWP2 that is configured to use separate PRACH resources, the UE 104 can use the eRedCap-specific PRACH resources for eRedCap identification.
[0077] Although not explicitly shown, the BWP may be configured with more than one eRedCap identification process.
[0078] In various implementations, some eRedCap identification procedures may be preferred over others. For example, in one implementation, RACH partitioning may be the preferred eRedCap identification procedure. Thus, if the BWP is configured with both eRedCap-specific PRACH resources and RACH partitioning, the UE 104 uses RACH partitioning for eRedCap identification instead of eRedCap-specific PRACH resources. In other implementations, other eRedCap identification procedures may be preferred.
[0079] Figure 4 Signaling operations 200 are illustrated in accordance with some embodiments. In signaling operations 400, UE 104 may use a two-step RA procedure 408 to inform base station 108 that UE 104 is operating as an eRedCap UE.
[0080] Signaling operations 400 may include base station 108 supporting eRedCap, at 404. In some embodiments, base station 108 may transmit a broadcast transmission indicating support of eRedCap by one or more cells provided by base station 108.
[0081] The RA process 408 may include: at 412, the UE 104 sends a first message (MsgA) to the base station 108. The MsgA transmission may include a RA preamble and a PUSCH transmission. Thus, MsgA indicates Figure 2 At 416, the base station 108 may respond with a second message (MsgB) that includes both the random access response and the contention resolution content. Thus, MsgB represents Figure 2 The four-step process described in
[15] is a combination of Msg2 and Msg4.
[0082] The UE 104 may use the RA procedure 408 to indicate that it is operating as an eRedCap UE in any manner similar to that described above. For example, the UE 104 may include a MAC CE with an eRedCap indication in the LCID in the PUSCH payload sent in MsgA, the UE may select an RA preamble from a RACH partition configured for eRedCap UEs, or the UE may use PRACH resources specific to eRedCap for the RA procedure 408.
[0083] Upon determining that the UE 104 is an eRedCap UE through one or more of the indication mechanisms of the RA process 408, the base station 108 may schedule uplink shared channels and downlink shared channels (e.g., PUSCH / PDSCH) within the eRedCap restrictions at 424. This may be accomplished, for example, by limiting the scheduled PRBs to have a bandwidth of 5 MHz or less. This restriction may be imposed at least until the UE 104 provides the base station 108 with a more complete set of eRedCap capabilities at a later time.
[0084] Figure 5 An operational flow / algorithm structure 500 for eRedCap identification according to some embodiments is illustrated. The operational flow / algorithm structure 500 may be implemented by a UE (such as, for example, UE 104 or 700) or a component therein (eg, processing circuit 704).
[0085] The operational flow / algorithm structure 500 may include generating a RACH message at 504. The RACH message may be a message from a 4-step RA process (e.g., Msg1 or Msg3) or a message from a 2-step RA process (e.g., MsgA). The RACH message may be part of a CBRA process or a CFRA process.
[0086] The operational flow / algorithm structure 500 may further include sending a RACH message to the base station at 508. The sending of the RACH message may provide an indication to the base station that the UE is an eRedCap UE having a UL SCH bandwidth of no greater than 5 MHz.
[0087] In some embodiments, the eRedCap indication may be included in the content of a RACH message. For example, a RACH message may include a PUSCH transmission with an eRedCap indication. This indication may be provided by the value of the LCID field of a MAC CE as described elsewhere herein. The LCID value may indicate that the UE is operating as an eRedCap UE and may additionally indicate whether the CCCH size is 48 bits or 64 bits.
[0088] In some embodiments, the eRedCap indication may be provided by the nature of the RACH message itself. For example, the UE may be configured with RACH resources to be used by an eRedCap UE. In some embodiments, the RACH resources may be a RACH partition configured via the FeatureCombination IE and the FeatureCombinationPreambles IE. A RACH partition may include multiple RA preambles to be used by an eRedCap UE. UE 104 may provide the eRedCap indication by selecting one of the RA preambles for inclusion in a Msg1 or MsgA transmission.
[0089] In some embodiments, the RACH resource may be a PRACH resource configured specifically for eRedCap UEs via the BWP-UplinkCommon IE. The UE 104 may provide an eRedCap indication by sending a RACH message on the eRedCap-specific PRACH resource.
[0090] Figure 6 An operational flow / algorithm structure 600 for eRedCap indication according to some embodiments is illustrated. The operational flow / algorithm structure 600 may be implemented by a base station (such as, for example, base station 108) or network node 800 or a component thereof (eg, processing circuit 804).
[0091] The operational flow / algorithm structure 600 may include receiving a RACH message from the UE at 604. The RACH message may be part of a 2-step or 4-step RA procedure, which may be a CBRA or CFRA procedure.
[0092] The operational flow / algorithm structure 600 may also include, at 608, determining that the UE is an eRedCap UE based on the RACH message received at 604. This determination may be based on the information provided above with respect to Figure 5 or an eRedCap indication provided by a RACH message similar to the RACH messages described elsewhere herein.
[0093] The operational flow / algorithm structure 600 may also include scheduling resources within the eRedCap limit at 612. For example, the base station 108 may limit the scheduling of PUSCH / PDSCH transmissions to PRB allocations not exceeding 5 MHz. The base station 108 may limit the scheduling at least until the base station receives a more complete set of UE capabilities at a later time.
[0094] Figure 7 UE 700 according to some embodiments is illustrated. UE 700 may be similar to Figure 1UE 104 and is essentially interchangeable therewith.
[0095] UE 700 can be any mobile or non-mobile computing device, such as, for example, a mobile phone, a computer, a tablet, an XR device, glasses, an industrial wireless sensor (e.g., a microphone, a carbon dioxide sensor, a pressure sensor, a humidity sensor, a thermometer, a motion sensor, an accelerometer, a laser scanner, a fluid level sensor, an inventory sensor, a voltage / current meter, or an actuator), a video surveillance / monitoring device (e.g., a camera or a camcorder), a wearable device (e.g., a smart watch), or an IoT device.
[0096] UE 700 may include a processor 704, RF interface circuitry 708, memory / storage 712, a user interface 716, sensors 720, driver circuitry 722, a power management integrated circuit (PMIC) 724, antenna structures 726, and a battery 728. The components of UE 700 may be implemented as integrated circuits (ICs), portions of integrated circuits, discrete electronic devices or other modules, logic components, hardware, software, firmware, or combinations thereof. Figure 7 The block diagram is intended to show a simplified view of some of the components of the UE 700. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.
[0097] Components of the UE 700 may be coupled to various other components via one or more interconnects 732, which may represent any type of interface, input / output, bus (local, system, or extension), transmission line, trace, or optical connection that allows various circuit components (on a common or different chip or chipsets) to interact with each other.
[0098] The processor 704 may include processor circuits such as, for example, a baseband processor circuit (BB) 704A, a central processor unit circuit (CPU) 704B, and a graphics processor unit circuit (GPU) 704C. The processor 704 may include any type of circuit or processor circuit that executes or otherwise operates computer-executable instructions (such as program code, software modules, or functional processes from the memory / storage device 712) to cause the UE 700 to perform operations as described herein.
[0099] In some embodiments, the baseband processor circuit 704A can access the communication protocol stack 736 in the memory / storage device 712 to communicate over a 3GPP-compatible network. Generally speaking, the baseband processor circuit 704A can access the communication protocol stack 736 to: perform user plane functions at the PHY layer, MAC layer, RLC sublayer, PDCP sublayer, SDAP sublayer, and upper layers; and perform control plane functions at the PHY layer, MAC layer, RLC sublayer, PDCP sublayer, RRC layer, and NAS layer. In some embodiments, PHY layer operations can additionally / alternatively be performed by components of the RF interface circuit 708.
[0100] The baseband processor circuit 704A may generate or process baseband signals or waveforms that carry information in 3GPP-compliant networks. In some embodiments, the waveforms used for NR may be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink.
[0101] The memory / storage device 712 may include one or more non-transitory computer-readable media including instructions (e.g., the communication protocol stack 736) that may be executed by one or more processors in the processor 704 to cause the UE 700 to provide eRedCap notifications through the RA process as described herein. For example, the processor 704 may cause the UE to perform the operating flow / algorithm structure 500 or any other method or process described herein.
[0102] The memory / storage 712 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 700. In some embodiments, some of the memory / storage 712 may be located on the processor 704 itself (e.g., L1 cache and L2 cache), while other memory / storage 712 is external to the processor 704 but accessible via a memory interface. The memory / storage 712 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.
[0103] The RF interface circuit 708 may include transceiver circuitry and a radio frequency front-end module (RFEM) that allow the UE 700 to communicate with other devices via a radio access network. The RF interface circuit 708 may include various components arranged in a transmit path or a receive path. These components may include, for example, switches, mixers, amplifiers, filters, synthesizer circuits, and control circuits.
[0104] In the receive path, the RFEM receives the radiated signal from the air interface via the antenna structure 726 and further filters and amplifies the signal (using a low-noise amplifier). The signal can be provided to the transceiver's receiver, which down-converts the RF signal to a baseband signal that is provided to the baseband processor of the processor 704.
[0105] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides an RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier before radiating the signal across the air interface via the antenna structure 726.
[0106] In various embodiments, the RF interface circuit 708 may be configured to send / receive signals in a manner compatible with NR access technology.
[0107] The antenna structure 726 may include antenna elements to convert electrical signals into radio waves to travel through the air and convert received radio waves into electrical signals. These antenna elements may be arranged into one or more antenna panels. The antenna structure 726 may have antenna panels that are omnidirectional, directional, or a combination thereof to achieve beamforming and multiple-input, multiple-output communications. The antenna structure 726 may include microstrip antennas, printed antennas manufactured on the surface of one or more printed circuit boards, patch antennas, or phased array antennas. The antenna structure 726 may have one or more panels designed for specific frequency bands, including frequency bands in FR1 or FR2.
[0108] The user interface 716 includes various input / output (I / O) devices designed to enable a user to interact with the UE 700. The user interface 716 includes input device circuitry and output device circuitry. The input device circuitry includes any physical or virtual component for accepting input, including, in particular, one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touch screen, a microphone, a scanner, or a headset. The output device circuitry includes any physical or virtual component for displaying or otherwise conveying information, such as sensor readings, actuator positions, or other similar information. The output device circuitry may include any number or combination of audio or visual displays, including, in particular, one or more simple visual outputs / indicators (e.g., binary state indicators such as light-emitting diodes (LEDs) and multi-character visual outputs), or more complex outputs such as a display device or touch screen (e.g., a liquid crystal display (LCD), an LED display, a quantum dot display, and a projector), where the output, such as characters, graphics, and multimedia objects, is generated or produced by the operation of the UE 700.
[0109] Sensors 720 may include devices, modules, or subsystems designed to detect events or changes in their environment and transmit information about the detected events (sensor data) to some other device, module, or subsystem. Examples of such sensors include: an inertial measurement unit including an accelerometer, gyroscope, or magnetometer; a microelectromechanical system or nanoelectromechanical system including a 3-axis accelerometer, 3-axis gyroscope, or magnetometer; a liquid level sensor; a flow sensor; a temperature sensor (e.g., a thermistor); a pressure sensor; a barometric pressure sensor; a gravity meter; an altimeter; an image capture device (e.g., a camera or lensless aperture); a light detection and ranging sensor; a proximity sensor (e.g., an infrared radiation detector, etc.); a depth sensor; an ambient light sensor; an ultrasonic transceiver; and a microphone or other similar audio capture device.
[0110] The driver circuitry 722 may include software and hardware components that operate to control specific devices embedded in, attached to, or otherwise communicatively coupled to the UE 700. The driver circuitry 722 may include various drivers to allow other components to interact with or control various I / O devices that may be present within or connected to the UE 700. For example, the driver circuitry 722 may include circuitry for facilitating coupling a UICC (e.g., UICC 78) to the UE 700. As another example, the driver circuitry 722 may include: a display driver for controlling and enabling access to a display device; a touch screen driver for controlling and enabling access to a touch screen interface; a sensor driver for obtaining sensor readings from, and controlling and enabling access to, the sensors 720; a driver for obtaining actuator positions of, or controlling and enabling access to, electromechanical components; a camera driver for controlling and enabling access to an embedded image capture device; and an audio driver for controlling and enabling access to one or more audio devices.
[0111] The PMIC 724 may manage power provided to various components of the UE 700. Specifically, with respect to the processor 704, the PMIC 724 may control power source selection, voltage scaling, battery charging, or DC-DC conversion.
[0112] In some embodiments, the PMIC 724 may control or otherwise be part of various power saving mechanisms of the UE 700, including DRX, as discussed herein.
[0113] The battery 728 can power the UE 700, but in some examples, the UE 700 can be installed in a fixed location and can have a power source coupled to the power grid. The battery 728 can be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some implementations, such as in vehicle-based applications, the battery 728 can be a typical lead-acid car battery.
[0114] Figure 8 Illustrated is a network node 800 according to some embodiments. The network node 800 may be similar to the base station 108 and may be substantially interchangeable therewith.
[0115] Network node 800 may include a processor 804 , RF interface circuitry 808 (if implemented as an access node), core network (CN) interface circuitry 812 , memory / storage circuitry 816 , and antenna structures 826 .
[0116] Components of network node 800 may be coupled to various other components via one or more interconnects 828 .
[0117] The processor 804, RF interface circuit 808, memory / storage 816 (including communication protocol stack 810), antenna structure 826 and interconnect 828 may be similar to those of reference Figure 7 Like-named elements are shown and described.
[0118] The memory / storage device 816 may include one or more non-transitory computer-readable media including instructions (e.g., the communication protocol stack 810) that are executable by one or more of the processors 804 to cause the network node 800 to identify and schedule the eRedCap UE described herein. For example, the processor 804 may cause the network node 800 to perform the operating flow / algorithm structure 600 or any other method or process described herein.
[0119] The CN interface circuitry 812 can provide connectivity to a core network (e.g., a 5th Generation Core Network (5GC) using a 5GC-compatible network interface protocol, such as a Carrier Ethernet protocol or some other suitable protocol). Network connectivity can be provided to / from the network node 800 via optical fiber or wireless backhaul. The CN interface circuitry 812 can include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 812 can include multiple controllers for providing connectivity to other networks using the same or different protocols.
[0120] In some embodiments, the network node 800 may be coupled to a transmit receive point (TRP) using antenna structures 826, CN interface circuitry, or other interface circuitry.
[0121] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining 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 stated to users.
[0122] For one or more aspects, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods described in the following embodiments. For example, the baseband circuitry described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the following examples. For another example, circuitry associated with the UE, base station, network element, etc. described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the embodiments described below in the embodiments section.
[0123] Example
[0124] In the following sections, additional exemplary aspects are provided.
[0125] Embodiment 1 includes a method of operating a user equipment (UE), the method comprising: generating a random access channel (RACH) message; and sending the RACH message to a base station, wherein the RACH message is sent to the base station to indicate that the UE is operating as an enhanced reduced capability (eRedCap) UE, the enhanced reduced capability (eRedCap) UE having an uplink (UL) shared channel (SCH) bandwidth of no greater than 5 megahertz (MHz).
[0126] Embodiment 2 includes a method according to embodiment 1 or some other embodiment herein, wherein the RACH message includes a value in a logical channel identifier (LCID) field of a medium access control (MAC) subheader, wherein the value is used to indicate that the UE is operating as the eRedCap UE.
[0127] Embodiment 3 includes the method of embodiment 2 or some other embodiment herein, wherein the value in the LCID field further indicates that a size of a common control channel (CCCH) is 48 bits or 64 bits.
[0128] Embodiment 4 includes the method according to embodiment 1 or some other embodiment herein, further comprising: receiving a random access response scheduling uplink resources from the base station; and sending the RACH message using the uplink resources.
[0129] Embodiment 5 includes the method according to embodiment 4 or some other embodiment herein, further comprising: performing a contention-based random access (CBRA) procedure by receiving the random access response and sending the RACH message.
[0130] Embodiment 6 includes the method according to embodiment 1 or some other embodiment herein, further comprising: receiving a random access (RA) preamble assignment message with a RA preamble from the base station, wherein the RACH message is a random access request including the RA preamble.
[0131] Embodiment 7 includes the method of embodiment 6 or some other embodiment herein, further comprising performing a contention-free random access (CFRA) procedure by receiving the RA preamble assignment message and sending the random access request.
[0132] Embodiment 8 includes a method according to embodiment 1 or some other embodiment herein, wherein the RACH message includes a random access (RA) preamble, and the method further comprises: receiving a configuration of RACH resources to be used by an eRedCap UE; and using the RACH resources to send the RA preamble to indicate that the UE is operating as the eRedCapUe.
[0133] Embodiment 9 includes the method of embodiment 8 or some other embodiment herein, wherein the RACH resource comprises a RACH partition configured with a plurality of RA preambles to be used by an eRedCap UE, wherein the RACH message comprises an RA preamble of the plurality of RA preambles.
[0134] Embodiment 10 includes the method of embodiment 9 or some other embodiment herein, the configuration of RACH resources comprising: a signature combination information element (IE) and a signature combination preamble IE.
[0135] Embodiment 11 includes the method of embodiment 8 or some other embodiment herein, wherein the RACH resources include physical RACH (PRACH) resources dedicated to eRedCap UEs, and the configuration of the PRACH resources includes a bandwidth fraction uplink common information element (IE).
[0136] Embodiment 12 includes a method according to embodiment 8 or some other embodiment herein, further comprising: receiving a system information broadcast (SIB) message from the base station, the system information broadcast (SI B) message having an instruction to provide an eRedCap indication in a message 1 (Msg1) RACH transmission or a message 3 (Msg3) RACH transmission.
[0137] Embodiment 13 includes a method of operating a base station, the method comprising: receiving a random access channel (RACH) message from a user equipment (UE); determining, based on the RACH message, that the UE is operating as an enhanced reduced capability (eRedCap) UE, the enhanced reduced capability (eRedCap) UE having an uplink (UL) shared channel (SCH) bandwidth of no greater than 5 megahertz (MHz); and scheduling uplink or downlink resources for the UE based on the determination that the UE is operating as an eRedCap UE.
[0138] Embodiment 14 includes the method of embodiment 13 or some other embodiment herein, wherein the RACH message includes a value in a logical channel identifier (LCID) field of a medium access control (MAC) subheader, wherein the value is used to indicate that the UE is operating as the eRedCap UE.
[0139] Embodiment 15 includes the method of embodiment 14 or some other embodiment herein, wherein the value in the LCID field further indicates that the size of a common control channel (CCCH) is 48 bits or 64 bits.
[0140] Embodiment 16 includes the method of embodiment 13 or some other embodiment herein, further comprising configuring the bandwidth portion using an eRedCap indication procedure, wherein the eRedCap indication procedure is based on a logical channel identifier, a RACH partition, or a physical RACH (PRACH) resource.
[0141] Embodiment 17 includes the method of embodiment 16 or some other embodiment herein, further comprising configuring a plurality of BWPs using a corresponding plurality of eRedCap indication processes.
[0142] Embodiment 18 includes a method according to embodiment 13 or some other embodiment herein, wherein the RACH message includes a random access (RA) preamble, and the method further includes: providing a configuration of RACH resources to be used by the eRedCap UE to the UE; receiving the RACH message on the RACH resources; and determining that the UE is operating as the eRedCap UE based on receiving the RACH message on the RACH resources.
[0143] Embodiment 19 includes the method of embodiment 18 or some other embodiment herein, wherein the RACH resources include a RACH partition and the configuration is provided in a feature combination information element.
[0144] Embodiment 20 includes the method of embodiment 18 or some other embodiment herein, wherein the RACH resources include physical RACH (PRACH) resources dedicated to eRedCap UEs, and the configuration is provided in a bandwidth part configuration information element.
[0145] Embodiment 21 includes the method according to embodiment 13 or some other embodiment herein, further comprising: sending a system information broadcast (SIB) message, wherein the system information broadcast (SIB) message has an instruction to provide an eRedCap indication in a message 1 (Msg1) RACH transmission or a message 3 (msg3) RACH transmission.
[0146] Another embodiment may include one or more non-transitory computer-readable media, which include instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of a method described or related to any one of Embodiments 1 to 21 or any other method or process described herein.
[0147] Another embodiment may include an apparatus comprising logic components, modules, or circuits for performing one or more elements of the method described in accordance with or related to any of Embodiments 1 to 21, or any other method or process described herein.
[0148] Another embodiment may include a method, technique, or process described according to or related to any one of Embodiments 1 to 21, or a portion or component thereof.
[0149] Another embodiment may include a device comprising: one or more processors; and one or more computer-readable media, wherein the one or more computer-readable media include instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process described in accordance with or related to any one of embodiments 1 to 21 or a portion thereof.
[0150] Another embodiment comprises a signal as described or relating to any one of embodiments 1 to 21, or parts or components thereof.
[0151] Another embodiment may include a datagram, information element, packet, frame, segment, PDU or message as described or related to any one of embodiments 1 to 21 or part or component thereof or otherwise described in this disclosure.
[0152] Another embodiment may include a signal encoded with data as described or associated with any one of embodiments 1 to 21, or portions or components thereof, or as otherwise described in this disclosure.
[0153] Another embodiment may include a signal encoded with a datagram, IE, packet, frame, segment, PDU, or message as described or related to any one of embodiments 1 to 21, or part or component thereof, or as otherwise described in this disclosure.
[0154] Another embodiment may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process described in accordance with or related to any one of embodiments 1 to 21 or a portion thereof.
[0155] Another embodiment may include a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform a method, technique, or process as described or related to any one of embodiments 1 to 21 or a portion thereof.
[0156] Another embodiment may include signals in a wireless network as shown and described herein.
[0157]
[0011] Another embodiment may include a method of communicating in a wireless network as shown and described herein.
[0158]
[0011] Another embodiment may include a system for providing wireless communications as shown and described herein.
[0159]
[0011] Another embodiment may include an apparatus for providing wireless communications as shown and described herein.
[0160] Unless expressly stated otherwise, any of the above embodiments may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the various aspects to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the various aspects.
[0161] Although the above aspects have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to encompass all such variations and modifications.
Claims
1. One or more computer-readable media having instructions that, when executed, cause a user equipment (UE): generating a random access channel (RACH) message; and The RACH message is sent to a base station to indicate that the UE is operating as an enhanced reduced capability (eRedCap) UE with an uplink (UL) shared channel (SCH) bandwidth of no greater than 5 megahertz (MHz).
2. The one or more computer-readable media of claim 1 , wherein the RACH message includes a value in a Logical Channel Identifier (LCID) field of a Medium Access Control (MAC) subheader, wherein the value is used to indicate that the UE is operating as the eRedCap UE.
3. The one or more computer-readable media of claim 2, wherein the value in the LCID field further indicates that a size of a common control channel (CCCH) is 48 bits or 64 bits.
4. The one or more computer-readable media of claim 1 , wherein the instructions, when executed, further cause the UE to: receiving a random access response scheduling uplink resources from the base station; and The RACH message is sent using the uplink resources.
5. The one or more computer-readable media of claim 4, wherein the instructions, when executed, further cause the UE to: A contention-based random access (CBRA) procedure is performed by receiving the random access response and sending the RACH message.
6. The one or more computer-readable media of claim 1 , wherein the instructions, when executed, further cause the UE to: receiving a random access (RA) preamble assignment message having a RA preamble from the base station, The RACH message is a random access request including the RA preamble.
7. The one or more computer-readable media of claim 6, wherein the instructions, when executed, further cause the UE to: A contention-free random access (CFRA) procedure is performed by receiving the RA preamble assignment message and sending the random access request.
8. The one or more computer-readable media of claim 1 , wherein the RACH message comprises a random access (RA) preamble and the instructions, which when executed further cause the UE to: receiving a configuration of RACH resources to be used by the eRedCap UE; and The RA preamble is sent using the RACH resource to indicate that the UE is operating as the eRedCap UE.
9. The one or more computer-readable media of claim 8, wherein the RACH resource comprises a RACH partition configured with a plurality of RA preambles to be used by an eRedCap UE, wherein the RACH message comprises an RA preamble of the plurality of RA preambles.
10. The one or more computer-readable media of claim 9, wherein the configuration of RACH resources comprises: Signature combination information element (IE) and signature combination preamble IE.
11. The one or more computer-readable media of claim 8, wherein the RACH resources comprise physical RACH (PRACH) resources dedicated to eRedCap UEs, and the configuration of the PRACH resources comprises a bandwidth fraction uplink common information element (IE).
12. The one or more computer-readable media of claim 8, wherein the instructions, when executed, further cause the UE to: A system information broadcast (SIB) message is received from the base station, the system information broadcast (SIB) message having an instruction to provide an eRedCap indication in a message 1 (Msg1) RACH transmission or a message 3 (Msg3) RACH transmission.
13. A method of operating a base station, the method comprising: receiving a random access channel (RACH) message from a user equipment (UE); determining, based on the RACH message, that the UE is operating as an enhanced reduced capability (eRedCap) UE having an uplink (UL) shared channel (SCH) bandwidth of no greater than 5 megahertz (MHz); as well as Uplink or downlink resources for the UE are scheduled based on the determination that the UE is operating as an eRedCap UE.
14. The method of claim 13, wherein the RACH message includes a value in a Logical Channel Identifier (LCID) field of a Medium Access Control (MAC) subheader, wherein the value is used to indicate that the UE is operating as the eRedCap UE.
15. The method of claim 14, wherein the value in the LCID field further indicates that a size of a common control channel (CCCH) is 48 bits or 64 bits.
16. The method according to claim 13, further comprising: The bandwidth portion is configured using an eRedCap indication procedure based on a logical channel identifier, a RACH partition, or a physical RACH (PRACH) resource.
17. The method according to claim 16, further comprising: Multiple BWPs are configured using the corresponding multiple eRedCap directive procedures.
18. The method of claim 13, wherein the RACH message comprises a random access (RA) preamble, and the method further comprises: providing, to said UE, a configuration of RACH resources to be used by the eRedCap UE; receiving the RACH message on the RACH resource; as well as A determination is made based on receiving the RACH message on the RACH resource that the UE is operating as the eRedCap UE.
19. The method of claim 18, wherein the RACH resources comprise a RACH partition and the configuration is provided in a feature combination information element.
20. The method of claim 18, wherein the RACH resources comprise physical RACH (PRACH) resources dedicated to eRedCap UEs, and the configuration is provided in a bandwidth portion configuration information element.
21. The method of claim 13, further comprising: A system information broadcast (SIB) message is transmitted with an instruction to provide an eRedCap indication in a message 1 (Msg1) RACH transmission or a message 3 (msg3) RACH transmission.